{"id":73425,"date":"2026-08-05T22:33:45","date_gmt":"2026-08-05T20:33:45","guid":{"rendered":"http:\/\/adiumento.local\/?page_id=73425"},"modified":"2026-08-05T22:33:45","modified_gmt":"2026-08-05T20:33:45","slug":"sbom-dependency-management","status":"publish","type":"page","link":"https:\/\/adiumento.de\/en\/themen\/regulatorik-sicher-umsetzen\/sichere-softwarebereitstellung\/sbom-dependency-management\/","title":{"rendered":"SBOM and dependency management"},"content":{"rendered":"
\"Sichere<\/span>

\u2190 Secure software delivery<\/a><\/p>

SBOM and dependency management<\/h1>

Create transparency about components \u2013 and make controllable decisions from them.<\/strong><\/p><\/div><\/div>\n\n\n\n

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.<\/p>\n<\/div>\n\n\n

Background<\/h2>\n\n
\"Sichere<\/figure>
\n

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.<\/p>\n<\/div><\/div>\n\n\n<\/div>\n\n\n

Technical context<\/h2>\n\n

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<\/a> and CycloneDX<\/a> 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.<\/p>\n\n\n\n

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.<\/p>\n<\/div>\n\n\n

What companies need to clarify specifically<\/h2>\n\n
\"Abstrakte<\/figure>
\n