fr.wedoany.com Rapport : L’Agence américaine de cybersécurité et de sécurité des infrastructures (CISA) a publié le guide « Logiciels open source : principes et pratiques de sécurité », destiné à orienter les agences fédérales dans la gestion de la sécurité des logiciels open source, la participation aux projets open source et l’évaluation des systèmes d’intelligence artificielle open source.
Le guide mentionne que le code source des logiciels open source peut être examiné de manière indépendante, ce qui réduit la dépendance aux déclarations des fournisseurs et diminue le risque d’être lié à un fournisseur unique ; l’exemption des frais de licence et le partage des travaux de développement peuvent réduire les coûts, et la publication des logiciels financés par des fonds publics, lorsque cela est approprié, peut également améliorer la transparence.
La CISA recommande aux agences de traiter les logiciels open source comme des actifs logiciels ordinaires, d’évaluer leur sécurité avant leur adoption et de les surveiller tout au long de leur cycle de vie. Il convient de privilégier les projets activement maintenus, de comprendre les conditions des licences et de tenir à jour un inventaire des composants open source utilisés.
Le guide recommande de suivre les dépendances logicielles, de surveiller les vulnérabilités nouvellement divulguées et d’évaluer régulièrement si les projets restent dignes de confiance. La nomenclature logicielle (SBOM) aide à identifier les composants affectés lors de la divulgation d’une vulnérabilité. Les agences doivent appliquer les correctifs de sécurité dès que possible ; lorsqu’aucune mise à jour n’est disponible pour un logiciel personnalisé ou un projet open source, elles doivent se préparer à contribuer en fournissant des correctifs. Si un projet atteint la fin de son support ou si les problèmes de sécurité ne sont toujours pas résolus, il doit être remplacé par une alternative prise en charge. Les outils, y compris ceux d’intelligence artificielle, augmentent le nombre de vulnérabilités détectées et accélèrent le développement de correctifs ; la CISA encourage à automatiser autant que possible la gestion des dépendances, le déploiement des correctifs et les tests de sécurité.
La CISA encourage les agences à contribuer aux améliorations des projets open source qu’elles utilisent, notamment les correctifs de sécurité, les rapports de bogues, la documentation et les discussions techniques, et à partager les modifications avec la communauté afin de réduire les travaux redondants, d’améliorer les logiciels et de rendre publics les résultats financés par le gouvernement. Avant de contribuer, il convient de vérifier que la licence du projet autorise la participation, et d’examiner le code source, les fichiers de documentation et de configuration afin d’éviter toute exposition de secrets tels que des mots de passe, des clés de chiffrement ou des détails sur les systèmes internes.
Pour les agences qui développent leurs propres logiciels, la CISA encourage à envisager la publication en open source dès le départ, sauf si des raisons juridiques, de sécurité ou opérationnelles l’interdisent. L’inventaire des logiciels développés en interne doit indiquer si un projet est destiné à une publication publique, à un partage au sein du gouvernement fédéral ou à un usage interne. Avant la publication, il faut vérifier l’absence d’informations sensibles, suivre des pratiques de développement sécurisées, choisir une licence appropriée et publier simultanément sur le dépôt public la documentation, les directives de contribution, la politique de divulgation des vulnérabilités et la SBOM. Après la publication, il convient de continuer à publier les mises à jour, de résoudre les problèmes de sécurité et de préciser quand le logiciel cesse d’être pris en charge. Si le logiciel est développé sur mesure par un sous-traitant, le gouvernement doit conserver le droit de réutiliser, de modifier et, dans des conditions appropriées, de publier le code en open source.
La CISA souligne que l’évaluation des systèmes d’« intelligence artificielle » open source doit être distinguée des logiciels open source : un modèle d’IA peut être publié sous une licence open source sans pour autant divulguer ses données d’entraînement. Sans accès aux données et au processus d’entraînement, il est difficile pour une organisation de déterminer l’origine du modèle ou d’évaluer si le processus de développement ou les composants ont été manipulés. Avant le déploiement, il convient de s’assurer d’une visibilité suffisante sur la méthode de développement (y compris les données et le processus d’entraînement) ; lorsque ces informations ne sont pas disponibles, le système doit être considéré comme un logiciel propriétaire dont l’origine est incomplète et soumis à une gestion des risques plus stricte.
