Written by Jordan Hardy

Threat Modeling: Expanding scope to the software supply chain

The average modern application contains a significant number of open-source packages; in some cases up to 90%* Despite their significance they are often left out of the threat model leaving a gap in necessary mitigations and risk analysis.

Understanding the human element

Software supply chains, certainly in the open-source community, are primarily about trust between people. How many maintainers have publishing rights to your dependencies? The principle of least privilege applies here too, each of these maintainers represent a potential compromise vector. This has been shown by “Shai-Hulud”, one of the latest supply chain attacks, targeting the NPM ecosystem and affecting many packages using self-propagation**. This attack was initiated using spoofing and phishing techniques to gain access to developers’ accounts. Once access was obtained, the attackers could distribute malicious versions of the packages.

Not only are external actors a concern, but also insider threats, although more complicated to manage, should be considered. Package maintainers can go rogue, be coerced, make mistakes, and depending on the situation, might over-rely on AI to generate code and fix bugs.

Both situations lead to packages that could compromise multiple assets in IT environments where they are used, including both pre-production and production systems. As mentioned above the Shai-Hulud attack’s intended goal was to gain access and target any asset of value. This includes data, deployment of ransomware, resource-theft for crypto mining, etc. Depending on the type of attack and its targets, developer workstations, CI/CD pipelines and application servers and -databases can be compromised. When it concerns client-side packages, this can result in JavaScript execution in the end-user’s browser where credentials and cookies can be stolen to gain access to their accounts.

Licensing and legal requirements, the hidden risk

While security vulnerability dominates the supply chain discussion, license compliance is an equally serious yet often overlooked threat. Every third-party package you use in your software carries legal obligation that, if ignored, can result in forced product recalls, financial penalties and even publicizing intellectual property. Depending on which license type is used, different requirements apply.

Permissive licenses (MIT, Apache, BSD): These are the most flexible and generally require preservation of copyright notices and disclaimers included with the original package.
Weak copyleft licenses (MPL, EPL): These licenses are allowed to be used and linked with commercial and closed-source software, but it does require that any modification to the licensed code remains open-source
Copyleft licenses (GPL, AGPL, LGPL) Overall these licenses require to release your own source code if you distribute the software. AGPL also extends requirements over network use, if a user interacts with the software over a network, the users also should have access to the source code itself. Generally copyleft licenses are considered a risk for proprietary code.

These license requirements are not only a risk with direct dependencies, as these licenses place requirements on linked source code. They also pose a risk deeper in the dependency tree in the form of transitive dependencies (i.e., dependencies of dependencies). Complying with the license requirements can become an issue as automated dependency updates might obscure to what licenses you’re bound by. Consistently monitor and review the requirements because package license models may change over time.

Know your supply chain

Before addressing any of the issues mentioned above, you need visibility into your supply chain, which involves a proactive and continuous monitoring approach for every component in your application. A Software Bill of Materials (SBOM) can be used as it is a complete inventory of used software components. The SBOM lists every dependency,

either direct or transitive, with their specific versions, license information and other relevant meta data.

The SBOM contains all relevant data to uncover any existing issues in the open-source packages and can support in uncovering high risk indicators in the open-source package:

Dependencies without recent updates (abandoned)
Single-maintainer projects with critical functionality
Packages with a history of many critical security issues
Copyleft licenses in proprietary products
Large number of transitive dependencies

For the actual threat model, when defining trust boundaries, an external dependency is considered an external-facing trust boundary. This should also include transitive dependencies, as you’re trusting the package as much as all the packages it depends on.

To identify the threats, STRIDE can be used to identify specific supply chain threats:

Spoofing: Attacker publishes malicious package with similar name (typo squatting) or compromises legitimate package repository account
Tampering: Dependency is modified between source and your build (compromised mirror, man-in-the-middle attack on package downloads from internal http servers)
Repudiation: Unable to verify authenticity of package or track who published it
Information Disclosure: Malicious dependency exfiltrates secrets, source code, or environment variables during build or runtime
Denial of Service: Dependency contains resource exhaustion bugs or is removed from registry, breaking your build
Elevation of Privilege: Vulnerable dependency provides attack path for privilege escalation in your application

Using an SBOM in your threat model transforms supply chain threats from abstract concerns into concrete risks with specific detection and mitigation strategies.

Conclusion

The supply chain supporting your applications creates many threats because you lack control over:

when maintainers push updates
when vulnerabilities are discovered in dependencies
when a package author decides to change their license
when an open-source project is abandoned

First and foremost: you have no control over the security practices of the thousands of open-source contributors whose code runs in your production environment. Being aware of the risks in the supply chain helps in isolating impact whenever possible.

Ready to master threat modeling?

About the Author

Robert is a seasoned software developer, software architect, and recognized leader in application security and threat modeling. He is dedicated to helping developers, architects, project managers, and other stakeholders strengthen their understanding of secure software design and architecture through threat modeling and related security practices. A strong advocate for building and sustaining organizational Threat Modeling Programs and Security Champion Programs, Robert brings extensive experience in guiding teams to successfully launch, scale, and mature these initiatives.