Prioritizing Adversaries, Exposing the Back Door

Inaccurate threat modeling diverts essential resources, ultimately compromising the defense of the actual attack surface

The 3CX incident in 2023 is instructive. An adversary — later attributed to Lazarus Group — compromised the 3CX build environment and trojanised the desktop application before it reached end users. Hundreds of thousands of installations were affected. The malicious code was compiled into a signed binary and distributed through the vendor’s legitimate update mechanism. No secret scanner would have caught it.

Ok, but what do you actually mean?

It is a statement about what secret scanners are actually built to do, and the gap between that and how they are frequently described and sold.

The Framing Problem

Search for “secret scanning” and “supply chain security” and you will find them treated as nearly synonymous. Security vendors, conference talks, and framework documentation routinely position secret scanning as a pillar of supply chain defense. The framing is not entirely wrong — hardcoded credentials in source code are a genuine vector. But the category is much narrower than the marketing implies, and the conflation has operational consequences.

Supply chain attacks operate at the level of build systems, update mechanisms, dependency registries, and compiled artefacts. SolarWinds was a build system compromise — malicious code was injected at compile time. 3CX was a compromised installer. The XZ Utils backdoor was introduced through social engineering of a maintainer and embedded in a legitimate commit. Volt Typhoon pre-positioned access through legitimate credentials obtained via living-off-the-land techniques — not through plaintext secrets committed to a repository.

In none of these cases would a tool scanning source files for high-entropy strings have produced a meaningful signal.

Secret scanners operate on a completely different problem: a developer accidentally committing a credential into version control. Not a state actor. Not a compromised build pipeline. A tired engineer doing a git add . who included a .env file that shouldn't have been there, or hardcoded a database password "just for testing" that survived into a commit. Exposed credentials in public repositories are routinely harvested within minutes by automated tooling. The consequences range from cloud bill shock to full environment compromise. The developer error vector is real, common, and worth defending against. But it is not supply chain security in the sense the industry uses that term when discussing SolarWinds or 3CX.

What the Scanner Is Seeing

A secret scanner reads text files. It applies patterns — regular expressions tuned to match the structure of known credential formats — and optionally applies statistical filters to reduce false positives on strings that match the pattern but are clearly placeholders.

That is the entire operation. The scanner has no visibility into:

• Whether a found credential is currently active
• Whether it has been used since it was committed
• How it arrived in the file — human error, deliberate insertion, or automated generation
• Whether the pipeline that produced the file was itself compromised

If an adversary has already compromised your CI/CD environment, a scanner that reads the source files tells you nothing about the compromise. The adversary is not committing secrets in plaintext. They are operating in the build layer, the execution layer, or the dependency layer — surfaces that static text analysis cannot reach.

Incremental improvements to heuristic sophistication cannot compensate for a fundamental scope mismatch. The current scanning logic is effectively blind to this threat, as the vulnerability manifests at a layer beyond its reach.

Where the Confusion Comes From

Part of the problem is that “supply chain” has become an elastic term. A decade ago it referred primarily to hardware tampering and compromised firmware in physical supply chains. In software security, it was used to describe dependency confusion and typosquatting attacks on package registries. After SolarWinds it expanded further to encompass build system compromise, update mechanism abuse, and insider threats at software vendors.

Secret scanning fits into this expanded definition at the margins — a leaked credential could theoretically provide access to a build system, creating a supply chain risk. But the causal chain is long enough that positioning the scanner as a supply chain security control obscures what it actually does well.

Secret scanning functions optimally as a developer error-prevention control, not a comprehensive security panacea. Its primary utility is situated at the ingress boundary — the critical junction between the local workstation and the remote repository. By targeting the specific threat of accidental credential inclusion during the commit process, it serves as a high-fidelity filter for human-centric lapses in hygiene. This is the extent of its operative value: a focused mitigation for a specific failure mode in the development lifecycle.

Vendors benefit from the broader framing because “supply chain security” commands more budget and urgency than “automated workflow hygiene” or “commit-level integrity controls”. But this misclassification does real damage once security teams that believe they have addressed supply chain risk by deploying a secret scanner have a false sense of coverage. The incidents they are most likely to face — compromised dependencies, build system intrusions, adversary activity in CI/CD pipelines — remain unaddressed.

The Operational Implication

If you are defending against workflow-level data exposure, a well-tuned secret scanner is a high-value, low-friction control. The ROI is good. The failure mode it addresses — credential exposure — is concrete, measurable, and has a clear remediation path. Deploy it. Run it at the PR stage so commits are blocked before they reach the repository, not after.

If you are defending against adversary-controlled supply chain intrusions, the detection surface is elsewhere. Build system integrity — are the outputs reproducible from the declared inputs? Dependency monitoring — are transitive dependencies behaving consistently? Pipeline telemetry — are build steps making unexpected network connections? Binary integrity verification — does the distributed artefact match the build output?

They require visibility into layers that most organisations do not currently instrument. But they are the problems that the notable supply chain incidents of the last five years actually required to detect. Secret scanning addresses neither of them. That does not make it useless. It makes it a specific tool with a specific job.

A Note on Air-Gapped Environments

One context where the framing matters practically is regulated environments — operational technology networks, classified government infrastructure, financial pipelines with egress restrictions. In these environments, the dominant secret scanning tools either cannot run (SaaS platforms require connectivity) or run in a degraded state (TruffleHog’s live verification layer does not function without outbound access, collapsing its precision advantage to regex).

The developer error problem does not go away in these environments. Engineers still commit credentials accidentally. The scanner still needs to run. But the tooling choices narrow, and the compliance requirements are more explicit.

The relevant evaluation in these environments is not “does this tool address supply chain risk” — it doesn’t, and neither does any other static scanner. The relevant evaluation must be “does this tool reliably catch the specific class of developer mistake it claims to catch, in an environment where it cannot phone home, without generating enough false positives to train developers into ignoring its output?”. That is a tractable question with a tractable answer. It is a better starting point than the inflated framing.

The Broader Point

The security industry has a recurring problem with scope inflation. A tool is built to solve a specific, well-defined problem. The problem is real. The tool works. Then the marketing attaches it to a larger, more alarming category of risk because that category commands more attention and budget. The tool does not change. The expectations placed on it do.

Secret scanning is one instance of this pattern. Vulnerability scanners that map CVEs to “nation-state attack vectors” are another. Endpoint detection tools that claim to provide “complete supply chain visibility” are a third.

When defenders believe a control addresses a threat it does not actually address, they stop looking for the additional controls that would. Coverage gaps compound. Incidents happen that a more accurate threat model would have surfaced as insufficiently defended. Being precise about what a tool does — and what it does not do — is not a limitation of the tool. It is how you use it correctly.