DEV Community: Rushabh Shah

What Log4Shell taught us about open-source supply-chain security

Rushabh Shah — Wed, 07 Oct 2026 04:42:06 +0000

On 9 December 2021, a security researcher publicly disclosed a critical remote code execution vulnerability in Apache Log4j 2, a Java logging library used by hundreds of millions of systems worldwide. Within hours, proof-of-concept exploits were circulating. Within days, CISA, the NSA, the FBI and security teams around the world were in full emergency response mode.

CVE-2021-44228, quickly nicknamed Log4Shell, became the defining supply-chain security incident of the decade. Four years later it's worth examining what it actually revealed about how software is built and consumed — because most of the underlying vulnerabilities in process and practice are still present.

Why it was so bad

Log4j is a transitive dependency. Most of the systems it ran on didn't import it directly. It was imported by the logging framework used by the web framework used by the application framework used by the actual product. Three, four, five levels deep in a dependency tree, in software that had been running unchanged for years.

That's why the question "do we use Log4j?" was so hard to answer. Developers who had never heard of Log4j were running it. When you ask a developer what their application depends on, they'll tell you the 20 packages in their pom.xml. They often can't tell you what those 20 packages depend on. The actual dependency tree of a medium-sized Java application routinely has 400–800 components.

The lesson: you cannot know your exposure to a vulnerability if you don't have a complete, machine-readable inventory of your dependencies — including transitives.

The tools weren't ready

Many organizations discovered during Log4Shell that their vulnerability scanning tools were either:

Not covering transitives — only checking direct dependencies against the CVE database.
Slow to update — commercial scanners that relied on vendor-maintained databases (rather than the OSV mirror) took days to get signatures for Log4Shell variants (there were four CVEs in two weeks).
Not deployed — teams had scanners available in theory but not integrated into CI/CD, so the check was manual and ad hoc.

The open-source OSV project, which Log4Shell helped drive adoption of, operates a different model: advisories are submitted by security researchers and ecosystem owners, the database is open and machine-readable, and it covers transitives by design.

Why the patch cycle was so painful

After Log4j 2.15.0 was released to fix the initial CVE, it was found to have a partial bypass (CVE-2021-45046), requiring 2.16.0. Then a DoS vulnerability was found (CVE-2021-45105), requiring 2.17.0. Then a separate RCE in the 1.x branch was found (CVE-2019-17571, which had been known but deprioritised) and a new one (CVE-2022-23302). Organizations that thought they were done patching kept getting pulled back.

The lesson here is that knowing the version you're running is not enough — you need to know the exact CVE history for each component you ship, and you need to be able to update that knowledge quickly when new advisories are published.

What actually protects you

Log4Shell accelerated adoption of several practices that were already best-in-class:

Automated dependency scanning in CI. If scanning runs on every PR, Log4Shell-class vulnerabilities are caught when they enter your dependency tree, not six months later during a security audit. The scan should cover the full transitive tree, not just direct dependencies.

SBOM generation in every build. An SBOM that's generated and stored at build time means that when a vulnerability drops, you can query "which builds contain this PURL?" rather than re-scanning every repo.

Dependency pinning in lockfiles. Lockfiles (package-lock.json, poetry.lock, Cargo.lock) record exact resolved versions, so you know precisely which version of which transitive you're shipping — not a range.

Exploitability-first prioritisation. When you have 400 vulnerable packages, you can't fix them all in a week. Log4Shell was a CVSS 10 with EPSS near 1.0 and almost immediately KEV-listed — the highest possible signal. Organizations that had already built exploitability-based triage were able to correctly identify it as the only thing that mattered that week.

VEX documents for your customers. Vendors who could quickly produce a Vulnerability Exploitability eXchange (VEX) document saying "we use Log4j but in a configuration where JNDI lookup is disabled and we are not vulnerable" saved enormous amounts of time on both sides of supplier relationships.

The supply-chain attack surface didn't shrink after Log4Shell. The xz-utils backdoor in 2024 — a deliberately inserted backdoor in a widely-used compression library — showed that the problem extends beyond accidental vulnerabilities to deliberate supply-chain compromise. The practices Log4Shell accelerated remain the best defence.

Open-source license compliance for developers: MIT, Apache 2.0, GPL and beyond

Rushabh Shah — Sat, 03 Oct 2026 10:49:59 +0000

Most developers have read the words "MIT License" at least a hundred times and couldn't explain what they actually permit or require. That's fine until the day someone in Legal asks you to audit the licenses in a product you're about to ship, or until you open-source your work and discover it's tangled up with a copyleft library.

Open-source licenses are legal contracts. They grant you rights to use, modify and redistribute code — but with conditions. Understanding those conditions matters in three situations: when you're using open-source code commercially, when you're distributing software to customers, and when you're open-sourcing your own work.

The permissive licenses (low obligation)

MIT is as permissive as it gets: you can use, copy, modify, merge, publish, distribute, sublicense, and sell the software with no restrictions beyond including the copyright notice and license text. A NOTICE file that lists the MIT dependencies you ship satisfies your obligations. MIT is compatible with everything.

BSD 2-Clause and 3-Clause are nearly identical to MIT. BSD 3-Clause adds a non-endorsement clause (you can't use the project's name to promote your product) that rarely matters in practice.

ISC License is MIT-equivalent and used heavily in the npm ecosystem (OpenSSH, many Node.js core utilities).

Apache License 2.0 is permissive but adds two significant clauses over MIT:

Patent grant — contributors explicitly grant you a license to any patents they hold that are necessarily infringed by the code.
Patent retaliation — if you sue anyone for patent infringement related to the software, your license terminates.
NOTICE file requirement — you must include the NOTICE file from Apache-licensed components in your distribution.

Apache 2.0 is generally preferred over MIT for commercial use because the explicit patent grant protects you from patent claims by contributors. Apache 2.0 is not compatible with GPL 2.0 (because of the additional conditions), but is compatible with GPL 3.0.

The weak copyleft licenses (medium obligation)

LGPL (GNU Lesser General Public License) applies to libraries and requires that the LGPL library remain modifiable by the end user. In practice:

You can use an LGPL library in a proprietary application if users can replace the LGPL component (e.g. it's dynamically linked and you provide a mechanism to swap it).
If you statically link the LGPL library into your binary, you're effectively distributing it as part of your software and need to comply with the linking requirements.
Modifications to the LGPL library itself must be published under LGPL.

LGPL is the license for many widely-used libraries: Qt, glibc, FFmpeg.

Mozilla Public License 2.0 (MPL-2.0) is file-level copyleft: modifications to MPL-licensed files must be shared under MPL, but you can combine them with proprietary code. It's a practical middle ground for commercial use.

Eclipse Public License (EPL) is similar to MPL but at the module level. Contributions to EPL modules must be shared, but combining with proprietary code is permitted.

The strong copyleft licenses (high obligation)

GPL 2.0 and GPL 3.0 are the "viral" licenses that commercial developers fear. Any software that incorporates GPL-licensed code and is distributed to users must be distributed under the GPL as well, with source code. If your commercial product statically links a GPL library and ships to customers, your product must also be GPL.

The critical caveat: network use is not distribution under GPL 2.0/3.0. Running GPL software on a server and making it available over a network (SaaS) does not trigger copyleft. This is the so-called "ASP loophole" that the AGPL was designed to close.

AGPL (Affero GPL) extends GPL to cover network use. If your SaaS uses an AGPL library, users accessing it over the network are considered to receive the software, and you must provide the AGPL source. Many commercial organizations have an explicit policy against using AGPL dependencies.

Practical compliance steps

Generate a NOTICE file. For every permissive dependency you ship, include the copyright notice and license text. This is a legal requirement for MIT, BSD and Apache 2.0 — not optional. DepWarden generates this automatically.

Audit before you ship. The time to discover a GPL library deep in your transitive tree is before the customer agreement is signed, not after. A dependency scan with SPDX categorisation surfaces this.

Separate concerns. Keep copyleft code in clearly separated modules, invoked via a well-defined API rather than imported directly, if you must use it at all. Dynamic linking (rather than static) gives you more flexibility with LGPL.

Track license changes. Libraries change licenses between versions. Redis went from BSD to SSPL. Elasticsearch moved from Apache 2.0 to Elastic License. A scanner that checks licenses at scan time, not just at adoption time, catches these changes.

Dual-licensed libraries. Some libraries offer both an open-source license and a commercial license. MySQL (GPL + commercial), Qt (LGPL + commercial), and many others follow this model. If you need to avoid the open-source obligations, purchasing a commercial license is the legitimate path.

The bottom line: permissive licenses (MIT, Apache 2.0, BSD) allow commercial use with attribution. Weak copyleft (LGPL, MPL) requires sharing modifications to the library but allows proprietary combination. Strong copyleft (GPL, AGPL) requires distributing your entire work under the same terms. Knowing which category each dependency falls into, before you ship, is non-negotiable for any commercial product.

Run this check on your own project with DepWarden's free open-source license compliance checker — SPDX categorisation and a generated NOTICE file, no account needed.

OpenSSF Scorecard explained: catching risk in packages that don't have a CVE yet

Rushabh Shah — Wed, 30 Sep 2026 16:52:51 +0000

Most dependency scanners only tell you about vulnerabilities that already have an advisory filed against them. That's useful, but it's inherently reactive — it only catches risk after someone has found and disclosed it. OpenSSF Scorecard takes a different angle: instead of asking "has this package been proven vulnerable," it asks "does this package show the hygiene signals of a project that's actively maintained and hard to compromise." That second question catches risk earlier, before an incident, not after one.

What Scorecard actually measures

Scorecard runs a set of automated checks against a project's public repository and CI configuration and produces a score from 0–10 across roughly 18 checks. The ones that matter most for supply-chain risk:

Maintained — has the project had commits or releases in the last 90 days, or is it effectively abandoned?
Branch protection — can a single compromised maintainer account push directly to the default branch, or does it require review?
Code review — are changes actually reviewed by someone other than the author before merging?
Dangerous workflow — does the CI configuration have script-injection patterns or run untrusted code with write access to secrets?
Pinned dependencies — are the project's own build dependencies pinned to a hash, or can a compromised upstream silently change what gets built?
Vulnerabilities — does the project have known, unfixed vulnerabilities of its own?
Token permissions — does CI use the principle of least privilege for its tokens, or does everything run with full write access?

Each check is a proxy for a real incident pattern. Branch protection and code review are the checks that would have made the XZ Utils backdoor (introduced via a subtly malicious commit from a trusted-looking maintainer account) meaningfully harder to slip in. Dangerous workflow and token permissions are the checks that catch the GitHub Actions script-injection class of attack that's been used to steal CI secrets from dozens of popular projects.

Why this matters even without a CVE

A package with a low Scorecard score isn't necessarily compromised right now — it's a package where, if something goes wrong, there's less standing between an attacker and your build. An unmaintained package with no branch protection and a single maintainer is a soft target: if that maintainer's account is phished, or they sell the package to someone with bad intent (a real, repeated pattern in the npm ecosystem), there's no review process to catch a malicious release before it reaches you. None of that shows up as a CVE until after it happens.

Reading a score in context

A 10/10 score is rare and not the bar to hold every dependency to — plenty of excellent, safe packages score lower simply because they're small, stable, and don't need elaborate CI. What matters is using the score as a relative signal: a sudden drop in a package you depend on, a very low score on a package with broad reach in your tree, or a low score combined with a package that hasn't been touched in years, are the combinations worth actually looking at. Scorecard is a triage signal, not a verdict.

How DepWarden uses it

DepWarden surfaces Scorecard health alongside every dependency in a scan, so a package's maintenance risk sits next to its vulnerability findings instead of requiring a separate lookup. Combined with deprecation markers and end-of-life release-line detection, it's part of the "risk that has no CVE yet" picture DepWarden shows before it bites — the same category of signal that catches typosquatting and dependency confusion.

A free, anonymous Snyk alternative for dependency scanning

Rushabh Shah — Sun, 27 Sep 2026 10:19:47 +0000

If you've shopped for Software Composition Analysis (SCA), you've hit the same wall: the good tools (Snyk, Black Duck, Mend, JFrog Xray) want an account, gate the useful parts behind a paywall, and upload your project to their cloud.

DepWarden is a free, anonymous alternative. You paste a manifest, a lockfile, or an SBOM — or point it at a public GitHub repo — and it runs in a private, session-isolated workspace. It never receives your source code, only the dependency manifest text.

Vulnerabilities, prioritized by real exploitability

Every component is matched against the full OSV mirror, then enriched with CISA KEV (actively exploited) and FIRST EPSS (exploit probability). Instead of a wall of CVSS scores, you get a "Fix these first" list that explains why — "actively exploited + fix available + direct dependency." That's the noise reduction the paid tools charge for.

Supply-chain risk CVE-only scanners miss

Typosquats / dependency confusion — packages one keystroke from a popular one (expresss, loadsh) before they reach your build.
Dependency health — OpenSSF Scorecard, deprecation, and end-of-life release lines (e.g. "django 2.2 stopped receiving security fixes in 2022").

Actionable remediation

Not just "a CVE exists" but a batch plan — "upgrading 3 packages clears 7 findings" — plus a copy-paste fix command for your ecosystem.

Compliance round-trip

Ingest an existing CycloneDX or SPDX SBOM; export a CycloneDX SBOM, an OpenVEX document, and a NOTICE / license-obligations file.

Repeat scans with no account

Connect a GitHub, GitLab, Bitbucket or Azure DevOps repo branch with a personal access token and attach a schedule — daily, weekly or monthly — and DepWarden re-scans it automatically and emails a report. No token retained beyond the scan.

Ecosystems

npm, PyPI, Maven, Gradle, Go, Cargo, Composer, RubyGems, NuGet, Dart, Swift — manifests, lockfiles and SBOMs.

What it deliberately doesn't do

No call-graph reachability and no auto-fix PRs — both need access to your source or a GitHub app with repo write, which would break the "no account, no source upload" promise. DepWarden trades that for privacy.

Try it: paste a package-lock.json with an old lodash and a typo'd package name and you'll see the prioritized fixes, the typosquat flag, and the one-command remediation in seconds. No sign-up, at depwarden.in.

What is SAST? A developer's guide to static application security testing

Rushabh Shah — Sun, 27 Sep 2026 10:17:15 +0000

Static Application Security Testing (SAST) is the practice of analyzing source code — or bytecode, or compiled binaries — for security vulnerabilities without executing the program. A SAST tool reads your code the way a security-aware compiler would: following execution paths, tracking data flow, and flagging patterns that match known vulnerability classes. The key word is static: analysis happens offline, on source files, with no running server or test environment required.

That property makes SAST the right tool for catching security bugs when they're cheapest to fix: at the moment a developer writes the code, on every commit, in the CI pipeline before a PR is merged.

How SAST works: three technical approaches

1. Pattern matching (regex-based)

The simplest approach is pattern matching: define a regular expression for a dangerous construct (eval(, System.exec(, password =) and flag every match. This is fast, easy to write rules for, and works across any language without a parser. The downside is false positives: eval( appears in safe code too, and a regex can't distinguish whether the argument to eval is attacker-controlled or a hardcoded constant.

2. Abstract Syntax Tree (AST) analysis

More sophisticated tools parse source code into an AST — a structured tree representing the code's syntax — and analyze patterns within that structure. An AST rule can express "find all method calls to query() where the first argument is a concatenation involving a non-constant value," which is far more precise than a regex. AST analysis understands code shape rather than raw text.

3. Taint analysis / data flow

The most powerful approach is taint analysis: the tool tracks data from untrusted sources (HTTP request parameters, form inputs, user-uploaded content) through the code until it reaches a dangerous sink (database queries, shell commands, HTML output). A taint finding fires only when there is a confirmed path from source to sink with no sanitization in between.

Taint analysis is how serious SQL injection, XSS, and command injection detections work. It requires building a data flow graph across the codebase, which is more expensive than pattern matching but dramatically reduces false positives. DepWarden's SAST engine combines all three: pattern rules for broad coverage, tree-sitter AST rules for structural precision on supported languages, and an intra-file taint pass that only fires injection-class rules when user-controlled data actually reaches the sink.

The vulnerability categories SAST covers

SAST tools primarily find code-level vulnerabilities — flaws in the application's own logic:

Injection (SQL, NoSQL, LDAP, OS command) — user input reaches a dangerous API call without sanitization. CWE-89, CWE-78.
Cross-Site Scripting (XSS) — user input is reflected into HTML output without escaping, enabling script execution in the victim's browser. CWE-79.
Insecure deserialization — attacker-controlled data is passed to a deserializer that can instantiate arbitrary objects. CWE-502.
Hardcoded credentials — API keys, passwords, tokens, private keys committed directly in source. CWE-798.
Weak cryptography — MD5 or SHA-1 for password hashing, ECB mode encryption, 1024-bit RSA keys, hardcoded initialization vectors, DES/RC4 usage. CWE-327, CWE-326.
Insecure randomness — Math.random() or rand() for security-sensitive values like tokens or session IDs. CWE-338.
Path traversal — user input reaches a file system call without sanitization, allowing arbitrary file access. CWE-22.
SSRF — user-controlled URLs are fetched server-side, enabling access to internal services and cloud metadata endpoints. CWE-918.
Insecure configuration — DEBUG = True in Django settings, CSRF protection disabled, security headers absent, CORS wildcard with credentials. CWE-16.

SAST, DAST, and SCA: the three-scanner model

These scanner types are complementary, not interchangeable:

Scanner	What it finds	When it runs
SAST	Bugs in your own source code	CI, pre-commit, every PR
DAST	Bugs exposed at runtime in a deployed app	Staging environment, release gate
SCA	Vulnerabilities in open-source dependencies	CI, pre-commit, every PR

SAST catches bugs in the code you write. SCA catches bugs in the code you import. DAST catches bugs that only manifest when the application is running — misconfigured servers, race conditions, issues SAST can't reach statically. A mature security pipeline uses all three; SAST and SCA run on every commit.

Integrating SAST into CI/CD

The most valuable property of SAST is that it runs without a deployed application. Upload a source zip in the browser, or connect a GitHub, GitLab, Bitbucket or Azure DevOps repo branch and schedule recurring scans so new findings surface without you doing anything.

The key configuration choice is --fail-on. Setting it to critical only blocks the most severe findings; high blocks high and critical. Starting with critical and moving to high once you've baselined your codebase is the practical approach. Failing on medium is usually too noisy until you've tuned suppressions for your codebase.

Managing false positives

The main challenge with SAST is false positives, which create alert fatigue that causes developers to ignore the scanner entirely. Good tooling reduces false positives through:

Taint gating: Only fire injection-class rules when the data flow is confirmed. A rule that matches eval( pattern-only fires on every eval call; a taint-gated rule fires only when the argument comes from user input.

Confidence levels: Separate HIGH-confidence (taint-confirmed, specific pattern, no plausible safe use) from MEDIUM and LOW (pattern-only, more context needed). Treat them differently in CI — block on HIGH, review MEDIUM.

Suppression markers: When a specific finding is safe by design, document it in code:

// depwarden-ignore: eval-user-input — content is from a curated config, not user input
eval(configExpression);

Not-patterns: Rules can include patterns that cancel the match. A "hardcoded password" rule can exclude lines that reference process.env or os.environ, since those are reading from environment variables, not hardcoding.

What DepWarden's SAST covers

DepWarden's static analysis covers:

14 languages: JavaScript, TypeScript, Python, Java, Go, PHP, Ruby, C, C++, C#, Rust, Kotlin, Swift, Shell/Bash
IaC: Terraform/HCL, YAML (GitHub Actions, Kubernetes), Dockerfile, config/secret files
300+ rules organized into packs:
- Core injection, XSS, secrets, weak crypto (applies to all languages)
- Framework-specific: Django, Spring Boot, Express, Rails, Laravel, ASP.NET Core
- Advanced cryptography: ECB mode, DES, RC4, hardcoded IV, bcrypt cost, TLS version
- Shell script security: eval injection, wget/curl pipe exec, world-writable files
- Mobile: Android WebView, iOS keychain, SSL pinning bypass
- API & web: JWT algorithm confusion, SSRF, open redirect, GraphQL introspection

Every finding includes CWE and OWASP Top 10 mapping, severity (CRITICAL/HIGH/MEDIUM/LOW), confidence level, remediation guidance, and a redacted code snippet that never exposes actual credentials.

Findings are separated from SCA dependency results and filterable by severity, confidence, category, language, and status. The engine runs in under 10 seconds for most projects.

CVSS, EPSS and KEV: how to actually prioritize dependency vulnerabilities

Rushabh Shah — Sun, 27 Sep 2026 04:42:38 +0000

Every week a dependency scanner finds dozens of vulnerabilities. Every week most developers ignore them, because there's no time to fix 200 issues and no obvious way to know which 3 actually matter. The answer lives in three numbers: CVSS, EPSS and KEV. Understanding what each one measures — and what it doesn't — is the difference between a security backlog that never shrinks and one you can actually work through.

CVSS: severity, not risk

The Common Vulnerability Scoring System (CVSS) gives every published CVE a score from 0 to 10 based on how bad the vulnerability could be in a worst-case scenario. CVSS 9.8 sounds terrifying. The problem is that CVSS scores are entirely theoretical — they describe the vulnerability in the abstract, with no reference to how often it's actually exploited or whether attackers even care about it.

In practice, fewer than 5% of published CVEs are ever exploited in the wild. A CVSS 9.8 in a library feature you don't use, in an attack path that requires local access you don't expose, is a lower priority than a CVSS 6.0 that's actively being used in ransomware campaigns. Sorting by CVSS alone means you're sorting by worst-case theory, not real-world risk.

That's why CVSS is the starting point, not the answer.

EPSS: exploitation probability

The Exploit Prediction Scoring System (EPSS), maintained by FIRST, takes a very different approach. It's a machine-learning model trained on actual exploitation evidence — threat intelligence feeds, honeypot data, proof-of-concept exploit activity, CISA data and more. It produces a daily probability score (0–1) for the likelihood that a given CVE will be exploited in the next 30 days.

The numbers are striking: the top 1% of CVEs by EPSS account for roughly 75% of observed exploitation attempts. The bottom 80% have near-zero probability of being exploited. This means if you filter to CVEs with EPSS > 0.10 (10% probability), your fix list shrinks dramatically while still covering the overwhelming majority of real attacks.

EPSS is updated every day as new exploitation evidence arrives, so a CVE that was low-priority last month can jump to high-priority overnight if attackers start weaponizing it.

KEV: confirmed exploitation in the wild

The CISA Known Exploited Vulnerabilities (KEV) catalog is the most reliable signal of all. CISA — the U.S. Cybersecurity and Infrastructure Security Agency — maintains a manually curated list of vulnerabilities that have been confirmed exploited in real-world attacks. These aren't predictions; they're facts. If a CVE is in the KEV catalog, attackers have working exploits and are actively using them.

The KEV list is legally binding for U.S. federal agencies (CISA mandates remediation within 2–3 weeks) but is freely published for everyone. KEV entries often have EPSS scores near 1.0, but not always — a CVE targeting industrial control systems might be KEV-listed with a lower EPSS simply because the affected population is small.

KEV findings are always your highest priority, regardless of CVSS.

A worked example

Suppose a scan of a mid-sized Node.js service returns five open findings. Here's what a naive CVSS-only sort produces versus what the KEV/EPSS-aware ranking produces:

Finding	CVSS	EPSS (illustrative)	KEV	Fix available
A — RCE in a logging library, reachable from a public HTTP handler	9.8	0.94	Yes	Yes
B — Deserialization bug in an admin-only internal tool	9.1	0.02	No	Yes
C — Prototype pollution in a deep transitive utility package	7.5	0.03	No	Yes
D — SSRF in a webhook-delivery library, actively targeted this quarter	6.5	0.61	No	Yes
E — Denial-of-service in a rarely-used parsing edge case	5.3	0.01	No	No

Sorted by CVSS alone, the order is A, B, C, D, E — B (9.1) outranks D (6.5) despite D being far more likely to actually be exploited.

Sorted by KEV, then EPSS, then CVSS, the order becomes:

A — KEV-listed and the highest EPSS in the set. Fix this week, full stop.
D — not KEV-listed, but EPSS of 0.61 puts it in the top slice of real-world exploitation activity. Fix in the current sprint, ahead of B.
B — high CVSS, but an EPSS of 0.02 says almost nobody is actually exploiting it (consistent with it requiring admin access an external attacker doesn't have). Schedule normally.
C — same story as B: real bug, low real-world pressure. A fix exists, so bundle it into the next routine dependency bump rather than an emergency patch.
E — lowest EPSS, no fix available yet, and the weakest CVSS in the set. Accept and monitor; revisit if a fix ships or its EPSS moves.

The CVSS-only ranking would have burned a week fixing B before D — the finding attackers were actually using. This is the entire value of layering EPSS and KEV on top of CVSS: it's not that CVSS is wrong, it's that CVSS alone answers "how bad could this be," not "should I fix this today."

Putting them together: a practical priority order

A useful mental model:

KEV-listed + fix available → fix immediately, this week.
EPSS > 0.20 + fix available → fix in the current sprint.
CVSS Critical + EPSS < 0.05 → schedule, deprioritise over items 1–2.
CVSS Medium with no fix → accept/document, monitor.
Everything else → triage periodically, don't block releases.

Two more signals matter beyond these scores:

Direct vs transitive — a vulnerability in a package you import directly is a higher priority than the same CVE in a package five levels deep that you can't easily upgrade.
Fix availability — upgrading to a safe version is a different problem than waiting for the upstream to patch. If there's no fix, your option is mitigation or accepting the risk, not just "upgrade".

If your organisation needs a documented SLA (for a customer contract, an audit, or an internal policy), it's reasonable to turn this into fixed remediation windows: KEV-listed findings within 7 days (matching CISA's own federal mandate as a sane external benchmark), EPSS above 0.20 within 30 days, everything else on your normal release cadence. Write the policy in terms of KEV/EPSS thresholds rather than a flat CVSS cutoff — a CVSS-only SLA ("fix all Criticals within 30 days") is exactly the policy that produces the wasted-effort scenario in the worked example above.

Common mistakes teams make with these three signals

Treating CVSS as a risk score. CVSS measures theoretical severity, not likelihood. A team that gates CI purely on "no CVSS >= 7" will spend real engineering time on findings nobody is exploiting while a lower-CVSS, high-EPSS finding sits unpatched in the same backlog. Use CVSS to understand impact, and EPSS/KEV to understand urgency — they answer different questions and neither replaces the other.

Ignoring EPSS because it "isn't a real number." EPSS is a probability, not a certainty, and it does move — a score of 0.02 today can become 0.80 within days of a public proof-of-concept exploit landing. Teams that check EPSS once and never again lose exactly the signal that makes it useful. It's designed to be re-checked, not memorised.

Forgetting that KEV is a floor, not a ceiling. A vulnerability leaving the KEV catalog (CISA does periodically review and remove stale entries) doesn't mean it's safe — it means active campaigns have moved on. A vulnerability entering KEV, on the other hand, should immediately jump every other prioritisation signal you're using, including a low EPSS score computed before the exploitation started.

Sorting the whole backlog instead of triaging the top slice. You don't need a perfect ranking of 200 findings. You need a reliable way to identify the 5-10 that matter this week. Spending analyst time perfectly ordering findings 50 through 200 is wasted effort next to just clearing the KEV-listed and high-EPSS findings first and re-triaging weekly.

Where to get EPSS and KEV data yourself

Both are free and public, with no API key required for reasonable use. EPSS scores are published daily by FIRST at api.first.org/data/v1/epss — query by CVE ID and get back the current probability plus a percentile rank. CISA KEV is a single JSON file at cisa.gov's known-exploited-vulnerabilities feed, updated as CISA confirms new active exploitation; there's no per-CVE lookup API, so most tooling downloads and caches the full catalog. Combined with CVSS from NVD or the CVE's own CNA record, this is enough to build the priority order above by hand — or a scanner can fetch and merge all three automatically, which is what removes the manual step.

What DepWarden does with this

DepWarden fetches EPSS scores and KEV status daily from their respective sources alongside the OSV vulnerability mirror. In the scan results, KEV findings are called out first with a red flag, EPSS scores are shown alongside CVSS so you can compare them at a glance, and the "Fix these first" ranking uses a composite of these signals — not a raw CVSS sort — to produce a list ordered by real-world risk. The goal is to put the three actionable fixes at the top, not the eighty theoretical ones.

What is a Software Bill of Materials (SBOM) and why your team needs one

Rushabh Shah — Thu, 24 Sep 2026 04:39:33 +0000

When a critical vulnerability like Log4Shell drops at 11pm on a Friday, the first question every security team asks is: "which of our products use Log4j?" Without an SBOM, answering that question means grep-ing through build files, chasing down dependency declarations in ten different repos, and hoping nobody missed an indirect import. With an SBOM, it's a single query.

A Software Bill of Materials (SBOM) is a machine-readable inventory of every component — library, package, framework, dependency — that went into a piece of software. Think of it as a nutritional label for code: it tells you what's in there, where it came from, and which version you're running.

What an SBOM contains

A complete SBOM includes, for each component:

Name and version — the package name and the specific version shipped, not a range.
Supplier — the organization or person who published it.
PURL (Package URL) — a standardized identifier like pkg:npm/express@4.18.3 or pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1 that tools can resolve without ambiguity.
License — the SPDX identifier of the license under which the component is distributed.
Hashes — cryptographic checksums (SHA-256 is standard) that let you verify you got what you expected.
Dependencies — which other components this one depends on, forming a graph rather than a flat list.

Modern SBOMs in the CycloneDX 1.7 format also embed VEX (Vulnerability Exploitability eXchange) data — statements about which CVEs affect your specific build and what your analysis concluded about each one.

A worked example: one component in CycloneDX

The clearest way to understand an SBOM is to look at one entry. Here's what a single component — the express npm package — looks like inside a real CycloneDX 1.7 document:

{
  "type": "library",
  "bom-ref": "pkg:npm/express@4.18.3",
  "name": "express",
  "version": "4.18.3",
  "purl": "pkg:npm/express@4.18.3",
  "licenses": [{ "license": { "id": "MIT" } }],
  "hashes": [
    { "alg": "SHA-256", "content": "9d3b..." }
  ],
  "externalReferences": [
    { "type": "vcs", "url": "https://github.com/expressjs/express" }
  ]
}

Every field earns its place: type distinguishes a library from an application, framework or OS component. purl (pkg:npm/express@4.18.3) is what makes this machine-resolvable — a vulnerability scanner takes that exact string, queries OSV or another advisory database, and gets back CVEs for this specific version, not a fuzzy name match. licenses uses a real SPDX identifier (MIT), not free-text, so a license-compliance tool can categorise it automatically. hashes lets a consumer verify the artifact they actually received matches what the SBOM claims — the same integrity check a checksum file gives you, but standardised and attached to the inventory itself.

A full SBOM is thousands of these entries plus a dependencies section recording the graph — which component requires which — so a scanner can distinguish a direct dependency from one four levels deep in the tree. When VEX is embedded (CycloneDX 1.7), each vulnerability gets its own statement, for example:

{
  "vulnerabilities": [{
    "id": "CVE-2024-XXXXX",
    "affects": [{ "ref": "pkg:npm/express@4.18.3" }],
    "analysis": {
      "state": "not_affected",
      "justification": "code_not_reachable"
    }
  }]
}

That single VEX statement is the difference between a scanner flagging a CVE and a security team having already recorded — in a machine-readable, auditable way — that this specific build doesn't actually reach the vulnerable code path. Without VEX, every downstream consumer of your SBOM re-does that analysis themselves.

The two main formats: CycloneDX and SPDX

CycloneDX is an OWASP standard designed specifically for security use cases. It's JSON or XML, compact, and well-supported by tools that want to do something with the SBOM — like scanning it for vulnerabilities or generating VEX documents. CycloneDX 1.7 (the current version) includes full dependency graphs, license expressions, external references, compositions, and embedded VEX.

SPDX (Software Package Data Exchange) is a Linux Foundation standard originally designed for license compliance and now widely used in government procurement. It's more verbose and supports more licensing metadata. U.S. government agencies increasingly require SPDX SBOMs from their software suppliers under the May 2021 executive order on cybersecurity.

Both formats are useful and most modern tooling can ingest either. DepWarden accepts both as input and exports CycloneDX 1.7 with embedded VEX.

When an SBOM is required vs when it's useful

When it's required: U.S. federal agencies and their suppliers are increasingly mandated to produce SBOMs. The EU Cyber Resilience Act will require them for CE-marked products. Defense and critical infrastructure contracts commonly specify them. If your customer is a government agency or a large enterprise with a mature vendor security program, you'll be asked for one.

When it's useful regardless:

Incident response — when a new CVE drops, you query the SBOM rather than auditing every codebase.
Merger and acquisition due diligence — assess the security and license risk of a target's software before the deal closes.
License compliance — know every copyleft dependency before you ship, not after legal flags it.
Change tracking — diff two SBOMs across releases to see exactly what components changed, and audit the new risk.

Common SBOM mistakes

Generating one, once, and calling it done. An SBOM captures a point-in-time inventory. The moment you bump a dependency or add a new one, it's stale — and a stale SBOM that says "no known vulnerabilities" is worse than no SBOM at all, because it's actively misleading. The fix is mechanical: generate the SBOM as a CI/CD build step, not a periodic manual export.

Treating name+version as unambiguous. Two different ecosystems can publish a package with the same name (request exists on both npm and as an unrelated project elsewhere), and a name alone doesn't tell a tool which registry to check. This is exactly why PURLs exist — pkg:npm/request@2.88.2 is unambiguous in a way "request 2.88.2" is not. An SBOM built from name+version pairs instead of PURLs quietly reintroduces the ambiguity the format was designed to remove.

Skipping the dependency graph. A flat component list without the dependencies relationships tells you what is in your software but not how it got there — which means when a transitive vulnerability shows up, you can't answer "which of my direct dependencies do I need to bump to fix this?" without redoing the resolution by hand. A flat SBOM is still useful for inventory purposes, but it can't drive remediation on its own.

Assuming SPDX and CycloneDX are interchangeable in every field. Both describe the same underlying facts, but CycloneDX's security-first fields (VEX, vulnerability references) have no direct SPDX equivalent, and SPDX's deeper license-relationship expressions don't map cleanly back either. If your downstream consumer specifically needs VEX, generating SPDX alone won't satisfy that requirement even though it's a valid SBOM.

Generating and consuming SBOMs

Generating an SBOM from a manifest is what DepWarden does when you scan: it resolves the dependency tree, assigns PURLs, fetches license data, and exports a CycloneDX 1.7 document. Tools like Syft, cdxgen, and the CycloneDX Maven/Gradle plugins can also generate SBOMs directly from build artifacts.

Consuming an SBOM means running it through a vulnerability scanner (DepWarden accepts CycloneDX and SPDX uploads), a license checker, or a policy engine. The round-trip — generate → enrich → scan → VEX → export — is the compliance workflow most organizations need.

The key insight is that an SBOM is most valuable when it's generated automatically in CI/CD and kept up to date with every release. A one-time SBOM is better than nothing; a stale one gives false confidence.

Validating an SBOM before you trust it

An SBOM being well-formed JSON doesn't mean it's complete. Before relying on one — your own, or one a vendor handed you — check three things. First, does the component count look plausible for the project's size? A Java service reporting 12 components when its build log shows 400 resolved artifacts means the generator only captured direct dependencies, not the full transitive tree. Second, do a sample of PURLs actually resolve — pick five components and confirm the ecosystem, name and version in the PURL match a real package at that registry. Third, check whether the dependency graph is present at all, or whether every component is listed with no relationships; a flat SBOM (see above) will validate against the CycloneDX or SPDX schema perfectly while still being far less useful than a graph-complete one.

Provenance and signing

An SBOM answers "what's in this software," but not "can I trust that this SBOM accurately describes what's really running." That's a separate, complementary concern usually handled by signing the SBOM itself (so a consumer can verify it wasn't tampered with in transit) and by attaching build provenance (SLSA-style attestations describing which CI pipeline, which commit, and which build steps produced the artifact the SBOM describes). A signed SBOM with strong provenance is what a mature vendor security review is actually asking for when it requests "your SBOM" — the document alone, unsigned and with no link back to a specific build, is a good start but not the full answer regulators and enterprise buyers are increasingly expecting.

Transitive dependencies explained: why a package you never installed can still break your build

Rushabh Shah — Sat, 19 Sep 2026 05:22:42 +0000

You run a scan and get a HIGH severity finding in minimist@1.2.0. You grep your package.json — it isn't there. So why is it in your build?

Direct vs transitive

A direct dependency is one you declared yourself, in package.json, requirements.txt, pom.xml, or whatever manifest your ecosystem uses. A transitive dependency is one of those packages' own dependencies — and their dependencies' dependencies, recursively, however deep the chain goes. A typical modern JavaScript project has a handful of direct dependencies and hundreds of transitive ones. minimist is a good example: it's an argument parser almost nobody installs directly, but it sits underneath dozens of popular build tools, so it shows up in an enormous number of dependency trees without anyone choosing it.

This matters because the fix is different depending on which one you have. A vulnerable direct dependency: bump the version yourself. A vulnerable transitive dependency: you can't npm install minimist@latest and expect it to matter — you have to find which of your direct dependencies pulls it in, and bump that one (or use your package manager's override mechanism) instead.

Why lockfile "depth" is not the same as "distance from root"

If you've looked at a package-lock.json, you might assume the nesting level of node_modules/ tells you how many hops a package is from your project. It doesn't, reliably. Package managers hoist dependencies — they lift a package as high in the node_modules tree as they can without creating a version conflict, purely to save disk space and installation time. A package can be physically hoisted to the top level of node_modules (nesting depth 0) while still being a transitive dependency three levels deep in your actual logical dependency graph. Depth-in-the-filesystem and depth-in-the-dependency-graph are two different numbers, and conflating them is a common source of confusion when triaging findings.

Tracing a package back to its root

The question that actually matters when you see a vulnerable transitive package is: which direct dependency do I need to upgrade to make this go away? Answering that requires walking the real dependency graph — the parent-to-child edges recorded in the lockfile — backward from the vulnerable package until you reach something declared in your manifest.

DepWarden builds this graph from your lockfile (npm, yarn, pnpm, Maven's effective POM resolution, Go's module graph, Cargo's resolver output, and more) and exposes it two ways. The dependency graph view shows the whole tree so you can see how deep and wide your third-party surface actually is. The dependency tree / trace-to-root search lets you type a package name and instantly see every direct dependency that pulls it in, with the actual path — so "why is this even installed" has a concrete answer instead of a guess.

What to actually do about it

Once you know the path, there are three real options: upgrade the direct dependency to a version that itself pulls a fixed version of the transitive package; use your package manager's override/resolution field (overrides in npm, resolutions in Yarn, dependency management in Maven) to force the transitive version directly; or, if neither is available yet, treat it as accepted risk with an expiring exception rather than silently ignoring it. DepWarden's minimal-fix solver checks the first option automatically — for a given transitive CVE, it tells you which direct dependency to bump and whether the latest release of that dependency actually resolves the issue, so you're not upgrading blind.

Catch typosquats and dependency confusion in CI (for free)

Rushabh Shah — Mon, 14 Sep 2026 08:25:12 +0000

Most "dependency scanners" only tell you about known CVEs. But a huge class of real supply-chain attacks has no CVE at all: typosquatting (publishing expresss to catch people who fat-finger express) and dependency confusion (publishing a public package with your internal name so it gets installed instead).

Trivy, Grype and Dependabot won't flag these — there's no advisory to match. By the time there is one, the malicious postinstall has already run in your CI.

The cheap, effective check

A name that's a single edit away from a very popular package, but isn't that package, is almost always malicious or a mistake. That's exactly what DepWarden flags — for free, no account, and without uploading your source. Connect a GitHub, GitLab, Bitbucket or Azure DevOps repo branch with a PAT and schedule recurring scans, and every run checks your lockfile for these names again.

A typosquat shows up as a HIGH supply-chain finding:

[HIGH] expresss :: Possible typosquat of "express"

Beyond typosquats

The same scan surfaces what classic tools skip: OpenSSF Scorecard health, deprecated packages, and end-of-life release lines — alongside OSV/KEV/EPSS-prioritized vulnerabilities.

Try it on your own lockfile at depwarden.in — no sign-up required.

How npm typosquatting and dependency confusion attacks work (and how to stop them)

Rushabh Shah — Thu, 10 Sep 2026 06:42:05 +0000

In February 2021, security researcher Alex Birsan published a paper describing how he had successfully deployed malicious packages to the internal build systems of Apple, Microsoft, PayPal, Shopify, and 32 other companies. He did it without hacking a single server, exploiting a single CVE, or phishing a single developer. He published packages to npm, PyPI and RubyGems with names matching internal packages those companies used — and their build systems installed his public versions automatically.

This is dependency confusion. It doesn't have a CVE because the vulnerability isn't in the package — it's in the resolution logic of package managers. And it's just one flavour of supply-chain attack that pure CVE-based scanners completely miss.

Typosquatting: catch the typo, own the build

Typosquatting exploits the fact that developers type package names by hand. Publish expresss to npm (with three s's) and anyone who makes that common typo in npm install pulls down whatever you put in the package. Publish it with a convincing README, a few hundred weekly downloads from bots, and a malicious postinstall script, and you have a stealthy credential-stealing payload reaching developer machines and CI pipelines.

Real examples from npm's history:

crossenv — a typosquat of cross-env that stole environment variables (which often contain API keys and tokens).
getcookies — embedded in a legitimate-looking utility, exfiltrated browser cookies.
loadsh — typosquat of lodash, one of the most-downloaded npm packages.
reqeusts / reqests — multiple typosquats of the Python requests library.

The postinstall script is the key mechanism: npm runs it automatically when the package installs, before you've had a chance to read the code. A malicious postinstall can exfiltrate environment variables, install persistent backdoors, or modify other packages in node_modules.

Dependency confusion: the namespace collision attack

Dependency confusion exploits a different logic flaw. Many companies use a private npm registry (Artifactory, Nexus, GitHub Packages) alongside the public npm registry. When a package manager is told to look up a package, most configurations check the public registry if the private one doesn't have it — or check both and take the highest version.

Birsan's attack: find the name of an internal package (often visible in job postings, leaked config files, or error messages), publish a public package with the same name at a version number higher than the internal one (e.g. 99.0.0), and wait for build systems to install the "newer" public version.

The fix at the package manager level is to scope all internal packages under a private namespace (@company/internal-lib rather than internal-lib) and configure the registry to only allow scoped packages from the private registry. But this requires intentional configuration that many teams never got around to.

What detection looks like

CVE-based scanners can't catch these attacks because there's no CVE. The signals that matter:

Typosquat detection uses edit distance algorithms (Levenshtein, Damerau-Levenshtein) to find packages in your dependency tree whose names are suspiciously close to popular packages but aren't those packages. A package one character transposition away from lodash, express or react with no established publishing history is a strong signal.

Install-script presence is a risk signal on its own. Legitimate packages rarely need to run code at install time. A package with a postinstall script from an unknown publisher warrants scrutiny, especially if it appeared recently in your tree.

Maintainer and publish history signals: a package published 3 days ago with 0 dependents and a postinstall script that matches a popular name is almost certainly malicious or a testing mistake. Package maintainer changes on established packages — the XZ Utils backdoor mechanism — are similarly high-signal.

Version anomalies: a version number that skips from 1.0.4 to 99.0.0 is a classic dependency confusion marker.

DepWarden's approach

DepWarden flags typosquats using a Damerau-Levenshtein edit-distance check against a curated list of the most popular packages in each ecosystem. A package one keystroke away from a popular one that isn't that package gets a supply-chain finding (HIGH severity) with the specific match it resembles.

Install-script presence, maintainer-change signals and version anomalies from the OpenSSF Scorecard and supply-chain metadata are also surfaced — the signals that have no CVE but matter enormously in the real attack landscape.

The important point: these attacks happen before a CVE is ever filed, if one ever is. By the time there's a CVE for loadsh, the attack has already run. The only defence is catching the suspicious signal upstream.

Curious how many of these look-alike names are actually live on the registry right now? We checked every single-character typo of the 30 most popular npm and PyPI packages against the real registries and cross-referenced the hits against OSV's malicious-package database — see the full data.

We checked every single-typo of the 30 most popular npm and PyPI packages. Here's what's actually registered.

Rushabh Shah — Mon, 07 Sep 2026 11:34:11 +0000

Typosquatting is one of the best-documented supply-chain attack techniques — publish a package one keystroke away from something popular, wait for developers to fat-finger npm install, and you have a foothold on their machine or CI pipeline with no CVE ever filed. It's been written about for years. What's less documented is a very simple question: right now, today, how many of those look-alike names are actually sitting on the registry?

So we checked. Not a sample, not an estimate — every single-character typo (omit a letter, double a letter, swap two adjacent letters — the three classic patterns) of the 30 most popular packages on npm and the 30 most popular on PyPI, queried live against each registry's real API, then cross-referenced every hit that's actually registered against OSV.dev's public malicious-package database.

The headline numbers

npm: 498 candidate typo names checked across 30 popular packages. 297 (59.6%) are currently registered, real packages. Of those 297, 97 (32.7%) are already documented as malicious in OSV's public database — not "suspicious," not "flagged by us," but carrying a real MAL- or GHSA- advisory ID today.
PyPI: 582 candidate typo names checked across an equally popular 30-package set. 47 (8.1%) are registered. Zero are flagged malicious in OSV.

Same technique, same rigor, same day. One ecosystem where a third of the look-alikes you'd stumble into are already confirmed hostile; the other where the exposure — at least via this specific single-typo technique — is close to zero.

Methodology

This mirrors the exact detection method DepWarden uses in production: Damerau–Levenshtein edit-distance matching against a curated list of high-popularity package names. For this study we narrowed to the three typo patterns that account for the overwhelming majority of real-world typosquats (and match the classic examples — expresss, epxress — that show up in every writeup of this technique):

Omission — drop one character (express → expres)
Duplication — double one character (express → expresss)
Adjacent transposition — swap two neighboring characters (express → epxress)

For each of the 30 most popular packages per ecosystem, every candidate generated by these three rules was checked against the real registry API (registry.npmjs.org for npm, pypi.org/pypi/.../json for PyPI) — a 200 response means it's a real, currently-published package. Every hit was then queried against api.osv.dev for any associated advisory. Nothing here is inferred or estimated; every count is a live HTTP response, checked on 25 August 2026.

What this deliberately doesn't claim: a registered look-alike name is not automatically malicious. Plenty of short candidate strings (vue → ve, next → net) collide with legitimate, completely unrelated packages that just happen to be short common words — npm alone has over 3 million packages, so some collision is inevitable. That's exactly why the OSV cross-reference matters: it's the difference between "this name exists" (weak signal) and "this specific package is a documented, named threat" (real finding). The 97/47 split above is the second kind.

Which popular packages attract the most confirmed-malicious squats

Popular package	Confirmed-malicious typo variants found
request	17
lodash	9
express	9
chalk	8
commander	8
async	8
react	7
debug	5
bluebird	5
moment	4

request — deprecated since 2020 but still one of the most-installed packages in npm history from years of accumulated dependents — tops the list by a wide margin. That's a pattern worth naming explicitly: an old, extremely popular, no-longer-actively-maintained package appears to be a more attractive squatting target than a young one, plausibly because the volume of developers who've typed its name from memory (and therefore mistyped it) over the package's lifetime is simply larger. We're not claiming causation from an n=30 sample, but the shape of the data points that way.

The full data, and how to re-run it yourself

The top-10 table above is the interesting slice, but a study you cannot check is just an assertion. So here is all of it — every candidate name, whether the registry says it is published, and every advisory id attached to it.

Download the dataset (CSV) — one row per candidate, 1,098 rows across both ecosystems.
Same data as JSON — includes the exact package lists used.
Re-run it yourself: the generator is in the DepWarden repo at scripts/typosquat-study.mjs. The package lists are hard-coded in that file on purpose, so a re-run stays comparable rather than drifting with whatever is popular this week.

Re-running the whole study on 5 September 2026, eleven days after the original pass, reproduced it closely: npm 483 candidates, 284 registered (58.8%), 99 carrying an advisory (34.9% of registered); PyPI 615 candidates, 52 registered (8.5%), zero carrying an advisory. The per-package ranking came back identical — request still first by a wide margin at 17. Counts move by a few points between runs because packages get published and unpublished and OSV adds advisories; the finding does not.

The second data point: how healthy are the real packages?

Alongside the typosquat check, we pulled real OpenSSF Scorecard scores — an independent, automated 0–10 supply-chain-hygiene rating covering branch protection, CI presence, signed releases and 15 other checks — for the same 60 popular packages (59 resolved; one npm package's GitHub mapping didn't return a score).

npm: average score 6.24/10. 20.7% score below 5. 6.9% score below 3.
PyPI: average score 6.79/10. 10.0% score below 5. 0% score below 3.

Lowest-scoring packages checked: bluebird (2.0), debug (2.6), and request (3.4) on npm; psycopg2 (3.7), setuptools (4.4), and httpx (4.9) on PyPI. Worth noting: bluebird and debug — two of the lowest Scorecard scores in the whole sample — also both appear in the confirmed-malicious-squat table above. Again, not a causal claim from this sample size, but a genuinely interesting adjacency: the same handful of enormously popular, comparatively lower-maintenance-signal packages show up on both lists.

What this means if you ship software

The practical takeaway isn't "avoid npm" — it's that single-character typing mistakes in npm install carry real, non-hypothetical, currently-live risk today, at a rate (roughly 1 in 3 of the names you could plausibly typo into) that's higher than most developers would guess. PyPI's exposure, at least to this specific attack pattern, is measurably lower — worth knowing if you're weighing where a supply-chain review should focus first.

Three concrete things that actually help: pin exact versions in a lockfile so a one-off typo in a scratch command doesn't become a permanent dependency; use a scanner that checks for typosquat-shaped names as a distinct signal from CVE matching, since (by definition) none of these 97 malicious packages have a CVE; and treat an unfamiliar package with a name suspiciously close to something you know — one character off, one character doubled — as worth a second look before installing, especially if it has few downloads and a recent publish date.

DepWarden runs this same detection — Damerau-Levenshtein matching against a curated popular-package list per ecosystem — on every scan, free, no account required. Related reading: how npm typosquatting and dependency confusion attacks work, detecting typosquats in CI, what the OpenSSF Scorecard actually measures.

SAST vs SCA: why your CI pipeline needs both

Rushabh Shah — Mon, 29 Jun 2026 11:13:44 +0000

When security teams talk about "scanning" code in CI/CD, they usually mean one of two very different things: scanning the code you wrote (SAST) or scanning the open-source code you imported (SCA). Both are called "security scanners." Both produce findings with severities and CVE-like identifiers. But they catch almost completely different vulnerability classes, and understanding that distinction determines whether you actually close your real risk gaps or just feel like you have.

What SAST scans

Static Application Security Testing (SAST) reads your source code — the JavaScript, Python, Java, Go, Ruby files that your team writes — and looks for security flaws in the code itself. SQL injection in a database query. A hardcoded AWS key in a config file. An XSS vector in a template. A call to MD5 where bcrypt should be. An HTTP endpoint that passes user input to a shell command.

SAST doesn't know about or care about which npm packages you installed. It's analyzing your code logic. A SAST tool will flag this:

const result = db.query(`SELECT * FROM users WHERE id = ${req.params.id}`);

...because the user-controlled value req.params.id flows directly into a SQL query without parameterization. It doesn't matter which database library you're using or whether that library has any CVEs. The bug is in your code.

What SCA scans

Software Composition Analysis (SCA) reads your dependency manifest — package.json, requirements.txt, pom.xml, go.mod — and checks every package (direct and transitive) against a vulnerability database like OSV. If you're running lodash@4.17.4, which has a known prototype pollution CVE, SCA flags it.

SCA doesn't analyze your code at all. It's checking the versions of the packages you depend on against a list of known-vulnerable versions. A perfect SAST run with zero findings can coexist with fifty SCA findings in your dependencies — and vice versa.

The blind spots in each

What SAST can't see:

Vulnerabilities introduced by the open-source packages you import
Supply-chain attacks with no CVE (typosquatting, dependency confusion)
Runtime configuration mistakes in cloud infrastructure
Bugs that only manifest under specific execution conditions

What SCA can't see:

Security bugs in the code your team writes
Hardcoded credentials in your own source files
Weak cryptographic choices in your own logic
Framework misconfigurations (CSRF disabled, DEBUG mode on, CORS wildcard)

The blind spots are almost perfectly complementary. An attacker probing your application has two main paths: exploit a bug in your code (SAST territory) or exploit a bug in a library you imported (SCA territory). Both scanners, covering both paths.

A concrete example: two reports, two attack surfaces

Imagine a Node.js API with these two problems:

Problem A (SAST territory): In controllers/user.js, you build a MongoDB query with string interpolation from req.query.username. This is a NoSQL injection vulnerability. It's in your code. No CVE exists for it. SCA will never find it.

Problem B (SCA territory): You depend on jsonwebtoken@8.5.1, which has a known algorithm confusion vulnerability (CVE-2022-23529). Your code calls jwt.verify() correctly. SAST may not flag it because the call looks correct in isolation — the vulnerability is in the library's internal implementation.

These are two real attack vectors. One scanner catches Problem A; the other catches Problem B. Running only SCA leaves NoSQL injection open. Running only SAST leaves the JWT library vulnerability open.

The combined CI gate

The most effective CI configuration runs both in parallel:

# GitHub Actions — combined SCA + SAST gate
- uses: Rushabh5000/dep-warden/cli@main
  with:
    file: package-lock.json   # SCA: dependency scan
    sast-dir: ./src           # SAST: static analysis
    fail-on: high
    sast-fail-on: high

This single step:

Parses package-lock.json, resolves the full transitive dependency tree, checks OSV/KEV/EPSS for vulnerabilities and typosquats
Walks ./src, detects languages, runs pattern + taint analysis across all source files against 300+ security rules
Fails the build if either scan produces a HIGH or CRITICAL finding

Two scan types, one gate, no account required.

Prioritization across both

When findings come from both SAST and SCA, the combined priority order:

SCA: KEV-listed + direct dependency + fix available — attackers are actively using this, you can fix it now
SAST: HIGH-confidence injection/RCE finding — user input confirmed flowing to a dangerous sink
SCA: HIGH CVSS + EPSS > 0.10 + fix available — elevated exploitation probability
SAST: hardcoded credential — immediate exposure risk if it reaches a repo
Everything else — triage by severity and confidence, don't block releases on MEDIUM/LOW

What DepWarden gives you

DepWarden combines both scanners in one tool, free and without an account:

SCA across 11 package ecosystems (npm, PyPI, Maven, Gradle, Go, Cargo, Composer, RubyGems, NuGet, Dart, Swift) with OSV/KEV/EPSS enrichment and exploitability-first prioritization
SAST across 15 languages and IaC formats, with 300+ security rules covering injection, XSS, secrets, weak crypto, framework-specific misconfigurations, and more
A single GitHub Action that gates pull requests with both scanners in one step

The only scanner you need in CI to cover the two main attack paths against your application.