Brian Behlendorf

En tant que personne ayant passé toute sa carrière dans les logiciels open source (OSS), le brouillage Log4Shell (un incendie à quatre alarmes à l’échelle de l’industrie pour remédier à une grave vulnérabilité dans le Apache Log4j package) est un humble rappel du chemin qu’il nous reste encore à parcourir. Les logiciels libres sont désormais au cœur du fonctionnement de la société moderne, aussi essentiels que les ponts routiers, les plateformes de paiement bancaire et les réseaux de téléphonie mobile, et il est temps que les fondations des logiciels libres commencent à agir en conséquence.

Des organisations comme Apache Software Foundation, Linux Foundation, Python Foundation et bien d’autres fournissent des services juridiques, d’infrastructure, marketing et autres à leurs communautés de développeurs OSS. Dans de nombreux cas, les efforts de sécurité de ces organisations manquent de ressources et sont paralysés dans leur capacité à définir des normes et des exigences qui atténueraient les risques de vulnérabilités majeures, de peur d’effrayer les nouveaux contributeurs. Trop d’organisations n’ont pas appliqué les fonds collectés ou défini des normes de processus pour améliorer leurs pratiques de sécurité, et ont imprudemment penché en faveur de la quantité plutôt que de la qualité du code.

À quoi ressemblerait « agir comme ça » ? Voici quelques actions que les fondations OSS peuvent faire pour atténuer les risques de sécurité :

Mettre en place une équipe de sécurité à l’échelle de l’organisation pour recevoir et trier les rapports de vulnérabilité, ainsi que coordonner les réponses et les divulgations aux autres projets et organisations concernés. Effectuer des analyses de sécurité fréquentes, via les outils CI, pour détecter les vulnérabilités inconnues dans le logiciel et reconnaître les vulnérabilités connues dans dépendances.Effectuer des audits de sécurité externes occasionnels du code critique, en particulier avant les nouvelles versions majeures.Exiger que les projets utilisent des frameworks de test et assurer une couverture de code élevée, afin que les fonctionnalités sans tests soient découragées et que les fonctionnalités sous-utilisées soient éliminées de manière proactive.Exiger que les projets suppriment les obsolètes ou des dépendances vulnérables. (Certains projets Apache ne sont pas vulnérables au CVE Log4j v2, car ils sont toujours livrés avec Log4j v1, qui a des faiblesses connues et n’a pas reçu de mise à jour depuis 2015 !)Encourager, puis exiger éventuellement, l’utilisation de formats SBOM comme SPDX pour aider tout le monde à suivre les dépendances plus facilement et plus rapidement, afin que les vulnérabilités soient plus faciles à trouver et à corriger.Encouragez, puis demandez éventuellement aux responsables de la maintenance de démontrer leur familiarité avec les bases des pratiques de développement de logiciels sécurisés.

Beaucoup d’entre eux sont intégrés dans le Insigne des bonnes pratiques CII, l’une des premières tentatives pour les codifier en une métrique comparable objective, et un effort qui s’est maintenant déplacé vers OpenSSF. L’OpenSSF a également publié un cours gratuit pour les développeurs sur la façon de développer des logiciels sécurisés, et SPDX a récemment été publié en tant que norme ISO.

Aucune des pratiques ci-dessus ne consiste à payer davantage les développeurs ou à canaliser des fonds directement des utilisateurs de logiciels vers les développeurs. Ne vous méprenez pas, les développeurs open source et les personnes qui les soutiennent devraient être mieux payés et plus appréciés en général. Cependant, ce serait une insulte pour la plupart des responsables de suggérer que si vous aviez simplement mis plus d’argent dans leurs poches, ils auraient écrit un code plus sécurisé. Dans le même temps, il est juste de dire qu’une tragédie des biens communs frappe lorsque chaque utilisateur en aval suppose que ces pratiques sont en place, exécutées et payées par quelqu’un d’autre.

Appliquer ces pratiques de sécurité et fournir les ressources nécessaires pour y remédier est ce que les fondations sont de plus en plus censées faire pour leur communauté. Les fondations devraient commencer à établir des exigences liées à la sécurité pour leurs projets hébergés et matures. Ils doivent collecter auprès des parties prenantes les ressources nécessaires pour des audits rémunérés réguliers pour leurs projets les plus critiques, des outils d’analyse et des CI pour tous leurs projets, et avoir au moins quelques membres du personnel rémunérés dans une équipe de sécurité inter-projets afin que les réponses urgentes soient ce n’est pas laissé aux bénévoles individuels. À long terme, les fondations devraient envisager de fournir des ressources pour projets ou segments de code critiques vers des langages sûrs pour la mémoire, ou financer des primes pour plus de tests.

L’Apache Software Foundation semble avoir une grande partie de ce droit, soyons clairs. Bien qu’ayant été averti juste avant les vacances de Thanksgiving, leur équipe de sécurité bénévole a travaillé avec les responsables de Log4j et a répondu rapidement. Log4j compte également près de 8 000 tests réussis dans son pipeline CI, mais même tous ces tests n’ont pas détecté la manière dont cette vulnérabilité pourrait être exploitée. Et en général, les projets Apache ne sont pas du tout obligés d’avoir une couverture de test, et encore moins d’exécuter le type d’analyses de sécurité SAST ou d’héberger des audits tiers qui auraient pu détecter cela.

De nombreuses autres fondations, y compris celles hébergées à la Linux Foundation, ont également du mal à faire tout cela – ce n’est pas facile de faire passer la philosophie du laissez-faire que de nombreuses fondations ont en ce qui concerne la qualité du code, et les audits et tests de code tiers ne le font pas. venir pas cher. Mais pour des raisons de durabilité, de réduction de l’impact sur la communauté au sens large et d’être plus résilients, nous devons faire mieux. Et nous devons le faire ensemble, car une crise de confiance dans les logiciels libres nous affecte tous.

C’est là qu’OpenSSF entre en jeu et ce qui m’a poussé vers le projet en premier lieu. Au cours de la nouvelle année, vous nous verrez annoncer un ensemble de nouvelles initiatives qui s’appuient sur le travail que nous avons fait pour « rehausser le niveau » de la sécurité dans la communauté open source. La seule façon de le faire efficacement est de développer des outils, des conseils et des normes qui rendent l’adoption par la communauté open source encouragée et pratique plutôt que lourde ou bureaucratique. Nous travaillerons et accorderons des subventions à d’autres projets et fondations open source pour les aider à améliorer leur jeu de sécurité. Si vous voulez rester proche de ce que nous faisons, suivez-nous sur Twitter ou s’impliquer d’autres manières. Pour un avant-goût de ce que nous avons fait à ce jour, lisez notre segment dans le Rapport annuel de la Fondation Linux, ou regardez notre plus récent Mairie.

En espérant un 2022 avec moins de quatre alarmes incendies,

Brian

Brian Behlendorf est directeur général de l’Open Source Security Foundation (OpenSSF) de la Linux Foundation. Il a été membre fondateur du groupe Apache, qui est devenu plus tard l’Apache Software Foundation, et a été président de la fondation pendant trois ans.

La poste Les fondations Open Source doivent travailler ensemble pour empêcher le prochain brouillage Log4Shell est apparu en premier sur Fondation Linux.