How do you use Trivy to generate and validate SBOMs (Software Bill of Materials)?

Think of an SBOM as the ingredient list on a food product. Just as a consumer with a peanut allergy needs to know every ingredient in a packaged meal, an organization needs to know every software component in a deployed container to assess risk when a new vulnerability is announced. When a critical CVE drops affecting a specific version of OpenSSL, having SBOMs for every service lets you instantly identify which of your 200 microservices are affected, rather than re-scanning every image from scratch.

A Software Bill of Materials is a machine-readable inventory of all components that make up a software artifact. Trivy generates SBOMs by analyzing container images, filesystem directories, and code repositories to enumerate every OS package, application library, and transitive dependency along with their exact versions, licenses, and supplier information. Trivy supports the two industry-standard SBOM formats: CycloneDX, which is an OWASP project focusing on security and software supply chain use cases, and SPDX, which is a Linux Foundation project emphasizing license compliance. For the payments-api image, running trivy image --format cyclonedx produces a JSON document listing every component from the base Alpine packages like musl and busybox to application dependencies like express and jsonwebtoken, including their PURL (Package URL) identifiers that enable cross-referencing with vulnerability databases.

The SBOM generation process works by leveraging the same scanning engine that powers vulnerability detection. Trivy decomposes the image into layers, identifies package managers and their metadata sources, and extracts the complete dependency tree. For OS packages, it reads the distribution package database such as dpkg status for Debian or apk installed for Alpine. For application dependencies, it parses lockfiles including package-lock.json for Node.js, go.sum for Go, Gemfile.lock for Ruby, and requirements.txt or poetry.lock for Python. The resulting SBOM includes component type classification, version strings, hash digests for integrity verification, and license identifiers using SPDX license expression syntax. Trivy can also generate SBOMs for filesystem directories using trivy fs --format spdx-json, which is useful for scanning source code repositories before containerization.

The real power of SBOMs emerges when they are stored and rescanned over time. Instead of pulling and analyzing every container image when a new critical vulnerability is announced, teams can rescan previously generated SBOMs using trivy sbom, which takes a CycloneDX or SPDX file as input and checks all listed components against the latest vulnerability database. For an organization running 50 microservices including order-processing-service, user-auth-service, and inventory-sync, storing SBOMs in a central repository like Dependency-Track allows the security team to immediately query which services contain the affected component when a zero-day drops. This SBOM-first approach reduces incident response time from hours of re-scanning to seconds of database queries. Executive Order 14028 on Improving the Nation's Cybersecurity mandates SBOM generation for software sold to the US government, making this capability a regulatory requirement for many organizations.

A key gotcha is SBOM completeness versus accuracy. Trivy generates SBOMs based on what it can detect through package managers and lockfiles, but it cannot identify statically compiled binaries, vendored dependencies copied without a manifest, or custom-built shared libraries. If the checkout-service includes a statically linked C library that was compiled from source in a multi-stage build, that component will be absent from the SBOM. Teams should supplement Trivy-generated SBOMs with build system metadata and provenance attestations to fill these gaps. Another trap is assuming that an SBOM generated at build time remains accurate indefinitely. If the base image uses floating tags like alpine:3.19 and the tag is updated with security patches, the stored SBOM no longer reflects the running container. Always generate SBOMs against specific image digests and regenerate them when images are rebuilt. Finally, be aware that SBOM rescanning with trivy sbom does not detect misconfigurations or secrets, only component vulnerabilities, so it complements but does not replace full image scanning.