Enhancing Secret Detection in Cybersecurity with Semantic Analysis

Enhancing Secret Detection in Cybersecurity with Semantic Analysis

Speakers: Danny Lazarev, Erez Harush

Conference: BSidesSF 2025 — April 26-27, 2025, San Francisco

YouTube: https://www.youtube.com/watch?v=1GIdQE1EuWM

Reading time: ~7 minutes

TL;DR

Regex-based secret detection generates too many false positives, misses context-dependent secrets, and can't keep pace with the explosion of new API integrations. Researchers Danny Lazarev and Erez Harush from Wiz describe how they fine-tuned a small language model (SLM) using a multi-agent LLM pipeline to achieve 86% precision and 80% recall on generic secret detection — running in under 10 seconds per file on a single-threaded CPU machine, at a fraction of the cost and privacy risk of large language model alternatives.

Introduction

The proliferation of third-party integrations has created an ever-expanding attack surface of API keys, tokens, and service account credentials embedded in code repositories. According to Wiz's research, 86% of organizations have at least one repository containing secrets, and the percentage with cloud keys — credentials that enable lateral movement inside cloud environments — in their public or open-source repositories is likely even higher among the general population. As Erez Harush noted, the rise of MCP servers and AI coding assistants like Cursor is generating yet more credentials, often stored insecurely by developers moving quickly.

The traditional defense — regex patterns tuned to known secret formats — was never designed for this environment. Lazarev and Harush set out to build something better: a purpose-built, production-scale secret detection engine using fine-tuned small language models that could run privately, cheaply, and fast enough to scan roughly 20 million files per day.

The Limits of Regex-Based Detection

▶ Watch: Why regex falls short for secret detection (04:00)

Regex-based detection fails in three interconnected ways. First, false positives: a pattern broad enough to catch real secrets will also catch placeholder values like test_test, XXXXXXXXXX, or similar dummy strings that appear during development and testing. Second, maintenance burden: every new service or API introduces a new secret format that requires a human-crafted regex, and writing a regex precise enough to minimize false positives while maintaining coverage is genuinely difficult. Third, and most critically, lack of context: a regex cannot understand that a variable named llave_privada (Spanish for "private key") holding an opaque string is a real secret, nor can it understand that a string matching a 32-character alphanumeric pattern in a test fixture is almost certainly not one.

The presenters illustrated these limits with two real examples from public repositories. In the first, a Spanish-named variable (llave_privada) holding an actual private key would be invisible to any regex that didn't include that specific keyword. In the second, a generic-looking secret was actually a placeholder — a regex would flag it as high-confidence, but any developer or security engineer reading the context would immediately recognize it as a test value. Both failure modes carry operational costs: missed true positives create real exposure, while false positives generate alert fatigue and erode developer trust.

Why Small Language Models, Not Large Ones

▶ Watch: SLM advantages for security workloads (08:01)

Large language models (LLMs) have obvious advantages for contextual reasoning — they generalize well, handle long context windows, and can be guided with prompt engineering. But three practical barriers rule them out for production secret scanning at scale: runtime and cost (GPU-dependent inference at $X per thousand tokens adds up quickly at 20 million files per day), latency (cloud API round-trips introduce unacceptable delays for near-real-time scanning), and privacy (organizations are unwilling, and often legally unable, to send source code containing potential secrets to external API endpoints).

Small language models (SLMs) — defined roughly as models with 8 billion parameters or fewer — address all three. Examples include the Phi family from Microsoft, Qwen from Alibaba, and Meta's Llama family. They can run on CPU machines without GPU acceleration, dramatically reduce cost, and keep all data on-premise. The catch: off-the-shelf SLMs are general-purpose models, not trained for secret detection. The solution is fine-tuning.

Building the Dataset: Multi-Agent LLM Labeling

▶ Watch: Multi-agent data generation pipeline (12:01)

Before fine-tuning is possible, a labeled training dataset is needed. With no existing labeled corpus for this specific task, the team built one from scratch using a multi-agent LLM pipeline — a process that would have been prohibitively expensive in manual analyst time just a few years ago.

The pipeline started with the GitHub Archive (a public dataset of all GitHub activity) filtered by basic keywords and code license. Two LLM agents — one based on Google Gemini, one on Anthropic's Claude Sonnet — independently labeled files, and a consensus mechanism merged their outputs. A third LLM served as a "judge," validating results and confidence scores. Edge cases underwent manual review. After prompt refinement, the entire pipeline ran across 100,000 files, producing a high-quality labeled dataset at a total cost of approximately $5,000.

Each labeled record captures more than a binary "secret / not secret" verdict. The model is asked to produce: a description of the secret, its category (e.g., "Facebook App Secret," "Ticktail Access Token"), the variable name, the secret value, and a confidence score (high / medium / low). That confidence score is the engine of the system's practical value — a high-confidence match in a production configuration file demands immediate action, while a low-confidence match in a test fixture can be triaged differently or suppressed.

Fine-Tuning: LoRA, Quantization, and the Production Target

▶ Watch: LoRA fine-tuning and quantization explained (16:01)

With the dataset in hand, the team chose LoRA (Low-Rank Adaptation) for parameter-efficient fine-tuning. Rather than updating all model weights — a process requiring substantial GPU time even for small models — LoRA adds a small set of low-rank adapter parameters on top of a frozen base model. Lazarev compared this to adding filters to a lens system: you're not changing the original optics, only adding calibrated filters. This approach dramatically reduces compute requirements and allows rapid iteration — fine-tune, evaluate, adjust data, fine-tune again — which proved essential over the two-to-three month research cycle.

The team also applied 8-bit quantization, representing model weights as 8-bit integers rather than 32-bit floating points. This significantly reduces memory footprint and speeds up inference, with minimal impact on output quality. At 20 million files per day, even small per-file latency reductions compound into meaningful infrastructure savings.

Output format was also carefully designed. Rather than generating verbose JSON responses (every extra token has a cost at scale), the model was trained to output a compact tuple that is post-processed into structured JSON. This reduced output token count substantially while maintaining all necessary information.

Results: 86% Precision, 80% Recall, 10 Seconds Per File

▶ Watch: Performance metrics and benchmark results (18:01)

The performance numbers tell a clear story. For generic secrets — credentials without strong structural patterns that regex-based detectors struggle most with — the baseline regex approach achieved 56% recall and 32% precision, which Lazarev described simply as "awful." The fine-tuned SLM (a Qwen model with approximately 3 billion parameters) achieved 80% recall and 86% precision on the same evaluation set, processing files in under 10 seconds on a single-threaded CPU.

An even smaller model — Qwen Code at 500 million parameters — reached 71% recall and 87% precision, processing files in just 2 seconds. Both models can run on a laptop (with Apple Silicon being notably faster), opening the door to pre-commit hooks and developer-side integration. The audience responded with spontaneous applause at this point.

One notable engineering challenge was hallucinations: the model occasionally produced secret values or variable names slightly different from what appeared in the input file. The team identified a close, finite set of hallucination patterns and built a custom fuzzy matching mechanism to map hallucinated outputs back to ground truth, preserving true positive counts that would otherwise have been lost.

Notable Quotes

"Eighty-six percent of organizations have at least one repository with secrets inside — and the number with cloud keys in public repositories is likely even higher for the general population."

— ▶ 00:00

"The model can run even on your laptop, and your laptop will actually be faster if you use a Mac. And that means you can deploy this model as a pre-commit hook to your Git."

— ▶ 20:02

"If we look at fine-tuning four or five years ago, it was reserved for data scientists. But now, software engineers, analysts, security researchers can do those things too — and there are cloud providers offering one-click fine-tuning."

— ▶ 22:02

Key Takeaways

• Regex is not enough for generic secret detection. 56% recall and 32% precision on generic secrets demonstrates that regex-only approaches leave substantial exposure, particularly for credentials without well-known structural prefixes.
• Small language models close the gap at manageable cost. A fine-tuned SLM at 3 billion parameters achieved performance close to the large LLM baseline at a fraction of the inference cost, with full data privacy.
• LLMs are practical data labeling engines. The $5,000 multi-agent labeling pipeline produced a 100,000-file labeled dataset that would have required months of manual analyst work. Security teams should internalize this as a general capability.
• Confidence scoring is the operational key. Extracting not just secret identity but confidence level (high/medium/low) allows security programs to triage findings by severity and reduce alert fatigue — the most common failure mode of automated detection systems.
• Fine-tuning is now accessible. With frameworks like Unsloth for efficient training and llama.cpp for quantized inference, security engineers without deep machine learning backgrounds can now build and deploy domain-specific models for their detection pipelines.