SBOM and dependency management
Create transparency about components – and make controllable decisions from them.
A Software Bill of Materials (SBOM) is a machine-readable record of software components and their relationships. It creates transparency, but not automatic security: only reliable generation, sufficient data quality, comparison with vulnerability information and regulated responsibilities make it usable. SBOM and dependency management therefore belong in build, release and operational processes - not just in one-off delivery documentation.
Background
Custom applications contain direct and transitive open source, third-party, and internal components. Without a reliable overview, questions about affected products in the event of a new vulnerability remain manual, slow and error-prone. At the same time, inventories are often created outside of the build, are not assigned to a specific release version, or contain unclear names and versions.
Technical context
An SBOM documents components of a specific software artifact as well as their supply chain relationships. It is not a vulnerability scan, not a proof of origin and not a release decision. CISA classifies SBOMs as a building block of supply chain security; SPDX and CycloneDX officially publish their specifications. Which format is suitable depends on the recipients, tool chain and use case; What is crucial is unique identifiers, versions, relationships and timeliness.
Within its scope, the CRA requires the identification and documentation of components including an SBOM. This does not result in a general signing requirement or a blanket requirement that an SBOM must be made publicly available to customers. Whether and to whom information must be provided depends on the product, role and specific obligation and must be legally checked.
What companies need to clarify specifically
- Which artifacts receive an SBOM: source package, container, installer, or shipped product?
- When is it automatically generated and clearly assigned to the build, commit and release?
- What minimum data is mandatory and how is missing or contradictory information handled?
- Who evaluates hits from CVE, manufacturer or VEX information based on actual impact?
- How are licenses, exceptions, updates and deployment to customers or review entities controlled?
Data quality determines the benefit
A usable SBOM is assigned to a specific release and includes direct and transitive dependencies, unique identifiers and traceable relationships. Tool and runtime components, timeliness, access and distribution also need to be checked. PURL or CPE can help with identification, but are not a universal requirement. A VEX (Vulnerability Exploitability eXchange) can also record whether and why a known vulnerability for a product is actually affected or not affected.
From requirements to implementation
Keeping Components Transparent
Risk: Unknown dependencies
Organisational measure: Specify responsible persons per product
Technical implementation: Generate an SBOM during the build
Possible evidence: SBOM for each release
Making data usable
Risk: Incorrect allocation of CVEs
Organisational measure: Quality criteria and exception process
Technical implementation: Check identifiers, hashes and relationships
Possible evidence: Quality report
Address vulnerabilities
Risk: Inaction or wrong reaction
Organisational measure: Defining triage, deadlines and escalation
Technical implementation: Matching with Advisories and VEX
Possible evidence: Ticket and decision history
Ensure care
Risk: Outdated inventory
Organisational measure: Connect release and operations processes
Technical implementation: New creation on every release
Possible evidence: Version history
Working with ADIUMENTO
ADIUMENTO can provide advice and implementation support in structuring SBOM and dependency processes and connecting them to existing build/operational processes. This does not involve an independent certification service or guarantee of conformity. Technology and service references can be found at Technologies, Services and Solutions.
Typical deliverables
- SBOM target image with artifact, format and receiver model;
- Quality rules and responsibilities for dependencies;
- Vulnerability assessment, remediation and exceptions process;
- Roadmap for automated generation, storage and operational handover.
Limitations and dependencies
A complete SBOM does not prove that an artifact is harmless, nor does it prove that every reported vulnerability is exploitable. Scanners, data sources, package managers and proprietary components limit the informative value. Signatures can support the integrity and provenance of an artifact, but do not replace SBOM or malicious code inspection; for this see Code signing and artifact signing. ADIUMENTO does not provide legal advice or guarantee of conformity.
Further official sources
- CISA: SBOM – CISA
- SPDX specifications – SPDX
- CycloneDX specification – OWASP CycloneDX
- Regulation (EU) 2024/2847 – EUR-Lex
Orientation
Frequently asked questions
Is an SBOM enough for a secure release?
No. It shows which components have been documented. Secure releases also require secure build and release processes, vulnerability management, testing and regulated operations.
Should we use CycloneDX or SPDX?
Both are established, machine-readable formats. The choice depends on tool support and exchange partners. A pilot with representative artifacts shows whether relationships, identifiers and handovers work in your own chain.
How does an SBOM help with incidents?
It speeds up the determination of which delivered versions might contain an affected component. The actual impact and priority must still be technically assessed and processed in the incident process; see Monitoring and incident response.
Next sensible step
Have a representative product and its release process outlined. From this, data gaps, automation potential and a reliable entry point for governance and operations can be derived.