SBOMs Critical to Software Supply Chain Security

By Deb Radcliff, DevSecOps analyst and editor of CodeSecure’s TalkSecure educational content (syndicated at Security Boulevard & YouTube)

LAS VEGAS – One day before the Black Hat Briefings started in Vegas last week, a group of experts met at the Wynn Las Vegas to talk about SBOMs (software bills of materials) during the Software Supply Chain Security Summit hosted by Lineaje. Despite that the summit came together somewhat last-minute, the content and speakers were top notch. 

Software ingredients: a lesson from Twinkies

Think of SBOMs as an ingredient list of all the code components included in a software product along with information about those components, including the producers, component name, version, unique identifiers, dependency information, the author of the SBOM, timestamps to authenticate where it came from, and more. (See my interview with Alicia Bond: How much data do you need in your SBOM?)

Allan Friedman, father of the SBOM, humorously described the purpose of an SBOM this way: “Think of what’s in those non-biodegradable Twinkies. Did you know that a key ingredient is cow fat? That’s something people with sensitive diets should know, just like we should know what’s in our software.” 

Tracking what’s in critical infrastructure software is a necessary first step, Friedman continued. And now that SBOM generation and standards for sharing and reading SBOM data are maturing, development teams and buying organizations need to turn that data into “actionable intelligence,”  Friedman continued. With the right intelligence, product teams can determine whether to use, keep, create a workaround, or replace a component, for example. And enterprises need the data to determine pretty much the same by comparing SBOM data against their unique risk and compliance profiles. 

Breaking down silos to support legacy systems

Friedman used an example of a power company that wanted to find and track all its software elements down to its subsystems. This took months to inventory and assess. He added, “We need to make this easier on operations like power and medical systems that are reliant on legacy code.”

But, in the case of legacy systems and unmanaged open-source components, the developers behind them are long gone. 

“When you’re talking about MedTech and other legacy systems, you’re usually doing your own QA on these types of vendor appliances where vulnerability remediation is outside the developer workflow,” said Jefferson Jones, solutions architect at GitLab. “How do you open these silos?” The good news, he added, is that SBOM programs are pushing product companies—and enterprise buyers—further into ‘discoverability.”

Discovery, a component of asset management, covers a broad swath of cyber activities across security and risk management teams that work in their respective silos, starting with finding all apps used by the enterprise (and those that should be retired), assessing them for vulnerabilities, and mapping their interdependences.

“Asset management is the core risk management component for enterprises, yet all their supply chain data is kept with the individual teams,” explained Cassie Crossley, VP of Supply Chain Security at Schneider Electric and author of the seminal book on software supply chain security for software, firmware, and hardware. 

“At Schneider, our core priority is centralizing asset management. We categorize suppliers based on risk criticality into high, medium, and low priority vendors,” Crossley added. “And everything we put in our products goes through testing and assessment based on the risk levels we’ve assigned.”

Assessing what you know and what you don’t know

Enterprise risk assessments usually involve red team, blue team, purple team penetration-type testing, and/or DAST (Dynamic Analysis Security Testing) to identify risks in applications that enterprises don’t have the source code for. Organizations that own their source code also test with SAST (Static Analysis Security Testing), a tool development teams have long used. 

In the case of legacy enterprise and third-party code where developers and enterprises don’t have access to the source, development teams and product buyers need to utilize Binary Composition Analysis (BCA), preferably using tools that automatically generate SBOMs from binary. But once SBOMs are generated, it also means keeping SBOMs up to date and searchable, and this is where third party SBOM lifecycle management platforms, such as Lineaje, come in.

Throughout the presentations, speakers pointed to the need for more automation, ownership, and centralized management around SBOMs.

Automate what you can, but be sure to support the development process with continuous developer training in addition to advanced workflow tools, added John Mark Walker, founding CEO and director of Fannie Mae’s Open-Source Program Office. “Developers don’t want to change the way they work, so training developers to keep their dependencies and run times up to date is critical.”

SBOM integration with workflow automation will solve some of these SBOM generation and usage problems, particularly on the product developer side. That automation should also enhance training and nurturing of security champions in the DevOps team. As Chitra Elango, senior cyber security and DevSecOps director at Fannie Mae puts it, “You can train developers to be security experts, but you can’t train security experts to be developers.”

Crawling up the SBOM maturity curve 

Taken together, the summit speakers provided a glimpse into the SBOM maturity curve as applied to the source, build, deploy, sell and buy cycles based on many factors, including (but not limited to) the following: 

Workflow integration along the CI/CD pipeline 
Lifetime support of SBOMs, especially as the code base changes
Cross-platform usability with interoperable data expression regardless of format (SPDX and CycloneDX)
Connection to searchable vulnerability databases like the CVEs and VEX
Searchability through large volumes of SBOM data
Prioritization based on actual risk to the product or its users (reducing false positives and false negatives)
Fluidity to expand with new data expression requirements and support continuous changes across all components and libraries included in the code
Support for operational risk management and response as software customers require

The rosiest outlook puts product companies on the lower upslope of the maturity curve—at least those product companies that are generating SBOMs with minimum required data in machine-readable format. SBOM maturity for legacy, third-party, and open-source code, on the other hand, is just getting started. Additionally, SBOM usage, particularly for buyers and security tools platforms, has a long way to go.

Frameworks and standards

In the best solutions-oriented session at the summit, Robert Martin, senior principal engineer at MITRE, showcased the MITRE System of Trust. Similar to the MITRE ATT&CK Framework, the  System of Trust Framework aims to provide a comprehensive, consistent, and repeatable supply chain security risk assessment framework based on actual threat levels. And, that which is repeatable can also be automated.


(Source: MITRE SOT homepage)


In his session, Martin laid out the complex web of risk categories, groupings, factors and measurements that go into these assessments. “It all starts with model-based system engineering, architectural design and analysis,” he noted. 

The framework also covers standards including SPDX and CycloneDX that support SBOM lifecycle management, and the IETF’s SCITT (Supply Chain Integrity, Transparency and Trust) initiative to standardize and verify attestation information that accompanies the SBOMs. From the SCITT website, “In practice, SCITT provides information about artifacts, enabling a mesh of dependencies to understand what each subsystem is consuming. Detailed information comes in varying formats, from structured to unstructured.” 

In slide after slide, Martin distilled the incredible amount of information MITRE and IETF have organized to document and categorize risks, threats, compliance and other critical data for assessing against SBOM data sets. These efforts (and so many more on the part of the CISA, and other standards bodies and working groups), all support the critical need for transparency across the software supply chain.

Resources:

Breakdown of top ten open-source security risks in CSO Online
Deb’s interview with Joe Silvia and Dick Brooks on how security teams will utilize SBOM data
Generating SBOMs from legacy and third-party code through BCA