How to Scan Dependencies for Vulnerabilities in CI

What and why

Most code in a modern app is third-party dependencies, and they carry known vulnerabilities (CVEs). Software composition analysis scans your dependency tree against vulnerability databases. Producing a Software Bill of Materials (SBOM) makes the inventory explicit and auditable.

Prerequisites

• A project with a committed lockfile.
• A CI provider.
• Basic command line familiarity.

Steps

1. Pin dependencies with a lockfile

Commit your lockfile (package-lock.json, go.sum, poetry.lock, etc.). Scanners read it to know exact resolved versions, and pinning makes builds reproducible.

2. Generate an SBOM

Use Syft to produce a standard SBOM:

syft dir:. -o cyclonedx-json=sbom.json

CycloneDX and SPDX are the common SBOM formats; store the file as a build artifact.

3. Scan for known vulnerabilities

Scan the SBOM or the filesystem with Grype:

grype sbom:sbom.json

For container images, scan the image directly with grype <image> or trivy image <image>.

4. Gate the build on severity

Fail only on actionable severities to avoid noise:

grype sbom:sbom.json --fail-on high

In GitHub Actions:

- uses: anchore/scan-action@v4
  with:
    path: '.'
    fail-build: true
    severity-cutoff: high

5. Automate upgrade pull requests

Enable Dependabot or Renovate so bumps arrive as pull requests:

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: npm
    directory: '/'
    schedule: { interval: weekly }

These tools open PRs for vulnerable and outdated packages, and your CI tests them automatically.

Verification

• An SBOM file is produced and stored as an artifact.
• A known-vulnerable dependency triggers a finding.
• A high-severity finding fails the build.
• Dependency-update PRs appear on schedule.

Next Steps

Add reachability analysis to deprioritize unexploitable findings, sign and attest the SBOM, and track mean time to remediate as a security KPI across repositories.