SSDF 1.2 : le projet NIST de décembre 2025
Date du fait ou de la source : 2025-12-17. Cette date est distincte de la publication de notre analyse.
Le 17 décembre 2025, le NIST a publié SP 800-218 Rev. 1, version 1.2 du SSDF, avec le statut « Initial Public Draft ». La page officielle consultée présente toujours ce document comme projet. Il ne faut donc pas l’annoncer comme version finale. Pour un SaaS, cette publication est un sujet de veille sur le développement sécurisé ; les décisions de préparation doivent distinguer le référentiel utilisé et les pratiques examinées.
Le fait daté présenté en ouverture est documenté par la source primaire. Les sections suivantes proposent des décisions de préparation ; elles ne créent pas une obligation supplémentaire.
Garder le statut du document visible
Dans votre veille, notez la référence, la date et le statut du projet. Si une nouvelle version apparaît, organisez une comparaison plutôt qu’un remplacement silencieux de toutes les références. Les documents internes et les réponses clients doivent citer ce qui est effectivement utilisé. La version finale SSDF 1.1 reste une ressource distincte à consulter dans son état actuel. Un projet peut inspirer des questions, mais sa présence ne crée pas une nouvelle exigence automatique de votre mission ISO ou SOC 2.
Examiner un parcours de développement
Choisissez un changement représentatif du SaaS et retrouvez ses décisions, ses tests et son déploiement. Le CTO doit comprendre les contrôles appliqués et les exceptions. Les pratiques proposées dans une ressource publique ne prouvent pas l’exécution dans votre chaîne CI/CD. Un atelier peut comparer la description interne aux traces réelles. Identifiez les points où la procédure ne correspond plus aux outils. Gardez une portée limitée pour éviter une conclusion globale à partir d’un seul exemple.
Relier dépendances et décisions de correction
Les alertes de vulnérabilité demandent un propriétaire et un traitement. Vérifiez comment les priorités sont choisies et comment un report est justifié. Les délais annoncés aux clients doivent correspondre aux règles validées et aux pratiques. Un scanner ajoute de l’information ; il ne décide pas du risque résiduel. La préparation peut organiser le suivi dans vos outils existants, sans acheter un produit uniquement pour afficher une référence au SSDF.
Contrôler les secrets et accès CI/CD
La chaîne de livraison peut disposer de droits sensibles sur la production. Identifiez les comptes de service et les propriétaires, puis examinez leurs droits et les possibilités de retrait. Les preuves doivent décrire la gestion sans copier de valeurs de secrets. Si une démonstration est nécessaire, convenez de son périmètre et de ses modalités. La collecte doit rester adaptée au besoin d’examen et aux restrictions internes, plutôt que créer un dossier qui expose les moyens d’accès.
Décider ce qui sera adopté
Une revue de projet documentaire peut aboutir à une amélioration interne même sans obligation nouvelle. La direction et le CTO doivent distinguer la raison de l’action et la référence utilisée. Conservez une décision sur les pratiques retenues, leurs responsables et leur vérification. Lorsque vous demandez un devis, décrivez les changements à examiner et les limites de la mission. Aucun préparateur ne devrait annoncer une certification du produit par simple adoption d’un framework de développement.
Exemple de décision, fictif
Exemple fictif : le CTO lit le projet SSDF 1.2 et utilise cette veille pour examiner les comptes de service de CI/CD. La revue constate un jeton sans propriétaire identifié. L’équipe corrige l’inventaire et vérifie les droits. Le registre indique que la décision vient d’un risque interne éclairé par la veille. Il ne présente pas le projet comme une norme finale ni la correction comme une certification du logiciel.
Questions avant de décider
SSDF 1.2 est-il final ?
La page NIST de SP 800-218 Rev. 1 consultée indique « Initial Public Draft ». Vérifiez son statut actuel avant de modifier votre référence documentaire.
La publication modifie-t-elle automatiquement SOC 2 ?
Non. La portée et les critères d’une mission SOC 2 doivent être discutés avec le cabinet. Le projet est une ressource de veille distincte.
Préparer la suite du travail
Sources et portée de lecture
Les sources ci-dessous documentent le cadre ou le fait cité. Les propositions d’organisation sont des conseils de préparation à adapter à votre situation. Elles ne reproduisent pas le texte des normes et ne constituent pas une décision d’audit ni un avis juridique.