Dependency Scanning

Modern web applications rely heavily on open-source, third-party packages from registries like npm. While these packages accelerate development, they can also introduce security vulnerabilities. This SOP outlines our process for managing and mitigating this risk.

The Risk of Vulnerable Dependencies

  • A vulnerability in a dependency is a vulnerability in our application.
  • Attackers can exploit known vulnerabilities in popular libraries to compromise our systems.
  • This is listed as “Vulnerable and Outdated Components” in the OWASP Top 10.

Our Automated Scanning Tools

We use a combination of automated tools to continuously monitor our dependencies for known vulnerabilities.

1. npm audit

  • What it is: A command built into npm that checks your project’s dependencies against the npm registry for known security vulnerabilities.
  • How to use it:
    # Run a security audit
    npm audit
     
    # To get a more detailed report
    npm audit --json
     
    # To automatically fix vulnerabilities (when possible)
    npm audit fix
  • When we use it:
    • Pre-commit Hooks: We can configure a pre-commit hook to run npm audit and prevent commits if high-severity vulnerabilities are found.
    • CI/CD Pipeline: npm audit is run as a step in our CI pipeline for every Pull Request. If new vulnerabilities are detected, the build will fail.

2. GitHub Dependabot

  • What it is: A feature built into GitHub that automatically detects vulnerabilities in your dependencies.
  • How it works:
    • Alerts: Dependabot will create alerts in the “Security” tab of your repository when a vulnerability is discovered.
    • Automated Pull Requests: For many vulnerabilities, Dependabot will automatically create a Pull Request to update the dependency to a secure version.
  • Our Process:
    • Enable Dependabot: Dependabot alerts and security updates should be enabled for all of our repositories.
    • Review PRs Promptly: Dependabot PRs should be reviewed, tested, and merged as quickly as possible, especially for critical and high-severity vulnerabilities.

The Triage and Remediation Process

Not all vulnerabilities are equally severe. We follow this process to triage and address them:

  1. Notification: An alert is triggered by Dependabot or npm audit in the CI pipeline.
  2. Assessment: A developer reviews the vulnerability report.
    • Severity: What is the severity level (Critical, High, Moderate, Low)?
    • Impact: Is our code actually using the vulnerable function? Is the vulnerability exploitable in our specific application context?
    • Fix Available: Is there a non-breaking update available?
  3. Prioritization:
    • Critical/High: Must be fixed immediately. This is a top priority. If an automated PR from Dependabot is available, it should be tested and merged. If not, a developer must be assigned to manually update the package.
    • Moderate: Should be fixed in the current or next sprint.
    • Low: Can be bundled with other dependency updates and addressed when time is available.
  4. Remediation:
    • Update the package: This is the most common solution.
    • Apply a patch: In rare cases where a direct update is not possible, we might use a tool like patch-package to apply a temporary fix.
    • Accept the risk: If a vulnerability is deemed not exploitable in our context and the effort to fix it is very high, we may formally decide to accept the risk. This decision must be documented in the bug tracking system.

By using these automated tools and following a clear remediation process, we can keep our applications secure from known threats in our software supply chain.