openskills.info
Course Preview

Software Supply Chain Security

Software supply chain security protects the code, dependencies, build systems, and release artifacts that software depends on. It gives a team visibility into what it ships, control over how it changes, evidence of how each artifact was produced, and verification that the artifact matches that evidence before it is trusted.

itSoftware supply chain security

Don't Panic — Software Supply Chain Security

Software supply chain security is the practice of knowing what you run, how it was made, and what you verified before you trusted it. A release is no longer one team's source code — it is a chain of source, dependencies, build, artifact, and deployment, and an attacker only needs one weak link.

Before this was a discipline, a team shipped whatever its build produced and hoped. SolarWinds, in late 2020, made the cost of that hope visible: a compromised build of one product reached about 18,000 customers through a signed update, because nobody verified that the artifact matched the source it claimed to come from.

Three ideas hold the practice up. Inventory with an SBOM tells you what components and versions are in an artifact — and it is only useful when tied to the artifact by its digest, the cryptographic identifier for exact bytes. Provenance is the evidence that links an artifact to the build that produced it, and SLSA names the levels of guarantee, from "provenance exists" at L1 to a hardened, isolated build at L3. Signing with Sigstore makes an artifact tamper-evident, but only when a verifier checks the expected identity, the digest, the trust root, and the transparency log.

The one thing that surprises people: a signature is not a verdict. A signature says some key signed these bytes; it does not say the code is harmless, the dependencies are safe, or your deployment policy is correct. Signing without verification is theater, and verification without a policy that names the acceptable producers is unmanageable.

The thing that catches every team: the hard part is not the cryptography. Cosign makes signing one command. The hard part is deciding which identities your policy accepts — who is allowed to produce a release, what a valid identity looks like, and what you do when one of them is compromised. The cryptography is solved; the policy is a negotiation no tool will do for you.

A lockfile is not a security verdict either. Pinning resolved versions proves they have not changed; it does not prove they are safe. A vulnerable pinned version is still vulnerable, and treating the lockfile as the answer is how a team signs everything and scans nothing.

Read the Intro for the full chain — inventory, controlled change, isolated build, provenance, verification, policy. The Cheatsheet holds the SLSA levels and the Sigstore components side by side. The Timeline shows how SolarWinds, the 2021 executive order, SLSA, Sigstore, and the XZ backdoor turned a hope into a discipline. And the Quiz checks that the distinction between signing and verifying stuck — because that distinction is the whole point.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources