Supply chain attacks on open source software increased 650% in 2021. Software supply chain attacks occur when adversaries manipulate third-party code to compromise downstream applications. Organizations must map dependencies, monitor for vulnerabilities, and quickly patch issues. A Software Bill of Materials (SBOM) provides visibility into components. OWASP Dependency Track helps generate SBOMs and identify vulnerabilities and license risks in dependencies. Implementing standards like the Supply Levels for Software Artifacts (SLSA) can help secure software supply chains and prevent tampering of artifacts.

1. Preventing Supply Chain Attacks
on Open Source Software
1
March 29, 2022

2. 2
Kavitha Venkataswamy
Product Security @ Capital One

3. 3
Srinivasan Rangaraj
Product Security @ Capital One

4. Confidential 4
AGENDA
● Software Supply Chain Attacks
● OWASP Dependency Track
● Supply chain attacks in Mobile Apps
● Implementing Supply chain Frameworks

5. Explosion on supply chain attacks
Supply chain attacks on open source software packages increased by 650% in 2021
5

6. Confidential 6
Software Supply chain
• A software supply chain attack happens when adversaries manipulate the code in
third-party software components in order to compromise the ‘downstream’
applications that use them.
• Attackers leverage compromised software to steal data, corrupt targeted systems, or
to gain access to other parts of the victim’s network through lateral movement.
• Any other ‘upstream’ part of an organization’s supply chain can be thus targeted,
including application developers, publishers of off-the-shelf software like SolarWinds,
API providers, and the open source community.

7. Confidential 7
Software Supply chain
• Need to have a comprehensive map of the dependences used by their applications
• Be Alert to vulnerability disclosures
• Build a robust system for patching security issues.
Key Step : First and Foremost application dependencies have to be mapped

8. Confidential 8
Software Bill of Materials (SBOM)
● Software bill of materials is an inventory of all software components (proprietary and
open source), open source licenses, and dependencies in a given product.
● A software bill of materials (SBOM) provides visibility into the software supply chain
and any license compliance, security, and quality risks that may exist
● CycloneDX - lightweight software bill-of-material (SBOM) spec designed for
supply chain component analysis.

9. Confidential 9
OWASP Dependency Track - Features
• Components with known vulnerabilities
• Out-of-date components
• License risk

10. Confidential 10
Operationalize software Bill of Materials

11. Confidential 11
Dependency Track - Integration
● National Vulnerability Database(NVD)
● Github Advisories
● Repositories including NPM, PyPi etc
● Sontatype OSS Index
● Private Vulnerability Repository

12. Confidential 12
Dependency Track - EcoSystem
• Maven (Java)
• NPM (JS)
• Pypi (Python)
• Gems (Ruby)
• NuGet (.NET)
• Hex (Erlang/Elixir)

13. Confidential 13
Dependency Track - Database & LDAP support
Database:
● Includes H2 by default - not for production, used for quick evaluation & Testing
● Microsoft SQL Server
● MySQL
● PostgreSQL
LDAP:
● Active Directory
● Apache DS
● Fedora 389

14. Confidential 14
Creating BOM File

15. Confidential 15
Software Bill of Materials (BOM)

16. Confidential 16
Software Bill of Materials (BOM)

17. Confidential 17
Dependency Track - How to Get Started
• Minimum Requirements : Java 8 u162 (or higher)
• java -Xmx12G -jar dependency-track-embedded.war -port 8081
• Launch the application.
• OWASP Dependency Track Launched

18. Confidential 18
Dependency Track - Project Creation

19. Dependency Track -Upload BOM
Confidential 19

20. Dependency Track -Vulnerabilities
Confidential 20

21. Dependency Track - Scan for Vulnerabilities
Confidential 21

22. Confidential 22
Dependency Track - Project Vulnerabilities Overview

23. Confidential 23
Dependency Track - Auditing
Project auditing is the
process of triaging
findings on the
components for each
project. Audit decisions,
comments, and audit
history performed on a
project

24. Confidential 24
Vulnerability Analysis
Known Vulnerability Analysis
● integrates with multiple sources of
vulnerability intelligence to identify
components with known
vulnerabilities.
● employs several methods of
vulnerability identification including
OSS Index analyzer, VulnDB
analyzer
Outdated Component Vulnerability
Analysis
● use of components which do not have known
vulnerabilities but are not the latest release,
also represent risk
● By keeping components consistently updated,
organizations are better prepared to respond
with urgency when a vulnerability affecting a
component

25. Confidential 25
Dependency Track - Jenkins Integration
● Dependency-Track Jenkins Plugin is the recommended for
publishing CycloneDX BOMs to Dependency-Track in a Jenkins
environment

26. Confidential 26
Dependency Track - Jenkins Integration

27. Confidential 27
Dependency Track - Impact Analysis
● Analyze the potential for impact of
a vulnerability in the environment.
● Dependency-Track can help
identify all affected projects across
the organization
● Can help organizations answer two
important questions:
What is affected? Where am I
affected?
● For example, search by a library
say, structs 2.3.5 or search by CVE

28. Confidential 28
Dependency Track - Impact Analysis
● perform vendor risk assessments
and identifying potential risk in
third-party software during and
after procurement.
● Ability for vendors to generate
Software Bill of Materials (SBOM)
demonstrates a certain level of
organizational maturity

29. Confidential 29
Supply Chain Component Analysis
Component Analysis is Process of identifying potential areas of risk from the use of
third-party and open-source software and hardware components.
Component Analysis is a function within an overall Cyber Supply Chain Risk
Management (C-SCRM) framework.

30. Confidential 30
Dependency Track - ECO System

31. Supply Chain Attacks in
Mobile Application
NIST/Google
SLSA
Access Control
Harderden the CI/CD
pipeline
Testing
Feature Disable
provision
Secure CryptoVault
Monitoring
Provenance
Vulnerability Scanning
Patching

32. Open Source in Mobile App
Mobile APP
Malicious App/Bot
Mobile Firmware
Mobile Operating System
Third Party Apps
Your Application
Mobile
Hardware
Requirements Design Development Testing
Deployment/Di
stribution
Dependencies Supply Chain
Third Party
First Party

33. Open Source -In Mobile Apps
● Open source is widely used in Mobile applications, providing attackers
with a target-rich environment.
● How do you patch your OpenSource in your App and SDKs
● Are you aware of open source used in your code base
● Does it get the Job done?
● Does it have an open source license?
● Does it have good docs
● Does it have SDK that make use of Open source libraries
● Does it have lots of downloads and GitHub stars
● Does it have recent commits
● How do you defend against common attacks targeting known
vulnerabilities.
● Hackers can exploit known open source security vulnerabilities as they
are available and is published in the CVE database,

34. NIST Mobile Threat Catalogue
# Threat List Description
1
SPC-0: Malicious Code in Open Source Software An adversary with access to open source code and knowledge of its particular use for the system being acquired can
insert malicious code into open source software used for libraries
2 SPC-1: Hardware or Firmware Component Interception A hardware or firmware component can be intercepted by an adversary while in transit between supplier and
acquirer, for the purpose of substitution or manipulation
3 SPC-2: Malicious Critical Hardware Replacement Adversarial supply chain distribution channel personnel (e.g., packaging, shipping, receiving, or transfer) can
intercept and replace legitimate critical hardware components with malicious ones
4 SPC-3: Malicious Software Inserted into Software
Processes or Tools
An adversary with access to software processes and tools within the development or software support environment
can insert malicious software into components during development or update/maintenance
5 SPC-4: Malicious Logic Introduction A software or firmware programmer with access to the configuration control system can introduce malicious logic into
software or microelectronics during coding and/or logic-bearing component development or update/maintenance
6 SPC-5: Malware Embedded in Critical Component An adversary with access to hardware procurement, maintenance, or upgrade control can embed malware in a
critical component
7 SPC-6: Improperly Vetted or Untested Malicious
Microelectronics
An adversary with access to the hardware commodity procurement process can insert improperly vetted or untested
malicious critical microelectronics components into the system during development
8 SPC-7: Hardware Component Substitution During
Transfer
An adversary with access to production component supplier shipping channels during transfer of system
components can substitute a maliciously altered hardware component for a tested and approved component
9 SPC-8: Firmware Component Substitution During
Transfer
An adversary with access to supplier shipping channels during transfer of system components can substitute a
counterfeit firmware component for an authentic component
10 SPC-9: Malicious Code in Custom Software An adversary with access privileges within the software development environment and to associated tools, including
the software unit/component test system and the software configuration management system, can hide malicious
code in custom software
11 SPC-10: Malicious Software in 3rd Party Bundling
Process
An adversary with access to 3rd party bundling processes and tools can implant malicious software in a system
during the hardware-software integration phase
12 SPC-11: Vulnerable BIOS Installation An adversary with access to download and update system software installs a BIOS containing known vulnerabilities
for future exploitation
From NIST

35. Malicious Code in Open Source
Threat Description: An adversary with access to open source code and knowledge of its particular use for the system being acquired can
insert malicious code into open source software used for libraries
Mobile App Developer- Possible Countermeasure
Prefer open source
software libraries for which
integrity-checking
mechanisms are provided
To increase the complexity
of this attack, when
possible, obtain multiple
instances of the same
library as hosted by various
sources (e.g., FTP mirrors)
from which it should be
available. Then evaluate all
obtained versions for
consistency (e.g., compare
strong hashes). If any
discrepancies are detected,
contact the open source
software developer
To reduce the probability
this variety of attack
goes undetected at
runtime, implement
defensive programming.
Any call to untrusted
code that can impact
critical functionality of
the system should
include checks on the
output for conditions that
should always be true
given an assumption the
library behaves as
expected
To protect open source library
used by a product from
modification, then if possible,
package a verified authentic
instance of the open source library
and apply cryptographic
protections (e.g., strong hashing,
digital signatures) to the product to
allow customers to verify the
authenticity and integrity of all
packaged components
To prevent distributing a
software package that
contains maliciously
modified open source
libraries, perform
sufficient functional
testing of the complete
system to verify that it
exhibits correct and
consistent behavior

36. Supply Chain Level for Software Artifacts
SLSA is a set of standards and technical controls
you can adopt to improve artifact integrity, and build
towards completely resilient systems. It’s not a
single tool, but a step-by-step outline to prevent
artifacts being tampered with and tampered artifacts
from being used, and at the higher levels, hardening
up the platforms that make up a supply chain.

37. https://slsa.dev/spec/v0.1/#supply-chain-threats
Protecting Against Key Threats
Reduce Dependency
Confusion Issues
Typosquatting
Using Red Team Tests
Against Supply Chain
Attacks
Open Source
Third Party
SDK/Lib
Mobile APP
source
SCM
CI/CD Distribution To APP
Store

38. Implement SLSA

39. SLSA Requirements

40. SLSA Provenance

41. Software Supply Chain

42. Confidential 42
References
• https://dependencytrack.org/
• https://pages.nist.gov/mobile-threat-catalogue/supply-chain-threats/SPC-0.html
• https://slsa.dev/spec/v0.1/#supply-chain-threats

43. Confidential 43
Thank You