Dependency and software supply-chain in CI

MS Learn module: Dependencies and software supply chain Learning objectives: scan dependencies for known vulnerabilities as a pipeline step, sign produced artifacts to prove provenance, and build reproducibly from a pinned, known-good dependency graph.

Overview

Modern software is mostly other people’s code. The pipeline is the choke point for supply-chain risk: every imported package or container is an attack surface. This module makes dependency health and artifact provenance first-class pipeline steps, not afterthoughts.

Units / lessons covered

  • Dependency scanning step — run vulnerability scanners (e.g. OWASP dependency-check, GitHub advisory scan) over the resolved dependency graph; a CVSS threshold halts the build.
  • Artifact signing — sign build output so consumers verify the artifact really came from you (tamper-evident) if signing keys are managed safely.
  • Reproducibility — pin/lock dependency versions (lockfiles, semantic version checks, allowed repos) so the build is byte-reproducible and supply-chain tampering surfaces immediately.
  • Containers as dependencies — scan the container image of every dependency and push only signed/known-good images to ACR.

Key terms / commands

  • Scanner tasks (GitHub code scanning / advisories check, npm audit, owasp/dependency-check)
  • sorted-dependencies / package-lock.json, Image signing + provenance, permitted-repo allowlists

Hands-on / what to try

Add a dependency-scan step to a workflow, configure it to fail the build on a critical CVE in any transitive package, then note how pinning in the lockfile is what makes a stable, reproducible rebuild possible.

Exam focus

  • Scanning and signing happen during CI, before release — not in prod.
  • Signed artifacts + a pinned dependency set is the “reproducible, verifiable build” story.
  • Locked/blessed repos prevent unnoticed supply-chain substitution.

Path MOC · pipeline-security-controls · pipeline-integration-tests · branch-protection-and-policies