Dependency Audit & CVE Scanning

Also Known As

TL;DR

Explanation

Every dependency is potential attack surface. CVE databases (National Vulnerability Database, GitHub Advisory Database) track known vulnerabilities with severity scores. Tools: composer audit (built-in, checks against GitHub Advisory), npm audit, Snyk, Dependabot (GitHub). Best practice: run in CI on every PR, fail the build on high-severity CVEs, automate dependency updates (Dependabot, Renovate). PHP-specific: track phpstan/phpstan, laravel/framework, symfony/* for security releases. Sign up to security mailing lists for frameworks you use.

Common Misconception

Why It Matters

Common Mistakes

• No audit step in CI — vulnerabilities are only caught when someone manually checks.
• Ignoring moderate CVEs — many critical exploits start as moderate severity findings.
• Not updating after audit — knowing about a vulnerability without fixing it provides no protection.
• Only auditing direct dependencies — transitive dependencies (dependencies of dependencies) are equally dangerous.

Code Examples

# No audit in CI — vulnerable packages silently deployed:
# .github/workflows/ci.yml:
steps:
  - run: composer install
  - run: vendor/bin/phpunit
  # No audit step
  # symfony/http-kernel with known RCE deployed to production

# Audit in CI — blocks deployment on high CVEs:
steps:
  - run: composer install
  - run: composer audit --no-dev  # Fail on any vulnerability
  - run: vendor/bin/phpunit

# .github/dependabot.yml:
version: 2
updates:
  - package-ecosystem: composer
    directory: /
    schedule:
      interval: weekly
    open-pull-requests-limit: 10

References

• ↗ https://getcomposer.org/doc/03-cli.md#audit

Tags

Related Terms