Les progiciels modernes sont plus sécurisés qu’ils ne l’ont jamais été, grâce aux progrès des pratiques de cybersécurité. Cependant, ils sont également confrontés aux menaces les plus avancées, ce qui les rend tout aussi vulnérables que sécurisés. Attaques de la chaîne d'approvisionnement comme Solarwinds et de graves vulnérabilités comme Log4Shell font partie des dernières menaces auxquelles sont confrontés les systèmes logiciels aujourd'hui. Les attaques de la chaîne logistique logicielle comme celles-ci ont un effet dynamique et sont plus difficiles à gérer car elles exploitent les vulnérabilités des systèmes qui échappent à votre contrôle direct.
Cependant, la première étape pour lutter contre de telles attaques de la chaîne logistique logicielle consiste à avoir une connaissance claire des packages, des dépendances et des composants inclus dans votre logiciel. C'est pourquoi il est important de générer une nomenclature logicielle (SBOM) pour votre build. Non seulement il améliore la visibilité des vulnérabilités dans la chaîne d'approvisionnement des logiciels, mais un SBOM est également devenu important à des fins de conformité. La génération SBOM a été mandatée par un récent décret émis par le gouvernement fédéral américain pour renforcer la cybersécurité et garantir l’authenticité des composants tiers utilisés dans les progiciels.
D’après une Gartner Selon nos prédictions, 60 % des organisations chargées de développer des logiciels d'infrastructure critique auront besoin de SBOM standardisés d'ici 2025. La création d'un SBOM commence par la sélection d'un outil qui s'aligne sur les normes et les objectifs de votre organisation, en déterminant les phases du cycle de vie de la construction logicielle pendant lesquelles appliquez le SBOM, confirmez qu'il adhère au format et effectuez une analyse de vulnérabilité. Générer un SBOM est un processus délicat et compliqué. Cet article expliquera quand la génération SBOM est nécessaire et comment la générer pour votre logiciel.
Quand générer une nomenclature logicielle
La génération d'une nomenclature logicielle (SBOM) est essentielle pour sécuriser vos versions logicielles ainsi que l'ensemble de votre chaîne d'approvisionnement logicielle. La génération SBOM peut être intégrée à différentes étapes du processus de construction de votre logiciel. Vous pouvez générer une nomenclature à l'aide du code source pendant la phase de construction, pendant l'exécution ou lors d'une analyse approfondie du logiciel. Parmi tous ces éléments, les experts recommandent de générer un SBOM pendant la période de construction. En effet, les générateurs SBOM au moment de la construction sont plus précis et génèrent une liste de dépendances plus complète. Cependant, comme cela n'est pas toujours pratique, le SBOM peut être généré à tout autre moment du cycle de vie DevOps.
Il convient de noter que le type d'outil de génération SBOM à utiliser dépend de l'étape du cycle de vie DevOps à laquelle la documentation SBOM est générée. Voici les différentes étapes auxquelles les SBOM peuvent être générés au cours du cycle de vie de la build. Chaque période présente des avantages et des compromis différents. Il est préférable de comprendre le public cible et le cas d'utilisation des données SBOM que vous générez et de choisir une approche qui vous offre le meilleur résultat.
Au stade du code source
En examinant les artefacts et toutes les sources associées telles que les manifestes, les métadonnées et les fichiers de verrouillage, les outils sources ou binaires généreront une nomenclature logicielle au stade du code source. A ce stade, vous pouvez soit faire une analyse des composants logiciels, soit une analyse binaire de votre logiciel.
Un outil SCA (analyse des composants logiciels) est conçu pour analyser un logiciel et ses fichiers manifestes afin de déterminer ses composants. Les outils d'analyse binaire, quant à eux, analysent les métadonnées du logiciel et créent des informations sur les artefacts pour générer un SBOM. Des exemples d'outils d'analyse utilisés à ce stade incluent CycloneDX, It-Depends, Fossa, AppSonar, Cybellum, Black Duck et Fortress.
Vous pouvez utiliser un analyseur de vulnérabilité avec un SBOM généré au stade du code source pour recevoir des avertissements précoces de vulnérabilité dans le logiciel en cours de construction. Cependant, les SBOM générés à ce stade présentent des limites. D'une part, ils ne sont pas complets, car ceux générés lors de la construction avec dépendances sont souvent manquants. De plus, ils peuvent inclure des informations sur les composants qui n'ont pas été utilisés dans le produit final déployé.
Pendant la construction
La création du SBOM au moment de la construction avec un outil qui exploite le système de construction offre la connaissance la plus exacte de ce qui se passe dans un binaire, y compris les dépendances transitives et non épinglées. Ceci est soutenu par le Étude de la NTIA sur la production et la fourniture de SBOM par les fournisseurs de logiciels.
La NTIA recommande de créer un SBOM pour chaque nouvelle version de composant. Cela signifie créer un nouveau SBOM chaque fois que vous mettez à jour ou publiez une nouvelle version de votre logiciel. Les fournisseurs sont également tenus de créer de nouveaux SBOM chaque fois qu'ils découvrent une erreur dans la précédente ou apprennent de nouvelles informations sur leurs composants logiciels qui n'étaient pas documentées auparavant.
La génération de votre SBOM pendant la construction implique l'utilisation d'un plugin qui fonctionne avec l'environnement natif avec lequel vous créez votre logiciel. La plupart des environnements de développement disposent de plugins qui s'intègrent au système de gestion des dépendances pour générer automatiquement un SBOM. Des exemples de générateurs SBOM au moment de la construction incluent SPDX, le plugin CycloneDX Maven et Dependency-Track-Check d'OWASP.
Bien que les générateurs SBOM au moment de la construction soient les plus complets et les plus précis, ils sont plus difficiles à configurer que les autres méthodes. De plus, cette méthode ne fonctionne pas pour certains systèmes de build et vous ne pouvez pas l'utiliser pour les produits existants.
Génération de SBOM pendant l'exécution
Un générateur SBOM qui fonctionne pendant l'exécution est conçu pour capturer les bibliothèques que le logiciel, le serveur d'applications ou les plugins utilisent pendant l'exécution. Ce type de générateur détaille également tous les services appelés par le logiciel ainsi que les ports et bibliothèques actives auxquels il accède. Cependant, cette méthode de génération de SBOM n’est pas largement disponible. De plus, il n'existe pas de flux de travail clair pour fusionner les données générées à l'aide de cette méthode avec la documentation SBOM d'origine. Jbom et ThreatMapper sont des exemples de générateurs SBOM d'exécution.
Comment générer une nomenclature logicielle : un guide étape par étape
La génération manuelle d'une nomenclature logicielle prend du temps et est fastidieuse pour les développeurs. Répertorier tous les composants d’un logiciel de cette manière est pour la plupart peu pratique. Cependant, de nombreux outils de génération SBOM sont désormais disponibles pour simplifier ce processus. La manière de procéder dépend des normes de votre organisation et du moment où vous souhaitez générer votre SBOM pendant le cycle de vie de développement.
En intégrant les workflows SBOM dans les pipelines de création de logiciels, vous pouvez automatiser le processus SBOM. La plateforme Scribe est l'un de ces outils qui simplifie la façon dont vous créez votre nomenclature logicielle. Scribe vous permet de gérer et de partager votre SBOM à partir d'un seul endroit. De cette façon, vous pouvez valider l’intégrité de vos composants logiciels et suivre les vulnérabilités dans le pipeline logiciel de manière transparente. Cette section est un guide étape par étape pour générer des nomenclatures logicielles avec Scribe.
Étape 1 : Inscrivez-vous et connectez-vous à Scribe Trust Hub.
Avant de commencer, sachez que la plateforme Scribe dispose d'une interface web – Scribe Trust Hub – accessible depuis votre navigateur. Cependant, le collecteur de preuves Scribe ne fonctionne que sur les appareils Linux et Mac. Pour générer un rapport d'intégrité et un SBOM avec Scribe, vous devez avoir l'autorisation de modifier le script de construction de votre projet et d'ajouter l'extrait de code pertinent nécessaire pour connecter votre projet à Scribe. Gardez à l'esprit que même si Scribe peut générer des SBOM pour des projets écrits dans n'importe quel langage de programmation générant une image de conteneur, la version actuelle ne fonctionne que pour les projets Node.js.
La première étape pour intégrer Scribe dans votre projet est de vous inscrire sur Scribe Trust Hub. Une fois inscrit et connecté, accédez à l’onglet « Produits » et cliquez sur Configuration. Scribe propose un produit de démonstration sur cette page, avec lequel vous pouvez interagir pour comprendre la plateforme et son fonctionnement.
Étape 2 : Intégrer Scribe Trust Hub
L'étape suivante consiste à connecter Scribe au pipeline d'intégration continue de votre projet. Cela automatise le processus de génération SBOM. Généralement, vous pouvez ajouter des extraits de code de Scribe Trust Hub en deux points de votre pipeline CI. Vous pouvez placer le code lors de l'extraction du code source ou dans l'image finale construite. La première option est recommandée mais pas obligatoire, tandis que la seconde est obligatoire.
La configuration CI de Scribe ne fonctionne actuellement que pour Jenkins sur Kubernetes et GitHub Actions. Le processus d'intégration de Scribe pour ces configurations CI est similaire. Vous devrez obtenir les informations d'identification suivantes sur la page de configuration de votre produit Scribe Hub pour commencer :
- Clé de produit
- identité du client
- Secret client
La clé de produit varie d'un produit à l'autre, tandis que les informations d'identification client sont uniques à votre compte.
Configuration de l'intégration CI pour Jenkins
Pour configurer les intégrations CI pour Jenkins, vous pouvez ajouter l'extrait de code pour appeler « Gensbom » (l'outil de Scribe Trust Hubs pour collecter des preuves et générer des SBOM) au point de paiement et/ou après avoir créé une image Docker.
Commencez par ajouter les informations d'identification ci-dessus à votre environnement de build conformément aux instructions uniques pour Jenkins. Ensuite, ajoutez l'extrait de code à votre pipeline selon les instructions ici.
Configuration de l'intégration CI pour les actions GitHub
Le processus de configuration de l'intégration CI pour GitHub Actions est similaire à celui de Jenkins. L'idée principale est d'appeler le collecteur de preuves et le générateur SBOM de Scribe « Gensbom ». Pour commencer, suivez les Instructions GitHub pour ajouter les informations d'identification de configuration du produit et l'extrait de code au pipeline conformément aux instructions ici
Intégration de Scribe Trust Hub avec d'autres systèmes CI
Bien que Scribe n'offre qu'une prise en charge native des actions Jenkins et GitHub, vous pourrez également l'utiliser pour d'autres systèmes CI. Pour commencer, téléchargez l'outil « Gensbom » à partir de votre interface de ligne de commande basée sur Unix. Ensuite, ajoutez votre produit et les informations d'identification du client, puis appelez Scribe gensbom à partir de votre script de construction, soit lors du paiement, soit après l'image finale construite.
Étape 3 : Génération de la nomenclature du logiciel
L'outil CLI gensbom de Scribe génère la nomenclature logicielle (SBOM) pour Docker et Open Containers Images (OCI). Cet outil ne fonctionne que sur les systèmes Mac ou Linux. Le SBOM final généré par Scribe est au format CycloneDX JSON, qui est l'une des machines standard et des formats lisibles par l'homme reconnus pour les SBOM. Les images du conteneur ouvert peuvent être extraites de Docker, d'un disque local ou d'un registre distant, selon le cas.
Bien qu'il existe des paramètres par défaut pour le nom, le répertoire et le chemin de l'image à partir de laquelle le SBOM est généré, il est possible de modifier ces paramètres par défaut en conséquence si vous le souhaitez.
Étape 4 : Exporter le SBOM
Scribe Trust Hub vous permet également d'exporter et de partager votre nomenclature logicielle de manière transparente dans le cadre du processus de validation de votre logiciel. Le SBOM est généré au format de rapport CycloneDX JSON et détaille toutes les dépendances open source de l'image Docker analysée. Une fois le SBOM généré, vous pouvez l'exporter en un clic. Vous trouverez le bouton « Exporter SBOM » dans le coin supérieur droit du rapport. Cliquez dessus pour exporter vos nomenclatures logicielles.
Conclusion
La génération d'une nomenclature logicielle devient une étape de plus en plus vitale pour sécuriser votre chaîne d'approvisionnement logicielle et également à des fins de conformité. Quelles que soient les raisons pour lesquelles vous avez généré un SBOM, Scribe Trust Hub constitue un moyen facile à utiliser et flexible d'automatiser le flux de travail de génération de SBOM pour chacune de vos versions logicielles.