Pendant trois décennies, la cryptographie est restée discrètement en arrière-plan du développement d’ software . Elle protégeait le trafic et signait de temps à autre une version, mais elle était rarement évoquée lors des réunions de direction.
Mais les choses ont changé. Aujourd’hui, un directeur général signe personnellement un document attestant que son entreprise respecte les pratiques de développement sécurisé, et le SSDF est au cœur de cet engagement.
Cette signature n'est pas une simple formalité. Il s'agit d'une déclaration officielle ayant une valeur juridique, et les éléments justificatifs sur lesquels elle repose doivent tenir la route si un acheteur fédéral venait à en demander la présentation. Ce guide explique ce qu'exige le cadre réglementaire, pourquoi la signature de code et la gestion des clés revêtent une telle importance, et comment établir une preuve solide.
En quoi consiste réellement la norme NIST SP 800-218 (SSDF) ?
Le cadre de développement sécurisé d'Software s (SSDF) correspond à la publication spéciale 800-218 du NIST. Le NIST a publié la version 1.1 en février 2022.
Plutôt que de constituer une liste de contrôle normative, le SSDF décrit les résultats que le développement sécurisé doit permettre d'atteindre. Cela permet aux équipes de l'adapter au cycle de vie de développement qu'elles utilisent déjà. Le cadre organise ces résultats en quatre groupes :
- Préparez l'entreprise : assurez-vous que le personnel, les processus et les outils sont prêts à développer des applications « software » en toute sécurité.
- Protéger l'software: Protéger toutes les formes de code contre toute altération et tout accès non autorisé.
- Développer des applications bien sécurisées software: Concevoir, développer et tester software afin qu’elle présente le moins de vulnérabilités possible au moment de sa mise en production.
- Réagir aux vulnérabilités : identifier, évaluer et corriger les problèmes dans les versions publiées d'software, puis empêcher qu'ils ne se reproduisent.
Pourquoi le SSDF est devenu une exigence en matière de marchés publics
Ce cadre est passé du statut de « bonne pratique » à celui de « condition d’achat » à la suite d’une série de mesures politiques fédérales. Le décret présidentiel n° 14028 (du 12 mai 2021) a en effet enjoint aux agences de renforcer les exigences en matière de sécurité de la chaîne d’approvisionnement « software ».
Le mémorandum M-22-18 de l’OMB (14 septembre 2022), tel que modifié par le mémorandum M-23-16 (9 juin 2023), est allé plus loin. Il a fait de la conformité certifiée au SSDF une condition préalable à l’utilisation, par les agences fédérales, des « software » concernés. Dans la pratique, les fabricants devaient signer avant que les agences puissent continuer à acheter ces produits. Le décret présidentiel n° 14306 (6 juin 2025) a ensuite abrogé les dispositions du décret n° 14144 relatives aux attestations et à la formulation des contrats du FAR, et a chargé le NIST de mettre à jour le SSDF.
La situation actuelle est plus nuancée. Le mémorandum M-26-05 de l’OMB (23 janvier 2026) a abrogé les mémorandums M-22-18 et M-23-16, remplaçant l’obligation applicable à l’ensemble de l’administration par une approche pilotée par les agences et fondée sur les risques. L'utilisation du formulaire commun de la CISA est désormais facultative pour les agences, et non plus obligatoire. Les agences conservent la faculté de demander des attestations et des SBOM, et le dossier FAR n° 2023-002 reste ouvert.
Qui doit s'en soucier (et cela ne concerne pas uniquement les fournisseurs fédéraux)
Trois groupes sont directement concernés. Premièrement, tout producteur d'software s qui vend aux agences fédérales. Deuxièmement, le PDG ou la personne habilitée à le représenter qui appose effectivement sa signature.
Troisièmement, et de plus en plus souvent, les acheteurs commerciaux. Les banques, les organismes de santé et les grandes entreprises font désormais référence au SSDF dans leurs questionnaires sur les risques liés aux fournisseurs. Ce référentiel est devenu un langage commun en matière de développement sécurisé, et son champ d’application dépasse donc largement le cadre des marchés publics fédéraux.
L'attestation est une signature, pas une case à cocher
Les producteurs signent le formulaire d'attestation relatif au développement sécurisé d'Software s, mis à disposition par la CISA. Le PDG ou un dirigeant désigné atteste, en toute bonne foi, que ces pratiques sont bien mises en œuvre.
Voici ce qui rend la situation d'autant plus délicate : il n'existe aucun système de certification par un organisme tiers. Aucun auditeur ne délivre de certificat permettant de trancher la question. La conformité repose entièrement sur les preuves conservées en interne par le producteur.
Le formulaire précise que le fait de fournir délibérément des informations fausses ou trompeuses peut constituer une infraction à l’article 18 U.S.C. § 1001, une disposition pénale, et qu’une fausse déclaration peut également entraîner des poursuites civiles au titre de la loi sur les fausses déclarations (False Claims Act). Une lacune dans la documentation devient ainsi un risque juridique, ce qui explique pourquoi les justificatifs sur lesquels repose la signature sont tout aussi importants que la signature elle-même.
Les pratiques qui ont le plus d'importance sur le plan cryptographique pour le SSDF
Plusieurs pratiques dépendent directement de la signature de code et de la gestion des clés. Ce sont celles que les évaluateurs peuvent vérifier à l'aide de preuves cryptographiques ; elles méritent donc toute notre attention.
P.S. 1 : protéger toutes les formes de code contre toute altération
PS.1 demande aux producteurs de protéger les artefacts source, de compilation et de publication contre toute modification non autorisée. Cela implique de mettre en place des contrôles d'accès et des mesures de protection de l'intégrité tout au long du pipeline. Les commits signés et les systèmes de compilation protégés vous fournissent des preuves d'intégrité que vous pourrez présenter ultérieurement.
P.S. 2 : offrir aux consommateurs un moyen de vérifier l'intégrité de la version
La spécification PS.2 prévoit un mécanisme permettant aux utilisateurs de vérifier qu’une version correspond bien à ce que le développeur a publié. Concrètement, chaque artefact de la version est signé cryptographiquement et les éléments de vérification sont publiés. Toute personne téléchargeant le fichier « software » peut alors vérifier la signature avant de se fier au code.
PS.2 et PO.5 : protéger les clés de signature elles-mêmes
La fiabilité d'une signature dépend entièrement de celle de la clé qui la sous-tend. La norme PS.2 préconise un examen périodique du processus de signature de code, notamment en ce qui concerne le renouvellement, la rotation, la révocation et la protection des certificats. La norme PO.5 traite des environnements sécurisés dans lesquels s'effectue la signature, y compris les environnements de compilation et de distribution.
Cela implique de générer et de stocker des clés privées dans hardware, de limiter les personnes autorisées à signer, et de contrôler régulièrement le renouvellement, la rotation et la révocation des clés. Une clé de signature volée permet à un pirate de signer un logiciel malveillant qui ressemble au vôtre ; ce contrôle vous protège donc, vous et vos clients.
PW.6 : renforcement de la sécurité lors de la compilation
Le document PW.6 s'intitule « Configurer les processus de compilation, d'interprétation et de construction pour améliorer la sécurité des exécutables ». Il vient compléter la signature des artefacts plutôt que de la remplacer.
Son objectif est de réduire le nombre de vulnérabilités, ainsi que le coût de leur correction, en éliminant les défauts avant le début des tests. Il comporte deux tâches. Premièrement, utiliser un compilateur, un interpréteur et des outils de compilation dotés de fonctionnalités renforçant la sécurité. Deuxièmement, choisir les fonctionnalités à utiliser, les configurer et appliquer systématiquement les configurations approuvées.
RV.2 : listes de composants logiciels (SBOM) signées et traçabilité pour une réponse rapide
Lorsqu’une vulnérabilité est révélée, la rapidité d’action dépend de la connaissance précise du contenu des produits livrés. RV.2 privilégie les nomenclatures « Software » (SBOM) signées et les attestations de provenance. Les SBOM signées permettent d’identifier rapidement les composants concernés et de prouver l’authenticité de l’inventaire, ce qui réduit le délai entre la divulgation et la correction.
Constituer le dossier de preuves à l'appui de l'attestation
Le formulaire signé ne représente qu'une infime partie de la conformité. Ce qui la justifie, c'est un dossier de preuves démontrant que les pratiques sont effectivement mises en œuvre. Rassemblez ces six éléments et présentez d'emblée les preuves correspondantes pour chacun d'entre eux :
- Dossier justificatif : conservez le formulaire signé ainsi que les pièces justificatives étayant chacune des affirmations qui y figurent.
- Protection des clés de signature de code : démontrer que les clés privées sont conservées dans un « hardware » et que l'accès à la fonction de signature est contrôlé.
- Vérification de l'intégrité d'une version : présenter un mécanisme opérationnel permettant aux utilisateurs de vérifier une version.
- Contrôle d'accès au pipeline de compilation : conserver les journaux permettant de déterminer qui a pu accéder à l'infrastructure de compilation et de mise en production, et à quel moment.
- SBOM signée et traçabilité : générer des inventaires de composants signés et des données de traçabilité pour les versions publiées de software.
- Auto-évaluation honnête : demandez-vous si ces éléments probants résisteraient à une contestation, puis comblez les lacunes que vous constatez.
Comment Keyfactor vous aider
Keyfactor permet aux producteurs d'software s de transformer ces pratiques en données issues d'un système unique, plutôt que d'une douzaine d'outils disparates.
Keyfactor AgileSec constitue la première étape fondamentale. Il détecte et recense les actifs cryptographiques présents dans le code, les pipelines de compilation et l’infrastructure cloud, ce qui vous permet de savoir où se trouvent réellement les clés de signature et les certificats. AgileSec génère également une SBOM signée et des données de provenance compatibles avec la norme RV.2, ainsi que des rapports centralisés pour le dossier de preuves d’attestation.
EJBCA émet et gère les certificats utilisés pour la signature de confiance. Il fournit l'autorité de certification ainsi que les certificats de signature de code qui garantissent l'authenticité des identités de signature tout au long de votre chaîne de compilation et de publication.
Keyfactor SignServer centralise la signature. Il signe les commits, les versions, les résultats de compilation et les images de conteneurs à partir d’un seul système, qui correspond directement aux versions PS.1, PS.2, PS.3 et aux builds sécurisés de PW.6. Pour les équipes CI/CD distribuées, Keyfactor Signum intègre la signature de code dans les workflows existants des développeurs.
Keyfactor Command automatise le cycle de vie des certificats et des clés requis par les normes PO.3 et PS.2. Il gère le cycle de vie des clés de signature de code et des certificats, et génère les rapports centralisés qui alimentent votre dossier de preuves d'attestation.
Associez ces éléments au « Trust Control Plane » d’ Keyfactor , un système de référence unique qui surveille, provisionne, orchestre et régit les clés de signature et les preuves. Lorsque les preuves étayant votre attestation proviennent d’une seule et même source, leur protection devient une procédure de routine plutôt qu’une course effrénée.
Faire du SSDF une capacité signée et vérifiable
La conformité au SSDF est une capacité opérationnelle, et non un projet ponctuel. Les clés changent, les pipelines évoluent et des vulnérabilités apparaissent ; les preuves doivent donc être tenues à jour.
L'avantage réside dans l'effet de levier. L'infrastructure de signature et de preuve qui sous-tend une attestation fédérale permet également de répondre aux questionnaires de sécurité commerciaux émis par les banques, le secteur de la santé et les entreprises. Il suffit de la mettre en place une seule fois pour satisfaire les deux.
Commencez dès maintenant : dressez un inventaire des méthodes de signature de votre code et de vos versions, vérifiez comment les clés de signature sont protégées, et constituez des preuves que vous pourriez défendre en cas d’examen approfondi. Demander une démo Découvrez comment « Keyfactor » fait du développement sécurisé une capacité signée et vérifiable.
Vous avez des questions sur le SSDF ? Nous avons les réponses.
Qu'est-ce que la norme NIST SP 800-218 (SSDF) ?
La norme NIST SP 800-218, intitulée « Secure Software Development Framework » (Cadre de développement de logiciels sécurisés), est un ensemble de pratiques axées sur les résultats, réparties en quatre groupes : préparer l'organisation, protéger l'software, produire des logiciels hautement sécurisés software et réagir aux vulnérabilités. Elle décrit les objectifs que doit atteindre un développement sécurisé plutôt que de prescrire une liste de contrôle figée.
Qui doit se conformer au SSDF ?
Tout producteur de documents « software » vendant au gouvernement fédéral peut être amené à attester de son respect des pratiques du SSDF. Les acheteurs commerciaux, tels que les banques, les organismes de santé et les grandes entreprises, font de plus en plus référence au SSDF dans leurs questionnaires sur les risques liés aux fournisseurs ; sa portée s'étend donc bien au-delà des contrats fédéraux.
Qu'est-ce que le formulaire d'attestation « Secure Software Development» (SSDF) de la CISA ?
Il s'agit du formulaire que les développeurs d'software s signent pour déclarer qu'ils respectent les pratiques SSDF. Les directives M-22-18 et M-23-16 obligeaient les agences à le collecter. L’OMB a abrogé ces deux directives en janvier 2026 ; l’utilisation du formulaire relève donc désormais de la décision de chaque agence. Lorsqu’une agence le demande, le PDG ou une personne désignée, employée et habilitée à engager l’entreprise, le signe, attestant en toute bonne foi que ces pratiques sont bien en place.
L'attestation SSDF a-t-elle force obligatoire ?
Oui. Il s'agit d'une déclaration officielle ayant une valeur juridique, et le signataire est tenu de conserver des preuves suffisantes pour la défendre en cas de contestation. Une fausse attestation peut entraîner des poursuites au titre de la loi sur les fausses déclarations (False Claims Act), ce qui aggrave considérablement les conséquences par rapport à un simple manquement à la conformité.
Quel est le lien entre la signature de code et le SSDF ?
Le PS.1 protège toutes les formes de code contre toute altération grâce à la signature des commits, à la signature de code et aux hachages. Le PS.2 exige un mécanisme de vérification de l'intégrité des versions utilisant la signature de code, des hachages publiés et un examen périodique du renouvellement, de la rotation et de la révocation des certificats, ainsi que de la protection des clés. Le PS.3 traite de l'archivage des versions avec leurs données d'intégrité et de provenance.
Quels éléments de preuve les évaluateurs recherchent-ils ?
Ils recherchentles preuves qui étayent l’attestation, et pas seulement le formulaire signé : des clés de signature de code protégées, un mécanisme opérationnel de vérification de l’intégrité des versions, un contrôle d’accès consigné sur l’infrastructure de compilation, ainsi que des SBOM et des informations de provenance signées. La question centrale est de savoir si ces preuves tiendraient la route en cas de contestation de l’attestation.
Le SSDF exige-t-il une certification par un organisme tiers ?
Non. Ce référentiel ne prévoit pas de système officiel de certification par un organisme tiers ; la démonstration de la conformité repose donc sur des preuves et des attestations internes plutôt que sur un certificat d'audit. Il incombe donc à l'organisation de conserver des preuves vérifiables.
Quelle est la première mesure concrète à prendre pour se conformer à la norme SSDF ?
Commencez par vous faire une idée précise de la manière dont le code et les versions sont signés, ainsi que de la façon dont les clés de signature sont protégées. Mettez ensuite en place un pipeline de compilation signé et centralisez les preuves. La mise en place de cette capacité vous permettra de répondre à la fois aux attestations fédérales et aux questionnaires de sécurité commerciaux à partir d'un même système d'enregistrement.
