1 of 34

Laurie Williams

Laurie_williams@ncsu.edu

Supply Chain Security: Vulnerable and Malicious Components

Yingyaipumi /stock.adobe.com

2 of 34

A6: Vulnerable and Outdated Components

Components used in an application are outdated or have a vulnerability
At the root of software supply chain attacks (think: Executive Order 14028).
Notable CWEs:

1104: Use of unmaintained third-party components
1035: Using components with known vulnerabilities

Source: OWASP.ORG| CC by 3.0

macrovector /stock.adobe.com

3 of 34

Software Supply Chain

… anything that touches your code from development through �CI/CD pipelines until it is deployed in production

SLSA/Apache 2.0

Modern software systems involve increasingly complex and dynamic supply chains; supply chain attack happens when someone infiltrates your organization through a third-party: a partner or provider.

the CI environment needs to have access to the secrets or credentials that grant access to these systems. Still very common for production credentials to be used and most importantly, it is highly likely that the CI environment will have access to the git repository, which is known to contain a trove of sensitive information.

Software supply chain attack – deliberate [with caution and attention] injection of malicious code into a software package to compromise dependent systems further down the chain .. Tamper with the end product of a given vendor that carries a valid digital signature … employ obfuscation and evasion techniques to avoid detection by humans or program analysis techniques.

The main difference between vulnerable and malicious is intention

Dependency managers automatically resolve, download, and install hundreds of open source packages throughout the software lifecycle … automated build systems.

There are many methods to attack a supply chain, from directly inserting malicious code as a new contributor, to taking over a contributor’s account without others noticing, or even compromising a signing key to distribute software that is not officially part of the dependency.

4 of 34

Growth in Software Supply Chain Attacks

5 of 34

Accidental dependency vulnerability

6 of 34

Dependencies as an attack vector

Siridhata/stock.adobe.com

Sergey Nivens /stock.adobe.com

7 of 34

Biggest growth in attacks

8 of 34

What needs to be done with third-party components?

We need to choose them
We need to manage them

9 of 34

https://www.explainxkcd.com/wiki/index.php/2347:_Dependency

Bad �choice

10 of 34

Ponder this …

When you bring a third-party component into your project, it’s like you are adding the developers of that component to your team. �Do you trust them?

Pixel-Shot /stock.adobe.com

11 of 34

Transitive dependencies

(also called indirect dependencies ⇒ dependencies of dependencies)

* Snyk: State of Open Source Dependencies 2020

12 of 34

OpenSSF Scorecard

2023 SONATYPE 9TH ANNUAL STATE OF THE SOFTWARE SUPPLY CHAIN REPORT

Purpose: help developers and organizations assess the security postureof open-source software by providing a set of automated checks that evaluate various software security practices

13 of 34

OpenSSF Scorecard

The result of a large multi-industry effort seeking to elevate all open source software through streamlined automated analysis.
Automated test suite designed to evaluate the security of software repositories.
Use by development teams to: (1) improve their practices to improve their score; and (2) to make good component choices.
Projects must be on GitHub and/or GitLab
Currently 18 metrics with a score from 0-10, weighted in the aggregated Scorecard Score in relation to their perceived relationship to security risk (based on the potential severity and impact

Critical: weight = 10
High: weight is 7.5
Medium: weight is 5
Low: weight is 2.5

14 of 34

Critical Metrics

Dangerous workflow: Checks if the project's GitHub Action workflows has dangerous code patterns: untrusted code checkout, script injections with untrusted context variables

Does the project avoid dangerous coding patterns in GitHub Actions?�

15 of 34

High metrics

Binary artifacts: cannot be scanned; the most common say that malicious actors compromise open source software
Branch protection: checks if project’s default and release branches are protected by branch protection or repository rules, allowing maintainer to define rules that enforce workflows for branches, such as requiring reviews, preventing forced pushes or passing status checks
Code review: most recent changes have an approval or if merger is different from committer
Dependency update tool: to keep the version of all dependencies close to (but not at) the latest available version. Software Composition Analysis (SCA) tool is enabled:

Dependabot, Renovate bot, PyUp

Maintained: software with routines progress is more likely to be secure because someone is watching over it and maintainers are ready and available to make security updates if needed

16 of 34

High metrics - 2

Signed releases: if the project cryptographically signs release artifacts. Looks at project’s past five releases for: *.minisig, *.asc (pgp), *.sig, *sign, *.intoto.jsonl

SLSA provenance file: verifiable information describing where, when, and how something was produced

Token permissions: project's automated workflows tokens follow the principle of least privilege; instead of using the default full privilege taken generated at each job step, add read-only permissions to the top level of the file and only increase permissions on steps that require it (principle of least privilege)
Vulnerabilities: one point is deducted for each vulnerability in the project or dependency in the Open Source Vulnerability (OSV) database

17 of 34

Medium metrics

Fuzzing: looks for fuzzing by OSS-Fuzz, ClusterFuzzLite, OneFuzz, Go fuzzing,QuickCheck, Hedgehog, Validity, SmallCheck, fast-check
Packaging: project if published as a package, giving users an easy way to download, install, update, and uninstall the software by a package manager
Pinned dependencies: dependency that is explicitly set to a specific hash instead of allowing a mutable version or range of versions

Mitigates risk of dependency compromise ensuring you know the exact commit, such as countering dependency confusion in which attackers fool the user into using a malicious package with a “higher” version
Downside: can inhibit software updates

SAST: determine if the project uses SAST (CodeQL, SonarCloud)
SBOM: project maintains and publishes a Software Bill of Materials (SBOM)
Security Policy: does the project have a security.md file to provide a process for responsibly reporting security vulnerabilities found

18 of 34

Low metrics

Continuous Integration (CI)-Tests: checks in CI suite to test code changes before they are merged. Look at last 30 commits for % of commits with activity from well-known CI tools (appveyor, buildkite, circleci, e2e, github-actions, jenkins, mergeable, test, travis-ci)�
CII best practices: OpenSSF Best Practices badge self-reporting�
Contributors: what company each contributor has listed on their profile, highest score 3 or more companies

1 company, could be self-serving/specific and no one else is interested; cross-pollination is good�

Licence: project has published a licence to provide users information about how the source code may or may not be used

19 of 34

Pinning dependencies

Typically projects use Semantic Versioning (SemVer) ranges (such as in package.json)�
Caret: Running npm install foobar, an entry like "foobar": "^1.1.0" added to the package.json. Verbosely, this means "any foobar version greater than or equal to 1.1.0 but less than 2".�
Tilde: Ranges like "foobar": "~1.1.0" which means "any foobar version greater than or equal to 1.1.0 but less than 1.2". This narrows the range to only patch updates to the 1.1 range.�
Pin" your dependencies rather than use ranges means you use exact entries like "foobar": "1.1.0

20 of 34

Dependency Confusion

Early build step – download source and dependencies from approved source and artifact repos

Anyone can freely upload code

Install dependencies: Node has npm; Python’s pip uses PyPi; RubyGems

Typosquatting – leverages typo’d versions of popular package names
Dependency confusion: a software installer is tricked into a pulling a malicious code file from a public repository instead of the intended file from an internal repository

https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610�https://dhiyaneshgeek.github.io/web/security/2021/09/04/dependency-confusion/

21 of 34

Dependency confusion - 3

Finding private packages (NPM)

Look at the package.json file

https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610�https://dhiyaneshgeek.github.io/web/security/2021/09/04/dependency-confusion/

22 of 34

Dependency Confusion - 2

Public package contains higher version compared to private package
If package indexing not done properly, it will automatically pull the higher version from the public registry

https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610�https://dhiyaneshgeek.github.io/web/security/2021/09/04/dependency-confusion/

23 of 34

OpenSSF Scorecard

25 of 34

Exercise

Go to deps.dev and click around:

Log4j (Maven org.apache.logging.log4j:log4j-core)

Go to the Dependencies tab and click on Graph
Name 3 interesting things you learned you could find on this site about log4j

26 of 34

OpenSSF Scorecard: On the Path Toward Ecosystem-Wide Automated Security Metrics. IEEE Secur. Priv. 21(6): 76-88 (2023)

27 of 34

What needs to be done with third-party components?

We need to choose them
We need to manage them

28 of 34

Software Component Analysis (SCA) Tools help

and more….

Dependency Check example

Fabio: tools generate many irrelevant or low priority alerts (spamming) .. Prefer to follow social media … abandon use of the tools

Github Dependabot: CVE + Github advisory database; severity; link to affected files in your project; link to pull request containing security update

OWASP dependency check: NVD/CVE

Snyk: CVE/NVD + public vulnerability database (60%) + 500 vuln reported by Snyk researchers + dependency tree information + “exploitablility index” + proof of concept of how it can be exploited

Blackduck: can find packages not in manifest/dynamically resolved (build process monitoring) + Blackduck advisories (Synopsys Cybersecurity Research Center (CyRC) )

Eclipse Steady: Analyses your Java and Python applications for open-source dependencies with known vulnerabilities, collects evidence regarding the execution of vulnerable code in a given application context (through the combination of static and dynamic analysis techniques), and supports developers in the mitigation of such dependencies.

SourceClear: control flow analysis (reduces work in some cases by up to 90 percent) + scan databases using ML

WhiteSource: whether your code utilizes them or not, so you know exactly what needs your attention the most. This reduces security alerts by up to 85%, allowing you to remediate more critical issues faster.

1 of 34

2 of 34

3 of 34

4 of 34

5 of 34

6 of 34

7 of 34

8 of 34

9 of 34

10 of 34

11 of 34

12 of 34

13 of 34

14 of 34

15 of 34

16 of 34

17 of 34

18 of 34

19 of 34

20 of 34

21 of 34

22 of 34

23 of 34

24 of 34

25 of 34

26 of 34

27 of 34

28 of 34

29 of 34

30 of 34

31 of 34

32 of 34

33 of 34

34 of 34