The worm's target list is a better secrets inventory than your audit

On August 7, GitGuardian published a useful piece of attacker accounting. Its researchers deobfuscated a Mini Shai-Hulud variant and found that the malware's filesystem collector had grown from 189 hardcoded secret locations to 469 across Linux, Windows and macOS. The additions covered configuration used by AI agents, CI/CD systems, cloud tools and cryptocurrency wallets. On Linux, the variant also began enumerating files across users when it had elevated privileges, rather than stopping at the current user's home directory.

That is not a census of every credential in an enterprise, and I did not execute the malware or reproduce GitGuardian's analysis. It is still a sharper prompt than most secrets audits: can our controls see the places an attacker has already decided are worth searching?

The practical move is to turn the attacker's categories into safe regression tests for your credential inventory. If a synthetic, non-working token placed in a representative local configuration directory survives your scanner, ownership route and cleanup workflow, the audit has proved the policy—not the coverage.

Your inventory lists approved storage

Secrets programs naturally start with sanctioned systems: the vault, repository scanner, CI variables and cloud secret manager. The worm starts with developer state. It looks where tools leave reusable authority while doing ordinary work: local configuration, shell state, package-manager settings, IDE data and the newer directories created by AI coding assistants and agent harnesses.

The earlier AndyMental question was what a poisoned package could steal from an agent environment. This incident adds a harder follow-up: can the security program demonstrate that it would find those copies before an installer does?

I initially went looking for a downloadable 469-row checklist. GitGuardian's public post does not provide one; it reports the count, operating-system split and added product categories. That correction improved the method. A copied path list would become another frozen compliance artefact, and 469 locations in one sample are not 469 universal controls. Steal the adversary's habit of updating the map, not the payload.

Make secret-surface coverage a release test

Build a disposable workstation profile for each operating system and runner image you support, then make the audit executable:

• Inventory the credential-bearing surfaces your developers actually use, including local AI-tool configuration, IDE and CLI state, package managers, CI tooling and cloud clients. Record the owner, credential type, privilege, expected lifetime and approved storage mechanism for each surface.
• Place detector-safe, non-working canary values in representative locations. Run the real endpoint, repository and CI scanners, then verify alert routing and cleanup—not merely pattern matching.
• Track two results separately: surface coverage, or which seeded locations were found, and authority risk, or which real credentials remain valid, privileged and reusable. A clean scan is not proof that no credential exists.
• Remove standing secrets where the workflow supports identity-backed, short-lived credentials. npm's trusted publishing uses OIDC so a release workflow does not need a long-lived publish token waiting on disk.
• Rerun the suite when a developer image, agent, IDE extension or build tool is added. The control should change at software cadence, not annual-audit cadence.

Do this in an isolated test profile with fake values. Do not run the malware, import its code or reproduce its exfiltration behavior. The useful artifact is a coverage fixture your defenders own.

The adjacent video shows the automation multiplier

The finished August 22 short below covers a sibling failure mode in the LiteLLM supply-chain incident: a short exposure window can still spread through automated installs. I checked the 30.04-second local render, its narration and sampled frames on September 11. It is context for why credential coverage has to run continuously, not evidence for GitGuardian's 469-location finding.

The count will change. The product names will change faster. That is exactly why this cannot end as an incident-response checklist. Each new tool that can authenticate creates another place where authority may settle, and every place your audit cannot test is a place it cannot honestly claim to cover.

If the worm adds your newest AI tool before your secrets scanner does, the security program is auditing policy while the attacker audits reality.