How SBOMs and Engineering Discipline Can Help You Avoid Trivy's Compromise

The Regulatory Shift That Changes Everything

Viktor Peterson, founder of sbomify and co-founder of Screenly, describes the EU's Cyber Resilience Act (CRA) as a "GDPR moment" for the software industry. Unlike GDPR's financial penalties, CRA threatens to block non-compliant products from the European market entirely.

Starting this year, the CRA requires companies selling products into Europe to generate SBOMs for anything that connects to the internet. This affects far more businesses than the earlier US Executive Order 4989, which only mandated SBOMs for government vendors.

SBOMs as Operational Tools, Not Just Compliance Checkboxes

Peterson argues that treating SBOMs as mere compliance exercises misses their true value. Companies already use SBOMs operationally for:

• Security audits: Identifying vulnerable components in their codebase
• License compliance: Ensuring no unauthorized licenses like GPLv3 are used
• Vulnerability management: Using VEX (Vulnerability Exploitability eXchange) files to determine if a CVE actually affects their specific usage

"If you can generate an SBOM from a lock file, you can then find CVEs affecting it," Peterson explains. "With VEX, you can say 'yes, I'm affected by the CVE, but we're not using that particular function,' so you can issue a non-impact statement instead of just 'upgrade now' alerts."

The Lock File Foundation

Before generating SBOMs, companies must establish proper lock files. Peterson emphasizes that ecosystems vary dramatically in maturity:

• JavaScript: Move from package.json to lock files generated by modern tools like Bun
• Python: Transition from requirements.txt to UV for better dependency tracking
• General principle: Use ecosystem-specific tools over generic scanners

"The ecosystem-specific tools tend to generate better quality SBOMs than the generic tools," Peterson notes. "Generic tools don't extrapolate all the metadata that various languages can provide."

Pipeline Integration and Trust

SBOM generation must happen in CI/CD pipelines with no human intervention. This ensures:

• Reproducibility: Consistent generation across environments
• Attestation: Digital signatures proving the SBOM hasn't been tampered with
• Audit trails: Ability to trace back to specific releases

Peterson stresses that SBOMs will likely be sent to external platforms, making digital signatures crucial for preventing tampering in transit.

The Transparency Exchange API (TEA)

TEA provides a standardized discovery mechanism for security artifacts. Using a product's barcode or SKU plus the company's domain, consumers can find SBOMs, VEX files, and other security documentation.

"It's not a storage mechanism; it relies on attestation from the source," Peterson explains. "You can discover that a device is using end-of-life software and decide not to buy it."

The Trivy Wake-Up Call

The recent compromise of Trivy, a popular SBOM generation tool, serves as a stark warning. Attackers injected infostealers into two releases, potentially compromising the entire Aqua GitHub organization.

Key lessons from the incident:

• Pin to hashes, not versions: Git tags can be overwritten; hashes cannot
• Use short-lived credentials: Move away from long-lived pipeline credentials
• Adopt OIDC: Implement OpenID Connect for better security

"The moral is move towards OIDC and more short-lived credentials in your pipeline," Peterson advises. "Pin all your GitHub action modules to hashes rather than versions."

Getting Started with SBOMs

Peterson recommends a phased approach:

1. Start with inventory: Audit lock files and ensure proper dependency tracking
2. Build processes: Integrate SBOM generation into CI/CD pipelines
3. Focus on quality: Aim for NTIA minimum element compliance
4. Manage releases: Tag releases that span multiple components for audit trails

"The time to get on top of SBOMs is now," Peterson concludes. "I expect all future compliance frameworks to require SBOMs. It becomes a litmus test of 'do you know what's going into your software?'"

Tool Recommendations

• CycloneDX vs SPDX: Choose one ecosystem and stick with it
• Ecosystem-specific tools: Prefer tools designed for your language over generic scanners
• Quality checks: Use tools like sbomify or sbomqs to verify NTIA compliance
• Release management: Implement systems that track component versions across releases

As Peterson predicts, SBOMs will become first-class citizens in trust centers alongside compliance documents, reshaping how companies demonstrate software security and transparency.