devops-kung-fu/bomberAnalyse les Software Bills of Materials (SBOM) pour les vulnérabilités de sécurité
bomber est une application qui analyse les SBOM pour détecter les vulnérabilités de sécurité.
Vous avez donc demandé à un fournisseur une nomenclature logicielle (SBOM) pour l'un de ses produits propriétaires, et il vous en a fourni une dans un fichier JSON… et maintenant ?
La première chose à faire est de vérifier si certains des composants listés dans le SBOM présentent des vulnérabilités de sécurité, et quels types de licences ces composants ont. Cela vous aidera à identifier le risque que vous prenez en utilisant ce produit.
Trouver les vulnérabilités de sécurité et les informations de licence pour les composants identifiés dans un SBOM, c'est exactement ce que bomber est conçu pour faire. bomber peut lire tout format JSON ou XML basé sur CycloneDX, ou un SBOM au format JSON SPDX ou Syft, et vous dire assez rapidement s'il y a des vulnérabilités.
Le logiciel peut être open source ou propriétaire. Vous pouvez considérer les composants tiers que vous trouvez sur GitHub ou tout dépôt public comme open source. Techniquement, le logiciel que vous créez en interne dans votre entreprise est aussi open source – il n'est pas public, mais vos équipes internes peuvent le voir. Le logiciel propriétaire peut aussi être interne, mais il s'agit généralement de logiciels que vous achetez auprès de fournisseurs externes.
Les entreprises peuvent utiliser des outils SCA fournis par des vendeurs tels que GitHub, Sonatype, Snyk, etc., pour analyser tout type d'open source et fournir des données de vulnérabilité – et même générer des SBOM dans certains cas. Ce qu'ils ne peuvent pas faire (pour l'instant…) c'est analyser un logiciel propriétaire auquel vous n'avez pas accès. C'est là que les SBOM et bomber entrent en jeu. Les SBOM fournissent la composition de logiciels auxquels vous ne pouvez pas accéder, et bomber détermine si quelque chose dans le SBOM présente des vulnérabilités.
Nous avons créé bomber pour analyser les SBOM propriétaires que vous recevez de vos fournisseurs. Il peut aussi analyser les SBOM open source, et techniquement vous pourriez utiliser bomber comme un outil SCA open source si vous le souhaitez.
Il existe plusieurs formats SBOM aujourd'hui. bomber supporte les suivants :
bomber supporte plusieurs sources d'informations sur les vulnérabilités. Nous appelons ces sources fournisseurs. Actuellement, bomber utilise OSV comme fournisseur par défaut, mais vous pouvez aussi utiliser la Base de données d'avis GitHub, l'Index OSS de Sonatype, ou Snyk.
Veuillez noter qu'à l'heure actuelle, OSV est gratuit et ne nécessite aucun identifiant, l'Index OSS de Sonatype est gratuit mais nécessite de s'inscrire et d'obtenir un jeton, et le support de Snyk nécessite une licence Snyk.
En plus des données que bomber collecte auprès des fournisseurs, il enrichit également les données de vulnérabilité avec des informations supplémentaires comme les probabilités d'exploitation.
Veuillez noter que chaque fournisseur supporte des écosystèmes différents, donc si vous ne voyez aucune vulnérabilité avec l'un, essayez un autre. Un écosystème est simplement le gestionnaire de paquets ou le type de paquet. Par exemple : rpm, npm, gems, etc. Il est important de comprendre que chaque fournisseur peut signaler des vulnérabilités différentes. En cas de doute, regardez-en plusieurs.
Si bomber ne trouve aucune vulnérabilité, cela ne signifie pas qu'il n'y en a pas. Cela signifie simplement que le fournisseur utilisé n'en a pas détecté, ou qu'il ne supporte pas l'écosystème. Certains fournisseurs renvoient des vulnérabilités sans information de sévérité. Dans ce cas, la sévérité sera indiquée comme "UNDEFINED".
La documentation des fournisseurs pour bomber se trouve ici :
Vous pouvez utiliser Homebrew pour installer bomber en utilisant les commandes suivantes :
brew tap devops-kung-fu/homebrew-tap
brew install devops-kung-fu/homebrew-tap/bomber
Si vous n'avez pas Homebrew, vous pouvez toujours télécharger la dernière version (ex : bomber_0.4.1_darwin_all.tar.gz), extraire les fichiers de l'archive et utiliser le binaire bomber.
Si vous le souhaitez, vous pouvez déplacer le binaire bomber dans votre répertoire /usr/local/bin ou n'importe où dans votre PATH.
Pour installer bomber, téléchargez la dernière version pour votre plateforme et installez-la localement. Par exemple, installez bomber sur Ubuntu :
dpkg -i bomber_0.5.0_linux_arm64.deb
Vous pouvez analyser soit un dossier complet de SBOM, soit un SBOM individuel avec bomber. bomber ne se soucie pas si vous avez plusieurs formats dans un seul dossier. Il triera tout pour vous.
Notez que la sortie par défaut de bomber se fait sur STDOUT. Les options pour sortir en HTML ou JSON sont décrites plus loin dans ce document.
# Utilisation d'OSV (le fournisseur par défaut) qui ne nécessite aucun identifiant
bomber scan cyclonedx.sbom.json
# Utilisation d'un fournisseur nécessitant des identifiants (ossindex)
bomber scan --provider=xxx --username=xxx --token=xxx [sbom.json]
Si le fournisseur trouve des vulnérabilités, vous verrez une sortie similaire à celle-ci :
Si le fournisseur ne renvoie aucune vulnérabilité, vous verrez un message indiquant qu'aucune vulnérabilité n'a été trouvée.
REMARQUE : Le fait qu'aucune vulnérabilité n'ait été trouvée avec un fournisseur donné ne signifie pas qu'il n'y a pas de vulnérabilités. Veuillez essayer les autres fournisseurs supportés par bomber.
C'est utile lorsque vous recevez plusieurs SBOM d'un fournisseur pour le même produit. Ou peut-être voulez-vous connaître les vulnérabilités présentes dans toute votre organisation. Une analyse de dossier trouvera tous les composants, les dédoublonnera, puis les analysera pour détecter les vulnérabilités.
# analyse d'un dossier de SBOM (la commande suivante analysera un dossier nommé "sboms" dans votre répertoire courant)
bomber scan --provider=xxx --username=xxx --token=xxx ./sboms
Vous obtiendrez un résultat similaire à celui d'une analyse d'un seul SBOM.
bomber produit des données dans trois formats utiles. Par défaut, la sortie est affichée dans la ligne de commande. Pour des rapports améliorés, vous pouvez sortir en HTML en utilisant le flag --output=html. Pour sortir en JSON, utilisez le flag --output=json. Utilisez une spécification de sortie séparée par des virgules pour obtenir une sortie dans plusieurs formats : --output=html,stdout,json.
Si vous souhaitez un rapport lisible généré avec des informations détaillées sur les vulnérabilités, vous pouvez utiliser le flag --output pour enregistrer un rapport dans un fichier HTML.
Exemple de commande :
bomber scan bad-bom.json --output=html
Cela enregistrera un fichier dans votre dossier courant au format "YYYY-MM-DD-HH-MM-SS-bomber-results.html". Si vous ouvrez ce fichier dans un navigateur web, vous verrez une sortie comme celle-ci :
bomber peut produire des données de vulnérabilité au format JSON en utilisant le flag --output. La sortie par défaut se fait sur STDOUT. Il y a beaucoup plus d'informations dans la sortie JSON que ce qui est affiché dans le terminal. Vous pourrez voir une description du paquet et son objectif, le nom de la vulnérabilité, un résumé de la vulnérabilité, et plus encore.
Exemple de commande :
bomber scan bad-bom.json --output=json > filename.json
bomber supporte également la sortie au format Markdown. C'est très similaire à la sortie HTML, mais laisse le style au rendu Markdown, comme celui de GitHub. La sortie est enregistrée dans un fichier au format "YYYY-MM-DD-HH-MM-SS-bomber-results.md".
Exemple de commande :
bomber scan bad-bom.json --output=md
Si nécessaire, vous pouvez utiliser le flag --ignore-file pour charger une liste de CVE à ignorer dans la sortie des vulnérabilités. Cette liste doit être dans un format spécifique où chaque CVE à ignorer est inscrit sur une ligne séparée, comme suit :
CVE-2022-31163
CVE-2022-23520
Un exemple de fichier bomber.ignore est disponible ici
Pour utiliser le fichier bomber.ignore, utilisez la syntaxe suivante :
bomber --ignore-file=bomber.ignore scan bom.json
Vous pouvez définir le niveau de sévérité avec le flag --severity afin de ne retourner que certaines sévérités de vulnérabilité. Par exemple, si vous définissez --severity=moderate, seules les vulnérabilités de sévérité MODERATE ou supérieure seront retournées.
Par exemple, la commande suivante ne retournera que les vulnérabilités haute et critique.
bomber --severity=high scan bom.json
bomber a la capacité d'enrichir les données de vulnérabilité obtenues auprès des fournisseurs. Le premier "enrichisseur" que nous avons implémenté est pour EPSS
REMARQUE : Le score EPSS n'est plus par défaut dans bomber 0.5.0 et versions ultérieures. Pour afficher les scores EPSS, assurez-vous d'utiliser le flag --enrich=epss.
EPSS signifie Exploit Prediction Scoring System et est un framework qui prédit la probabilité qu'une vulnérabilité soit exploitée. EPSS est souvent utilisé pour aider à identifier les vulnérabilités à haut risque à prioriser pour la correction.
EPSS utilise un pourcentage pour la probabilité. Donc si vous voyez 94, le score signifie que la vulnérabilité a une probabilité d'exploitation de 94%. Et il est logique qu'une vulnérabilité avec un score comme 94 mérite une attention immédiate, tandis qu'une vulnérabilité avec un score de, disons, 20 mérite une priorité plus faible.
Si vous le souhaitez, vous pouvez définir deux variables d'environnement pour stocker vos identifiants et ne pas avoir à les taper sur la ligne de commande. Consultez les informations sur les Variables d'environnement plus loin dans ce README.
Si vous utilisez bomber dans vos pipelines CI/CD, vous pouvez faire une commande tout-en-un avec Syft pour générer et analyser un SBOM à la recherche de vulnérabilités. Pour ce faire, vous pouvez utiliser une commande de ce type :
# Assurez-vous d'inclure le caractère - à la fin de la commande. Cela déclenche bomber pour lire depuis STDIN
syft packages . -o cyclonedx-json | bomber scan --provider ossindex --output json -
Cette commande crée un SBOM, le pipe dans bomber et génère les résultats au format JSON.
Si vous ne voulez pas entrer d'identifiants à chaque fois, vous pouvez ajouter ce qui suit à votre .bashrc ou .bash_profile
export BOMBER_PROVIDER_USERNAME={{votre nom d'utilisateur OSS Index}}
export BOMBER_PROVIDER_TOKEN={{votre jeton API OSS Index}}
L'utilisation du flag --exitcode renverra un code de retour représentant la sévérité la plus élevée des vulnérabilités trouvées. Sans ce flag, vous pouvez vous attendre à un code de retour de 0 pour le succès, ou 1 en cas d'erreur.
En supposant qu'il n'y a pas d'erreur, les valeurs suivantes seront renvoyées par bomber avec --exitcode
| Sévérité | Code de retour |
|---|---|
| NON SPÉCIFIÉ (état où le fournisseur nous donne quelque chose de bizarre, ou aucune info) | 10 |
| FAIBLE | 11 |
| MODÉRÉE |
bomber contient désormais une fonctionnalité expérimentale qui enrichit la description des vulnérabilités dans une sortie html. Cette fonctionnalité prend une vulnérabilité et modifie la description en quelque chose de plus compréhensible pour un utilisateur non technique.
REMARQUE : Cette fonctionnalité est en état alpha majeur à l'heure actuelle. Elle est extrêmement lente et la sortie n'est pas très bien formatée.
Pour utiliser cette fonctionnalité, vous devrez fournir une clé API OpenAI. Vous pouvez passer cette clé dans le CLI en utilisant --openai-api-key={{votre clé API OpenAI}} ou ajouter une variable d'environnement :
export OPENAI_API_KEY={{votre clé API OpenAI}}
Après avoir défini votre clé API OpenAI, vous pouvez définir le flag de sortie comme suit :
bomber scan --output ai [sbom.json]
Si vous voulez essayer bomber, vous trouverez une sélection de SBOM de test dans le dossier test.
--license. Si vous avez besoin d'informations de licence, assurez-vous de les demander avec le SBOM.bomber doit envoyer un PURL à la fois pour obtenir les vulnérabilités, donc pour un gros SBOM, cela prendra du temps. Nous surveillerons cela.Si vous souhaitez contribuer au développement de bomber, veuillez vous référer au fichier CONTRIBUTING.md dans ce dépôt. Veuillez lire le fichier CODE_OF_CONDUCT.md avant de contribuer.
bomber utilise Syft pour générer une nomenclature logicielle à chaque fois qu'un développeur soumet du code à ce dépôt (tant que Hookz est utilisé et initialisé dans le répertoire de travail). Plus d'informations sur CycloneDX sont disponibles ici.
Le SBOM CycloneDX actuel pour bomber est disponible ici.
Merci aux sponsors et soutiens de bomber
Un grand merci à nos amis de ZERO pour le logo de bomber.
Merci à Sonatype pour avoir fourni un outil génial comme l'Index OSS de Sonatype.
Un grand merci à nos amis et collègues contributeurs de bomber chez Snyk pour avoir créé un fournisseur et codé le traitement d'un SBOM depuis STDIN. Vous êtes géniaux.
La description d'EPSS provient de l'équipe de Nucleus. Merci !
| 12 |
| HAUTE | 13 |
| CRITIQUE | 14 |