A clean source repository does not guarantee a clean software release. Code can be altered through compromised dependencies, build runners, container images, or publishing credentials before it reaches production. Security checks, therefore, need to follow the software through every stage, not appear only when the finished artifact is ready to deploy.
Know what can change the software before release
Teams examining how to prevent software supply chain attacks first need to map every system capable of changing code before deployment. The Minimus analysis also looks beyond third-party packages, covering the repositories, build systems and registries that can alter software before release.
A malicious package may enter through a public repository. Stolen credentials can give someone permission to modify a workflow or publish a replacement release. A compromised build service may alter an artifact while the source repository still appears untouched.
The 2024 XZ Utils incident showed why reviewing visible source code is not always enough. Malicious code was placed in release tarballs and activated during the build process, while part of the mechanism was absent from the public Git repository. Verification has to cover the packaged source, build inputs and resulting binary, as well as visible changes in version control.
Lock down the systems that create each build
CI/CD infrastructure is a valuable target because it often holds signing keys, registry credentials and permission to create trusted releases. Once a runner is compromised, a legitimate pipeline can distribute altered software.
Persistent runners create extra risk when cached files, environment variables, or credentials remain available between jobs. Using a fresh runner for each build limits what can survive from an earlier task. Each runner should receive only the secrets it needs and be removed when the work is complete. Permissions also need to be separated by function. A testing job should not be able to publish images to a production registry, while a build job should not receive broader cloud access than required.
Different inputs need different forms of pinning. CI/CD actions can be fixed to commit hashes, container base images to immutable digests and language dependencies through lockfiles and checksum verification. Movable tags such as “latest” are less reliable because their contents can change without any update to the pipeline configuration. Build provenance records of the source revision, inputs and builder used to create an artifact. SLSA 1.2 separates protections for the build process from controls covering the origin and handling of source code.
Verify dependencies and artefacts at the gate
Verizon’s 2025 Data Breach Investigations Report found third-party involvement in 30% of the breaches analyzed, up from 15% in the previous report. The figure includes more than software dependencies, but it illustrates how frequently a breach involves systems outside the victim’s direct control. A pre-production gate should answer three questions. Is the component known? Did it come from the expected build? Has it changed since that build?
An SBOM lists packages and versions. Provenance records how the artifact was created, while a valid signature or attestation provides evidence that it has not been replaced since leaving the approved build process. Vulnerability scanning serves another purpose. It checks known components against published flaws but cannot confirm that an image came from an approved builder. A valid signature also says nothing about whether the signed software contains a known vulnerability. No single check answers every question.
Protecting signing keys is equally important. Guidance on verifying software with code-signing certificates explains why automated verification is safer than ad hoc manual checks. Unsigned or unexpected artifacts should be rejected instead of simply recorded in a log.
Reduce what reaches production
Every additional package in a container creates another component to inventory, scan, update and investigate when a vulnerability is disclosed. Reducing that footprint leaves fewer dependencies through which inherited weaknesses can enter.
Minimus examines this risk through reduced package counts, frequently rebuilt container images and records showing which components each image contains. This does not make an image immune to compromise. It leaves fewer packages to inspect, fewer unexpected tools inside the container and less software to maintain.
Minimal images still need regular rebuilding and scanning. An image that appears secure when created may later contain a dependency affected by a newly published vulnerability.
A production gate can turn those principles into six checks:
- Is each dependency pinned and verified?
- Was the image created by an approved, isolated runner?
- Does the artifact have valid provenance and a recognized signature?
- Is an SBOM tied to this exact release?
- Did scanning run against the final image?
- Have any unapproved package or base-image changes appeared?
A failed check should stop promotion. Logging the result as a warning pushes the decision into a release window, when deadlines make exceptions more likely.
Make production admission depend on evidence
A final scan cannot make up for weak controls earlier in the build. Source records, locked dependencies, isolated runners, provenance and signatures each address a different point where trust can break down.
Monitoring must continue after release because a dependency that appears safe today may be affected by a new disclosure tomorrow. Before deployment, however, the rule should remain straightforward: when a team cannot verify where an artifact came from, what it contains, or how it was built, it should not reach production.
