Framing
NTIA Software Supply Chain
Transparency
January 13, 2021

Framing Working
Group
Managed with love and patienceby co-chairs Michelle Jump andArt Manion

Michelle Jump
MedSec LLC
Global Regulatory Advisor - Medical
Device Cybersecurity
MichelleJump@medsec.com

Meeting almost weekly since July
2018•
•Fridays at 1400 EDT
https://lists.sei.cmu.edu/mailman/
listinfo/ntia-sbom-framing

Framing concepts that apply tothe entire multi-stakeholder
process

Art Manion
Software Engineering Institute
CERT Coordination CenterPrinciple Engineer “/” Technical Manager
amanion@cert.org

2

Agenda1. SBOM refresher
2. New draft documents – finalizing comment resolution
1. Sharing and Exchanging SBOMs
2. Software Identification Challenge and Guidance

3. Expected upcoming work
1. “VEX”
2. Glossary

4. Considerations for Further Work
1. Beyond baseline
2.Integrity/Authenticity/Provenance3

Refresher: What is anSBOM?
Framing Software Component
Transparency: Establishing aCommon Software Bill ofMaterial (SBOM)
https://tinyurl.com/y7s8ab3t“An SBOM is effectively anested inventory, a list ofingredients that make up
software components.”

Partial Table of Contents
2 What is an SBOM?
2.2 Baseline Component Information
2.4 Component Relationships
4 SBOM Processes
4.1 SBOM Creation: How
4.2 SBOM Creation: When
4.3 SBOM Exchange
4.4 Network Rules
4.6 Applications of SBOMs
5 Terminology
4

Final good
assembledPart

Compound part

Two Discussion Papers –Now Released
Sharing
Identity
6

Two New
PapersReleased
Available at: SOFTWARE BILL OF
MATERIALS | National
Telecommunications andInformation Administration(ntia.gov).
1.Sharing and Exchanging
SBOMs
2.Software Identification
Challenge and Guidance
7

Sharing and Exchanging SBOMs“Transparency in the supply chainenables better risk decision-making for
producers and consumers of software.
This means that information about theunderlying software components in apiece of software—a Software Bill ofMaterial (SBOM)—should be accessible
to the right entities at the right time.”

8

Programmatic end system SBOM sharing• Goal• An IETF standard• Discover SBOM, determine its format and an appropriate
retrieval mechanism• Method• Provide a simple model• Use of existing network discovery functions to access it(MUD, DHCP, certificate attributes)• Be content neutral: support SPDX, CycloneDX, andanything else
• Status• Adopted by IETF Ops Area Working Group• Early code developed• More work needed to add “VEX” capability• https://tools.ietf.org/html/draft-ietf-opsawg-sbom-access-00

YANG model:+--rw sboms* [version-info]+--rw version-info
string+--rw (sbom-type)?
+--:(url)| +--rw sbom-url? inet:uri+--:(local-uri)| +--rw sbom-local* enumeration+--:(contact-info)+--rw contact-uri? inet:uri

Software Identification Challenges and Guidance“Possibly the biggest single challenge tosupply-chain transparency and theSBOM model is the difficulty inidentifying
softwarecomponents
globally... This paper captures some ofthe major challenges… and offers someguidance on how to address thesechallenges.”10

Ongoing Efforts

11

Framing: Focus Areas Within Phase II• Is the baseline accurate and effective?

• Reviewing baseline to clarify and detail beyond baseline info

• VEX: How do we understand the exploitability status of a particularvulnerability?
• Vulnerability exploitability status• Glossary: Let’s all speak the same language• Common set of terms

12Framing Group Report: Under Revision• Baseline:• Clarifying from past year of experience• NOT significantly changing the baseline• Beyond the Baseline• Providing more context for value of moving beyond the baseline• Other minor editorial/clarification changes that have been identified
since initial release13

Vulnerability Exploitability eXchange (VEX)• Is a piece of software(component!) actuallyaffected by a vulnerability?
• Claims about impact from aparticular author• Can come from the supplier ora third party• Many but not all use cases
associated with SBOM
• Separate from SBOM, butlinkableVEX + SBOM example• Software includes a vulnerablecomponent• SW supplier determines that thevuln doesn’t affect the built software• E.g., relevant code isn’t included bycompiler• E.g., relevant code is present, but not
used or exposed• Supplier issues a VEX with the claimthat the component is “not affected”
and no action is required• Consumer integrates SBOM data,
vulnerability data, and VEX data to
make some risk-based decision

An initial approach to VEX data
Vex Data Fields

VEX targets

Component identifier(s) orcomponent family identifier

VEX metadata• Identifier string for the VEX• Author• Author-role• Timestamp• Integrity/Signature/etc• SBOM identifier (optional)

For each vulnerabilityidentified• Vulnerability identifier• Vulnerability status (Machine readable)• Further vulnerability details• Affected component (optional)

Link to SBOM

Progress on VEX• Aligning as a profile for the OASIS Common Security Advisory Framework(CSAF) standard• Mapping the minimum fields for CSAF and VEX• Hope to include this in the upcoming CSAF version• Draft definitions of the vulnerability status – based on actions needed• Known_not_affected• No mitigation is required regarding this vulnerability.
• This could be because the code referenced in the vulnerability is not present, not exposed,compensating controls exist, or other factors. See {{{field x}}} for more details”• Known_affected• Actions are recommended to mitigate or address this vulnerability• This could include learning more about the vulnerability and context, and/or making a riskbased decision• Under_Investigation• Fixed• Working with the Healthcare POC to test and align