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
- Le cadre de développement logiciel sécurisé (SSDF) du NIST (National Institute of Standards and Technology) vous invite à vérifier en permanence la conformité des composants tiers, y compris ceux issus de l'open source, par rapport à vos propres exigences.
- Une analyse de vulnérabilité ne constitue qu'une partie du processus de vérification, et les exemples fournis par le SSDF portent également sur l'état de maintenance et l'intégrité.
- Dans le domaine de l'open source, il n'y a généralement pas de fournisseur tenu de prouver qu'un composant répond à vos exigences ; c'est donc à votre équipe qu'il revient de rassembler ces preuves.
- Ces informations comprennent la provenance, c'est-à-dire un historique de l'origine et des modifications de chaque composant. Une simple liste de composants ne suffit pas à rendre compte de tout cela.
- La vérification se résume à quatre éléments : les exigences, les preuves, les mesures de sécurité avant la mise en place et un plan pour les composants non maintenus. Commencez par les exigences.
Si un client vous demande comment vous vérifiez les bibliothèques open source utilisées dans votre produit, c'est probablement le cadre de développement de logiciels sécurisés (SSDF) du NIST qui a inspiré cette question. L'une de ses tâches, la PW.4.4 du groupe « Produire des logiciels bien sécurisés », demande aux éditeurs de vérifier les composants tiers, y compris ceux open source, par rapport aux exigences qu'ils définissent eux-mêmes.
Un rapport d'analyse complet couvre les vulnérabilités connues, mais les exemples fournis dans la version PW.4.4 indiquent également si un composant fait encore l'objet d'une maintenance et si son intégrité peut être confirmée. La tâche en elle-même ne définit pas ce qu'est une « vérification », ne cite aucun outil ni ne précise quelles preuves doivent être conservées.
Il ne vous reste plus qu’à rédiger le cahier des charges et à fournir la preuve. Et pour les composants open source, il n’y a généralement pas de contrat associé à la bibliothèque ; aucun fournisseur n’est donc tenu de vous fournir cette preuve.
Où en est le SSDF du NIST en 2026 ?
Le NIST publie le SSDF sous le titre « Special Publication (SP) 800-218 ». La version finale actuelle est intitulée « Secure Software Development Framework (SSDF) Version 1.1 : Recommandations pour atténuer le risque lié aux vulnérabilités logicielles », datée de février 2022. Il classe ses pratiques en quatre groupes, chacun identifié par un code à deux lettres : Préparer l'organisation (PO), Protéger le logiciel (PS), Produire un logiciel sécurisé (PW) et Réagir aux vulnérabilités (RV). Chaque pratique possède un identifiant, tel que PW.4, et ses tâches sont désignées par un numéro supplémentaire, tel que PW.4.4.
La version 1.1 s'adresse aux éditeurs et aux acheteurs de logiciels, et précise que les organisations non gouvernementales peuvent l'utiliser à titre volontaire. Elle décrit ses pratiques comme une base pour une planification fondée sur les risques et précise qu'elles ne sont pas destinées à servir de liste de contrôle. Le NIST présente le SSDF comme un vocabulaire commun que les acheteurs peuvent utiliser avec leurs fournisseurs ; ainsi, une exigence vous est généralement communiquée par le biais d'une politique d'achat ou d'un contrat qui y fait référence.
Remarque : le NIST a publié un premier projet public de la norme SP 800-218, révision 1, intitulée « Secure Software Development Framework (SSDF) », version 1.2, le 17 décembre 2025, en réponse au décret présidentiel n° 14306. En octobre 2026, la version 1.1 reste la version définitive. Le projet conserve la section PW.4.4 et la tâche relative à la provenance, PS.3.2, avec la même numérotation et la même formulation, et ajoute deux nouvelles pratiques, accompagnées d'exemples, sous la section PW.4.4. Cet article se réfère à la version 1.1.
Ce que dit la norme PW.4.4 et ce qu’elle laisse en suspens
La norme PW.4.4 demande aux producteurs de vérifier que les composants logiciels acquis (commerciaux, open source ou provenant d’autres tiers) sont conformes aux exigences définies par l’organisation tout au long de leur cycle de vie. Cette formulation vous laisse le soin de définir ces exigences et mentionne explicitement les composants open source. Elle prévoit également que cette vérification se poursuive tant que vous utilisez le composant, bien au-delà d’un simple examen ponctuel lors de son adoption.
Par ailleurs, le NIST propose sept exemples théoriques de mise en œuvre.
| Exemple PW.4.4 | Ce qu'il couvre | Base |
|---|---|---|
| Exemples 1 et 2 : vérifier la présence de vulnérabilités connues du grand public que les éditeurs n'ont pas encore corrigées, y compris la détection automatique dans la chaîne d'outils | Failles connues du composant | SP 800-218 version 1.1, théorique |
| Exemple 3 : utiliser les résultats existants fournis par des services de vérification commerciaux | Résultats de l'évaluation externe | SP 800-218 version 1.1, théorique |
| Exemple 4 : vérifier que le composant fait toujours l'objet d'une maintenance active et qu'il n'a pas atteint sa fin de vie (EOL), et notamment que les vulnérabilités récemment découvertes font l'objet de correctifs | État du support et correction des nouvelles failles | SP 800-218 version 1.1, théorique |
| Exemple 5 : élaborer un plan d'action pour les composants qui ne sont plus pris en charge ou qui ne seront bientôt plus disponibles | Votre réaction à la fin de l'assistance | SP 800-218 version 1.1, théorique |
| Exemple 6 : vérifier l'intégrité à l'aide de signatures numériques ou d'autres mécanismes | Intégrité de l'objet | SP 800-218 version 1.1, théorique |
| Exemple 7 : examiner, analyser ou tester le code | Le code lui-même | SP 800-218 version 1.1, théorique |
La recherche des vulnérabilités connues couvre deux de ces sept exemples ; un rapport d'analyse suffit donc à lui seul à répondre en partie à cette tâche. Une analyse visant à détecter les failles connues ne permet généralement pas de savoir si un artefact est intact ou si ce composant fait encore l'objet d'une maintenance, et ce sont précisément ces questions qui sont abordées dans les exemples 4 et 6.
La version préliminaire 1.2 du SSDF ajoute un huitième exemple à la section PW.4.4 : vérifier régulièrement si les bibliothèques tierces ont fait l'objet de changements de propriété et évaluer l'impact de chaque changement. Un scan des vulnérabilités connues ne signale généralement pas un changement de propriété ; cet exemple nécessiterait donc un contrôle spécifique.
Pour un composant qui n'est plus pris en charge, le plan d'action présenté dans l'exemple 5 prend généralement l'une des trois formes suivantes : le remplacer, appliquer un correctif à la version que vous utilisez, ou accepter le risque par écrit. La deuxième option implique que quelqu'un doive rédiger et tester le correctif, et ce « quelqu'un », c'est vous, à moins que vous n'ayez chargé quelqu'un d'autre de s'en charger.
Avec l'open source, il n'y a souvent aucun fournisseur à qui demander des preuves
Le point PO.1.3, qui traite des obligations du SSDF vis-à-vis des fournisseurs, porte sur la communication des exigences aux tiers fournissant des composants commerciaux. Parmi les exemples cités figurent l’ajout d’exigences dans les contrats, l’obligation pour les fournisseurs d’attester que leurs logiciels répondent à ces exigences, ainsi que l’exigence de données de provenance et de mécanismes de vérification de l’intégrité pour tous les composants de leurs logiciels.
Le code open source que vous distribuez relève de la clause PW.4.4 mais pas de la clause PO.1.3 ; le SSDF vous demande donc de le vérifier sans qu’une tâche soit prévue pour définir les conditions avec ses auteurs. Dans la pratique, une bibliothèque est généralement fournie sans contrat ; il n’y a donc généralement pas de contrepartie tenue de vous fournir des preuves de provenance ou d’intégrité. C’est à quelqu’un de votre côté de les produire ou de les collecter.
Vos exigences passent avant tout, et la section PO.1.1 constitue le point de départ utilisé par le SSDF pour les rédiger. Son deuxième exemple consiste à définir des politiques visant à sécuriser vos processus de développement, y compris ceux relatifs aux composants open source et autres composants tiers. Rédigez-les avant d’évaluer tout outil. La section PW.4.4 évalue les composants au regard de vos exigences, et les vérifications par défaut d’un outil ont tendance à se substituer à celles-ci si vous sautez cette étape.
Un bref cahier des charges peut préciser quelles activités de maintenance sont acceptables, ce qui se passe lorsqu'un composant ne bénéficie plus d'un support en amont, qui approuve une dérogation et comment l'intégrité est vérifiée. Le cinquième exemple du PO.1.3 décrit un processus de gestion des exigences auxquelles un composant ne répond pas, y compris la révision périodique des dérogations approuvées. Vous pouvez appliquer ce même processus aux composants open source.
D'après le SSDF : PW.4.1, la mission du SSDF en matière d'acquisition de composants comprend deux exemples décrivant les mesures que votre équipe peut prendre sans faire appel à un fournisseur. La première consiste à obtenir des informations de provenance, telles qu'une nomenclature logicielle (SBOM) ou une analyse de composition, pour chaque composant. La seconde consiste à héberger des composants open source approuvés et vérifiés dans un ou plusieurs référentiels.
En l'absence d'intermédiaire, il n'y a généralement rien entre la version publiée par le responsable de maintenance et votre compilation, à moins que vous n'ajoutiez une mesure de sécurité. Parmi les options possibles, on peut citer la vérification des signatures lorsque les éditeurs les fournissent, la recompilation à partir du code source ou le filtrage des éléments reçus avant qu'ils n'atteignent votre environnement de compilation. Les exemples théoriques du SSDF en mentionnent certains, notamment les signatures dans le paragraphe PW.4.4 et la compilation à partir du code source dans le paragraphe PW.4.1.
La provenance au sens de la section PS.3.2 ne se limite pas à une simple liste de composants
La norme PS.3.2 relève du groupe « Protect the Software » de la SSDF. Elle demande aux éditeurs de collecter, de sécuriser, de conserver et de partager les données de provenance pour tous les composants de chaque version, et cite la SBOM comme un exemple de support pouvant héberger ces données. Pour les composants open source, il n’y a généralement aucun fournisseur tenu de vous les transmettre.
Le NIST définit la provenance, en s'inspirant de la publication spéciale 800-53, comme la chronologie de l'origine, du développement, de la propriété, de l'emplacement et des modifications d'un composant. Selon cette définition, une liste de noms et de versions indique ce que contient une version, tandis que la chronologie précise d'où provient chaque élément et ce qu'il est devenu. Une liste de composants ne fournit pas automatiquement cette seconde information ; vérifiez donc si votre SBOM consigne cet historique ou si elle se limite à la liste.
Les exemples cités au paragraphe PS.3.2 incluent le partage des données avec les acquéreurs et vos propres équipes d’intervention, la protection de leur intégrité afin que les destinataires puissent les vérifier, et leur mise à jour chaque fois qu’un composant est mis à jour. Le paragraphe PS.3.2 mentionne « tous les composants » et n’utilise pas le terme « transitif ». L’appliquer à des dépendances que vous n’avez jamais choisies directement relève d’une déduction, mais celle-ci découle du mot « tous ». Déterminez si les dépendances transitives entrent dans le champ d’application en fonction de vos exigences, et consignez cette décision.
Deux autres termes apparaissent aux côtés des SBOM. Le SLSA (Supply-chain Levels for Software Artifacts) est une spécification distincte relative à la sécurité de la chaîne d’approvisionnement, et son « Build Level 3 » décrit une plateforme de compilation renforcée qui protège contre toute altération pendant la compilation. Les documents VEX (Vulnerability Exploitability eXchange), tels que décrits par la Cybersecurity and Infrastructure Security Agency (CISA), indiquent le statut d’un produit par rapport à une vulnérabilité donnée : affecté, non affecté ou corrigé. Ces deux éléments vous fournissent des preuves pour les tâches SSDF. La provenance SLSA consigne qui a compilé un paquet, avec quel processus et à partir de quelles données d’entrée, ce qui fait partie de l’historique que la section PS.3.2 vous demande de conserver. Un enregistrement VEX indique si une vulnérabilité connue affecte un composant, ce qui correspond à la demande du premier exemple de la section PW.4.4.
Questions posées dans le formulaire fédéral d'attestation concernant les composants
Auparavant, les acheteurs fédéraux se renseignaient directement sur les composants tiers. Conformément aux notes de service M-22-18 et M-23-16 du Bureau de la gestion et du budget (OMB), les agences devaient obtenir des attestations de la part des éditeurs de logiciels ; à cette fin, la CISA et l’OMB ont publié, le 11 mars 2024, le formulaire d’attestation relatif au développement sécurisé de logiciels.
La section III du formulaire demande aux producteurs d’attester qu’ils déploient des efforts de bonne foi pour maintenir des chaînes d’approvisionnement fiables en code source, en utilisant des outils automatisés ou des processus comparables qui garantissent la sécurité des composants tiers et gèrent les vulnérabilités associées. Elle leur demande également d’attester qu’ils conservent la traçabilité des composants tiers « dans toute la mesure du possible ». L’annexe du formulaire établit un lien entre ces éléments et les tâches du SSDF, notamment les points PW.4.4 et PS.3.2.
Le formulaire ne couvre pas les composants tiers, qu'ils soient open source ou propriétaires, intégrés au produit utilisé par une agence. Toutefois, les producteurs qui utilisent ces composants certifient tout de même avoir pris les mesures prévues à la section III afin de réduire le risque lié à leur utilisation.
Le 23 janvier 2026, la note de service M-26-05 de l’OMB a abrogé les notes M-22-18 et M-23-16. Les agences peuvent toujours utiliser ce formulaire et exiger des SBOM dans le cadre de leurs contrats ; la note mentionne la norme SP 800-218 comme référence qu'elles peuvent utiliser. Elle précise qu'il n'existe « aucune méthode universelle et unique » pour sécuriser les logiciels et le matériel utilisés par les agences, laissant à chacune d'elles le soin de définir des politiques d'assurance adaptées à son profil de risque.
| Document | Ce qu'il dit | Situation actuelle | Base |
|---|---|---|---|
| SP 800-218 version 1.1 | Définit les normes PW.4.4 et PS.3.2 | Fin, février 2022 | Recommandations du NIST |
| SP 800-218, révision 1, projet (SSDF 1.2) | Conserve les deux tâches et ajoute du nouveau contenu | Projet initial destiné au public | Projet de lignes directrices du NIST |
| OMB M-22-18 et M-23-16 | A exigé des organismes concernés qu'ils obtiennent des attestations | Abrogé le 23 janvier 2026 | Politique de l'OMB |
| Formulaire d'attestation | Les producteurs attestent du respect des pratiques issues du SSDF | Facultatif pour les agences | Formulaire de l'agence (CISA et OMB) |
| OMB M-26-05 | Les agences définissent leurs propres politiques en matière d'assurance qualité | Actuel | Politique de l'OMB |
Les circulaires M-22-18 et M-23-16 ayant été abrogées, la question de savoir si un acheteur vous demande comment vous vérifiez les composants ou en suivez la provenance dépend de la politique et du contrat de cet acheteur.
Déterminer ce que signifie la « vérification » pour vos dépendances
Dans la pratique, la vérification se résume à quatre décisions : quelles exigences un composant doit respecter, quelles preuves conserver, ce qui se passe entre une version en amont et votre build, et comment réagir lorsqu’un responsable en amont cesse de prendre en charge ce composant. Les deux premières relèvent de la définition de politiques, une tâche que seule votre équipe peut accomplir. Quant aux deux dernières, c’est là que les outils peuvent prendre le relais pour les tâches répétitives.
SecureChain de TuxCare s'intercale entre les versions en amont et votre processus de compilation. Il analyse le code source des paquets open source à la recherche de logiciels malveillants et de schémas suspects, recompile les paquets à partir de ce code source dans des environnements renforcés et isolés, et continue à leur appliquer des correctifs dans le cadre d'un accord de niveau de service tant que la maintenance en amont est active. Le support à cycle de vie illimité (ELS) continue à fournir des correctifs une fois la maintenance en amont terminée, couvrant ainsi l'option « appliquer le correctif à la version que vous utilisez » décrite précédemment. La couverture s’étend à JavaScript, Python, Java, Go, Rust et PHP. TuxCare fournit également des SBOM, des enregistrements VEX et une provenance SLSA de niveau 3 pour chaque paquet.
Si vous vous demandez comment gérer les paquets open source qui n'ont pas été vérifiés ou qui ne sont plus maintenus, n'hésitez pas à nous demander ce que couvre SecureChain.
FAQ
Qu'est-ce que le SSDF du NIST ?
Le SSDF du NIST (Secure Software Development Framework) est le cadre de développement logiciel sécurisé que le NIST, l'agence américaine de normalisation, publie sous le numéro de publication spéciale (SP) 800-218. Il regroupe les pratiques de développement sécurisé en quatre catégories : « Préparer l'organisation », « Protéger le logiciel », « Produire un logiciel bien sécurisé » et « Réagir aux vulnérabilités ». La version finale actuelle est la 1.1, datée de février 2022.
À qui s'adresse le guide SSDF du NIST ?
Les éditeurs de logiciels, tels que les fournisseurs commerciaux et les équipes de développement internes, ainsi que les acquéreurs de logiciels, notamment les agences fédérales et d’autres organisations, constituent les deux principaux publics cibles. Le NIST, l’agence américaine de normalisation, précise que les organisations non gouvernementales peuvent utiliser le cadre de développement logiciel sécurisé (SSDF) à titre volontaire. Une entreprise qui s’appuie sur des composants open source est considérée comme un éditeur.
Le SSDF couvre-t-il les logiciels libres ?
En partie. Dans le cadre de développement logiciel sécurisé (SSDF), la tâche relative à la vérification des composants tiers (PW.4.4) et celle relative à leur acquisition (PW.4.1) mentionnent toutes deux les composants open source. La tâche relative à la communication des exigences aux fournisseurs (PO.1.3) ne mentionne quant à elle que les composants commerciaux. Le NIST (l’agence américaine de normalisation) mentionne une référence SSDF pour les logiciels open source parmi les mesures qu’il envisage, mais en octobre 2026, il n’en avait toujours pas publié.
Qu'est-ce qu'un exemple de mise en œuvre théorique dans le SSDF ?
Dans le cadre de développement logiciel sécurisé (SSDF), les exemples d'implémentation théoriques sont des exemples d'outils, de processus ou de méthodes susceptibles de faciliter la réalisation d'une tâche. L'agence américaine de normalisation NIST précise qu'aucun exemple ni aucune combinaison n'est obligatoire, et qu'il ne s'agit pas là des seules options possibles.
Le NIST certifie-t-il des produits dans le cadre du SSDF ?
Le NIST, l'agence américaine de normalisation, publie le « Secure Software Development Framework » (SSDF) à titre de guide, et ses documents relatifs au SSDF ne décrivent aucun programme de certification. Le formulaire d'attestation fédéral accepte soit l'auto-attestation du producteur, soit une évaluation par un tiers, et le Bureau de la gestion et du budget (OMB) n'impose plus l'utilisation de ce formulaire à l'ensemble de l'administration fédérale.
