United States (federal) · federal standard
SSDF · Protect Software (PS): what it asks, and the records to keep
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.
01 / What it asks
What SSDF · Protect Software (PS) asks
Software producers, including vendors selling software to US federal agencies, and their development teams.
- 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.
02 / AI work
Where it touches AI work
SP 800-218A adds PS.1.2 (protect training, testing, fine-tuning and aligning data) and PS.1.3 (protect model weights and configuration parameters), and applies PS.1.1, PS.2.1 and PS.3.2 to models, weights, pipelines and model provenance.
03 / Dates
The dates that matter
SP 800-218 (SSDF 1.1) published with PS.1 to PS.3
SP 800-218A adds AI-specific PS.1.2 and PS.1.3 tasks
Draft SSDF 1.2 (SP 800-218 Rev. 1) released for comment
Comment period on draft SSDF 1.2 closed
04 / Enforcement
Who enforces it
None directly; voluntary. Agencies may require SSDF practices or an attestation by contract, and false contract representations can create False Claims Act exposure.
05 / Records
Records an organisation keeps
What an auditor or an inquiry usually asks to see. Your obligations depend on your role and your facts.
- 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.
QUESTIONS
The questions that come next
How does SLSA provenance satisfy SSDF requirements?+
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. Read the full answer
SOURCES
Go back to the source
CHANGE LOG
What changed, and when
Rebuilt from primary sources; facts checked on this date.
Related: SSDF · Protect Software (PS) for defense AI workflows · NIST AI RMF · OMB M-25-21/22 · DoW RAI S&IP · EO 14179 · FIPS 140-3 · SHA-256 / FIPS 180-4