The 24-hour CRA deadline is changing software supply chain visibility

According to an analysis published by The Hacker News, manufacturers of products with digital elements sold in the European Union will face a September 11 deadline under the Cyber Resilience Act (CRA) to notify regulators within 24 hours after learning that a vulnerability is being actively exploited, with a fuller report due within 72 hours. For manufacturing executives, the 24-hour window may bring greater attention to software supply-chain visibility. Complex products can contain proprietary software, supplier-developed applications, commercial packages, microcontroller software, and open-source libraries, with dependencies extending across several tiers. A manufacturer may maintain numerous supplier relationships while having limited insight into the software embedded within individual components.

Under the CRA, the relevant product can encompass the complete finished product, creating a need to connect information from numerous suppliers into a coherent software inventory. Automotive, medical-device, aerospace, and consumer-electronics manufacturers may face particularly intricate versions of this challenge.

Software Bills of Materials, or SBOMs, provide an important foundation for organizing that information. According to IBM, an SBOM provides a machine-readable inventory of software components, libraries, modules, and dependencies, helping organizations understand the software included in products and systems. IBM also describes broader adoption of SBOM practices across sectors as regulatory requirements and software supply-chain concerns have expanded. For large manufacturers, however, supplier files may arrive in different formats and with varying levels of detail. A collection of documents can consequently become difficult to reconcile at product level, particularly when the underlying software changes after an SBOM has been produced.

That distinction may become particularly important when vulnerability reporting is time-sensitive. The Hacker News analysis of the CRA argues that organizations may find the September 11 requirement most challenging when they cannot quickly establish which software is present in a particular product or when a vulnerability first became known. A spreadsheet or email archive can document software composition at a particular moment, while subsequent releases, patches, dependency changes, or newly identified components can alter the picture.

This is the environment in which FossID, a software composition analysis company focused on source-code intelligence and software supply-chain transparency, has developed its role. Chief Growth Officer Aaron Branson views the underlying issue through the reliability of the information reaching manufacturers. “An SBOM is only as useful as the confidence an organization can place in the information inside it,” he states. “For companies receiving software from numerous suppliers, that confidence requires an additional layer of examination at the point where supplier information enters the enterprise.”

Source-code analysis aims to provide that layer by examining the software itself to identify components, dependencies, licenses, and vulnerabilities. FossID’s technology can scan code and identify open-source and third-party components, including smaller code fragments and dependencies that may be difficult to establish from declared package information alone. According to Branson, this creates an important distinction between receiving an SBOM and examining whether the SBOM corresponds with the underlying software.

The supplier relationship may add another layer to the visibility challenge. For large manufacturers, the usefulness of an SBOM may depend partly on whether information from different suppliers can be evaluated consistently and brought into a common record. This is an area where software composition analysis can play a broader role. Supplier-provided information can be examined against the software itself, helping distinguish a document that has been submitted from information that has been sufficiently validated.

Branson argues that this distinction may become increasingly important as regulatory responsibility reaches across complex chains of software dependencies. FossID’s work sits within a broader effort to make supplier software information more usable for the engineering, security, and compliance teams responsible for the finished product.

The complexity can increase when a supplier’s software contains dependencies from additional vendors and open-source projects. A manufacturer may receive information about a component without having the same level of visibility into the software beneath it. This can create a broader question about how manufacturers can establish confidence in software information that originates outside their own engineering teams.

“Our work in source-code analysis is relevant to that question because it examines software composition at the code level, providing another means of assessing information supplied through the broader ecosystem,” Branson explains. “But the larger issue is that manufacturers may need processes that allow software information to be verified across multiple layers of responsibility.” According to Branson, FossID has discussed this broader challenge with industry analysts as organizations move from simply generating SBOMs toward incorporating them into ongoing software-supply-chain processes.

Katie Norton, Senior Research Manager at IDC, sees flexibility as an important part of that transition. “As enterprises operationalize SBOMs, they need processes that can accommodate differences in suppliers, regulatory requirements, and internal review,” Norton states. “The challenge is supporting those variations without imposing the same workflow on every organization.”

Branson sees this as a change in the purpose of SBOM management itself. “The question is moving from ‘Do we have an SBOM?’ to ‘Can we continuously verify the software supply chain that the SBOM represents?‘” he states. That distinction places software composition analysis within a broader operational process involving engineering, security, procurement, and regulatory teams. An SBOM can serve as the record, while source-code analysis can provide a means of testing that record against the software from which it was derived.

Ultimately, the September 11 requirement may represent an early milestone in a broader evolution of software governance. The Hacker News notes that the CRA’s reporting obligations arrive before the regulation’s wider engineering requirements, which are scheduled to apply in December 2027. This sequence may give manufacturers an opportunity to examine the systems supporting vulnerability identification, supplier information, and product-level software visibility.

As connected products incorporate software from increasingly complex supply chains, regulatory readiness may increasingly depend on the quality and currency of the information behind an organization’s software inventory. The emerging challenge may be more about sustaining a reliable understanding of the software that remains connected to a product throughout its lifecycle.