Ce que fait la loi sur la sécurisation des logiciels libres et ce qu’elle manque
Il y a au moins une chose sur laquelle les républicains et les démocrates peuvent s’entendre au Sénat américain : l’importance des logiciels open source. Sérieusement.
Comme l’a déclaré le sénateur américain Gary Peters (D-MI) la semaine dernière, « les logiciels open source sont le fondement du monde numérique ». Son partenaire de l’autre côté de l’allée, Rob Portman (R-OH), était d’accord, disant : « Les ordinateurs, les téléphones et les sites Web que nous utilisons tous au quotidien contiennent des logiciels open source qui sont vulnérables aux cyberattaques. »
Par conséquent, « La loi bipartite sur la sécurisation des logiciels open source [PDF] veillera à ce que le gouvernement américain anticipe et atténue les vulnérabilités de sécurité des logiciels open source afin de protéger les données les plus sensibles des Américains. »
Ce projet de loi propose que puisque l’explosion de la sécurité de Log4j en 2021 et ses répliques continues ont montré à quel point nous sommes vulnérables aux attaques de code open source, la Cybersecurity and Infrastructure Security Agency (CISA) doit aider à « garantir que les logiciels open source est utilisé en toute sécurité par le gouvernement fédéral, les infrastructures essentielles et autres. »
Après tout, le communiqué du gouvernement du 22 septembre introduisant la législation ajoutait : « L’écrasante majorité des ordinateurs dans le monde s’appuient sur du code open source ». C’est loin d’être la première fois que le gouvernement fédéral constate à quel point les logiciels libres sont devenus vitaux pour tout le monde. En janvier, la Federal Trade Commission des États-Unis a averti qu’elle punirait les entreprises qui ne résolvent pas leurs problèmes de sécurité Log4j.
Le gouvernement américain soutient depuis longtemps les logiciels open source. Par exemple, depuis 2000, la National Security Agency a aidé à créer Security-Enhanced Linux (SELinux). Et, en 2016, le directeur de l’information américain de l’époque, Tony Scott, a proposé une politique de codage favorable à l’open source qui exigeait que tout « nouveau logiciel développé spécifiquement pour ou par le gouvernement fédéral soit mis à disposition pour partage et réutilisation entre les agences fédérales ». comprend un programme pilote qui se traduira par la diffusion publique d’une partie de ce nouveau code personnalisé financé par le gouvernement fédéral. »
Aussi: XeroLinux pourrait être le plus beau bureau Linux du marché
La loi sur la sécurisation des logiciels open source, cependant, fait passer l’open source du domaine des décisions politiques et réglementaires au droit fédéral. Ce projet de loi obligera la CISA à élaborer un cadre de risque pour évaluer la manière dont le code open source est utilisé par le gouvernement fédéral. La CISA déciderait également de la manière dont le même cadre pourrait être utilisé par les propriétaires et les exploitants d’infrastructures critiques.
Selon l’Open Source Security Foundation (OpenSSF) dans son analyse de la loi, la « CISA produirait un cadre d’évaluation initial pour gérer les risques liés au code open source, incorporant les cadres gouvernementaux, industriels et communautaires open source et les meilleures pratiques des logiciels Sécurité. »
En bref, la CISA n’essaierait pas de réinventer la roue, mais utiliserait plutôt le meilleur des techniques de sécurité open source existantes. Cela suit les traces du décret exécutif du président Joseph Biden sur l’amélioration de la cybersécurité de la nation, qui stipulait que les développeurs devaient fournir « à un acheteur un SBOM [Software Bill of Materials] pour chaque candidature. »
La loi obligera également la CISA à identifier les moyens d’atténuer les risques liés aux logiciels open source. Pour ce faire, la CISA doit embaucher des développeurs open source pour résoudre les problèmes de sécurité. Il propose également que certaines agences fédérales créent des bureaux de programme open source (OSPO). Enfin, cela obligera le Bureau de la gestion et du budget (OMB) à financer un sous-comité de sécurité des logiciels CISA et à publier des directives fédérales sur la manière dont les utilisateurs peuvent sécuriser les logiciels open source.
Les personnes qui suivent de près la sécurité open source en ont déjà beaucoup entendu parler. Comme l’a noté OpenSSF, « Certaines des idées nous semblent familières – par exemple, l’utilisation de SBOM, l’importance des pratiques de sécurité des processus de développement, de construction et de publication), et un appel à un cadre d’évaluation des risques [echo] notre flux Tableau de bord d’évaluation des risques de notre plan de mobilisation. »
Mais, étonnamment, le projet de loi manque d’autres points. Par exemple, tous les logiciels, pas seulement open source, doivent être vérifiés pour les risques potentiels. Comme Brad Arkin, vice-président principal de Cisco et responsable de la sécurité et de la confiance, a témoigné devant le Congrès à propos de Log4J : « Les logiciels open source n’ont pas échoué, comme certains l’ont suggéré, et il serait erroné de suggérer que la vulnérabilité Log4j est la preuve d’une faille unique. ou un risque accru avec les logiciels open source. La vérité est que tous les logiciels contiennent des vulnérabilités dues aux défauts inhérents au jugement humain dans la conception, l’intégration et l’écriture de logiciels.
Aussi: Il est temps d’arrêter d’utiliser C et C++ pour les nouveaux projets, déclare Microsoft Azure CTO
Pourtant, aussi imparfait que soit le projet de loi, l’OpenSSF affirme qu’il est « engagé à collaborer et à travailler à la fois en amont et avec les communautés existantes pour faire progresser la sécurité open source pour tous. Nous sommes impatients de collaborer avec les décideurs du monde entier pour améliorer la sécurité du logiciels dont nous dépendons tous. »
L’OpenSSF n’est pas le seul groupe à vouloir travailler avec le gouvernement pour améliorer fondamentalement la sécurité open source, mais a également des inquiétudes. Deb Bryant, directrice de la politique américaine de l’Open Source Initiative (OSI), craint que le Congrès « construise un cadre qui vise à traiter l’open source comme une classe spéciale de logiciels au lieu de le résoudre pour tous les logiciels ».
Heather Meeker, une avocate open source bien connue et partenaire général d’OSS Capital, a ajouté avec plus d’optimisme : « Il est bon de voir un effort bipartite pour améliorer la gestion de la sécurité dans l’infrastructure logicielle, y compris les logiciels open source. Le marché privé a longtemps réclamé cette amélioration, via les demandes et les attentes des clients vis-à-vis des fournisseurs de logiciels et de services cloud. Mais la surveillance gouvernementale peut aider à accélérer les efforts d’amélioration en dehors des accords commerciaux avec les fournisseurs, ou dans des situations où le pouvoir du marché des fournisseurs permet aux fournisseurs de repousser les demandes des clients.
Bien sûr, ce n’est pas parce qu’un projet de loi parvient au Congrès qu’il deviendra loi. Pourtant, son comité a avancé le projet de loi au Sénat le 29 septembre. C’est très rapide pour n’importe quel projet de loi sur n’importe quelle question. S’il parvient au Congrès, il ne fait aucun doute que Biden le signera. Avec un peu de chance, la sécurisation des logiciels open source deviendra la loi du pays en 2023.
Histoires liées :