SBOMAn Update on Efforts for Transparency in the

Software Supply ChainAllan Friedman, PhD

National Telecommunications & Information AdministrationUS Department of Commerce

afriedman@ntia.gov @allanfriedman

How many organizations can answer:

Am I potentially affected by $vulnerabilty

Should I pay attention or clean out my inbox?

• Transparency helps markets across the supply chain• Why aren’t we already doing this?

• Public Policy Context

• Progress in NTIA’s open, cross—sector, global SBOM work

• The what, the why, and the how

• Current, ongoing work

• The automotive perspective• How you can get involved

4

Where did we get the idea of paying attention to the supply chin?

So what about software?

See Asuka Nakajima’s OEM Finderhttp://oemfinder.ilab.ntt.co.jp/oem

10

11

Produce Software

Choose Software

Operate Software

Three perspectives across the supply chain

• Monitor for vulnerabilities in components• Better manage code base & minimize bloat• Execute white-list or black-list practices• Prepare and respond to end-of-life contingencies• Know and comply with license obligations• Provide an SBoM for customers

Use Cases: Producing software

• Identify known vulnerabilities• More targeted security analysis• Compliance• EOL awareness• Verify sourcing & supplier claims• Understand software integration• Market signal of secure

development process.

Use Cases: Choosing software

• Vulnerability management

• Better understanding of operational risks

• Real time data on components in assets

• Improved understanding of potential exploitability

• Enable potential non-SW mitigations

Use Cases: Operating Software

So why aren’t we doing this?

Some people already tried…

It’s hard.It’s hard.

A market failure?

Enter your friends, the Feds

Cross sectorEn

tire

Supp

ly c

hain

Open sourceMiddlewareCommercial SW

EmbeddedCustomers

NTIA’s open, transparent, consensus based processes bring together diverse stakeholders can catalyze real progress across the ecosystem.

NTIA’s Process on Software Component Transparency

The Bigger Picture - Broader Policy Context

• Supply Chain focus• CISA Supply Chain Risk Management Task Force• Federal Acquisition Security Council• Extensive DOD work

• Regulators• FDA pre-market guidance for medical devices.• HHS and healthcare• NHTSA

• Global landscape of concern

• Regulation

• Source code disclosure

• Standards Development

• Solving all supply chain issues

What the NTIA process is not doing

Modern software systems involve increasingly complex and dynamic supply chains. Lack of systemic transparency into the composition and functionality of these systems contributes substantially to cybersecurity risk as well as the costs of development, procurement, and maintenance. In our increasingly interconnected world,risk and cost impact not only individuals and organizations directly but also collective goods like public safety and national security.

The problem to be solved

Source: Framing Software Component Transparency: Establishing a Common Software Bill of Material

• Harmonization• Amplification & routinization• Extensions & innovation

• Clear appreciation across sectorson the potential value of transparency

• Consensus on• The broad scope of the problem• Focus on a baseline SBOM• Machine-readability of the solution• Modularity and Scalability

• Resources: ntia.gov/SBOM

What is an SBOMWhy should we SBOM How do we SBOM Can we SBOM today?

Making progress

What is an SBoM?

A toy example

29

AcmeAppliance

v1.1

BingoBufferv2.1

Bob’sBrowser

v2.2

Carol’sCompressionEngine v3.1

Included in

Included in

Included in

unknown

partialroot

known

A toy example

30

AcmeAppliance

v1.1

BingoBufferv2.1

Bob’sBrowser

v2.2

Carol’sCompressionEngine v3.1

Included in

Included in

Included in

unknown

partialroot

known

Known Unknowns

Software Components

SupplierComponent

NameVersionHash

How many levels deep?

Must include all top-level includes.Should ask for includes’ SBOMs.

Ideally makes a best-effort for all known components.

Why should we SBoM?

Natural Selection in the SW ecosystem

How do we SBoM?

Two formats to implement SBOMSPDX is an open standard for communicating software bill of material information (including components, licenses, copyrights, and security references). The SPDX specification is developed by the SPDX workgroup, which is hosted by The Linux Foundation. The grass-roots effort includes representatives from more than 20 organizations—software, systems and tool vendors, foundations and systems integrators—all committed to creating a standard for software package data exchange formats.

SWID tags record unique information about an installed software application, including its name, edition, version, whether it is part of a bundle and more. SWID tags support software inventory and asset management initiatives. The structure of SWID tags is specified in international standard ISO/IEC 19770-2:2015.

Implementing core SBOM fields

Translation between formats• We have identified the common elements.• A ‘multilingual’ ecosystem does not offer too many challenges• Rather than pick a winner, we will build out guidance to support

both formats with effective interoperability.

40

HealthcareProof of Concept

Next steps• Refining and extending the model

• Software namespace• Mechanism for sharing SBOM data• Vulnerability vs Exploitability• High assurance: integrity, pedigree, provenance• Cloud & containers• Dock with other efforts around supply chain

• Tooling for automation• What tools exist today?• What tools do we need?

• Awareness and adoption• Get the message to the community• Draft contract language• Further demonstrations in different sectors

Challenge: Software Naming

Challenge: Sharing SBOM data

Challenge: Vulnerability vs Exploitability

44

Vendors can communicate risk (or the lack thereof) with their customers.

We need to enable this process.

Challenge:

Vulnerability vs.

Exploitability

Category Type Description

Author during Build

Build Document is automatically created as part of building an artifact and contains information about the build.

Author after Creation

Manual A person will manually fill in the information

Audit Tool A source code analysis or audit tool will generate the document by inspection of the artifact and any associated sources.

Consume View Be able to understand the contents in human readable form (picture, figures, tables, text.). Use to support decision making & business processes.

Diff Be able to compare two documents of a given formation and clearly see the differences. For instance, comparing between two versions of a piece of software.

Analyze Be able to import a document into

Transform Translate Change from one file type to another file type while preserving the same information.

Merge Multiple sources of documents can be merged together for analysis and audit puproses

Tool integration

Support use in other tools by APIs, libraries.

Taxonomy for Classifying SBOM Tools

Opportunity:Proofs of concept

Considerations for the Auto Sector

• Longer supply chain: more players, and more lead time

• Concerns about public disclosures

• Who needs this data today?• Potential of a trusted third party• Where is the data in the

organization?• Regulatory future

Transparency

• Tracking third party components can help understand and address a wide range of risks across the entire ecosystem

• Cross-sector supply-chain driven approach • What a Software Bill of Materials is• Why it can help across the supply chain• How we can implement it

• Sectors and orgs can shape their own future through Proof-of-Concept exercises

• Ongoing work needs your help to build and use SBOM data

Get involved in the NTIA process!Contact: afriedman@ntia.govRead: ntia.gov/SBOMJoin the conversation @allanfriedman #SBOM

To recap…

Software Bill of Materials#SBOMntia.gov/sbom