Generating an SBOM for your project can reveal surprising details about the transitive dependencies you’ve inherited.
Let’s see Trivy in action. Imagine you have a simple Go application.
package main
import (
"fmt"
"net/http"
)
func main() {
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "Hello, world!")
})
http.ListenAndServe(":8080", nil)
}
To generate an SBOM for this, you’d first need to build it, then run Trivy.
go build -o myapp main.go
trivy sbom --scanners vuln,secret,config,sbom --format cyclonedx --output sbom.json ./myapp
This command tells Trivy to scan the myapp executable. It enables vulnerability, secret, configuration, and SBOM scanners. The output format is CycloneDX JSON, and it will be saved to sbom.json.
The resulting sbom.json file will contain a detailed inventory of the application’s components. For a Go binary, this includes not just your direct dependencies but also their dependencies, recursively. You’ll see entries for the Go standard library packages, any external Go modules you’ve imported, and potentially even lower-level system libraries that the Go runtime depends on. Each entry will have a unique identifier, like a Package URL (PURL) or a Common Platform Enumeration (CPE), along with version information.
This SBOM serves as a foundational artifact for supply chain security. It answers the question: "What exactly is in my software?" This visibility is crucial for understanding your attack surface. If a vulnerability is discovered in a specific version of, say, golang.org/x/crypto, your SBOM will immediately tell you if your application is affected.
Beyond just listing components, Trivy can also integrate with attestation. Attestation is a cryptographically signed statement about a build or a component. When Trivy generates an SBOM, it can also generate an attestation that proves the SBOM was generated by a trusted tool (Trivy itself) at a specific time, for a specific artifact. This adds a layer of verifiability to your SBOM.
Here’s how you might generate an SBOM and an attestation using Trivy, often integrated into a CI/CD pipeline:
# Assuming your Go app is built and available as ./myapp
# This command generates the SBOM and signs it as an in-toto attestation
trivy sbom --scanners vuln,secret,config,sbom --format cyclonedx --output sbom.json --attach-sbom-to cyclonedx .
The --attach-sbom-to cyclonedx flag is key here. It instructs Trivy to generate an SBOM (in CycloneDX format, as specified by --format cyclonedx) and then create a separate in-toto attestation file that includes this SBOM. This attestation is signed, providing a verifiable record. The output will typically be a .intoto.jsonl file containing the attestation.
This attestation proves that an SBOM was generated for your application. When you later fetch this application, you can verify the attestation to ensure the SBOM hasn’t been tampered with and was indeed produced by a trusted source. This is critical for demonstrating compliance and for security audits. The attestation will contain metadata about the build environment, the source code (if available), and the generated SBOM itself, all bundled together and cryptographically secured.
The true power of this combination lies in its integration into a secure software supply chain. Instead of just having an SBOM lying around, the attestation embeds it within a verifiable, signed artifact. This means you can trust that the SBOM you are examining is the actual SBOM generated during the build process, not one that was retroactively modified. This is particularly important when using tools like SLSA (Supply-chain Levels for Software Artifacts) or other policy enforcement mechanisms that rely on verifiable provenance.
When you query an artifact for its security posture, you’re not just looking at the artifact itself. You’re looking for associated attestations. These attestations act as a chain of custody, proving that the artifact was built correctly, scanned, and that its security properties (like the SBOM) are trustworthy.
The next step in securing your supply chain involves integrating these attestations into your deployment pipeline, ensuring that only software with valid, trusted attestations can be deployed.