Les risques concernant la chaîne d'approvisionnement de logiciels que vous devez connaître

Le code créé par les développeurs d'une organisation ne constitue que le commencement du développement d'un logiciel moderne. En fait, la première partie du code est susceptible de n'être qu'une portion succincte d'une application ; parfois, elle ne constitue que 10 % de l'écosystème de l'artefact de l'application.

La chaîne d'approvisionnement de logiciels d'une entreprise comporte plusieurs éléments, puisés dans de nombreuses ressources : packages open source, logiciels commerciaux, fichiers infrastructure-as-code (IaC), conteneurs et images SE, entre autres. Cette diversité signifie que la chaîne d'approvisionnement que vous devez sécuriser comptabilise de nombreuses situations à risque et menaces en matière de sécurité en raison d'erreurs, de supervision, de mauvaise qualité ou d'attaque malveillante.

Les quatre tendances en matière de risque concernant la chaîne d'approvisionnement de logiciels

Il est important de comprendre où se trouvent ces situations à risque vulnérables pour sécuriser votre chaîne d'approvisionnement de logiciels. Mais les résoudre une par une avec des solutions uniques revient à jouer au jeu du chat et de la souris ; une menace éradiquée peut tout simplement réapparaître dans un autre endroit auquel vous n'auriez pas pensé.

La protection complète de votre chaîne d'approvisionnement de logiciels contre les menaces requiert une vigilance de bout en bout. Cela commence même avant que le développeur n'appelle un package externe ; cette protection est nécessaire dans le développement du code propriétaire, la compilation du code, les versions préliminaires, le pipeline, la publication, la distribution, la production, voire même après le déploiement. En plus de révéler simplement les vulnérabilités et d'autres problèmes de sécurité, vous devrez également connaître leur contexte afin de pouvoir évaluer le véritable risque.

Les menaces de la chaîne d'approvisionnement de logiciels peuvent être (approximativement) divisées en deux chemins principaux.

Le premier utilise la chaîne d'approvisionnement « nature ouverte » pour obtenir des informations sur le logiciel que l'attaquant entend cibler. Un exemple courant serait une tentative d'un adversaire de mapper un service Web à distance ou de déposer un logiciel pour des appareils IdO afin de se familiariser avec les packages open source qu'il utilise. Il peut ensuite facilement trouver des informations sur des CVE associés à de tels packages, en apprendre davantage sur les configurations de sécurité des packages, voire même tenter de trouver des vulnérabilités inconnues (appelées « zero day »). Lorsqu'il a suffisamment de connaissances sur les chemins d'exploitation, l'attaquant peut ensuite passer à la seconde phase.

Cette phase consiste à utiliser la chaîne d'approvisionnement pour injecter du code et des packages malveillants dans des dépôts publics ou privés, ou modifier du code existant et y intégrer des éléments malveillants.

Attaques de la chaîne d’approvisionnement de logiciels : Deux chemins principaux

Examinons quatre risques majeurs qui menacent la chaîne d'approvisionnement de logiciels et peuvent la rendre vulnérable aux attaques :

1. Vulnérabilités connues

Les composants de tiers, comme un logiciel commercial et open source, peuvent comprendre des vulnérabilités involontaires qui sont généralement connues et publiquement suivies dans la liste Common Vulnerabilities and Exposure (CVE, exposition et vulnérabilités courantes).

Vous pouvez révéler de tels risques avec une solution Software Component Analysis (SCA, analyse des composants du logiciel) qui identifie le SBOM d'un code donné ou artefact et l'associe avec des CVE connues, généralement en croisant les métadonnées du logiciel identifié avec les bases de données CVE publiques.

Mais vous devrez également avoir suffisamment d'informations pour pouvoir prendre des décisions basées sur les risques et les automatiser. Une base de données externe est un atout ; elle doit traquer non seulement plus de risques, mais inclure également une recherche de sécurité approfondie pouvant vous aider à comprendre toutes les options afin d'atténuer ces risques et vous permettre de choisir la méthode la plus pratique et la plus rentable.

Une analyse contextuelle qui identifie la probabilité qu'une vulnérabilité soit exploitée est tout aussi importante. Par exemple, la fonction vulnérable dans un composant ne peut pas être utilisée par l'application ou un processus vulnérable n'est jamais exécuté dans une version de production, ou une configuration spécifique rend une CVE donnée inutile.

Vous pouvez également reconnaître des risques opérationnels éventuels de composants qui semblent être sûrs. Par exemple, un package open source qui n'a pas été géré pendant un temps peut ne pas avoir été suffisamment surveillé pour repérer des problèmes de sécurité. Dans ces cas, les vulnérabilités sont incertaines, mais une menace potentielle peut être anticipée.

Ces risques anticipés et connus peuvent et devraient être repérés aux niveaux suivants :

Code source : faire un déplacement à gauche de la vigilance en matière de sécurité au moment où le code est créé peut éviter les coûts de réparation ultérieure. Les équipes de sécurité peuvent traiter un dépôt interne de composants tiers approuvés, et/ou les développeurs peuvent obtenir des alertes de dépendances vulnérables via des extensions à leurs IDE. Bien qu'incomplète, cette approche peut permettre d'éviter des risques connus. Elle ne peut cependant être entièrement exhaustive ; les outils de sécurité de déplacement à gauche surchargent généralement les développeurs avec des centaines, voire des milliers de tâches qui n'ont pas nécessairement d'impact au niveau de la sécurité, en l'absence de contexte global de la vulnérabilité ou du problème de sécurité.
Fichiers binaires : le scan SCA automatisé de tous les packages, builds et images dans les dépôts de fichiers binaires clés (dans les composants premiers et tiers) garantit que toute votre chaîne d'approvisionnement de logiciels est protégée contre les risques opérationnels et les vulnérabilités connus. Représentation la plus exacte de l'état de production de votre application, les fichiers binaires permettent l'analyse réelle de qualité optimale des risques et offrent un contexte plus précis. Ils permettent également d'analyser les problèmes qui sont des « angles morts » pour les outils de déplacement à gauche et les solutions de sécurité en production.

2. Vulnérabilités inconnues (« zero days »)

Les erreurs constituent une part quotidienne du codage. Les failles de logique, un mauvais chiffrement et des corruptions de mémoire potentielles rendent involontairement les applications vulnérables aux attaques malveillantes comme une exécution de code à distance (RCE) et une attaque par déni de service (DoS). Ces erreurs peuvent être non détectées dans le code principal ou tiers, parfois pendant des années.

Ces erreurs sont appelées des problèmes « zero day », en partie pour la période durant laquelle elles sont connues, mais aussi parce que leur urgence signifie que les équipes n'ont pas le temps de les corriger dans le logiciel déjà déployé.

Pour cerner et éviter les problèmes « zero day » potentiels, vous devez tester chaque composant et/ou application, en prenant en compte le flux entre les différents fichiers binaires, processus et services. Les outils d'analyse de code statique (pour examiner la source du code) et d'examen dynamique du code (pour tester le code exécuté) peuvent habituellement identifier environ 85 % des failles, mais ils peuvent générer des milliers d'entrées par version. Un savoir-faire est donc requis pour interpréter les résultats et les prioriser. Tout comme avec les problèmes connus, une vulnérabilité peut exister, mais cela ne signifie pas qu'elle est nécessairement exploitable.

Des technologies plus avancées qui combinent une exécution symbolique, une analyse du flux de données et un test à données aléatoires automatisé peuvent réduire considérablement le taux de faux positif et identifier les vulnérabilités qui ne peuvent pas être repérées par un SAST/DAST typique. La combinaison de l'analyse des fichiers binaires et source peut également produire de meilleurs résultats et permettre aux développeurs, équipes de sécurité et gestionnaires de production de se focaliser sur les corrections qui importent.

En dépit de tous les efforts, de nouvelles vulnérabilités peuvent toujours être potentiellement découvertes et impacter le logiciel déployé. Un scan SCA continu peut permettre de garantir une notification rapide des dernières CVE qui affectent le logiciel de production. Des métadonnées de logiciels de nomenclature riches vous permettent de connaître rapidement l'impact d'une vulnérabilité dans votre organisation et d'atténuer ou de résoudre le problème dans tout l'inventaire d'applications. Une intégration correcte avec les dépôts d'artefact et de code permet de prendre des mesures rapidement dans votre organisation et d'atténuer la menace identifiée.

3. Problèmes ne concernant pas le code

Toutes les vulnérabilités ne concernent pas le code ; elles peuvent apparaître dans les fichiers binaires comme les EPM, les conteneurs de fichiers JAR, les micrologiciels et les artefacts de soutien comme les fichiers de configuration ou les fichiers IaC. Des mauvaises configurations, un mauvais chiffrement, une exposition des secrets et clés privées ou des problèmes de système d'exploitation peuvent ouvrir une surface d'attaque.

Ces sous-produits de l'erreur humaine sont généralement dus à un manque d'attention plutôt qu'à une malveillance et sont généralement introduits en dehors du développement majeur. Les configurations constituées pour le test peuvent être inconsidérément envoyées en production. Ces risques sont souvent faciles à résoudre, mais difficiles à repérer et encore plus à réparer.

Même une bonne intention peut avoir des conséquences malveillantes. La plus célèbre est la violation SolarWinds qui a commencé avec un mot de passe exposé sur un serveur public GitHub, permettant l'injection d'un code malveillant qui a fini par dévoiler des données gouvernementales sensibles. Une confusion de dépendance entre des packages ayant des noms similaires peut également se produire sans malveillance, notamment lorsque la résolution de dépôt de package est mal configurée.

Il est capital de repérer rapidement ces problèmes avant qu'ils ne progressent dans la production. Vous devrez prendre ces risques potentiels au sérieux, autant que les vulnérabilités dans votre code, et intégrer cette vigilance dans la posture de sécurité de bout en bout de vos pipelines.

4. Code Malveillant

Les menaces intentionnelles, qu'elles soient dues à des attaques d'injection externes ou à des initiés malveillants, peuvent être les plus difficiles à trouver, car elles sont souvent masquées afin d'apparaître comme un composant déjà validé. Les chevaux de Troie, les bots, les rançongiciels, les cryptominers et les logiciels espions sont souvent délivrés comme des charges utiles via les types de vulnérabilités introduits avec une bonne volonté, comme vu ci-dessus. L'amorçage de dépôts populaires avec des packages nuisibles, le piratage de comptes de maintenance pour modifier des packages existants ou l'injection de code dans des dépôts source compromis sont des méthodes fréquemment utilisées qui permettent l'accès dérobé pour une attaque.

Il est généralement trop tard lorsque l'on trouve ces attaques après le déploiement ; les dommages ont été causés et ils peuvent être vraiment onéreux. C'est pourquoi vous devriez vous protéger dans tout votre pipeline :

Contrôle de l'accès : les dépôts de packages internes doivent limiter l'accès en écriture aux rôles clés et aux membres de l'équipe via des autorisations et une authentification sécurisée (y compris l'authentification multi-facteur) cohérentes dans toute l'organisation.
Dépôts de proxy : la mise en cache des dépôts externes (comme Maven Central et npm) peut fournir une capture immuable des ressources tierces afin que tout écrasement malveillant ultérieur soit immédiatement évident.
Test et analyse : les outils d'analyse dynamique et statique sophistiqués peuvent détecter et repérer le code malveillant, ainsi que les comportements malveillants de packages douteux. L'équipe de recherche en matière de sécurité de JFrog a détecté et divulgué plus de 1 300 packages malveillants dans des dépôts de packages publics grâce à des outils qu'elle a développés.

Une vigilance intégrale pour la gestion des risques de la chaîne d'approvisionnement de logiciels

Bien que certaines de ces tendances de risques puissent être gérées une à la fois, les solutions sont simplement des systèmes d'alarme et uniquement utiles là où vous pensez à les placer.

Pour la même raison, des solutions de sécurité séparées ont une utilité limitée car leur portée réduite ne peut pas vous permettre d'analyser et d'évaluer le contexte global d'un risque dans toute la chaîne d'approvisionnement de logiciels. Lorsque vous êtes déconnecté des dépôts et des solutions de gestion de logiciels, même si les solutions de sécurité sont très précises, il serait extrêmement difficile de prendre des mesures efficaces pour résoudre et atténuer le problème identifié.

Une posture de sécurité exhaustive ne peut pas simplement se focaliser sur des points isolés de votre pipeline ; elle doit vous permettre d'établir un lien entre les différents problèmes et les constatations en matière de sécurité ; chose que les solutions de niche séparées ne peuvent pas faire.

La sécurité des logiciels requiert une vigilance intégrale, des IDE des développeurs à la production, imposant une surveillance des risques constante et permettant la mitigation des environnements de développement et de production. Vos solutions de sécurité doivent agir globalement sur votre chaîne d'approvisionnement de logiciels et vous permettre de prendre des mesures à grande échelle. Afin de sécuriser de manière cohérente votre organisation, elles doivent agir contre une source d'informations unique pour tous vos fichiers binaires et être bien intégrées avec des outils DevOps.

Vous souhaitez en savoir plus sur « ce qui se passe ensuite » avec JFrog pour répondre à ces besoins ? Inscrivez-vous à l'un des événements swampUP City Tour qui aura lieu près de chez vous !