Sécuriser votre SBOM sur Google Cloud

Ces dernières années, la sécurité de la chaîne d’approvisionnement logicielle est devenue une priorité pour les gouvernements comme pour les entreprises. Après Log4Shell, fin 2021, la stratégie nationale de cybersécurité de l’administration Biden s’est notamment intéressée à la sécurité de la chaîne d’approvisionnement open source.

La National Security Agency (NSA) a récemment publié de nouvelles recommandations pour sécuriser les chaînes d’approvisionnement des logiciels open source. Ce nouveau document formule des recommandations sur la gestion des logiciels open source (OSS) et la tenue d’une nomenclature logicielle (SBOM).

La sécurité de la chaîne d’approvisionnement logicielle retient l’attention pour une bonne raison. Le nombre de paquets logiciels touchés par des attaques de la chaîne d’approvisionnement est passé d’environ 700 en 2019 à plus de 185 000 en 2022.

Alors que les équipes de développement réfléchissent à la manière de répondre aux nouvelles recommandations de la NSA, notamment dans des environnements cloud comme Google Cloud, elles doivent trouver des partenaires capables de les accompagner et d’intégrer ces bonnes pratiques à un modèle DevSecOps itératif.

Les recommandations de la NSA en détail

Intitulé Sécuriser la chaîne d’approvisionnement logicielle : bonnes pratiques recommandées pour gérer les logiciels open source et la nomenclature logicielle, ce nouveau document s’articule autour de quatre grands thèmes de sécurité :

1. Gestion des logiciels open source

2. Création et maintenance de dépôts open source sécurisés

3. Maintenance des logiciels open source et gestion de crise

4. Création et validation des SBOM

Passons en revue quelques recommandations du document destinées aux développeurs.

Gestion des logiciels open source

Ce document confie aux développeurs l’essentiel de la responsabilité de la gestion des logiciels open source. Ils doivent choisir les meilleures options OSS, vérifier les problèmes de licence et de vulnérabilité, les intégrer à leur cycle de développement et créer une SBOM.

La NSA recommande plusieurs bonnes pratiques pour intégrer des logiciels open source à votre processus de développement, notamment :

• Sélection : évaluer correctement les logiciels OSS afin de choisir les options les plus sécurisées

• Évaluation des risques : comprendre pleinement les risques associés à chaque logiciel OSS retenu

• Licences : respecter les obligations et restrictions imposées par les licences

• Contrôle des exportations : respecter les réglementations applicables en matière d’exportation

• Maintenance : gérer un dépôt interne sécurisé

• Réponse aux vulnérabilités : définir un processus pour détecter et corriger les nouvelles vulnérabilités

• Livraison sécurisée de logiciels : vérifier une dernière fois le contenu du livrable à l’aide d’une analyse de composition binaire avant sa mise à disposition

Création et maintenance de dépôts open source sécurisés

Dans sa récente publication, la NSA consacre une section aux recommandations pour créer un dépôt interne sécurisé.

Ses deux recommandations pour la maintenance de ce dépôt sont les suivantes :

• Mettre en place un processus d’adoption des logiciels OSS adapté à la taille de votre organisation et aux ressources dont elle dispose.

• Évaluer les vulnérabilités et les risques avant et après l’adoption, puis utiliser les résultats pour décider quels composants utiliser ou lesquels remplacer ou mettre à jour vers des versions plus sécurisées.

Maintenance des logiciels open source et gestion de crise

Même les logiciels open source considérés comme sécurisés et approuvés pour un dépôt interne peuvent être exposés à des vulnérabilités zero-day. Les organisations doivent également réfléchir aux moyens de détecter et de traiter ces nouveaux risques dans les logiciels OSS qu’elles ont retenus.

Les entreprises peuvent élaborer un plan de continuité pour détecter et corriger les nouvelles vulnérabilités et menaces open source en appliquant les bonnes pratiques suivantes :

• Exploiter des renseignements fiables pour repérer les menaces émergentes.

• Utiliser une SBOM pour localiser les composants vulnérables dans les bibliothèques.

• Suivre un processus de correction des vulnérabilités, par exemple en passant à une version corrigée ou en revenant à une version non affectée.

• Préparer un plan de gestion de crise pour faire face à l’avance aux problèmes logiciels majeurs et communiquer les informations nécessaires aux parties prenantes en temps utile.

Création et validation des SBOM

Le document souligne également l’importance des SBOM : les créer, les mettre à jour et les rendre accessibles aux personnes et aux outils concernés.

La NSA met en avant plusieurs caractéristiques d’une SBOM efficace :

• Des informations détaillées sur les composants, les versions, les licences et les dépendances

• Une intégration au pipeline avec des techniques de sécurité comme l’analyse de composition logicielle (SCA)

• Des outils d’extraction automatisés pour faciliter la détection et la mise à jour des composants tout au long du cycle de vie du développement logiciel (SDLC)

• Des contrôles qualité et une validation garantissant que les données de la SBOM sont au bon format pour que les développeurs puissent les intégrer à leurs outils et automatisations

Comment les utilisateurs de Google Cloud peuvent appliquer ces recommandations avec Snyk

Ces processus peuvent sembler représenter une charge supplémentaire pour vos équipes de développement, mais ce n’est pas une fatalité. La gestion de la sécurité open source de Snyk facilite la détection et la correction des vulnérabilités dans vos composants open source existants, l’analyse des demandes de fusion afin de repérer les composants non sécurisés avant leur intégration et la création de SBOM enrichies. Grâce à Snyk Open Source, notre outil SCA, 99 % des clients de Snyk touchés par Log4J ont corrigé la vulnérabilité Log4Shell en trois jours. En utilisant la plateforme de sécurité Snyk conçue pour les développeurs, vous pouvez plus facilement respecter les directives fédérales de sécurité en :

• Détecter les dépendances vulnérables au fil de votre travail, directement dans votre IDE ou votre CLI.

• Testant vos projets directement depuis le dépôt avant leur intégration, puis en les surveillant quotidiennement pour détecter de nouvelles vulnérabilités.

• Ajouter un test Snyk automatisé à votre pipeline CI/CD afin d’empêcher les nouvelles vulnérabilités de passer les étapes de compilation.

• Testant votre environnement de production pour vérifier qu’il n’est pas exposé à des vulnérabilités connues.

• Générant des SBOM enrichies avec les informations de Snyk pour chaque paquet open source, notamment les détails des licences, les liens externes, les informations sur les responsables de maintenance et bien plus encore.

Par ailleurs, Snyk collabore avec Google Cloud pour sécuriser les chaînes d’approvisionnement logicielles et s’intègre aux services Google que vous utilisez pour créer et exécuter vos applications, notamment :

• Google CloudBuild. Snyk analyse tous les paquets de vos projets et fournit des recommandations automatisées pour les corriger.

• Google Artifact Registry (GAR). Snyk analyse vos conteneurs à la recherche de vulnérabilités et teste vos images de base.

• Google Kubernetes Engine (GKE). Snyk vous permet d’importer et d’analyser les charges de travail en cours d’exécution afin de détecter les vulnérabilités dans les images et les configurations.

Grâce à ces intégrations, les équipes qui développent des applications modernes conteneurisées sur Google Cloud peuvent valider leurs SBOM et sécuriser leur chaîne d’approvisionnement logicielle sans quitter leurs environnements habituels.

Les clients peuvent également utiliser leurs mécanismes de facturation Google existants pour acheter directement les logiciels Snyk sur le Google Cloud Marketplace.

Découvrez comment Snyk a aidé l’équipe de Kroger à sécuriser sa chaîne d’approvisionnement.