La sécurité de Kubernetes soumise aux risques de la supply chain logicielle
Si Kubernetes demeure relativement préservé des failles de sécurité, l’écosystème et la supply chain qui sous-tendent le déploiement de l’orchestrateur sont soumis à des risques majeurs de compromission.
Kubernetes et l’approche « cloud native » sont au centre de l’évolution fulgurante ayant eu lieu au cours de la dernière décennie, celle qui a entraîné l’adoption massive de l’open source par les entreprises. En parallèle, les problèmes de sécurité liés à la chaîne logistique logicielle se sont multipliés.
Quatre des 17 secteurs industriels mentionnés dans le rapport annuel « Open Source Security Analysis 2022 » de Synopsys emploient l’open source dans 100 % de leurs bases de codes. Les treize autres secteurs utilisent de l’open source dans 93 à 99 % de leur code source.
Depuis l’attaque de Solarwinds fin 2020, une série d’exploits s’appuyant sur des failles dans du code libre ont fait beaucoup de bruit. Surtout, les chercheurs ont révélé les problèmes de cybersécurité considérables que lèvent ces chaînes d’approvisionnement alambiquées.
Fin 2021, la vulnérabilité de Log4j a démontré comment des bibliothèques open source embarquées dans d’autres dépendances pouvaient être utilisées dans des attaques potentiellement dévastatrices et difficiles à détecter. Les entreprises ont eu du mal à déterminer et à localiser la présence de bibliothèques vulnérables dans leurs environnements.
Dans ce contexte, Kubernetes lui-même reste un refuge relativement sûr en raison de sa communauté importante et très investie, selon le rapport de Synopsys. Mais beaucoup d’autres composants open source s’intègrent dans l’écosystème Kubernetes, y compris de petits projets soutenus par un seul développeur, dont la maintenance – ou le manque de maintenance – peut fragiliser la plateforme au sens large.
« GitHub compte des millions de projets supportés par moins de dix développeurs », selon le rapport de Synopsys. « L’une des leçons à tirer de la découverte de Log4Shell devrait être la nécessité de mettre en place un plan pour atténuer le risque opérationnel lié à l’utilisation de logiciels open source. Il est important de noter qu’en soi le logiciel libre ne crée pas de risque pour les entreprises, mais sa mauvaise gestion, si ».
Kubernetes + déploiements automatisés = risques pour la chaîne d’approvisionnement
SolarWinds a été compromis via son processus CI/CD, et d’autres vulnérabilités récemment découvertes dans des composants open source ont, elles aussi, tirées partie des mécanismes de déploiement et de mise à jour automatisés. Des chercheurs ont démontré que ces dispositifs pouvaient être trompés afin de placer stratégiquement des paquets malveillants dans les dépôts de code publics.
Le rapport 2 022 « Cloud Native Threat Report » publié le 20 avril par Aqua, un éditeur spécialisé dans la sécurisation des conteneurs, décrit un tel exploit. Il a été présenté par un chercheur en février 2021, qui a inséré du code malveillant dans un dépôt public et officiel, sous le même nom de paquet que les dépendances populaires.
« En donnant à ses paquets malveillants des numéros de version supérieurs à ceux des paquets authentiques, [le chercheur] a trompé les processus de construction pour qu’ils téléchargent et intègrent automatiquement la dépendance malveillante », indique le rapport d’Aqua.
Après la publication de cette première étude, d’autres chercheurs ont placé 150 paquets de ce type dans NPM ; les analyses effectuées par Aqua sur 30 000 paquets Python ont permis d’en trouver plus de 170 comportant des fonctions suspectes ou malveillantes.
Kubernetes a été ciblé 10 % plus souvent par les attaquants en 2021 que l’année précédente, mais cela semble bien dérisoire en comparaison de la croissance des attaques de la chaîne logistique logicielle qu’Aqua a estimée à 300 %, d’une année sur l’autre. Cependant, lorsque les attaquants trouvent des vulnérabilités qui peuvent être utilisées pour infiltrer la plateforme Kubernetes, cela peut générer des effets de bord massifs. De fait, l’orchestrateur est très largement utilisé par les entreprises dont les SI sont interconnectés via des API hébergées dans le cloud.
Ainsi, les politiques de sécurité de Kubernetes doivent porter sur le code brut et les images de conteneurs de base dès le début du processus de développement, une pratique connue sous le nom de « shift left ».
« Vous devez commencer dès le début, lorsque le code est créé et que vous intégrez ces bibliothèques open source dans vos [applications] », recommande Janet Worthington, analyste chez Forrester Research. « Et ce n’est pas seulement une pratique ponctuelle, car les bibliothèques open source peuvent être déployées dans votre projet à différents moments ; et une [vulnérabilité] de type zero-day peut être trouvée à tout moment ».
Ici, la sécurité de Kubernetes croise un autre problème plus général : les approches bien intentionnées, mais malavisées du shift left peuvent créer plus de travail pour les développeurs et les submerger rapidement, aggravant les mauvaises configurations et autres erreurs.
L’enquête « 2022 Open Source Software Supply Chain Survey », publiée le 13 avril par le spécialiste du suivi de dépendance open source Tidelift, suggère que de nombreux développeurs sont dépassés par la gestion des logiciels open source en raison des préoccupations croissantes en matière de sécurité.
La sécurité de l'open source est la priorité numéro 1 des développeurs, selon un sondage mené récemment par Tidelift.
« Nous posons des questions similaires depuis plusieurs années dans ces enquêtes, et chaque année, les trois principaux défis cités par les répondants sont liés à la maintenance, à la sécurité et aux licences », selon le rapport de Tidelift. « Dans notre enquête précédente, la maintenance avait été le défi n° 1, mais cette année – sans surprise – la sécurité a pris la première place ».
L’identification et la résolution des vulnérabilités de sécurité est la principale préoccupation citée par 57 % des 691 répondants à l’enquête, suivie par la prise de bonnes décisions quant au moment de mettre à niveau les composants et les frameworks open source (54 %), et le choix des bons composants et versions des logiciels open source à utiliser (53 %). Ces problèmes sont aggravés par un manque de clarté quant aux composants libres qu’ils peuvent utiliser en toute sécurité et qui sont approuvés au sein de leur organisation pour 33 % des répondants.
SBOM et SCA gagnent en popularité
En réponse à cet engorgement, certaines entreprises ont créé des équipes d’ingénieurs chargés de la fiabilité des sites et des plateformes DevOps (SRE) afin d’offrir aux développeurs un « chemin pavé » de la création du code à la production. Ces approches déplacent la sécurité et d’autres fonctions dans le pipeline de développement, mais administrent la plupart des détails de la mise en œuvre pour le compte des développeurs.
Aujourd’hui, un nombre croissant de produits intègrent des contrôles de sécurité de la supply chain dans ces plateformes DevOps. Ceux-ci sont souvent des outils d’analyse de la composition logicielle (SCA) et de nomenclature logicielle (SBOM) qui détaillent exactement les bibliothèques que contiennent les utilitaires open source. Certaines de ces solutions peuvent également détecter les codes malveillants et remédier les pipelines mal configurés.
Selon Janet Worthington de Forrester, le décret présidentiel de l’année dernière, concernant la sécurité de la chaîne logistique logicielle, les réseaux zéro confiance et l’authentification multifacteur, a considérablement augmenté le rayonnement des outils SCA et SBOM.
« Pour une fois, le gouvernement fédéral a devancé l’industrie », remarque-t-elle. « En disant “préoccupez-vous davantage de la cybersécurité”, le gouvernement fédéral américain a poussé les entreprises à réclamer des SBOM à d’autres sociétés, alors qu’elles ne les exigeaient pas il y a seulement deux ans ».
Cependant, les outils SBOM n’en sont encore qu’à leurs débuts et le marché est dans une phase de croissance qui nécessitera une consolidation avant d’arriver à maturité, prévient-elle. Les entreprises doivent également affiner les flux de travail pour utiliser efficacement les produits SCA et les SBOM.
« Les entreprises veulent savoir jusqu’à quel niveau elles peuvent connaître les dépendances transitives, et souhaitent avoir un moyen pour analyser les différentes nomenclatures logicielles », indique l’analyste de Forrester. « Une fois que vous avez tous ces SBOM, et qu’il y a une [vulnérabilité] de type “zero-day”, la question devient : “Comment gérez-vous tout cela ? Comment rechercher certaines choses dans tous les SBOM ?” ».
Google couple le framework SLSA avec Sigstore
L’année dernière, un sous-groupe de la Linux Foundation, appelé Open Source Security Foundation (OpenSSF), a levé 10 millions de dollars pour faire avancer des projets de sécurisation de la supply chain logicielle tels que Sigstore et le framework SLSA (Supply chain Levels for Software Artifacts) de Google.
Ces projets demeurent jeunes, mais ils sont encourageants pour les analystes du secteur et les utilisateurs finaux.
Récemment, Google et GitHub ont dévoilé une architecture de référence, qui montre comment combiner les flux GitHub Actions avec les outils de Sigstore pour vérifier la provenance des composants open source, afin de se conformer au cadre SLSA.
« Deux brèches majeures, SolarWinds et Codecov, ont toutes deux démontré qu’une faille dans la conception et la distribution du code peut entraîner de nombreuses compromissions chez les clients en aval ».
Daniel KennedyAnalyste, 451 Research
« Le projet SLSA et la présentation d’une architecture de référence qui prend en charge ses diverses exigences sont d’une importance capitale », avance Daniel Kennedy, analyste chez 451 Research, une division de S&P Global. « Deux brèches majeures, SolarWinds et Codecov, ont toutes deux démontré qu’une faille dans la conception et la distribution du code peut entraîner de nombreuses compromissions chez les clients en aval ».
Un utilisateur de Google Cloud, qui contribue également à des projets de sécurisation dans les communautés Drupal et PHP, envisage que l’architecture de référence Google/GitHub pourrait aider ces communautés à sécuriser également les chaînes d’approvisionnement en logiciels.
« Il semble que cela gère réellement la partie [de la confiance numérique] sur laquelle je ne travaille pas », affirme David Strauss, cofondateur et directeur technique de Pantheon.io, une plateforme d’opérations web à San Francisco. « Nous serions en mesure de configurer quelque chose sur GitHub Actions, de le faire signer à l’aide de clés de Sigstore, puis d’intégrer cela avec la partie déploiement sur laquelle j’ai travaillé pour vérifier ces signatures ».
Sigstore et l’architecture de référence Google/GitHub s’attaquent aux premières phases du processus de création de logiciels, les phases d’une supply chain sécurisée les plus difficiles à mettre en place, explique David Strauss.
« Lorsque j’ai effectué le travail initial pour Drupal trust, nous avons littéralement distribué des jetons matériels – les gens y faisaient parfois référence comme à une cérémonie ou un ensemble de cérémonies autour de la gestion de ces jetons », raconte David Strauss. « Une technologie comme Sigstore élimine une grande partie de la difficulté et de l’incertitude à ce sujet ».
