SSDF et signature de code : comment les fabricants de « Software » prouvent aux acheteurs fédéraux qu’ils respectent les normes de développement sécurisé

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.

What is NIST SP 800-218 (SSDF)?
NIST SP 800-218 is the Secure Software Development Framework, a set of outcome-based practices in four groups: prepare the organization, protect the software, produce well-secured software, and respond to vulnerabilities. It describes what secure development should achieve rather than prescribing a fixed checklist.

Who has to comply with the SSDF?
Any software producer selling to the federal government may need to self-attest to following SSDF practices. Commercial buyers such as banks, healthcare organizations, and large enterprises increasingly reference the SSDF in vendor risk questionnaires, so its reach extends well beyond federal deals.

What is the CISA Secure Software Development Attestation Form?
It is the form software producers sign to declare that they follow SSDF practices.  M-22-18 and M-23-16 required agencies to collect it. OMB rescinded both in January 2026, so use of the form is now an agency decision. Where an agency asks for it, the CEO or a designee who is an employee with authority to bind the company signs, attesting to the best of their knowledge that the practices are in place.

Is the SSDF attestation legally binding?
Yes. It is a formal, legally significant declaration, and the signer is expected to retain evidence sufficient to defend it if challenged. A false attestation can create exposure under the False Claims Act, which raises the stakes above a typical compliance gap.

How does code signing relate to the SSDF?
PS.1 protects all forms of code from tampering through commit signing, code signing, and hashes. PS.2 asks for a release-integrity verification mechanism using code signing, published hashes, and periodic review of certificate renewal, rotation, revocation, and key protection. PS.3 covers archiving releases with their integrity and provenance data.

What evidence do assessors look for?
They look for the proof behind the attestation, not just the signed form: protected code-signing keys, a working release-integrity verification mechanism, logged access control over build infrastructure, and signed SBOMs and provenance. The core question is whether that evidence would hold up if the attestation were challenged.

Does the SSDF require a third-party certification?
No. The framework carries no formal third-party certification scheme, so demonstrating conformance rests on internal evidence and attestation rather than an audit certificate. That places the burden on the organization to retain defensible proof.

What is the first practical step toward SSDF conformance?
Start by gaining visibility into how code and releases are signed and how signing keys are protected. Then formalize a signed build pipeline and centralize the evidence. Building that capability once lets you answer both federal attestations and commercial security questionnaires from the same system of record.