[{"data":1,"prerenderedAt":157},["ShallowReactive",2],{"blog-post-blog_en-software-bill-of-materials-fuer-softwareprodukte":3},{"id":4,"title":5,"body":6,"cover":141,"date":142,"description":143,"draft":144,"extension":145,"meta":146,"navigation":147,"path":148,"seo":149,"stem":150,"tags":151,"__hash__":156},"blog_en\u002Fen\u002Fblog\u002Fsoftware-bill-of-materials-fuer-softwareprodukte.md","Software Bill of Materials: SBOMs for Secure Software Products",{"type":7,"value":8,"toc":134},"minimark",[9,13,18,30,33,67,70,73,77,80,83,109,112,115,119,122,125],[10,11,12],"p",{},"A Software Bill of Materials is moving from an optional security artefact to a practical leadership concern for software products. When teams ship faster with AI coding tools, add more open-source components, and face CRA or customer requirements, a package list in the repository is no longer enough.",[14,15,17],"h2",{"id":16},"what-a-software-bill-of-materials-provides","What a Software Bill of Materials Provides",[10,19,20,21,25,26,29],{},"An SBOM is a machine-readable inventory of the components that make up a product. Formats such as ",[22,23,24],"strong",{},"CycloneDX"," and ",[22,27,28],{},"SPDX"," make this information reviewable for Security, Engineering, Procurement, and customers.",[10,31,32],{},"The value does not come from the document itself, but from the decisions connected to it:",[34,35,36,43,49,55,61],"ul",{},[37,38,39,42],"li",{},[22,40,41],{},"Components:"," Which libraries, container images, frameworks, and build artefacts are included in the product?",[37,44,45,48],{},[22,46,47],{},"Versions:"," Which exact version runs in which release, tenant, or deployment?",[37,50,51,54],{},[22,52,53],{},"Origin:"," Does the component come from a trusted source or from a package path that is difficult to assess?",[37,56,57,60],{},[22,58,59],{},"Risk:"," Which known vulnerabilities, licences, or support end dates are relevant?",[37,62,63,66],{},[22,64,65],{},"Ownership:"," Who decides whether a finding blocks a release or is accepted deliberately?",[10,68,69],{},"The Cyber Resilience Act names SBOMs in a commonly used, machine-readable format as part of the vulnerability handling requirements for products with digital elements. Reporting obligations start on 11 September 2026, while the main obligations apply from 11 December 2027. That makes SBOMs not only a security topic, but a product and market-access topic.",[10,71,72],{},"The important point is that an SBOM does not automatically have to be public. It does need to be current, reproducible, and connected to a process that actually handles vulnerabilities.",[14,74,76],{"id":75},"where-teams-should-start-with-sboms","Where Teams Should Start With SBOMs",[10,78,79],{},"The most common mistake is generating an SBOM once for a customer questionnaire. The artefact exists, but there is no reliable way to handle dependencies, patches, and supply chain risk.",[10,81,82],{},"A pragmatic starting point is the most important production system, not the entire organisation. Teams should define four things there:",[34,84,85,91,97,103],{},[37,86,87,90],{},[22,88,89],{},"Build integration:"," The SBOM is generated from CI\u002FCD, container builds, or the release process, not from a manual spreadsheet.",[37,92,93,96],{},[22,94,95],{},"Format decision:"," CycloneDX or SPDX is chosen deliberately and tested with the tools already used in the company.",[37,98,99,102],{},[22,100,101],{},"Release rules:"," Critical vulnerabilities, unknown package sources, or missing licences get clear escalation paths.",[37,104,105,108],{},[22,106,107],{},"Customer evidence:"," Sales and Customer Success know which SBOM information may be shared and which stays internal.",[10,110,111],{},"This becomes especially relevant with AI-assisted development. Coding agents, fast prototypes, and automatically generated pull requests can introduce new dependencies without a conscious discussion about origin. SBOMs do not replace reviews, but they make these changes visible.",[10,113,114],{},"Warning signs include version drift between repository and deployment, many transitive dependencies without owners, scanners without prioritisation, and release processes that look at security findings only after go-live.",[14,116,118],{"id":117},"why-this-matters","Why This Matters",[10,120,121],{},"A Software Bill of Materials does not eliminate every vulnerability. It reduces the time a company needs to understand whether it is affected. In Log4j-like incidents, that speed determines cost, customer communication, and operational stability.",[10,123,124],{},"For decision-makers, SBOM work is therefore not an extra technical task. It improves due diligence, enterprise sales, CRA preparation, and incident response. It also shows whether a product architecture remains controllable when teams ship faster and AI puts more code into the pipeline.",[10,126,127,128,133],{},"Growing companies should not treat SBOMs as compliance PDFs, but as part of technical control. An ",[129,130,132],"a",{"href":131},"\u002Fen\u002F#packages","Architecture & AI Review"," can assess whether dependencies, build processes, and security ownership are already robust enough for customer requirements and regulatory pressure.",{"title":135,"searchDepth":136,"depth":136,"links":137},"",2,[138,139,140],{"id":16,"depth":136,"text":17},{"id":75,"depth":136,"text":76},{"id":117,"depth":136,"text":118},null,"2026-06-01","A Software Bill of Materials makes dependencies, vulnerabilities and supply chain risk visible before compliance or customers create pressure.",false,"md",{},true,"\u002Fen\u002Fblog\u002Fsoftware-bill-of-materials-fuer-softwareprodukte",{"title":5,"description":143},"en\u002Fblog\u002Fsoftware-bill-of-materials-fuer-softwareprodukte",[152,153,154,155],"Compliance","Cybersecurity","Software Architecture","Software Quality","_lnaUGB5N9laetMLa7fMA6mTBchosrO-fglkHXdBUrM",1781596427377]