By Yann Albou.
Au dela de la Supply Chain Attack, découvrez le concept de SBOM et améliorer la sécurité de la CI/CD et détecter au mieux les vulnérabilités.
Cet article s’inscrit dans une série sur comment se protéger d’une "Supply Chain Attack" ?
Comme expliqué dans l’article La Supply Chain Attack ? et afin de faciliter la mise en application de nos recommandations, nous avons adopté une signalétique. Voici celle concernant notre sujet:
Le champ d’application concerne la partie Dev et CI (Continuous Integration). c’est une pratique et de l’outillage à mettre en place qui demande un effort modéré. Cette recommandation offre une mitigation du risque de type détection qui l’a rend très intéressante à mettre en place.
Ce terme signifie "Software Bill of Materials" en anglais, ce qui se traduit en français par "Liste des Composants Logiciels". C’est un document (dans un format normé) qui répertorie tous les composants logiciels utilisés dans la création d’un produit logiciel donné, y compris les bibliothèques tierces, les modules, les frameworks et les packages.
Elle doit répertorier tous les composants logiciels utilisés dans la création d’un progiciel donné, y compris les bibliothèques tierces, les modules, les frameworks et les packages et pas seulement ceux de l’application mais aussi ceux du système surlequel tourne l’application à l’intérieur d’un container (ex: lib openssl). Il est important d’avoir une liste complète et exhaustive à jour des composants, applicatifs et systèmes, pour garantir que la solution est sûre, fiable et conforme aux normes de qualité.
Elle doit identifier les dépendances directes et indirectes entre les différents composants logiciels. Les dépendances directes sont les composants qui sont explicitement référencés dans le code source, tandis que les dépendances indirectes sont des composants qui sont requis par les dépendances directes. Il est important d’identifier ces dépendances pour comprendre la complexité de l’application et les risques potentiels liés à ces dépendances.
La SBOM doit identifier de manière unique chaque package et chaque version de chaque composant logiciel utilisé. Cette identification unique est essentielle pour garantir la traçabilité des composants et permettre une gestion efficace des licences et des contrats.
Elle peut être considérée comme une approche vertueuse, car elle vise à améliorer la sécurité, la qualité et la transparence du logiciel. Mais cela peut aller au delà:
Ce concept nous permettra, par exemple, de répondre aux questions du type:
L’utilisation d’outils pour en extraire les informations n’est pas nouvelle et elle est déjà intégrée dans certains frameworks de développement. Par exemple, le fichier pom.xml utilisé par Maven pour la gestion des projets Java contient des informations sur les dépendances directes et indirectes, les versions, les licences et les URL des dépôts pour chaque composant. De même, le fichier package.json utilisé par les frameworks js contient des informations sur les dépendances directes, les versions, les URL des dépôts et les scripts de construction pour chaque paquet. Ces fichiers sont des exemples de ce que l’on appelle des "descripteurs de dépendances" et ils sont utilisés par les outils de gestion de dépendances pour télécharger les composants appropriés et les installer dans le projet.
Ces descripteurs de dépendances sont également utilisés pour extraire les informations. Par exemple, les outils de gestion de dépendances tels que Maven, npm, Cargo, Go Modules, etc. peuvent extraire les informations à partir de ces fichiers. Cela permet de créer automatiquement une SBOM pour le projet, qui peut être utilisée pour vérifier les licences, les vulnérabilités et les dépendances indirectes.
Celle-ci est une extension des outils existants pour fournir une vue d’ensemble complète des composants logiciels utilisés dans le système. Les outils de gestion de dépendances sont généralement limités (pas tous) à la gestion des dépendances directes. Cependant, elle doit également inclure des informations sur les dépendances indirectes, qui peuvent être plus difficiles à identifier. Les outils d’analyse statique peuvent être utilisés pour identifier les dépendances indirectes, mais cela peut être un processus fastidieux et coûteux.
Elle fournit également des informations sur les versions de chaque composant, ce qui est important pour la gestion des mises à jour et des correctifs de sécurité. Les outils de gestion de dépendances peuvent également gérer les mises à jour et les correctifs de sécurité, mais elle fournit une vue d’ensemble de tous les composants dans le système et facilite la planification des mises à jour et des correctifs.
En fin de compte, l’utilisation d’outils pour extraire les informations de la SBOM est une pratique courante dans les environnements de développement et elle est déjà intégrée dans certains frameworks. Elle fournit une vue d’ensemble complète des composants utilisés dans le système, ce qui facilite la gestion des licences, des vulnérabilités, des dépendances indirectes et des mises à jour.
A titre d’exemple et de manière non-exhaustive voici quelques outils open source de génération de SBOM : Trivy(projet Opensource par Aquasecurity), Syft(projet Opensource par Anchore), SBOM Tool(projet Opensource par Microsoft), bom(projet Opensource par kubernetes-sigs), spdx-sbom-generator, Tern, …
A noter que la nouvelle commande docker sbom s’appuie sur Syft pour générer une sbom.
Avant d’utiliser ces outils assurez-vous qu’ils correspondent à vos besoins en matière de packages, frameworks et système supportés et qu’ils s’intègrent correctement à votre environnement (mode deconnecté, standards, CI, …).
La SBOM doit être générée dans un format standardisé pour garantir une meilleure interopérabilité et une adoption plus large. Deux formats standardisés populaires sont SPDX et CycloneDX. SPDX (Software Package Data eXchange) est un format standard de l’industrie pour échanger des informations sur les licences et les métadonnées associées. CycloneDX est un format de métadonnées pour les composants logiciels qui fournit une représentation standardisée des informations sur les composants.
Voici un exemple de format SPDX pour un package applicatif :
SPDXVersion: SPDX-2.2
DataLicense: CC0-1.0
DocumentNamespace: http://example.com/project/1.0
PackageName: example-project
PackageVersion: 1.0.0
PackageDownloadLocation: https://github.com/example/project/releases/tag/v1.0.0
PackageChecksum: SHA1:4b74d58f79a74766ca2fbb7201a9e1d3d3e0c6b8
PackageVerificationCode: PACKAGE_VERIFICATION_CODE
PackageHomePage: http://example.com/project
PackageSourceInfo: git+https://github.com/example/project.git#v1.0.0
PackageLicenseDeclared: Apache-2.0
FilesAnalyzed: true
PackageLicenseComments: This package is released under the Apache-2.0 license.
Creator: Tool: SPDX-Tools-1.0
CreatorComment: SPDX Version 2.2 SPDX-Tools-1.0: SPDX-Tools-1.0Dans cet exemple, on retrouve des informations telles que la version de SPDX, la licence de données, le nom et la version du package, l’emplacement de téléchargement du package, la somme de contrôle, la page d’accueil du package, les informations sur la source, la licence déclarée, etc. Ces informations peuvent être utilisées pour générer une liste complète des dépendances pour le package logiciel.
Voici un autre exemple, mais avec le format CycloneDX:
<?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1" serialNumber="urn:uuid:562f1c4d-0eb9-4129-8a3a-d6c0e47fd0f8">
<components>
<component type="library" name="example-library" version="1.0.0">
<purl>pkg:maven/org.example/example-library@1.0.0</purl>
<licenses>
<license id="Apache-2.0"/>
</licenses>
<dependencies>
<dependency ref="pkg:maven/org.apache.commons/commons-lang3@3.0.1">
<scope>compile</scope>
</dependency>
</dependencies>
</component>
</components>
</bom>Dans cet exemple, on retrouve des informations telles que le nom, la version et l’identifiant universel de ressource de package (PURL) du composant logiciel, ainsi que ses licences et ses dépendances. Ces informations peuvent être utilisées pour générer une liste complète pour des dépendances applicatives.
Il est important d’avoir un standard car cela permet une communication et une collaboration efficaces entre les différentes parties prenantes impliquées dans le développement, la distribution et l’utilisation de solutions applicatives via l’amélioration de la transparence et de la traçabilité, de la sécurité, de la conformité et de l’efficacité.
Ce qui est particulièrement important dans un environnement de plus en plus complexe et interconnecté.
Dans le contexte des conteneurs, il est crucial de comprendre les dépendances logicielles qui se trouvent dans l’image d’un conteneur. Cela peut aider à identifier rapidement les vulnérabilités et à déterminer les mises à jour nécessaires en cas de faille de sécurité. C’est là qu’intervient la SBOM, qui fournit une liste complète de tous les composants et dépendances d’une image conteneurisée.
Son ajout aux images conteneurisées permet également de suivre les changements de versions et les mises à jour des dépendances au fil du temps, offrant ainsi une meilleure visibilité sur la sécurité et la conformité. En l’attachant à l’image conteneurisée, les équipes de développement peuvent facilement identifier les composants vulnérables et prendre des mesures pour corriger les failles de sécurité.
Les outils de gestion de conteneurs tels que Docker et Kubernetes permettent de l’attacher aux images conteneurisées.
Par exemple, depuis la version de Docker BuildKit v0.11, il existe la prise en charge des attestations de construction et des SBOM, permettant de créer des images avec des informations de la façon dont l’image a été construite, comme par exemple la SBOM.
Les manifestes d’attestation sont attachés à l’objet d’index d’image racine, sous un manifeste d’image OCI distinct. Chaque manifeste d’attestation peut contenir plusieurs objets blob d’attestation, toutes les attestations d’un manifeste s’appliquant à un seul manifeste de plateforme. Toutes les propriétés des manifestes OCI et Docker standard continuent de s’appliquer.
Cela vous permet de répondre plus facilement aux questions courantes, telles que les packages contenus dans l’image, d’où l’image a été créée et si vous pouvez reproduire les mêmes résultats localement.
A noter que sa génération de manière automatisée est un point clé qui permet d’éviter l’effet CMDB qui diverge après 2 jours et qui s’inscrit totalement dans une CI.
Il est important d’inclure la publication de la SBOM dans son pipeline
En somme, attacher la SBOM aux images conteneurisées de manière automatisée est essentiel pour garantir la transparence et la traçabilité des composants logiciels utilisés dans l’environnement des conteneurs.
Les dépendances obfusquées sont des composants logiciels ou systèmes dont le code source est difficile à lire ou à comprendre, ce qui rend difficile l’identification des dépendances directes ou indirectes.
En particulier, les dépendances obfusquées, directes ou indirectes, peuvent poser un problème de sécurité lorsqu’elles ne sont pas détectées dans les images de conteneurs. Les images de conteneurs peuvent inclure des binaires ou des bibliothèques de dépendances dont les noms ont été modifiés pour dissimuler leur origine réelle. Cela rend difficile pour les outils de sécurité de détecter les vulnérabilités dans ces dépendances.
Un exemple est la compilation d’une application en binaire (Go, Java natif, C, C++, …) qui par nature cache toutes les dépendances qui rendent obsolètes la plupart des scanners ou outils de sécurité.
De la même manière, certaines images de conteneurs peuvent ne pas être directement scannables du fait d’être inaccessible (pas de gestionnaire de packages, ni de shell). c’est par exemple le cas de certaines images minimalistes : "From scratch" images, Distroless images, Chainguard images, …
D’un point de vue sécurité, l’utilisation de binaires ou d’images minimalistes est plutôt une bonne chose, mais c’est largement moins pertinent si nous ne pouvons pas scanner de manière fiable le contenu de ces artefacts…
C’est la que la SBOM devient aussi très intéressante et permet de résoudre ce type de pb en l’attachant aux métadonnées de l’image !
En l’attachant aux métadonnées de l’image, cela permet d’avoir une vue complète et précise de toutes les dépendances utilisées dans l’image les cas d’utilisation décrits précédemment et sans avoir d’outils de scanning sophistiqués.
Nous verrons dans un autre article comment s’assurer de l’intégrité des composants et en particulier de la SBOM.
Dans les environnements de développement complexes, il est possible que plusieurs SBOM soient générées pour différents composants utilisés. Il est important de consolider celles-ci dans une seule globale pour fournir une vue d’ensemble complète des composants logiciels utilisés dans l’ensemble du système. Cela permet de mieux comprendre la complexité du système et de faciliter la gestion des risques associés aux dépendances.
Des solutions de sécurité globales ont ce genre de fonctionnalité et même bien plus, telle que:
Pour ce besoin de consolidation, une "moulinette" peut être faite manuellement, mais attention aux coûts de développement et à la maintenabilité.
Attention aussi aux solutions seulement intégrées à la registry car cela peut générer beaucoup de faux positifs (images présentes mais non active)
En conclusion, la SBOM est un élément clé dans la sécurité et la transparence de la chaîne d’approvisionnement logicielle. Avec cette dernière, les équipes DevOps peuvent avoir une vue complète et précise de toutes les dépendances utilisées dans leurs applications, ce qui leur permet de gérer l’évolution des versions et d’avoir une vraie gouvernance des dépendances mais aussi de détecter et de résoudre les vulnérabilités plus rapidement. Cela est particulièrement important dans un contexte de "Supply Chain Attack", où des attaquants peuvent infiltrer une chaîne d’approvisionnement logicielle et insérer des composants malveillants dans des applications légitimes.
En l’intégrant dans une démarche DevSecOps, les équipes DevOps peuvent travailler en collaboration avec les équipes de sécurité pour renforcer la sécurité de leurs applications et détecter plus rapidement les menaces. Cela permet également de répondre plus rapidement aux exigences de conformité en matière de sécurité, tout en améliorant la qualité des applications.
En somme, elle est un outil essentiel pour garantir la sécurité et la transparence de la chaîne d’approvisionnement!