Question · SSDF · Protect Software (PS)
How does SLSA provenance satisfy SSDF requirements?
PS is one of the SSDF's four practice groups; it says organizations should protect all components of their software from tampering and unauthorized access.
01 / The answer
The short answer
SLSA provenance does not satisfy the SSDF on its own, but it is strong evidence for the Protect the Software (PS) practices. Signed, verifiable build attestations record where and how an artifact was built. That supports PS.2.1 (give acquirers a way to verify release integrity), PS.3.1 (archive each release with its integrity and provenance data) and PS.3.2 (collect and share provenance for release components). The SSDF is outcome-based, so map each SLSA control to the SSDF task it supports and keep records that it runs for every release.
02 / The rule
What SSDF · Protect Software (PS) requires
PS is one of the SSDF's four practice groups; it says organizations should protect all components of their software from tampering and unauthorized access. For AI work, NIST's generative AI profile (SP 800-218A) extends PS to training data, model weights and model provenance.
- 01PS.1.1: store all source code, executable code and configuration-as-code with least-privilege access for people, tools and services.
- 02PS.2.1: make integrity verification information, such as cryptographic hashes or signatures, available to software acquirers.
- 03PS.3.1: securely archive each release with its supporting data, such as integrity and provenance information.
- 04PS.3.2: collect, safeguard, maintain and share provenance data for all components of each release, for example in an SBOM.
03 / Records
Records to keep
- 01Repository access-control lists and access reviews
- 02Signed release artifacts and published hashes
- 03Release archive with integrity and provenance data
- 04SBOM or other provenance record for each release
Optional evidence · where Planisphere fits
Keep a record anyone can check
When your team meets a duty, Planisphere can seal the event it reports as a receipt.
A disclosure shown, a review signed, a model change approved: the event your system reports.
The event becomes a sealed receipt, dated and attributed to whoever is signed in.
Paste the receipt into Verify. No account or key.
A record supports your compliance evidence process. It is not a legal finding or a certification. Systems that call Planisphere's gate API can also hold or refuse an action before it runs.
SOURCES
Go back to the source
RELATED