Les versions GitHub sont l'endroit où les SBOM vont mourir.
23 mars 2025
Interlynk
Aperçu
Salut à tous 👋, passionnés de SBOM ! Depuis le décret exécutif sur la cybersécurité de 2021 par Joe Biden. Les SBOM (Software Bill of Materials) sont devenus essentiels pour la sécurité et la conformité logiciel. Avec des pays comme l'UE, les États-Unis, l'Allemagne, et l'Inde introduisant leurs propres régulations SBOM, il est clair :
Les SBOM ne sont plus optionnels - ils sont le nouveau standard.
Pour répondre à cette demande, des outils pour la génération, la signature, l'analyse de qualité, l'enrichissement, et l'intégration des SBOM dans les plateformes de sécurité ont rapidement évolué, principalement grâce à la communauté open-source.
Le défi de transfert SBOM
Une fois généré, un SBOM doit généralement être téléchargé manuellement, téléchargé et intégré dans les outils de sécurité, nécessitant une intervention humaine à plusieurs étapes.
Cette approche est :
❌ Chronophage – Le téléchargement et le téléchargement répétés des SBOM consomment un temps précieux
❌ Susceptible aux erreurs – La manipulation manuelle augmente le risque d'erreurs.
❌ Démodé – À une époque d'automatisation, compter sur des flux de travail manuels ne scale tout simplement pas.
La méthode manuelle est devenue démodée dans le monde de l'automatisation.
Cette inefficacité est un goulot d'étranglement majeur pour les équipes de sécurité et ralentit la gestion des risques de la chaîne d'approvisionnement logicielle.
Transfert d'SBOM sans couture utilisant sbommv
Chez Interlynk, nous avons conçu sbommv pour permettre des transferts SBOM sans couture entre les systèmes. Son architecture modulaire prend en charge les adaptateurs d'entrée et de sortie, ainsi que la traduction et l'enrichissement, garantissant flexibilité et adaptabilité. Ce design rend sbommv hautement extensible, facilitant l'intégration avec des systèmes supplémentaires à l'avenir.
Élimine le travail manuel – Fini le téléchargement, le téléversement ou la gestion fastidieuse des fichiers.
Intégration sans effort et sans couture – Déplace sans effort les SBOMs entre plateformes avec un minimum de configuration.
Scalable et prêt pour l'avenir – S'adapte aux besoins évolutifs en matière de sécurité et de conformité.
🚀 Avec sbommv, les SBOMs circulent de la source à la destination sans aucun effort manuel—éliminant l'intervention humaine et s'alignant parfaitement avec l'approche moderne axée sur l'automatisation.
Scénario du monde réel
De nombreux projets logiciels publient des SBOM sur GitHub, aux côtés de binaires, archives, exécutables et signatures. Les artefacts SBOM sont également appelés artefacts numériques.
Une fois qu'un SBOM est généré, il doit être transféré vers des plateformes de gestion des SBOM telles que Dependency-Track, Interlynk et d'autres outils de sécurité pour une analyse plus approfondie, des évaluations de vulnérabilités et un suivi de la conformité. Cependant, ce processus est souvent manuel et inefficace. Les équipes de sécurité ou les ingénieurs doivent généralement localiser, télécharger et télécharger les SBOM manuellement, ce qui ajoute une surcharge inutile et augmente le risque d'erreurs.
Ce flux de travail obsolète implique :
1️⃣ Rechercher manuellement des SBOM dans les versions GitHub ou d'autres dépôts.
2️⃣ Télécharger et re-télécharger ces derniers sur des plateformes de gestion des SBOM pour traitement.
3️⃣ Répéter ce processus pour chaque version logiciel, à travers plusieurs dépôts—ce qui entraîne une perte de temps et des incohérences potentielles.
Ce flux de travail manuel est répandu dans les projets open-source, les entreprises, et les secteurs réglementés, où la sécurité des logiciels et la conformité sont critiques. À mesure que le développement logiciel s'accélère et que les cycles de publication se raccourcissent, la fréquence de génération des SBOM augmente. S'appuyer sur des transferts manuels de SBOM n'est plus pratique—les organisations ont besoin d'une approche évolutive et automatisée pour suivre le rythme.
Pour relever ce défi, explorons un guide pratique pour transférer efficacement des SBOM entre systèmes via sbommv...
sbommv en action 🚀
Installation
Si vous recherchez des méthodes d'installation alternatives, vous pouvez suivre ce guide.
Prise en main avec sbommv
Avant de transférer des SBOMs de Github à Dependency-Track, assurez-vous que vous avez installé et en cours d'exécution. Pour des étapes d'installation détaillées de Dependency-Track, consultez l' [Annexe](Annexe : Configuration de Dependency-Track) dans la section inférieure.
Nous avons terminé la configuration des prérequis pour sbommv. Libérons la puissance de sbommv…
1. Transfert automatisé de SBOM de GitHub à Dependency-Track
C'est le moyen le plus simple et le plus automatisé de gérer les SBOMs avec un effort utilisateur minimal. Il tire parti de l'API GitHub pour extraire automatiquement le SBOM pour la dernière branche principale, car GitHub permet d'exporter le SBOM pour un dépôt.
NOTE : Activer l'exportation SBOM via l'API Dependency Graph
Exécutez la commande suivante pour récupérer le SBOM du dépôt sbommv et le déplacer vers Dependency-Track :
Après exécution :
Le SBOM est récupéré --> converti en CycloneDX --> téléversé vers Dependency-Track.
Si le projet n'existe pas, il est auto-créé dans Dependency-Track. Il est créé avec le nom interlynk-io/sbommv-latest
Avec la création du projet, il ajoute description et tags. La description est ajoutée sous la forme - "Créé & téléversé par sbommv" et les tags comme "github" et "sbommv".
Avantages & Inconvénients de l'utilisation de la méthode API GitHub pour le transfert SBOM
Comme GitHub permet d'exporter des SBOMs manuellement ou via son API Dependency Graph, cela en fait une source pratique de SBOM.
✅ Avantages
✔️ Complètement automatisé – Élimine le besoin de générer et de transférer manuellement des SBOMs.
✔️ Maintient les projets à jour – Synchronise automatiquement avec Dependency-Track, garantissant que le dernier SBOM est toujours disponible.
✔️ Le moyen le plus rapide de commencer, sans utiliser d'outils pour la génération de SBOM.
❌ Inconvénients
⚠️ Limité à la branche principale – L'API GitHub fournit uniquement des SBOMs pour la branche par défaut, ce qui signifie qu'elle manque de visibilité sur les versions passées ou les versions spécifiques.
⚠️ Aucun instantané historique – Elle ne capture pas les SBOMs pour les versions précédentes du logiciel, ce qui peut être crucial pour des audits de conformité ou de sécurité.
Méthodes alternatives GitHub pour des workflows SBOM plus avancés
Pour les équipes ayant besoin d'un contrôle accru sur l'extraction de SBOM, sbommv prend en charge d'autres méthodes GitHub au-delà de l'approche API :
Méthode basée sur les versions – Récupère tous les SBOMs des versions GitHub, garantissant que l'historique des versions est capturé.
Méthode basée sur l'outil – Clone le dépôt et génère des SBOMs frais en utilisant des outils comme Syft, fournissant une facture logicielle plus complète.
Ces options permettent d'avoir des informations plus approfondies, un meilleur suivi des versions, et une gestion SBOM plus complète au-delà de ce que l'API GitHub seule peut offrir.
2. Téléversement de SBOMs préexistants d'un dossier à Dependency-Track
Dans les cas où les SBOMs sont déjà stockés localement, sbommv peut les transférer facilement d'un Dossier à Dependency-Track
Pour démontrer cela, peuplons un dossier local avec des SBOMs. Nous allons télécharger tous les SBOMs depuis le dépôt GitHub sbomqs via la version GitHub méthode, en veillant à récupérer la dernière version disponible.
Fig : SBOMs récupérés depuis la page de version du dépôt "sbomqs" & sauvegardés dans le dossier "demo" localement
Maintenant que nous avons une collection de SBOMs dans notre dossier local demo, la prochaine étape consiste à les transférer sans problème à Dependency-Track en utilisant sbommv.
Exécutez la commande suivante pour téléverser tous les SBOMs du dossier local demo vers Dependency-Track :
Fig : téléversement de SBOMs depuis le dossier demo vers DTrack
Fig : SBOMs téléversés vers DTrack avec le nom du projet comme "version principale comp"
Après exécution :
Seuls les fichiers SBOM valides sont détectés et téléversés.
Les SBOMs SPDX 2.2 sont automatiquement mis à niveau vers SPDX 2.3 avant d'être convertis en CycloneDX, maintenant la compatibilité avec l'acceptabilité de Dependency-Track.
Crée automatiquement le nom du projet en utilisant le nom et la version du composant principal du SBOM.
3. Mode Dry-Run (Fonctionnalité optionnelle)
Avant d'exécuter un transfert de SBOM, sbommv offre un mode dry-run, permettant aux utilisateurs de prévisualiser quels SBOMs seront traités—sans effectuer de changements réels. Cette fonctionnalité aide à vérifier les transferts pour les sources SBOM basées sur GitHub et basées sur un dossier.
Prévisualisation d'un transfert de GitHub à Dependency-Track
Pour vérifier quels SBOMs seront transférés d'un dépôt GitHub à Dependency-Track, exécutez :
Fig : mode dry-run pour prévisualiser le transfert de GitHub à Dependency-Track
Affiche la liste des SBOMs qui seraient récupérés ainsi que leurs formats.
Assure que les noms de projet et les formats sont correctement identifiés avant l'exécution.
Nombre total de SBOMs récupérés.
Prévisualisation d'un transfert de dossier à Dependency-Track
Pour vérifier les SBOMs stockés dans un dossier local avant de les transférer à Dependency-Track, exécutez :
Fig : mode dry-run pour prévisualiser le transfert de dossier à Dependency-Track
Liste les fichiers SBOM valides détectés dans le dossier.
Confirme le format, le nom du projet avec lequel il sera téléversé à DTrack, la version de spécification et le nom de fichier.
Total de SBOMs à téléverser.
Le mode dry-run aide à prévenir les erreurs et à valider les transferts avant exécution, ce qui en fait une fonctionnalité utile pour garantir une gestion fluide des SBOM.
Jusqu'à présent, nous avons couvert deux scénarios clés de l'industrie :
1️⃣ Génération et transfert automatisés de SBOM – Récupération des SBOMs directement depuis GitHub et intégration sans heurts dans Dependency-Track.
2️⃣ Téléversement de SBOMs préexistants – Transfert des SBOMs stockés localement d'un dossier à Dependency-Track tout en garantissant la compatibilité des formats et l'organisation des projets.
Ces workflows démontrent comment sbommv optimise le mouvement des SBOM, réduisant l'effort manuel et garantissant que les SBOMs sont toujours disponibles pour l'analyse de sécurité et de conformité.
Travail futur : Quelles sont les prochaines étapes pour sbommv ?
Nous commençons tout juste ! 🚀 Voici ce qui arrive ensuite :
Surveillance des Dossiers – Au lieu de déclencher manuellement les transferts SBOM, sbommv surveillera en continu les répertoires et téléchargera automatiquement les nouveaux SBOM au fur et à mesure qu'ils apparaissent. Restez à l'écoute—cette fonctionnalité sera lancée la semaine prochaine 🚀 avec un accompagnement sur la plateforme Interlynk !
Support Élargi pour les Entrées & Sorties – Nous ajoutons la prise en charge des buckets S3, des outils de sécurité supplémentaires, et d'autres formats SBOM, rendant sbommv encore plus polyvalent.
Traitement Avancé des SBOM – Des améliorations sont en cours, y compris de meilleures conversions de formats SBOM, une validation améliorée, et des journaux détaillés pour une meilleure visibilité sur les transferts SBOM.
Si vous trouvez sbommv utile, montrez votre soutien en donnant une ⭐ au dépôt sur GitHub. Vos retours et contributions aident à orienter son développement futur !
Avez-vous une demande de fonctionnalité ? Ouvrez un problème sur notre dépôt GitHub—nous serions ravis d'entendre vos idées ! 🚀
Conclusion
Le transfert manuel des SBOM n'est plus une approche viable, surtout que les exigences en matière de sécurité de la chaîne d'approvisionnement logiciel et de conformité continuent d'évoluer. Les flux de travail inefficaces ne gaspillent pas seulement du temps mais introduisent également des risques pouvant compromettre la sécurité. L'automatisation est la seule solution évolutive.
Avec sbommv, le mouvement des SBOM est sans faille—que ce soit en tirant directement de GitHub ou en transférant des SBOM préexistants depuis des dossiers locaux vers Dependency-Track. En éliminant la gestion manuelle, les organisations peuvent s'assurer que les SBOM sont toujours à jour, intégrés dans les outils de sécurité, et facilement accessibles pour l'analyse.
Le passage à la gestion automatisée des SBOM n'est pas juste une commodité—c'est une nécessité.
"Commencez à utiliser sbommv aujourd'hui et apportez l'automatisation à votre cycle de vie des SBOM
— car la sécurité ne se développe pas manuellement."
Références & Ressources
🔹 Dépôt GitHub sbommv – [Lien GitHub]
🔹 Documentation de Dependency-Track – [Lien Docs DT] et [Lien Github]
🔹 SPDX & Spécification CycloneDX – [Lien SPDX] | [Lien CycloneDX]
🔹 Site Officiel d'Interlynk – [Lien du site]
🔹 Projets OSS d'Interlynk – [Lien Github]
🔹sbommv [guide de démarrage] et [exemples]
Annexe : Configuration de Dependency-Track
Exécutez Dependency-Track localement sur votre système en utilisant docker
Visitez http://localhost:8080
Connectez-vous avec les identifiants par défaut :
Maintenant, changez votre mot de passe.
Enfin, vous êtes arrivé sur la page d'accueil de la plateforme Dependency-Track.
Créons un jeton DTRACK_API_KEY, qui est requis pour accéder à la plateforme.
Sur le côté gauche, allez à Administration --> Gestion des Accès --> Équipes --> cliquez sur Administrateur --> copiez les clés API ci-dessous, quelque chose comme ceci :
Maintenant, exportez ce jeton dans votre CLI, avant d'exécuter sbommv.