Software Supply Chain Security

A supply chain attack compromises software upstream — in a dependency, build system, or distribution mechanism — so that the malicious payload flows through trusted channels into every downstream consumer. Because organizations trust their dependencies and build tools implicitly, one compromise can cascade to thousands of victims. Notorious examples include SolarWinds (compromised build pipeline) and the wave of malicious npm/PyPI packages. Defending the supply chain has become a top security priority, shifting focus from "is my code secure?" to "is everything that produced my software trustworthy?"

An SBOM is a formal, machine-readable inventory of everything in your software: direct and transitive dependencies, versions, and licenses. Standard formats are CycloneDX and SPDX. Its killer use case is rapid incident response: when a critical CVE like Log4Shell is announced, organizations with SBOMs can query "which of our products contain the affected library?" in minutes, while those without spend days manually hunting. SBOMs also support license compliance and are increasingly required by regulation and enterprise procurement.

SLSA ("salsa" — Supply-chain Levels for Software Artifacts) is a security framework defining maturity levels for protecting the build and release process. Higher levels demand stronger guarantees: that builds are scripted and reproducible, run on a hardened build service, produce signed provenance (verifiable metadata about how and from what an artifact was built), and are resistant to tampering. It gives organizations a concrete, incremental roadmap — moving from level 1 (basic provenance) toward level 3+ (tamper-resistant, fully attested builds) — rather than a vague "be more secure."

Artifact signing attaches a cryptographic signature to a build output (container image, package, binary). Consumers verify the signature before use, gaining two guarantees: authenticity (it came from the legitimate publisher) and integrity (it has not been altered in transit or storage). Sigstore and its Cosign tool make this practical by enabling keyless signing tied to identity (e.g. an OIDC identity), with a transparency log recording signatures. Verifying signatures at deploy time is a core defense against an attacker substituting a malicious artifact for a trusted one.

Dependency confusion (Alex Birsan, 2021) exploits how package managers resolve names across public and private registries. An attacker publishes a package to a public registry (npm, PyPI) with the same name as a target company's internal package. If the build tool is misconfigured to check the public registry — and the attacker uses a higher version number — it may pull the attacker's malicious package instead of the legitimate internal one. Defenses: scoped/namespaced packages, explicitly pinning registries per dependency, and reserving your internal names publicly.