Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- En l'absence d'évaluation par un tiers, le PDG ou un employé désigné et habilité à engager la société signe le formulaire.
- Le signataire atteste, en toute bonne foi, que le producteur applique actuellement de manière systématique les pratiques décrites dans le présent formulaire.
- Conformément à la note de service M-26-05 de l'OMB, chaque organisme fédéral décide désormais s'il souhaite exiger ce formulaire ; il est donc possible qu'un organisme auquel vous vendez des produits continue de l'exiger.
- Les logiciels libres tiers ne relèvent pas directement du champ d'application du formulaire, mais les producteurs affirment néanmoins gérer les risques qui y sont associés.
Si une agence fédérale demande le formulaire d’attestation de développement logiciel sécurisé et que votre entreprise procède à une auto-attestation plutôt que de joindre une évaluation réalisée par un tiers, le signataire doit être votre directeur général (CEO) ou une personne désignée par celui-ci, employée de l’entreprise et habilitée à engager la société. La décision de demander ou non ce formulaire relève désormais de la seule appréciation de l’agence, conformément à la note de service M-26-05 de l’Office of Management and Budget (OMB), datée du 23 janvier 2026.
Il se peut que cette personne n'ait jamais examiné comment les dépendances open source s'intègrent dans vos builds, mais son nom figure néanmoins sous une déclaration expliquant comment votre entreprise gère les risques liés au code que votre équipe n'a pas écrit.
Le formulaire demande à une seule personne d'attester des pratiques mises en œuvre par plusieurs équipes. Cette attestation comporte des conditions, et plusieurs de ses termes laissent au rédacteur le soin de déterminer ce qui y répond. Un signataire qui comprend à la fois ces conditions et ces termes ouverts est bien mieux à même de signer un document exact.
Comment le formulaire d'attestation de développement logiciel sécurisé est devenu facultatif
L'Agence pour la cybersécurité et la sécurité des infrastructures (CISA) a publié ce formulaire le 11 mars 2024. Les éditeurs de logiciels, c'est-à-dire les entreprises qui développent ou compilent des logiciels, l'utilisent pour attester que les produits qu'ils commercialisent ont été développés conformément à des pratiques de développement sécurisées bien définies.
Depuis quelques années, l’OMB a rendu cette attestation obligatoire. La note de service M-22-18, publiée le 14 septembre 2022 et mise à jour par la note de service M-23-16 du 9 juin 2023, autorise une agence à utiliser un logiciel concerné uniquement après que son éditeur a attesté qu’il appliquait des pratiques de développement sécurisées conformes au Cadre de développement logiciel sécurisé (SSDF).
Puis, le 23 janvier 2026, la circulaire M-26-05 a abrogé ces deux notes de service. Les agences peuvent désormais choisir d’utiliser ou non le formulaire de la CISA. Elles peuvent également inclure dans leurs contrats des clauses exigeant qu’un fournisseur fournisse, sur demande, une liste à jour des composants logiciels (SBOM). Le formulaire lui-même n’ayant pas été révisé et citant toujours les deux notes de service abrogées comme référence, certaines de ses instructions ne s’appliquent plus.
Pour un producteur qui ne peut pas attester de toutes les pratiques, le formulaire décrit néanmoins un plan d’action et des étapes clés (POA&M) visant à combler les lacunes, assortis d’une prolongation ou d’une dérogation accordée par l’OMB. La directive M-26-05 ne prévoit aucun substitut à ce processus ; par conséquent, un producteur se trouvant dans cette situation devrait demander à l’organisme demandeur quelle alternative il accepte.
Ce que précise le signataire et ce qui reste en suspens
La section III du formulaire, intitulée « Attestation et signature », demande à une personne de déclarer, au nom du producteur, que le logiciel est développé conformément aux pratiques qui y sont énumérées. Elle présente quatre déclarations numérotées, précédées de deux précisions. Le signataire atteste que, « à ma connaissance », le producteur « utilise actuellement de manière systématique » ces pratiques dans le développement du logiciel mentionné dans la section I. Ces pratiques couvrent l’environnement de compilation, la chaîne d’approvisionnement du code, la provenance (les informations indiquant d’où provient le code et comment il a été compilé), ainsi que la manière dont le producteur identifie et traite les vulnérabilités. Aucune disposition de la section III n’exige du signataire qu’il déclare que le logiciel est exempt de vulnérabilités.
Ces deux précisions restreignent la portée de la déclaration. L’expression « à l’heure actuelle » couvre les pratiques en vigueur au moment de la signature du formulaire, tandis que « à ma connaissance » limite la déclaration à ce que le signataire sait. Ni les instructions ni la section III ne précisent ce qu’un signataire doit faire pour confirmer que ces pratiques sont bien en place, et la personne désignée n’a pas besoin d’occuper un poste particulier. C’est donc le responsable qui décide qui se porte garant de ces pratiques, par exemple les équipes chargées des déploiements, avant que quiconque ne signe. Une signature donnée sur cette base n’est aussi fondée que le sont les connaissances de ces équipes.
Tableau 1. Précisions du formulaire concernant la signature
| Article | Ce qui est indiqué sur le formulaire | Base |
|---|---|---|
| Signataire | Le PDG de l'éditeur de logiciels, ou toute personne désignée par celui-ci parmi les salariés et habilitée à engager la société | Instructions relatives au formulaire |
| Champ d'application | À l'échelle de l'entreprise, pour un produit donné, pour plusieurs produits ou pour des versions spécifiques d'un produit | Formulaire, section I |
| Alternative | Une évaluation réalisée par un tiers est jointe au formulaire ; dans ce cas, le producteur ne signe pas. | Instructions relatives au formulaire et section III |
Un producteur peut joindre une évaluation réalisée par un tiers au lieu de signer. L’évaluateur doit être un organisme d’évaluation tiers (3PAO) certifié dans le cadre du Programme fédéral de gestion des risques et des autorisations (FedRAMP) ou approuvé par écrit par un responsable compétent de l’agence. Il doit également effectuer son évaluation conformément aux directives pertinentes de l’Institut national des normes et des technologies (NIST), qui couvrent tous les éléments du formulaire. Le FedRAMP désigne désormais ces organismes sous le nom d’« évaluateurs indépendants », bien que le formulaire de la CISA utilise toujours l’abréviation 3PAO. Pour utiliser une évaluation, le producteur coche une case dans la section III et la joint au dossier.
Emplacement des composants tiers dans le relevé
La section I énumère quatre catégories non couvertes par le formulaire. L’une d’entre elles concerne ce qu’il appelle les « composants tiers, qu’ils soient open source ou propriétaires », c’est-à-dire ceux intégrés au produit logiciel final utilisé par une agence. Une note figurant dans cette même section précise que les signataires certifient le respect des pratiques de la section III pour le code développé par le producteur. Les instructions indiquent toutefois que les producteurs qui utilisent des composants tiers doivent certifier avoir pris les mesures spécifiques prévues à la section III afin de minimiser les risques liés à leur utilisation. Lues conjointement, l’exclusion et les instructions signifient que le signataire ne se porte pas garant du code tiers en lui-même, mais uniquement des mesures prises par le producteur pour gérer ce risque.
Les déclarations 2 et 3 sont celles où les composants tiers sont mentionnés nommément. La déclaration 2 exige un « effort de bonne foi » pour maintenir des chaînes d’approvisionnement de code source fiables, en utilisant des « outils automatisés ou des processus comparables » afin de garantir la sécurité du code interne et des composants tiers et de gérer les vulnérabilités associées. La déclaration 3 demande au producteur de conserver la traçabilité du code interne et des composants tiers « dans toute la mesure du possible ». À titre de référence, l’annexe du formulaire fait correspondre ces deux points à des tâches du SSDF, notamment celle consistant à vérifier les composants open source.
Ces deux affirmations laissent une marge d'appréciation. Le formulaire ne définit jamais ce qu'il entend par « chaînes d'approvisionnement de code source fiables » ou « processus comparables », et il ne précise pas dans quelle mesure la traçabilité est jugée réalisable. Chaque éditeur doit déterminer ce que ces termes signifient pour son propre logiciel, et le signataire atteste du résultat uniquement au mieux de ses connaissances.
Elles dépendent également de la connaissance du code tiers contenu dans une version, et le formulaire laisse au producteur le soin de choisir la méthode à utiliser. Un producteur incapable de répertorier ce code n'a aucun moyen de savoir s'il répond à l'une ou l'autre de ces exigences.
La section III ne mentionne pas non plus les composants dont la maintenance en amont a pris fin. L’exigence n° 4 demande toujours la mise en place d’une politique ou d’un processus permettant de traiter les vulnérabilités détectées avant la mise en production. Pour un composant dont les responsables de maintenance ont cessé de publier des correctifs, cette politique ne peut pas compter sur une nouvelle version en amont. Il reste alors des options telles que le remplacement du composant ou l’application de correctifs à la version utilisée, soit en interne, soit par l’intermédiaire d’un fournisseur qui effectue des backports.
Ce qui suit la signature
La signature du formulaire entraîne des engagements qui s’étendent au-delà de la date de signature. La section III comprend une attestation selon laquelle le fabricant s’engage à informer tout organisme ayant reçu le formulaire « si et lorsque » il cessera d’appliquer ces pratiques de manière systématique. Une note de bas de page précise qu’une telle attestation s’applique aux futures versions du produit concerné jusqu’à ce que le producteur informe ces organismes que ses pratiques de développement ne sont plus conformes. L’obligation de notification incombe au producteur vis-à-vis des organismes, et le formulaire ne précise pas comment le signataire est informé d’un manquement. Ce sont probablement les équipes chargées de la mise en œuvre de ces pratiques qui constateront en premier lieu un manquement. Le producteur doit donc mettre en place un processus permettant à ces équipes de le signaler au signataire.
La déclaration relative à la loi sur la protection de la vie privée figurant sur le formulaire, rédigée pour le compte du ministère de la Sécurité intérieure, précise deux conséquences. Le fait de ne pas fournir les informations demandées peut amener l'agence à cesser d'utiliser le logiciel. Le fait de fournir sciemment des informations fausses ou trompeuses peut constituer une infraction pénale fédérale, en vertu de l'article 1001 du titre 18 du Code des États-Unis (18 U.S.C. § 1001).
Remarque : chaque organisme utilisant ce formulaire doit fournir sa propre déclaration relative à la loi sur la protection de la vie privée ; par conséquent, la formulation des conséquences présentée au signataire peut varier d'un organisme à l'autre.
Un signataire qui souhaite que l'attestation reste exacte doit, avant de signer, vérifier quelles équipes certifient chaque pratique, comment le producteur a défini des termes tels que « processus comparables » et « réalisable », et comment ces équipes signaleront un manquement.
Savoir ce qui entre dans vos builds
SecureChain de TuxCare analyse le code de chaque paquet open source à la recherche de logiciels malveillants cachés et recompile le paquet à partir du code source au sein d’environnements renforcés et isolés. Tout paquet ne passant pas le contrôle est exclu de votre environnement. Chaque paquet que vous recevez est accompagné d’une SBOM répertoriant son contenu et d’un enregistrement de provenance. Tant que le développeur en amont assure la maintenance d’un paquet, SecureChain l’applique des correctifs dans le cadre d’un accord de niveau de service (SLA) ; le support à cycle de vie illimité (ELS) continue quant à lui de fournir des correctifs une fois la maintenance en amont terminée. SecureChain couvre les dépendances open source en JavaScript, Python, Java, Go et PHP.
Si votre équipe n'est pas en mesure de déterminer ce que contiennent les dépendances open source intégrées à vos builds, ni qui se charge de les mettre à jour une fois que le développement en amont a cessé, SecureChain apporte une réponse à ces deux questions.
FAQ
Qu'est-ce que le formulaire d'attestation de développement logiciel sécurisé de la CISA ?
Il s'agit du formulaire utilisé par les éditeurs de logiciels pour attester que leurs logiciels sont développés conformément aux pratiques issues du Cadre de développement de logiciels sécurisés (SSDF). L'Agence pour la cybersécurité et la sécurité des infrastructures (CISA) l'a publié le 11 mars 2024. Lorsque l'éditeur procède à une auto-attestation, le directeur général (CEO) ou une personne désignée par lui, employée et habilitée à engager la société, la signe. Un éditeur peut également joindre une évaluation réalisée par un tiers.
Le formulaire d'attestation relatif au développement sécurisé de logiciels est-il facultatif ou reste-t-il obligatoire ?
Il ne s'agit plus d'une exigence applicable à l'ensemble de l'administration. La note de service M-26-05 du Bureau de la gestion et du budget (OMB), datée du 23 janvier 2026, a abrogé les notes de service M-22-18 (14 septembre 2022) et M-23-16 (9 juin 2023), qui autorisaient les agences à utiliser les logiciels concernés uniquement après attestation par le fabricant. Chaque agence décide désormais si elle souhaite utiliser ce formulaire ; il est donc possible qu’une agence en particulier vous en demande un.
Quels logiciels ce formulaire couvre-t-il ?
Ces instructions s'appliquent aux logiciels développés après le 14 septembre 2022 (date de la note de service M-22-18 de l'OMB), aux logiciels plus anciens ayant fait l'objet d'un changement de version majeur après cette date, ainsi qu'aux logiciels dont l'éditeur propose des mises à jour continues, tels que les logiciels en tant que service (SaaS). Ces règles provenaient des notes de service M-22-18 et M-23-16, qui ont été abrogées par la note M-26-05 ; par conséquent, un organisme qui demande ce formulaire peut désormais définir lui-même son champ d’application. Il convient de se référer aux instructions et aux clauses contractuelles de l’organisme demandeur. La section I du formulaire énumère également quatre catégories qui ne sont pas couvertes par celui-ci, notamment les composants tiers intégrés au produit.
Comment le formulaire gère-t-il les composants tiers et open source ?
La couverture exclut les composants tiers, qu’ils soient open source ou propriétaires, intégrés au produit. Les instructions précisent également que les fabricants qui utilisent des composants tiers doivent attester avoir pris les mesures énumérées dans la section III du formulaire, consacrée à l’attestation, afin de minimiser les risques liés à leur utilisation. Deux de ces mesures, concernant la sécurité de la chaîne d’approvisionnement et la provenance, mentionnent directement les composants en question.
Que précise le formulaire concernant les informations erronées ou manquantes ?
Sa déclaration relative à la loi sur la protection de la vie privée, rédigée pour le compte du ministère de la Sécurité intérieure, précise que le fait de ne pas fournir les informations demandées peut amener l'agence à cesser d'utiliser le logiciel. Le fait de fournir sciemment des informations fausses ou trompeuses peut constituer une infraction à l'article 18 U.S.C. § 1001, une disposition pénale. Chaque agence utilisant ce formulaire fournit sa propre déclaration relative à la loi sur la protection de la vie privée.
Une évaluation effectuée par un tiers peut-elle remplacer la signature ?
Oui. Un producteur peut joindre une évaluation réalisée par un organisme d’évaluation tiers (3PAO) certifié dans le cadre du Programme fédéral de gestion des risques et des autorisations (FedRAMP) ou approuvé par écrit par un responsable compétent de l’agence. Le 3PAO doit évaluer tous les éléments du formulaire au regard des recommandations pertinentes du NIST. Le producteur coche ensuite la case de la section III, joint l’évaluation et ne signe pas.
Que devient une attestation lorsqu'une nouvelle version du logiciel est disponible ?
Une attestation s'applique aux versions futures du produit concerné jusqu'à ce que le fabricant informe les organismes compétents que ses pratiques de développement ne sont plus conformes. Cela correspond à un engagement figurant dans la section « Signature » elle-même, dans laquelle le fabricant s'engage à informer tout organisme ayant reçu le formulaire s'il cesse d'appliquer ces pratiques de manière cohérente.
