SSDF practices PS.1 to PS.3 ask you to restrict access to all forms of code, give customers a way to verify release integrity, and archive each release with provenance data such as an SBOM. Evidence is repository permissions, signing or hash records, and stored release bundles.
The three practices
| Practice | Purpose | Task |
|---|---|---|
| PS.1 | Protect all forms of code from unauthorized access and tampering | PS.1.1 |
| PS.2 | Provide a way to verify release integrity | PS.2.1 |
| PS.3 | Archive and protect each software release | PS.3.1, PS.3.2 |
PS.1: protect code
PS.1.1 says to store source code, executable code and configuration as code using least privilege. Examples include keeping everything in a repository, tracking changes to individual accounts, commit signing, code owner approval of changes, code signing for executables and hashes for file integrity.
Evidence: permission exports, branch rule settings, a sample of signed commits or approvals.
PS.2: verify integrity
PS.2.1 asks you to make integrity verification information available to acquirers. Examples include posting hashes for release files on a secured site and using an established certificate authority for code signing. The document also suggests periodic review of the signing process, including renewal, rotation and revocation.
Evidence: published hashes, signature verification steps, key rotation records.
PS.3: archive releases
PS.3.1 asks you to securely archive the files and supporting data for each release, including integrity information and provenance data. PS.3.2 asks you to collect, safeguard, maintain and share provenance data for all components of each release, for example in a software bill of materials. Examples include standards based formats, sharing with acquirers and response teams, protecting the data's integrity, and updating it whenever a component changes.
Evidence: a release archive with read only access, an SBOM per release, a record of updates.
Release checklist
- Tag the release and record who approved it.
- Generate and store the SBOM.
- Sign or hash the artifacts.
- Archive everything with restricted access.
- Record where the archive lives.
Try it yourself
Open the demo and see a dependency inventory for a project. This is the component data that PS.3.2 asks you to keep per release.
Click through it at your own pace, or open it full screen.
Quick check
Is an SBOM mandatory for PS.3.2?
The task names provenance data, with an SBOM as an example. It is one accepted form, not the only one.
Why archive old releases?
The practice says it helps identify, analyze and eliminate vulnerabilities found after release, which needs the exact files and components that shipped.
Where tooling helps
Safeguard offers SBOM and dependency scanning and compliance and evidence automation, which can keep a dated component record per release. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
