Sur les SBOM, BitBucket et OWASP Dependency Track

Tutoriels

Le musée des architectures anciennes et modernes avec lequel je suis impliqué m’a contraint à me pencher sur leur protection. Par exemple, une ancienne dépendance peut devenir une CVE ou un projet open-source solide peut devenir commercial. C’est ici que le concept de Software Bill of Material (SBOM) est né pour cataloguer l’écosystème de licences et de dépendances des systèmes. Cet artefact de construction, à son tour, est ensuite analysé pour déterminer si les composants constitutifs sont :

  1. Vulnérables à l’exploitation, ou
  2. Licenciés sous des conditions peu acceptables, comme étant trop commerciaux ou trop prédateurs.

Cet article expliquera comment contrôler une telle vulnérabilité en utilisant :

  1. les pipes BitBucket pour la génération de SBOM, et
  2. comment OWASP’s Dependency Track peut l’analyser.

Sachez vos risques

Ne pas savoir ce qui se cache dans votre code et vos conteneurs est un bonheur, mais dangereux. Cependant, faire passer tous vos composants par un analyseur de dépendances peut donner un retour écrasant. Il est préférable de créer un tableau de bord et d’incorporer dans la culture d’équipe que le nombre de problèmes de dépendance devrait toujours être moins aujourd’hui qu’hier.

Wikipedia indique que : « Le Open Worldwide Application Security Project (OWASP) est une communauté en ligne qui produit des articles, méthodologies, documentations, outils et technologies disponibles gratuitement dans les domaines de l’IoT, des logiciels système et de la sécurité des applications web. » Il n’est donc pas surprenant qu’ils fournissent une plateforme pour suivre et analyser les vulnérabilités des systèmes. Sa caractéristique la plus frappante est son tableau de bord principal :

Le plus grand graphique au milieu affiche le nombre de vulnérabilités pour tous les projets suivis. Les métriques sur les vulnérabilités critiques, moyennes et faibles sont affichées juste en dessous. Dependency Track récupère les vulnérabilités connues à partir d’une ou plusieurs sources. La plus notable d’entre elles est la liste des Vulnérabilités et Expositions Courantes (CVE) des États-Unis Base de Données Nationale des Vulnérabilités. Chaque CVE se voit attribuer un niveau de criticité allant d’inconnu et faible à critique. Cette analyse de risque est effectuée par Dependency Track à intervalles réguliers en arrière-plan en utilisant le Logiciel de Facture de Matériel (SBOM) pertinent comme entrée.

La section directement en dessous du plus grand graphique détaille les violations de politique, avec des politiques configurées selon ce que l’on considère important. On peut enregistrer certaines dépendances comme indésirables, ou on peut exiger que certaines licences ou même groupes de licences soient affichés sur le tableau de bord et rapportés. Ce mécanisme de retour d’information est configurable par politique.

La section supérieure représente alors les vulnérabilités du portefeuille, les projets à risque, les composants vulnérables et un score de risque au fil du temps.

Il y a plus de vues, graphiques et statistiques telles que l’avancement de l’audit, les vulnérabilités par projet au fil du temps et les vulnérabilités par composant au fil du temps, entre autres, mais concentrons-nous plutôt sur la manière dont BitBucket peut générer et envoyer le SBOM à Dependency Track.

BitBucket prépare le SBOM

La préparation du SBOM se fait dans le pipeline CI/CD de BitBucket qui s’exécute après que les demandes de fusion sont fusionnées dans la branche principale. Cela garantit que les tableaux de bord sont toujours à jour avec l’état des choses. 

J’ai utilisé un pipe BitBucket qui enveloppe syft pour générer un SBOM CycloneDX. Les commandes syft pour les interrogations de code et de conteneur diffèrent légèrement.

Inspection de code

La commande syft pour analyser le code à partir de la racine de votre projet est la suivante :  

syft --output cyclonedx-json=code-cdx-sbom.json -v --java-use-network true .

Cette commande génère le SBOM dans un fichier appelé code-cdx-sbom.json et utilise le réseau pour récupérer les informations de licence sur Internet ; par exemple, à partir des dépôts Maven centraux.

Le syft BitBucket pipe de shiftleftcyber (merci !) est ensuite configuré dans le bloc de script du pipeline BitBucket pour encapsuler cette commande syft comme suit :

YAML

 

Le readme du projet syft liste une impressionnante gamme de langages pris en charge, mais je ne l’ai utilisé que sur Java et JavaScript avec un projet Python dans le backlog.

Que cache vos conteneurs ?

Pour scanner un conteneur de votre registre, on exécute la commande suivante dans le cadre d’un « docker login » :

syft --output cyclonedx-json=container-cdx-sbom.json docker.s2c.co.za/container:latest --from registry

Le pipe BitBucket correspondant est :

YAML

 

Le commutateur all-layers demande à syft d’inspecter toutes les couches de l’image du conteneur et pas seulement le produit final.

BitBucket comme moyen de dépôt

Tout ce qui reste est que Dependency Track ingère le SBOM. J’ai utilisé le pipe sœur pipe du pipe BitBucket qui a généré le SBOM :

YAML

 

J’ai spécifié trois paramètres d’entrée :

  1. URL de l’instance Dependency Track
  2. L’ID du projet Dependency Track à charger le SBOM
  3. La clé API pour autoriser le téléchargement

L’identifiant du projetpeut facilement être trouvé en cliquant sur « Voir les détails » depuis la vue du projet :

Suivi par la copie de l’Identifiant d’Objet en bas :

L’clé APIse trouve dans le champ d’entrée portant un nom similaire de l’équipe Automation, accessible depuis le menu Administration du panneau de gauche :

Conclusion

Les incidents passés ont montré que l’exploitation des faiblesses tend à entraîner des interruptions de service pouvant déborder sur des systèmes ou industries voisines. Cela entraîne des dépenses inattendues et des désagréments. La récupération de cela éloignera les développeurs et les ressources des objectifs de l’équipe.

La licence d’un projet open source, de plus, peut devenir commerciale et aboutir à ce qu’une organisation soit frappée de frais de licence rétroactifs. À l’autre extrémité de l’échelle, des demandes peuvent être faites pour rendre open source une propriété intellectuelle critique utilisée pour obtenir un avantage concurrentiel en raison de conditions de licence prédateurs.

Il est donc de la responsabilité de chaque développeur de mettre en œuvre et de soutenir des stratégies actives pour contrer ces risques. Si votre code est sur BitBucket, l’approche décrite ci-dessus peut aider vos systèmes à s’adapter. Cependant, l’API Dependency Track ne limite pas l’accès exclusivement à BitBucket et il doit exister des moyens d’obtenir des factures de matériaux logiciels à partir d’autres technologies de pipeline CI/CD.

Source:
https://dzone.com/articles/on-sboms-bitbucket-and-owasp-dependency-track