Un nouvel espoir pour la sécurité des logiciels

Par Matt Asay

Contributeur, InfoWorld |

La vulnérabilité Log4j de décembre 2021 a mis en lumière la chaîne d’approvisionnement logicielle comme une zone de sécurité massivement négligée. Cela a révélé à quel point nos artefacts logiciels sont interconnectés et comment nos systèmes sont aussi sécurisés que leurs maillons les plus faibles. Cela a également renforcé l'idée selon laquelle nous pouvons penser que la sécurité est quelque chose que nous pouvons acheter, mais en réalité, il s'agit de la façon dont nous fonctionnons en tant qu'équipes de développement.

Depuis, nous sprintons pour nous améliorer.

Peut-être plus particulièrement, le projet Sigstore, que Google a open source, est devenu la méthode de signature de facto pour les artefacts logiciels, adoptée par tous les principaux écosystèmes linguistiques, notamment Java, Python, Node, Ruby, etc. Il est devenu l’un des projets de sécurité open source les plus rapidement adoptés de l’histoire et a donné aux développeurs un « sceau de cire » d’authenticité pour déterminer l’origine et la provenance de leurs éléments constitutifs de logiciels.

Alors, on y est déjà ?

Pas vraiment. Pas encore. Le concept de nomenclature logicielle (SBOM) introduit par le décret de la Maison Blanche en mai 2021 continue de paraître lointain. Ce concept de lingua franca permettant aux développeurs de partager des listes d'ingrédients dans des progiciels a plusieurs formats émergents (SPDX, CycloneDX), ce qui complique les choses. Pire encore, il n'est pas clair comment les SBOM s'intégreraient réellement dans les flux de travail des développeurs et quels avantages spécifiques un développeur gagnerait dans le processus.

Ce qui commence à rassembler tout cela (et à créer plus d'urgence pour créer une stratégie cohérente autour de la signature de logiciels, des SBOM et du flux de travail des développeurs) est la réglementation, qui exigerait une appropriation plus stricte de l'intégrité de la sécurité des logiciels.

En avril dernier, la Cybersecurity and Infrastructure Agency (CISA) a publié une demande de commentaires sur un nouveau formulaire d'attestation de développement de logiciels sécurisés qui imposera aux PDG des éditeurs de logiciels d'attester que leurs logiciels ont été construits dans des environnements sécurisés et que Des efforts raisonnables et de bonne foi ont été déployés pour maintenir des chaînes d’approvisionnement de codes sources fiables.

Qu’est-ce qui est considéré comme « raisonnable » ?

Jusqu'à présent, les efforts « raisonnables » semblent être les lignes directrices énoncées dans les exigences d'analyse des vulnérabilités pour les conteneurs de FedRAMP et dans le cadre de développement de logiciels sécurisés du National Institute of Standards and Technology. Mais l’interprétation beaucoup plus nuancée et lue entre les lignes des nouvelles exigences d’auto-attestation se trouve dans les clauses qui couvrent le code tiers incorporé dans le logiciel. En bref, les fournisseurs de logiciels seront tenus responsables de l’open source populaire non financé et non maintenu qu’ils utilisent dans leurs chaînes d’approvisionnement.

Attends quoi? Responsable du code aléatoire d'un responsable de projet ? Apparemment, oui. Est-ce « raisonnable » ?

Cet éventail vertigineux de considérations pour les RSSI est devenu la cible d’un certain nombre de mèmes sur Twitter :

Il s’agit d’une vérification quelque peu choquante, si nécessaire, de l’adoption sans entrave de l’open source. Je ne dis pas que les entreprises ne devraient pas utiliser l’open source, bien au contraire. Je vous rappelle qu'il n'y a pas de repas gratuit, y compris lorsqu'il est présenté sous forme de logiciel gratuit (et open source). Quelqu'un doit payer pour que les responsables restent allumés, et quelqu'un doit aider les développeurs à donner un sens à tous ces logiciels open source entrants.

Chainguard pourrait bien être quelqu’un de tel.

Chainguard est une société dirigée par d'anciens Googleurs à l'origine du projet Sigstore. Il s'agit de rassembler le tout dans une chaîne d'outils cohérente pour les développeurs. Les premiers efforts de la startup se sont concentrés sur les étapes visant à verrouiller le processus de création et à créer des fonctionnalités telles que les signatures, la provenance et les SBOM natives des chaînes d'approvisionnement de logiciels et du processus de création de logiciels. L'année dernière, avec Wolfi, ils ont présenté la première (dé)distribution Linux communautaire construite spécifiquement autour des primitives de sécurité de la chaîne d'approvisionnement. Ils ont également lancé Chainguard Images, qui sont des images de base pour les binaires autonomes, des applications comme nginx et des outils de développement tels que les compilateurs Go et C.