Plusieurs réglementations internationales et en particulier l’Ofac aux Etats-Unis imposent aux développeurs open source de ne pas travailler avec des pays touchés par des sanctions. La Fondation Linux a publié un guide pour détailler ces différents cadres et les risques.
En octobre dernier, Greg Kroah-Hartman, responsable de la maintenance du noyau Linux stable et Linus Torvalds, fondateur de Linux ont annoncé que onze développeurs russes avaient été démis de leurs fonctions. La conséquence selon Linus Torvalds des « sanctions contre les russes ». Il fait référence aux sanctions prévues par l’Ofac (office assets control) et d’autres réglementations mondiales similaires. L’affaire est prise au sérieux par la Fondation Linux qui vient de publier un guide à l’attention des développeurs pour les aider à comprendre l’ensemble de ces cadres.
Dans un blog, l’organisme indique que les risques accrus en matière de cybersécurité et de conformité réglementaire imposent aux communautés open source des obligations dont elles doivent tenir compte. Le guide se nomme « Navigating Global Regulations and Open Source : US OFAC Sanctions ». Le focus sur la réglementation américaine est justifié par l’affaire du mois d’octobre sur le noyau Linux. « Les questions relatives aux programmes de sanctions de l’Ofac ne sont pas courantes, mais il est important d’en être conscient », explique la Fondation.
Une liste non exhaustive de pays, des régions et d’organisations
La violation des sanctions décidées par l’administration américaine peut avoir de graves conséquences, notamment d’importantes amendes et des sanctions pénales. Ces peines ne s’appliquent pas seulement aux transactions financières, mais souvent à presque toutes les interactions avec une cible de sanctions, y compris dans les espaces de la communauté open source. De nombreux autres pays ont également mis en place des programmes de sanctions similaires, notamment l’Union européenne, le Royaume-Uni, le Japon, l’Australie, la Suisse, la Chine et bien d’autres encore. Parmi les pays sanctionnés par l’Ofac figurent des pays qui font l’objet de sanctions globales comme la Russie, l’Iran, Cuba et la Corée du Nord, plus d’autres pays comme l’Irak, le Liban, le Venezuela et le Nicaragua.
Les américains publient une liste de ressortissants spécifiques (SDN) avec un moteur de recherche. Grâce à lui, un utilisateur peut vérifier si une entreprise ou une administration figurent sur la liste. Certaines sanctions s’appliquent à des pays entiers (par exemple, l’Iran), à des régions (par exemple, la Crimée en Ukraine) ou à des gouvernements (par exemple, le gouvernement du Venezuela). « La liste SDN de l’Ofac et l’outil de recherche ne sont pas non plus exhaustifs et toute analyse ne peut se fonder uniquement sur cette liste », précise la Fondation. Celle-ci ajoute « nous ne pouvons que regretter que la communauté open source ne puisse pas fonctionner indépendamment des programmes de sanctions internationales, mais elles sont la loi de chaque pays et ne sont pas optionnelles ».
Plusieurs réglementations internationales et en particulier l’Ofac aux Etats-Unis imposent aux développeurs open source de ne pas travailler avec des pays touchés par des sanctions. La Fondation Linux a publié un guide pour détailler ces différents cadres et les risques.
En octobre dernier, Greg Kroah-Hartman, responsable de la maintenance du noyau Linux stable et Linus Torvalds, fondateur de Linux ont annoncé que onze développeurs russes avaient été démis de leurs fonctions. La conséquence selon Linus Torvalds des « sanctions contre les russes ». Il fait référence aux sanctions prévues par l’Ofac (office assets control) et d’autres réglementations mondiales similaires. L’affaire est prise au sérieux par la Fondation Linux qui vient de publier un guide à l’attention des développeurs pour les aider à comprendre l’ensemble de ces cadres.
Dans un blog, l’organisme indique que les risques accrus en matière de cybersécurité et de conformité réglementaire imposent aux communautés open source des obligations dont elles doivent tenir compte. Le guide se nomme « Navigating Global Regulations and Open Source : US OFAC Sanctions ». Le focus sur la réglementation américaine est justifié par l’affaire du mois d’octobre sur le noyau Linux. « Les questions relatives aux programmes de sanctions de l’Ofac ne sont pas courantes, mais il est important d’en être conscient », explique la Fondation.
Une liste non exhaustive de pays, des régions et d’organisations
La violation des sanctions décidées par l’administration américaine peut avoir de graves conséquences, notamment d’importantes amendes et des sanctions pénales. Ces peines ne s’appliquent pas seulement aux transactions financières, mais souvent à presque toutes les interactions avec une cible de sanctions, y compris dans les espaces de la communauté open source. De nombreux autres pays ont également mis en place des programmes de sanctions similaires, notamment l’Union européenne, le Royaume-Uni, le Japon, l’Australie, la Suisse, la Chine et bien d’autres encore. Parmi les pays sanctionnés par l’Ofac figurent des pays qui font l’objet de sanctions globales comme la Russie, l’Iran, Cuba et la Corée du Nord, plus d’autres pays comme l’Irak, le Liban, le Venezuela et le Nicaragua.
Les américains publient une liste de ressortissants spécifiques (SDN) avec un moteur de recherche. Grâce à lui, un utilisateur peut vérifier si une entreprise ou une administration figurent sur la liste. Certaines sanctions s’appliquent à des pays entiers (par exemple, l’Iran), à des régions (par exemple, la Crimée en Ukraine) ou à des gouvernements (par exemple, le gouvernement du Venezuela). « La liste SDN de l’Ofac et l’outil de recherche ne sont pas non plus exhaustifs et toute analyse ne peut se fonder uniquement sur cette liste », précise la Fondation. Celle-ci ajoute « nous ne pouvons que regretter que la communauté open source ne puisse pas fonctionner indépendamment des programmes de sanctions internationales, mais elles sont la loi de chaque pays et ne sont pas optionnelles ».
Une proposition prévoit d’incorporer des documents SBOM (un inventaire des composants) dans les paquets Python afin d’améliorer le suivi des dépendances et l’analyse des vulnérabilités.
Au début janvier, une proposition pour améliorer Python (Python Enhancement Proposal) a été soumise à commentaires. Elle prévoit d’intégrer des documents de nomenclature des logiciels aussi appelés SBOM (Software Bill-of-Materials) dans les paquets Python. L’objectif est d’améliorer leur « mesurabilité » et de résoudre le problème des « dépendances fantômes ». Pour justifier cette proposition, les auteurs expliquent que les paquets Python sont particulièrement affectés par un problème de dépendance fantôme, ce qui signifie qu’ils incluent souvent des composants logiciels qui ne sont pas écrits en Python, que ce soit pour des raisons de compatibilité avec les normes, de facilité d’installation, ou dans des cas d’usage comme l’apprentissage machine qui utilisent des bibliothèques compilées de C, C++, Rust, Fortran, et autres langages.
La proposition note que si le format de paquetage binaire Python wheel est préféré par les utilisateurs en raison de sa facilité d’installation, il nécessite de regrouper des bibliothèques compilées partagées sans méthode d’encodage des métadonnées les concernant. De plus, les paquets liés aux paquets Python doivent parfois résoudre le problème de bootstrapping en Python, et donc inclure des projets Python purs dans le code source.
Un besoin de documentation plus en plus fort
Cependant, ces composants logiciels ne peuvent pas non plus être décrits à l’aide des métadonnées des paquets Python et risquent de ne pas être vus par les outils d’analyse de la composition des logiciels (Software Composition Analysis), si bien que les composants logiciels vulnérables ne sont pas signalés avec précision. L’inclusion d’un document SBOM annotant toutes les bibliothèques incluses permettrait aux outils SCA d’identifier de manière fiable les logiciels inclus.
Étant donné que le SBOM est indépendant de la technologie et de l’écosystème pour décrire la composition, la provenance et l’héritage des logiciels, et que les SBOM sont utilisés comme données d’entrée pour les outils d’analyse de la composition des logiciels (SCA), comme c’est le cas des scanners pour les vulnérabilités et les licences, la proposition préconise l’usage des SBOM pour améliorer la mesurabilité des paquets Python. Par ailleurs, les listes répertoriant tous les composants logiciels, leurs dépendances et les métadonnées associées sont requises par les récentes réglementations de sécurité, comme le Secure Software Development Framework (SSDF). En raison de ces réglementations, les auteurs de la proposition pensent que la demande de documents SBOM pour les projets open source devrait rester élevée, ce qui justifie encore plus l’utilisation des documents SBOM dans les paquets Python.
Basé sur Sigstore, GitHub Artifact Attestations signe et vérifie l’intégrité des artefacts logiciels dans les flux de travail Actions.
Présentée par GitHub, Artifact Attestations, la fonctionnalité de signature et de vérification de logiciels basée sur Sigstore, disponible en version bêta publique, protège l’intégrité des développements logiciels dans les flux de travail Actions. Avec cette solutuion, les responsables de projets peuvent créer une « trace écrite inviolable et infalsifiable » qui relie les artefacts logiciels au processus qui les a créés.
« Les consommateurs en aval de ces métadonnées peuvent les utiliser comme base pour des vérifications supplémentaires de sécurité et de validité par le biais d’évaluations de politiques via des outils comme Rego et Cue », avait expliqué Github le 2 mai, lors de l’annonce de la fonctionnalité. Dans un premier temps, la prise en charge de la vérification sera basée sur GitHub CLI, mais elle sera étendue pour apporter les mêmes contrôles à l’écosystème Kubernetes plus tard dans l’année.
Une paire de clés temporaire
Artifact Attestations s’appuie sur le projet open source Sigstore pour la signature et la vérification des artefacts logiciels. « Artifact Attestations simplifie les processus de déploiement de l’infrastructure à clé publique en plaçant la confiance dans la sécurité d’un compte GitHub », a déclaré le fournisseur. La fonction repose sur la signature d’un document avec une paire de clés temporaire. Une clé publique est attachée à un certificat associé à l’identité de la charge de travail d’un système de build.
« À la différence des autres approches de signature qui reposent sur des identités humaines et des clés à longue durée de vie, la clé privée ne quitte pas la mémoire du processus et est supprimée immédiatement après la signature », a déclaré GitHub. La mise en place d’Artifact Attestations se fait en ajoutant YAML à un workload Actions pour créer une attestation et en installant l’outil CLI pour la vérifier.
À partir du mois de décembre, GitHub intégrera Copilot Chat dans son offre de partage de code. L’offre Copilot Entreprise est, elle, attendue en février 2024. L’éditeur en a profité pour annoncer d’autres fonctionnalités dans Copilot autour des plug-in et de la sécurité.
Dans le monde du développement, GitHub a été un pionnier dans l’apport de l’IA pour la complétion de code avec Copilot. Depuis, la filiale de Microsoft a accéléré sur le sujet avec le renfort de GPT-4 d’OpenAI. Le fruit de cette collaboration est Copilot Chat qui passera de la version beta à une disponibilité générale pour les abonnés en décembre prochain. C’est ce qu’a annoncé l’éditeur lors de son évènement Universe 2023.
Un chat multitâche
Concrètement, les développeurs disposeront d’une interface de chat pour interagir avec Copilot en langage naturel. Les réponses aux questions liées au codage peuvent être reçues à partir d’un IDE pris en charge, dont les IDE JetBrains, Visual Studio Code et Visual Studio de Microsoft, et l’éditeur Neovim. À noter que le support de JetBrains est disponible en avant-première dès maintenant.
Le chatbot comprend une fonction inline propose aux développeurs de discuter de lignes de code spécifiques. Il introduit également des commandes « slash » pour rationaliser des tâches de création de tests unitaires. Disponible via Github.com, mais aussi sur l’application mobile (Android et iOS), Copilot Chat, les développeurs pourront accéder à différentes fonctions comme les demandes de retrait, la documentation et les questions générales de codage.
Copilot Enteprise attendu en février 2024
Autre point présenté, Copilot Enteprise, les sociétés peuvent personnaliser l’assistant avec le contexte complet d’une base de code. A travers le Chat, les équipes pourront rechercher et de construire de la documentation, obtenir des suggestions basées sur le code interne et privé, et examiner les demandes d’extraction. La disponibilité de Copilot Enteprise (qui englobe Copilot for Business) est prévue en février 2024 au prix de 39 dollars HT par utilisateur et par mois.
Entraîné sur du texte en langage naturel et du code source provenant de référentiels accessibles au public, le mode de fonctionnement de Copilot a suscité certaines controverses. En particulier, certains se sont interrogés sur la légalité de l’utilisation de code sous licence open source pour la formation. Un recours collectif intenté il y a un an est toujours en cours d’examen par les tribunaux et aucun accord n’a été trouvé, selon GitHub, qui se dit convaincue que Copilot respecte les lois en vigueur.
Plug-in et sécurité en complément
Parmi les autres annonces lors de l’évènement Universe 2023, GitHub a évoqué un programme de partenariat sur Copilot pour créer un écosystème de plug-ins. L’objectif est d’élargir la portée de ce que les développeurs peuvent faire avec l’IA GitHub envisage plusieurs cas d’usage, par exemple l’amélioration des performances des requêtes de base de données, la vérification du statut d’un « feature flag » et l’affichage des résultats d’un test A/B.
Par ailleurs, l’équipe de recherche Next a mis au point une passerelle alimentée par l’IA pour aider les développeurs à surmonter l’obstacle que représente la transposition des idées en code. Baptisé Copilot Workspace et attendu en 2024, ce service proposera un plan de mise en œuvre des modifications logicielles, qui seront ensuite construites, testées et validées. Si les développeurs introduisent une erreur, celle-ci sera corrigée et le code sera réexécuté. Enfin, Advanced Security s’enrichit de tests de sécurité applicative pilotés par l’IA. Ces tests détecteront et de corrigeront les vulnérabilités et les secrets dans le code.
JFrog a enrichi sa plateforme de plusieurs fonctionnalités, notamment de tests statiques de sécurité des applications (SAST) et de contrôles de conformité et d’intégrité des versions logicielles.
Surfant sur la problématique très actuelle de la sécurité des modèles de machine learning, JFrog a présenté un ensemble de fonctionnalités de gestion des modèles ML pour sa Software Supply Chain Platform. Appelé ML Model Management, cet ensemble vise à rationaliser la gestion et la sécurité des modèles d’apprentissage machine. Grâce à leur combinaison, les entreprises peuvent gérer leurs modèles propriétaires dans Artifactory et utiliser le référentiel de Hugging Face pour mettre en cache les modèles d’IA open source sur lesquels elles s’appuient, les rapprochant ainsi de la production et du développement et les protégeant de toute suppression ou modification.
De plus, les dernières capacités de sécurité ML de Xray proposent aux entreprises de détecter et de bloquer les modèles malveillants et ceux dont les licences ne sont pas conformes aux politiques de la société. Les utilisateurs peuvent également stocker des modèles ML créés ou enrichis en interne avec des contrôles d’accès et un historique des versions. Il est aussi possible de regrouper et de distribuer les modèles ML dans n’importe quelle version de logiciel. Selon JFrog, de plus en plus d’entreprises intègrent des modèles ML dans leurs applications. Les réglementations gouvernementales exigeant des fournisseurs de logiciels qu’ils indiquent ce qu’ils contiennent, JFrog pense qu’il ne faudra pas attendre longtemps avant que ces directives soient étendues aux modèles d’IA et de ML. « L’intégration de la capacité de gestion des modèles ML permet aux clients de stocker, de sécuriser et de gérer les modèles ML en même temps que d’autres composants logiciels », a déclaré l’entreprise.
D’autres fonctionnalités
Le même jour, JFrog a aussi dévoilé les fonctionnalités suivantes pour Software Supply Chain Platform :
– Static Application Security Testing (SAST) : cette fonction de tests statiques de sécurité des applications facilite le scan de code source pour rechercher des vulnérabilités de sécurité de type « zero-day ». JFrog SAST réduit le nombre de faux positifs et classe les actions de remédiation selon les priorités établies par une analyse contextuelle.
– Open-Source Software (OS) Catalog : cette fonction de moteur de recherche pour les solutions logicielles est accessible dans l’interface utilisateur de JFrog ou via une API. Alimentée par des données publiques et celles de JFrog, elle donne aux utilisateurs un aperçu des métadonnées de sécurité et de risque associées aux logiciels open source. Le catalogue fait partie de la composante Curation de la plateforme Software Supply Chain.
– Release Lifecycle Management (RLM) : cette fonction de gestion du cycle de vie des versions permet de créer un ensemble de versions immuables propre à un logiciel et ses composants dès le début du cycle de développement du logiciel. La fonction s’appuie également sur des systèmes de lutte contre la falsification, des contrôles de conformité et l’acquisition de preuves pour collecter des données sur chaque bundle de versions.
JFrog a déclaré que pour faire face à l’augmentation des attaques dans la cycle de dévloppement des logiciels, il était indispensable de sécuriser les releases au niveau binaire pour garantir l’immuabilité des versions publiées, car c’était le seul moyen de certifier l’intégrité de ces versions, et que la certification des releases était le seul moyen de certifier la sécurité de l’utilisation.
Govulncheck est un utilitaire en ligne de commande qui se sert de la base de données des failles dans Go pour les dénicher dans le code source et les binaires du langage.
Présenté le 13 juillet dernier, Govulncheck passe en version 1.0.0 et a pour ambition d’analyser les binaires et le code source de Go à la recherche de failles. Pour cela, l’utilitaire en ligne de commande réduit le bruit en s’appuyant sur une base de données des bugs dans les modules publics de Go. Il utilise l’analyse statique du code source ou de la table des symboles d’un binaire pour limiter ses rapports aux seules vulnérabilités susceptibles d’affecter une application particulière.
Govulncheck doit être construit avec Go 1.18 ou une version ultérieure. Go 1.20 est la version de production actuelle du langage de programmation. Il recherche les vulnérabilités en utilisant une configuration de compilation spécifique. Pour le code source, la configuration est la version de Go spécifiée par la commande « go » trouvée sur le chemin. Pour les binaires, la configuration est celle utilisée pour construire le code.
L’utilitaire avertit sur quelques limitations. Par exemple, il analyse les pointeurs de fonction et les appels d’interface de manière conservatrice, ce qui peut entraîner des faux positifs ou des des stacks d’appels inexacts. De même, il n’y a pas de support pour rendre secret les découvertes de vulnérabilités. L’outil doit être perfectionné au fil du temps. Il est possible de l’installer avec go install. (go install golang.org/x/vuln/cmd/govulncheck@latest).
Mis en exergue par la NSA, le C++ ne serait pas assez sécurisé notamment sur l’accès mémoire. Bjarne Stroustrup, le créateur du C++, n’est pas d’accord avec cette analyse.
C’est dans un bulletin du 20 novembre 2022 sur la sécurité de la mémoire des logiciels, que l’agence de renseignement américaine (NSA), a recommandé de ne pas utiliser le C++, conseillant aux entreprises d’opter plutôt pour des langages protégeant mieux les mémoires. Mais Bjarne Stroustrup défend le vénérable langage de programmation qu’il a conçu en 1979. Pour commencer, le créateur du C++ a rappelé les efforts déployés depuis des décennies pour améliorer le langage et le rendre plus sûr et plus efficace. « Notamment, le travail sur les instructions de base du C++ vise spécifiquement à fournir un C++ statiquement garanti, sûr au niveau des types et des ressources, pour les personnes qui en ont besoin, sans perturber les bases de code qui peuvent se débrouiller sans ces garanties solides ou introduire des chaînes d’outils supplémentaires », constate-t-il.
Le document de la NSA déconseille l’utilisation du C/C++ car, même si les programmeurs effectuent souvent des tests rigoureux pour s’assurer que le code est sûr, les problèmes de mémoire dans les logiciels sont toujours très impliqués dans l’exploitation des vulnérabilités. « La NSA conseille aux entreprises de laisser de côté les langages qui offrent peu ou pas de protection inhérente de la mémoire, comme le C/C++, et de leur préférer un langage sûr pour la mémoire quand c’est possible », a fait valoir l’agence. En guise d’exemple, la NSA cite des langages comme le C#, Go, Java, Ruby, Rust et Swift. Selon l’agence, si des langages couramment utilisés, comme le C et le C++, offrent une liberté et une flexibilité dans la gestion de la mémoire, ils s’appuient fortement sur le programmeur pour effectuer des contrôles sur les références mémoire.
Un mélange C et C++ dommageable
Mais Bjarne Stroustrup insiste sur les améliorations apportées à la sécurité. « Si je considérais que l’un de ces langages « sûrs » était supérieur au C++ pour les nombreux cas d’usage qui m’intéressent, je m’accommoderais du déclin du C/C++, mais ce n’est pas le cas ». Il ajoute « tel qu’il est décrit, le terme « sûr » se limite à la sécurité de la mémoire, laissant de côté une douzaine d’autres façons dont un langage pourrait (et sera) utilisé pour violer une certaine forme de sûreté et de sécurité « .
Il déplore également le mémo de la NSA associant le C++ à l’ancien langage C. Le C++, qui s’appelait à l’origine C avec classes, est une extension du C. « Comme c’est trop souvent le cas, l’agence regroupe le C et le C++ dans la seule catégorie C/C++, ignorant plus de 30 ans de progrès », a ajouté le créateur du C++. Dans un courriel envoyé la semaine dernière, M. Stroustrup a ajouté : « Oui, beaucoup trop de gens parlent du mythique langage C/C++, mais trop souvent, ils se concentrent ensuite sur les faiblesses de la partie C. Ces faiblesses peuvent être évitées en grande partie grâce à l’utilisation de la technologie C avec classes. Beaucoup de ces faiblesses peuvent être évitées en C++, essentiellement en écrivant un code plus efficace qui exprime plus directement l’intention du programmeur », a ajouté Bjarne Stroustrup.
Une sécurité des langages à géométrie variable
Dans ce courriel, Bjarne Stroustrup a également partagé sa définition de la sécurité. Telle qu’il l’entend, la sécurité du C++ vise les types et des ressources, dans laquelle chaque objet est utilisé conformément à son type et aucune ressource ne fuit. Pour le C++, cela implique une certaine vérification de l’étendue des fonctions au moment de l’exécution, l’élimination de l’accès par le biais de pointeurs pendants et une utilisation non abusive des casts et unions. « Le C++ offre des facilités de haut niveau, comme les conteneurs, l’étendue de fonction, les boucles range-for et les variantes qui peuvent offrir des garanties sans nuire à la productivité ou à l’efficacité ». En ce qui concerne les langages dits sûrs cités par la NSA, M. Stroustrup a déclaré que tous ces langages sont vulnérables parce que leur code n’est pas vérifié de manière statique. « En outre, chaque système doit utiliser un hardware, et l’accès effectif au matériel est rarement sûr », a-t-il ajouté.
Voici la stratégie préconisée par Bjarne Stroustrup pour utiliser le C++ en toute sécurité :
– L’analyse statique pour vérifier qu’aucun code non sûr n’est exécuté.
– Des règles de codage pour simplifier le code afin de rendre l’analyse statique possible à l’échelle industrielle.
– Des bibliothèques pour que ce code simplifié soit raisonnablement facile à écrire et pour assurer les contrôles d’exécution nécessaires.
Selon Bjarne Stroustrup, il existe des millions de développeurs C++ et des milliards de lignes de code C++. Le langage est actuellement utilisé dans des domaines comme l’aérospatiale, l’instrumentation médicale, l’IA/ML, les graphiques, la biomédecine, la physique des hautes énergies, etc. La NSA a reconnu que la gestion de la mémoire n’est pas entièrement sûre, même dans un langage « sûr pour la mémoire », et que des mécanismes comme les tests de sécurité des applications statiques (SAST) et les tests de sécurité des applications dynamiques (DAST) peuvent être utilisés pour améliorer la sécurité de la mémoire dans les langages dits « non sûrs pour la mémoire ». « Mais ni les SAST ni les DAST ne peuvent rendre un code non sécurisé par la mémoire, totalement sûr », a encore déclaré la NSA.