Open Worldwide Application Security Project (OWASP)

OWASP (the Open Worldwide Application Security Project, formerly the Open Web Application Security Project) is a nonprofit foundation whose volunteer-led projects publish free application security documents, standards, and tools, including the OWASP Top 10, ASVS, SAMM, and CycloneDX. OWASP matters because auditors, procurement teams, and scanners treat its lists as the default vocabulary for application risk.

The most consequential change in OWASP's recent work concerns dependencies. In the OWASP Top 10:2025, Software Supply Chain Failures ranks third (A03), and exactly 50% of community survey respondents ranked it their top concern (A03:2025). Yet only 11 CVEs map to that category's weaknesses, and the malware that defines modern supply chain attacks is filed under a different category. Our view: OWASP got the diagnosis right and the instrumentation wrong. Its prevention guidance still leans on known-vulnerability databases, which cannot see a malicious package until someone has already reported it.

OWASP is a set of independently led projects held together by a small nonprofit foundation. The OWASP project launched on December 1, 2001, and was incorporated as the US nonprofit OWASP Foundation, Inc. on April 21, 2004. OWASP counts over 250 local chapters and over 275 active open source projects (About OWASP). Almost everyone involved is a volunteer, and OWASP states that it "is not affiliated with any technology company" (Top 10:2025). All of its tools and documents are free and open.

Projects are the unit of work. Each OWASP project has its own leaders, repository, license, and release cadence, and OWASP labels its most mature projects Flagship. Quality and scope follow the project's leaders, so the OWASP name on a document tells you who hosts it, not how rigorous it is. OWASP output comes in four shapes:

Not every well-known project stays inside OWASP. The core team of the ZAP web scanner announced in August 2023 that ZAP was leaving for the Software Security Project, a Linux Foundation initiative. ZAP has since left that foundation too, and is now maintained with Checkmarx's support.

OWASP stands for Open Worldwide Application Security Project. Until 2023, the W stood for Web. On February 15, 2023, the OWASP board voted 6-0 to replace every reference to the "Open Web Application Security Project" with the "Open Worldwide Application Security Project" (board minutes). The new name matches the scope: OWASP projects now cover APIs, mobile apps, CI/CD pipelines, AI systems, and third-party dependencies, not only web applications. The acronym did not change, and older URLs, including this page's, still carry the old name.

The OWASP Top 10 is a ranked list of ten web application risk categories, first published in 2003 and revised every few years. Its 2021 edition is blunt about what it is: "The OWASP Top 10 is primarily an awareness document" (OWASP Top 10:2021). The Top 10 names categories. It does not tell you whether an application passes anything.

Each category groups several Common Weakness Enumeration (CWE) entries. The 2025 edition maps 248 CWEs across its ten categories, using data donated for over 2.8 million applications (2025 introduction). Eight categories come from that testing data. Two, A03 and A09, were promoted through a community survey, because OWASP says testing data looks backward and lags new attack classes.

The dependency category has never dropped since it first appeared in 2013, and it climbed three places in each of the last two editions.

The 2025 rename changes the threat model, not just the label. A06:2021 described a stale library with a known CVE. A03:2025 covers compromises "within or across the entire ecosystem of software dependencies," and its exposure checklist reaches IDEs, artifact repositories, build servers, and CI/CD pipelines. Its example attacks include SolarWinds, the 2025 Bybit theft, and Shai-Hulud, which OWASP calls the first successful self-propagating npm worm. We covered the release of the OWASP Top 10:2025 when the release candidate appeared on November 6, 2025. As of November 2026, the 2025 edition is final and is the current list.

Malware in a dependency lands in A08:2025 Software or Data Integrity Failures, not in A03, if you follow OWASP's own CWE mappings. A03 maps six weaknesses about stale, unmaintained, vulnerable, or insufficiently trustworthy components, such as CWE-1104 (Use of Unmaintained Third Party Components) and CWE-1395 (Dependency on Vulnerable Third-Party Component). A08:2025 maps 14 weaknesses, including CWE-506 (Embedded Malicious Code) and CWE-509 (Replicating Malicious Code). OWASP describes A08 as integrity failures "at a lower level than Software Supply Chain Failures."

The split matters because tools assign findings by CWE, not by reading OWASP's prose. Take A03's own third example. The first wave of Shai-Hulud trojanized @ctrl/tinycolor, a package with 2.2 million weekly downloads at the time. Here is what the npm registry and its audit endpoint return for it today:

$ curl -s https://registry.npmjs.org/@ctrl%2ftinycolor \
    | jq -r '.time | to_entries[] | select(.key|test("^4\\.(1|2\\.0)")) | "\(.key)  \(.value)"'
4.1.0  2024-04-13T19:04:45.788Z
4.1.1  2025-09-15T19:52:46.624Z
4.1.2  2025-09-15T20:13:43.540Z
4.2.0  2025-09-16T03:17:48.101Z

$ npm view @ctrl/tinycolor@4.1.1 version
npm error code E404
npm error 404 No match found for version 4.1.1

$ curl -s -H 'content-type: application/json' \
    -d '{"@ctrl/tinycolor":["4.1.1"]}' \
    https://registry.npmjs.org/-/npm/v1/security/advisories/bulk | jq
{
  "@ctrl/tinycolor": [
    {
      "id": 1107730,
      "url": "https://github.com/advisories/GHSA-qjqf-7j6f-82c4",
      "title": "Malware in @ctrl/tinycolor",
      "severity": "critical",
      "vulnerable_versions": ">=4.1.1 <=4.1.2",
      "cwe": ["CWE-506"],
      "cvss": { "score": 0, "vectorString": null }
    }
  ]
}

We ran these commands on November 4, 2026. The malicious versions 4.1.1 and 4.1.2 were published 21 minutes apart and have since been removed, so only their timestamps remain. The advisory record shows three properties that follow any malicious package through a CWE-driven pipeline:

1. It is classified CWE-506. Under OWASP's mapping, a dashboard that rolls findings up by OWASP category would file the textbook A03 incident under A08 and leave the A03 tile empty.
2. It is "critical" with a CVSS score of 0. The vector string is null. Any queue sorted by CVSS score puts the most dangerous finding last.
3. It has no CVE. The GitHub Advisory Database entry, GHSA-qjqf-7j6f-82c4, lists no CVE ID. A scanner that matches products to CVEs through NVD data never sees it.

The figure contrasts the two categories. A03:2025 maps six CWEs (CWE-1035, CWE-1104, CWE-1329, CWE-1357, CWE-1395, and one for use of obsolete functions) and 11 CVEs. A08:2025 maps 14 CWEs and 3,331 CVEs, including CWE-506 and CWE-509, the two weaknesses that describe malware and worms. OWASP's A03 page uses Shai-Hulud as its third example scenario, but the advisory for the Shai-Hulud versions of @ctrl/tinycolor, GHSA-qjqf-7j6f-82c4, carries CWE-506, severity critical, a CVSS score of 0, and no CVE. A tool that classifies by CWE therefore files it under A08.

Every one of those signals exists only after someone detects the malware and files an advisory. The worm itself ran from a post-install script, harvesting tokens and republishing other packages, and OWASP records that it "reached over 500 package versions before being disrupted by npm." Install time is where this attack class executes, and a database lookup that happens after install is a cleanup tool, not a defense. We made the same argument about the limits of CVE-based scanners in 2023: malware does not get a CVE.

A03's own "How to Prevent" section shows the gap. Its monitoring advice is to watch CVE, NVD, and OSV for vulnerabilities in your components. Its only control that names malicious components is to prefer signed packages, with a pointer to A08. Neither helps against a worm that publishes through a real maintainer's stolen token: as we wrote when npm v12 shipped with install scripts off by default in July 2026, the Shai-Hulud and Miasma waves "ran from compromised maintainer accounts publishing through legitimate pipelines, some with valid provenance." That release, and pnpm 10 before it, stops dependency lifecycle scripts from running unless you approve them, which removes the default execution path but not the compromised account behind it. OWASP could close part of the gap cheaply: cross-list CWE-506 and CWE-509 under A03, and tell teams to inspect what a package's code does before it runs.

ASVS and SAMM turn the Top 10's awareness categories into requirements and a maturity path. Both have dependency guidance, and both are where an auditor will actually look.

The Application Security Verification Standard (ASVS) is OWASP's list of testable security requirements. ASVS 5.0.0 was released in May 2025, on stage at Global AppSec EU in Barcelona, and its preface describes roughly 350 requirements across 17 chapters and three levels (ASVS repository). We counted the official CSV and got 345: 70 requirements at Level 1, 183 at Level 2, and 92 at Level 3. Dependency requirements live in chapter V15, and the inventory they ask for is a software bill of materials (SBOM):

We think V15.2.4 is at the wrong level. Most organizations target ASVS Level 1 or 2, so placing dependency confusion at Level 3 tells them it is a high-assurance concern. It is an ordinary one. The attack needs nothing more than a public package with the same name as an internal one, and the main defense, pinning each package name to a single registry, is mostly configuration in npm. Python still lacks a protocol-level fix, which is a reason to test for it earlier, not later.

The Software Assurance Maturity Model (SAMM) scores a whole security program rather than one application. SAMM v2, announced on January 31, 2020, has 5 business functions and 15 security practices, each split into two streams. Its Secure Build practice has a Software Dependencies stream with three maturity levels (SAMM Secure Build). Level 1 is creating bill-of-materials records. Level 2 is evaluating dependencies and reacting promptly to risk. Level 3 is analyzing dependencies for security issues with the same rigor you apply to your own code. We agree with that bar. An SBOM records what you have, not what it does, and the distance between SAMM level 1 and level 3 is where install-time malware lives.

OWASP Dependency-Check is a scanner, Dependency-Track is a platform, and CycloneDX is a data format. All three are OWASP Flagship-tier projects, and all three are mostly about known vulnerabilities.

OWASP Dependency-Check runs in a build or from the command line. It identifies each dependency, tries to find a Common Platform Enumeration (CPE) identifier for it, and links matching CVE entries (README). Since version 9.0.0 in January 2024, it pulls data from the NVD API, and its maintainers say updates are "extremely slow" without an NVD API key. That dependency on NVD product data is now a liability. In April 2026, NIST said the NVD would only enrich CVEs that appear in CISA's KEV catalog, cover software the federal government uses, or cover critical software under Executive Order 14028 (NIST officially stops enriching most CVEs). An unenriched CVE has no CPE, so a CPE matcher cannot connect it to your dependency. Dependency-Check also has a Node Audit analyzer that calls the same npm audit API shown above, which is how it can report an npm malware advisory after one exists.

OWASP Dependency-Track is a server that ingests SBOMs from CI, suppliers, or its API and continuously checks every component against several feeds, including the NVD, GitHub Advisories, and OSV. Because it re-evaluates stored inventories, it can tell you that a library you shipped last quarter got a CVE this morning.

CycloneDX is the SBOM format Dependency-Track consumes. CycloneDX joined OWASP as a Flagship project in June 2021, and version 1.6 was ratified as the Ecma standard ECMA-424 in June 2024. Ecma Technical Committee 54 (TC54), formed jointly by Ecma International and OWASP, now develops it. Socket joined TC54 in January 2025 and contributes to CycloneDX and Package URL (PURL).

Verdict: run Dependency-Track, or Dependency-Check in the build, for the inventory and CVE work that ASVS V15 and SAMM levels 1 and 2 require. Do not count either as coverage for malicious packages under A03. That requires analyzing package contents before the package manager runs them. Socket Firewall does this by wrapping the install command (sfw npm install) with a short-lived proxy that checks each requested package against Socket's analysis before it is fetched. Its free tier blocks known-malicious packages, only warns on AI-detected suspected malware, and does not block versions Socket has not yet scanned. Pre-install analysis narrows the window between publish and detection. It does not close it.

A03 has only 11 CVEs because the attacks that define it rarely produce CVEs. A compromised maintainer token, a worm in a post-install script, and a poisoned CI workflow are not weaknesses in your code that a test can find. They are events in someone else's release process. OWASP's data-driven method will undercount this category in every edition, and only the community survey kept it at number three. The next edition should measure supply chain failure the way attackers practice it: by what packages do when installed, not by which CVEs they carry.