The most surprising thing about Trivy’s Rekor attestations is that they don’t actually prove anything about your build; they simply record a claim about it.
Let’s watch this happen. Imagine you’ve got a container image, docker.io/myuser/myapp:latest. You want to attest to its build process. First, you’d use Trivy to generate an attestation:
trivy image --format json --output image-attestation.json docker.io/myuser/myapp:latest
This image-attestation.json file contains a structured log of what Trivy observed during its scan. Now, you’ll take this information and upload it to Rekor, the transparency log for the SLSA (Supply-chain Levels for Software Artifacts) framework. This involves signing the attestation and then posting it to Rekor. The exact steps involve using tools like cosign to sign the JSON file and then rekor-cli to upload it.
Once uploaded, Rekor gives you a unique UUID for that entry. This UUID is your pointer to the claim that was made about your image. Anyone can then retrieve this entry from Rekor using the UUID and verify that the signature on the attestation is valid and that the content matches what they expect.
Here’s where the mental model solidifies: Rekor is a blockchain-like ledger. It’s append-only and immutable. When you submit an attestation, you’re essentially writing a tamper-evident log entry. Trivy’s role is to generate the content of that log entry – the "what happened" during the build scan. cosign (or a similar tool) is used to cryptographically sign this content, proving who made the claim. Rekor then makes this signed claim publicly available and immutable.
The problem this solves is the "trust gap" in software supply chains. Before, you might have a build server that claims it built an image, but how could you verify that claim? How could you prove that the image hasn’t been tampered with after the build? Trivy, combined with Rekor, provides a mechanism for creating verifiable, immutable records of build events. You can trust that the attestation was generated by a specific entity (identified by their signing key) and that the content of the attestation (the scan results) hasn’t been altered since it was logged.
The exact levers you control are:
- What Trivy scans: You choose which images, files, or codebases to scan, and what options to use (e.g., vulnerability scanning, misconfiguration checks).
- The signing identity: You control the private key used to sign the attestations, which is critical for verifying the origin of the claim.
- The Rekor entry: You control the act of submitting the signed attestation to Rekor, making the claim public and immutable.
The surprising part for many is that Rekor itself doesn’t validate the accuracy of the claim; it only validates that the claim was made by the claimed entity and hasn’t been tampered with since. If Trivy, for some reason, reported a false positive or missed a vulnerability, that false information would be immutably logged in Rekor. The attestation is a record of what Trivy said, not necessarily an absolute truth about the artifact.
The next step in understanding this is to explore how to integrate these attestations into CI/CD pipelines for automated verification.