Last month, the Enduring Security Framework (ESF), a working group that includes representatives from multiple U.S. government agencies (NSA, ODNI, and CISA) along with private sector partners, released a new document designed to help organizations jumpstart their SBOM programs and effectively manage risks related to open source software.
“Securing the Software Supply Chain: Recommended Practices for Managing Open-Source Software and Software Bill of Materials” includes a range of guidance for both software developers and consumers. The report has four main sections:
- Open Source Software Management
- Creating and Maintaining a Company Internal Secure Open Source Repository
- Maintenance, Support, and Crisis Management
- SBOM Creation, Validation, and Artifacts
The document builds on the U.S. federal government’s landmark 2021 cybersecurity executive order and the ESF’s software supply chain security best practices guides, which you can find at the bottom of this press release.
In this blog, we’ll highlight four of our primary takeaways from the new OSS and SBOM management document, along with an analysis of why we think each is important. Please note that we don’t intend this article to be a comprehensive overview of the ESF’s recommendations; rather, we’re highlighting a few sections and takeaways that we view as particularly relevant to FOSSA users.
1. License Compliance is a Mission-Critical Part of Effective Open Source Management
As the report notes (in Section 5.1.2), SBOMs were conceived with open source license compliance as a primary use case. In fact, the SPDX bill of materials specification was originally announced as part of the Linux Foundation’s Open Compliance Program. Today, of course, many organizations utilize SBOMs for security and regulatory compliance reasons, but this shift hasn’t reduced the importance of open source license compliance.
On the contrary, enterprises of all types continue to rely heavily on open source to fuel application development, and organizations need to have a plan in place to maintain an inventory of their licenses and continuous compliance with licensing requirements — or risk the legal, reputational, and financial exposure that can come with non-compliance.
The report does highlight (Section 2.2.1) that managing compliance activities “may be a lot for individual programmers to track” (given the large volume of open source in most applications), but “organizations can provide tools to make this consideration easy or transparent for the humans at keyboards.”
Our view is that automating license scanning and detection, attribution notice creation, and the implementation of license approve/deny policies are among the most important activities for enabling compliance at scale.
2. Customize SBOMs for Your Use Cases and Consumers
There are a lot of factors that contribute to SBOM usability. For starters, a high-quality SBOM needs to have accurate and up-to-date information, and it should include sufficient metadata to comprehensively describe the component. (The NTIA’s minimum required elements are a good place to start.)
But, as the report notes in Section 2.4, in cases where you intend your SBOM to be ingested by a third party, it’s also important that “care should be taken to ensure SBOMs are provided in a format that can be processed by their consumers without the loss of integrity…”
Section 5.1.1 echoes that guidance: “When creating an SBOM, consideration should be given on who is going to consume the SBOM and what formats are acceptable.”
In practice, the focus on making SBOMs usable for consumers starts with generating your SBOM in a machine-readable format (SPDX or CycloneDX).
Another important consideration is customizing SBOM metadata to support its primary use case. For example, if you are producing an SBOM for a government agency, you must include the NTIA-required elements. If the SBOM consumer is an organization preparing for technical due diligence, you should include licensing fields. If security is a consideration, consider embedding (or linking to) VEX (Vulnerability Exploitability eXchange) documents with accurate state and justifications. And so on and so forth.
The big-picture takeaway is that there’s no single SBOM format or standardized set of data fields that will be most useful to 100% of consumers, so it’s important to gather that information before generating and transmitting your bill of materials.
3. Go Beyond CVSS Scores to Prioritize Vulnerabilities
Traditionally, CVSS (Common Vulnerability Scoring System) has been the go-to for assessing and prioritizing open source vulnerabilities. The idea was that the higher the CVSS score, the greater the risk and the more urgent the remediation.
However, CVSS isn’t the be-all, end-all. Although it communicates vulnerability severity, it doesn’t account for direct or indirect exploitability. Just because a vulnerability could have devastating effects doesn’t mean it’s actually likely to be exploited or is even accessible given the context of the vulnerable application. This is why relying too heavily on CVSS can lead to false positives and overload security teams with CVE alerts.
So, while CVSS is still an important part of vulnerability management programs, it’s best to include other inputs as well. Section 3.2 of the report highlights other frameworks worth using, such as the EPSS Scoring System; EPSS measures how likely it is that a specific vulnerability will be exploited in the wild, a dynamic determination given the persistence and ingenuity of threat actors.
4. Start Thinking About VEX
VEX (short for Vulnerability Exploitability eXchange) is the subject of frequent discussion in the report — it’s mentioned 61 times in total. Similar to EPSS, VEX is a potentially valuable tool in helping organizations understand whether vulnerabilities in their software are actually exploitable. However, VEX and EPSS differ in that VEX data is provided by the software supplier and based on internal inputs, while EPSS is a data model based on external factors.
As such, VEX holds particular promise in helping SBOM consumers understand the security risks they’re inheriting from software suppliers. In other words, VEX could be key to unlocking many mission-critical SBOM security use cases.
In a VEX document, the software supplier will annotate a particular vulnerability with information to help the consumer understand exploitability. VEX data fields include whether a product is affected by a vulnerability (“Status or State”), why the product is or isn’t affected (“Justification”), a detailed response to contextualize the justification (“Description”), and how to mitigate the vulnerability if the product is affected (“Recommendation”), among others.
The ESF guidance explains (Section 5.1.3) that “VEX provides additional context which may reduce the number of ‘false positive’ vulnerabilities that a vulnerability scanning (tool) would report against an SBOM due to the specific package instance.”
One of the challenges organizations seeking to adopt VEX currently face is that, as a relatively new standard, there’s still work to be done around standardization (e.g. which data fields to include in a VEX document) and automation (e.g. given the complex nature of modern applications, managing VEX with manual processes isn’t scalable).
Despite these current barriers, it’s increasingly clear that security teams will be well served to start thinking about how to integrate VEX into their SBOMs (and develop processes for requesting suppliers to do the same).
Section 5.1.3 of the report includes an example of how this might be done.
ESF Recommendations: The Bottom Line
The ESF’s report is a timely document that deals with several challenging and complex areas related to managing SBOMs and reducing the risks that can come from using open source software. I hope this article gives FOSSA users (and open source management/SBOM teams) a feel for the report and its focus areas, but I do encourage you to consider reviewing the document for a deeper dive.
Additionally, for more insights on these topics, consider checking out the following on-demand webinars:
