ShinyHunters stole Cisco source code via Trivy supply chain attack - AWS keys breached, 300 repos cloned

A CI/CD pipeline resolved a Trivy container image by tag from a public registry. The image executed. AWS credentials present in the build environment were transmitted to an external endpoint. Approximately 300 Cisco source code repositories were subsequently cloned via those credentials. The pipeline produced no error. The scanner returned output. The build completed.

The trust model encoded in the pipeline treated a registry tag as a stable, content-addressed identifier. The system assumed: the artifact resolved by trivy:latest (or equivalent pinned tag) was the artifact published by the upstream project; namespace membership in the registry was a sufficient provenance signal; and the content of the image did not require re-verification at pull time because it had been verified - or assumed verified - at some prior configuration point. The pipeline distinguished between “artifact exists at this reference” and “artifact is safe to execute” using only the first condition. Tag resolution was treated as identity proof.

The artifact at the registry reference was replaced. The system’s trust evaluation did not re-execute. A registry tag is a mutable pointer. When the pointer was updated to reference a modified image, the pipeline’s trust inherited from the tag’s history - not from the image’s current content. The assumption that a public registry entry would remain unmodified between the time it was trusted and the time it was pulled was never encoded as a verification step. The system operated on reference equality as a proxy for content equality. The proxy was wrong.

The substituted image preserved Trivy’s external interface: it accepted image inputs, executed scans, and returned structured vulnerability output. Concurrently, it executed a secondary payload against the credential store available in the build environment - AWS credentials surfaced as environment variables or mounted secrets in the CI runner. Those credentials were exfiltrated via outbound HTTP before the scan process exited. The pipeline had no mechanism to detect this: the scanner’s stdout contained expected output, the exit code was clean, and no anomalous process was visible to the build log. The system verified what the scanner reported. It did not verify what the scanner did.

The Larger Pattern

Security tooling is granted execution access commensurate with its function. A container scanner runs inside the build environment, adjacent to secrets, source trees, and artifact stores - because that is where it must run to do its job. The same access model that allows the scanner to evaluate images allowed it, once the image was substituted, to exfiltrate everything the pipeline could reach. The scanner was not isolated from the build environment. Its outputs were trusted. Its provenance was not verified at execution time. The access model was unchanged. Only the artifact content was different.

The System Condition

Container registries are mutable by default. Tag references are not content-addressed. Image signing infrastructure exists - Sigstore/Cosign, Notary v2 - but enforcement at pull time requires explicit admission policy that is absent in most CI configurations. The pipeline’s security posture was bounded by its least-verified, most-trusted component. Trivy’s published image digest was not pinned in the pipeline configuration. No signature was verified before execution. The 300-repository exfiltration was not the result of a novel attack primitive - it was the result of a system that verified the objects being scanned while leaving the scanning object unverified. The attack surface was the trust boundary itself.