Actualité & analyse

4 volets, 1 doctrine open source signée CISA — les 6 exigences que j’aurais aimé lire avant notre dernier audit de dépendances

Panos Petropoulos

Architecte logiciel & responsable chaîne de build · 5 août 2026 · 11 min

Il y a des publications qu’on lit par curiosité et d’autres qu’on lit parce qu’on sait qu’elles finiront dans un appel d’offres. Le guide que la CISA a mis en ligne lundi appartient à la seconde catégorie, et je pèse mes mots : les documents de cette agence ont une remarquable capacité à devenir des exigences contractuelles européennes en l’espace de deux ou trois trimestres, sans jamais avoir eu la moindre force réglementaire de ce côté-ci de l’Atlantique.

Le titre officiel est « Open Source Software: Security Principles and Practices », publié le 3 août 2026. Il s’adresse aux agences fédérales américaines. Il vous concerne quand même, et je vais expliquer pourquoi — puis détailler les six exigences qui, à mon avis, poseront le plus de difficultés aux équipes françaises.

Ce que contient le document

Le guide s’organise en quatre volets, et cette structure est en soi une information : elle montre que la CISA ne traite plus l’open source comme un simple risque d’approvisionnement, mais comme un cycle complet.

• Utiliser des logiciels open source — évaluation, sélection, suivi.
• Contribuer aux projets dont on dépend.
• Développer et publier ses propres logiciels open source.
• Évaluer les systèmes d’intelligence artificielle dits open source.

Les recommandations centrales tiennent en quelques lignes : traiter un composant open source comme n’importe quel autre actif logiciel et l’évaluer en conséquence ; choisir des projets activement maintenus et comprendre leur licence ; tenir un inventaire des composants sous forme de nomenclature logicielle ; suivre les dépendances et surveiller les vulnérabilités ; automatiser la gestion des dépendances, le déploiement des correctifs et les tests de sécurité ; contribuer en retour à la communauté ; et relire le code avant publication pour éviter d’exposer des données sensibles.

Rien de révolutionnaire pris isolément. C’est précisément ce qui rend le document dangereux pour les équipes qui n’ont rien formalisé : chaque point est individuellement raisonnable, donc difficile à contester dans un questionnaire fournisseur.

Notre avis d’expert n°1 : le volet IA est le seul vraiment nouveau

Les trois premiers volets reformulent des bonnes pratiques connues. Le quatrième introduit une distinction que la plupart des équipes n’ont pas encore intégrée, et le document la formule sans détour : « AI models can be released under an open source license without making their training data publicly available. »

Traduit en conséquences opérationnelles : la licence ne qualifie pas la transparence. Un modèle peut être « open source » au sens juridique — poids téléchargeables, licence permissive — tout en restant une boîte noire sur ce qui compte pour l’évaluation du risque : la provenance des données, les filtres appliqués, la présence éventuelle de données personnelles ou de contenus sous droits.

La recommandation de la CISA est d’exiger de la visibilité sur les données et les processus d’entraînement. C’est une demande considérable, que très peu de modèles actuellement diffusés satisfont réellement. Pour une équipe qui intègre un modèle ouvert dans un produit livré à un client public, la question va se poser rapidement — et la réponse « il est open source » ne suffira plus.

Notre avis d’expert n°2 : « activement maintenu » est le critère le plus difficile

Choisir des projets activement maintenus paraît évident jusqu’au moment où il faut l’écrire dans une procédure. Quel seuil ? Un commit par mois ? Trois mainteneurs ? Une réponse aux signalements de sécurité en moins de trente jours ?

Nous avons tranché ainsi sur nos projets, après plusieurs itérations : un composant est considéré comme à risque si aucune version n’est sortie depuis 18 mois, ou si un seul contributeur détient les droits de publication, ou si aucune politique de sécurité n’est publiée. Trois critères mécaniques, vérifiables automatiquement, qui ne remplacent pas le jugement mais qui permettent de trier une liste de six cents dépendances en quelques minutes.

Le résultat de ce tri est toujours désagréable. Sur une application métier typique, entre 4 et 9 % des dépendances directes tombent dans au moins une de ces catégories — et il s’agit rarement de bibliothèques obscures. Ce sont souvent des utilitaires très répandus, maintenus bénévolement par une personne, et présents dans l’arbre de dépendances de la moitié de l’écosystème.

Notre avis d’expert n°3 : contribuer en retour n’est plus seulement une posture

Le volet « contribuer » est celui que les équipes françaises lisent le plus vite, en général avec un léger sourire. C’est une erreur d’appréciation.

La logique de la CISA n’est pas philanthropique, elle est gestionnaire : si vous dépendez d’un composant maintenu par une seule personne, votre risque d’approvisionnement est directement corrélé à la santé de ce mainteneur. Contribuer — du code, de la documentation, du temps de revue, ou de l’argent — est une mesure de réduction de risque au même titre qu’un correctif.

C’est aussi, accessoirement, l’argument qui permet de faire financer ce temps en interne. « Nous contribuons parce que c’est bien » ne passe jamais un arbitrage budgétaire ; « nous contribuons parce que trois de nos dépendances critiques ont un seul mainteneur » passe systématiquement.

Les 6 exigences qui poseront problème aux équipes françaises

1. L’inventaire exhaustif des composants. Pas une liste tenue à la main dans un tableur, mais une nomenclature générée à chaque build. C’est le prérequis de tout le reste, et la majorité des équipes que nous auditons ne l’ont pas.

2. Le critère de maintenance active, écrit. Il ne suffit pas de « faire attention ». Il faut un seuil défendable devant un client.

3. La compréhension effective des licences. Pas seulement leur recensement : savoir ce que chacune impose lors d’une redistribution. C’est un travail juridique que peu d’équipes techniques mènent correctement seules.

4. L’automatisation des correctifs. Détecter ne suffit pas ; le guide insiste sur le déploiement automatisé. Beaucoup d’équipes ont l’alerte et pas le pipeline.

5. La revue avant publication. Si vous publiez du code, une relecture visant explicitement l’exposition de secrets et de données sensibles doit être formalisée. Nous avons vu plus d’un dépôt public contenir des identifiants dans son historique.

6. L’évaluation spécifique des modèles d’IA. La plus difficile, et celle pour laquelle l’outillage n’existe pas encore vraiment. Les précautions d’intégration décrites par Plug-Tech pour les agents en production couvrent une partie du sujet côté exécution, mais la question de la provenance des données d’entraînement reste largement ouverte.

Sur le volet vulnérabilités et correctifs, la lecture que WebGuard Agency fait des angles morts de la veille par flux publics complète utilement ce guide : la CISA recommande de surveiller les vulnérabilités, mais surveiller les avis publics ne suffit pas toujours à être informé à temps.

Par où commencer concrètement

Par l’inventaire, sans hésitation. Tant que vous ne savez pas quels composants entrent dans vos livrables et dans quelles versions, aucune autre recommandation n’est applicable — vous ne pouvez ni évaluer la maintenance, ni vérifier les licences, ni répondre à une question sur une vulnérabilité.

C’est aussi l’étape la moins coûteuse : sur une base de code moyenne, l’outillage se met en place en deux à quatre jours et s’intègre à la chaîne de build existante. Nous avons détaillé la marche à suivre côté écosystème Python dans notre guide sur l’audit de dépendances et la génération de nomenclature logicielle.

Une dernière observation. Ce guide, comme les textes européens qui vont dans le même sens, augmente mécaniquement le niveau de compétence attendu des équipes de développement : lire une licence, évaluer la santé d’un projet, instrumenter une chaîne de build. Ce sont des compétences d’ingénierie logicielle au sens large, pas des spécialités exotiques — mais elles restent rares sur le marché français, et c’est un point à anticiper dans vos recrutements bien avant que le questionnaire fournisseur n’arrive.

Questions fréquentes

Le guide de la CISA s’applique-t-il aux entreprises françaises ?

Juridiquement non : il s’adresse aux agences fédérales américaines et n’a aucune valeur contraignante en France. En pratique, les publications de la CISA se retrouvent très vite reprises dans les questionnaires de sécurité fournisseurs, y compris européens, parce qu’elles offrent un référentiel gratuit, lisible et internationalement reconnu. C’est le mécanisme par lequel un document non contraignant devient une exigence contractuelle en quelques trimestres.

Quels sont les quatre volets du document ?

L’utilisation de logiciels open source, la contribution aux projets, le développement et la publication de logiciels open source, et l’évaluation des systèmes d’IA dits open source. Ce quatrième volet est le plus notable : il traite explicitement du fait qu’un modèle peut être diffusé sous licence open source sans que ses données d’entraînement soient rendues publiques.

Que dit la CISA sur les modèles d’IA « open source » ?

Qu’il faut les évaluer différemment des logiciels classiques, en exigeant de la visibilité sur les données et les processus d’entraînement. La licence ne suffit pas à qualifier le niveau réel de transparence, et l’auditabilité d’un modèle ne se déduit pas de son étiquette.

Par où commencer si l’on n’a rien formalisé ?

Par l’inventaire. Tant que vous ne savez pas quels composants open source entrent dans vos livrables et dans quelles versions, aucune des autres recommandations n’est applicable. Une nomenclature générée automatiquement à chaque build est le prérequis de tout le reste, et c’est le point de départ le moins coûteux : deux à quatre jours d’outillage sur une base de code moyenne.