Dependency & SCA Scanning

Dependency & SCA Scanning

Every modern application is predominantly third-party code. A typical Node.js service pulls in hundreds of transitive dependencies; a Java Spring Boot application ships thousands of JARs it never directly required. When a critical vulnerability surfaces in one of those packages — Log4Shell in log4j, CVE-2021-44228, shut down production systems at companies across the globe within hours of disclosure — the organisations that survived with minimal damage were the ones that already knew exactly where they were using that library and could ship a patch or mitigation the same day. The ones who spent three days hand-searching codebases had a very different experience.

Software Composition Analysis (SCA) is the discipline of continuously inventorying, analysing, and remediating the open-source and third-party components your software depends on. It answers four questions in an automated, pipeline-integrated way: What do we depend on? What known vulnerabilities exist in those dependencies? Do our licences conflict with how we distribute software? And how quickly can we remediate?

How Vulnerability Databases Work

SCA tools do not discover vulnerabilities — they correlate. They resolve your dependency graph into a precise list of package-name@version tuples, then look those up against one or more vulnerability databases:

• NVD (National Vulnerability Database) — NIST-maintained, the canonical source. Every CVE eventually lands here with CVSS scoring and affected version ranges.
• OSV (Open Source Vulnerabilities) — Google-maintained, schema-first, used by many tools as a faster and more machine-readable alternative to NVD. Covers PyPI, npm, Maven, RubyGems, Go modules, and more.
• GitHub Advisory Database (GHSA) — feeds directly into Dependabot. Often has advisories days before NVD because maintainers coordinate disclosure directly through GitHub's security advisory tooling.
• Snyk Intel — commercial database with hand-curated exploitability notes, reachability analysis, and remediation PRs. Proprietary but often has higher signal-to-noise for real exploitability.

CVSS score alone is a poor triage signal. A CVSS 9.8 vulnerability in a library you only use for a benign utility function, where the vulnerable code path is never reached, is lower priority than a CVSS 7.0 in a network-facing authentication library. Enterprise-grade SCA tools (Snyk, Mend, Semgrep Supply Chain) add reachability analysis: they trace your actual call graph and tell you whether the vulnerable function is reachable from your application entry points.

Dependabot: Automated Dependency Updates at Scale

GitHub's Dependabot operates in two distinct modes that teams often conflate. Dependabot alerts are passive — they notify you when a dependency in your default branch has a known CVE, using the GHSA database. Dependabot security updates are active — they automatically open a pull request with the minimal version bump that resolves the vulnerability. Dependabot version updates go further: they open PRs on a schedule to keep dependencies current, regardless of CVEs, which is the best long-term strategy because keeping the delta small means each update is low-risk.

Configure Dependabot via .github/dependabot.yml at the repository root:

Renovate: More Power, More Control

Renovate (Mend Renovate) is the open-source alternative that most large engineering organisations prefer over Dependabot for complex monorepos or multi-ecosystem repositories. It supports more package managers (including Helm charts, Terraform providers, and custom regex), has richer auto-merge rules, and provides a dependency dashboard issue that gives you a single-pane view of all pending updates.

Renovate's vulnerabilityAlerts block is critical: it bypasses the normal schedule and opens security-fix PRs immediately, regardless of other batching or concurrency limits. In a well-configured pipeline, these PRs also auto-merge once CI passes, meaning a critical CVE can be patched, tested, and deployed without human intervention — in minutes rather than days.

Running SCA in CI: Trivy, Grype, and Snyk

Dependabot and Renovate handle remediation. For enforcement — blocking a build when a high-severity vulnerability is introduced — you need a CI-integrated scanner. Three tools dominate production use:

• Trivy (Aqua Security) — open-source, fast, scans OS packages, language dependencies, container layers, IaC, and SBOMs. Zero configuration for common ecosystems.
• Grype (Anchore) — open-source, pairs with Syft for SBOM generation. Excellent for policy-as-code pipelines.
• Snyk — commercial SaaS with free tier, reachability analysis, and developer-facing fix PRs. Best-in-class for teams with budget and a focus on developer experience.

Lockfile Hygiene: The Foundation of Reproducibility

Lockfiles (package-lock.json, yarn.lock, Pipfile.lock, poetry.lock, go.sum, Gemfile.lock, pom.xml with pinned versions) are not optional. They are the primary defence against two classes of supply chain attack:

• Dependency confusion attacks — an attacker publishes a malicious package with the same name as an internal package to a public registry. Without a locked registry scope, package managers may resolve the public version. Lockfiles record the exact registry URL and integrity hash, so resolution is deterministic.
• Typosquatting — a malicious package name that closely resembles a popular package (lodahs vs lodash). Lockfiles prevent accidental resolution of the wrong package once a correct install has been done.

Critical lockfile rules for production pipelines: always commit lockfiles; use npm ci (not npm install) in CI — ci fails if the lockfile is out of sync with package.json and never modifies it; and verify integrity hashes. Node's lockfile v2/v3 and Go's go.sum both embed sha512 or sha256 hashes of the resolved tarballs. If a package is tampered with after you locked it, the hash check fails at install time.

Policy as Code: Enforcing Acceptable Risk

Raw CVE counts are not a policy. A mature SCA practice defines explicit acceptance criteria — typically in a .trivyignore file or an OPA/Rego policy — and treats exceptions as time-bounded, reviewed, and audited. At minimum, block:

• Any CRITICAL CVE with a fix available and a CVSS exploit score above 8.0
• Licences incompatible with your distribution model (GPL in a proprietary closed-source product)
• Direct dependencies on packages deprecated or archived by their maintainer

Use trivy fs . --format cyclonedx --output sbom.json to emit a CycloneDX SBOM alongside the vulnerability report — this feeds directly into the SBOM workflow covered in Lesson 7. When a zero-day breaks, an up-to-date SBOM lets you search your entire estate in seconds rather than days.