The 24-hour CRA deadline is transforming visibility in the software supply chain.

      Starting September 11, the EU Cyber Resilience Act will mandate that manufacturers inform regulators within 24 hours if they discover their product has a vulnerability that is being actively exploited. For companies using software from multiple suppliers, the challenge lies not in having a Software Bill of Materials (SBOM) but in ensuring that it accurately represents the actual code. Aaron Branson from FossID argues that source-code analysis adds a layer of verification that enhances the reliability of SBOMs as supply-chain intelligence.

      An analysis from The Hacker News highlights that manufacturers of products with digital components sold in the EU must meet the September 11 deadline under the Cyber Resilience Act (CRA) to report vulnerabilities within 24 hours, followed by a more detailed report within 72 hours. This 24-hour time frame may heighten the focus on software supply-chain visibility for manufacturing executives. Complex products often incorporate proprietary software, third-party applications, commercial software, microcontroller software, and open-source libraries, creating dependencies that span multiple tiers. Manufacturers may hold numerous supplier relationships while possessing limited visibility into the software embedded in each component.

      As per the CRA, the applicable product could include the entire finished product, necessitating the integration of information from various suppliers into a consolidated software inventory. This challenge may be particularly complex for manufacturers in sectors like automotive, medical devices, aerospace, and consumer electronics.

      Software Bills of Materials (SBOMs) are essential for organizing this information. IBM defines an SBOM as a machine-readable list of software components, libraries, modules, and dependencies, assisting organizations in understanding the software within their products and systems. IBM notes that there has been a broader adoption of SBOM practices due to increasing regulatory demands and concerns about software supply chains. However, for larger manufacturers, supplier files might come in different formats and varying levels of detail, leading to difficulties in reconciling the information at the product level, especially when the underlying software changes after an SBOM has been created.

      This distinction becomes crucial when reporting vulnerabilities is urgent. The Hacker News analysis of the CRA suggests that organizations may struggle with the September 11 requirement if they cannot quickly determine the software in a specific product or when a vulnerability was first identified. A spreadsheet or email archive can capture software composition at a given time, but subsequent updates, patches, changes in dependencies, or newly recognized components can alter that landscape.

      In this context, FossID, a software composition analysis firm focused on source-code intelligence and transparency in software supply chains, has carved out its role. Chief Growth Officer Aaron Branson emphasizes the reliability of information that reaches manufacturers. He states, “An SBOM is only as useful as the confidence an organization can place in the information inside it.” For companies receiving software from various suppliers, this confidence requires an additional layer of scrutiny where supplier information enters the company.

      Source-code analysis aims to provide this additional layer by reviewing the software itself to identify components, dependencies, licenses, and vulnerabilities. FossID's technology can scan code to identify open-source and third-party components, including smaller code fragments and dependencies that may not be revealed by declared package information alone. Branson points out that this creates an essential distinction between merely receiving an SBOM and verifying whether it matches the actual software.

      The relationship with suppliers can further complicate visibility. For larger manufacturers, the effectiveness of an SBOM may depend on the ability to consistently evaluate information from different suppliers and consolidate it into a unified record. Software composition analysis plays a critical role in this area, as it allows for cross-verifying supplier information against the software itself, distinguishing validated data from documents that have been submitted without verification.

      Branson emphasizes that this distinction may gain importance as regulatory responsibilities extend across complex chains of software dependencies. FossID’s efforts align with a broader initiative to enhance the usability of supplier software information for engineering, security, and compliance teams tasked with delivering the finished product.

      Complexity can escalate when a supplier’s software includes dependencies from other vendors and open-source projects. A manufacturer might obtain data about a component without a corresponding level of visibility into the underlying software. This raises a broader concern about how manufacturers can trust software information sourced from outside their engineering teams.

      “Our work in source-code analysis addresses this concern by evaluating software composition at the code level, offering an additional method for validating information supplied through the broader ecosystem,” Branson explains. “The larger issue is that manufacturers may require processes capable of verifying software information across multiple layers of responsibility.” According to Branson, FossID has engaged in discussions with industry analysts regarding this challenge as organizations transition from merely generating SBOMs to integrating them into ongoing software supply-chain processes.

      Katie Norton, Senior Research Manager at IDC, highlights the importance of flexibility in this adaptation. “As enterprises operationalize SBOMs, they need processes that can handle differences in suppliers, regulatory demands, and internal reviews,” Norton notes. “The challenge lies in managing those variations without applying a uniform workflow across all organizations.”

      Branson views this transition as a shift in the purpose