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

THE CHANGING LANDSCAPE OF SOFTWARE SUPPLY CHAINS: SBOMS AND THEIR CHALLENGES

CYBERSECURITY INCIDENTS SHOW NEED OF SBOM

‍The significance of SBOMs considering recent cybersecurity incidents

The importance of Software Bills of Materials (SBOMs) has been underscored by two significant cybersecurity incidents. In August 2021, ONEKEY’s advisory highlighted severe vulnerabilities in Realtek’s SDK, affecting a wide range and hundreds of thousands of IoT devices. These vulnerabilities, stemming from lax security practices, continue to persist in many customer premise products, as revealed by Palo Alto in early 2023. This underscores the urgent need for Supply Chain Bill of Materials (SBOMs), providing transparency and accountability in software production and distribution. SBOMs play a pivotal role in identifying and rectifying vulnerabilities before they reach end-users, fortifying the security of IoT ecosystems.

Another incident occurred in November 2021 when Chen Zhao Jun, a security analyst at Alibaba Cloud Services, reported a critical vulnerability in the widely used Java logging library Log4j to the Apache Foundation. This vulnerability, known as Log4Shell(CVE-2021-44228), triggered a global crisis. Despite prompt fixes being released after Apache’s public announcement, Log4Shell was swiftly and extensively exploited. IT organizations faced challenges in identifying whether their suppliers had incorporated Log4j into their products, impeding mitigation efforts. Soft-ware vendors were inundated with inquiries and had to search for Log4j in their own products while rushing to release successive fixes. In many cases, they had to rely on their suppliers for patches from upstream sources. Consequently, numerous organizations remained unaware of the danger and took no action.

These incidents highlighted two crucial lessons: accidental vulnerabilities can have devastating consequences comparable to supply chain attacks, and managing exposure to both types of risks is challenging in modern extended software supply chains.

VULNERABILITIES COULD BE WEAPONIZED

Additionally, these incidents raised concerns about the potential mis-use of vulnerabilities if disclosures were not made publicly, as exemplified by the possibility that Log4Shell could have been covertly weaponized if exclusively disclosed to the Chinese authorities, as mandated by a recent Chinese law. The repercussions of these events have significantly drawn the attention of regulators to the critical nature of software supply chains.‍

RE-USING COMPONENT SHAVE INCREASED PRODUCTIVITY

‍The pervasive challenges of software component integration in modern development‍

In modern software development practices, there is a strong emphasis on integrating existing software components rather than starting
from scratch. This approach involves combining a smaller amount of new code with numerous pre-existing components, including proprietary and open-source libraries and services. The ability to reuse these software components has greatly advanced the abstraction, sharing, and consumption of such components, resulting in significant improvements in developer productivity.

The IoT revolution has effectively capitalized on the availability of highly reusable embedded and cloud software platforms. These platforms integrate solutions for various design challenges at a low cost, enabling the widespread adoption of connected embedded systems.

Many of these systems utilize an “IoT OS,” or embedded OS, often in the form of reference code from the microcontroller vendor, along with additional imported code such as peripheral drivers, board support packages, and application-specific libraries. In numerous cases, this imported code comprises the majority, ranging from 90% to 99%of the overall codebase. This approach has substantially reduced the costs associated with IoT/OT device development.

Importing software components has become such a commonplace and effortless practice that many projects incorporate them without much consideration, even though these components often come with numerous dependencies. Anything that aids project advancement is readily adopted. However, as this practice has become more prevalent, three significant problems have emerged.influence over the actions of their suppliers.

First, organizations that heavily rely on externally developed components surrender control over the quality and security of their own soft-ware. While they may implement cutting-edge quality techniques in their own projects, they have limited.

Furthermore, they may have limited visibility into the entire supply chain beyond their immediate suppliers.

The second challenge lies in keeping up with issues and security updates across a diverse range of externally maintained components. Software vendors must promptly assess, and address security notifications related to these components, as any vulnerability can expose customers to attacks.However, effectively managing this task is notoriously difficult. Even organizations that excel in this area often depend on their suppliers to do the same.

The third challenge arises when utilizing externally developed software that is provided under multiple copyright licenses. It is easy to lose track of the cumulative terms associated with these licenses and inadvertently become non-compliant.

Although not directly related to cybersecurity, non-compliance poses a risk of disruption due to potential litigation by copyright holders. As a result, corporate legal departments have begun to pay attention to this issue.

While the integration of software components offers benefits in terms of productivity and cost savings, it also presents notable challenges in ensuring quality, security, and compliance throughout the supply chain.Addressing these challenges requires organizations to prioritize soft-ware supply chain management, implement robust security practices, and establish effective communication and collaboration with suppliers.

Understanding the role and challenges of SBOMs in supply chain risk management

While Software Bills of Materials (SBOMs) have gained significant attention, it’s essential to recognize that they are not a standalone solution for supply chain risks. Instead, SBOMs enable effective solutions by providing a comprehensive list of software components.

Cybersecurity tools, processes, and policies become more impactful and less prone to blind spots when applied systematically against a diligently maintained SBOM. Therefore, the focus should be on implementing the broader set of solutions rather than solely relying on SBOMs.

It is crucial to appreciate that generating a usable SBOM is more challenging than it may seem. A well-designed SBOM needs to identify software components universally and unambiguously. It should include additional information such as dependency relationships, maintainers, and licenses, all in a standardized and widely shareable format.

Moreover, it should strive for completeness across various types of components and be continuously updated to reflect changes in the software it documents. Ideally, each software component should document its own dependencies, facilitating the creation of a comprehensive SBOM.

It’s worth noting that SBOMs are not entirely new. Many maintainers of IoT/OT libraries and devices already employ some form of software inventory to address these challenges or build their applications.

Furthermore, several vendors possess the capability to automatically generate reasonably high-quality SBOMs, even if they are not currently utilizing them. What’s novel is the grow- ing interest, driven by regulatory initiatives, in elevating supply chain security. This includes the standardization and communication of SBOMs throughout supply chains, along with heightened expectations for their effective utilization.

In the following sections, we will outline the essential components and main standards for SBOMs. We will also discuss how IoT/OT vendors should generate and share SBOMs, as well as how all stakeholders in the IoT/OT supply chain can utilize SBOMs effectively to mitigate cyber risks for IoT/OT operators.

The ONEKEY Product Cybersecurity & Compliance Platform (PCCP) enable manufacturer to automate their product security management from design to end-of-life, throughout the entire product lifecycle:

ONEKEY’s unique & proprietary binary ex-traction technology enables a deeper & more precise analysis of the binary firmware image without the need for source code. ONEKEY automatically generates a detailed SBOM, including software dependencies at all levels of the firmware.

Next, based on artificial intelligence and ma-chine learning, ONEKEY uses a natural language processing (NLP) approach to de-termine whether there are publicly known vulnerabilities affecting this software ver-sion. In addition, ONEKEY’s AI/ML-based approach automatically analyses the pre-conditions for exploitability of the vulnerabilities. In an integrated, automated impact assessment, the target device is analyzed if the prerequisites for exploitability are met, filtering out non-relevant vulnerabilities. This unique approach shortens response times by significantly reducing manual impact assessment and allowing development & ProductSecurity Incident Response Teams (PSIRT)to focus on the truly relevant vulnerabilities.‍

The ONEKEY Product Cybersecurity & Compliance Platform (PCCP) provides SBOMs on the fly - ready for export, in CycloneDX or other formats.

ONEKEY can generate an SBOM simply from a binary firmware image. The SBOM can be exported both in machine readable (i.e., Cy-cloneDX, SPDX) or human readable formats (CSV, EXCEL) to make them available to other systems, end users, and regulatory bodies.ONEKEY‘s firmware monitoring analyses the target product daily for new zero-day vulnerabilities or known vulnerabilities and performs automatic AI/ML-based impact assessments for all identified vulnerabilities. This enables manufacturers to react to new vulnerabilities in the shortest possible time and to create and distribute security patches.

Analysis and monitoring for automated security due diligence of third-party components- simply set up ONEKEY as a quality gate for any third-party component or product.

UNDERSTANDING SBOM CONTENT AND RELATED CHALLENGES

NTIA'S MINIMUM REQUIREMENT FOR SBOMS

The National Telecommunications and Information Administration (NTIA) in the United States has made significant contributions to the understanding of SBOMs. According to the NTIA, the primary purpose of an SBOM is to identify components and their relationships uniquely and unambiguously3. For this purpose, the minimum required data elements4 include the supplier, component name, component version, other unique identifiers, depend- ency relationships, author of SBOM data, and timestamp5. In addition to these minimum elements, an SBOM may also include additional data elements, such as SPDX license short ID and/or license text, depending on the specific needs and preferences of the stakeholders involved.

IDENTIFIERS ARE BENEFICIAL FOR EFFECTIVE VULNERABILITY SEARCHES

One crucial application of Software Bill of Materials (SBOMs) is the identification of vulnerabilities from databases. To enable efficient vulnerability searches, it is beneficial for an SBOM to incorporate identifiers that correspond to components within those databases. For instance, the United States‘ National Vulnerability Database (NVD) employs Common Platform Enumerations (CPEs) as identifiers6. Initially, CPEs were assigned to components when vulnerabilities were first reported, which posed challenges for setting up proactive automated searches. Howev- er, one possible solution is for library and device maintainers to pre-register a CPE.7 Nonetheless, it is anticipated that NVD might phase out CPEs in favor of Software IDentification (SWID) tags.8

A recommended approach is to locally generate a SWID and derive a CPE9 from it, incorporating both as unique identifiers
in SBOMs shared with customers. Subsequently, the CPE name, SWID, or both can be registered in the NVD or any other relevant vulnerability database as required. However, the NTIA recognizes the impracticality of establishing a global naming scheme and suggests that software and device maintainers define and con- sistently employ unambiguous supplier, component, and version names. Ideally, these names should be supplemented with hash- es, UUIDs, or other unique identifiers.

In cases where the original supplier of a component has not provided their preferred component names in an SBOM, down- stream integrators are allowed to make an educated guess and document this fact using the „Author of SBOM Data“ element.
In the following sections, we will delve deeper into the main SBOM standards, discuss how IoT/OT vendors can generate and share SBOMs, and explore how stakeholders in the IoT/OT supply chain can effectively utilize SBOMs to reduce cyber risks for IoT/ OT operators.

FOUR POTENTIAL SOURCES FOR INFORMATION

Streamlining SBOM Generation in CI/CD Pipelines: Automation and Information Sources

‍
Automating the generation of Software Bills of Materials (SBOMs) in continuous integration/continuous deployment (CI/ CD) pipelines is crucial. There are four potential sources of information for SBOM generation, each with its own tools and advantages.

1. Package managers: Commonly used package managers such as pip, Maven, npm, and Cargo can list dependencies and provide valuable information for generating an SBOM. Even in embedded C/C++ environments where package management is less com- mon, build systems like Cmake or utilities such as Zephyr pro- ject‘s West can be leveraged.
2. Source code scanning: Source code analysis tools and scripting can efficiently identify dependencies, linked libraries, and embedded code. Commercial source code analysis (SCA) tools can also detect copy-pasted code snippets. While this approach requires initial setup and ongoing maintenance, it is highly effective and easily automated in CI/CD pipelines.
3. Binary analysis: Binaries can be analyzed to extract SBOM information when source code is not available. Reverse-engineer- ing tools can extract symbol names and strings from ELF files and object files but resolving them into component identities
   is challenging. Specialized analysis approaches are needed for different types of executable files, microcontroller and Linux disk images, patch files, packages, and over-the-air update wrappers.
4. SBOM documentation from the supply chain: SBOMs can be generated by each participant in the supply chain, utilizing original metadata, sources, and upstream SBOM documentation. Sharing SBOMs downstream can provide a completer and more accurate device SBOM, overcoming limitations in single-source visibility. However, the practice of comprehensive SBOM documentation is still evolving, and it is common for projects to lack SBOMs for all imported components.

Automating the generation and sharing of SBOMs requires investment in time and effort, but the availability of tooling has made the process easier. The level of effort scales with the project size and complexity. Smaller IoT library developers can add a command to their release script, while larger embedded projects may require several engineer-months of detective work, consolidation of information sources, transformation into a standard format, and automation. The positive benefits of automating SBOM generation justify the effort in both cases.

CONCERNS REGARDING SECURITY INFO IN SBOMS?

Sharing SBOMs: Advantages for Defenders Outweighing Security Concerns

Sharing SBOMs downstream should be automated and done consistently using a small number of recommended methods10 for different types of components.
Concerns may arise regarding the security sensitivity of SBOMs, especially for binaries and device images. Could access to a device SBOM assist attackers in identifying imported vulnerabili- ties, exploiting them, or planning supply chain attacks?
While transparency does present some risks, it is crucial to understand that SBOMs primarily benefit defenders rather than attackers. Attackers do not necessarily require an SBOM to find vulnerabilities; they often target unpatched vulnerabilities they are already aware of. Defenders, on the other hand, can leverage SBOMs as a systematic defense against software supply chain risks. Even organizations that distribute SBOMs only to their customers do not view disclosure as a disaster and do not seek to further secure them.
In summary, sharing SBOMs provides significant advantages for defenders in addressing software supply chain risks, and con- cerns about attackers leveraging SBOMs are outweighed by the benefits they bring to defense efforts.

THE TWO LEADING SBOM STANDARD FORMATS

Standardizing SBOMs: CycloneDX and SPDX

To facilitate sharing and encourage the development of inter- operable tools and services, the adoption of SBOM (Software Bill of Materials) standards is essential. Embracing one of these standards simplifies the generation, utilization, and sharing of SBOMs while reducing costs. A comprehensive review of current standards has been published by the NTIA 11.

The two leading standards in this field are CycloneDX and the Software Product Data Exchange (SPDX). CycloneDX originat- ed in the OWASP information security community, while SPDX emerged from the OSS community. Although SWID tags have also been considered, their primary use case is to provide unique and unambiguous identifiers for software components.

The original purpose of SPDX is to ensure license compliance. It is maintained by a working group within the Linux Founda- tion. The initial draft was introduced in 2010, and the current specification is freely available as the ISO/IEC standard ISO/ IEC 5962:2021 12. Ongoing development progress can be tracked through the group‘s public GitHub repository.

CycloneDX, on the other hand, was initially developed to address vulnerability identification, license compliance, and outdated component analysis. It follows an open governance model. The first draft specification was introduced in 2017, and the standard has now reached version 1.4. Both standards have undergone extensive use, resulting in their maturity. They boast active communities and are continuously being developed.

RICH SBOMS ARE THE BEST

They strive to support all SBOM use cases and enjoy broad support from various compatible tools. Many tools even offer support for both standards. However, neither of them provides specific advantages for embedded projects.
SBOM Completeness: Challenges and Considerations
The usefulness of an SBOM (Software Bill of Materials) increases with its accuracy, level of detail, and completeness. However, it is important to acknowledge that SBOMs are rarely able to achieve all these attributes, and objectively measuring their quality can be challenging.
An internal effort to generate an SBOM may provide some metrics, such as the fraction of attributed code artifacts or the number of identified components with detected incompatible licenses. However, these metrics may overlook significant sets of components, including „unknown unknowns“ that have not been considered yet.
Even non-embedded software projects face difficulties in identifying and documenting software components of various types and layers, such as binaries, source code, package-managed and non-package-managed components, containerized applications, static and dynamic libraries.

IOT DEVICES HAVE ADDITIONAL CHALLENGES

IoT devices present additional challenges, as they encompass the entire stack from bare metal boot and often include deep- ly embedded firmware in network interface controllers (NICs), secure elements, and other integrated circuits. Creating a de- liberate and meticulous inventory of opaque and „hidden“ soft- ware components is the only way to transform them into „known unknowns.“

When an upstream supplier provides an SBOM to downstream consumers, there is no easy way to ensure that it meets their standards. Currently, no standard or certification scheme exists for this purpose. Some consumers generate and analyze SBOMs themselves using their own Software Composition Anal- ysis (SCA) tools, which can motivate suppliers to improve their SBOMs. However, consumers still rely on suppliers for interpretation, and for many, the effort required may not be justifiable.

Ultimately, it is important to remember that even an incomplete SBOM is better than having no SBOM at all. While the use of SBOMs can significantly reduce compliance issues and known vulnerabilities, it is unlikely to eliminate them.

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