Software Supply Chain Security

A formal, machine-readable inventory of all components, libraries, and dependencies that make up a software product, including version numbers and licensing information.

"After the Log4Shell vulnerability, we generated an SBOM for every service and queried it to identify which ones included a vulnerable version of log4j — in minutes rather than days."

Supply chain Levels for Software Artefacts — a security framework defining four progressive levels of build integrity controls, from basic scripted builds (Level 1) to fully hermetic, verified provenance (Level 4).

"Achieving SLSA Level 2 required us to use a hosted build service and generate signed provenance for every artefact — it took a sprint to implement but now we can verify build origin automatically."

Verifiable metadata that describes where a software artefact came from, how it was built, and what source code produced it — allowing consumers to trust the artefact's origin.

"The provenance record proved the container image was built from commit a3f7c2 in our internal CI — not from a tampered copy introduced by a compromised developer machine."

An open-source project providing free tools (cosign, fulcio, rekor) for signing, verifying, and recording software artefact signatures using short-lived certificates tied to developer identities.

"We use cosign from the Sigstore project to sign every Docker image at build time — deployment scripts verify the signature before pulling, rejecting any unsigned or tampered image."

An attack where a malicious public package with the same name as a private internal package is uploaded to a public registry, causing build tools that check public registries first to install the attacker's package instead.

"The dependency confusion attack succeeded because our npm config checked the public registry before our private one — adding a scoped namespace and explicit registry mapping for internal packages fixed it."

A supply chain attack where malicious packages are published with names closely resembling legitimate popular packages (e.g. "coloers" vs "colors"), hoping developers install them by mistake.

"Security scanning found that one of our services was importing 'reqests' — a typosquatted package mimicking the popular 'requests' library. The developer had mistyped it during initial setup."

A dependency that your project does not directly import but is pulled in by one of your direct dependencies. Transitive dependencies are often overlooked in security reviews despite representing the majority of a project's attack surface.

"The vulnerability wasn't in any library we directly depended on — it was in a transitive dependency three levels deep. The SBOM helped us trace the dependency chain and identify which service to patch first."

Automated tooling that analyses an application's open-source components and dependencies to identify known vulnerabilities (CVEs), licence compliance issues, and outdated packages.

"We integrated SCA into the CI pipeline — every pull request is now scanned by Dependabot and Snyk. Critical CVEs in dependencies block the merge until remediated."

Locking dependencies to a specific exact version or cryptographic hash rather than a version range, ensuring every build uses identical packages and preventing unexpected updates from introducing vulnerabilities.

"After the malicious update incident in the ecosystem, we moved from semver ranges to exact pinning with integrity hashes in our lock file — no dependency can silently change between builds."

A build process that is fully isolated from the external network and file system — all inputs are explicitly declared and fetched in advance, making builds reproducible and immune to supply chain tampering during the build step.

"Our hermetic builds run with network access disabled — all dependencies are pre-fetched into a content-addressed cache. An attacker cannot inject a malicious package by compromising a registry mid-build."

A cryptographically signed statement by a trusted build system asserting that a specific artefact was produced from a specific source at a specific time under specific conditions.

"The deployment pipeline verifies the build attestation before promoting an image to production — if the signature doesn't match the expected builder identity, the promotion is blocked automatically."

A build process that produces bit-for-bit identical output whenever given the same source code and build environment, allowing anyone to independently verify that a released binary matches its published source.

"We verified the reproducible build by rebuilding the release from source on a separate machine and comparing SHA-256 hashes — the output was identical, confirming the release binary hadn't been tampered with post-build."