Third-Party and Open Source Software Risk
Third-party and open source software risk encompasses the security exposure introduced into an application when code, libraries, frameworks, or services originate outside the organization's direct control. This sector of application security is structured around a core paradox: the software components that accelerate development most dramatically also represent the attack surface with the least organizational visibility. Regulatory bodies including NIST, CISA, and the White House Office of Management and Budget have each issued formal guidance addressing this risk domain, reflecting its prominence in both commercial and government software supply chains.
Definition and scope
Third-party software risk refers to vulnerabilities, licensing conflicts, and malicious code introduced through external dependencies — including commercial libraries, open source packages, software development kits (SDKs), and externally hosted APIs. Open source risk is a subset of this broader category, specific to publicly available code distributed under licenses such as MIT, Apache 2.0, or GPL.
NIST SP 800-161r1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, establishes the foundational federal framework for addressing risks that originate in the software supply chain, which includes both direct vendors and transitive (indirect) dependencies.
Scope boundaries distinguish between:
- Direct dependencies: packages explicitly declared in a project's manifest (e.g.,
package.json,requirements.txt,pom.xml) - Transitive dependencies: packages pulled in automatically as dependencies of dependencies, often invisible to the consuming team without tooling
- Vendored code: third-party code copied directly into a repository rather than managed via a package manager
- Runtime integrations: external APIs and SaaS services whose code executes in or adjacent to the application but is not distributed with it
The transitive dependency problem is operationally significant. Ecosystem analyses from platforms such as Sonatype's State of the Software Supply Chain report have identified that transitive dependencies can outnumber direct dependencies by a ratio exceeding 5-to-1 in large Node.js and Java projects, meaning the majority of third-party exposure is invisible without dedicated software composition analysis.
How it works
Risk materializes through four primary mechanisms:
- Known vulnerability inheritance: When a dependency contains a documented CVE, every application consuming that dependency inherits the vulnerability. The National Vulnerability Database (NVD) maintained by NIST recorded over 25,000 new CVEs in 2022 alone, a meaningful portion of which affected widely distributed open source packages.
- Malicious package injection: Threat actors publish packages with names resembling popular libraries (typosquatting) or compromise existing maintainer accounts to insert malicious code into legitimate packages — a pattern documented by CISA in Alert AA22-137A.
- Dependency confusion attacks: An attacker publishes a public package using the same name as a private internal package, causing package managers to fetch the malicious public version due to resolution precedence rules.
- License compliance risk: Code distributed under copyleft licenses such as GPL v3 can impose redistribution obligations on downstream consumers, creating legal exposure separate from but often managed alongside security risk.
The attack vector is compounded by the update velocity of open source ecosystems. The npm registry alone hosts over 2.1 million packages (npm public registry statistics), and the mean time between a vulnerability's discovery and its public disclosure creates windows of exploitability with no practical remediation path.
Organizational response frameworks generally follow this sequence: inventory → classify → assess → remediate → monitor. The inventory phase is addressed specifically through SBOM (Software Bill of Materials) tooling, which the Biden Executive Order 14028 (May 2021) mandated for software sold to federal agencies (EO 14028 text via Federal Register).
Common scenarios
Log4Shell (CVE-2021-44228): The December 2021 disclosure of a remote code execution vulnerability in Apache Log4j 2 illustrated the transitive dependency problem at scale. Because Log4j was embedded in thousands of commercial and open source products as a logging dependency, organizations discovered they were affected by a critical-severity vulnerability in software they did not know they were running. CISA issued an emergency directive and published a dedicated Log4j guidance page.
SolarWinds supply chain compromise: Though centered on a commercial product rather than open source code, the 2020 SolarWinds incident established that supply chain security for software applies equally to proprietary dependencies and that build-pipeline integrity is a distinct risk layer requiring separate controls.
Protestware and maintainer sabotage: In 2022, the maintainer of the node-ipc npm package introduced destructive code targeting users in specific geographic regions — demonstrating that trusted, actively maintained packages can become malicious without a change in ownership.
These scenarios cluster around two distinct risk profiles:
| Risk Type | Origin | Detection Window | Primary Control |
|---|---|---|---|
| Known vulnerability | CVE in existing code | Post-disclosure | SCA scanning, patch management |
| Malicious injection | Attacker-introduced code | Pre/post-publish | Integrity verification, registry monitoring |
Decision boundaries
Practitioners and security programs use defined thresholds to determine when third-party risk requires escalation versus routine management. The OWASP Dependency-Check and related tools apply CVSS scores as the primary severity gate, with scores of 9.0 or above (Critical) typically triggering immediate remediation or compensating control requirements under frameworks like PCI DSS application security requirements.
Key decision points include:
- Accept vs. remediate: Low-severity CVEs in non-network-exposed code paths may be formally accepted with documented rationale; critical CVEs in internet-facing components require immediate patch or component removal
- Block vs. allow in CI/CD: Application security in CI/CD pipelines integrations enforce policy gates that block deployments when dependency scans exceed severity thresholds
- Commercial vs. open source procurement: Organizations applying the NIST Secure Software Development Framework (SSDF) must attest to third-party risk management regardless of whether the dependency is commercial or open source
- SBOM completeness requirements: Federal contractors subject to EO 14028 must produce SBOMs meeting minimum element standards defined by NTIA's Minimum Elements for an SBOM
The distinction between open source and commercial third-party risk is primarily one of transparency: open source codebases can be inspected directly, while commercial black-box components require vendor attestation. Neither category eliminates risk; each requires tooling, policy, and governance structures calibrated to the organization's asset classification and regulatory environment.
References
- NIST SP 800-161r1 – Cybersecurity Supply Chain Risk Management
- National Vulnerability Database (NVD) – NIST
- CISA Alert AA22-137A – Supply Chain Compromise
- CISA Log4j Vulnerability Guidance
- Executive Order 14028 – Improving the Nation's Cybersecurity (Federal Register)
- NTIA Minimum Elements for a Software Bill of Materials
- OWASP Dependency-Check Project
- NIST Secure Software Development Framework (SSDF) – SP 800-218
- npm Public Registry