Rethinking Dependency Vulnerability Management: From Compliance Checkbox to Risk-Based Prioritization

tring; events: Array<{ version: string }> }> }>; severity: number; aliases: string[]; }

interface ContextFilterConfig { productionImports: Set<string>; excludedEcosystems: string[]; runtimeMitigations: { networkExposed: boolean; sandboxed: boolean; inputValidated: boolean; }; }

export class VulnerabilityContextFilter { private sbom: SBOMComponent[]; private vulnerabilities: Vulnerability[]; private config: ContextFilterConfig;

constructor(sbomPath: string, vulnPath: string, config: ContextFilterConfig) { this.sbom = JSON.parse(readFileSync(sbomPath, 'utf-8')).components; this.vulnerabilities = JSON.parse(readFileSync(vulnPath, 'utf-8')).vulnerabilities; this.config = config; }

private isProductionDependency(component: SBOMComponent): boolean { return this.config.productionImports.has(component.name) && !this.config.excludedEcosystems.includes(component.type); }

private isVersionAffected(version: string, ranges: Vulnerability['affected'][0]['ranges']): boolean { for (const range of ranges) { for (const event of range.events) { if (event.version === version) return true; } } return false; }

private isRuntimeMitigated(vuln: Vulnerability): boolean { const { networkExposed, sandboxed, inputValidated } = this.config.runtimeMitigations;

if (vuln.id.includes('XSS') && inputValidated) return true;
if (vuln.id.includes('RCE') && sandboxed) return true;
if (vuln.id.includes('Network') && !networkExposed) return true;

return false;

}

public filter(): Vulnerability[] { const productionComponents = new Map<string, SBOMComponent>(); this.sbom.forEach(c => { if (this.isProductionDependency(c)) { productionComponents.set(${c.name}@${c.version}, c); } });

return this.vulnerabilities.filter(vuln => {
  for (const affected of vuln.affected) {
    const key = `${affected.package.name}@${affected.ranges[0]?.events[0]?.version}`;
    if (!productionComponents.has(key)) continue;
    if (this.isVersionAffected(productionComponents.get(key)!.version, affected.ranges)) {
      if (!this.isRuntimeMitigated(vuln)) return true;
    }
  }
  return false;
});

} }

### Architecture Decisions and Rationale

- **SBOM-First Design:** Generating SBOM during build guarantees consistency between development, CI, and production. Post-build SBOM generation introduces drift and breaks reproducibility.
- **Multi-Scanner Strategy:** `osv-scanner` excels at language-specific vulnerability matching and supports the Open Source Vulnerability format. `trivy` covers container layers, OS packages, and IaC. Running both in parallel prevents blind spots without duplicating effort.
- **Context Filtering Over CVSS:** CVSS measures theoretical severity. Context filtering evaluates actual exploitability. This reduces false positives by 80%+ and aligns findings with engineering priorities.
- **Caching and Hash Deduplication:** Scanning the same dependency graph repeatedly wastes CI minutes. Hashing the SBOM and caching scanner results reduces runtime by 60-75% on subsequent runs.
- **SARIF/JSON Output:** Structured output integrates natively with GitHub Advanced Security, GitLab, and Jira. Raw text logs force manual parsing and break automation.

## Pitfall Guide

### 1. Treating CVSS Score as Absolute Priority
CVSS assumes ideal conditions for exploitation. A 9.8 CVE in a logging library that never processes user input is lower risk than a 6.5 CVE in an authentication module that parses external requests. Always map severity to actual attack surface.

### 2. Ignoring Transitive Dependencies
Direct dependencies are only the tip of the iceberg. A single `express` install can pull 40+ transitive packages. Scanners that only audit `package.json` or `go.mod` miss 70% of the vulnerability surface. Always scan lockfiles and generated dependency trees.

### 3. Running Scans Without Database Freshness Controls
Vulnerability databases update daily. Scanning with stale data creates false confidence. Always pull the latest OSV/Trivy DB before scanning, or use managed services that guarantee real-time updates. Cache DBs locally but enforce TTL policies.

### 4. Blocking CI on Low-Severity Noise
Strict CI gates that fail on any CVE create developer friction and encourage suppression. Use risk-based gating: block on exploitable, unmitigated vulnerabilities; warn on theoretical exposure; allow dev/test dependencies to fail silently.

### 5. Confusing License Compliance with Vulnerability Scanning
License scanning and vulnerability scanning serve different purposes. License tools check legal risk; vulnerability scanners check security risk. Running both in the same pipeline without separating output causes confusion and misprioritization.

### 6. Not Validating Fix Compatibility
Automated dependency updates frequently break builds. Always run integration tests against proposed version bumps. Use semantic versioning constraints in manifests to prevent accidental major upgrades. Pin critical dependencies to specific versions in production.

### 7. Failing to Correlate with Runtime Environment
A vulnerability in a package that only runs in development mode, or in a container without network access, does not require immediate remediation. Map vulnerabilities to deployment topology, network policies, and execution contexts to prioritize accurately.

**Best Practices from Production:**
- Generate SBOMs as build artifacts, not afterthoughts
- Use lockfile integrity checks (`npm ci`, `go mod verify`) before scanning
- Implement automated PR creation for patchable vulnerabilities
- Maintain a baseline of accepted risk for legacy components
- Rotate scanner credentials and DB caches on a strict schedule
- Correlate findings with SAST/DAST results for full attack path visibility

## Production Bundle

### Action Checklist
- [ ] Generate CycloneDX/SPDX SBOM during build pipeline execution
- [ ] Run `osv-scanner` and `trivy` in parallel with fresh vulnerability databases
- [ ] Implement context filtering to remove dev-only, unimported, and runtime-mitigated findings
- [ ] Configure risk-based CI gates: block exploitable, warn theoretical, allow dev/test
- [ ] Automate PR creation for patchable vulnerabilities with integration test validation
- [ ] Cache scanner results using SBOM hash deduplication to reduce CI runtime
- [ ] Export findings to SARIF/JSON and integrate with issue tracking and security dashboards
- [ ] Establish quarterly dependency baseline reviews and accept/reject risk formally

### Decision Matrix

| Scenario | Recommended Approach | Why | Cost Impact |
|----------|---------------------|-----|-------------|
| Small team, single language, limited CI budget | `npm audit` + `osv-scanner` with basic CI gate | Low setup overhead, covers ecosystem-specific vulns, minimal maintenance | Low setup, moderate false positives |
| Multi-language monorepo, strict compliance requirements | SBOM generation + `trivy` + `osv-scanner` + context filtering | Covers OS, containers, and language packages; reduces noise for audit trails | Moderate setup, high accuracy, lower remediation cost |
| High-velocity startup, frequent releases | Integrated scanner with automated PR creation and risk-based gating | Prevents bottleneck, keeps security aligned with sprint velocity | Higher tooling cost, significantly lower MTTR |
| Regulated industry (finance, healthcare) | Full SBOM lifecycle + runtime correlation + manual security review for critical CVEs | Meets audit requirements, provides traceability, ensures risk acceptance documentation | High operational cost, compliance-ready, breach risk minimized |

### Configuration Template

```yaml
# .github/workflows/dependency-scan.yml
name: Dependency Vulnerability Scan

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Generate SBOM
        uses: cyclonedx/gh-generate-sbom@v1
        with:
          path: .
          output: sbom.json
          format: json

      - name: Run OSV Scanner
        uses: google/osv-scanner-action@v1
        with:
          scan-args: |
            --sbom=sbom.json
            --format=json
            --output=osv-results.json

      - name: Run Trivy
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'fs'
          format: 'json'
          output: 'trivy-results.json'
          severity: 'CRITICAL,HIGH'

      - name: Context Filter & Prioritize
        run: node scripts/filter-vulnerabilities.js
        env:
          PRODUCTION_IMPORTS: "express,pg,redis,axios"
          EXCLUDED_ECOSYSTEMS: "dev,test"
          NETWORK_EXPOSED: "true"
          SANDBOXED: "false"

      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: filtered-results.sarif

Quick Start Guide

1. Install scanner CLI tools globally or via package manager: npm i -g @google/osv-scanner trivy
2. Generate your first SBOM: cyclonedx-cli -o sbom.json -f json .
3. Run initial scan: osv-scanner --sbom=sbom.json --format=json > osv.json && trivy fs --format json -o trivy.json .
4. Apply context filtering: Use the TypeScript filter class above with your production import list and runtime configuration to generate filtered-results.json
5. Integrate with CI: Copy the GitHub Actions template, adjust environment variables to match your stack, and push. First run completes in under 5 minutes; subsequent runs leverage caching for sub-60-second execution.