Le développement de Software repose en grande partie sur l'utilisation de composants tiers préconstruits pour rationaliser les processus, dont certains sont open source. Ces composants sont les éléments constitutifs des applications web modernes, mais ils peuvent également introduire des vulnérabilités, offrant aux cybercriminels des points d'entrée potentiels dans votre système.
Pour avoir une visibilité sur les composants et gérer les vulnérabilités des dépendances de votre logiciel, la tenue d'une liste appelée SBOM (software bill of materials) est essentielle pour renforcer la sécurité, la gestion des risques et la conformité de votre application.
Qu'est-ce que le SBOM ?
A Software Bill of Materials (SBOM) est un inventaire détaillé de tous les composants, bibliothèques et dépendances fermés et libres utilisés dans une application. En termes plus simples, tout comme un produit physique peut être accompagné d'une liste de composants et de matériaux, un logiciel a également ses composants.
Les développeurs et les vendeurs construisent souvent des logiciels en combinant du code open-source et du code commercial. Le SBOM détaille systématiquement ces composants afin de garantir la transparence et la traçabilité des composants de code fondamentaux dans les produits logiciels, ce qui contribue à faciliter la sécurité de la chaîne d'approvisionnement et à garantir la conformité avec les réglementations.
Quels sont les avantages d'un SBOM ?
Au fond, un SBOM offre trois avantages principaux :
Transparence
Il offre une vue claire de la composition du logiciel, permettant aux parties prenantes - qu'il s'agisse de développeurs, d'auditeurs ou d'utilisateurs finaux - de comprendre les composants qui entrent dans la composition de leur pile logicielle.
Vulnerability Management
La sécurité est l'une des préoccupations les plus pressantes en matière de développement de logiciels. Un SBOM permet de localiser rapidement les composants d'un logiciel, ce qui facilite l'identification, le traitement et la correction des vulnérabilités.
Lorsqu'un avis de sécurité est publié, il contient généralement des informations actualisées sur les vulnérabilités des composants logiciels. En croisant un SBOM avec les derniers avis de sécurité, les entreprises peuvent rapidement déterminer si leurs applications sont à risque et prendre les mesures d'atténuation nécessaires pour garantir leur sécurité.
Intégration dans le SDLCSoftware Development Lifecycle)
Au fur et à mesure que le logiciel progresse dans le pipeline de développement, il est continuellement mis à jour, depuis la conceptualisation et la conception jusqu'au déploiement et à la maintenance. Un SBOM est un enregistrement dynamique qui garantit une image claire des composants, des dépendances et des relations du logiciel à chaque étape du SDLC.
Qui a besoin d'un SBOM ?
D'une manière générale, un consommateur de logiciels peut être n'importe quelle entité, commerciale ou non, qui se procure ses composants et utilitaires logiciels tiers auprès de fournisseurs. Ces fournisseurs couvrent un large spectre :
- Éditeurs de logiciels commerciaux
- Développeurs de logiciels contractuels fournissant des composants logiciels
- Fournisseurs de Software libres et open-source (FOSS) gestion du code dans des dépôts ouverts ou gestionnaire de paquets
En particulier, ces fournisseurs ont plusieurs casquettes. Ils peuvent être fabricants, développeurs, responsables de la maintenance ou fournisseurs. Dans l'idéal, ces entités devraient également créer des SBOM pour leurs capacités logicielles. Une distinction unique à retenir est que la plupart des fournisseurs sont également des consommateurs. Toutefois, un fournisseur qui n'a pas de composants en amont est généralement considéré comme une entité racine.
Le SBOM dans le secteur public
Les agences fédérales jouent un rôle central dans l'adoption et l'application des normes du SBOM. Leur surveillance ne consiste pas seulement à établir des critères de référence, mais aussi à garantir la conformité à ces critères dans l'intérêt général. Publié en mai 2021, l'ordre exécutif américain 14028 charge plusieurs agences aux compétences étendues, dont le NIST (National Institute of Standards and Technology), de renforcer la cybersécurité par le biais de diverses initiatives liées à la sécurité et à l'intégrité de la chaîne d'approvisionnement en logiciels.
La section 10 (j) de l'Executive Order 14028 définit un SBOM comme un "enregistrement formel contenant les détails et les relations de la chaîne d'approvisionnement des divers composants utilisés dans la construction d'un logiciel". Les SBOM sont susceptibles d'accroître la transparence, la provenance et la rapidité avec laquelle les vulnérabilités peuvent être identifiées et corrigées par les ministères et les agences fédérales.
Types de SBOM et définitions
Selon l'étape de développement et de déploiement du logiciel, différents types de SBOM sont générés, chacun ayant un objectif unique et offrant des informations distinctes sur les composants du logiciel. Voici six types de documents SBOM courants.
Conception
À ce stade du développement de l'application, il se peut que certains composants n'existent même pas encore. Ce type de SBOM est généralement dérivé d'une spécification de conception, d'un appel d'offres (RFP) ou d'un concept initial.
Source
Formé directement à partir de l'environnement de développement, il donne un aperçu des fichiers sources et des dépendances nécessaires à la construction d'un artefact de produit. Il est généralement généré par un outil d'analyse de la composition du logiciel (SCA) et nécessite parfois des clarifications manuelles.
Construire
Produit dans le cadre du processus de construction du logiciel, il consolide les données provenant des fichiers sources, des composants construits et d'autres dépendances. Il est d'autant plus précieux qu'il est généré lors de la création d'un artefact logiciel publiable.
Analysé
Ce SBOM est dérivé de l'analyse post-construction des artefacts logiciels, tels que les exécutables ou les images de machines virtuelles. Il fait appel à diverses heuristiques et est parfois appelé SBOM "tiers".
Déployé
Inventaire exhaustif des logiciels présents sur un système. Généré par la documentation du SBOM des composants logiciels installés sur les systèmes, il donne un aperçu du déploiement réel des logiciels.
Quels sont les éléments d'un SBOM ?
Selon la NTIA (National Telecommunications and Information Administration), les éléments minimaux d'un SBOM comprennent le nom du fournisseur du logiciel, les composants, leurs versions, les identifiants uniques, la relation des dépendances, l'auteur des données du SBOM et l'horodatage. En outre, les données du SBOM doivent contenir les éléments suivants pour être efficaces et complètes :
- Champs de données : Les champs de données doivent être clairement définis et préciser le nom, les versions et les attributs des composants du logiciel. Cela garantit que chaque partie prenante comprend parfaitement la composition du logiciel.
- Soutien à l'automatisation : Compte tenu de la nature dynamique du développement de logiciels, un SBOM doit pouvoir être automatiquement mis à jour et intégré dans les processus de développement et de déploiement de logiciels. Cela garantit la précision et l'efficacité en temps réel.
- Pratiques et processus : Au-delà de la simple énumération des composants, un SBOM doit être intégré dans les meilleures pratiques et processus qui régissent sa création, sa maintenance et son utilisation.
Formats du SBOM
Les formats SBOM les plus courants sont les suivants
- SPDXSoftware Package Data Exchange) - développé par la Fondation Linux
- CycloneDX - couramment utilisé pour la sécurité des applications
- SWIDSoftware Identification Tagging) - Défini par ISO/IEC 19770-2
En cataloguant chaque composant, un SBOM permet aux organisations d'identifier clairement les licences associées à chaque logiciel, ce qui leur permet de rester en conformité avec les conditions de licence et d'éviter les pièges juridiques potentiels.
Restez conforme et Secure dans votre SDLC
En raison des attaques croissantes de la chaîne d'approvisionnement, le gouvernement fédéral et le secteur privé reconnaissent l'importance de l'identification des logiciels. Un SBOM est essentiel pour détailler les composants logiciels, en particulier les composants tiers. Les données du SBOM aident à prévenir les vulnérabilités et garantissent la transparence dans la création du SBOM. Chaque logiciel devrait inclure un SBOM complet afin de renforcer les mesures de sécurité.
En cataloguant chaque composant, un SBOM permet aux organisations d'identifier clairement les licences associées à chaque logiciel, ce qui leur permet de rester en conformité avec les conditions de licence et d'éviter les pièges juridiques potentiels.
Avec OPSWAT OM, les développeurs peuvent identifier les vulnérabilités connues, valider les licences et générer un inventaire des composants pour les logiciels libres, les dépendances tierces et les conteneurs. Pour en savoir plus sur la sécurisation de votre chaîne d'approvisionnement en logiciels avec des solutions SBOM robustes, visitez la solution Sécurité deSupply Chain Software OPSWAT.
