Sécuriser la chaîne d’approvisionnement des logiciels Kubernetes

Les pratiques modernes d’avancement des applications logicielles rendent la sécurisation de la chaîne d’approvisionnement des applications logicielles plus cruciale que jamais. Notre code a des dépendances sur des bibliothèques open source qui ont des dépendances sur d’autres bibliothèques et ainsi de suite – une chaîne de code que nous n’avons pas développée, n’avons pas assemblée et n’avons que peu ou pas de concept d’où elle provient.

Une partie de ce code est presque omniprésente. L’exploit Log4Shell qui a causé des ravages sur le marché provenait d’une utilisation résultant d’un ancien bogue dans une partie de journalisation Java typique, log4j. Nous construisons un marché qui ne repose pas sur les épaules de géants, mais sur les épaules d’une poignée de mainteneurs d’applications et d’éléments qui font fonctionner notre infrastructure mondiale pendant leur temps supplémentaire et par bonté de cœur.

Le développement dispersé comprend des dangers

Ceci n’est pas pour diminuer le travail des mainteneurs ; ils sont un élément essentiel de la chaîne d’approvisionnement des applications logicielles modernes, fournissant tout, des petits modules aux plates-formes entières basées sur des conteneurs. Ils sont sous-évalués et sous-payés pour l’importance de leur code. Malheureusement, il y a eu un certain nombre de circonstances où de mauvaises stars ont en fait pris le contrôle de la conservation du code, uniquement pour inclure des logiciels malveillants, s’attendant à ce que le code soit installé automatiquement car il avait l’habitude d’être crédible.

Nous peut s’attendre à voir plus d’attaques comme celles-ci car une plus grande partie de notre code finit par être un effort de groupe. Comment nous protégeons-nous ainsi que nos applications ? Premièrement, nous devons comprendre que la chaîne d’approvisionnement logicielle existe en réalité, que nous ne développons pas de code de manière isolée, et nous ne l’avons pas fait depuis longtemps maintenant, si jamais nous l’avons fait. Les bibliothèques open source et tierces sont une partie essentielle de la façon dont nous créons des logiciels, et elles ne feront que gagner en importance.

De quelles étapes pouvons-nous avoir besoin pour sécuriser la chaîne d’approvisionnement des applications logicielles ? Beaucoup de travail a été consacré à l’offre d’outils permettant de gérer les coûts logiciels des produits : numériser le code pour les bibliothèques, utiliser une analyse fixe et dynamique, y compris les signatures numériques et les hachages pour coder, et tout intégrer dans des référentiels gérés. Il manque une partie de l’image : comment valider ce travail et confirmer le code que nous utilisons ? L’un des anciens adages de sécurité reste « faire confiance mais vérifier ».

Sécurisation de la chaîne d’approvisionnement des applications logicielles

Nous devons nous fier au code que nous utilisons, mais nous devons également confirmer que c’est fiable. Nous devons également le faire sous la pression du temps, avec le code natif du cloud expédiant de toutes nouvelles versions au fur et à mesure que le code dans les référentiels change. La nature automatisée de l’avancement moderne est la clé ici, avec des plates-formes telles que GitHub au cœur de notre processus de vie logicielle, offrant une intégration continue et une livraison constante (CI/CD).

Les choses deviennent plus complexes lorsque nous ‘traitent des innovations telles que Kubernetes, qui sont créées pour s’appuyer sur l’approche mix-and-match des architectures et des conteneurs de microservices. Bien que notre code puisse s’exécuter dans des conteneurs séparés, il s’exécute dans des zones utilisateur abstraites imbriquées, chaque fichier docker collectant une sélection de dépendances, dont la plupart ne sont pas complètement documentées. Comment pouvons-nous faire confiance à la nomenclature des produits dans les conteneurs que nous utilisons ?

Présentation de Ratify : un workflow de vérification des artefacts

L’équipe open source cloud native de Microsoft a fait face à une toute nouvelle exigence qui doit aider à cela. Validate est un framework de vérification qui prend en charge les différents artefacts qui se réunissent dans les applications Kubernetes. Il utilise un ensemble de métadonnées de sécurité fiables et une nomenclature signée pour garantir que tout ce que vous déployez correspond à ce que vous vous attendez à déployer.

Les images et autres composants tirent le meilleur parti de la signature et de la confirmation Notary V2. et la spécification d’artefact ORAS (OCI Windows Registry As Storage). ORAS fait partie du registre Windows Open Container Effort, ce qui signifie qu’il permet de conserver n’importe quoi, pas simplement des conteneurs. Cela fonctionne bien comme méthode d’assemblage d’une dépense logicielle de produits. Étonnamment, il y a une similitude entre la signification d’un programme d’installation d’application distribué par Bindle et un manifeste ORAS, ce qui facilite le passage d’un SBOM à un programme d’installation d’application distribué validé. Ensemble, les 2 fournissent un graphique de la chaîne d’approvisionnement qui peut être analysé et utilisé dans le cadre d’un schéma de vérification au sein d’un cluster Kubernetes.

Ratifiez ensemble ces principes, y compris un moteur de workflow pour appliquer des politiques à vos dépenses logicielles de matériaux, en vérifiant diverses chaînes d’approvisionnement tout au long de votre code et de ses dépendances. En son cœur se trouve un planificateur qui gère le flux de travail de la politique dans l’ensemble de votre image de conteneur. Il est extensible, de sorte qu’il peut fonctionner dans tous les registres d’ordinateurs publics et personnels, en utilisant une conception de plug-in familière similaire à celles utilisées dans Kubernetes.

Ratification basée sur des politiques

Le modèle de politique utilisé par Ratify est basé sur des outils familiers, offrant un moyen de présenter rapidement des politiques de base en utilisant vos propres configurations ainsi que des politiques plus complexes développées à l’aide du représentant Open Policy. Il fonctionnera également à différents moments du cycle de vie de développement de votre application, en se connectant aux systèmes CI/CD pour vérifier les artefacts au moment de la construction et dans Kubernetes pour s’assurer que le code n’a pas été modifié entre la construction et l’exécution. Il est important d’avoir un mode de vérification qui fonctionne sur l’ensemble de votre pile, garantissant que vous empêchez les attaques de la chaîne d’approvisionnement qui peuvent arriver au code lors du développement, dans les référentiels et les registres Windows, et lors de l’exécution.

Avoir un seul outil avec une confirmation tout au long du cycle de vie de votre application logicielle est très important car cela garantit que vous n’avez qu’à rédiger des politiques à quel moment. Divers outils pour différentes situations incluent la menace d’erreurs de transcription et de traduction dans les politiques ; avoir un seul outil et un seul format de politique permet d’éviter ce risque. Vous pouvez également disposer d’un outil externe de filtrage des politiques qui peut vous aider à enquêter sur les « et si » avant de livrer votre code.

Structurer votre toute première politique Ratify

L’équipe Ratify a du code de démonstration dans son référentiel GitHub qui montre comment utiliser Ratify avec Gatekeeper dans Kubernetes. Ratify installe à l’aide d’un graphique Helm, en apportant quelques exemples de modèles de configuration. Vous pouvez les utiliser pour vérifier les opérations de Ratification, par exemple, en obstruant toutes les images qui n’ont pas de signature. Gatekeeper rejettera toutes les images de conteneur qui ne sont pas signées, ce qui les empêchera de s’exécuter.

Les fichiers de stratégie sont écrits en YAML, vous pouvez donc les modifier dans Visual Studio Code ou d’autres outils, en tirant le meilleur parti du format de code outils. Ils constituent un moteur de règles simple, faisant passer les artefacts à travers une confirmation. Proviennent-ils d’un registre de système informatique approuvé ? Inspectez-vous un artefact plus que quand pour différentes signatures ? Les artefacts de votre propre registre d’ordinateurs privés sont-ils plus fiables que les artefacts des registres d’ordinateurs publics ? Tous vos moteurs de vérification concordent-ils lorsque vous exécutez plusieurs vérifications ? Il s’avère que les règles pour une confirmation d’exécution sont assez faciles à définir, bien que ce ne soit probablement pas le cas pour une exécution dans un système CI/CD où vous devez déterminer l’état de plusieurs artefacts et avec des signatures de nombreuses racines différentes de confiance.

Valider est actuellement une proposition préliminaire intéressante d’un ensemble d’outils pouvant gérer tous les éléments d’une nomenclature d’application logicielle. Bien qu’il n’évite absolument aucun jour d’impacter des bogues cachés depuis longtemps, il peut rapidement identifier le code affecté, en développant des directives pour éviter qu’il ne soit utilisé et exécuté.

Avec les risques de la chaîne d’approvisionnement très mis en lumière , il est essentiel pour l’industrie d’examiner attentivement de telles propositions et d’y travailler dans les espaces publics. Il est bon de voir que Microsoft s’est déjà consacré au partage de Ratify avec la structure d’informatique native du cloud, où il devrait obtenir l’analyse de la communauté de développement Kubernetes plus large dont il a besoin.