Eric Campbell 5 min read Security

Dependency Scanning: Vulnerability Detection

Your application is mostly code you didn't write. A typical Node.js project pulls in hundreds of transitive dependencies. A Java application might include thousands. Each one is a potential attack...

Key Insights

  • Dependency scanning isn’t optional anymore—with 80%+ of modern application code coming from third-party packages, automated vulnerability detection is your first line of defense against supply chain attacks.
  • The best scanning strategy combines multiple tools: use native package manager audits for speed, dedicated scanners for depth, and CI/CD integration for consistency.
  • False positives are inevitable; build a documented suppression process that requires justification and periodic review rather than blanket ignoring results.

The Hidden Risk in Your Dependencies

Your application is mostly code you didn’t write. A typical Node.js project pulls in hundreds of transitive dependencies. A Java application might include thousands. Each one is a potential attack vector.

The Log4Shell vulnerability (CVE-2021-44228) demonstrated this at scale. A single logging library, buried deep in dependency trees across millions of applications, gave attackers remote code execution capabilities. Organizations spent weeks just identifying whether they were affected.

This wasn’t an anomaly. The Equifax breach traced back to an unpatched Apache Struts vulnerability. The event-stream incident showed how a malicious actor could compromise a popular npm package. These aren’t theoretical risks—they’re documented disasters.

Dependency scanning automates what would otherwise be impossible: continuously checking every package in your application against known vulnerabilities. It’s not perfect, but it’s essential.

How Dependency Scanners Work

Scanners operate by matching your dependencies against databases of known vulnerabilities. The core components are straightforward:

CVE Databases: The National Vulnerability Database (NVD) maintains the authoritative list of Common Vulnerabilities and Exposures. Commercial tools supplement this with proprietary research and faster disclosure timelines.

Software Bill of Materials (SBOM): An SBOM is a complete inventory of your application’s components. Scanners generate these implicitly or explicitly, then cross-reference against vulnerability databases.

Version Matching: Scanners compare your exact package versions against affected version ranges in vulnerability records. A vulnerability in lodash@4.17.0-4.17.20 won’t flag lodash@4.17.21.

Here’s what a CycloneDX SBOM looks like for a Node.js project:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "version": 1,
  "components": [
    {
      "type": "library",
      "name": "express",
      "version": "4.18.2",
      "purl": "pkg:npm/express@4.18.2",
      "licenses": [
        {
          "license": {
            "id": "MIT"
          }
        }
      ]
    },
    {
      "type": "library",
      "name": "lodash",
      "version": "4.17.21",
      "purl": "pkg:npm/lodash@4.17.21"
    }
  ]
}

The Package URL (purl) format provides unambiguous identification across ecosystems. When a new CVE drops, scanners query their databases for matching purls and flag affected projects.

The tooling landscape offers options for every budget and use case. Here’s an honest assessment:

npm audit / yarn audit: Built into your package manager, zero configuration required. Fast and free, but limited to the npm ecosystem and sometimes lags behind on new vulnerabilities. Use it as a baseline, not your only defense.

# Basic npm audit
npm audit

# Get JSON output for programmatic processing
npm audit --json

# Only show high and critical vulnerabilities
npm audit --audit-level=high

Sample output you’ll need to interpret:

# npm audit report

lodash  <4.17.21
Severity: high
Prototype Pollution - https://github.com/advisories/GHSA-jf85-cpcp-j695
fix available via `npm audit fix`
node_modules/lodash

3 vulnerabilities (1 moderate, 2 high)

Trivy: Open-source scanner from Aqua Security. Handles containers, filesystems, and git repositories. Excellent for polyglot projects and container scanning.

# Scan a filesystem
trivy fs --severity HIGH,CRITICAL .

# Scan a container image
trivy image myapp:latest

# Generate SBOM in CycloneDX format
trivy fs --format cyclonedx --output sbom.json .

Snyk: Commercial tool with a generous free tier. Strong developer experience, good IDE integrations, and proprietary vulnerability database that often catches issues before NVD. The fix suggestions are genuinely useful.

OWASP Dependency-Check: Mature, open-source, and thorough. Higher false positive rate than commercial tools, but comprehensive. Best for organizations with security teams who can tune it.

GitHub Dependabot: Automatic pull requests for vulnerable dependencies. Low friction but reactive rather than proactive. Useful as a safety net, not a primary scanner.

My recommendation: run Trivy in CI for broad coverage, enable Dependabot for automatic PRs, and consider Snyk if you need deeper analysis or have a polyglot codebase.

Integrating Scanning into CI/CD Pipelines

Scanning means nothing if it doesn’t block vulnerable code from reaching production. Here’s a GitHub Actions workflow that fails builds on high-severity vulnerabilities:

name: Security Scan

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

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

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

      - name: Install dependencies
        run: npm ci

      - name: Run npm audit
        run: npm audit --audit-level=high

      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'fs'
          scan-ref: '.'
          severity: 'HIGH,CRITICAL'
          exit-code: '1'
          format: 'table'

      - name: Upload Trivy scan results
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: trivy-results
          path: trivy-results.sarif

For GitLab CI, the configuration is similarly straightforward:

stages:
  - test
  - security

dependency_scan:
  stage: security
  image: aquasec/trivy:latest
  script:
    - trivy fs --exit-code 1 --severity HIGH,CRITICAL .
  allow_failure: false
  artifacts:
    reports:
      container_scanning: trivy-report.json

npm_audit:
  stage: security
  image: node:20
  script:
    - npm ci
    - npm audit --audit-level=high
  allow_failure: false

Set allow_failure: false to make security a hard gate. Teams often start with allow_failure: true during initial adoption, then tighten once the backlog is cleared.

Handling False Positives and Prioritizing Fixes

Not every CVE requires immediate action. A vulnerability in a development dependency never deployed to production is different from one in your web framework. Context matters.

Create a structured suppression process. Document why you’re ignoring a finding and set a review date:

// .trivyignore.yaml
vulnerabilities:
  - id: CVE-2023-12345
    paths:
      - "node_modules/dev-only-package"
    statement: "Development dependency only, not included in production builds"
    expires: "2024-06-01"
    
  - id: CVE-2023-67890
    paths:
      - "node_modules/legacy-lib"
    statement: "Vulnerability requires local file system access; our deployment prevents this attack vector"
    expires: "2024-03-15"

For npm, use the audit configuration in your package.json:

{
  "overrides": {
    "vulnerable-package": "2.0.0"
  },
  "auditConfig": {
    "ignore": [
      {
        "id": 1089909,
        "reason": "No patch available; input validation prevents exploitation",
        "expires": "2024-04-01"
      }
    ]
  }
}

Prioritize fixes using these criteria:

  1. Exploitability: Is there a public exploit? Is it being actively used?
  2. Exposure: Is this component reachable from untrusted input?
  3. Impact: What’s the worst-case scenario if exploited?
  4. Fix availability: Is there a patched version?

CVSS scores help but don’t tell the whole story. A critical-rated vulnerability in an unused code path is less urgent than a high-rated one in your authentication flow.

Remediation Strategies

When a vulnerability appears, you have several options:

Direct update: The simplest fix. Update the vulnerable package to a patched version.

npm update vulnerable-package

Transitive dependency override: When the vulnerability is in a nested dependency that your direct dependencies haven’t updated yet, force the version:

// package.json for npm
{
  "overrides": {
    "lodash": "4.17.21",
    "minimist": "1.2.8"
  }
}

// package.json for Yarn
{
  "resolutions": {
    "lodash": "4.17.21",
    "**/minimist": "1.2.8"
  }
}

Fork and patch: When maintainers are unresponsive, fork the package, apply the fix, and reference your fork. Use this sparingly—you’re now the maintainer.

Accept the risk: Sometimes the vulnerability doesn’t apply to your use case, or the fix introduces breaking changes you can’t absorb. Document this decision and set a review date.

# Generate a detailed audit report for security review
npm audit --json > audit-report.json

Building a Continuous Scanning Culture

Dependency scanning isn’t a one-time project. Vulnerabilities are discovered daily. Your scanning must be equally continuous.

Schedule daily scans of your main branches. Configure notifications that reach the right people—security findings buried in build logs don’t get fixed. Track metrics: time-to-remediation, vulnerability backlog size, and false positive rates.

Educate developers on reading scan results and understanding severity ratings. A team that understands why scanning matters will write better dependency hygiene: fewer dependencies, more careful version pinning, and faster response to alerts.

Balance security with velocity. A pipeline that fails on every moderate vulnerability will get bypassed. A pipeline that ignores everything provides false confidence. Find the threshold that catches real risks without creating alert fatigue.

The goal isn’t zero vulnerabilities—that’s impossible with third-party code. The goal is knowing what’s in your software and making informed decisions about acceptable risk. Dependency scanning gives you that visibility. Use it.

Liked this? There's more.

Every week: one practical technique, explained simply, with code you can use immediately.