Leçons tirées des vulnérabilités OpenSSL, partie 2 : détecter et corriger les vulnérabilités de la chaîne d’approvisionnement

Cette série consacrée à la chaîne d’approvisionnement revient sur les enseignements tirés d’OpenSSL et sur les éléments à prendre en compte pour renforcer la sécurité de votre chaîne d’approvisionnement. Si cette série s’intéresse à OpenSSL et aux bibliothèques associées, nous examinerons aussi les vulnérabilités dans leur ensemble. Dans le premier volet, nous avons passé en revue tout ce qu’il faut savoir pour déterminer où chercher les bibliothèques vulnérables. Passons à la deuxième partie pour voir comment détecter — et surtout corriger — les vulnérabilités de votre chaîne d’approvisionnement.

Comment détecter les vulnérabilités de votre chaîne d’approvisionnement

Les méthodes à utiliser pour rechercher les bibliothèques ou les packages problématiques dépendent des éléments que vous examinez. Les hôtes et les machines virtuelles ne font pas appel aux mêmes mécanismes que les conteneurs et le code. Aujourd’hui, nous allons nous concentrer sur les logiciels : les conteneurs et le code.

Une vue centralisée de tout votre écosystème peut vous aider à répondre à la question « Sommes-nous concernés ? ». Elle vous donnerait une visibilité sur l’ensemble de votre portefeuille d’applications. Elle devrait inclure toutes vos applications et les composants qui les constituent : le code, les conteneurs dans lesquels vous les déployez, ainsi que toutes leurs dépendances open source. Cette « vue centralisée » stockerait de fait une nomenclature logicielle (SBOM) pour chacun de vos composants logiciels, et fournirait un index de toutes les applications et de tous les conteneurs que vous exécutez ou stockez.

Code source et bibliothèques open source

Une vue centralisée est très utile, mais, comme on dit, après coup, tout paraît évident. Il est tout à fait possible que l’annonce concernant OpenSSL soit arrivée avant que vous ayez pu établir un inventaire — voire avant que vous sachiez qu’il était possible de le centraliser. Voyons les éléments à prendre en compte et les endroits à examiner si vous ne disposez pas encore d’une vue centralisée. Les applications modernes s’appuient sur des composants et des bibliothèques open source : 80 % ou plus du code de vos applications pourrait échapper à votre contrôle direct. Déterminer où ces bibliothèques et packages sont utilisés est donc une grande partie du problème.

Trouver les bibliothèques importées par vos applications et projets personnalisés est plus compliqué que de les rechercher sur des hôtes physiques. Vous pourriez lancer une recherche exhaustive du terme « openssl » dans toutes les occurrences de requirements.txt sous les répertoires racine de vos projets, mais vous ne trouveriez probablement pas grand-chose. Non seulement il est peu probable qu’un seul hôte contienne le code source de tous vos projets, mais il est tout à fait possible — voire probable — que si vos applications dépendent d’OpenSSL, ce soit par le biais des dépendances transitives évoquées précédemment.

Dans l’idéal, vous disposerez d’une nomenclature logicielle (SBOM) pour chacune de vos applications afin de déterminer rapidement les risques, mais ces nomenclatures ne sont pas encore généralisées. Plusieurs outils permettent de générer une SBOM pour vos applications. Snyk propose par exemple une API et une commande CLI, snyk sbom, qui génèrent une nomenclature logicielle aux formats SPDX ou CycloneDX. Mais vérifier manuellement chacun de vos dépôts de code source n’est pas réaliste. Au lieu de scanner votre code source sur votre machine locale, de nombreuses solutions vous permettent de le scanner là où il se trouve, dans vos dépôts. Snyk, par exemple, vous permet d’ajouter les dépôts à surveiller en associant simplement vos comptes et en sélectionnant les dépôts concernés.

Une fois les dépôts associés de cette manière, vous pouvez les scanner régulièrement. Cela permet de détecter les vulnérabilités nouvellement découvertes qui se trouvaient déjà dans les dépendances de vos projets — comme les vulnérabilités OpenSSL, que nous ignorions hier — ainsi que celles qui ont pu être introduites par les développeurs.

Images de conteneurs

Les images de conteneurs font également partie de votre chaîne d’approvisionnement logicielle. Elles servent non seulement de moteurs à vos charges de travail, mais regroupent aussi des éléments extérieurs à votre code et à ses dépendances. Plusieurs outils permettent de scanner la composition, les packages et les vulnérabilités des images de conteneurs, notamment Snyk Container, qui propose des offres payantes et gratuites, des intégrations IDE, une interface en ligne de commande et la prise en charge de l’automatisation dans vos pipelines CI/CD. Il existe aussi plusieurs projets open source — tels que Syft, Grype, trivy, ainsi qu’un outil non officiel « docker index » — qui peuvent rechercher des vulnérabilités. L’outil docker-index permet de rechercher des CVE depuis la ligne de commande. Bien que l’outil ne soit actuellement pas signé, vous pouvez l’exécuter dans un conteneur (très méta). Voici un exemple d’image publique, apache/tika:2.6.0.1, qui, au moment de la rédaction, contient toujours une version vulnérable d’OpenSSL. J’ai développé les arguments pour en faciliter la lecture ; n’hésitez pas à raccourcir -it.

1docker run \
2    --interactive \
3    --tty \
4    --rm \
5    ghcr.io/docker/docker-index:main \
6    cve -i \
7    apache/tika:2.6.0.1 CVE-0000

La commande docker-index détecte les vulnérabilités OpenSSL 3602 et 3768, mais rien d’autre :

1INFO Requesting image apache/tika:2.6.0.1
2INFO Copied image
3INFO Indexed 333 packages
4INFO Detected 2 vulnerabilities
5
6Detected CVE-2022-3602  HIGH
7https://dso.docker.com/cve/CVE-2022-3602
8
9pkg:deb/ubuntu/openssl@3.0.2-0ubuntu1.6?os_distro=jammy&os_name=ubuntu&os_version=22.04
10ADD file:ba96f963bbfd429a0839c40603fdd7829eaca58f20adfa0d15e6beae8244bc08 in /
110: sha256:301a8b74f71f85f3a31e9c7e7fedd5b001ead5bcf895bc2911c1d260e06bd987
12
13Detected CVE-2022-3786  HIGH
14https://dso.docker.com/cve/CVE-2022-3786
15
16pkg:deb/ubuntu/openssl@3.0.2-0ubuntu1.6?os_distro=jammy&os_name=ubuntu&os_version=22.04
17ADD file:ba96f963bbfd429a0839c40603fdd7829eaca58f20adfa0d15e6beae8244bc08 in /
180: sha256:301a8b74f71f85f3a31e9c7e7fedd5b001ead5bcf895bc2911c1d260e06bd987

La plupart des scanners de conteneurs et de composants open source affichent une liste de vulnérabilités, certains indiquant également une version « corrigée ». Voici, par exemple, le résultat de Trivy, qui détecte toute une série de vulnérabilités que docker-index ne repère pas (extrait ci-dessous) :

Il a détecté les deux nouvelles vulnérabilités OpenSSL de gravité HIGH, avec une présentation générale et une version « corrigée », mais ne permet pas vraiment de créer un conteneur plus sécurisé :

┌────────────────┬────────────────┬──────────┬───────────────────┬────────────────────┐
│ libssl3        │ CVE-2022-3602  │ HIGH     │ 3.0.2-0ubuntu1.6  │ 3.0.2-0ubuntu1.7   │
│                │                │          │                   │                    │
│                ├────────────────┤          │                   │                    │
│                │ CVE-2022-3786  │          │                   │                    │
│                │                │          │                   │                    │
└────────────────┴────────────────┴──────────┴───────────────────┴────────────────────┘

Comme pour l’open source dans notre premier article, scanner une ou deux images de conteneurs est peut-être envisageable, mais en scanner des centaines ou des milliers n’est pas réaliste dans un flux de développement habituel.

Comme pour les dépendances transitives et les logiciels open source, vous n’exécutez probablement pas directement des images comme Ubuntu ou tika elles-mêmes, mais utilisez plutôt des images dérivées de celles-ci. Elles héritent ainsi de toutes les vulnérabilités qu’elles contiennent, auxquelles s’ajoutent celles que vous avez introduites avec des instructions utilisateur, ce qui complexifie encore la recherche.

Où sommes-nous concernés ?

Comme nous l’avons vu, plusieurs outils peuvent vous aider à détecter les bibliothèques vulnérables dans vos images de conteneurs et vos dépendances open source. Les outils qui effectuent des analyses ponctuelles dans votre environnement de développement local peuvent convenir aux projets réunissant peu de développeurs, mais deviennent difficiles à gérer à mesure que l’équipe et le nombre de projets s’agrandissent. À l’inverse, les outils qui s’intègrent aux sources de référence de votre portefeuille d’applications — dépôts de code source et registres d’images de conteneurs — peuvent suivre votre inventaire et vous fournir des informations à jour sur les impacts potentiels. Par exemple, en filtrant sur une autre vulnérabilité très médiatisée, Snyk Reporting affiche une vue centralisée de nos projets concernés par Log4Shell. Que nous ayons utilisé la méthode de recherche exhaustive ou une vue centralisée bien organisée, nous avons au moins une réponse à la question : « Où sommes-nous concernés ? »

Il ne s’agit pas seulement de « trouver » les occurrences

Nous avons vu que plus de 80 % du code de votre chaîne d’approvisionnement logicielle pourrait provenir de sources externes, mais trouver les occurrences ne répond qu’à une partie de la question que vous posera votre responsable. Maintenant que nous savons où se trouvent nos vulnérabilités et que nous avons une liste de correctifs à appliquer, il reste à répondre à la deuxième partie de la question : « Comment allons-nous les corriger ? ». Pour les systèmes d’exploitation ou les applications, « corriger » signifie généralement attendre et appliquer les correctifs ou les mises à jour d’un fournisseur.

Pour les vulnérabilités des bibliothèques open source et des conteneurs, vous devrez probablement aussi attendre les mises à jour des mainteneurs du projet, avec quelques étapes supplémentaires. En effet, les mainteneurs attendent eux aussi sans doute un correctif en amont. Prenons Ubuntu 22.04, la version à support à long terme (LTS) de cette distribution Linux populaire. Lorsque les vulnérabilités OpenSSL ont été divulguées, Ubuntu 22.04 incluait OpenSSL 3.0.2 (plus précisément, 3.0.2-0ubuntu1.6), l’une des versions vulnérables. Dans le cas d’Ubuntu, au lieu de passer à la version 3.0.7, la version 3.0.2 a été corrigée pour inclure les correctifs des vulnérabilités. Mais ce n’était pas tout. Une fois la bibliothèque corrigée, il fallait encore publier la mise à jour d’Ubuntu 22.04 et créer des images de conteneurs actualisées.

Si vous utilisez directement des images Ubuntu (par exemple, si votre Dockerfile commence par FROM ubuntu:22.04), vous pouvez reconstruire vos images pour intégrer le correctif une fois les images concernées publiées — en veillant, bien sûr, à tester vos images, car même les changements les plus mineurs doivent être validés. En revanche, si vous êtes un consommateur en aval qui dépend d’images dérivées de cette nouvelle version de Jammy Jellyfish, vous devrez peut-être attendre quelques cycles supplémentaires pour que les correctifs se propagent et que l’image attendue soit mise à jour.

Contrairement aux solutions open source de scan de conteneurs présentées dans la section précédente, Snyk Container vous aide à parcourir les arbres de dépendances des images pour trouver de meilleures images de base et ainsi créer des images plus sécurisées. Snyk tient à jour un index des versions d’images officielles populaires sur Docker Hub, ce qui vous permet de savoir quand les images utilisant des tags flottants (mises à jour sur place, sans incrémenter de version mineure) ne sont plus à jour. Dans cet exemple, Snyk Container détecte que ubuntu:22.04 a été mise à jour depuis la création de l’image scannée et indique qu’il faut la reconstruire pour intégrer cette modification :

1Your base image is out of date
21) Pull the latest version of your base image by running 'docker pull ubuntu:22.04'
32) Rebuild your local image

Snyk Container peut également vous proposer une liste de meilleures images, que vous utilisiez des images Docker officielles ou vos propres images de base personnalisées. Il peut même générer des pull requests en un clic, pour vous permettre de mettre rapidement à niveau vos images et de corriger plusieurs vulnérabilités à la fois.

Avec Snyk, il est également facile de corriger les vulnérabilités des dépendances open source. Vous obtenez notamment des informations sur les bibliothèques vulnérables et les versions corrigées, comme ci-dessous :

Snyk fournit également les outils nécessaires pour les corriger au moyen de « Fix PRs », qui vous permettent de traiter plusieurs vulnérabilités en un seul clic.

Si la correction au cas par cas n’est pas adaptée à votre échelle, la réponse à la question « Comment allons-nous corriger ces vulnérabilités ? » est simple : « Avec Snyk. »

Préparez-vous à la prochaine vulnérabilité de la chaîne d’approvisionnement avec Snyk

Profitez des vulnérabilités OpenSSL dont la gravité a été revue à la baisse pour tester vos processus de gestion des vulnérabilités. Créez des procédures et des listes de contrôle pour gérer la prochaine vulnérabilité : déterminez qui impliquer, comment évaluer l’impact, quels éléments de l’inventaire examiner et comment communiquer vos conclusions et l’impact en interne — et en externe, le cas échéant. Plus important encore, assurez-vous que chacun sait où trouver ces procédures. Avant la prochaine vulnérabilité critique, commencez à utiliser des outils de suivi de votre code source et de votre inventaire de conteneurs afin d’être mieux préparé.

En utilisant Snyk Container et Snyk Open Source pour sécuriser votre chaîne d’approvisionnement logicielle, vous pouvez surveiller de manière proactive vos conteneurs et vos projets open source. Plutôt que de devoir vous précipiter pour rechercher les occurrences d’images de conteneurs ou de packages open source vulnérables, vous pouvez savoir si vous êtes concerné avant même la publication des vulnérabilités et avoir ainsi l’assurance de pouvoir répondre lorsque vous cliquez sur le bouton « envoyer » dans Slack pour faire partir ce message à votre responsable.

Découvrez les outils de sécurité de la chaîne d’approvisionnement logicielle, voyez comment Snyk peut vous aider à renforcer la sécurité de votre chaîne d’approvisionnement logicielle, et commencez gratuitement dès aujourd’hui.