Triage new dependency vulnerability findings

A scanner report is a list of advisory records matched to resolved versions. It is not yet a list of findings. One vulnerability often arrives under several IDs: on 2026-10-10, OSV.dev returned six records for jinja2 3.1.4, which are three GitHub advisories and three PyPA PYSEC records for the same three CVEs. Triage starts by collapsing those aliases and keeping one row per alias group, package, resolved version and the artifact it ships in.

As a measured example, OSV-Scanner 2.6.0 run on 2026-10-10 against a small fixture, a Node.js API locked to express 4.19.2 with micromatch 4.0.5 as a development dependency and a Python worker pinned to jinja2 3.1.4, printed 20 advisory records. The script below collapsed them into 16 findings in 10 packages. Eleven of the 16 came from express 4.19.2 itself and the packages it pulls in, such as path-to-regexp, cookie, qs, send and body-parser, which is typical: most findings in a Node.js service are transitive.

Match identity exactly before doing anything else. The ecosystem and package name must both match; a PyPI package with the same name as an npm package is a different component. For operating system packages, compare against the distribution's own advisory, because a backported fix keeps the old upstream version number.

"""Collapse an OSV-Scanner JSON report into one row per distinct finding.

Usage: osv-scanner scan -r . --format json > osv.json
       python3 triage_batch.py osv.json
"""
import json
import re
import sys
from pathlib import Path


def key(version):
    """Loose numeric ordering; good enough for x.y.z versions, not for pre-releases."""
    return [int(n) for n in re.findall(r"\d+", version)]


def fix_for(vuln, name, version):
    """The 'fixed' version of the range that contains the installed version."""
    for affected in vuln.get("affected", []):
        if affected["package"]["name"] != name:
            continue
        for r in affected.get("ranges", []):
            start = None
            for event in r["events"]:
                if "introduced" in event:
                    start = event["introduced"]
                elif "fixed" in event and start is not None:
                    if key(start) <= key(version) < key(event["fixed"]):
                        return event["fixed"]
                    start = None
    return None


with open(sys.argv[1], encoding="utf-8") as f:
    report = json.load(f)

records = rows = 0
for result in report["results"]:
    source = Path(result["source"]["path"])
    for pkg in result["packages"]:
        name, version = pkg["package"]["name"], pkg["package"]["version"]
        scope = "dev" if "dev" in (pkg.get("dependency_groups") or []) else "prod"
        by_id = {v["id"]: v for v in pkg["vulnerabilities"]}
        records += len(by_id)
        for group in pkg["groups"]:  # records that share an alias are one finding
            rows += 1
            cves = sorted(a for a in group["aliases"] if a.startswith("CVE-")) or group["ids"][:1]
            fixes = [fix_for(by_id[i], name, version) for i in group["ids"]]
            fix = "no fix" if None in fixes else max(fixes, key=key)
            print(f"{source.parent.name}/{source.name}\t{scope}\t{name}@{version}\t"
                  f"{','.join(cves)}\tcvss={group.get('max_severity') or '?'}\tfix={fix}")
print(f"{records} advisory records -> {rows} distinct findings", file=sys.stderr)

Most transitive findings close when their parent moves. In the fixture, upgrading express from 4.19.2 to 4.22.1, micromatch to 4.0.8 and Jinja2 to 3.1.6 left four findings, and two of those were new. The express upgrade alone resolved path-to-regexp 0.1.13, cookie 0.7.2, send 0.19.2, serve-static 1.16.3 and body-parser 1.20.8. Do this first, because a precondition analysis of a finding that one routine upgrade removes is wasted work.

Then rescan, because an upgrade can add findings too. After the upgrade the lockfile held two copies of qs: 6.16.0 under body-parser, which was clean, and 6.14.2 under express, which express 4.22.1 pins with the range ~6.14.0. That copy matched three advisories, two of which did not affect the old 6.11.0, one because it was introduced in 6.14.2 itself. The parent's range cannot reach a fixed version, so the choices are an overrides entry that forces a newer qs with tests to prove the parent still works, waiting for a parent release, or a dated exception if the code path is unreachable.

The last residual, braces 3.0.3, was development-only and had no fixed version. It never reaches the shipped image, so it is a tooling risk to note and recheck, not a production finding.

Presence in a shipped artifact makes a finding real; the advisory's precondition decides how urgent it is. Most advisories say what has to be true for the bug to matter. Read that sentence, then check it in your code and configuration with something you can rerun, such as a search, a call graph or a test. Record the scope of the check: the artifact digest, the entry points you looked at and the trigger that would reopen it.

For Go, govulncheck does this at symbol level. For two programs that both required golang.org/x/text v0.3.7, govulncheck reported GO-2022-1059 as affecting the one that passes a header to language.ParseAcceptLanguage, with the call trace, and listed it only as imported but not called for the program that never calls that function. Other ecosystems lack an equivalent standard tool, so a targeted search plus a test is the usual evidence. Absence of a reachability warning from a scanner that does not analyze calls is not evidence of anything.

# Collapse the batch: one row per package, version and alias group
osv-scanner scan -r . --format json > osv.json
python3 triage_batch.py osv.json

# Is the flagged copy shipped, and which parent pins it?
npm ls qs path-to-regexp --package-lock-only
npm ls micromatch --omit=dev --package-lock-only   # empty: dev-only

# Check the precondition named in the advisory, not just the version
grep -rnE "['\"]/[^'\"]*:[A-Za-z_]+[^/.'\"]+:[A-Za-z_]+" src/   # path-to-regexp: two params in one segment
grep -rn "res.cookie(" src/                                 # cookie: is the name, path or domain user input?
grep -rnE "from_string|Template\(" report-worker/          # Jinja2: are templates built from input?

# Go: symbol-level reachability
govulncheck ./...

Every finding should leave triage with exactly one outcome and an owner. The due date for a fix comes from your prioritization policy, which combines CISA KEV, EPSS, CVSS 4.0 and SSVC with exposure and asset value; /frameworks/vulnerability-prioritization/ explains each signal and gives a decision table, including the deadlines that CISA's BOD 26-04 sets for US federal civilian agencies, so this page does not repeat it. What triage adds is the local evidence those signals cannot see: whether the copy ships, whether its precondition holds, and which upgrade closes it.

Escalate rather than queue when a finding is exploited in the wild and present in something you run. A KEV entry, a vendor telling users to rotate secrets, or a malicious version in a lockfile means hours, not a sprint: switch to /domains/appsec/vulnerability-response/dependency-vulnerability-response/, which covers scoping, containment, hunting and rotation. If you are a manufacturer under the EU Cyber Resilience Act, that same escalation can start a 24-hour reporting clock, which /frameworks/cra-reporting-runbook/ covers.

The cheapest triage is the finding that never needs a human. Configure Dependabot or Renovate so routine bumps arrive grouped and tested, and keep human review for the findings that need a decision. The configuration below groups development tooling into one pull request, groups production security fixes so one rebuild closes them, and keeps a release-age cooldown for version updates. Since 2026-07-14 Dependabot applies a 3-day cooldown to version updates by default; security updates still open immediately, so the cooldown never delays a fix for a known vulnerability. Renovate's equivalent is minimumReleaseAge.

A cooldown matters for supply-chain attacks as well as stability: malicious versions such as the ones in /domains/supply-chain/dependencies/case-study-shai-hulud/ were usually found and removed within hours to days, so a few days of waiting keeps most of them out of your lockfile.

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    # Version updates wait for a release to age; security updates open at once.
    cooldown:
      default-days: 3
      semver-major-days: 14
    groups:
      # One PR for the routine bumps of tools that never ship.
      dev-tooling:
        dependency-type: "development"
        update-types: ["minor", "patch"]
      # Security fixes for production packages land together, so one rebuild closes them.
      prod-security:
        applies-to: security-updates
        dependency-type: "production"
  - package-ecosystem: "pip"
    directory: "/report-worker"
    schedule:
      interval: "weekly"

A merged pull request is an intermediate step. Close a finding when the rebuilt artifact contains the fixed version and that artifact is what runs: rescan the built image or its SBOM, not the repository, and compare the digest every environment runs with the one you scanned. Scheduled jobs and rarely deployed workers are where old images survive.

Keep the record after closure: the alias group, the package URL and version, the artifact digests, the precondition check and its scope, the outcome and the reopen trigger. When a VEX statement or an exception changes the response, keep the original detection next to the assessment rather than deleting it, so a later scan that sees the same package can be matched to the decision. /domains/supply-chain/vex/producer-and-consumer-decisions/ covers publishing those decisions to customers.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. OSV-Scanner: usage
2. OSV-Scanner: output formats
3. GitHub Advisory GHSA-9wv6-86v2-598j: path-to-regexp outputs backtracking regular expressions (CVE-2024-45296)
4. GitHub Advisory GHSA-pxg6-pf52-xh8x: cookie accepts out-of-bounds characters (CVE-2024-47764)
5. GitHub Advisory GHSA-q2x7-8rv6-6q7h: Jinja sandbox breakout through format method (CVE-2024-56326)
6. GitHub Docs: Dependabot options reference (cooldown, groups, open-pull-requests-limit)
7. GitHub changelog: Dependabot version updates introduce a default package cooldown (2026-07-14)
8. Go: govulncheck tutorial
9. npm Docs: npm ls. npm v11.
10. OpenVEX specification. v0.2.0 (draft).

Reference information

Tags

VEX and vulnerability statusDependency managementVulnerability managementJavaScript and Node.js

SDLC phase

DevelopmentMaintenance

Role

DevelopersAppSec engineers

ASVS 5.0.0 requirements

v5.0.0-15.1.1 · v5.0.0-15.2.1

Download this guide as Markdown

Continue exploring