NIST SSDF (SP 800-218)

Les quatre groupes de pratiques

Le SSDF organise ses pratiques en quatre groupes. Chaque pratique énonce un résultat, et le NIST précise explicitement qu'il ne s'agit pas d'une checklist : c'est une base de planification fondée sur le risque.

Groupe	Objectif	Exemples
Préparer l'organisation (PO)	Les personnes, les processus et les outils sont prêts	Définir les exigences de sécurité, attribuer les rôles, sécuriser l'environnement de développement
Protéger le logiciel (PS)	Le code et les releases sont à l'abri de toute altération	Protéger le code sous toutes ses formes, vérifier l'intégrité des releases, archiver chaque release
Produire des logiciels bien sécurisés (PW)	Peu de vulnérabilités dans ce que vous publiez	Concevoir pour la sécurité, réutiliser des logiciels bien sécurisés, relire et tester le code
Répondre aux vulnérabilités (RV)	Trouver les failles restantes et les traiter	Identifier les vulnérabilités en continu, les prioriser et les corriger, analyser les causes profondes

Les pratiques qui touchent votre chaîne d'approvisionnement

• PO.3, chaînes d'outils de support, et PO.5, environnements sécurisés. Votre système CI fait partie de ce que vous devez protéger. Consultez la checklist de sécurité du pipeline CI/CD.
• PS.3, archiver et protéger chaque release. Cela inclut la collecte de données de provenance pour les composants de chaque release, et le SSDF cite la SBOM comme moyen d'y parvenir.
• PW.4, réutiliser des logiciels bien sécurisés. Les composants tiers doivent être vérifiés et tenus à jour, et c'est là qu'intervient l'analyse de la composition logicielle.
• RV.1, identifier les vulnérabilités de façon continue. C'est une obligation permanente, pas une étape de contrôle avant release : elle impose donc de surveiller ce que vous avez déjà livré.
• RV.2, évaluer, prioriser et corriger. Voir comment prioriser les vulnérabilités.

Le SSDF est-il obligatoire ?

Pas en soi. C'est une publication du NIST, pas une loi. Pendant quelques années, il a directement concerné les fournisseurs fédéraux américains, car les mémos OMB M-22-18 et M-23-16 les obligeaient à attester de pratiques qui en étaient tirées. Cela a changé le 23 janvier 2026 : le mémo OMB M-26-05 a abrogé ces deux mémos et adopté une approche fondée sur le risque. Les agences peuvent toujours utiliser le formulaire d'attestation commun et les normes du NIST, mais elles n'y sont plus tenues : les fournisseurs doivent donc s'attendre à des exigences variables selon l'agence.

En dehors des marchés publics fédéraux, le SSDF reste utile comme langage commun. Les clients s'en inspirent dans leurs questionnaires de sécurité, et il peut être mis en correspondance avec d'autres normes.

Les versions du SSDF

• La version 1.1, SP 800-218, publiée en février 2022, est la version finale actuelle.
• La version 1.2, SP 800-218 Revision 1, a été publiée sous forme de projet en décembre 2025.
• SP 800-218A est un profil communautaire qui étend le SSDF à l'IA générative et aux modèles de fondation à double usage.

Comment adopter le SSDF

1. Cartographiez ce que vous faites aujourd'hui. Parcourez les pratiques et notez où vous les respectez déjà, et avec quelles preuves.
2. Classez les écarts par risque. Le SSDF attend de vous que vous l'appliquiez en fonction de votre propre risque : toutes les pratiques ne méritent donc pas le même degré d'approfondissement.
3. Automatisez les preuves. Les preuves issues du pipeline restent à jour sans effort supplémentaire. Les preuves rédigées à la main se périment.
4. Désignez des responsables. Chaque pratique a besoin d'un responsable. La plupart relèveront de l'ingénierie plutôt que de la sécurité.
5. Faites des revues à intervalles réguliers. Mettez à jour la cartographie à mesure que vos outils changent et que la version 1.2 progresse.

SSDF, SLSA et le CRA

Le SSDF dit ce qu'un programme de développement sécurisé doit atteindre. SLSA approfondit l'une de ses parties, l'intégrité du build. Le Cyber Resilience Act de l'UE est une loi dotée de ses propres obligations. Le travail mené pour l'un profite aussi aux autres, car tous attendent de vous que vous sachiez ce que contient votre logiciel et que vous en traitiez les vulnérabilités.

La place de CRACI

Le SSDF est un vaste programme, et aucun outil ne le couvre. CRACI fournit des preuves pour les pratiques qui dépendent du build et de ce qui a été livré : SBOM de chaque job GitHub Actions, jobs isolés et contrôle du trafic sortant dans l'environnement de build, surveillance continue des logiciels livrés et tri de ce qu'il détecte. CRACI ne vous rend pas conforme, et la cartographie comme l'attestation restent de votre ressort. Consultez la sécurité de la chaîne d'approvisionnement logicielle avec CRACI.

NIST SSDF : questions fréquentes

Qu'est-ce que le NIST SSDF ?

Le Secure Software Development Framework, publié sous la référence NIST SP 800-218. C'est un ensemble de pratiques pour construire des logiciels sécurisés, organisé en quatre groupes : préparer l'organisation, protéger le logiciel, produire des logiciels bien sécurisés et répondre aux vulnérabilités.

Que signifie SSDF ?

Secure Software Development Framework.

Le SSDF est-il obligatoire ?

Non. C'est un guide, pas une loi. Les fournisseurs fédéraux américains devaient auparavant attester de pratiques qui en étaient tirées, mais le mémo OMB M-26-05 a abrogé cette exigence en janvier 2026. Les agences peuvent toujours demander des attestations.

Quelle est la dernière version du SSDF ?

La version 1.1 (SP 800-218, février 2022) est la version finale actuelle. La version 1.2 a été publiée sous forme de projet en décembre 2025 : vérifiez donc son statut sur le site du NIST.

Quelle est la différence entre le SSDF et SLSA ?

Le SSDF couvre le développement sécurisé dans son ensemble, à travers les personnes, les processus et la technologie. SLSA approfondit l'intégrité du build et la provenance. Ils se complètent bien.

Le SSDF exige-t-il une SBOM ?

Il vous demande de collecter et de partager des données de provenance pour les composants de chaque release, et cite la SBOM comme moyen d'y parvenir. Il décrit des résultats plutôt que d'imposer un outil précis.