Software Supply Chain Security
The software supply chain includes source code, dependencies, build systems, CI runners, package registries, container bases, deployment tools, and credentials. A secure application can be compromised by a poisoned dependency, a leaked token, or a malicious build step.
Provenance and SBOMs
Provenance answers where an artifact came from: source repository, commit, builder, build command, dependencies, and output digest. An SBOM lists software components inside an artifact. Neither is a silver bullet, but both improve incident response. When a new vulnerability is disclosed, teams need to know which artifacts contain the affected component.
Build Integrity
Strong build systems use pinned actions, least-privilege tokens, isolated runners for untrusted code, protected branches, reviewed workflow changes, and reproducible or verifiable builds where practical. SLSA provides levels for reasoning about build integrity and provenance.
Exercise
Choose a production artifact and trace it backward. Can you identify the source commit, build workflow, runner class, dependencies, image digest, and deployment approver? Each missing link is a supply-chain risk.
Dependency Trust
Dependencies are executable trust decisions. A package may include install scripts, transitive dependencies, native extensions, compromised maintainers, or abandoned code. Version pinning improves reproducibility but does not prove safety. Automated updates reduce stagnation but can introduce malicious or breaking changes. A mature system combines lockfiles, review, provenance, vulnerability intelligence, and rapid rollback.
Dependency confusion is a common pattern: an internal package name is accidentally resolved from a public registry. Registry configuration and namespace control are therefore security controls, not just developer convenience.
CI as an Attack Surface
CI systems often hold secrets, cloud permissions, package publish tokens, and deployment authority. Attackers target workflow definitions because a small YAML change can exfiltrate credentials or publish a malicious artifact. Protected branches, workflow review, pinned actions, isolated runners, and restricted token permissions reduce this risk.
Provenance Use
Provenance is valuable only when consumers check it. A deployment policy might require that production images were built by a trusted workflow from a protected branch, with no unreviewed builder changes. This turns provenance from paperwork into an enforceable control.
Study Task
Audit one repository for supply-chain exposure. Check unpinned actions, broad CI permissions, package publish tokens, public registry fallback, missing lockfiles, unowned dependencies, and whether production deploys verify artifact identity.
Operational Review
Supply-chain security should be reviewed from both directions. Trace a production artifact backward to its source, builder, dependencies, and approvals. Then trace a source change forward to the artifacts and environments it can affect. Any gap in either direction weakens incident response and trust.
The review should include people and automation. Which maintainers can approve dependency updates? Which workflows can publish packages? Which tokens can write to registries? Which runners execute untrusted pull requests? Which policy checks are mandatory, and who can bypass them?
A mature supply-chain posture does not assume every dependency is malicious. It assumes compromise is possible and designs for detection, containment, and recovery. Provenance, SBOMs, pinned workflows, isolated runners, and least privilege all reduce the distance between suspicion and action.