# Your Security Scanner Just Became the Attacker's Best Friend
Security teams spent years convincing engineering organizations to embed application security scanners into their CI/CD pipelines. Threat modeling, SAST, dependency auditing — the whole discipline of shifting left was built on the premise that catching vulnerabilities early means they get fixed. Now researchers are about to show, on the main stage at Black Hat, that those same scanners can be turned into the delivery mechanism for the attack you were trying to prevent.
The irony would be funny if the blast radius weren't so real.
## What the Attack Actually Looks Like
ZeroPath's security team didn't discover this by hunting for a theoretical weakness. They stumbled into it while investigating an alert in their own environment late last year. That probe led to a systematic evaluation of 20 application security vendors — the kind of companies selling scanners to teams who believe they're hardening their code.
Five of the twenty had significant vulnerabilities. One handed out the maximum bug bounty the vendor offered.
What the researchers found on the other side of these vulnerabilities is the kind of list that turns a security director's hair gray: cloud credentials, access to production databases, Docker tokens, GitHub personal access tokens belonging to actual vendor developers. "These instances could have reached customers that thought they were secure," ZeroPath co-founder and CTO Raphael Karger told Dark Reading ahead of next week's session.
The attack path is cleaner than you might expect. You don't need to compromise the vendor's build environment. You don't need insider access. You don't need to pull off a sophisticated supply chain intrusion. You feed the scanner a specially crafted malicious repository and let it do its job. The scanner — built to find dangerous code — runs the dangerous code in the process of analyzing it.
## This Has Happened Before, Except Worse
Last spring's TeamPCP campaign provides the comparison point everyone should be sitting with. That group managed something more operationally complex: they compromised the development environments of two separate open source security projects, poisoning official distributions of Trivy and KICS. Teams that pulled those tools as dependencies got backdoored builds. The credential theft that followed was extensive.
The ZeroPath research describes a different threat model — less effort, potentially broader exposure. Compromising a vendor's CI environment is hard. Getting a security scanning service to scan your malicious repo is trivially easy, especially when many vendors offer free tiers or public demo environments to attract customers. Any researcher, bug hunter, or attacker with a GitHub account can queue a scan.
The attack surface expands further when you consider who uses these tools. Security services that offer to scan user-submitted code — think automated code review platforms, vulnerability audit services, even some open source project security initiatives — could be serving as unwitting processing infrastructure for attacker reconnaissance.
## The Developer Token Problem Is Specific and Underreported
One finding from the ZeroPath research deserves more attention than it's likely to get: the GitHub personal access tokens and Docker credentials that belonged to vendor developers themselves. This isn't just about downstream customer exposure. If an attacker can exfiltrate a developer's PAT at a security vendor, that token can be used to push code to internal repositories, access private packages, or pivot laterally into any service that token has permission to reach.
Security vendors, by virtue of their customer relationships, often have elevated access to client repositories and infrastructure. A compromised developer credential at the wrong security vendor isn't a contained incident — it's a master key.
The supply chain math here is uncomfortable. Security tooling occupies a privileged position in the software development lifecycle. It has to, to do its job. That privilege, earned and often necessary, is exactly what makes it attractive as an intermediate target.
## HackWire Analysis
The ZeroPath findings arrive at a moment when the security industry is still processing what TeamPCP's Trivy and KICS campaign revealed about trusted tooling. But the industry conversation has mostly focused on the wrong lesson — treating those attacks as aberrations requiring extraordinary attacker capability, rather than indicators of a structural vulnerability class.
What's more significant about the ZeroPath research is how ordinary the attack surface turns out to be. Repository parsing in security scanners involves deep code analysis — executing or emulating code paths, resolving dependencies, unpacking archives, interpreting build systems. Each of those operations is a potential injection point if the scanner doesn't maintain strict isolation between analysis and execution contexts. The irony is that the more thorough a scanner is, the larger the potential attack surface becomes.
There's a pattern worth naming: security tooling has historically been held to lower scrutiny than the products it protects. Scanners are treated as infrastructure rather than as software that needs to be secured itself. Vendors don't typically publish their own security audit results. Customers rarely conduct vendor security assessments on their AppSec providers with the same rigor they'd apply to a database vendor.
The defenders who most need to act on this research aren't just security vendors patching their products. They're engineering teams evaluating which scanning tools they trust with their pipeline, and they need to ask vendors pointed questions: What isolation exists between analyzed code and scanner execution environment? Are there published security assessments of the scanner itself? What credentials does the scanner process have access to, and how are they scoped?
Organizations running self-hosted security scanners face a configuration question right now — confirming those deployments run with minimal necessary privileges and that any credentials the scanner touches aren't shared with production systems.
The Black Hat session will add technical depth, but the structural problem it exposes won't be solved by patching five vendors. It requires the industry to start treating security tooling like any other third-party software with privileged access — which means actually auditing it.
— HackWire Editorial
## Related Coverage