ShinyHunters exfiltrated Cisco source through Trivy

Opening position

Cisco source code was exfiltrated. ShinyHunters is named as the actor. The attack path runs through Trivy, a vulnerability scanning tool. AWS keys were breached. 300 repositories were cloned. Everything else is not confirmed.

The scanner became the carrier. A control deployed to identify vulnerable components was the component that enabled access. This is not a story about a tool failing to do its job. It is a story about a tool doing exactly what it was permitted to do, inside an environment that granted it more trust than the data it was protecting.

Treat the rest of this writeup the same way the facts demand. Where the input is silent, the answer is not confirmed. Dwell time is not confirmed. Initial access vector into the Trivy supply chain is not confirmed. The number of distinct AWS keys, their privilege scope, and their lifetime is not confirmed. Whether the 300 cloned repositories are a subset of, equal to, or distinct from the source code described as stolen is not confirmed. Customer downstream impact is not confirmed. The operator position holds regardless.

What actually failed

A security tool with execution access inside Cisco infrastructure was the path through which source code left the environment. That is the observable failure. Trivy ran. The runtime context Trivy operated in had reachability to source repositories and to AWS credentials. The actor obtained both. The mechanism that allowed Trivy to execute is the mechanism that allowed the exfiltration.

AWS keys were breached. The presence of keys in a context reachable by a scanning tool is the second observable failure. Whether the keys were embedded in CI/CD configuration, exported as environment variables to the scanner runtime, or retrieved from an instance role attached to the executor is not confirmed. What is confirmed is that the credential boundary did not hold against a workload that should not have required production credential access to perform its stated function.

300 repositories were cloned. The clone operation requires read access at the repository scope. Either the credentials Trivy operated under carried that scope by design, or the actor used credentials harvested in an earlier step of the same chain to broaden access. The input does not state which. What it does state is that read access to 300 repositories was reachable from a single compromised execution context. That is the third observable failure: a single workload identity with line of sight to a 300-repository blast radius.

Why it failed

Trust was placed in the tool, not validated against the workload. A scanner is software. It executes. It reads. It transmits. The decision to run a third-party binary inside a context that holds source code and cloud credentials is a decision to extend the trust boundary of that context to whoever controls the binary’s supply chain. Cisco extended that trust. ShinyHunters operated inside it. That is the design condition that made the outcome possible.

The identity boundary did not separate the scanner’s operational need from the assets in its reach. A vulnerability scanner needs to read package manifests and image layers. It does not need cloud administrative keys, and it does not need clone permissions across hundreds of repositories. The fact that both were obtainable from the same execution context means the identity attached to that context was overscoped relative to the function being performed. Whether this was a CI service principal, an instance role, or a developer-owned token is not confirmed. The overscope is implied by the outcome.

Supply chain validation, if present, did not stop the modified Trivy distribution from running with full trust. The presence or absence of binary verification, signature pinning, or pipeline integrity checks is not confirmed. What is confirmed is that whichever controls existed did not interrupt execution. Controls that do not interrupt the behaviour they exist to interrupt are ineffective. The control posture, as observed through the outcome, treated Trivy as a trusted internal component when its provenance was external. That distinction is the failure.

Mechanism of failure

The mechanism is trust inheritance. A scanner is granted execution inside a runtime. The runtime carries an identity. The identity holds credentials and read scope. The scanner inherits all of it the moment it is invoked. There is no separation between what the tool needs to perform its function and what the tool can reach. The supply chain that produces the scanner becomes the effective perimeter of every system that runs it. ShinyHunters did not break Cisco’s perimeter. ShinyHunters operated inside the perimeter Cisco extended to whoever controlled Trivy’s distribution.

This is not a defect in the scanner. It is the structural property of running third-party code with privileged workload identity. Every component placed in a CI/CD path with execution rights becomes a credential consumer at runtime, regardless of whether the component was designed to handle credentials. Trivy is built to read package manifests. The runtime it operated in handed it everything else by default. AWS keys were reachable. Repository read scope was reachable. The tool did not need either to do its job. The environment did not enforce that distinction. The actor enforced it, in reverse, by taking what was reachable.

The drift is slower and harder to see than the breach itself. Scanners accumulate in pipelines over time. Each new tool is added with the assumption that the previous tools were safe to add. The blast radius of any single compromised upstream maintainer grows with each addition. The control surface moves from systems the organisation operates to systems the organisation depends on but does not audit at execution time. By the point of compromise, the perimeter has already been delegated. The breach is the moment the delegation becomes visible. Until then, it looks like tooling.

Expansion into parallel pattern

The same mechanism applies to every tool granted execution inside a credential-bearing context. Linters. Formatters. Dependency resolvers. Infrastructure-as-code scanners. Observability agents. Language servers running in CI. Pre-commit hooks pulled from public registries. Each one is third-party code executing with the workload’s identity. Each one inherits the same trust the runtime carries. The Trivy case is a single instance of a structural class. The class has been demonstrated repeatedly across the industry, and the lesson does not transfer.

The Codecov bash uploader compromise in 2021 used the identical mechanism. A CI tool with environment variable access. Modified upstream. Credentials harvested across every customer running it. SolarWinds Orion used the same mechanism on a longer timescale. Signed binary. Trusted agent. Full reachability into the network it observed. 3CX, the MOVEit-adjacent upstream chain, the npm and PyPI package incidents that surface monthly. The vector changes. The mechanism does not. Execution rights plus credential reachability equals identity transfer the moment the supply chain is compromised.

The pattern holds because the design choice holds. Organisations grant execution to tools in order to operate at the speed of automation. The same automation that scales control scales failure. A scanner that runs across 300 repositories on every commit is also a single point of access to 300 repositories on every commit. The ratio of one workload identity to a 300-repository blast radius is not a Trivy property. It is a property of any tool placed at that point in the pipeline. The next compromise will use a different binary, a different maintainer, a different package. The reachability profile will look the same.

Hard closing truth

A control that runs with the same identity as the assets it inspects is not a control. It is a co-resident process with the same access rights as everything around it. The label changes nothing. If the binary is compromised, the control becomes the threat actor’s tooling, executing with the trust the organisation chose to grant. The word “scanner” describes the intent. The runtime describes the capability. The actor uses the capability.

Identity is the boundary. When a single execution context can reach source code, AWS credentials, and clone scope across 300 repositories, the boundary has already collapsed before any external actor arrives. The collapse is not caused by the breach. The breach reveals it. The design condition that produced the outcome existed every day the pipeline ran without incident. Absence of compromise is not evidence of containment. It is evidence that the containment had not yet been tested.

The operator position is unchanged by the specifics of this incident. Trust placed in a third-party binary is trust extended to that binary’s supply chain, in full, at the privilege level of the runtime that executes it. There is no version of this in which the scanner is trusted and the supply chain behind it is not. The two are the same surface. Cisco’s source code did not leave through a sophisticated zero-day. It left through a tool that was given permission to be there. Everything else in this writeup is detail. That sentence is the breach.

See also: NordVPN for tunneled traffic when operating outside controlled networks.

---

#ad Contains an affiliate link.