Dependency Vulnerability Scan — Your Code Is Only as Secure as Your Dependencies

When to Use This Skill

• Before any release to production — scan all dependencies for known CVEs
• When setting up CI/CD pipelines — integrate vulnerability scanning as a blocking gate
• After adding new dependencies — verify no known vulnerabilities or license conflicts
• During periodic security audits — quarterly dependency health check
• When a new critical CVE drops (Log4Shell, Spring4Shell) — rapid impact assessment
• Before enterprise customer onboarding — generate SBOM for procurement review
• When preparing for SOC 2, FedRAMP, ISO 27001, or PCI DSS compliance audits
• After a supply chain security incident — verify lockfile integrity and package provenance
• When evaluating a new third-party library — license and vulnerability pre-check

---

How It Works

┌──────────────────────────────────────────────────────────────────────────┐
│                 DEPENDENCY VULNERABILITY SCAN FLOW                       │
│                                                                          │
│  ┌───────────┐  ┌───────────┐  ┌───────────┐  ┌───────────┐            │
│  │ PHASE 1   │  │ PHASE 2   │  │ PHASE 3   │  │ PHASE 4   │            │
│  │ Dependency │─▶│ Vuln      │─▶│ CVE       │─▶│ SBOM      │            │
│  │ Discovery │  │ Scanning  │  │ Triage    │  │ Generation│            │
│  └───────────┘  └───────────┘  └───────────┘  └───────────┘            │
│   Lockfiles      npm audit     CVSS scoring   CycloneDX                 │
│   Manifests      Snyk/Trivy   Reachability    SPDX                      │
│   Dep tree       pip-audit    Exploitability  VEX                       │
│   Phantom deps   cargo-audit  Risk decision   Distribution              │
│       │                                              │                  │
│       ▼                                              ▼                  │
│  ┌───────────┐  ┌───────────┐                 ┌───────────┐            │
│  │ PHASE 5   │  │ PHASE 6   │                 │ PHASE 7   │            │
│  │ License   │─▶│ Supply    │                 │ Patch Mgmt│            │
│  │ Compliance│  │ Chain     │                 │ & Report  │            │
│  └───────────┘  └───────────┘                 └───────────┘            │
│   License scan   Typosquatting                 SLA tracking             │
│   Copyleft det.  Dep confusion                 Auto-update              │
│   Compatibility  Lockfile                      Breaking chg             │
│   Policy enforce integrity                     35+ checklist            │
│                                                                          │
│  ┌──────────────────────────────────────────────────────────────┐       │
│  │               SEVERITY → SLA MAPPING                         │       │
│  │  CRITICAL (CVSS 9.0-10.0) → 24 hours   — Pipeline blocks    │       │
│  │  HIGH     (CVSS 7.0-8.9)  → 7 days     — Sprint priority    │       │
│  │  MEDIUM   (CVSS 4.0-6.9)  → 30 days    — Scheduled patch    │       │
│  │  LOW      (CVSS 0.1-3.9)  → 90 days    — Next maintenance   │       │
│  └──────────────────────────────────────────────────────────────┘       │
└──────────────────────────────────────────────────────────────────────────┘

---

Phase 1 — Dependency Discovery

Map every dependency in the project — direct, transitive, dev, optional, peer, and phantom.

Scanning Layers

┌──────────────────────────────────────────────────────────────┐
│                  DEPENDENCY DISCOVERY LAYERS                  │
│                                                              │
│  Layer 1: Manifests (package.json, requirements.txt, etc.)   │
│                         │                                    │
│                         ▼                                    │
│  Layer 2: Lockfiles — source of truth for exact versions     │
│           (package-lock.json, yarn.lock, Pipfile.lock, etc.) │
│                         │                                    │
│                         ▼                                    │
│  Layer 3: Full Dependency Tree — transitive resolution       │
│           (npm ls --all, pipdeptree, cargo tree, etc.)       │
│                         │                                    │
│                         ▼                                    │
│  Layer 4: Container Images — OS packages + app deps          │
│           (Trivy, Grype, Docker Scout)                       │
└──────────────────────────────────────────────────────────────┘

Discovery Checklist

• All package managers identified and documented
• All manifest files located (including monorepo subdirectories)
• Lockfiles exist, committed, and verified not stale (npm ci passes)
• Full dependency tree generated — direct vs transitive counted
• Phantom dependencies identified (imported but not in manifest)
• Dev dependencies verified as excluded from production builds
• Duplicate package versions and unmaintained packages flagged

---

Phase 2 — Vulnerability Scanning

Run vulnerability scanners against the full dependency tree using multiple data sources.

Scanner Configuration by Language

Key Scanning Commands

npm audit --audit-level=critical          # JS/Node — CI gate: fail on critical
pip-audit --strict                        # Python — fail on any known vuln
govulncheck ./...                         # Go — reachability-aware scanning
cargo audit --json > cargo-audit.json     # Rust
trivy fs --severity CRITICAL,HIGH --exit-code 1 .   # Multi-language + containers

Scan Results — Fields to Capture

For each vulnerability: CVE ID, affected package, installed version, fixed version, CVSS score + vector, severity label, direct vs transitive, reachability (yes/no/unknown), exploit availability (Metasploit, PoC, in-the-wild), and EPSS score (exploitation probability in 30 days).

---

Phase 3 — CVE Triage and Risk Prioritization

Not all CVEs are equal. Triage based on exploitability, reachability, and business context.

CVSS Severity SLA Table

Risk Decision Tree

┌──────────────────────────────────────────────────────────────┐
│                    CVE TRIAGE DECISION TREE                   │
│                                                              │
│  New CVE found in dependency                                 │
│       │                                                      │
│       ▼                                                      │
│  Is it a direct dependency?                                  │
│    ├── YES → Is the vulnerable function called in your code? │
│    │          ├── YES → CONFIRMED RISK ──▶ Patch per SLA     │
│    │          └── NO  → Check if input reaches the vuln path │
│    │                    ├── YES → CONFIRMED RISK             │
│    │                    └── NO  → REDUCED RISK (still patch) │
│    └── NO (transitive)                                       │
│          │                                                   │
│          ▼                                                   │
│  Is the vulnerable code reachable via your direct dep?       │
│    ├── YES → Same as direct — patch per SLA                  │
│    ├── NO  → REDUCED RISK — patch within 2x SLA             │
│    └── UNKNOWN → Assume YES — patch per standard SLA         │
│                                                              │
│  ADDITIONAL RISK FACTORS (escalate severity by one tier):    │
│    • Exploit is public (PoC, Metasploit module)              │
│    • Listed in CISA KEV catalog                              │
│    • EPSS score > 0.5 (50% exploitation probability)         │
│    • Network-reachable attack vector (AV:N)                  │
│    • No authentication required (PR:N)                       │
│    • Package processes untrusted input (parsers, serializers)│
└──────────────────────────────────────────────────────────────┘

For each triaged vulnerability, document: CVE ID and package/version, CVSS score and vector, reachability determination, EPSS score and KEV status, risk decision (patch now / patch per SLA / accept), fixed version with breaking change assessment, remediation owner and target date.

---

Phase 4 — SBOM Generation

Generate a machine-readable inventory of every component in your software.

SBOM Formats

NTIA Minimum Elements (required by EO 14028)

Generation Commands

npx @cyclonedx/cdxgen -o sbom.json --spec-version 1.5    # CycloneDX (auto-detect)
syft . -o spdx-json > sbom-spdx.json                     # SPDX via Syft
trivy fs --format cyclonedx --output sbom.json .          # Trivy SBOM

SBOM Distribution Checklist

• Generate SBOM in CI on every tagged release
• Store as versioned build artifact with SHA-256 hash
• Attach VEX statements for known CVEs not exploitable in your context
• Make available to enterprise customers on request
• Retain historical SBOMs for every production release

---

Phase 5 — License Compliance

Detect and enforce license policies to prevent legal risk.

License Compatibility Matrix

License Scanning Commands

npx license-checker --failOn "GPL-2.0;GPL-3.0;AGPL-3.0;SSPL"         # Node.js
trivy fs --scanners license --format json --output license-report.json .  # Multi-language
pip-licenses --fail-on="GNU General Public License v3 (GPLv3)"        # Python

License Compliance Checklist

• All direct and transitive dependency licenses identified
• Copyleft licenses flagged (GPL, AGPL, LGPL, MPL, EUPL, SSPL)
• "No license" packages blocked (defaults to all rights reserved)
• Attribution requirements met (LICENSE/NOTICE files)
• Dual-licensed packages verified using permissive option
• License policy exceptions documented with legal approval

---

Phase 6 — Supply Chain Attack Prevention

Detect and prevent common dependency supply chain attack patterns.

Supply Chain Attack Patterns

Prevention Checklist

• Use lockfiles and verify integrity (npm ci in CI, never npm install)
• Enable provenance verification (npm audit signatures, Sigstore attestations)
• Configure registry scoping for private packages (.npmrc with @org:registry=...)
• Audit install scripts (preinstall, postinstall) for new dependencies
• Pin exact versions for security-sensitive dependencies
• Monitor ownership transfers on critical dependencies
• Enable Socket.dev or similar real-time supply chain monitoring

---

Phase 7 — Patch Management and Remediation

Establish SLA-driven patching workflows with breaking change assessment.

Patch Priority Matrix

Breaking Change Assessment

Before upgrading, evaluate by version bump type: After upgrading: run unit tests (API contract changes), integration tests (behavior changes), E2E tests (runtime errors), and build (type/compilation errors). If tests fail on a security-critical patch, apply a workaround while fixing the breaking change.

Automated Updates

Configure Dependabot (.github/dependabot.yml) or Renovate (renovate.json) with:

• Weekly schedule for each package ecosystem and directory
• Group patch/minor updates together, separate major updates
• Auto-merge patches with passing CI, require review for minor/major
• Labels (dependencies, security) and security team as reviewers

---

Phase 8 — CI Pipeline Integration

Configure vulnerability scanning as a mandatory CI gate. The CI workflow should:

• Trigger on PRs that modify dependency files (package.json, lock, requirements.txt)
• Run weekly scheduled scans for newly disclosed CVEs
• Run npm audit --audit-level=critical for each service directory
• Run Trivy filesystem scan with --severity CRITICAL,HIGH --exit-code 1
• Run license checker with --failOn "GPL-2.0;GPL-3.0;AGPL-3.0;SSPL"
• Generate and upload SBOM as build artifact on main branch merges

CI Gate Rules

---

Phase 9 — Vulnerability Dashboard and Tracking

Track open vulnerabilities, SLA compliance, and dependency health trends. Track each open vulnerability with: CVE ID, package, severity, CVSS, EPSS, discovery date, SLA deadline, status, and owner.

Dependency Health Metrics

---

Dependency Vulnerability Checklist

Discovery

• All package managers, manifests, and lockfiles identified and committed
• Full dependency tree generated — phantom deps and duplicates flagged
• Dev dependencies verified as excluded from production builds
• Unmaintained dependencies (no release > 2 years) flagged

Vulnerability Scanning

• Primary scanner configured per language, running against lockfiles
• Container images scanned (if applicable)
• All CRITICAL/HIGH findings documented with EPSS and KEV status
• Reachability analysis performed for transitive vulnerabilities

CVE Triage

• Every CRITICAL/HIGH CVE has risk decision, owner, and SLA deadline
• Reachability and exploit availability determined
• Remediation path identified (fixed version + breaking change assessment)

SBOM

• SBOM generated (CycloneDX/SPDX) with all NTIA minimum elements
• Generated automatically in CI, stored as versioned build artifact
• VEX statements attached for non-exploitable findings

License Compliance

• License policy defined and enforced in CI (build fails on violation)
• No copyleft or unlicensed packages in production dependency tree
• Attribution requirements met

Supply Chain Security

• Lockfile integrity verified (npm ci), provenance signatures checked
• Registry scoping configured, install scripts audited
• Typosquatting and dependency confusion prevention in place

Patch Management & CI

• Automated update PRs enabled with defined auto-merge policy
• Critical CVEs and license violations block the build pipeline
• Scheduled weekly scans for newly disclosed CVEs
• Patch SLAs tracked, overdue patches escalated

---

Tips for Best Results

• Start with discovery — you cannot secure what you cannot see. Map every dependency before scanning.
• Scan lockfiles, not manifests — package.json says ^4.18.0 but your lockfile says 4.18.2. The lockfile is what runs in production.
• Use multiple scanners — no single vulnerability database is complete. npm audit + Snyk or Trivy catches more than either alone.
• Reachability matters — a CVSS 9.8 CVE in code your application never calls is lower risk than a CVSS 7.0 in your hot path. Prioritize accordingly, but still patch both.
• Automate everything — manual dependency updates do not scale. Dependabot or Renovate PRs should be a weekly routine, not a quarterly fire drill.
• Track SLA compliance, not just vulnerability count — the metric that matters is "how fast do we patch?" not "how many vulns do we have right now?"
• License scanning is not optional — one AGPL dependency discovered during an enterprise deal can delay a contract by months. Scan proactively.
• Treat SBOM as a product deliverable — enterprise customers and government contracts increasingly require SBOMs. Build the pipeline now.
• Monitor for supply chain attacks actively — typosquatting and dependency confusion are not theoretical. Subscribe to OpenSSF Package Analysis and Socket.dev alerts.
• Keep the vulnerability window small — the time between CVE publication and your production patch is your exposure. Weekly automated updates keep this window under 7 days for most packages.