Software Supply Chain Security: SBOMs, Provenance, and Signed Builds

Ask a team what their application is made of and you'll usually get an answer about the code they wrote. But in a typical modern service, the code the team authored is a thin layer on top of hundreds of third-party packages, a base container image, a CI system, and a handful of build plugins. All of it ships to production. Almost none of it gets the scrutiny the first-party code does.

That gap is the software supply chain, and it has become one of the most productive attack paths available. Compromising one widely used package or one build system reaches every downstream consumer at once — far better leverage than attacking targets individually.

Where the Real Risk Sits

Supply chain risk isn't one problem. It's four, and they need different controls:

• Dependency compromise: a legitimate package is taken over — through a hijacked maintainer account, a malicious contributor, or an abandoned project transferred to the wrong hands — and a malicious version is published under a name you already trust.
• Namespace attacks: typosquatting and dependency confusion, where an attacker publishes a package whose name is one keystroke away from yours, or matches an internal package name in a public registry your resolver also checks.
• Build system compromise: the source is clean, but the pipeline that compiles and packages it is not. This is the hardest class to detect, because the artifact never matches anything visible in the repository.
• Artifact tampering: a binary or image is altered between build and deployment, or pulled from a registry that was never verified in the first place.

A newer variant is worth naming: AI coding assistants sometimes suggest package names that don't exist. Attackers watch for those hallucinated names and register them. If your team accepts an import without checking that the package is real, established, and the one intended, that's a live path into your build.

Start With an SBOM

A Software Bill of Materials is an inventory of everything in a build — every dependency, its version, and its licence. The formats to know are SPDX and CycloneDX, both widely supported by tooling and increasingly expected by enterprise and government buyers.

The value isn't the document. It's the question it lets you answer in minutes instead of days: when a critical vulnerability lands in a widely used library, which of our services actually ship it, and in which versions? Teams without an SBOM spend the first day of an incident grepping repositories. Teams with one spend it patching.

Generate the SBOM as part of the build, store it alongside the artifact, and keep the history. An SBOM produced by hand once a quarter is documentation. One produced automatically per build is infrastructure.

Then Prove Where the Artifact Came From

An SBOM tells you what is inside a build. Provenance tells you how it was made. A provenance attestation is signed metadata recording which source commit, which builder, and which parameters produced a given artifact — so a consumer can verify that the thing they're about to deploy really came from the pipeline they trust.

The SLSA framework describes this as a set of increasing levels, and the progression is a useful roadmap: start by producing provenance at all, then make it generated by the build platform rather than the build script, then harden the platform itself so provenance can't be forged. You don't need the top level to benefit — most of the value arrives as soon as unverified artifacts stop being deployable.

Sign Everything You Ship

Signing closes the loop between build and deploy. Modern tooling has made this dramatically easier than it used to be: keyless signing flows tied to workload identity remove the long-lived private keys that made signing painful and, ironically, created their own risk. Container images, packages, and provenance attestations can all be signed and recorded in a transparency log.

The control that matters is on the other end. Verification has to be enforced at deployment — an admission policy in your cluster or a gate in your deployment pipeline that refuses anything unsigned or signed by an unexpected identity. Signatures nobody checks are decoration.

Harden the Pipeline Itself

Your CI system is production infrastructure with write access to everything you ship. Treat it that way:

• Pin dependencies: lockfiles for packages, digests rather than mutable tags for container images and CI actions. A tag can be moved; a digest cannot.
• Use short-lived credentials: federated identity between CI and your cloud provider removes standing secrets from the pipeline entirely.
• Isolate build steps: untrusted code — including dependency install scripts and pull requests from forks — should not run with access to release credentials.
• Restrict egress: a build job that can reach arbitrary hosts is a build job that can exfiltrate. Allowlist what it genuinely needs.
• Separate build from release: the identity that can publish to your registry should not be the one that runs every test job.
• Proxy your registries: an internal mirror gives you a single point to scan, cache, and block packages, and neutralises dependency confusion.

Making It Sustainable

The failure mode of supply chain security is noise. Turn on every scanner at once and you get thousands of findings, most of them unreachable code paths in transitive dependencies, and the team learns to ignore the dashboard. That is worse than not scanning.

A sequence that holds up in practice: generate SBOMs for every build first, so you have visibility. Then break the build only on critical, reachable vulnerabilities in direct dependencies, and triage the rest on a schedule. Add provenance and signing once artifacts are inventoried. Enforce verification at deploy last, after you've confirmed nothing legitimate is being blocked. Each step should be boring by the time you enable enforcement.

The goal isn't a perfect score against a framework. It's the ability to answer three questions quickly when something goes wrong: what is in this build, where did it come from, and can we prove it wasn't changed on the way to production.

MEGAFINTECH designs and hardens CI/CD pipelines, container platforms, and cloud infrastructure for companies that need delivery to stay fast and auditable at the same time. If you want your builds inventoried, signed, and verifiable end to end, get in touch and we'll review your pipeline with you.