A CI/CD pipeline executed a post-scan hook under full environment permissions and exfiltrated AWS credentials from version control history. The scanner completed successfully.

Trivy scanned a container image. A post-scan hook executed. The hook ran with full access to environment variables and repository history. AWS credentials committed to version control five months prior — never purged, still valid — were in scope. Approximately 300 repositories were cloned. No pipeline component flagged the operation as anomalous. The scan result was clean.

The Original Assumption

The pipeline was built on a trust inheritance model. Trivy was classified as an inspection tool: read-only, open-source, externally auditable. That classification was assigned at the point of integration and never re-evaluated. Post-scan execution — hooks that triggered on scan completion — was treated as an extension of the scanner’s context. The credential state of the repository was assumed to be isolated from the execution environment: present in history, unreachable without explicit extraction logic. No mechanism in the pipeline encoded this isolation as a constraint.

What Changed

A post-scan execution hook was added to the pipeline after the initial trust boundary was established. The hook ran under the same permission scope as the scanner. The assumption that scan completion constitutes a bounded, read-only trust state became invalid the moment an execution context was appended to it — but the pipeline’s trust model was not updated. The AWS credentials remained valid. The repository history remained accessible. The pipeline inherited its prior trust state and applied it to a materially different execution context without re-evaluation.

Mechanism of Failure

Scan completion was used as a reference signal, not a validation boundary. When Trivy returned a result, the post-scan hook executed without privilege separation, output validation, or secret isolation. The hook’s execution context had full access to environment variables and to the repository, including its commit history. Credentials stored in plaintext in git history — reachable via standard repository access from within the hook — were exfiltrated via AWS API calls authenticated against those keys.

The failure is not attacker-injected code in Trivy. The failure is the pipeline’s encoding of an equivalence that does not hold: Trivy’s trust classification was extended to an execution context with a different privilege profile. Reference replaced validation. “Trivy completed” substituted for “this execution context is constrained to read-only, secret-isolated operations.”

Operational Consequence

The AWS credentials provided sufficient permissions to enumerate repositories and clone at scale. 300 repositories were extracted. The exfiltration was not out-of-bounds from the pipeline’s perspective — it matched the permissions the system had explicitly granted to the post-scan execution context. No threshold was crossed that the pipeline was instrumented to detect.

Structural Property

Post-scan execution hooks are a standard pattern in CI/CD architectures — present in GitHub Actions workflows triggered on vulnerability findings, Jenkins pipelines executing remediation or notification scripts, and container build chains that invoke downstream processes based on scanner output. The structural property is consistent across implementations: the scanner’s trust classification is inherited by whatever executes after it, without that inheritance being explicitly validated or constrained.

This is not a Trivy-specific property. Any tool embedded in a pipeline as an execution trigger — regardless of its own security posture — can serve as the trust anchor for a downstream execution context with broader permissions. The attack surface is the gap between the tool’s classification and the hook’s actual privilege scope.

What the Pipeline Architecture Encodes

No scanner output is a trust boundary. Scanner completion is a state signal — it indicates that a defined operation finished. It does not constrain what executes next, under what permissions, or with access to what state. Post-scan execution requires privilege scoping defined independently of the scanner’s classification. Credentials present in version control — regardless of age, apparent inaccessibility, or prior classification as inactive — remain in scope for any process with repository read access.

The pipeline that exfiltrated these credentials was functioning as designed. The design encoded the wrong trust model.