Before installing an update, we usually check that it came from the expected supplier. For an in-house application, a successful build often serves as similar reassurance. Neither a familiar name nor passing tests answers the whole question: what produced this file, and who could change it before users received it?
Software supply chain security examines that delivery path. First-party code, a library, the build environment and the package registry may have different owners and access controls. A well-protected production server will still execute dangerous software if the normal release process delivers it as an approved update.
What ships besides our own code?
Consider a document-exchange service. It includes a file-processing library, transitive dependencies, a base image and build tools. Any of these can change the result without a modification to business logic. Some tools run only during the build but can still access its files and credentials.
Keep a reproducible inventory of inputs and permitted sources. Pinning versions or hashes reduces unexpected substitution between builds. It does not make the selected version safe forever: updating, testing and retiring vulnerable components remain necessary.
Tags can move. For example, GitHub recommends pinning third-party Actions to full commit SHAs. That identifies specific content, but does not prove the content is trustworthy. The permissions granted to that step matter too.
A builder need not be a deployer
Testing an unapproved change should be separate from publishing a production release. If tests of an external contribution receive production credentials, authority has already been granted before the code is accepted. A persistent shared runner can also carry unwanted files or processes between jobs.
Separate testing, package publication and deployment. Define allowed inputs, who can modify each stage and where privileged credentials become available. A change to build instructions deserves review just as application code does, especially when those instructions can sign and publish an executable.
Isolated runners, narrow permissions and temporary credentials address parts of the problem. The ability to change the trusted process remains powerful. Workload identity reduces permanent-key distribution; it should not grant production access to every job merely because a familiar platform runs it.
Composition, provenance and safety are different claims
A software bill of materials, or SBOM, lists components in a delivery. It helps identify products using a particular library. Its completeness depends on how it was generated: declared dependencies may omit something downloaded by a build script. Associate it with a specific finished package, not merely with a repository.
Provenance describes how that result was produced: the source, builder and relevant parameters. A signature supports verification of a claim and the party trusted to make it. It does not certify that the signed program contains no vulnerability or malicious behaviour.
Acceptance should compare the artifact's digest, trusted builder, expected source and important parameters. SLSA's verification guidance describes this process. Accepting any valid signature from any project misses the intended trust boundary.
Generating attestations is insufficient unless somebody verifies them before use. The GitHub attestation documentation makes this distinction explicit. Storing evidence and preventing an unacceptable deployment are separate capabilities.
Find what is already running
When a library is reported unsafe, “it appears in our code” is only the first answer. Which releases contain it, where are they installed, and which older installers remain available? Linking component inventory, immutable artifact identity and deployment location makes the information operationally useful.
Scanner results need assessment: a component may be present while the vulnerable path depends on how it is used and configured. Conversely, a clean report does not prove the absence of unknown problems. Exceptions to a blocking check need a reason, owner and review date, rather than disabling the scanner wholesale.
Following a compromise, a normal update may not be sufficient. Investigate builder access, published artifacts and possible misuse of exposed secrets. Replacing a dependency does not revoke a copied credential. A previous release also needs checks before it becomes a recovery option.
Follow one real release
Choose a finished package and trace it back to source and build. In a controlled test, offer the acceptance check a different digest, an unexpected source or a package without required evidence. Verify that publication is actually rejected, not merely that another report was produced.
Then locate every installation of the selected version and establish how it will be replaced. If that requires finding the release author in a chat, deployment inventory may be the next useful improvement. Elaborate provenance infrastructure cannot replace the basic link between a released file and a running product.