Software Bills of Materials (SBOMs) have become a key part of software supply chain security. But producing an inventory is only the beginning. How do organizations make sure it is accurate, up to date, secure, and useful when a vulnerability emerges?
ENISA’s Technical Advisory for Software Bill of Materials, published October 22, 2026, offers practical answers. The guidance is intended particularly for organizations beginning their SBOM programs, but its recommendations apply across software development environments.
Here are six recommendations worth paying attention to—and what they mean in practice.
1. Start with Build-Time SBOM Generation
ENISA recommends beginning with build-time integration as the foundation of an SBOM program. Its reasoning is straightforward: dependencies are most accurately known when software is being built. Teams can use existing CI infrastructure to generate an SBOM after compilation while build context is still available.
Context is important for SBOM accuracy, compliance, and vulnerability management. A repository may contain libraries that never appear in a particular release, while statically linked or build-specific dependencies may be difficult to identify afterward. Build-time generation helps tie the inventory to the software actually produced.
This is the approach behind RunSafe Identify, RunSafe’s SBOM generator that captures components and dependencies during the build process. The benefits apply across development environments and are especially valuable in complex C/C++ and embedded projects where package manifests often provide an incomplete picture.
2. Use Standard Formats and Consistent Component Data
ENISA discusses machine-readable formats such as CycloneDX and SPDX, along with the metadata needed to identify components and their relationships. Names and versions are essential, but supplier information, identifiers, hashes, licenses, and dependency relationships can make an SBOM considerably more useful.
Ideally, choose a widely supported format and define which data fields your organization needs. An SBOM that cannot reliably identify a component will struggle to support vulnerability matching, supplier communication, or compliance reporting.
3. Validate SBOMs and Document What’s Missing
Generating a file does not guarantee a reliable inventory. ENISA calls for validation checkpoints before publication, including checks for format compliance, license compatibility, and signatures where applicable.
It also recommends documenting known coverage gaps and “known unknowns,” such as dependencies that cannot be identified or third-party components with incomplete supplier information. Knowing where your SBOM is incomplete is more useful than assuming it is complete.
4. Automate Generation and Preserve Release History
An SBOM can become outdated as soon as the software changes. ENISA recommends integrating generation into CI/CD workflows, defining triggers such as commits or releases, and storing SBOMs alongside associated build artifacts.
Keeping historical records is just as important. When a new CVE is disclosed, teams need to determine which versions of a product contain the affected component—including software already deployed in the field. Release-linked SBOMs make that investigation far more manageable.
5. Secure the Entire SBOM Lifecycle
An SBOM can reveal sensitive information about software components and dependencies, and the systems producing it can also be attacked. ENISA considers threats to generators, validation services, repositories, and consumption pipelines—not just to the SBOM document.
Its recommended controls include least-privilege access, multi-factor authentication, audit logging, tool integrity checks, verifiable provenance, and tamper-evident storage. Organizations should protect SBOMs as part of their software supply chain, rather than treating them as ordinary exported files.
6. Turn SBOM Data Into Risk-Based Vulnerability Decisions
Finding a vulnerable component does not automatically mean every affected product faces the same level of risk. ENISA recommends combining SBOM data with vulnerability information, Vulnerability Exploitability eXchange (VEX), reachability, exposure, and product criticality to guide remediation.
This helps teams distinguish vulnerabilities that require urgent attention from those that are not applicable or can be addressed through a planned remediation path. ENISA also calls for defined timelines, severity thresholds, and escalation procedures. The goal is to make the inventory useful when decisions need to be made and not simply to produce it for an audit.
The Bigger Takeaway: An SBOM Is a Process, Not Just a Document
ENISA’s advisory is guidance, not a new set of legal obligations under the EU Cyber Resilience Act. Its message is practical: generate accurate inventories, maintain them as software changes, protect their integrity, and connect them to vulnerability response.
For organizations evaluating their current approach, a useful question is whether an SBOM can quickly answer three things: What is in this release? Which products are affected by a new vulnerability? And what action should we take?
Read the full ENISA Technical Advisory for Software Bill of Materials for the complete implementation and security recommendations.
Want a deeper look at build-time SBOM generation? Read our blog, or take a more technical dive into RunSafe’s white paper, RunSafe Identify: Build-Time SBOM Generation and Vulnerability Management.
