Every Dependency & Supply Chain Audit check

OWASP A06 (Vulnerable and Outdated Components) is the category behind some of the most damaging breaches in recent memory. A single critical CVE in a production dependency — like prototype pollution in lodash or remote code execution in a widely-used serializer — gives an attacker a direct entry point into your running application. The CISA KEV catalog tracks CVEs with confirmed exploits in the wild; if any of your dependencies appear there, your production environment is actively targeted. SSDF PW.4 requires that software be tested for weaknesses, and shipping with known critical vulnerabilities is a categorical failure of that control. CWE-1357 (Reliance on Insufficiently Trustworthy Component) names the exact defect class. A critical CVE is not a theoretical risk — it is a scored, published attack path with a working exploit.

Why this severity: Critical because known critical CVEs represent confirmed exploit paths against your running production application, and any single one can result in full system compromise or data exfiltration.

High-severity CVEs documented under OWASP A06 and CWE-1357 may not have immediate public exploits, but they represent scored weaknesses in production code that attackers actively scan for. A high-severity SSRF vulnerability in `axios` (CVE-2021-3749) or a ReDoS in a string-processing library can be chained with other weaknesses to achieve full compromise. SSDF PW.4 requires software weaknesses be identified and addressed; carrying known high-severity CVEs means that control is failing. Unlike critical CVEs, high-severity issues may not immediately block your CI, but they accumulate into a risk debt that eventually gets called in — often at the worst possible moment. The fix window should be measured in days, not sprints.

Why this severity: High because these CVEs have confirmed security impact and are often exploitable given the right application context, even if they lack a universal remote exploit.

Without a committed lock file, every `npm install` — on your machine, in CI, and at deploy time — is a fresh resolution against whatever versions are current on the registry at that moment. A transitive dependency can silently update between your local install and the production deploy, introducing a behavioral change or a newly-published vulnerability without any visible diff. SLSA L2 requires that the build process be reproducible from a pinned source; a missing lock file breaks that invariant. CWE-829 (Inclusion of Functionality from Untrusted Control Sphere) applies because the install is pulling code from a source you haven't reviewed at that exact version. Lock files are the minimum viable proof that what you shipped is what you tested.

Why this severity: High because a missing lock file means your production environment can silently install different code than what was tested, turning any npm publish into a potential silent update to your running application.

Postinstall scripts execute arbitrary shell code with your user's filesystem and network permissions the moment anyone runs `npm install`. This is the mechanism behind several real supply chain attacks — including the `event-stream` incident — where a legitimate package was transferred to a malicious maintainer who added a postinstall that harvested crypto wallets. OWASP A08 (Software and Data Integrity Failures) covers exactly this failure mode. CWE-829 (Inclusion of Functionality from Untrusted Control Sphere) and CWE-114 (Process Control) both apply when a package executes code you have not reviewed. SSDF PW.4 requires that third-party components be vetted. A postinstall script making network requests to an unrecognized host should be treated as a confirmed incident, not a warning.

Why this severity: High because a malicious postinstall script executes with developer or CI system privileges at install time, before any code review occurs, and can exfiltrate secrets from the environment.

Dependency confusion attacks work by registering a malicious package on the public npm registry using the same name as your private internal package. When npm resolves dependencies, it may fetch the public (attacker-controlled) version instead of your private one — silently installing code that exfiltrates credentials or establishes a backdoor. This attack class has compromised systems at Microsoft, Apple, PayPal, and dozens of other organizations. OWASP A08 (Software and Data Integrity Failures) and CWE-829 (Inclusion of Functionality from Untrusted Control Sphere) define the failure. SLSA L2 requires that every dependency be verifiable against a trusted source. An `@yourcompany/internal-lib` in `package.json` with no private registry configured in `.npmrc` is an open invitation for this exact attack.

Why this severity: Critical because dependency confusion attacks have been executed successfully against major organizations and result in silent installation of attacker-controlled code on developer machines and CI systems.

Typosquatting attacks exploit fast-typing or AI-assisted package installation: an attacker registers `lodahs` or `crossenv` on npm and waits for installations. These packages typically contain postinstall scripts that exfiltrate environment variables — specifically targeting `AWS_SECRET_ACCESS_KEY`, `DATABASE_URL`, and similar credentials that are almost universally present in developer environments. OWASP A08 (Software and Data Integrity Failures) and CWE-829 both apply. CWE-1357 covers the reliance on an insufficiently trustworthy component. AI coding tools that auto-generate `npm install` commands are particularly vulnerable to this vector because they may hallucinate a package name that closely resembles a real one. A single character transposition in a production dependency name can mean you're running attacker code.

Why this severity: Medium because typosquatting requires the malicious package to be installed — the attacker depends on a typographic error — but the consequence when triggered is immediate credential exfiltration.

Abandoned packages are a latent supply chain risk: they accumulate unpatched CVEs indefinitely, and their maintainers cannot respond to security disclosures. When an abandoned package becomes popular enough to be a valuable attack surface, malicious actors have successfully requested and received maintainer access — precisely to insert backdoors into what appears to be a legitimate, versioned dependency. OWASP A06 (Vulnerable and Outdated Components) explicitly covers this scenario. CWE-1104 (Use of Unmaintained Third Party Components) names the defect class. SSDF PW.4 requires ongoing vulnerability tracking; you cannot track vulnerabilities in a package whose maintainer has gone dark. The longer an abandoned package stays in your dependency graph, the more likely it becomes that you'll be the last project to find out it was compromised.

Why this severity: Medium because abandonment itself doesn't introduce an immediate exploit, but it guarantees that any future vulnerability in that package will go unpatched and unannounced.

Deprecated packages receive no further releases, which means any vulnerability discovered after the deprecation date will never be patched by the original maintainer. OWASP A06 (Vulnerable and Outdated Components) and CWE-1104 (Use of Unmaintained Third Party Components) define this risk precisely. The `request` library — deprecated in 2020 — is still found in production codebases years later, and every CVE filed against `node-fetch` or `axios` since then represents a risk that `request` users cannot mitigate. SSDF PW.4 requires that known weaknesses in components be identified and addressed; shipping a deprecated dependency means you've accepted permanent vulnerability exposure for whatever the package does.

Why this severity: High because deprecated packages cannot receive security patches, meaning any CVE discovered after deprecation creates permanent, unresolvable vulnerability exposure in your production stack.

A production dependency with under 50 weekly downloads has almost no community scrutiny — no one is filing issues, no one is reviewing commits, and no one is running automated CVE scans against it. This makes it an ideal target for a supply chain takeover: an attacker can register a nearly identical package name or, if the package is already published, request maintainer access from an unresponsive original author. OWASP A06 covers the risk of components without active community oversight. CWE-1357 applies when the trustworthiness of a component cannot be independently verified. Low download counts also serve as a signal for typosquatting — the intended package likely has orders of magnitude more downloads than the misspelled one you may have accidentally installed.

Why this severity: Medium because very low download counts indicate a package that is essentially unaudited by the community, making it both higher-risk to trust and harder to get security disclosures for.

Wildcard and unbounded version specifiers like `*`, `latest`, and `>=1.0.0` mean that every `npm install` across your team and CI pipeline can resolve to a different package version — potentially including versions published hours ago by a compromised maintainer. SLSA L2 requires that the build be reproducible from a pinned artifact; `"package": "latest"` makes that impossible. CWE-1357 covers reliance on components that cannot be verified to a fixed state. SSDF PS.1 (Protect All Code from Unauthorized Access and Tampering) implicitly requires that the software composition be deterministic. AI tools in particular have a habit of generating `"latest"` as a version specifier — it seems convenient but it converts every `npm install` into a potential silent update from the registry.

Why this severity: Medium because wildcard versions allow any future npm publish — including a malicious one from a compromised maintainer — to silently become your production code on next install.

Running a major version that is 2+ releases behind the current means you are on a branch of the dependency that no longer receives backported security patches. React 16 does not receive fixes for vulnerabilities discovered in React's rendering pipeline. Express 3 has not received security patches since 2015. OWASP A06 (Vulnerable and Outdated Components) directly names major version lag as a risk vector. CWE-1104 (Use of Unmaintained Third Party Components) applies when the installed major version has reached end-of-life. The deeper the lag, the larger the eventual migration — skipping from React 16 to 19 requires addressing three sets of breaking changes simultaneously, while each single-major upgrade is manageable. Major version lag is technical debt with a compounding interest rate.

Why this severity: Low because being one or two majors behind does not introduce immediate exploits, but it accumulates migration debt and means security patches from the current major branch do not apply to your version.

GPL-3.0 and AGPL-3.0 are strong copyleft licenses: if you distribute software that includes GPL-licensed code as a combined work, you are legally required to release your entire application's source code under the GPL. AGPL extends this obligation to server-side use — running an AGPL-licensed library as part of a SaaS application may trigger source disclosure obligations. This is not a theoretical risk; companies have faced legal action for GPL non-compliance. CWE-1357 covers the risk of using components whose terms you have not adequately evaluated. This check is rated critical because the business consequence — compelled open-sourcing of proprietary code — is irreversible and can fundamentally undermine your competitive position or commercial model.

Why this severity: Critical because GPL or AGPL in production dependencies of a proprietary commercial application may legally compel source disclosure of the entire codebase, an irreversible and commercially catastrophic outcome.

In most jurisdictions, software without a license is implicitly 'all rights reserved' — you have no legal permission to use it, even if it is freely distributed on npm. A production dependency with an absent, `UNLICENSED`, or unrecognizable license field exposes you to IP claims from the original author at any time. CWE-1357 applies because you are relying on a component whose terms of use cannot be verified. Unlike the copyleft check, unknown licenses represent legal uncertainty in all directions: you do not know whether commercial use is permitted, whether redistribution triggers obligations, or whether the author intends to change the terms. This risk is amplified when AI tools generate `npm install` commands for packages they may have hallucinated.

Why this severity: High because using software without a valid license means you have no legal permission to do so, exposing the business to IP claims from the original author with no clear defense.

License incompatibilities create legal obligations that may be impossible to satisfy simultaneously. GPL-2.0 and Apache-2.0 are considered mutually incompatible for combined works because the Apache patent termination clause is inconsistent with GPL-2.0's terms — the FSF and OSI both document this. If your production application statically links both, the resulting combined work cannot be legally distributed under either license. Creative Commons licenses applied to code — rather than content — create a different set of incompatibilities with standard software licenses. The consequence is that your software may not legally be shipped or distributed in its current form, regardless of your intent or how the components are actually used at runtime.

Why this severity: Medium because license conflicts require legal analysis to resolve and may prevent compliant redistribution of the combined work, but typically do not affect SaaS applications that don't distribute binaries.

MIT, Apache-2.0, and BSD licenses all carry attribution requirements: you must preserve copyright notices and license texts when distributing the software. Without a license inventory, you cannot verify that you are meeting these obligations, and during any commercial transaction — acquisition, enterprise sales with contractual IP representations, or legal due diligence — the absence of a license inventory is a red flag that slows or blocks the deal. SSDF PW.4 treats third-party component tracking as a requirement, not a nice-to-have. A license inventory is also the prerequisite for any copyleft or conflict check to be meaningful: you cannot evaluate what you have not enumerated.

Why this severity: Low because missing attribution documentation is a compliance gap rather than an active vulnerability, but it becomes a blocking issue during legal due diligence or enterprise sales.

Every production dependency is an additional attack surface: a potential CVE vector, a maintenance obligation, an install-time script that executes on every developer machine and CI run, and an entry in your lock file that must be audited. SSDF PW.4 requires that the software composition be evaluated; an excessive dependency count means you have more components to track, more advisories to monitor, and more attack surface to defend than the project's functionality justifies. CWE-1357 scales with the number of third-party components you rely on. AI coding tools in particular routinely install duplicate-purpose packages — both `axios` and `node-fetch`, both `dayjs` and `date-fns` — because they generate installs session-by-session without a holistic view of what's already present.

Why this severity: Medium because an inflated dependency count multiplies audit overhead, attack surface, and install-time risk proportionally — each unnecessary package is a supply chain vector that provides no value.

Bundle size directly affects Time to Interactive, Core Web Vitals scores, and user-perceived performance — all of which influence both conversion rates and Google search ranking. A 67KB gzipped `moment` import on a page that formats one date adds payload weight that could instead be eliminated by a two-line switch to `dayjs`. Beyond performance, heavy packages often bundle more code than you use, increasing the attack surface of your client-side JavaScript: a compromise of the package affects all the functionality bundled in, not just the features you call. The ISO 25010 performance-efficiency characteristic explicitly covers minimizing resource consumption relative to functional requirements.

Why this severity: Low because heavy packages degrade performance rather than introduce direct security vulnerabilities, but they measurably increase bundle size, slow page loads, and expand client-side attack surface.

Two major versions of the same package installed simultaneously means two copies of that code running in your application. For React, this causes hooks to fail silently or crash at runtime because each copy maintains its own internal state. For validation libraries, it means validators from one version cannot accept instances created by the other. The ISO 25010 maintainability characteristic is directly degraded: duplicate packages make the dependency graph non-deterministic from a debugging standpoint and inflate install size without adding functionality. Duplicate packages most commonly appear when you upgrade a direct dependency but a transitive parent still pins the old major — the resolution is visible in the lock file but invisible at the source code level.

Why this severity: Low because duplicate major versions rarely introduce security vulnerabilities directly, but they cause subtle runtime failures and inflate bundle size in ways that are difficult to diagnose without explicit dependency graph inspection.

Barrel imports like `import _ from 'lodash'` or `import AWS from 'aws-sdk'` pull the entire library into the module graph at bundle time. Even with tree-shaking, not all packages are written to be tree-shakeable — lodash's default export is a single object, not named exports, so tree-shaking cannot eliminate the unused functions. The result is a client bundle that includes code paths you never call, increasing both payload size and the attack surface of your front-end JavaScript. The ISO 25010 performance-efficiency characteristic requires that resource use be proportional to functional demand; importing 71KB of utility functions to use three of them is a direct violation of that principle.

Why this severity: Low because inefficient imports increase bundle size and attack surface but do not introduce direct security vulnerabilities — the impact is performance degradation and unnecessary client-side code exposure.

A runtime package in `devDependencies` will silently disappear when your deployment runs `npm install --production` or `NODE_ENV=production` — causing runtime crashes that only surface in production, not local development or CI. Conversely, build tools like `jest`, `eslint`, and `typescript` in `dependencies` bloat your production install, increase container image sizes, and expand the attack surface of your production environment with tooling that was never meant to be deployed. OWASP A06 applies when the wrong set of packages is present in the production environment. CWE-1357 covers unnecessary components in the production software composition. SSDF PW.4 requires that the production component set be intentionally defined and reviewed.

Why this severity: High because a runtime package accidentally in devDependencies causes guaranteed production crashes when installed with `--production` or `NODE_ENV=production`, while build tools in dependencies silently expand production attack surface.

Unused production dependencies are pure supply chain liability: they represent packages that must be audited for CVEs, monitored for deprecation, and maintained through version upgrades — all while providing zero functionality. CWE-1357 applies directly: relying on more third-party components than your software requires increases the attack surface proportionally. SSDF PW.4 requires that the software composition be intentional and minimal. AI coding tools are the primary source of unused dependency accumulation — they install a package to explore an approach, then implement a different solution, but never run `npm uninstall`. The result is a `package.json` that describes a project that never existed.

Why this severity: Info because unused dependencies do not themselves contain vulnerabilities in the running application, but they are pure supply chain overhead that increases audit burden without contributing any functionality.

Without bundle analysis tooling, you have no visibility into the JavaScript payload your users download. A single `npm install` can add 100KB to your production bundle without any visible signal in your development workflow — and that cost compounds with each new dependency. The ISO 25010 performance-efficiency characteristic requires that resource use be measured and managed relative to functional requirements; shipping an unmeasured bundle means you cannot know whether that requirement is being met. SSDF PW.4 treats third-party component evaluation as ongoing, not one-time. Bundle analysis is the instrumentation that makes that evaluation possible: you cannot manage what you cannot see.

Why this severity: Info because the absence of bundle analysis tooling is an observability gap rather than an active defect — but without it, you have no mechanism to detect when a new dependency significantly degrades client-side performance.