SBOM Requirements Hit in 2027: What to Build Now

You've got three years before the Cyber Resilience Act makes Software Bills of Materials (SBOMs) mandatory in Europe. That deadline is at the end of 2027, and if you're selling software into EU markets, you'll need a working SBOM generation process, not a last-minute vendor pitch deck.

The US moved first. The Biden Administration's May 2022 cybersecurity executive order required SBOMs for federal software contracts. If you ignored that because you don't sell to the government, you won't have that luxury with the EU regulation.

Scope

This guide covers what you need to build an SBOM capability that'll satisfy regulatory requirements and improve your security posture. It's written for teams that need to ship compliant software, not research papers on supply chain theory.

What's in scope:

• SBOM format specifications and tooling requirements
• Integration points in your build pipeline
• Vulnerability correlation workflows
• Compliance documentation chains

What's not:

• Vendor selection criteria (your stack determines this)
• SBOM consumption for third-party software (that's procurement's problem)
• Attestation frameworks like SLSA (separate implementation)

Core Concepts

Software Bill of Materials (SBOM): A machine-readable inventory of every component in your software artifact. Think package.json or requirements.txt, but comprehensive and standardized.

Component: Any discrete unit of software. This includes direct dependencies, transitive dependencies, container base images, compiled binaries, and JavaScript libraries loaded at runtime.

Pedigree: The chain of custody for a component. It shows where it came from, who built it, and what modified it. This is critical for supply chain attacks like SolarWinds, where malicious code entered through a compromised build process.

Vulnerability correlation: Matching your SBOM against known vulnerability databases (NVD, GitHub Security Advisories, OSV) to identify exposure. This is why SBOMs matter more than inventory spreadsheets.

Two formats dominate:

• SPDX (Software Package Data Exchange): ISO/IEC 5962:2021 standard, comprehensive but verbose
• CycloneDX: OWASP project, lighter weight, better for continuous integration

Pick one. Most tooling supports both, but you'll waste time converting between them.

Requirements Breakdown

Minimum Viable SBOM

Your SBOM must identify:

1. Component name and version
2. Supplier (publisher/maintainer)
3. Unique identifier (Package URL or CPE)
4. Dependency relationships (what requires what)
5. Timestamp of SBOM generation

Without these five elements, you can't correlate vulnerabilities or prove compliance.

Enhanced Requirements

Add these for operational value:

• License information (SPDX license identifiers)
• Component hashes (SHA-256 minimum)
• Build environment details
• Known vulnerabilities at build time
• Signature/attestation (SBOM integrity)

Regulatory Alignment

Federal contracts (US): Follow NTIA Minimum Elements for an SBOM. The National Telecommunications and Information Administration published these in 2021. Seven baseline fields, three operational contexts.

Cyber Resilience Act (EU): Final technical requirements aren't published yet, but expect SPDX 2.3 or CycloneDX 1.5 as acceptable formats. The act covers products with digital elements, which means firmware, embedded systems, and SaaS.

PCI DSS: Requirement 6.3.2 mandates inventory of bespoke and custom software. An SBOM satisfies this if you're tracking components in payment applications.

Implementation Guidance

Pipeline Integration

Generate SBOMs at build time, not as an audit activity. Your CI/CD pipeline should produce an SBOM artifact alongside your container image or binary.

For container images:

docker build → Syft/Trivy scan → SBOM generation → image push + SBOM storage

For application builds:

dependency resolution → build → SBOM generation → artifact signing → deployment

Store SBOMs with the same retention policy as your artifacts. If you keep container images for 90 days, keep their SBOMs for 90 days.

Tool Selection by Ecosystem

JavaScript/Node.js: CycloneDX NPM plugin, Syft
Python: CycloneDX Python library, pip-audit with SBOM output
Java/Maven: CycloneDX Maven plugin
Go: Syft, go-sbom
Containers: Syft, Trivy, Anchore

Don't build your own SBOM generator. The format specifications are complex, and you'll miss transitive dependencies.

Vulnerability Workflows

An SBOM without vulnerability correlation is just expensive documentation. You need:

1. Continuous monitoring: Feed SBOMs into a vulnerability scanner that polls databases daily
2. Alert routing: Critical vulnerabilities in production SBOMs go to on-call, everything else to backlog
3. Remediation tracking: Link SBOM vulnerabilities to tickets/PRs so you can prove closure

When Log4j dropped, teams with SBOMs identified affected services in hours. Teams without SBOMs spent weeks searching codebases and guessing.

Common Pitfalls

Generating SBOMs post-deployment: You've lost the build context. Transitive dependencies get missed, versions get fuzzy.

Ignoring runtime dependencies: Your SBOM shows what you compiled, but your application loads plugins, fetches libraries, or uses system binaries. Document these or accept blind spots.

Treating SBOMs as point-in-time: Components don't change, but vulnerability data does. A clean SBOM today might show critical issues tomorrow.

No SBOM distribution plan: Customers will ask for SBOMs (especially after 2027). You need a secure delivery mechanism, not email attachments.

Skipping transitive dependencies: Your direct dependencies pull in dozens of libraries. Those matter just as much. If your tool only captures top-level dependencies, it's not producing a real SBOM.

Quick Reference

Requirement	Tool/Format	Frequency	Owner
SBOM generation	Syft, CycloneDX plugins	Every build	Platform/DevOps
Format compliance	SPDX 2.3 or CycloneDX 1.5	N/A	Security architecture
Vulnerability scanning	Grype, Trivy, Dependency-Track	Daily	Security operations
Storage/retrieval	Artifact repository (Artifactory, Harbor)	Per retention policy	Platform/DevOps
Customer delivery	Secure portal or signed artifacts	On request	Customer success
Compliance documentation	SBOM + scan results + remediation log	Per audit cycle	Compliance team

What to Do This Quarter

Start with one application. Pick something you deploy frequently, with a modern build pipeline.

1. Add SBOM generation to the build (one day)
2. Store SBOMs in your artifact repository (half day)
3. Set up vulnerability correlation (two days for tool config)
4. Document the process for your compliance team (one day)

That's a week of engineering time to build the foundation. Scale it to other applications once you've validated the workflow.

You don't need perfect SBOMs in 2025. You need working SBOM generation that you can refine over the next three years. The teams that wait until 2027 will be paying consultants $300/hour to retrofit their entire software catalog under deadline pressure.