Ce blog présente les principaux enseignements tirés de notre webinaire «Supply Chain Software : les maillons faibles exploités par les pirates ». Regardez l'intégralité du webinaire ici.
Les risques liés à la chaîne Software ont considérablement augmenté, car les organisations s'appuient davantage sur des composants open source, des packages externes et des pipelines de développement automatisés. De petites failles qui semblaient autrefois inoffensives ont désormais des conséquences réelles, d'autant plus que les dépendances sont de plus en plus profondes et difficiles à vérifier.
Un exemple clair de cette évolution est le récent ver npm Shai-Hulud et Shai-Hulud 2.0, qui s'est propagé via des paquets compromis et a affecté des milliers de projets en aval en quelques heures. Des incidents comme celui-ci montrent clairement une chose : les faiblesses de la chaîne d'approvisionnement ne restent plus confinées, elles se propagent à l'ensemble des écosystèmes.
Avec 70 à 90 % des logiciels modernes composés de composants open source, dont la plupart des développeurs ne voient jamais directement, les petits problèmes peuvent rapidement devenir de gros risques. Pourtant, seules 15 % des entreprises se sentent confiantes dans leur gestion de ce risque open source. Avec 70 % des attaques malveillantes d'IA qui devraient cibler les chaînes d'approvisionnement d'ici 2025, il est désormais essentiel d'identifier les maillons faibles de la chaîne d'approvisionnement logicielle.
Pour les équipes d'ingénierie et de sécurité, l'avantage est simple : connaître l'emplacement de ces points faibles permet d'éviter les mauvaises surprises, d'accélérer les temps de réponse et de réduire considérablement le risque de se retrouver à la une des journaux dans le domaine de la chaîne d'approvisionnement.
Les SBOM ne sont plus facultatives
Pour gérer les risques liés à la chaîne logistique logicielle et répondre aux vulnérabilités, les organisations doivent avoir une vision claire de leur pile logicielle. Cette visibilité repose sur la SBOM (nomenclature logicielle), qui apporte la transparence nécessaire pour comprendre les risques liés aux composants et agir rapidement en cas de problème.
Une SBOM est définie comme un inventaire détaillé de tous les composants, licences et dépendances fermés et open source utilisés dans une application. Cet inventaire fournit des données essentielles pour la transparence, la conformité et la gestion des risques.
Ce qui n'est pas vulnérable ou malveillant aujourd'hui peut facilement le devenir demain. Étant donné que des vulnérabilités sont découvertes en permanence, y compris dans les anciennes versions, une surveillance et un inventaire continus sont nécessaires.
George PrichiciVice-président, Produits, OPSWAT
SBOM vs SCA
Il est important de faire la distinction entre SBOM et SCA (Software Analysis, analyse de la composition logicielle). Le SBOM est l'inventaire, ou la liste des composants. Le SCA évalue si certains de ces composants sont vulnérables, obsolètes ou risqués. Ensemble, ils fournissent aux organisations les informations nécessaires pour prendre des décisions éclairées, réagir plus rapidement aux problèmes de sécurité et renforcer la gestion globale des risques.
| Catégorie | SBOM | SCA |
|---|---|---|
Objectif | Inventaire des composants |
Identifier les vulnérabilités des composants
|
Couverture des risques | Conformité et visibilité | Risques liés à la sécurité, CVE, risques liés à l'exécution |
Calendrier | Pré-déploiement / approvisionnement | Continu / compilation et exécution |
Les mouvements mondiaux, motivés en partie par des attaques telles que SolarWinds, exigent désormais des SBOM, avec des pressions réglementaires provenant d'entités telles que la CISA, la NSA et le NIST, ainsi que de l'UE et des pays alliés de l'OTAN, rendant la transparence des SBOM non plus facultative, mais fondamentale pour tout fournisseur de logiciels.
Les 7 maillons faibles critiques exploités par les pirates informatiques
La rapidité du développement moderne, associée à une forte dépendance vis-à-vis des codes tiers et open source, a introduit de graves vulnérabilités. Les acteurs malveillants exploitent sept failles principales :
1. Risques liés à l'open source et aux dépendances
Lorsque les développeurs privilégient la rapidité, ils utilisent souvent de grandes bibliothèques open source sans procéder à une révision complète du code. Un seul composant peut introduire des dépendances transitives supplémentaires. Si vous ne surveillez que le niveau supérieur, vous risquez de passer à côté de codes malveillants injectés dans ces dépendances transitives cachées.
Ce schéma est récurrent dans les écosystèmes open source. Un seul paquet compromis peut se propager à travers les chaînes de dépendances et atteindre des millions de téléchargements avant que quiconque ne s'en aperçoive. Une récente attaque de la chaîne logistique npm impliquant un crypto-malware illustre parfaitement comment cela se passe dans la pratique.
Meilleures pratiques :
- Analysez tous les paquets open source et leurs chaînes de dépendances complètes afin d'identifier les vulnérabilités, les composants obsolètes ou les logiciels malveillants cachés avant qu'ils n'atteignent votre base de code.
- Surveillez en permanence les dépendances au fil du temps, car des composants sûrs peuvent devenir risqués à mesure que de nouvelles vulnérabilités CVE ou des mises à jour malveillantes apparaissent.
- Utilisez des registres fiables et vérifiez l'intégrité des paquets afin de vous assurer que les paquets que vous téléchargez n'ont pas été altérés.
- Appliquez des politiques qui signalent ou bloquent les licences à risque afin que des conditions de licence incompatibles ou virales ne se glissent pas dans vos builds.
- Retardez l'utilisation des nouveaux paquets publiés jusqu'à ce qu'ils aient été vérifiés, afin de réduire le risque d'introduire dans votre environnement des versions non vérifiées ou malveillantes.
2. Risque lié aux licences
Les questions de licence touchent désormais autant l'ingénierie que le domaine juridique. Les licences virales, telles que la GPL, peuvent obliger votre application finale à être publiée sous la même licence, ce qui peut entraîner la perte de la propriété intellectuelle (PI) de votre entreprise. Une surveillance continue est nécessaire, car les conditions de licence peuvent changer, même pour les versions plus anciennes qui étaient auparavant conformes.
Meilleures pratiques :
- Utilisez un outil de détection automatique des licences pour signaler les licences à haut risque ou incompatibles dès le début du développement. Vous trouverez ici une explication plus détaillée de l'importance de cette démarche : Le rôle crucial de la détection des licences dans la sécurité open source.
- Suivez en permanence les changements de licence afin de détecter les modifications susceptibles d'affecter la conformité ou l'exposition de la propriété intellectuelle.
- Bloquez ou examinez les composants soumis à des licences restrictives ou virales avant qu'ils n'entrent dans la base de code.
- Conservez un inventaire clair de toutes les licences utilisées afin de simplifier les audits et les évaluations des risques.
3. Lacunes dans les données SBOM ou SBOM manquantes
Bien que la réglementation impose le partage des SBOM, une liste générale ne suffit pas. Des données détaillées, notamment sur l'auteur, les contributeurs, la fréquence de publication et l'état de maintenance, sont nécessaires pour assurer une atténuation et une prévention efficaces.
Meilleures pratiques :
- Améliorez les rapports SBOM en réanalysant les composants afin de les enrichir avec des données de licence mises à jour, le statut des vulnérabilités et d'autres métadonnées critiques. Vous trouverez un exemple détaillé de la marche à suivre dans la section Validation et enrichissement des rapports SBOM CycloneDX.
- Valider et enrichir les SBOM à l'aide d'outils automatisés afin de garantir que les informations sont complètes, exactes et exploitables.
- Exiger des fournisseurs qu'ils fournissent une liste complète des composants logiciels (SBOM), y compris les dépendances transitives et toutes les métadonnées pertinentes.
- Mettre à jour et surveiller en permanence les inventaires SBOM à mesure que les composants évoluent ou que de nouvelles vulnérabilités apparaissent.
4. Fournisseurs tiers
Chaque fournisseur auquel vous faites appel fait partie intégrante de votre chaîne logistique. S'il livre des composants obsolètes ou compromis, vous en héritez le risque. Des SBOM complètes, incluant les dépendances transitives, vous permettent de comprendre rapidement votre exposition au risque plutôt que de devoir courir après les fournisseurs en cas d'incident. Un article récent intitulé « Managing Dependency Vulnerabilities in Your Software Supply Chain » ( Gérer les vulnérabilités liées aux dépendances dans votre chaîne logistique logicielle) explore comment les équipes peuvent renforcer cette partie du processus.
5. Supply Chain IA
En raison de l'adoption rapide de l'IA, les équipes contournent souvent les restrictions habituelles, ce qui en fait un vecteur d'attaque majeur. Les pirates injectent du code malveillant dans les modèles d'apprentissage automatique, les fichiers PICO ou les bibliothèques open source. Le typosquatting est courant dans des environnements tels que Pytorch, où les utilisateurs peuvent télécharger la mauvaise bibliothèque, ce qui peut entraîner l'installation de logiciels malveillants et l'exécution complète de code à distance sur l'ordinateur d'un ingénieur.
6.Container
L'analyse des conteneurs doit évoluer au-delà de la simple recherche des vulnérabilités. La sécurité moderne doit également rechercher les logiciels malveillants, les mineurs de cryptomonnaie et les menaces à action rapide publiés dans des images de conteneurs accessibles au public. Une analyse récente du NVIDIA Container CVE-2024-0132 montre à quel point ces problèmes peuvent être facilement négligés.
7. Fuite de secrets et d'informations d'identification
Lorsque les équipes travaillent rapidement, elles intègrent souvent des clés d'accès ou des identifiants dans le code source à des fins de test. Même s'ils sont ensuite remplacés, ces secrets restent souvent dans l'historique Git, où les pirates peuvent facilement les trouver en effectuant un scan. Démasquer les menaces cachées : comment détecter les secrets dans le code montre comment ces expositions se produisent et ce que les équipes peuvent faire pour les éviter.
La voie vers uneSupply ChainSoftware Secure
Pour contrer ces menaces, la sécurité doit adopter une mentalité « shift left », ce qui signifie que les mêmes politiques appliquées avant la mise en production doivent être appliquées plus tôt dans le cycle de développement. L'objectif est d'intégrer la sécurité en tant que couche supplémentaire au-dessus du pipeline CI/CD existant. Cette approche automatisée garantit l'application des mesures nécessaires, sans impact sur la productivité des ingénieurs.
Une solution complète doit fournir :
- Analyse automatisée de la chaîne logistique tout au long du pipeline
- Visibilité sur le code source, les conteneurs et les fichiers fournis par les fournisseurs
- Analyse qui va au-delà des CVE pour détecter les logiciels malveillants, les problèmes de licence et les secrets exposés
Comment OPSWAT combler ces lacunes
- Multiscanning détecter les logiciels malveillants dès le début du processus
- Portails de sécurité CI/CD intégrés pour GitHub, GitLab, TeamCity, Jenkins, etc.
- Génération automatisée de SBOM et cartographie des vulnérabilités
- Signature des artefacts et validation de leur intégrité
- Analyse des secrets et application des règles d'hygiène des identifiants
Discutez avec l'un de nos experts pour trouver dès aujourd'hui des solutions sur mesure pour votre pile.
