Top 10 Open Source Software Risks: The OWASP List Explained With Fixes

Most organisations measure open source risk by counting CVEs, which misses the hijacked packages, lookalike names, abandoned projects and mutable downloads that cause the worst incidents. Open source components make up most of the code in a typical application, and every one of them brings its maintainers, build systems and publishing accounts into your supply chain. This page walks through the ten risks in the OWASP Top 10 Risks for Open Source Software, in OWASP's order, with what goes wrong, real incidents, how to detect each risk and the fix. It is for application security, platform and procurement teams, and for leaders who need to know which controls to fund first. It is a list-format companion to the Open Source Security Guide and the Top 10 Supply Chain Attacks, which cover the attack side in more depth.

The Top 10 at a glance

1. Known vulnerabilities in dependencies
2. Compromise of a legitimate package
3. Name confusion attacks
4. Unmaintained software
5. Outdated software
6. Untracked dependencies
7. Licence and regulatory risk
8. Immature software
9. Unapproved change (mutable components)
10. Under-sized and over-sized dependencies

OWASP does not present the list as a strict severity ranking, and neither do we: the numbering is OWASP's. The practical priority for most organisations is in "Where to start" below.

1. Known vulnerabilities in dependencies

The risk: a component version contains a publicly disclosed flaw (a CVE or a GitHub Security Advisory) that is reachable in your application. Most vulnerable code arrives as a transitive dependency that nobody chose directly.

Why it matters: OWASP's examples are CVE-2017-5638 in Apache Struts, which led to the Equifax breach, and CVE-2021-44228 in Apache Log4j (Log4Shell). Both are in the CISA Known Exploited Vulnerabilities (KEV) catalog, and CISA marks both as known to be used in ransomware campaigns.

The fix: run software composition analysis (SCA) across direct and transitive dependencies in repositories, container images and running systems. Prioritise by exploitation evidence, not CVSS alone: OWASP names CVSS, EPSS, the KEV catalog and reachability analysis. Set remediation targets by priority (for example, KEV-listed and reachable within days). See the Vulnerability Scanning Guide.

2. Compromise of a legitimate package

The risk: attackers inject malicious code into a real, trusted project by hijacking a maintainer's account or publishing token, abusing its CI/CD pipeline, or exploiting the package registry. The package name, history and download count all look right.

Why it matters: OWASP cites the event-stream incident, where a legitimate npm component was altered to target users of Copay Bitcoin wallets. Since then, stolen publishing tokens have driven self-spreading worms across npm and PyPI that steal developer and CI credentials and use them to republish more packages. The code runs on developer laptops and build systems, which hold exactly the credentials an attacker wants. ATT&CK tracks this as T1195.001 (Compromise Software Dependencies and Development Tools).

The fix: there is no single control. Pull all packages through an internal binary repository manager (S2C2F ING-2), scan for malware before ingestion (SCA-4), keep a deny list for known malicious versions (ING-3), and verify provenance where the ecosystem publishes it (AUD-1), for example SLSA provenance or registry attestations. Add a short cool-down before new versions are allowed into builds, so that a compromised release is usually found and pulled before you consume it. See the Malicious Open Source Package Response Playbook and the Self Propagating Supply Chain Worms guide.

3. Name confusion attacks

The risk: attackers publish packages whose names resemble legitimate ones (typo-squatting), suggest a trusted author (brand-jacking) or combine common words in ways developers expect (combo-squatting). Dependency confusion is the internal variant: a public package with the same name as a private one wins the version resolution.

Why it matters: OWASP's example is "colourama" on PyPI in 2018, a typo-squat of colorama that redirected Bitcoin transfers to an attacker-controlled wallet. OWASP also warns that some package metadata is not verified by registries and can be forged, so a convincing description or repository link proves nothing.

The fix: secure package source configuration (S2C2F ENF-1): map internal names to the internal feed, use scoped or namespaced packages, and reserve your organisation's names on public registries. Before adoption, check install hooks, encoded payloads, maintainer history and release frequency, and verify signatures where the ecosystem supports them. A curated feed (ENF-2) blocks most of this class. See the Malicious Package and Dependency Confusion Guide.

4. Unmaintained software

The risk: a component is no longer developed or supported, so new security bugs will not be fixed upstream, or only after a long delay. Your team becomes the maintainer by default.

Why it matters: OWASP's examples include core-js (npm, 2020), the Gorilla web toolkit (Go, 2022) and minimist (npm, 2022). The matching weaknesses are CWE-1104 (Use of Unmaintained Third Party Components) and CWE-1329 (Reliance on Component That is Not Updateable). Single-maintainer projects are also a social engineering target: a tired maintainer may hand commit rights to a helpful stranger.

The fix: scan for end-of-life components (S2C2F SCA-3) and check project health before adoption: recent commits and releases, issue response, corporate backing, documented long-term support dates and archived status. The OpenSSF Scorecard "Maintained" check gives its highest score for at least one commit per week over the previous 90 days and its lowest to archived projects. OWASP notes that low activity can also mean maturity, so read the signal, do not just threshold it. Plan replacements for anything end-of-life. See the OpenSSF Scorecard Guide.

5. Outdated software

The risk: you use an old version of a component even though newer versions exist. The gap grows until an emergency patch becomes a migration project.

Why it matters: old branches may not even be assessed for new vulnerabilities. OWASP points to Apache Tomcat, whose security pages state that vulnerabilities are not checked against the 8.0.x branch and will not be fixed. When the next Log4Shell lands, teams that are many major versions behind cannot patch in days.

The fix: make dependency updates recurring backlog work, automate update pull requests (S2C2F UPD-2) and show vulnerability data in the pull request itself (UPD-3), with two-person review. Track "versions behind" for critical components and agree a maximum lag. See the Dependency Update Automation Guide.

6. Untracked dependencies

The risk: you depend on code you do not know about, so none of the other controls apply to it. OWASP lists incomplete SBOMs, code snippets and vendored source files copied into projects, rebundled binaries, packages installed by scripts with apt-get or brew rather than a manifest, and developer tools such as IDE plugins, build scripts and test dependencies.

Why it matters: when a critical vulnerability or a malicious version is announced, the first question is "where do we run it?". Untracked components turn a one-hour search into a week of manual hunting, and developer tooling is often where malicious packages execute.

The fix: maintain an automated inventory of all open source in development (S2C2F INV-1), generate SBOMs at build time for every release, and test whether your SCA tooling finds vendored and rebundled code. Audit that developers consume open source only through the approved route (AUD-2), for example by searching repositories for checked-in binaries. Have an open source incident response plan (INV-2). See the SBOM Guide and SBOM operations.

7. Licence and regulatory risk

The risk: a component has no licence, a licence incompatible with how you distribute it, or licence obligations you cannot meet. Files inside a component can carry conflicting licences, and some components conflict with regulatory requirements such as export control or government certification programmes.

Why it matters: using code without a licence, or outside its terms, is copyright infringement that the rights holder can act on. OWASP cites Free Software Foundation v. Cisco Systems (2008). Licence changes upstream can also block upgrades, which turns a legal issue into a security one.

The fix: define acceptable licences by use case (linking, SaaS versus distributed software), scan for licences (S2C2F SCA-2) using SPDX identifiers, block components with no licence, and check for files with multiple or incompatible licences. See the Open Source Licence Compliance Guide.

8. Immature software

The risk: a project lacks basic engineering practice: no versioning scheme, no regression tests, no review rules, no documentation. It may work today and break on the next minor release, or ship weaknesses nobody tested for.

Why it matters: immaturity is mainly an operational risk, but it compounds the others: projects without code review or branch protection are easier to compromise, and projects without semantic versioning make updating risky, so teams stop updating.

The fix: set adoption criteria for new dependencies: test code and CI, documentation, a security policy, code review, and an OpenSSF Best Practices badge where relevant. Scorecard checks such as Code-Review, Branch-Protection, CI-Tests, Security-Policy, Binary-Artifacts and Signed-Releases make this repeatable at scale. See the OpenSSF OSPS Baseline Guide.

9. Unapproved change (mutable components)

The risk: a component changes without anyone noticing or approving it, because you reference something mutable: a script piped from a URL into a shell, a Git branch or tag instead of a commit, a container tag instead of a digest, or a registry reached over plain HTTP.

Why it matters: OWASP's example is the Codecov Bash Uploader in 2021, where, from 31 January 2021, an attacker used a leaked cloud storage credential to add one line to the script customers ran in CI, sending their CI environment variables, and so their secrets, to an attacker server; a customer found it on 1 April 2021 because the script did not match its published checksum. In March 2025 an attacker with a stolen bot token repointed the tags of the tj-actions/changed-files GitHub Action to a malicious commit that printed runner secrets into workflow logs; CISA added it to the KEV catalog as CVE-2025-30066 on 18 March 2025. Every workflow that referenced the action by tag ran the new code automatically.

The fix: use immutable references: pin GitHub Actions and other CI components to full commit SHAs, containers to digests, and packages to exact versions with lockfile hashes. Verify digests or signatures after download and before use (S2C2F AUD-3), and use TLS for every registry. The Scorecard "Pinned-Dependencies" check measures whether a project pins build dependencies to hashes. See the GitHub and GitHub Actions Security Guide and the SLSA and Build Provenance Guide.

10. Under-sized and over-sized dependencies

The risk: a micro package gives you a few lines of code but the full supply chain risk of its maintainers and publishing account. A very large package gives you features you never use, each adding attack surface and often more transitive dependencies.

Why it matters: OWASP's examples are left-pad (npm, 2016), 11 lines of string padding whose removal broke builds across the ecosystem, and Apache Log4j, whose rarely used ability to fetch and run remote Java classes became Log4Shell.

The fix: review micro packages and replace trivial ones with internal code; for large components, disable unused features, especially network and code-loading ones, or choose a smaller alternative. OWASP points to capability analysis tools such as Google Capslock (Go) and Microsoft Application Inspector. Mirror critical packages internally (S2C2F ING-2 and ING-4) so that an upstream removal cannot break your builds.

Detecting open source risk

Metrics that show progress: percentage of applications with a current build-time SBOM (target 100%), median days to fix KEV-listed reachable vulnerabilities, share of package downloads served through the internal proxy, end-of-life components in production (trend to zero), and CI workflows with fully pinned third-party actions.

Lessons from incidents

• The build system is the target: the Codecov breach and the tj-actions/changed-files compromise both ran attacker code inside CI, where secrets live. Short-lived, narrowly scoped CI credentials limit the blast radius when a component turns.
• Publishing credentials are the weak link: worms such as the Shai-Hulud npm worm spread by stealing registry tokens and republishing packages. Trusted publishing and short-lived tokens on the producer side protect everyone downstream. See the npm Token Changes and Trusted Publishing guide.
• Trust in a maintainer can be manufactured: the XZ Utils backdoor came from a contributor who built maintainer trust over a long period in an under-resourced project, combining risks 2 and 4.

Mapping to OWASP

ATT&CK covers the attack side as T1195.001 (risks 2, 3 and 9). In NIST CSF 2.0, inventory sits under ID.AM-02, vulnerability identification under ID.RA-01, keeping software maintained and removing it when unsupported under PR.PS-02, and supplier requirements under GV.SC-05 and GV.SC-07.

Where to start

If you can do only three things this quarter: route all package downloads through an internal proxy with malware scanning and a deny list (risks 2 and 3); generate SBOMs for every production application and match them to the KEV catalog daily (risks 1 and 6); and pin every third-party CI action and container image to an immutable reference (risk 9). These three also make incident response fast, because you can answer "are we affected?" from data.

Smaller teams can get most of the way with the dependency update and secret scanning features of their source code platform, lockfiles, and a hosted package proxy. Larger organisations should adopt S2C2F as the maturity scale (levels L1 to L4), add a curated internal feed, provenance verification and rebuilding of the most critical components, and put open source criteria into procurement. The Software Supply Chain Maturity Model shows how these steps fit together.

Practitioner checklist

• Run SCA on every repository and container image, including transitive dependencies, and prioritise by KEV, EPSS and reachability.
• Force all package installs through an internal repository manager; block direct public registry access from CI.
• Scan new package versions for malware and install-time scripts before they reach developers or builds.
• Configure package sources so internal names resolve only to internal feeds; reserve your names publicly.
• Generate and store an SBOM for every release, including build tooling and vendored code.
• Flag end-of-life and archived components and assign an owner and replacement date to each.
• Automate update pull requests and set a maximum version lag for critical components.
• Pin CI actions to commit SHAs, images to digests and packages to lockfile hashes.
• Maintain a licence allow list and block unlicensed components.
• Keep an open source incident runbook: how to find every use of a package within an hour and which credentials to rotate.

Standards and references

• OWASP: Top 10 Risks for Open Source Software
• OpenSSF: Secure Supply Chain Consumption Framework (S2C2F)
• OpenSSF: Scorecard Checks
• CISA: Known Exploited Vulnerabilities Catalog
• MITRE ATT&CK: Compromise Software Dependencies and Development Tools
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Software Supply Chain Security Guide · Open source package compromise · Open Source Software Policy Template · Supply chain NHI breaches