AI Coding Tools Are Now a Primary Attack Target. bomwerk Never Calls One.

Google's Threat Intelligence Group (GTIG) published a report on 8 September warning that AI-assisted coding tools have become a primary target for threat actors, and that this shift has already contributed to several large-scale software supply chain compromises. Worth reading directly if you haven't: the group tracks a financially motivated actor, UNC6780, running credential-stealing malware called Dustmaker across PyPI, npm, and Docker Hub.

Two specific techniques stood out. Dustmaker pulls tokens out of GitHub Actions runner process memory, then uses them to publish compromised package versions that pass the automated trust checks AI coding tools rely on. And separately, it drops malicious files into hidden project workspace directories, the kind AI coding assistants use for their own configuration, specifically so the malware blends into normal developer "noise" instead of standing out.

That second technique is the one worth sitting with. Hidden and vendored directories are already where most inventory tools fall short, not because anyone's hiding anything maliciously, just because a manifest-driven scanner looks for a manifest and finds none there. We've written about that gap before. What's new is that attackers now have a specific, documented reason to put things there on purpose: it's the same blind spot, just weaponized instead of accidental.

Google's own analyst on the report, John Hultquist, put it plainly: at this point, you can assume every threat actor is using AI in some capacity, and their operations have benefited from it.

Where bomwerk sits in this picture

bomwerk doesn't call a cloud AI service to do anything. Identifying components is deterministic and heuristic, built on parsing manifests, reading archive headers, and walking directory structures, not on sending your source to a model somewhere and asking what it thinks is in there. The CLI runs fully on-prem, with an offline mode for exactly the air-gapped environments where that matters most.

To be explicit about the other half of that sentence, because the distinction is the whole point: we do use AI assistance internally, during development, the way most small engineering teams do in 2026. Every line it produces is reviewed before it ships, and the parts that decide what ends up in your SBOM are reviewed twice. That is a statement about how the code gets written. It is a different question from what the shipped binary does on your machine, which is the part that touches your attack surface, and there the answer is simply that bomwerk makes no AI calls at all.

That's not a claim that bomwerk is safer than every cloud-based tool on the market, that's a broader claim than the facts support, and we try not to make those. What's specifically true is narrower and checkable: scanning your codebase with bomwerk doesn't add a new cloud-AI dependency to your attack surface, doesn't send your source to a third party, and isn't the kind of tool the GTIG report is describing. It can't leak your code into someone else's model context, because there's no model in the loop to begin with.

It also doesn't fix the underlying problem the report describes. Nothing about bomwerk stops an attacker from targeting your CI pipeline or your other AI tooling. What it does is give you an honest inventory of what's actually in your repository, including the vendored and hidden-directory code that's exactly where this kind of malware is now designed to hide.

The CRA already asks you to know what you ship. This is one more reason that inventory needs to include the corners a manifest-only scanner skips, because attackers have started checking whether you're looking there too.