DEV Community: Rushabh Shah

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.