Software Supply Chain Foundations

Intro: Supply chain security is the discipline of proving what entered the build, how it was transformed, what left the build, and what evidence exists for the release decision.

Core building blocks

trusted source control
reviewed dependency strategy
isolated runners
artifact integrity
release evidence
signed outputs where appropriate
SBOM generation and retention
dependency and image vulnerability management

What aged well from older DevSecOps material

Several older books were right about the fundamentals:

software supply chain risk is a real engineering problem, not a compliance side quest;
teams need an inventory of dependencies and build inputs;
CI/CD is the right place to automate repetitive trust checks;
smaller changes make supply-chain failures easier to detect and roll back.

What changed is the ecosystem around those ideas.

Then versus now

Topic	Older or legacy example	Current 2026-friendly direction
Open source dependency scanning	OWASP Dependency-Check, SourceClear, Nexus Lifecycle	Dependency-Check still works; also use Veracode SCA, Dependency-Track, OSV-aware tooling, or platform-native SCA depending estate
Container scanning	Clair, OpenSCAP, registry-specific checks	Trivy, Syft + Grype, registry-native scanning, SBOM-driven re-scan workflows
Artifact signing	Docker Content Trust / Notary v1	Sigstore Cosign or Notation
Dependency inventory	ad hoc lockfiles only	CycloneDX or SPDX SBOMs stored with builds
Vulnerability review	static report snapshots	continuously refreshed inventory with policy and exception workflow

Strategic rule

Do not ask only, “Does this dependency have CVEs?”

Also ask:

why is it in the build?
who approved it?
what transitive packages came with it?
do we have an SBOM for this release?
do we know which services consume it?
can we re-scan old releases when new advisories arrive?

Practical snippet — legacy but still useful Java/Gradle or Maven scanning

dependency-check.sh \
  --project app-api \
  --scan . \
  --format HTML \
  --format JSON \
  --out reports/

Why it still matters:

Dependency-Check is still a valid entry point for teams with Java-heavy estates;
it remains useful for “known vulnerable component” hygiene;
it is not enough by itself for broad 2026 supply-chain coverage.

Practical snippet — SBOM-first modern pattern

syft dir:. -o cyclonedx-json > sbom.cdx.json
grype sbom:sbom.cdx.json --fail-on high

This pattern is strong because it separates:

inventory generation;
vulnerability evaluation;
future re-analysis without rebuilding the artifact.

Practical snippet — image scanning in CI

image_scan:
  stage: scan
  image: aquasec/trivy:latest
  script:
    - trivy image --scanners vuln,misconfig,secret \
        --severity HIGH,CRITICAL \
        --exit-code 1 \
        "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"

Practical snippet — signing and verifying an OCI artifact

Legacy pattern

export DOCKER_CONTENT_TRUST=1
docker trust sign registry.example.com/team/app:1.2.3

Modern pattern

cosign sign --keyless registry.example.com/team/app:1.2.3
cosign verify registry.example.com/team/app:1.2.3

Why both are shown

Teams still inherit DCT/Notary v1 workflows. For new work, prefer a signing path that aligns with the current OCI and Sigstore ecosystem.

Practical policy ideas

Fail builds when one of these is true:

a new dependency is introduced from an unapproved source;
the image contains critical vulnerabilities above policy threshold;
no SBOM was produced for a release artifact;
a protected release artifact is unsigned or unverifiable;
a reusable pipeline component changed without required review;
a new third-party GitHub Action or CI component is introduced without pinning and review.

Common mistakes

treating SCA as a one-time report instead of a continuously re-evaluated inventory;
signing artifacts but not verifying them in downstream environments;
producing SBOMs and then never using them for triage or re-scan;
trusting mutable tags as if they were release evidence;
focusing only on app dependencies while ignoring build images, CI components, and registries.

---Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.