NIST SSDF (SP 800-218)

I quattro gruppi di pratiche

L'SSDF organizza le sue pratiche in quattro gruppi. Ogni pratica indica un risultato, e il NIST è esplicito nel dire che non è una checklist: è una base per una pianificazione fondata sul rischio.

Gruppo	Obiettivo	Esempi
Preparare l'organizzazione (PO)	Persone, processi e strumenti sono pronti	Definire i requisiti di sicurezza, assegnare i ruoli, proteggere l'ambiente di sviluppo
Proteggere il software (PS)	Codice e release sono al sicuro dalle manomissioni	Proteggere il codice in ogni sua forma, verificare l'integrità delle release, archiviare ogni release
Produrre software ben protetto (PW)	Poche vulnerabilità in ciò che si rilascia	Progettare per la sicurezza, riutilizzare software ben protetto, revisionare e testare il codice
Rispondere alle vulnerabilità (RV)	Trovare i difetti rimanenti e gestirli	Identificare le vulnerabilità di continuo, dare loro priorità e correggerle, analizzare le cause profonde

Le pratiche che riguardano la Sua supply chain

• PO.3, toolchain di supporto, e PO.5, ambienti sicuri. Il Suo sistema CI fa parte di ciò che deve proteggere. Veda la checklist di sicurezza per la pipeline CI/CD.
• PS.3, archiviare e proteggere ogni release. Ciò comprende la raccolta dei dati di provenance per i componenti di ogni release, e l'SSDF indica la SBOM come un modo per farlo.
• PW.4, riutilizzare software ben protetto. I componenti di terze parti vanno valutati e mantenuti aggiornati, ed è qui che si inserisce la software composition analysis.
• RV.1, identificare le vulnerabilità in modo continuativo. È un dovere continuativo, non un controllo al momento del rilascio, quindi richiede di monitorare ciò che è già stato distribuito.
• RV.2, valutare, dare priorità e correggere. Veda come dare priorità alle vulnerabilità.

L'SSDF è obbligatorio?

Di per sé no. È una pubblicazione del NIST, non una legge. Per alcuni anni ha contato direttamente per i fornitori federali statunitensi, perché i memo OMB M-22-18 e M-23-16 imponevano loro di attestare pratiche tratte da esso. Le cose sono cambiate il 23 gennaio 2026: il memo OMB M-26-05 ha revocato entrambi e ha adottato un approccio basato sul rischio. Le agenzie possono ancora usare il modulo di attestazione comune e gli standard del NIST, ma non sono più obbligate a farlo, quindi i fornitori devono aspettarsi requisiti diversi da un'agenzia all'altra.

Al di fuori degli appalti federali, l'SSDF resta utile come linguaggio comune. I clienti vi attingono nei questionari di sicurezza ed è mappato su altri standard.

Versioni dell'SSDF

• La versione 1.1, SP 800-218, pubblicata nel febbraio 2022, è l'attuale versione definitiva.
• La versione 1.2, SP 800-218 Revision 1, è stata pubblicata come bozza nel dicembre 2025.
• SP 800-218A è un profilo della community che estende l'SSDF all'IA generativa e ai modelli di base a duplice uso.

Come adottare l'SSDF

1. Mappi ciò che fa oggi. Esamini le pratiche e registri dove le soddisfa già, e con quali evidenze.
2. Ordini le lacune in base al rischio. L'SSDF presuppone che venga applicato in base al proprio rischio, quindi non tutte le pratiche meritano la stessa profondità.
3. Automatizzi le evidenze. Le evidenze che escono dalla pipeline restano aggiornate senza lavoro aggiuntivo. Quelle scritte a mano diventano obsolete.
4. Assegni i responsabili. Ogni pratica ha bisogno di una persona responsabile. La maggior parte ricadrà sull'engineering più che sulla sicurezza.
5. Riveda a intervalli prestabiliti. Aggiorni la mappatura man mano che cambiano i Suoi strumenti e che la versione 1.2 avanza.

SSDF, SLSA e CRA

L'SSDF dice che cosa dovrebbe ottenere un programma di sviluppo sicuro. SLSA va in profondità su una sua parte, l'integrità della build. Il Cyber Resilience Act dell'UE è una legge con obblighi propri. Il lavoro fatto per uno vale anche per gli altri, perché tutti si aspettano che Lei sappia che cosa c'è nel Suo software e ne gestisca le vulnerabilità.

Dove si colloca CRACI

L'SSDF è un programma ampio e nessuno strumento lo copre. CRACI fornisce evidenze per le pratiche che dipendono dalla build e da ciò che è stato distribuito: SBOM da ogni job GitHub Actions, job isolati e controllo dell'egress nell'ambiente di build, monitoraggio continuo del software distribuito e triage di ciò che trova. CRACI non La rende conforme, e la mappatura e l'attestazione restano a Suo carico. Veda la sicurezza della software supply chain con CRACI.

NIST SSDF: domande frequenti

Che cos'è il NIST SSDF?

Il Secure Software Development Framework, pubblicato come NIST SP 800-218. È un insieme di pratiche per sviluppare software sicuro, organizzate in quattro gruppi: preparare l'organizzazione, proteggere il software, produrre software ben protetto e rispondere alle vulnerabilità.

Che cosa significa SSDF?

Secure Software Development Framework.

L'SSDF è obbligatorio?

No. È una guida, non una legge. In passato i fornitori federali statunitensi dovevano attestare pratiche tratte da esso, ma il memo OMB M-26-05 ha revocato questo requisito nel gennaio 2026. Le agenzie possono ancora chiedere attestazioni.

Qual è l'ultima versione dell'SSDF?

La versione 1.1 (SP 800-218, febbraio 2022) è l'attuale versione definitiva. La versione 1.2 è stata pubblicata come bozza nel dicembre 2025, quindi ne verifichi lo stato sul sito del NIST.

Qual è la differenza tra SSDF e SLSA?

L'SSDF copre lo sviluppo sicuro nel suo insieme, tra persone, processi e tecnologia. SLSA va in profondità su integrità della build e provenance. Funzionano bene insieme.

L'SSDF richiede una SBOM?

Chiede di raccogliere e condividere i dati di provenance per i componenti di ogni release e indica una SBOM come un modo per farlo. Descrive risultati, non impone uno strumento specifico.