The Code You Trusted Came From Somewhere

A modern application is 80–90% open-source dependencies pulled from package registries, containers, and CI pipelines. An attacker who poisons that — a malicious package, a hijacked project, a backdoored build image — infects thousands of applications at once without touching a single one's source code. Supply-chain security is inventorying, verifying, and continuously watching every artifact you do not write yourself.

The Known Supply-Chain Attacks

Typosquatting publishes packages named one typo away from a popular one (requests vs requestss). Dependency confusion exploits a quirk where a private internal package name also exists publicly and can be pushed to the internal registry with a higher version, so the resolver pulls the attacker's copy. Package takeovers repackage dead-but-popular projects. Build-image poisoning bakes a compromise into the container you deploy. CI is a supply-chain target too: a compromised GitHub Action or an un-pinned build tool executes with the privileges of your pipeline — including your production credentials. Every one follows the same logic: the artifact you ingest is code, and code runs with somebody's privileges.

The Inventory Is the SBOM

You cannot secure what you cannot enumerate. A Software Bill of Materials (SBOM) is a machine-readable list of every component and dependency in a product — its registry fingerprints, versions, and licenses — generated at build time and kept current. From the SBOM you get the two operational tools: known-vulnerability scanning (GitHub Dependabot, Snyk, Trivy, pip-audit, npm audit) which replays your inventory against CVE feeds, and enforcement — gates that fail the build if a vulnerable or forbidden dependency lands. An SBOM is also the artifact you hand an auditor when "what did this release contain?" is asked.

Pinning, Signing, and Lock Files Their Way

Adopt the practices that make ingestion deterministic. Lock files (package-lock.json, poetry.lock, requirements.txt + hashes, container digests) freeze exact versions — reproducibility that also freezes security (patches then arrive by deliberate upgrade, not by drift). Signed artifacts (the digital-signatures lesson): verify package signatures and registry attestations; a broken signature aborts the install. Rename/typosquat protections: pre-register your own names and scan new registry releases for look-alikes. And pin CI: reference actions by full commit SHA, not by a moving @v1 tag, so the CI that builds you cannot be re-pointed at attacker code without you noticing.

The Operational Cadence

Security here is a rhythm, not a one-time fix. Scan on every commit/PR (fast, fail the merge) and on a schedule (deep, catch the long tail); watch advisory feeds for your exact packages and upgrade on a patched release with a SLA you can defend; rebuild containers from source rather than re-tagging old images; and treat an unexpected version bump in your own dependency tree as a security incident, because a hijacked package's first move is a plausible-sounding "security fix". The adoption question is the same as zero trust: you cannot patch what you cannot inventory — so the SBOM is not paperwork, it is the ammunition. Teams often start the routine with a disappointing first scan (modules nobody remembers adding, licenses nobody owns); that inventory is the point, not the failure mode. Budget the remediation backlog like a production issue, because a dependency you know nothing about is a dependency you cannot defend.