Cisco’s Pipeline Handed Valid AWS Credentials to Anyone Who Read the Build Log

A CI/CD pipeline at Cisco executed a Trivy scan job using AWS credentials stored as plaintext environment variables. Those credentials were valid. The IAM permissions attached to them included codecommit:ListRepositories and codecommit:GitPull across AWS CodeCommit. A failed pipeline job emitted those environment variables into its build log. That log was publicly accessible. An external party read the log, extracted the credentials, and issued the same API calls the pipeline issued. Three hundred repositories were cloned, including source for Cisco IOS and the Adaptive Security Appliance. The credential was not rotated. The pipeline continued running. No alert fired.

The trust model assumed that credential validity was bounded by the execution context in which the credential was provisioned. A key generated for a CI/CD pipeline was, in that model, a pipeline key: it operated during pipeline jobs, from pipeline infrastructure, and its reach was constrained by where pipelines run. The system treated execution context as an access control - the credential was safe because of where it lived, not because of what it was permitted to do or how its exposure was monitored. Trust was assigned at provisioning and was not re-evaluated against the credential’s actual exposure surface.

A failed pipeline job emitted its environment variable state into a publicly accessible build log. The credential was now readable by any unauthenticated party with access to the CI platform’s public job output. That state change occurred before any external party acted on it. The system did not detect it. The credential remained marked valid. The execution context that was supposed to bound its exposure no longer existed as a boundary. Trust was not re-evaluated. It was inherited from the provisioning state.

The AWS API received authenticated requests bearing valid credentials with codecommit:ListRepositories and codecommit:GitPull permissions. It returned the expected responses. The authentication model does not encode request origin - it encodes identity. The CI/CD pipeline’s legitimate use of those credentials established the request pattern. The external party reproduced that pattern exactly. The API executed it identically both times. The SIEM logged no alerts because the API calls matched the expected signature of legitimate build operations - because they were legitimate build operations, structurally. No bypass occurred. No anomaly was introduced. The credential did what a credential with those permissions does when presented to the API.

A system that grants access based on credential identity rather than credential integrity will execute any request that presents valid credentials, regardless of how those credentials arrived at the requester. Trust lives in the token, not in the channel. When the token escapes its intended channel, the trust travels with it. The pattern: trust encoded in a transferable artifact does not expire when the artifact transfers.

Consequence

The repositories contained implementation-level detail for authentication and firmware validation logic in Cisco IOS and ASA. That material was available on ShinyHunters’ leak site within approximately 48 hours of exfiltration. The credential remained active for the duration of the incident. The detection gap ran to roughly fourteen days per available incident reporting. The pipeline continued executing scheduled jobs throughout. Nothing in the system’s instrumentation was positioned to distinguish the external party’s requests from the pipeline’s - because the requests were identical.