The document discusses the importance of software Bills of Materials (BOMs) for managing software supply chain risks. It provides background on the creator's work developing standards like CycloneDX and tools like Dependency Track. BOMs allow organizations to understand component dependencies, track vulnerabilities, and ensure compliance. The document outlines common use cases like vulnerability analysis and outlines standard BOM formats like CycloneDX and Package URL. It demonstrates how BOMs can integrate with DevOps pipelines and provide continuous monitoring of supply chain risks.

1. BOMs Away
Why Everyone Needs a BOM
OWASP AppSec Cali: January 2019

2. § Creator of OWASP Dependency-Track
§ Creator of CycloneDX BOM Specification
§ Contributor to OWASP Dependency-Check
§ Contributor to Package URL Specification
§ Multiple Software Transparency Working Groups
§ Software Security Architecture at ServiceNow
About
@stevespringett
steve.springett@owasp.org
https://stevespringett.com
https://github.com/stevespringett

3. § Dependency-Track project reboot (dubbed v3)
§ Analyzing specifically what problems I was trying to solve
§ Facts vs evidence, multi-vuln intel, outdated components, actionable intelligence
§ OWASP Summit 2017
§ Sherif Mansour noticed that NVD and Dependency-Track trying to solve similar problem
§ NTIA created multi-stakeholder process to improve Software Transparency
§ NIST, MITRE, NSA, OWASP, Linux Foundation, Software, Healthcare, Device Manufactures,
Financial Services, etc.
§ Multiple working groups
Backstory

4. NTIA Software Transparency
Working Groups:
• Understanding the Problem
• Use Cases and State of Practice
• Standards and Formats
• Healthcare Proof of Concept
https://www.ntia.doc.gov/SoftwareTransparency

5. Analogy

6. Analogy

7. § Compliance
§ Regulation
§ FDA and others
§ Economic / Supply-Chain Management
§ Use fewer & better suppliers, use highest quality parts, track throughout lifecycle
§ Market Forces
§ SDLC maturity, procurement, operational costs, risks, impact analysis
§ Forensics
§ NTSB and others
Contributing Factors

8. Cybersecurity in Medical Devices
Cybersecurity Bill of Materials (CBOM) – a list that includes but
is not limited to commercial, open source, and off-the-shelf
software and hardware components that are or could become
susceptible to vulnerabilities.
Content of Premarket Submissions for Management of Cybersecurity in Medical
Devices:
https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/
GuidanceDocuments/UCM623529.pdf

9. Deliver Uncompromised
A strategy for supply chain security and resilience in response to
the changing character of war.
https://www.mitre.org/sites/default/files/publications/pr-18-2417-deliver-
uncompromised-MITRE-study-8AUG2018.pdf
Chris Nissen, John Gronager, Ph.D., Robert Metzger, J.D., Harvey Rishikof, J.D.

10. § Another thing an organization has to do
§ Incorrect. A simple change in strategy
§ Doesn’t improve the security of the thing I’m tracking parts on
§ Wrong. Facilitates accurate vulnerability and other supply-chain risk analysis
§ Not in vested interest
§ Some SCA vendors. Other vendors are on-board
§ License compliance
§ Yeah… That’s a problem
Reluctance

11. Game: Find the Fallacies
https://www.alienvault.com/blogs/security-essentials/software-bill-of-materials-sbom-does-it-work-for-devsecops

12. Conceptually
Asset BOM J
Analyze
Analyze
Analyze
Analyze
Analyze
Analyze
Analyze
Analyze
Analyze

13. § License identification and compliance
§ Outdated component analysis
§ Vulnerability analysis (software and hardware)
§ Documenting direct, transitive, runtime, and environmental dependencies
§ File verification (via hash checking)
§ Hierarchical (system, sub-system, etc) representation of component usage
§ Tracking component pedigree (ancestors from which a component is
derived from)
Common Use Cases

14. BOM Formats
• Software Package Data Exchange (SPDX)
– Older spec, RDF-based, Linux Foundation
• Software Identification (SWID): ISO/IEC 19770-2:2015
– Supported by NVD/DoD, Focuses on traditional software lifecycle, spec behind paywall
• CycloneDX
– Newer, lightweight spec with software security focus

15. CPE Dictionary
§ redhat → resteasy → 3.1.0
Centralized vs Decentralized

16. CPE Dictionary
§ redhat → resteasy → 3.1.0
§ cpe:2.3:a:redhat:resteasy:3.1.0:*:*:*:*:*:*:*
Centralized vs Decentralized

17. CPE Dictionary
§ redhat → resteasy → 3.1.0
§ cpe:2.3:a:redhat:resteasy:3.1.0:*:*:*:*:*:*:*
Reality
§ org.jboss.resteasy → resteasy-jaxrs → 3.1.0-Final
Centralized vs Decentralized

18. CPE Dictionary
§ redhat → resteasy → 3.1.0
§ cpe:2.3:a:redhat:resteasy:3.1.0:*:*:*:*:*:*:*
Reality
§ org.jboss.resteasy → resteasy-jaxrs → 3.1.0-Final
§ pkg:maven/org.jboss.resteasy/resteasy-jaxrs@3.1.0-Final?type=jar
Centralized vs Decentralized

19. § Decentralized URI describing component and its place within ecosystem
§ Support virtually unlimited number of ecosystems
§ Maven, Docker, NPM, RPM, etc
§ Identifies all relevant component metadata
§ Ecosystem (type)
§ Group (namespace)
§ Name
§ Version
§ Key/Value pairs (qualifiers)
Package URL

20. <?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1"
xsi:schemaLocation="http://cyclonedx.org/schema/bom/1.0 http://cyclonedx.org/schema/bom/1.0">
<components>
<component type="library">
<group>org.jboss.resteasy</group>
<name>resteasy-jaxrs</name>
<version>3.1.0.Final</version>
<description>JAX-RS bindings for RestEasy</description>
<hashes>
<hash alg="SHA-1">6427a9a622bff4dbe99d6f08dabd0dd89af85235</hash>
<hash alg="SHA-256">97bb6890cea26ed6f107603426fdb19f1444932c310705895ecf9cc24992da0d</hash>
</hashes>
<licenses>
<license>
<id>Apache-2.0</id>
</license>
</licenses>
<purl>pkg:maven/org.jboss.resteasy/resteasy-jaxrs@3.1.0-Final?type=jar</purl>
<modified>false</modified>
</component>
</components>
</bom>
CycloneDX Example

21. <?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" version="1" xsi:schemaLocation="http://cyclonedx.org/schema/bom/1.0
http://cyclonedx.org/schema/bom/1.0">
<components>
<component type="hardware">
<group>Intel</group>
<name>Core i7</name>
<version>8700K</version>
<modified>false</modified>
</component>
</components>
</bom>
CycloneDX Example

22. Conceptually
Asset BOM J
Analyze
Analyze
Analyze
Analyze
Analyze
Analyze
Analyze
Analyze
Analyze

24. Demo

25. Component Analysis Pipeline
Build Dependency-TrackPlugin
Notifications
Jenkins
Integrations

26. Integrations
§ Ingest BOMs during CI/CD
§ Analyzes continuously
§ Notifications on
§ New vulnerability
§ New vulnerable dependency
§ Audit decision changes
§ Outdated versions (future)
§ Monitor activity (slack, teams)
§ Automate response (webhooks)
§ Part of organizations risk metrics

27. Dependency-Track Project Info
• License: Apache 2.0
• GitHub
– https://github.com/DependencyTrack/
• Social Media
– https://twitter.com/DependencyTrack
– https://www.youtube.com/channel/UC8xdttysl3gNAQYvk1J9Efg
– https://www.peerlyst.com/companies/dependency-track
• Documentation
– https://docs.dependencytrack.org/
• Website
– https://dependencytrack.org/

28. Resources
• OWASP: Component Analysis
– https://www.owasp.org/index.php/Component_Analysis
• CycloneDX
– https://cyclonedx.org/
• Package URL
– https://github.com/package-url
• Software Package Data Exchange (SPDX)
– https://spdx.org/
• Software Identification (SWID): ISO/IEC 19770-2:2015
– https://www.iso.org/standard/65666.html

29. Q&A

30. Thank You