SBOM and the Cyber Resilience Act: mapping dependency risks

The entry into force of the Cyber Resilience Act¹ (CRA) imposes new responsibilities on European C-levels and technical decision-makers: software security is no longer just an engineering best practice, but a strict legal requirement for market access. The legislator has drawn a clear line, establishing that opacity within the supply chain is no longer an acceptable business risk. Those who place digital products on the single market are now directly responsible for vulnerabilities present in the code, including those originating from third-party libraries.

Faced with these directives, the Software Bill of Materials (SBOM) emerges as the fundamental and mandatory operational tool for obtaining the CE marking. Without an exact mapping of what makes up the software, demonstrating compliance is impossible. This article explores methodologies for exhaustively mapping dependencies, quantifying technical debt accumulated in repositories, and preparing corporate infrastructure for new compliance standards. Moving from a reactive approach to structured governance requires the native integration of security into software development and distribution processes². This evolution ensures total visibility into the foundations of your product, allowing you to release secure updates without suffering regulatory blocks.

Why the Cyber Resilience Act makes the SBOM a business constraint

European legislation transfers the legal responsibility for vulnerabilities directly to those who distribute the product. Without an updated inventory of dependencies, maintaining the CE marking becomes impossible. This failure translates into an immediate block on sales and exposure to sanctions calculated on the company’s global turnover.

The transition imposed by the new European regulation consists of abandoning traditional reactive patching in favor of a structural approach based on Security-by-design³. Until a few years ago, the integration of open source or third-party components took place with minimal checks, implicitly delegating security to external maintainers. Today, the CRA establishes that the burden of proof falls on the manufacturing company.

The latter must ensure that every line of packaged and distributed code is traceable, secure, and free of known vulnerabilities. This European regulatory orientation aligns with a global movement that began in the United States with Executive Order 14028⁴, ⁵. The provision, known as the Executive Order on Improving the Nation’s Cybersecurity⁶, mandated the use of software bills of materials for anyone providing digital solutions to federal agencies.

A careful analysis of legal responsibilities shows that compliance is no longer an operational delegation for development teams, but a fiduciary mandate for the corporate board. Integrating code of unknown origin and composition is equivalent to placing a physical product on the market without knowing its manufacturing materials. This responsibility is fully integrated into modern risk management and ESG governance strategies, where digital transparency is a fundamental pillar.

The absence of rigorous governance over dependencies exposes the organization to severe risks. The first obstacle is the blocking of commercialization due to the immediate invalidation of the CE marking throughout the European Economic Area. Added to this are direct financial sanctions, calculated as a percentage of the company’s global turnover, in the event of incidents resulting from negligence in mapping. Finally, there is the risk of catastrophic reputational damage and the loss of trust from customers and investors, as demonstrated by recent supply chain attacks on official packages linked to large vendors. Without total visibility, affected companies do not know they are executing hostile code, replicating on a smaller scale the systemic damage already observed during the SolarWinds case⁷.

What does SBOM mean and how does it differ from a traditional bill of materials?

An SBOM is the formal and structured inventory of all components, libraries, and dependencies used to build a software application. Unlike a traditional bill of materials, it includes specific versions, usage licenses, hierarchical relationships between packages, and cryptographic signatures necessary to ensure the integrity of the entire supply chain.

To understand the value of this tool, an analogy with the manufacturing industry is useful. When an automotive company assembles an engine, it tracks exactly the origin, batch, and specifications of every single screw; if a supplier reports a metallurgical defect, the parent company knows exactly which vehicles to recall. Software engineering, for decades, has operated by assembling libraries without maintaining this level of traceability. In traditional PLM (Product Lifecycle Management) systems, software is often treated within an EBOM⁸ (Engineering Bill of Materials) or an MBOM⁹ (Manufacturing Bill of Materials) as a single black-box component, a monolithic aggregate devoid of internal details.

The software bill of materials breaks this opacity. However, a simple text list of packages is not sufficient for the automation required by modern regulations. For this reason, the industry has developed specific standards. CycloneDX¹⁰ and SPDX¹¹ are the standardized formats used to document information about software components within an SBOM. These formats, also recommended by CISA guidelines¹², allow machines to read the inventory and automatically cross-reference it with global threat databases, such as the National Vulnerability Database¹³.

For enterprise organizations, maintaining total supply chain visibility through a structured component inventory is the only scalable method for managing application complexity.

The substantial differences between a generic bill of materials and a standardized SBOM emerge on three fronts. Regarding resolution depth, the generic bill lists only first-level libraries, while the standardized SBOM maps the entire hierarchical tree. For license management, the modern inventory automatically includes legal metadata to prevent copyright violations derived from restrictive open source code. Finally, cryptographic verification integrates unique hashes for each component, ensuring that the scanned library is exactly the one compiled into the final artifact.

How to map dependencies to mitigate supply chain risk?

Mapping dependencies requires the integration of compositional analysis tools directly into development pipelines, tracking both directly imported packages and transitive dependencies. This continuous approach identifies vulnerabilities before release into production, transforming the inventory from a static document into a dynamic and automated security safeguard.

The greatest risk for CTOs does not lie in internally written code, and often not even in libraries imported directly by developers. The real blind spot is constituted by transitive dependencies: code written by third parties that in turn calls other third-party code, creating a deep and invisible chain. As pointed out by our CTO Paolo Mainardi, organizations have now reached a point of no return in managing software dependencies: ignoring the complexity of this tree means accepting incalculable technical debt. The OSSRA 2024 report reveals that 91% of examined code repositories include components that are 10 or more versions behind.

How can we govern this complexity? Modern software engineering is based on the continuous integration of third-party libraries. This composable approach is correct and necessary to accelerate releases, but it exposes applications to structural fragility if not governed. The weakness of these architectures is demonstrated by a series of recent attacks that have compromised ecosystems considered secure. In the world of development tools, the compromise of the Nx Console extension for VS Code demonstrated how a stolen token on GitHub can distribute malicious code to millions of machines. The Python ecosystem has suffered critical blows on PyPi, where packages linked to the AI stack like LiteLLM were manipulated to steal root keys.

Enterprise infrastructures are not immune either. Red Hat had to manage critical vulnerabilities linked to unauthorized access in its GitHub organizations, while cloud-native platforms like Vercel faced security incidents that threatened frontend deployments. In the PHP ecosystem, targeted attacks hit Laravel Lang packages by injecting credential stealers directly into translation dependencies. These incidents demonstrate that blindly trusting imported code is equivalent to leaving the keys to the infrastructure to strangers.

From our field experience in the enterprise projects we manage, we have found that inventory generation cannot be a manual activity performed at the end of a project. It must become a native process within Continuous Integration (CI) pipelines. Implementing industry standards like Sigstore¹⁴ and OpenSSF to validate OCI artifact integrity ensures that the distributed code corresponds exactly to the scanned code, preventing attacks on package repositories.

The strategic approach for effective mapping is divided into three operational phases:

1. Direct and transitive identification: automated scanning of manifest files (such as package.json or pom.xml) during the build phase to resolve the entire dependency tree, exposing the deepest levels.
2. Cross-referencing with vulnerability databases: real-time comparison of component hashes with threat intelligence feeds, assigning an immediate risk score to every build.
3. Continuous validation and selective blocking: configuration of policy-as-code that automatically interrupts the CI pipeline if the introduction of a library with critical vulnerabilities or unapproved licenses is detected.

What metrics define the ROI of automated management?

The ROI of automated management is measured through a reduction in Mean Time To Remediation (MTTR) of up to 80% during critical incidents and the elimination of hours dedicated to manual audits. Automation transforms compliance from an operational cost into a competitive advantage, accelerating the time-to-market of secure software releases.

The implementation of a software tracking system should not be evaluated solely as an expense linked to regulatory compliance. Automating the generation and analysis of bills of materials significantly reduces the cognitive load on development teams, a cornerstone principle of the Platform Engineering discipline. When developers do not have to worry about manually tracking libraries or managing spreadsheets for licenses, they can focus on writing value-added features. In this context, the operational efficiency derived from adopting cloud-native and DevOps practices acts as a direct growth engine for the entire organization.

The impact on business becomes evident during security crises. When a widespread zero-day vulnerability emerges, as happened with Log4j¹⁵, companies without an automated inventory take weeks to discover where the vulnerable component is running, accumulating remediation costs that easily exceed 100,000 euros per single incident. With an automated system, the query takes a few seconds. Gartner forecasts indicated that by 2025, 60%¹⁶ of organizations¹⁷ would have mandated the use of these structured inventories in their software procurement processes. Today, in 2026, this dynamic has materialized: the request for SBOMs has become a de facto standard in B2B contracts. Furthermore, rigorous industry standards such as PCI DSS 4.0¹⁸ (the evolution of the PCI DSS framework for payment security) explicitly require detailed inventories of software components to maintain certification.

Concrete metrics for evaluating return on investment include:

• Contraction of Mean Time To Remediation (MTTR): moving from weeks of manual investigation to a few minutes for the identification and localization of compromised packages.
• Reduction of security audit hours: total elimination of manual code reviews for verifying open source licenses and obsolete dependencies.
• Acceleration of time-to-market: smoother release pipelines where security checks occur asynchronously, avoiding bottlenecks before deployment to production.

Next steps for continuous compliance

Adapting to European regulatory requirements represents a path of technological maturity that necessarily begins with total visibility into the software infrastructure. The bill of materials for components is not a static document to be archived after release, but a dynamic data set that requires continuous orchestration to reflect the daily evolution of code and global threats. For C-levels, governing this process means protecting business continuity and ensuring uninterrupted market access.

Organizations that intend to implement the frameworks required by the Cyber Resilience Act and protect their digital assets can request a specialized audit or explore our Supply Chain Security services to ensure full compliance.

In the next article in the series, we will examine the use of artificial intelligence to simulate attacks and automate vulnerability reporting within 24 hours, as required by the CRA time windows.

Notes and sources