Que sont les SBOM et que signifient-ils pour les logiciels libres? –

Qu’y a-t-il dans le logiciel commercial et open source que vous utilisez? Quelle quantité a été écrite par le fournisseur et quelle partie est du code tiers? Peut-on faire confiance à tout ce code?

Les menaces sont réelles

La récente vague de cyberattaques très médiatisées démontre amplement les effets d’entraînement des cyberincidents agressifs. Le piratage de SolarWinds a exposé les réseaux de leurs clients à la menace de compromission des cybercriminels. L’attaque Codecov a exposé les environnements d’intégration continue / de déploiement continu de leurs utilisateurs aux acteurs de la menace.

Dans les deux cas, l’attaque contre les organisations s’est répercutée en aval sur d’autres membres de cet écosystème – les clients. Les attaques qui paralysent les infrastructures critiques ont un impact beaucoup plus large. Ce ne sont pas seulement les clients de l’organisation ou du service concerné qui sont concernés – les ondulations s’étendent vers des industries indépendantes et la société au sens large.

L’attaque du ransomware de mai 2021 contre la Colonial Pipeline Company a conduit à la fermeture d’un pipeline de 5500 miles. Parmi les autres carburants raffinés, le pipeline fournit 45% de l’approvisionnement en essence – 2,5 millions de barils par jour d’essence – à la côte Est. La livraison d’essence s’est simplement arrêtée. Les prix à la pompe sont montés en flèche et les achats de panique se sont installés. Des milliers de stations-service ont dû fermer en raison du manque d’approvisionnement.

L’attaque de la Colonial Pipeline Company était financièrement motivée. C’était une attaque de ransomware, une forme courante d’extorsion numérique. Colonial Pipeline a payé aux cybercriminels une rançon de 75 Bitcoins – environ 4,4 millions de dollars, selon les taux de change – pour que leurs systèmes leur soient restaurés.

Mais s’il s’agissait d’un acte de cyberterrorisme ou de cyberguerre, il n’y aurait eu aucune option pour acheter le programme de décryptage nécessaire pour remettre en ligne les systèmes sinistrés. Un État-nation doté de capacités cyber-offensives peut rendre un autre pays incapable de fonctionner en interne grâce à une campagne de cyberattaques stratégiques.

Répondre aux menaces

Le 21 mars 2021, le président Biden a signé un décret sur l’amélioration de la cybersécurité du pays. Il établit un ensemble de normes et d’exigences que tous les systèmes d’information fédéraux doivent respecter ou dépasser.

La section 4 du décret traite des moyens d’améliorer la sécurité de la chaîne d’approvisionnement des logiciels. Cela impose aux ministères gouvernementaux des obligations assorties de dates de fournir des directives, des normes et des procédures pour de nombreux aspects du développement et de l’acquisition de logiciels. Les fournisseurs de logiciels doivent respecter les normes et suivre les procédures pour être des fournisseurs de logiciels éligibles auprès du gouvernement.

La transparence est citée comme une exigence. Les éditeurs de logiciels doivent révéler tous les composants et bibliothèques tiers qui ont été utilisés dans le développement de leurs produits. Cette exigence se répercute tout au long de la chaîne d’approvisionnement, de sorte que les fournisseurs de ces bibliothèques et composants doivent à leur tour répertorier tous les composants logiciels de source externe qu’ils ont utilisés dans leurs produits.

Les logiciels open source sont spécifiquement mentionnés. Le décret dit «d’assurer et d’attester, dans la mesure du possible, l’intégrité et la provenance des logiciels open source utilisés dans n’importe quelle partie d’un produit».

Ce n’est pas surprenant. Un rapport de 2021 sur la sécurité open-source a révélé que le nombre moyen de composants open-source dans les projets commerciaux non triviaux est de 528. C’est une augmentation de 259% par rapport à il y a cinq ans, lorsque la moyenne était de 84 composants open-source par projet.

Open-Source comme consommable

De toute évidence, les projets open-source doivent répondre aux normes et procédures qui seront promulguées à la suite du décret. À première vue, la partie transparence devrait être facile. Les projets open-source suspendent leur code source à tout type d’examen. Mais bien sûr, les projets open-source utilisent d’autres composants open-source, qui utilisent d’autres composants open-source, et ainsi de suite, imbriqués comme des poupées russes.

En outre, les applications logicielles ont des dépendances. Ils s’appuient sur d’autres progiciels pour fonctionner. En choisissant d’inclure un seul composant open-source dans votre propre projet de développement, vous pourriez involontairement inclure de nombreux autres produits open-source en tant que dépendances.

Il ne suffit donc pas d’avoir votre code source disponible pour examen. Vous devez fournir une liste des ingrédients logiciels de votre produit, tout comme la liste des produits alimentaires et des ingrédients chimiques sur un emballage de barre chocolatée. Dans le monde du logiciel, cela s’appelle une nomenclature logicielle ou un SBOM.

La nomenclature du logiciel

La sécurité commence par la connaissance. Vous devez savoir ce que vous avez pour vous assurer que vous l’avez sécurisé. C’est pourquoi les registres des actifs informatiques et les registres de traitement des données sont si importants. Un SBOM – prononcé ess-bomb – est un document spécifique à une application qui répertorie tous les éléments logiciels qui composent un produit logiciel.

C’est une connaissance précieuse. Le posséder permet aux utilisateurs de ce logiciel de prendre des décisions en matière de sécurité. Si vous connaissez les composants présents dans le logiciel, le risque associé à chacun d’eux et la gravité de chaque risque, vous pouvez faire des choix réfléchis et éclairés.

Vous pouvez lire la liste des ingrédients sur un emballage de barre chocolatée et constater qu’il contient quelque chose à quoi vous êtes allergique. Avec un SBOM, vous pouvez passer en revue les versions de build, les numéros de version des ingrédients logiciels et décider de continuer ou non. Par exemple, vous pouvez refuser catégoriquement d’utiliser un produit qui incorpore (disons) telnet, ou un qui utilise une version de SSH qui a une vulnérabilité connue.

Mettre en place un SBOM détaillé n’est pas une tâche de cinq minutes. Mais il doit être précis et suffisamment détaillé, sinon il ne servira pas son objectif. Au minimum, pour chaque composant logiciel d’un projet logiciel, un SBOM doit contenir:

• Nom du fournisseur: Le fournisseur ou les personnes qui ont écrit le logiciel.
• Nom du composant: Le nom du composant.
• Identifiant unique: Un identifiant unique universel (UUID).
• Chaîne de version: Les détails de construction et de version du composant.
• Hash de composant: Un hachage cryptographique du composant. Cela permet à un destinataire de vérifier, s’il a des soupçons, si un binaire qui lui a été fourni a été modifié.
• Relation: La relation entre les composants logiciels décrit les dépendances entre les composants et les composants qui ont été compilés et liés à d’autres composants.
• Licence: Le type de licence sous lequel le composant logiciel est publié.
• Nom de l’auteur: L’auteur du SBOM. Ce n’est pas nécessairement le fournisseur du logiciel.

Pour que les SBOM soient largement adoptés, il doit exister une norme définissant les formats de données, le contenu des données et les processus et normes acceptés. Cela est susceptible d’apparaître dans le cadre des directives que le décret a demandé d’être créé.

Il existe plusieurs normes SBOM concurrentes. Les trois pionniers dans ce domaine sont Software Package Data Exchange (SPDX), la norme ISO 19770-5: 2013 Software Identification (SWID) et CycloneDX. Il sera intéressant de voir si l’une d’elles est adoptée par le gouvernement fédéral comme norme préférée.

L’automatisation peut aider

Plusieurs classes d’outils peuvent aider à la production et à l’utilisation des SBOM. Des progiciels sont disponibles pour analyser les projets, déterminer les dépendances et générer des SBOM – ou des SBOM presque complets dans lesquels vous pouvez insérer des détails de finition.

Les SBOM seront probablement disponibles sous forme de téléchargements ou dans le cadre du logiciel packagé, un peu comme un fichier «readme». Une fois que vous êtes en possession du SBOM de quelqu’un d’autre, vous devez le réviser.

Cela va prendre du temps. Chaque composant devra être vérifié pour s’assurer qu’il est autorisé selon les critères que votre organisation a définis et que la licence de chaque composant ne provoque aucun conflit pour vous.

Un logiciel est disponible pour effectuer ces vérifications à votre place. Les packages les plus complets répertorient les vulnérabilités connues pour chaque composant et la gravité de ces vulnérabilités.

La sécurité commence par la connaissance

La provenance des progiciels et de tous leurs composants va devenir un outil vital pour les consommateurs de logiciels pour évaluer et prendre des décisions d’achat. Ce sera également un facteur de différenciation pour les éditeurs et les producteurs de logiciels, qu’ils créent des logiciels pour d’autres développeurs ou pour les utilisateurs finaux.