Andrea Schaumann, Fortress’s director of federal programs and partnerships, gave a keynote address...
Seven Risk Areas Addressed by SBOMs
In the ever-evolving landscape of software development and cybersecurity, the software transparency benefits Software Bill of Materials (SBOM) cannot be overstated. This new tool serves as indispensable assets for evaluating software risks. When assessing software risks, it's imperative to cast a comprehensive net, covering an array of potential threats. In this article, we'll delve into seven critical risk areas, each integral to a holistic understanding of software risk and its mitigation.
Vulnerability – Severity, Exploitability, and Reachability
In order to determine the severity of potential vulnerabilities, each component of the software – including its international equivalents and private sources – should be evaluated against published vulnerability databases such as the National Vulnerability Database (NVD).
Vulnerabilities should then be evaluated for exploitability using sources such as CISA’s Known Exploited Vulnerabilities (KEV) catalog and the Forum of Incident Response and Security Team’s (FIRST) Exploit Prediction Scoring System (EPSS).
To reduce false positives caused by vulnerabilities that might be present but not reachable (due to inoperative functions or other reasons), reachability should be evaluated. Reachability is presently a challenge when evaluating third-party software, as automated methods are still in the early stages of development. Vulnerability Exploitability eXchange (VEX) is one solution a supplier can be use to indicate the status of a software or software component with respect to exportability (e.g., affected, not-affected, etc.) – since they can more easily determine reachability through analysis of their own source code.
Dependency – Obsolescence, Security, Reliability/Maintainability
Software should be built upon well-maintained code. The Linux Foundation estimates that 70%-90% of any given piece of modern software solutions utilize free and open-source software (FOSS) as a dependency10. FOSS should be evaluated for being up to date, how well it is being supported, if there are any known compromises or malware, the reputation of those contributing to it, the appropriateness of its code review practices, and that its upstream dependencies are also up to date.
In some cases, FOSS components are abandoned, causing significant concerns for downstream consumers. This issue has become so prevalent that there are now companies that broker transactions between FOSS communities and commercial software providers to ensure that FOSS is actively maintained.
Malware – Compromises, Malicious Maintainers
All components used should be evaluated for code contributions from a list of known or suspected malicious contributors, source code compromises, malicious packages, and build system compromises. The Open-Source Security Foundation’s (OpenSSF) Scorecard, for example, is one tool that the industry uses to evaluate risks in FOSS. Additional malware scans should be performed on the compiled software as well.
Integrity – Component Hash Validation
Most methods for identifying vulnerabilities rely on proper fingerprinting of software. If an SBOM includes a dependency but the hash value of the dependency does not match the source’s hash value, this means the code may have been altered, and there could be hidden risks such as malicious code or vulnerabilities.
Licensing – Compliance, Obligation Tracking
There are certain standard software licenses that bring obligations with them. Examples include the GNU General Public License (GPL) that requires any software that includes the license to also be made available under the same license, also known as copyleft. Mozilla Public License (MPL) allows for code modifications, as long as any code licensed under the MPL is kept in separate files and these files are distributed with the software. There are several other licenses with variations of these requirements. SBOM analysis tooling should indicate these obligations.
Foreign Presence – Influence from Adversaries
Through various U.S. Government publications, China, Cuba, Iran, North Korea, Russia, and Venezuela have been designated as foreign adversaries that “have engaged in a long-term pattern used should be evaluated for any potential influence from these adversaries. For example, reviewing code contributors, reviewing affiliations of commercial entities contributing to software dependencies.
Attestation for Secure Software Development – Governance
NIST SP 800-218, Secure Software Development Framework, was released on February 3, 2022, as a framework for developing secure software throughout five phases of development: planning, architecture & design, implementation, testing, and deployment & operations. By using this framework, software producers (and their customers) can expect their software to have a lower risk of vulnerabilities, increased security, and long-term security cost savings from applying a secure-by-design approach.
The Cybersecurity and Infrastructure Security Agency (CISA) is preparing a Secure Software Self-Attestation Common Form to be used by suppliers to attest that key practices of NIST SP 800-218 are being followed. In general, suppliers selling software to U.S. government agencies will be required to attest to these practices under Executive Order (EO) 14028 and subsequent Office of Management & Budget (OMB) Memo No. M-22-18 and OMB Memo No. M-23-16.