Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Ces dernières années, l'adoption de logiciels libres dans le domaine du développement a fait un bond en avant. jusqu'à 90 % de ce qui est construit. La popularité de ces logiciels auprès des entreprises du monde entier s'explique par les économies réalisées et l'accélération de la mise sur le marché des produits. Cependant, il y a un aspect crucial à prendre en compte lors de l'intégration de composants logiciels open-source. Synopsys rapporte que 84 % des bases de code commerciales et propriétaires comportent au moins une vulnérabilité connue en matière de logiciels libres. Cela souligne l'importance croissante de garantir la sécurité des composants open-source que vous utilisez. C'est là qu'une nomenclature logicielle (SBOM) s'avère utile.
Qu'est-ce qu'un SBOM ?
Les composants open-source et le code tiers peuvent être complexes et comporter de nombreuses couches. À l'instar des poupées russes, ces éléments s'emboîtent les uns dans les autres et chaque couche peut être soumise à ses propres règles. Pour s'assurer que leurs logiciels sont sûrs, les entreprises doivent savoir exactement ce qu'ils contiennent.
Un SBOM fournit des informations détaillées sur chaque composant. C'est comme une étiquette pour un logiciel, qui énumère toutes les parties et leurs relations - comme un mélange de pièces à code source ouvert, de pièces de tiers et de code propre à l'entreprise. Il donne des détails techniques sur chaque élément, notamment son nom, sa version et sa licence. Les SBOM peuvent également inclure des informations sur les problèmes de sécurité, les dépendances transitives, l'origine des composants et d'autres informations.
Par exemple, dans l'industrie automobile, les fabricants établissent des spécifications détaillées pour chaque véhicule, y compris pour les pièces qu'ils ont fabriquées et celles qui proviennent de fournisseurs extérieurs. Si une pièce s'avère défectueuse, le fabricant sait rapidement quels sont les véhicules concernés. Il peut ainsi informer les propriétaires des réparations ou des remplacements nécessaires. Ce type d'enregistrement clair est important pour déterminer l'origine des défauts et la manière de les corriger efficacement.
Exigences minimales en matière de données
Aux États-Unis, les développeurs de logiciels adoptent de plus en plus la nomenclature des logiciels (SBOM), sous l'influence des nouvelles politiques gouvernementales en matière de sécurité de l'information qui exigent des mesures plus strictes en matière de sécurité des logiciels.
Le décret présidentiel présidentiel n° 14028publié le 12 mai 2021, visant à "améliorer la cybersécurité de la nation", établit des normes spécifiques pour les systèmes d'information fédéraux. Un aspect essentiel de cet ordre, détaillé à la section 4, consiste à formuler des lignes directrices pour le développement de logiciels sécurisés et les pratiques d'approvisionnement. Le document reconnaît le SBOM comme un élément crucial pour assurer l'intégrité des logiciels et gérer les risques associés à la chaîne d'approvisionnement en logiciels.
Conformément au décret n° 14028, le ministère américain du commerce et l'administration nationale des télécommunications et de l'information (NTIA) ont défini des exigences minimales en matière de données pour les composants logiciels, classées en trois groupes principaux :
- Les champs de données comprennent des informations essentielles sur chaque composant du logiciel, telles que
-
- Nom du fournisseur: Le nom d'une entité qui crée, définit et identifie les composants.
- Nom du composant: Désignation attribuée à une unité de logiciel définie par le fournisseur d'origine.
- Version du composant: Identifiant utilisé par le fournisseur pour spécifier un changement de logiciel par rapport à une version précédemment identifiée.
- Autres identifiants uniques : Autres identifiants utilisés pour identifier un composant ou servir de clé de recherche pour les bases de données pertinentes.
- Relations de dépendance: Caractérise la relation selon laquelle un composant amont X est inclus dans le logiciel Y.
- Auteur de SBOM Data: Le nom de l'entité qui crée les données SBOM pour ce composant.
- Horodatage: Enregistrement de la date et de l'heure de l'assemblage des données SBOM.
- Support d'automatisation facilite la génération automatique des SBOM et leur lisibilité par les machines afin de permettre leur mise à l'échelle dans l'écosystème logiciel. En outre, les SBOM doivent être générés dans l'un des trois formats suivants :
- Échange de données sur les progiciels (SPDX)
- CycloneDX
- Étiquettes d'identification des logiciels (SWID)
Échange de données sur les progiciels (SPDX)
Ce format est largement utilisé pour documenter les informations sur les licences et les composants logiciels. Développé par la Fondation Linux, SPDX normalise la façon dont les organisations communiquent les composants logiciels et les licences utilisées dans leurs produits, simplifiant ainsi la conformité.
CycloneDX
Principalement axé sur la sécurité, CycloneDX est un format SBOM léger conçu pour être utilisé dans des contextes de sécurité des applications et d'analyse des composants de la chaîne d'approvisionnement. Il fournit un moyen standard de représenter les composants, les bibliothèques et les modules d'une application, ainsi que les risques de sécurité et les licences qui leur sont associés.
Étiquettes d'identification des logiciels (SWID)
Développées par l'Organisation internationale de normalisation (ISO), les balises SWID sont des structures XML qui fournissent une identification unique pour les produits logiciels. Elles permettent de gérer l'inventaire des logiciels et de garantir le respect des licences. Les balises SWID sont particulièrement utiles pour la gestion des actifs logiciels et la cybersécurité.
- Pratiques et processus qui doivent être suivis pour intégrer le SBOM dans le cycle de développement sécurisé. Il s'agit notamment d'établir une fréquence pour les mises à jour du SBOM, de définir la profondeur des arbres de dépendance, de traiter les éléments du SBOM dont les informations sur les dépendances sont incertaines ou incomplètes, et de définir des politiques de distribution, de livraison et de contrôle d'accès.
Cas d'utilisation du SBOM
Les cas d'utilisation du SBOM peuvent être divisés en trois catégories principales :
- Détection et gestion des vulnérabilités : Le SBOM permet de suivre tous les composants du code. Lorsqu'une vulnérabilité critique est découverte, les équipes de sécurité peuvent rapidement utiliser le SBOM pour localiser le problème dans le code, comprendre son impact et établir des priorités pour le corriger. Par exemple, TuxCare's SecureChain for Java de TuxCare de TuxCare fournit un SBOM détaillé pour chaque paquetage Java contrôlé et corrigé par le service, garantissant une transparence totale pour une prise de décision éclairée.
- Gestion des licences de logiciels : Avec un SBOM, les entreprises peuvent facilement suivre les licences des logiciels tiers et des logiciels libres. Les licences changent souvent, il est donc nécessaire de procéder à des vérifications régulières. Cela permet de s'assurer que l'entreprise n'enfreint aucun contrat de licence ou droit de propriété intellectuelle, évitant ainsi les problèmes juridiques et les risques financiers.
- Amélioration du cycle de vie du développement logiciel (SDLC) : Le SBOM rend plus efficace l'ensemble du processus de création, de déploiement et de maintenance des logiciels. Par exemple, les développeurs dressent la liste de toutes les dépendances logicielles dans un SBOM initial lorsqu'ils écrivent le code. Ce SBOM est mis à jour au cours des phases de test et de déploiement, à mesure que de nouvelles vulnérabilités et dépendances sont découvertes. Il avertit également les développeurs de tout problème survenant après l'utilisation du logiciel, garantissant ainsi des mises à jour et des améliorations continues.
L'avenir du SBOM
Le SBOM est particulièrement crucial pour les entreprises qui fournissent des logiciels aux entités gouvernementales, notamment dans des secteurs tels que la défense et l'aérospatiale. Toutefois, sa pertinence s'étend également à d'autres entreprises.
La récente recrudescence des attaques de la chaîne d'approvisionnementqui exploitent souvent les vulnérabilités des logiciels libres, souligne l'importance d'un examen rigoureux des composants, des bibliothèques et des cadres de travail des logiciels libres tiers. Ces attaques peuvent permettre à des acteurs malveillants de prendre le contrôle total des systèmes d'une entreprise, de perturber le fonctionnement d'un produit, d'introduire des logiciels malveillants et même de propager des virus à des clients et à d'autres organisations en interaction. L'impact imprévisible et potentiellement étendu de ces attaques en fait une menace importante.
Gartner prédit que, d'ici 2025, 60 % des organisations intégreront le SBOM dans leurs systèmes de sécurité. Cependant, bien qu'utile, le SBOM n'est pas une panacée pour les défis de la chaîne d'approvisionnement et de l'assurance logicielle, comme le reconnaît la NTIA. Il s'agit d'un outil parmi d'autres, et non d'une solution globale. L'efficacité des SBOM dépend de leur adoption généralisée, qui est toujours en cours, les normes et les exigences évoluant. Il faudra du temps pour parvenir à une utilisation universelle, compte tenu de la diversité émergente des outils et des normes en cours d'élaboration.
