Navigating industrial cyber threats with SBOMs, VEX, CSAF for enhanced supply chain resilience

A significant rise in cybersecurity threats and attacks, particularly targeting software supply chains, has led to heightened scrutiny and a pressing need to enhance the resilience of supply chains for software utilized across government and critical infrastructure sectors. Any vulnerability or compromise within the software supply chain can have far-reaching consequences, as it can allow malicious cyber adversaries to infiltrate systems, steal sensitive data, or disrupt critical operations. 

One of the main challenges in securing software supply chains is the increasing reliance on third-party components and dependencies. Many software applications are built using a combination of proprietary code, open-source libraries, and commercial off-the-shelf software. While this approach allows for faster development and innovation, it also introduces potential vulnerabilities if these components are not properly vetted and maintained.

Embracing approaches such as Software Bill of Materials (SBOMs), Vulnerability Exploitability eXchange (VEX), and Cybersecurity Assurance Framework (CSAF) become imperative. Effective SBOM management mitigates cyber risk and improves cybersecurity throughout the software’s lifecycle, enabling organizations to prioritize SBOM implementation for enhanced transparency and comprehensive visibility into software components. VEX facilitates the exchange of vulnerability information, fostering collaboration to swiftly address emerging threats. Concurrently, CSAF ensures a standardized approach to cybersecurity practices. 

Impact of SBOMs on supply chain transparency and security

Industrial Cyber collaborated with cybersecurity experts to examine the impact of SBOMs on the transparency and security of the industrial supply chain. They also explored the challenges organizations encounter when implementing SBOMs effectively. Additionally, they investigated strategies that can be employed to enhance the resilience of industrial supply chains against cyber incidents as the reliance on interconnected devices continues to grow.

SBOMs are a critical component of cyber and supply chain transparency and risk management, as they enable stakeholder understanding of critical infrastructure and other industrial software supply chains, Jessica Wilkerson, a senior cyber policy advisor, and the medical device cybersecurity team lead with the Office of Strategic Partnerships and Technology Innovation (OST) in the Center for Devices and Radiological Health (CDRH) within the Food and Drug Administration (FDA), told Industrial Cyber. 

“This transparency allows stakeholders to understand their own risks, take targeted risk management actions, and respond to cyber threats more effectively when they arise,” Wilkerson said. “Developing strong policies and tools across the ecosystem for leveraging SBOM data, including ingestion, analysis, and sharing, can allow organizations, such as health care delivery organizations, to reduce or otherwise remove risk from their supply chains, potentially avoiding or mitigating cyber incidents.”

Eric Byres, founder and chief technology officer at aDolus Technology, told Industrial Cyber that SBOMs are the first step — but by no means the last — in ensuring software supply chain transparency. 

“The US government began calling for them in 2021’s Executive Order 41028 and the market followed suit,” Byres highlighted. “Gartner reckons ‘by 2025, 60% of organizations building or procuring critical infrastructure software will mandate and standardize SBOMs in their software engineering practice, up from less than 20% in 2022.’ There are now multiple solutions available for generating SBOMs.” 

But, Byres added that “SBOMs just give you a list of ingredients, they don’t tell you if subcomponents are going to introduce risk into your environment. If your interconnected devices have embedded third-party components (and I assure you, they do), you are going to need to combine SBOMs with deeper analysis tools that can also assess risk.”

In the industrial supply chain, software producers and consumers are looking for more transparency, Alex Santos, CEO and co-founder at Fortress Information Security, told Industrial Cyber. “SBOMs are a way to automate and scale the creation and ingestion of this information. Software producers need a better way to track the various proprietary, open-source, and third-party commercial codes that make up their products.”

“Some challenges organizations face during implementation in sharing this information between software suppliers and consumers,” according to Santos. “There are standard formats for SBOMs, for example, CycloneDX and SPDX, however, there are no standards for sharing them between stakeholders. We found many vendors are willing to share but want to do so in a secure and ‘permissioned’ manner, which is why we created the North American Energy Software Assurance Database. Making sharing easy makes it more likely to happen.”

Santos added that to ensure the resilience of industrial supply chains against disruptions, transparency information should be applied across organizations. “For software producers, this includes thinking about security upfront, during product design and development to prevent and correct issues before a product is released. Vulnerabilities are going to occur, so transparency information provided by SBOMs can be used in a procurement process to evaluate, product secure, understand what’s being pulled into your environment in advance, as well as have an accurate inventory of software components.”

Dmitry Raidman, CTO and co-founder at Cybeats told Industrial Cyber that SBOMs significantly enhance industrial supply chain security by listing software ingredients and their versions, identifying risks and vulnerabilities, and ensuring compliance with regulatory requirements and frameworks like NIST SP 800-161, FDA (pre and post-market), EU CRA, RMF, and CMMC. 

“The main challenges in implementing SBOMs effectively include the complex task of SBOM management, which involves tracking and maintaining SBOMs across diverse industrial systems and device firmware,” Raidman evaluated. “Additionally, continuous monitoring for new risks and integrating SBOMs with asset management solutions for full traceability, such as pinpointing the locations of assets with vulnerabilities like Log4j, are crucial for comprehensive risk mitigation.”

He pointed out that integrating SBOMs with asset management is essential for effective cybersecurity in industrial environments. “This integration links each software-based product SBOM to its corresponding physical or virtual asset, allowing for precise mapping. Assessing the criticality of assets within this framework helps prioritize risks, focusing resources on the most crucial areas.”

Raidman also said that continuously monitoring and applying changes of vulnerabilities to SBOM components, enriched with detailed information like U.S. Cybersecurity and Infrastructure Security Agency (CISA), KEV (Known Exploited Vulnerabilities), EPSS, and software supply chain intelligence, ensures a constantly updated security posture. 

“SBOMs have had a huge positive influence on the security of the software supply chain in general because software suppliers are using them heavily to manage vulnerabilities in the products they are developing,” Tom Alrich, an independent consultant specializing in supply chain security of critical infrastructure, told Industrial Cyber. “However, they are barely being used at all by organizations that are not developers for the primary use case that all of us are interested in: tracking on a daily basis the risks posed by the components included in software we use to accomplish our mission (this applies to private and public organizations).”

Alrich added that the reason for this isn’t that most suppliers don’t want to release SBOMs, but that end-user organizations aren’t asking to have them with each new version of their software (which is essential). “This is because there are zero low-cost, commercially supported tools that perform the complete set of steps necessary for the primary use case.”

However, the lack of tools is itself a symptom of two primary problems: the ‘naming problem’ and the lack of clarity on VEX, according to Alrich. “The OWASP SBOM Forum is working on mitigating both problems, as well as related problems that are also inhibiting the distribution and use of SBOMs. The group is open to all,” he added.

Dealing with cybersecurity risks using VEX metrics in OT environments 

The executives examine how VEX (Vulnerability Exploitability eXchange) metrics aid in evaluating and mitigating cybersecurity risks in OT environments, as well as the barriers that impede their widespread adoption.

VEX metrics can provide additional context to users about whether particular vulnerabilities are exploitable in a subject device, according to Wilkerson. “FDA’s premarket guidance recommends that manufacturers follow the NTIA’s ‘Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM)’ for generating SBOMs and performing a separate safety and security assessment of vulnerabilities associated with SBOM components.” 

She added that the safety and security assessment could be used by manufacturers to inform their VEX metrics.

“Currently, VEX is just a concept – in fact, it’s a number of concepts, none of them well defined; that’s the problem,” Alrich said. “The OWASP SBOM Forum is working on fixing that problem now.”

Byres detailed that VEX documents provide a machine-readable mechanism for OT vendors to communicate to their customers about whether or not their product or products are affected by any known vulnerabilities. “Many vulnerabilities are not exploitable, so vendors can save their customers a lot of time and angst by reassuring them when patching or mitigations aren’t necessary.” 

He cautioned that VEX documents are quite new though, so most asset owners don’t yet have systems in place to ingest VEX documents; thus, vendors aren’t necessarily experiencing pressure to provide them. “Recall though — we saw the same ‘chicken and egg’ scenario with SBOMs and once a few SBOM-generating solutions emerged, the paralysis evaporated,” he added. 

Santos said that VEX was developed to fill vulnerability management needs around the use of SBOMs. “SBOMs explain what software components are contained within a product. VEXs are machine-readable companion documents that explain if a product is affected by a newly discovered vulnerability, like Log4j. They can also include mitigation information, like configuration changes or if a patch is available.”

He added that VEX has not reached a crucial mass yet, but awareness helps drive adoption as the benefits of standardization and machine-readability encourage more tooling support and software suppliers to produce them.

“VEX is crucial for identifying and prioritizing real security risks in OT environments, helping to decide which vulnerabilities are affecting us and which aren’t,” Raidman said. “A key strategy includes isolating high-risk assets such as end-of-life Windows 7 in highly secure network segments (air-gap) or applying mitigation techniques. However, challenges in adopting VEX widely include the complexity of producing reliable VEX data at scale, the lack of fully automated methods, a shortage of skilled cybersecurity professionals, difficulties in integrating VEX with existing systems, and the need for constant updates in a changing threat environment since VEX comparing to SBOM is dynamic.” 

He further added that overcoming these obstacles is key to effectively using VEX for improving OT cybersecurity.

Role of CSAF in boosting industrial supply chain communication

The executives went on to elaborate on the significance of the Common Security Advisory Framework (CSAF) in enhancing communication and collaboration within the industrial supply chain, and what barriers exist in its implementation. 

Alrich detailed that CSAF is a vulnerability reporting platform that was previously called CVRF (Common Vulnerability Reporting Framework) and has been used for years. “VEX documents can be implemented on both the CSAF and CycloneDX platforms (VEX is just a type of vulnerability report). While big software developers like Microsoft, Red Hat, and Oracle have been providing vulnerability notifications in CVRF and CSAF for years, the specification is very difficult to understand and there are no general purpose CSAF consumption tools.” 

Thus, Alrich added that almost all organizations that wish to ‘consume’ CSAF documents (including CSAF VEX documents) need to develop their own tooling; not many non-developer organizations have done this. “The SBOM Forum is working to fix exactly this problem now.”

Wilkerson said that CISA has begun publishing advisories related to medical devices in CSAF. “FDA has published a white paper on “Best Practices for Communicating Cybersecurity Vulnerabilities to Patients,” and FDA co-led the development of a Medical Technology (MedTech) Vulnerability Communications toolkit through the Health Sector Coordinating Council (HSCC), with both resources targeted at ensuring that patients/users have the appropriate clinical context for vulnerabilities. This information complements the technical specifics from the CISA advisories,” she added.

“Adoption of CSAF is critical to improving information flow between software suppliers and users. Currently, the entire security industry is hamstrung by the lack of a consistent format for sharing vulnerability information,” Byres stated. “Even inside the same company, we see vulnerability disclosures with completely different formats and information. As a result, it can be exceptionally difficult to automate the ingestion of vulnerability information.”

He added that the barrier to adoption is inertia; however, with majors like Hitachi, Siemens, and Schneider Electric now releasing CSAF-formatted notices, expect the rest of the industry to get on board.

“CSAF is a machine-readable format for security advisories. Vendors are already using CSAF security advisories to communicate remediation instructions and other data for CVEs affecting their products,” Santos said. “Several large vendors in critical infrastructure including Cisco, Siemens, Schneider Electric, and Red Hat have CSAFs available.” 

He added that the CISA is also building an open repository of CSAF advisories.

Additionally, Santos pointed out that CSAF and VEXs help with vulnerability prioritization. “When a new vulnerability is discovered in a component, it doesn’t mean it is automatically exploitable in a product which it’s included in. A CSAF from a vendor explains if this is a vulnerability which needs attention now if it’s less serious due to a configuration needed for exploitation, or even a non-issue.”

Raidman said that in the context of industrial cybersecurity, CSAF profile 5 is instrumental for standardizing VEX disclosure, aiding in efficient vulnerability communication and lifecycle management. “Overall, VEX carries information on whether the software in use is affected by a certain vulnerability or not. However, a significant barrier lies in the interoperability between Vulnerability Exploitation eXchange (VEX) data and SBOMs, which differs from traditional security advisories.” 

He added that for optimal effectiveness, VEX should be closely linked with the SBOM, referencing it directly to ensure that the vulnerabilities’ exploitability information aligns with the detailed software inventory. “This connection is vital for comprehensive risk management and implementing targeted mitigation strategies, yet bridging the gap between VEX data and SBOMs remains a critical challenge to be addressed in the industrial cybersecurity landscape.”

Dive into SBOM adoption, impact on industrial cybersecurity, future trends

As cybersecurity threats continue to escalate and SBOM adoption gains momentum, the executives evaluate when SBOMs and related technologies will reach mainstream adoption. They also examine how these technologies might impact the cybersecurity landscape in industrial environments. Additionally, considering the current disagreements and lack of conformity, they provide predictions on the future appearance of SBOMs.

Wilkerson said “As of March 29, 2023, medical device manufacturers of certain types of medical devices (‘cyber devices’) must submit SBOMs as part of the submissions to FDA when seeking marketing authorization to be able to sell their products within the United States. For other types of devices where SBOMs may be relevant, SBOMs are a recommended part of submissions.”

Consequently, she added that in the medical device subsector, FDA’s actions are supporting mainstream SBOM adoption, and form an important part of medical device cyber risk management, allowing FDA, medical device manufacturers, and their customers to use SBOM information to respond to cyber threats, such as by identifying potentially vulnerable medical devices when new vulnerability information is found, and/or by using SBOM information to help make purchasing, acquisition, or regulatory decisions.

Byres expects to see SBOMs in widespread use by the end of this year. “The US federal government has been pushing for them for some time now, and the EU Cyber Resilience Act will be enacted sometime this year. But more importantly, we’re seeing a huge uptick in demand from the market from all players across the software supply chain.” 

“OT vendors want to vet third-party components they use, asset owners are writing transparency requirements into their procurement contracts, and integrators and consultants are having to shoulder risk without them,” according to Byres. “There are different SBOM formats vying for supremacy and different mechanisms for producing them. You can produce SBOMs at various points in the software development lifecycle, using source code, or performing binary code analysis. For the foreseeable future, all will play a role in increasing transparency as they each offer different strengths and weaknesses.”

Alrich disclosed that SBOM use by software developers, to learn about vulnerabilities in the products they’re developing, has huge momentum. “Just one tool, Dependency Track, is now used 17 million times a day to look up vulnerabilities in components found in an SBOM; however, this usage is almost entirely by developers to manage vulnerabilities in products they are developing.”

Unfortunately, he added that nothing like that is happening on the end user side. “This situation won’t change until people take action to change it. That’s what the OWASP SBOM Forum is doing. I am sure SBOMs will be in wide use by end users (or by service providers operating on their behalf) within 5-10 years, but probably not much earlier than that.”

Santos assesses that there is a crawl-walk-run in the adoption of new technologies and “we’ve seen new organizations typically start out by producing SBOMs on their own internally developed software for license compliance or vulnerability management purposes. This is a great first step and helps to educate and build awareness inside organizations of what SBOM are and the usefulness of the data they provide.”

He added, “On the horizon, we see the use cases expanding in organizations to include formal requests for them during procurement processes, contract negotiation, architecture review, incident response, and even M&A activity as part of the due diligence process to get ahead of what you’re pulling into your organization, and if their technology worth the price.”

By 2025-2026, Raidman said that as SBOMs become mainstream, their sharing, consumption, monitoring, and management will be standard capabilities within the modern toolbox of product security professionals CPSO (chief product security officer) on the software producers’ side and the CISO organizations of software-based product consumer side. 

He added “This trend reflects a significant shift in the cybersecurity landscape, particularly in industrial environments. High-quality SBOMs will be paramount for ensuring software transparency and effective vulnerability management, with the failure to provide them as a potential disqualifier for vendors based on recent Gartner research.” 

Additionally, the importance of related concepts like HBOM (Hardware Bill of Materials), CBOM (Cryptography Bill of Materials), and MLBOM (Machine Learning Bill of Materials) will also rise, highlighting the need for a comprehensive view of all components – software, hardware, data, and cybersecurity elements – combining the product, Raidman said. “Integrating SBOMs with other cybersecurity tools will evolve into a more proactive and preventive approach, with standardized practices enhancing their effectiveness in risk validation, detection, and mitigation,” he concluded.