Preparing for the SBOM Tsunami
For years, the open source community has advocated for Software Bills of Material (SBOM). Briefly, an SBOM is a list of all the open source components included in an application or product. The benefit of an SBOM is clear:
For Software Developers: SBOMs provide development teams with visibility to vulnerabilities and potential risks for any open source components they are using.
For Software Consumers/Product Teams: SBOMs identify open source components and provide alerts on vulnerabilities in third party or externally developed software and binaries, allowing teams to effectively manage risk without necessarily needing access to source code.
For IT and Operational Technology: SBOMs complement vulnerability scanners by maintaining a continuous inventory of components and where they are used and vulnerability alerts for IT infrastructure, including cloud apps, and containers.
For Legal and Compliance: SBOMs maps open source components to their associated licenses to identify obligations and potential conflicts that might put Intellectual Property (IP) at risk.
In short, more SBOMs equals more transparency and less risk to teams building and consuming software.
Legal Requirements for SBOMs are Increasing
The open source community is not alone in their efforts, of course. Growing concerns about supply chain security have helped push legislative efforts.
United States Legislation
EO 14028
The 2020 SolarWinds attack prompted Executive Order (EO) 14028 “Improving the Nation’s Cybersecurity”. EO 14028 requires that organizations providing software to the US government “ensure its products are built and operate securely, and partner with the Federal Government to foster a more secure cyberspace”. Among the requirements is “providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website;”
Secure Software Development Framework (SSDF)
NIST Publication 800-218: Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. Organizations adhering to 800-218 must follow several practices, including:
· “Collect, maintain, and share provenance data for all components and other dependencies of each software release (e.g., in a software bill of materials [SBOM]).” (PS.3.2)
· Obtain provenance information (e.g., SBOM, source composition analysis) for each software component, and analyze that information to better assess the risk that the component may introduce. (PW.4.1)
Food and Drug Administration
Following the disclosure of several vulnerabilities in medical devices, in 2022 Congress amended the Federal Food, Drug, and Cosmetic Act (FD&C Act) to add section 524B, Ensuring Cybersecurity of Devices. Per the Act, premarket submissions for a cyber device must include:
· “A plan to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures;
· Design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure, and make available postmarket updates and patches to the device and related systems; and
· A software bill of materials, including commercial, open-source, and off-the-shelf software components.”
European Legislation
Cyber Resilience Act (CRA)
The CRA was proposed in 2022 and is expected to
enter into force in 2024. Its goals are to ensure that
“products with digital elements” (PDE) are delivered
to customers with fewer vulnerabilities, require
manufacturers to monitor and help customers
manage the security of PDE throughout the product’s
lifecycle, and inform consumers during the buying
process of PDE about the security measures taken by
manufacturers.
Annex I of the CRA describes the “Essential
Cybersecurity Requirements” organizations must
follow to ensure that cybersecurity is considered in
the planning, design, development or production,
testing and maintenance of the PDE. These include
documentation of all cybersecurity risks, a Software
Bill of Materials (SBOM) listing all open source
components, and continuous monitoring and reporting of new and actively exploited vulnerabilities for the life of the product.
Asian Legislation
Republic of Korea: SW Supply Chain Security Guidelines
The Guidelines are part of a government-wide response to attacks on software supply chains. They were published by The Ministry of Science and ICT, the National Intelligence Service, the Digital Platform Government Committee (Diffle Committee), and the Korea Internet & Security Agency (KISA).
Japan: Guide to Implementing the Software Bill of Materials (SBOM) for Software Management
In 2023, the Japan Ministry of Economy, Trade and Industry (METI) published A Guide to Implementing the Software Bill of Materials (SBOM) for Software Management. The guide (English, Japanese) is divided into three phases.
o Phase 1: Environment and system development – During phase 1 organizations can familiarize themselves with the requirements and learn how to select and use SBOM tools.
o Phase 2: SBOM production and sharing – Phase 2 focuses on becoming proficient at scanning applications to generate SBOMs in formats that can be used internally and externally.
o Phase 3: SBOM use and management – In phase 3, teams use SBOM tools in production to manage security and license risk. This includes “evaluating severity, assessing impact, fixing vulnerabilities, and confirming residual risk”.
A Tsunami of SBOMs
Organizations today use Software Composition Analysis (SCA) tools to generate SBOMs for the applications they build in-house and mitigate security and license risk. Rarely do they need to manage 3rd or 4th party SBOMs from suppliers (or suppliers to suppliers).
This is about to change. The changing legislative landscape holds the potential to inundate organizations with hundreds or thousands of SBOMs from vendors and partners.
Challenges in Managing 3rd Party SBOMs
Security and risk management teams must prepare for a world where they receive SBOMs from any entity providing them with software or products containing software. This raises several challenges:
Inability to validate SBOMs: Suppliers that choose to manually compile an SBOM or use open source tools will likely miss critical components.
No access to source code: Vendors are unlikely to provide source code for organizations to build independent SBOMs for applications and products.
No standard vulnerability and license data source: Software vendors may use manual lookups or not update SBOMs when new vulnerabilities are disclosed, leaving software users exposed.
No visibility to policies: While organizations that build software may have policies for what open source licenses and security standards are required, 3rd parties (and their 4th party suppliers) will be unlikely to publish that information.
Best Practices for Managing 3rd Party SBOMs
Managing security and license risk across hundreds or thousands of 3rd party SBOMs can be simplified by following four best practices.
1. Centrally Manage All SBOMs
This step is simple. Managing dozens or hundreds of SBOMs manually or in a homegrown database is not a sustainable solution. Instead, look for an SBOM solution that serves as a single repository for all internally and externally generated bills of material. Be sure that all component identifiers, severity scores, and license or security data comes from a reliable source.
2. Maintain SBOMs for Your Entire Attack Surface
Web facing applications and IT infrastructure are likely an organization’s dominant attack surface. Vulnerable open source components in device firmware, applications, and IT infrastructure present criminals with a simple attack vector for gaining a foothold. From there, they can move laterally, escalate privileges, and execute attacks such as ransomware, advanced persistent threats, and data theft.
Generating an SBOM does not necessarily require access to source code. Some Binary Software Composition Analysis (SCA) allows teams to create SBOMs without accessing source code and without violating software license agreements.
It is important to include your organization’s IT infrastructure (that often bypasses a formal SDLC). Some Binary SCA solutions can generate SBOMs automatically and map components to license and vulnerability databases. This complements vulnerability scanning solutions to provide teams with up to date information on where vulnerable components are present, allowing for prioritized scanning to confirm exploitability.
3. Verify critical 3rd Party SBOMs
Not all applications and products present the same risks to an organization. Critical systems – even those for which a vendor-supplied SBOM exists – should be verified using binary SCA. Binary SCA allows teams to generate comprehensive SBOMs for these applications and product firmware without reverse engineering techniques that would violate license agreements.
For example, the graphic below shows an SBOM for the latest firmware releases of three popular wireless routers. Each of the firmware releases had over 1,000 security vulnerabilities associated with the open source components used in the firmware, including dozens with publicly available exploits.
Providing visibility to risk in critical systems, IT and security teams are better able to make smart choices, whether that entails vendor selection or compensating controls to mitigate risk
4. SBOM Data Must Be Actionable
Having a list of open source components for each application and device in your environment is useless without timely, actionable data on risk. This includes accurate license and vulnerability data from reliable sources such as the US National Vulnerability Database (NVD), Japan Vulnerability Notes (JVN), and the Chinese National Vulnerability Database (CNVD).
Information to look for includes:
Prioritization: Understand which systems are most critical to your organization’s goals. A vulnerability with a severity score of 7 in an online banking application will likely be more critical than a vulnerability with a severity score of 10 in an internal application. Further, look to see if an exploit has been published for the vulnerability. A publicly available exploit makes an attack much simpler and therefore increases the potential threat actors to include “script kiddies”.
Scoring: Most organizations measure and prioritize risk on critical assets using the Common Vulnerability Scoring System (CVSS). This qualitatively measures risk severity using a variety of factors categorized as base, temporal, and environmental metrics. Look for an SBOM management solution that will normalize scoring across all SBOMs.
The base score characterizes the vulnerability. This score weighs factors such as the attack vector, required privileges to exploit the vulnerability, and the impact of the confidentiality, integrity, and availability of systems in the event of a successful exploit. The temporal score represents the vulnerability’s changing urgency over time, including the maturity and availability of exploit code and patches or workarounds to mitigate risk. The environmental score represents the impact potential on an organization. These apply to the specific environment in which a vulnerability exists and are unique to each organization.
Exploitability: Remember that the presence of a vulnerability in a component does not necessarily represent an exploitable issue. To be exploitable, an attacker must be able to reach a vulnerability. For example, if the vulnerable code is not present it is (obviously) not reachable. At times, developers will use modified or partial components. A binary SCA tool that analyzes code “as deployed” can minimize false positives and unnecessary rework by confirming the presence or absence of the vulnerable piece of code.
Remediation Guidance: Often, the vulnerable component can be years old. Simply upgrading to fix the reported vulnerability may result in using a version of the component with far more vulnerabilities. Look for a solution that provides information on the security profile of all versions of a component.
Binary SCA is Better
Most organizations generate SBOMs using source-based approaches to SCA that can lead to inaccurate results. Let’s look briefly at the different approaches solutions can take to generate an SBOM:
Package Manager Parsing: Most Software Composition Analysis tools simply parse a package manager or build file to generate a list of open source dependencies. While this is rapid, it may misidentify ambiguous version requests, miss components that are compiled directly into an application by developers, and cannot be used for programming languages that do not support package managers like C and C++.
Hash Matching: Other, more sophisticated SCA solutions may use hash matching; generating hashes for source or binaries and comparing those to pre-compiled databases of common open source components. While this can identify some components missed by parsing the package manager, hash based matching may also be ineffective in some use cases. This is because an almost infinite number of compiled binaries can be produced from a single source depending on the options used for the compilation process.
Binary Analysis
In addition to using the package manager and hash matching, Insignary Clarity is unique in that it scans for “fingerprints” of open source components to identify code elements that survive the compilation process unchanged such as string literals, function, and variable names. It compares those against the fingerprint database created from open source components in numerous open source repositories.
The fingerprints are used for matching open source components where hash based matching may be ineffective. For example, in the embedded Linux space, there are almost no standard repositories for reusable binary components which makes it difficult to obtain hash values for comparison.
Be Prepared With Insignary Clarity
Soon, managing internal and third-party SBOMs will be part of every organization’s responsibility. This will require the ability to produce SBOMs for internal projects and IT infrastructure, validate SBOMs from vendors and partners, and track license and security risks.
Insignary Clarity is a Binary SCA solution that simplifies life for security, development, and risk management teams. It provides a single solution to generate, validate, and manage internal and external SBOMs. Clarity identifies open source components in source code and binaries, maps those components to license and security risk, and provides clear remediation guidance.