La Maison Blanche rejoint OpenSSF et la Fondation Linux pour sécuriser les logiciels open source

Sécuriser la chaîne d’approvisionnement des logiciels open source est une tâche énorme. L’année dernière, l’administration Biden a publié un décret exécutif pour améliorer la sécurité de la chaîne d’approvisionnement des logiciels. Cela s’est produit après que l’attaque du rançongiciel Colonial Pipeline a interrompu les livraisons de gaz et de pétrole dans tout le sud-est et l’attaque de la chaîne d’approvisionnement du logiciel SolarWinds. La sécurisation des logiciels est devenue une priorité absolue. En réponse, l’Open Source Security Foundation (OpenSSF) et la Linux Foundation ont relevé ce défi de sécurité. Maintenant, ils demandent un financement de 150 millions de dollars sur deux ans pour résoudre dix problèmes majeurs de sécurité open source.

Ils auront besoin de chaque centime et plus encore.

Le gouvernement ne paiera pas le fret pour ces changements. 30 millions de dollars ont déjà été promis par Amazon, Ericsson, Google, Intel, Microsoft et VMWare. Plus est déjà en route. Amazon Web Services (AWS) a déjà promis 10 millions de dollars supplémentaires.

Lors de la conférence de presse de la Maison Blanche, le directeur général d’OpenSSF, Brian Behlendorf, a déclaré : « Je veux être clair : nous ne sommes pas ici pour collecter des fonds auprès du gouvernement. couronné de succès. »

Voici les dix objectifs que l’industrie open source s’est engagée à atteindre.

1. Formation à la sécurité : offrez à tous une formation et une certification de base en matière de développement de logiciels sécurisés.

2. Évaluation des risques : établissez un tableau de bord d’évaluation des risques public, indépendant du fournisseur et basé sur des mesures objectives pour les 10 000 principaux composants OSS (ou plus).

3. Signatures numériques : Accélérez l’adoption des signatures numériques sur les versions logicielles.

4. Sécurité de la mémoire : éliminez les causes profondes de nombreuses vulnérabilités en remplaçant les langages non sécurisés en mémoire.

5. Réponse aux incidents : Établissez l’équipe de réponse aux incidents de sécurité OpenSSF Open Source, des experts en sécurité qui peuvent intervenir pour aider les projets open source pendant les moments critiques lors de la réponse à une vulnérabilité.

6. Meilleure analyse : accélérez la découverte de nouvelles vulnérabilités par les mainteneurs et les experts grâce à des outils de sécurité avancés et des conseils d’experts.

7. Audits de code : Effectuez des révisions de code tierces (et tout travail de correction nécessaire) sur jusqu’à 200 des composants OSS les plus critiques une fois par an.

8. Partage de données : coordonnez le partage de données à l’échelle de l’industrie pour améliorer la recherche qui aide à déterminer les composants OSS les plus critiques.

9. Nomenclature logicielle (SBOM) : Partout Améliorez l’outillage et la formation SBOM pour favoriser l’adoption.

10. Chaînes d’approvisionnement améliorées : Améliorez les 10 systèmes de création de logiciels open source, les gestionnaires de packages et les systèmes de distribution les plus critiques avec de meilleurs outils de sécurité de la chaîne d’approvisionnement et les meilleures pratiques.

Je reviendrai plus en détail sur ceux-ci dans des histoires ultérieures, mais même en un coup d’œil, c’est une entreprise colossale. Par exemple, C, qui est au cœur du noyau Linux, le plus important de tous les projets open source, contient de nombreuses vulnérabilités. Alors que le langage Rust sécurisé en mémoire est maintenant utilisé sous Linux, il reste des années, des décennies, avant de remplacer le C dans les plus de 27,8 millions de lignes de code de Linux. En effet, je doute que nous verrons jamais tout le code C de Linux remplacé par Rust.

Nous sommes déjà sur le point de résoudre certains des autres. La société de sécurité open source Chainguard appelle l’industrie du logiciel à se standardiser sur Sigstore. Sigstore permet aux développeurs de signer en toute sécurité des artefacts logiciels tels que des fichiers de version, des images de conteneurs, des fichiers binaires, des manifestes de nomenclatures. et plus. Ce projet de la Linux Foundation est soutenu par Google, Red Hat et Purdue University.

Sigstore a plusieurs fonctionnalités intéressantes. Ceux-ci inclus:

• La signature sans clé de Sigstore offre une excellente expérience de développement et supprime le besoin d’une gestion des clés pénible.

• Le journal de transparence publique de Sigstore (Rekor) et les API permettent aux consommateurs de Kubernetes de vérifier facilement les artefacts signés.

• L’utilisation de normes par Sigstore, telles que la prise en charge de tout artefact Open Container Initiative (OCI) (y compris les conteneurs, les graphiques Helm, les fichiers de configuration et les ensembles de politiques) et OpenID Connect (OIDC), signifie qu’il s’intègre de manière transparente avec d’autres outils et services.

• La communauté Sigstore active, open source et neutre vis-à-vis des fournisseurs donne l’assurance que le projet sera rapidement adopté et deviendra un standard de facto de l’industrie.

En effet, Kubernetes a déjà adopté Sigstore. En bref, il est simple d’adopter une signature numérique sécurisée pour votre code. Ensuite, les programmeurs qui utilisent votre code peuvent être sûrs qu’il s’agit bien du code qu’ils veulent et auquel ils peuvent faire confiance.

Ce qui est essentiel. Comme l’a déclaré Stephen Chin, société de sécurité de la chaîne logicielle JFrog, vice-président des relations avec les développeurs : « Alors que l’open source a toujours été considéré comme une graine de modernisation, la récente augmentation des attaques de la chaîne d’approvisionnement logicielle a démontré que nous avons besoin d’un processus plus durci pour valider l’open-source. référentiels sources. »

Bien sûr, il y aura toujours des bugs. Comme l’a dit Behlendorf, « Les logiciels ne seront jamais parfaits. Le seul logiciel qui n’a pas de bugs est un logiciel sans utilisateurs. »

Histoires liées :