# The Trivy Compromise: What Pinning, Isolation, and Evidence Each Do

Source: https://www.testifysec.com/blog/cilock-action-supply-chain-attacks/

Author: TestifySec

Published: 2026-03-21

Updated: 2026-10-06

A review of the March 2026 incident and the distinct roles of prevention, observation, and policy verification.

Editorial update · October 6, 2026

Revised by TestifySec Editorial to remove unsupported outcome claims and explain the current product and trust boundaries. The original publication date and URL are preserved.

- [Current TestifySec docs →](https://www.testifysec.com/docs)
- [Trust architecture →](https://www.testifysec.com/docs/cilock/trust)

The Trivy incident showed why a familiar action name and a version tag are not enough to establish trust. Aqua’s [maintainer advisory](https://github.com/aquasecurity/trivy/security/advisories/GHSA-69fq-xp46-6x23) reports compromised releases and malicious GitHub Action tags in March 2026. Its updated count is 76 of 77 trivy-action tags, correcting the earlier figure in this article.

 

Use the advisory and the [maintainer’s incident conclusion](https://github.com/aquasecurity/trivy/discussions/10462) for affected versions, exposure windows, and remediation. This article focuses on the architectural lesson.

 

## Pinning controls which content is selected

 

Pinning a reviewed action to an immutable commit prevents a later tag move from silently selecting another commit. It does not establish that the pinned code, its downloaded dependencies, or the runner is safe. Updates still require review.

 

An approved-source policy is useful only if it is evaluated before the untrusted code runs. Evaluating a statement about the action after execution cannot retroactively prevent that execution.

 

## Isolation limits what the code can reach

 

Do not give an untrusted test job production credentials or policy-administration authority. Separate execution from privileged promotion and review the artifacts that cross that boundary. Short-lived credentials still need limited scope and protected issuance.

 

## Content inspection and tracing have different limits

 

A secret scanner can detect supported credential patterns in the content it examines. It is not a general malware detector. Encoded content is covered only to the extent the selected decoder and scan configuration support it.

 

A trace can record supported process, file, or network observations within the capture boundary. Policy can evaluate those observations, but coverage depends on the platform, backend, permissions, and release. A trace does not prove that nothing happened outside that boundary.

 

## What the original experiment demonstrated

 

The earlier article linked a [TestifySec reproduction repository](https://github.com/testifysec/cilock-trivy-detection-test) with illustrative credential-output and file-access scenarios. Those scenarios are distinct from replaying every part of the real incident. They are also not a current-release acceptance test or a general detection-rate benchmark.

 

The historical Rego and CLI snippets are now deferred to the maintained documentation. In particular, March-era tracing limitations must not be treated as a description of every later CI/lock release.

 

## Verification needs a decision point

 

CI/lock captures the work and its configured evidence. A verifier checks the expected producer, artifact binding, required results, and policy. The system blocks a release or push only when that verification is wired into the relevant enforced gate.

 

Post-execution rejection cannot undo credential theft that already happened. Keep preventive isolation, least privilege, and incident response separate from the evidence used to evaluate a later decision.

 

## Evaluate the workflow you will deploy

 

Start with the [CI/lock support matrix](https://www.testifysec.com/docs/concepts/support-matrix) and [trust model](https://www.testifysec.com/docs/cilock/trust). Test a clean workload, a known failing condition, missing evidence, and a mismatched artifact. Record the exact release and execution environment with the results.

 

For repository acceptance, read the [Pushgate architecture](https://www.testifysec.com/docs/pushgate/trust-architecture). The platform manages multiple gates, but each still needs an explicit policy and trust boundary.