The New Standard for Digital Trust: Why Businesses Should Create SBOMs Now

In modern software development, projects rarely operate in isolation. Most rely on open-source libraries, third-party components, and external package repositories to speed up development and cut costs. However, the benefits of this interconnectedness come with their own set of security risks.

Attackers have discovered that compromising a single dependency or package maintainer can be far more efficient than going after each company one by one. Once a malicious package slips in, it can spread fast across many projects, leaving countless applications exposed.

The latest incidents in SolarWinds and the Log4Shell vulnerability demonstrate how quickly such threats can cascade through entire ecosystems. What started as a single compromised component ended up affecting thousands of organizations worldwide. Which, in turn, caused huge financial losses for businesses. In 2025, for instance, global costs of cybersecurity breaches were estimated at around $60 billion, and they’re expected to grow by more than 15% each year, reaching about $138 billion by 2031.

Why Software Chain Security is Crucial

For decades, security teams worked on building walls to harden the outer system defense. However, today’s attackers are no longer trying to break in. Instead, they slip through internal supply chain tools & services.

According to Verizon’s report, 30% of global breaches in 2025 were traced back to third-party system weaknesses. The share of such incidents has doubled since last year, pulling software supply chain failures to number 3 in the OWASP Top 10:2025 chart.

OWASP defines such weaknesses as compromises in the processes and components used to build, distribute, and update software. Those typically include third-party code, tools, and dependencies. This makes supply chain failures one of the most prevalent and hardest-to-detect risks today.

In response, OWASP recommends taking a comprehensive approach to software security, which includes:

• Maintain a detailed Software Bill of Materials (SBOM)
• Track component versions and vulnerabilities
• Use trusted, signed packages
• Patch high-risk issues fast
• Control access to repositories and builds
• Safeguard systems’ integrity from development to release

These practices aim to close the gaps that attackers exploit in the supply chain. But they all depend on one foundation: a Software Bill of Materials. Without it, every other security measure becomes guesswork.

SBOM Explained: How It Helps Keep Your Software Secure

The key to preventing software supply chain attacks is having full visibility in every component and dependency that makes up your product. A Software Bill of Materials (SBOM) provides this transparency by showing exactly what’s inside your software.

It includes crucial metadata such as component names, versions, licenses, and sources, allowing organizations to understand where each element originates from. Also, SBOMs enable future automated analysis, vulnerability scanning, and compliance verification across the software lifecycle.

Organizations that integrated SBOMs into their development processes can not only maintain continuous visibility over their software supply chains but also enable faster response to emerging threats or attacks.

Numerous cybersecurity standards and regulations now require organizations to generate a Software Bill of Materials as part of their compliance process, specifying detailed requirements for SBOM generation, structure, and content.

Which Regulations Define SBOM as Mandatory

One of the most critical regulatory frameworks driving SBOM adoption is the EU Cyber Resilience Act – Regulation (EU) 2024/2847. The regulation establishes cybersecurity requirements for products with digital elements, including software sold within the European Union.

Under the CRA, manufacturers, importers, and distributors are required to provide a Software Bill of Materials (SBOM) in a machine-readable format (such as SPDX or CycloneDX) as part of the technical documentation necessary for market access.

Core requirements include timely updating SBOMs, covering at least all top-level components and dependencies. Full enforcement of the CRA is expected by December 2027, following designated transitional periods.

The SBOM obligation serves as a prerequisite for conformity assessment and market entry, meaning that non-compliant products may be prohibited from entering the EU market.

Another regulation that emphasizes a Software Bill of Materials adoption is the U.S. Executive Order 14028 on Improving the Nation’s Cybersecurity. It requires software vendors to supply the federal government with detailed SBOMs for all products.

Cybersecurity and Infrastructure Security Agency (CISA) has issued detailed guidance, “2025 Minimum Elements for a Software Bill of Materials (SBOM)”, which defines expectations for a Software Bill of Materials content, structure, and supplier transparency.

Other industry standards (especially in banking and finance), like NIST’s Secure Software Development Framework (SSDF), treat SBOMs as a key part of managing software supply chain risks. Similarly, Germany’s BSI TR-03183 guideline supports the EU Cyber Resilience Act (CRA) and requires SBOMs for software distributed in Germany and across the EU.

Risks of Non-Compliance

If a Software Bill of Materials is missing where required, organizations risk non-compliance under the EU Cyber Resilience Act (CRA), which carries administrative fines of up to €15 million or 2.5% of worldwide annual turnover. Alongside potential market-access restrictions, recalls, or sales bans until conformity is achieved.

Given that CRA defines machine-readable SBOM as part of the technical documentation for products with digital elements, its absence can be treated as a failure in the conformity assessment. Without it, products cannot enter the EU market. While manufacturers and, in some cases, importers and distributors risk facing enforcement actions from national authorities.

The United States, in contrast, has no universal fine system tied to the absence of SBOM. However, federal procurement does require SBOMs. This pushes large enterprises to consider dropping non-conformant vendors, putting those companies at risk of losing contracts and revenue.

How to Make SBOM Work For Your Organization In Practice

Many open-source projects now make SBOMs publicly accessible in their GitHub repositories in the repo, or via GitHub’s SBOM API users components and track vulnerabilities. For instance, the Polly project attaches a SPDX-format SBOM to its GitHub releases, illustrating how maintainers can publish machine-readable inventories alongside binaries.

The FreeRTOS project documents its dependencies also in SPDX-format SBOM and includes it in every new release. Besides project-specific repos, GitHub allows SPDX SBOM for any repository, enabling consistent, reproducible public SBOM access. For specific file examples, the CycloneDX community hosts a repository of public SBOM samples covering various ecosystems and use cases, useful as references for structure and content.

SBOMs’ publicity creates value for everyone. Users gain confidence knowing exactly which components they depend on and can quickly assess vulnerability exposure when threats emerge. Projects benefit from reduced support requests as users can answer their own dependency questions. And they also earn more trust from security-conscious adopters while making compliance much easier for enterprises that need SBOMs for regulatory reasons.

What Comes Next

Software Bills of Materials are no longer optional. The EU Cyber Resilience Act requires them for market access by 2027. Federal procurement mandates them now. Major enterprises demand them from vendors. And with supply chain attacks on the rise, the lack of visibility in software components leaves organizations operating blind.

The good news is that implementing SBOMs doesn’t require reinventing your development process. Modern tools allow for integrating SBOM generation into existing CI/CD pipelines, with minimal friction. The real challenge isn’t technical, it’s organizational. Businesses need to make a conscious, context-aware choice about how to implement SBOMs rather than treating them as a generic checkbox.

Here’s a good place to start:

1. Clarify which regulation is applicable to your product
   Regulatory regimes often dictate not only that an SBOM is required, but also that it must follow certain minimum content and machine-readable format expectations (e.g., SPDX or CycloneDX).
2. Assess your technology stack and delivery model
   Check your existing build tools, packaging systems, container platforms, and CI/CD pipelines to identify which SBOM formats and generation tools integrate most naturally and can be automated end-to-end, from development to release.
3. Select an SBOM format and communicate it with the team
   Once regulatory obligations, technical ecosystem, and tooling capabilities are aligned, you can choose a primary SBOM that minimizes friction for developers, satisfies auditors and customers, and provides a solid, scalable foundation for ongoing software supply-chain security.

Although the regulatory deadlines are approaching, you still have enough time to implement it thoughtfully, avoiding rushed compliance efforts and getting maximum value for your business security.

If you need support bringing SBOMs into your workflow – our team is here to help you shape the next step. From there, you’ll get expert support on every stage of the process, from regulatory assessment and format selection to automated generation and continuous update.

• #Manufacturing
• #Regulatory Compliance