SLSA v1.0 became final in April 2023. Its release made software supply-chain assurances a timely topic for teams that already had continuous integration but little evidence about how a deployed artifact was produced.
Start with a release question
Given a running application, can the team identify its source revision, build run and artifact? If that requires somebody’s memory, begin there before pursuing a maturity label.
Build once, then promote that artifact between environments. Rebuilding separately for production introduces another input to investigate when staging and production behave differently. Keep environment-specific configuration outside the immutable application package.
Protect the path to production
Review who can change pipeline definitions and who can approve a deployment. Restrict credentials to the job that needs them. A pull request from an untrusted source should not receive production secrets just because it triggers a familiar workflow.
Retain the build record alongside the artifact, including dependency resolution information where available. Practise retrieving that evidence for a previous release.
Provenance is evidence about origin, not proof that software is free of vulnerabilities. Treat it as one input to release confidence alongside review, testing and operational monitoring. Any claim of a particular SLSA level needs verification against the relevant requirements.