SOFTWARE SUPPLY CHAIN REGULATIONS: How to achieve effective & efficient SBOM management?

HINTERGRUND

DER NEUE EUROPÄISCHE CYBER-RESILIENZ-Act (CRA) ZIELT AUF DIE ERHÖHUNG DES SICHERHEITSNIVEAUS UND DER TRANSPARENZ AB

Am 15. September 2022 veröffentlichte die Agentur der Europäischen Union für Cybersicherheit (ENISA) den Entwurf des neuen Cyber Resilience Act (CRA), welcher nach Anpassungen und Beschluss der EU per 10. Dezember 2024 in Kraft getreten ist. Der CRA gilt in der gesamten Europäischen Union und weltweit für alle Hersteller, Importeure und Händler von Produkten mit digitalen Elementen, die ihre Produkte in der EU vermarkten. Der CRA zielt darauf ab, das Sicherheitsniveau aller Produkte mit digitalen Elementen in der Europäischen Union zu erhöhen, indem sie die Hersteller verpflichtet, einen Cybersicherheitsrahmen zu implementieren und aufrechtzuerhalten und diesen Rahmen während des gesamten Produktlebenszyklus einzuhalten. Darüber hinaus wird eine verbesserte Transparenz in Bezug auf Sicherheitseigenschaften es Verbrauchern und Unternehmen ermöglichen, sicherheitsbewusste Entscheidungen zu treffen und Produkte mit digitalen Elementen sicherer zu verwenden.

BEGRENZTE HANDLUNGSZEIT FÜR PRODUKTE MIT DIGITALEN ELEMENTEN

Diese Initiative der ENISA folgt auf die zunehmenden Schäden durch Cyberkriminalität, die 2021 zu weltweiten Kosten von mehr als 5,5 Billionen Euro führten. Viele dieser Cyberangriffe werden durch Sicherheitslücken in Produkten mit digitalen Elementen verursacht und durch die mangelnde Transparenz der Hersteller in Bezug auf relevante Sicherheitseigenschaften noch verschärft. Während die CRA ein breites Spektrum an „Produkten mit digitalen Elementen“ ins Visier nimmt, das von Betriebssystemen, Desktop- und mobilen Anwendungen bis hin zu Hardwaregeräten und Netzwerkgeräten reicht, konzentriert sich dieses Whitepaper auf vernetzte Geräte und richtet sich an Hersteller, Händler und Importeure solcher Geräte.

Der CRA wurde in 2024 von der Europäischen Kommission als Europäische Richtlinie verabschiedet und ist per 10. Dezember 2024 in Kraft getreten. Dadurch bleibt — selbst mit der Übergangsfrist bis 10. Dez 2026 — nur wenig Zeit, um die erforderlichen Berichtspflichten zu verabschieden und die verbleibenden grundlegenden Anforderungen zu erfüllen. Aufgrund mehrjähriger Konstruktions- und Entwicklungszyklen müssen alle Hersteller jetzt handeln. Nur Geräte, die durch die Verordnung (EU) 2018/1139 (Zivilluftfahrt), die Verordnung (EU) 2017/745 (Medizinprodukte) und die Verordnung reguliert werden (EU) 2017/746 (medizinische In-vitro-Diagnostika) oder gemäß der Verordnung (EU) 2019/2144 zertifizierte Geräte (Typgenehmigung von Kraftfahrzeugen und ihren Anhängern sowie für solche Fahrzeuge bestimmte Systeme, Bauteile und selbstständige technische Einheiten...) sind ausgenommen von der CRA. Angesichts der durchschnittlichen mehrjährigen Zeitspanne zwischen der Entwicklung und der Produktion der angeschlossenen Geräte bleibt nur wenig Zeit für die Annahme und Anwendung der notwendigen Sicherheitsänderungen.

ÜBERBLICK ÜBER DIE CRA ANFORDERUNGEN

Während der CRA erweiterte Sicherheitsverpflichtungen für die Erfüllung der grundlegenden Sicherheitsanforderungen festlegt, wie z. B. Konformitätsbewertungen durch Dritte für kritische Produkte (sowohl für Klasse I als auch für Klasse II), bleiben die zugrunde liegenden Anforderungen für alle Produkte gleich. Die neuen Anforderungen der CRA lassen sich grob in die drei Kategorien Governance, Produktentwicklung und Berichterstattung einteilen:

ANFORDERUNGEN AN DIE PRODUKTENTWICKLUNG

1. Anforderungen, die das Produkt selbst betreffen, definieren ein Mindestmaß an Sicherheitseigenschaften, um das Produkt vor Cyberangriffen zu schützen und sein Sicherheitsniveau zu erhöhen.

ANFORDERUNGEN AN DIE UNTERNEHMENSFÜHRUNG

2. Anforderungen, die sich auf die Prozesse des Softwareentwicklungszyklus (SDLC) des Herstellers auswirken, wie Konzept und Design, Entwicklung, Produktion und Markteinführung sowie Service und Support, sollen die Sicherheit erhöhen, sichere Produkte zu entwickeln und ihr Sicherheitsniveau auf wiederholbare, transparente und nachhaltige Weise aufrechtzuerhalten, die mit angemessenen Sicherheitskontrollen messbar ist.

ANFORDERUNGEN AN DIE BERICHTERSTATTUNG

3. Melde- und Informationspflichten gegenüber den Überwachungsbehörden und Nutzern von Produkten über ausgenutzte Sicherheitslücken und Vorfälle, die das Produkt betreffen, stellen sicher, dass Maßnahmen zur Schadensbegrenzung zeitnah umgesetzt werden können. Ziel ist es, den Zeitrahmen, in dem sowohl Endnutzer als auch Anbieter kritischer Infrastrukturen durch kritische Sicherheitslücken Cyberbedrohungen ausgesetzt sind, zu minimieren, um das allgemeine Sicherheitsniveau der europäischen digitalen Infrastruktur zu erhöhen, indem bereitgestellte Korrekturen oder Zwischenmaßnahmen ergriffen werden, um die Auswirkungen der Sicherheitslücke zu verringern.

CRA-ANFORDERUNGEN DECKEN SICHERHEITSLÜCKEN IN DER LIEFERKETTE AB

Die folgende Abbildung gibt einen Überblick über die wichtigsten Anforderungen und deren Zusammenhang mit den jeweiligen Phasen des Produktsicherheitslebenszyklus. Ihr Zweck besteht darin, tiefgreifende und sichere Schutzansätze zu unterstützen und zu gewährleisten, mit dem Ziel, die Gewissheit zu schaffen, dass die Produkte die erhöhten Sicherheitserwartungen des europäischen Marktes erfüllen. Eine zentrale Anforderung des CRA ist das Risikomanagement in der Lieferkette.

STRENGTHENING SOFTWARE SUPPLY CHAIN SECURITY AND COMPLIANCE

FAILED COMPLIANCE TO OPEN-SOURCE LICENSES EXPOSE RISK OF LEGAL ACTION

Streamlining Open-Source Software License Compliance in IoT/OT

The embedded software of an IoT device is often com- posed of complex but essentially standard functions, which can account for up to 90% of its codebase. However, the cost involved in developing and maintaining such a software stack is often beyond the means of most embedded product manufac- turers. As a result, original equipment manufacturers (OEMs) acquire this software from library and operating system vendors, as well as open-source software (OSS) projects. Consequently, the majority of IoT devices incorporate a significant amount of third-party software, the copyright of which remains with its creators. Users and operators of these devices can only use this software within the boundaries set by the copyright holders‘ licensing agreements. While licenses can specify any terms chosen by the copyright holder, most open-source software projects employ standardized license forms to simplify compliance.

Failure to comply with the terms of these licenses exposes users and operators of IoT devices to the risk of legal action by the copyright holders. While most cases related to OSS are resolved amicably, situations involving commercial software, breakdowns in goodwill, or copyright trolling scenarios.13 can lead to substantial financial consequences and operational disruptions. Driven by a few prominent litigation cases, many organizations have adopted SBOMs with the aim of reducing license compliance risks. Interestingly, it is often the General Counsel rather than the CTO or CISO who has spearheaded this initiative.

OPEN CHAIN RECOMEDED FOR OWN OSS LICENSE PROGRAMS

During procurement, operators have started demanding evidence of full license compliance from suppliers. In response, sup- pliers have partially addressed this demand by providing SBOMs that list software components and their respective licenses. However, operators have no guarantee of the completeness
and accuracy of such SBOMs, prompting them to seek indemnification against copyright claims. While indemnification is not a concept that General Counsels are comfortable with, over time, legal teams at software vendors have found a middle ground with engineering teams. If the inventory of OSS software is comprehensive and well-maintained, and engineers are vigilant in identifying unusual licenses for review, General Counsels can be assured regardless of the number of OSS components involved. For IoT/OT vendors in need of their own OSS license compliance program, implementing the OpenChain standard (ISO/IEC 5230)14 is recommended. This standard has been developed as a community service by pioneers in such programs. Like SPDX, it is a freely available ISO standard that is widely embraced by engineering departments, corporate legal teams, and the OSS community due to its simplicity and proven effectiveness.

VEX HELPS ON EXPLOITABILITY EVALUATION

Enhancing Vulnerability Management in IoT/OT Supply Chains

IoT/OT faces an increasing risk of cyberattacks, with unpatched software vulnerabilities posing a significant threat. In the broader IT landscape, these vulnerabilities are known to contribute to one in three information security breaches 15 16. Consequently, reducing the time between vulnerability discovery and implementing mitigations has become a crucial goal for the entire IoT/OT supply chain.

While tools and best practices are emerging, establishing an effective vulnerability management program remains challenging. Despite vulnerabilities being typically announced alongside patches or mitigations, IT organizations take an average of 60 to 200 days to apply these patches. Factors contributing to this delay include a lack of situational awareness, resulting in over- looked vulnerabilities, and overwhelming SecOps teams when improved awareness reveals numerous vulnerabilities.

However, IoT/OT suppliers committed to securing their products aim to avoid the risks associated with unpatched vulnerabilities. In the realm of vulnerability management, the National Telecom- munications and Information Administration (NTIA) is developing the Vulnerability Exploitability eXchange (VEX see 17 ). VEX com- plements Software Bill of Materials (SBOMs) and allows device manufacturers to communicate the exploitability of vulnerabil- ities discovered in their software components. By using VEX, organizations can determine if a vulnerability listed in an SBOM affects their products without the need for extensive investigation.

VEX enables OEMs to assess whether vulnerabilities in the components they use are exploitable in the product. Factors such as code execution, conditional compile statements, and existing security controls determine if a vulnerability poses a risk. This knowledge saves developers time by focusing on addressing vul- nerabilities that pose a genuine threat, rather than unnecessary fixes.

VEX ALONE DOES NOT MAKE THE (EXPLOITABILITY) STORY

While VEX provides valuable insights, it is recommended to combine it with context-based analysis to further mitigate supply chain risks. Advanced context-based analysis encompasses hard- ware architecture, OS configurations, encryption mechanisms, control flow, and API calls, providing a comprehensive understanding of a product‘s vulnerabilities.

To enhance transparency and visibility, the NTIA suggests ex- panding SBOM use cases and encourages organizations to request additional data fields, such as component hash, lifecycle phase, relationships, and license information.
It also emphasizes the need to create and maintain SBOMs for cloud-based software and SaaS, ensure integrity and authentic- ity through mechanisms like digital signatures, link to external vulnerability data sources, assess vulnerabilities and exploita- bility in dependencies using VEX, employ binary analysis tools for legacy software, and maintain implementation flexibility and uniformity.

By combining automated tools like VEX, comprehensive SBOMs, and context-aware vulnerability analysis, organizations can effi- ciently manage supply chain vulnerabilities and strengthen their overall security posture.

SBOMS AS A TO-LIST

Ensuring Supply Chain Security in IoT/OT Environments

Managing supply chain risks often involves suppliers demonstrat- ing compliance with specific policies. This includes rules of ori- gin, secure software development standards, and maintenance commitments. Ideally, software suppliers would self-report their performance on supply chain security compliance using widely accepted metrics, optionally certified by independent third par- ties. However, organizations currently need to conduct their own research and map results into their own metrics, using an SBOM as a to-do list. IoT/OT software suppliers aim to deliver high-quality software to satisfy customers, boost sales, reduce support costs, and fo- cus on new product development. However, ensuring consistent quality and security from upstream developers is challenging, as many do not have formal requirements.

After implementing internal policies, imported components should be brought up to the same compliance level. Full com- pliance may take time, but an SBOM can serve as a to-do list to record compliance plans and progress. Collaboration is rec- ommended for small open-source software (OSS) components, either by forking them and integrating compliance within the product or by contributing improvements upstream.

Informal OSS components may struggle with maintenance commitments, but recent activity and defect handling can be used to extrapolate maintenance expectations or explore maintenance contracts. Balancing OSS and software supply chain security is an evolving practice requiring further details to be worked out.

When implementing supply chain security programs, IoT/OT device original equipment manufacturers (OEMs) should consid- er multiple factors, such as device design, manufacturing, pro- visioning processes, and the software supply chain. Conversely, operators must be conscious that working with suppliers who have not made adequate investments in quality and security exposes them to increased vulnerabilities.

PRIORITIZE YOUR SBOM PROJECT ACCORDING TO YOUR PRODUCT CRITICALITY

The urgency of evaluating supply chain security during the procurement process depends on the criticality of the applications involved. To initiate this assessment, it is advisable for operators to inquire about the supply chain, including the software sup- ply chain, from OEM suppliers using a Software Bill of Materials (SBOM). Additionally, it is important to ensure the integrity and quality of assets. While a comprehensive standard for IoT/ OT OEM certification does not currently exist, operators should establish their own criteria based on different aspects, such as device resilience against attacks, software asset integrity, confidentiality of device secrets, and controls over certificate chains of trust. When addressing security requirements in the software supply chain, it is advisable to articulate them in terms of measurable outcomes, like other requirements. Since the exact number of exploitable vulnerabilities cannot be determined, it is useful to rely on proxy measures such as code quality metrics, mean time to response, and adherence to best practices. For IoT/OT operators, it is important to choose or create a specific set of metrics that align with their needs, like the approach adopted by the US federal government through EO 14028.

An outlook to CSAF

Integrating the Cybersecurity Assurance Framework (CSAF) into supply chain security efforts adds an additional layer of robust- ness. CSAF provides a structured approach for assessing and enhancing cybersecurity practices across the supply chain. By leveraging CSAF, organizations can establish clear benchmarks for compliance and performance, facilitating smoother collabo- ration with suppliers.

This framework offers standardized language for discussing cybersecurity measures and ensures a more comprehensive evaluation of security posture. Implementing CSAF alongside SBOMs and other metrics can significantly strengthen the overall security posture of IoT/OT environments.

Moving forward, organizations should explore the synergies between CSAF and existing supply chain securi- ty strategies to establish a more resilient and secure ecosystem.

KEY TAKEAWAYS TO ACHIEVE EFFECTIVE & EFFICIENT SBOM MANAGEMENT:

• Centralize SBOM Management - Achieve comprehensive insight into your supply chain, third-party software, and in- house code throughout all components, products, and divi- sions.
• Simplify Compliance Procedures - Swiftly create, verify, and generate reports to effortlessly adhere to industry stand- ards, such as those set by the FDA, ISO, and other entities.
• Incorporate SBOM Creation into Current Workflows - Integrate smoothly with your existing systems like PLM, CI/CD, and software update mechanisms, while supporting all SBOM and VEX formats, including CycloneDX and SPDX, with capa- bilities for import and export.
• Go Beyond Basic SBOMs - Reveal all related risks extending beyond mere SBOMs, encompassing HW BOM, cryptography, passwords, PII, OS configurations, and more.
• Prioritize Security Research Over SBOM Verification - Avoid the expensive and labor-intensive process of manual audits, enabling you to allocate your time effectively towards mini- mizing risk and addressing crucial vulnerabilities.
• Be Audit-Ready - Ensure SBOMs are prepared for compliance and can be swiftly shared or exported, allowing you to concentrate on securing future endeavors.

Are you interested in further discussion with our security experts on how to achieve product cybersecurity compliance through effective and efficient SBOM management?

Please contact our security experts at: experts@onekey.com