La question de savoir si les logiciels open source (OSS) sont appropriés dans les systèmes de défense a été largement résolue dans les années 2000 et 2010 : la réponse est oui, avec une gestion appropriée. La note de politique du Département américain de la Défense de 2009 sur les logiciels open source était l'une des premières déclarations formelles que les OSS doivent être évalués selon les mêmes critères que les logiciels propriétaires. Cette position permissive mais gérée est désormais effectivement universelle parmi les cadres d'acquisition de défense dans les nations démocratiques.
Le défi actuel n'est pas de savoir si utiliser les OSS, mais comment les gérer rigoureusement. L'incident de backdoor XZ Utils de 2024, dans lequel un acteur malveillant a passé deux ans à construire sa crédibilité dans un projet open source avant d'y insérer un backdoor sophistiqué, a démontré que les risques pour la chaîne d'approvisionnement OSS ne sont pas théoriques.
La position actuelle permissive-mais-gérée envers l'OSS
La position actuelle du DoD américain sur l'OSS est consignée dans plusieurs documents de politique. Le fil conducteur constant : l'OSS n'est ni intrinsèquement plus ni moins sûr que le logiciel propriétaire — la sécurité dépend du composant spécifique, des pratiques de développement de sa communauté et de la gouvernance appliquée par l'organisation consommatrice. Les programmes DoD sont généralement autorisés à utiliser l'OSS sous réserve de revue de licence, d'évaluation des vulnérabilités et d'un monitoring continu. Les organisations de défense alliées adoptent généralement la même approche.
Risques de la chaîne d'approvisionnement : typosquatting, mises à jour malveillantes et bibliothèques abandonnées
Typosquatting. Les attaquants enregistrent des noms de paquets proches de paquets légitimes populaires. Un développeur qui commet une faute de frappe dans un nom de paquet installe un code malveillant au lieu de la bibliothèque visée. L'atténuation requiert la vérification du nom du paquet au moment de l'installation et des fichiers de verrouillage épinglant les noms et versions exacts des paquets.
Mises à jour malveillantes. Un paquet légitime et largement utilisé peut devenir un vecteur de logiciels malveillants si ses mainteneurs sont compromis ou remplacés par des acteurs hostiles. L'incident XZ Utils est l'exemple le plus sophistiqué. L'atténuation requiert l'épinglage de versions spécifiques plutôt que l'acceptation automatique des dernières mises à jour et la surveillance des changements de comportement anomaux entre versions.
Bibliothèques abandonnées. Les projets open source sont fréquemment maintenus par des bénévoles individuels ou de petits groupes. Lorsque les mainteneurs cessent le développement actif, le projet peut continuer à être utilisé par des logiciels en aval tout en accumulant des vulnérabilités non corrigées. L'atténuation requiert le suivi du statut de maintenance des dépendances et une politique de remplacement ou de fork des composants non maintenus.
Conformité des licences. Les licences open source imposent des obligations aux consommateurs. Les licences copyleft (GPL, AGPL) peuvent exiger la divulgation du code source dérivé — créant des risques juridiques pour les programmes de défense ne pouvant pas divulguer le code source en raison de la classification.
Processus d'approbation OSS : revue de licence, scanning de vulnérabilités et provenance
La revue de licence détermine si la licence du composant est compatible avec l'utilisation prévue du programme. Les programmes qui utilisent des composants avec des licences incompatibles découvrent le problème lors de la livraison contractuelle ou de la revue juridique.
Le scanning de vulnérabilités évalue la version spécifique du composant envisagé pour inclusion par rapport aux bases de données de vulnérabilités connues. L'évaluation doit couvrir non seulement le composant lui-même mais ses dépendances transitives. Le scanning de vulnérabilités au moment de l'inclusion est nécessaire mais insuffisant ; il doit être répété en continu.
L'évaluation de provenance évalue la fiabilité du développement et de la distribution du composant : l'identité et les antécédents des mainteneurs ; si le projet a un processus de divulgation de sécurité ; si les versions sont signées ; si les pratiques de développement offrent une assurance raisonnable de qualité intentionnelle.
Distinction critique : Le scanning de vulnérabilités identifie les vulnérabilités connues. Il ne protège pas contre les vulnérabilités inconnues ni les backdoors intentionnels. L'évaluation de provenance et la posture de sécurité plus large de la chaîne d'approvisionnement du projet adressent l'espace de risque que le scanning de vulnérabilités ne peut atteindre.
SBOM comme outil de gestion des dépendances OSS
Un Software Bill of Materials (SBOM) est un inventaire formel, lisible par machine, de tous les composants logiciels d'un système — incluant les bibliothèques open source, les composants commerciaux sur étagère et les modules développés en interne — avec leurs versions, licences et relations de dépendance. Le SBOM est de plus en plus exigé pour les logiciels de défense.
Pour la gestion OSS, le SBOM offre deux capacités difficiles à atteindre autrement à l'échelle. Premièrement, il permet une corrélation automatisée des vulnérabilités : quand une nouvelle vulnérabilité est divulguée, elle peut être automatiquement corrélée au SBOM pour identifier tous les programmes incorporant la version affectée. Deuxièmement, le SBOM permet le monitoring de la conformité des licences sur l'ensemble de l'arbre des dépendances, y compris les dépendances transitives. Les programmes SBOM efficaces intègrent la génération SBOM dans le pipeline CI/CD afin que le SBOM soit toujours à jour avec le code réellement déployé.