TrustForge.pub

Author: Paul Gedeon

Supply chain security has become a question of visibility before it is a question of control. Modern organizations rarely buy a single product from a single supplier. They buy systems assembled by integrators, built on third-party libraries, cloud services, firmware, subcontracted components, and open-source projects maintained by people the final customer may never see. This is why the logic behind NIST SP 800-161 is important¹. Cybersecurity supply chain risk management depends on understanding who and what sits behind the visible vendor relationship. Trust cannot be built on branding alone. It requires transparency.

The Software Bill of Materials, or SBOM, is one practical answer to this problem. It gives customers and operators a structured view of the software components inside a product.² In theory, when a vulnerability is disclosed, an organization can compare the affected component against its SBOM and quickly determine whether it is exposed. That is useful. In environments where a single vulnerable library can appear across hundreds of products, SBOM can reduce confusion and shorten the time needed to identify affected assets.

But SBOM solves only part of the transparency problem. It tells us what is present. It does not automatically tell us whether the vulnerable code is reachable, exploitable, exposed, enabled, configured dangerously, or protected by compensating controls. It also does not tell us who is responsible for remediation when the vulnerable component sits three layers below the integrator. This exploitability gap is precisely what VEX (Vulnerability Exploitability eXchange) was designed to address, allowing a supplier to assert whether a product is affected, not affected, fixed, or still under investigation for a given vulnerability.³ Yet VEX shows that even when the ecosystem invents an exploitability layer, the harder problem of coordinated, timely response parties remains unsolved. A list of ingredients is not the same as a food safety system. It is necessary, but it does not cook the meal, clean the kitchen, or stop the restaurant from burning down.

This distinction matters because the threat environment is changing faster than traditional vulnerability management models were designed to handle. The old process assumes a relatively linear sequence: vulnerability disclosure, vendor analysis, customer notification, patch development, testing, deployment, and closure. That model already struggled before AI. Now attackers can increasingly automate reconnaissance, vulnerability matching, exploit adaptation, target selection, phishing, and malware variation. The result is a compression of time. The interval between public disclosure and active exploitation is shrinking. AI is best understood here as an accelerant of an existing trend rather than its sole cause, lowering the cost and skill needed to weaponize disclosed vulnerabilities at scale.⁴

In that environment, SBOM-based patching remains valuable, but its effectiveness can diminish if it remains a static compliance artifact. An organization may know that it contains a vulnerable component and still fail to act quickly enough. Worse, suppliers may each hold only part of the truth. The software vendor knows the component. The integrator knows the product architecture. The customer knows the deployment context. The security vendor sees exploit attempts. The open-source maintainer understands the original code. No single party has the full operational picture.

This is the core supply chain weakness, not lack of data, but lack of coordinated interpretation and response. Large vulnerability disclosures create a coordination crisis. When thousands of products may be affected, customers do not only need SBOM files. They need prioritization. They need to know which vulnerabilities are actively exploited, which products are truly reachable, which mitigations are safe, which patches are ready, and which suppliers are still investigating. Transparency without coordination can become noise.

That is why supply chain security should evolve from document exchange toward collaborative threat response. SBOM should become the inventory layer of a larger operating model, not the final objective. The real goal is not to prove that a vendor can generate a component list. The goal is to ensure that all relevant parties can respond together when risk becomes real.

A collaborative threat response and information-sharing center would be a practical step in this direction. Such a center should combine SBOM data, vulnerability intelligence, exploit telemetry, reachability analysis, patch availability, mitigation guidance, and vendor status updates. It should allow suppliers, integrators, cybersecurity vendors, customers, and relevant authorities to build a shared view of risk during major vulnerability events. This would help answer the questions SBOM alone cannot answer: Is this component used in a vulnerable path? Is exploitation happening? Which products are exposed? Who owns the fix? What temporary controls are available? Which customers need urgent action? This is also the direction regulation is moving: the EU Cyber Resilience Act makes both SBOM provision and coordinated vulnerability handling mandatory obligations for manufacturers, including reporting of actively exploited vulnerabilities to ENISA.⁵ The question of who owns the fix three layers below the integrator is precisely the accountability gap the law now seeks to assign.

This model would also reduce duplicated effort. Today, after a major disclosure, many organizations independently ask the same suppliers the same questions. Suppliers respond with inconsistent statements, customers wait for clarification, and security teams waste time translating partial information into action. A shared response mechanism could standardize evidence, reduce confusion, and make vulnerability handling more operational. It would also make accountability clearer. Vendors could no longer hide behind vague statements such as “we are investigating” without providing structured status updates.

However, this approach requires care. Information sharing must not become uncontrolled disclosure. Sensitive exploit details, customer exposure data, and supplier architecture information need governance, access control, and legal protection. The center must avoid becoming a bureaucratic portal where risk goes to die quietly in a dashboard. Its value depends on speed, trust, and actionable output. If it produces only reports, it will fail. If it produces coordinated decisions, it can materially improve resilience.

To conclude, SBOM is necessary, but insufficient. It improves transparency, and transparency is the foundation of trust. But in the age of AI-driven attacks, trust also requires speed, shared analysis, and coordinated response. A supplier that provides an SBOM but cannot explain exploitability, mitigation, ownership, or response timelines has delivered documentation without operational transparency. The component list is real, but it does not yet support a decision.

Supply chain security should therefore move beyond “Can you show me what is inside your product?” toward “Can we respond together when what is inside becomes dangerous?” That is the difference between compliance and resilience. SBOM gives us the map. The next challenge is building the command center.

1. National Institute of Standards and Technology, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, NIST Special Publication 800-161 Rev. 1 (Washington, DC: U.S. Department of Commerce, 2022), https://doi.org/10.6028/NIST.SP.800-161r1. ↩︎
2. National Telecommunications and Information Administration, The Minimum Elements for a Software Bill of Materials (SBOM) (Washington, DC: U.S. Department of Commerce, 2021), https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf. ↩︎
3. Cybersecurity and Infrastructure Security Agency, Vulnerability Exploitability eXchange (VEX) – Use Cases (Washington, DC: U.S. Department of Homeland Security, 2022), https://www.cisa.gov/sites/default/files/publications/VEX_Use_Cases_April2022.pdf. ↩︎
4. Microsoft, Microsoft Digital Defense Report 2023 (Redmond, WA: Microsoft Corporation, 2023), https://www.microsoft.com/en-us/security/security-insider/microsoft-digital-defense-report-2023. (Note: If you have a different specific threat intelligence report in mind for the AI section, replace this entry using the same format: Organization, Title in Italics (City: Publisher, Year), URL). ↩︎
5. European Parliament and Council of the European Union, Regulation on Horizontal Cybersecurity Requirements for Products with Digital Elements and Amending Regulation (EU) 2019/1020 (Cyber Resilience Act) (Brussels: Official Journal of the European Union, 2024). ↩︎