CICD-SEC-9 : validation d’intégrité des artefacts défaillante

Neuvième entrée du Top 10 OWASP CI/CD. Libellé officiel : Improper Artifact Integrity Validation. Le risque porte sur les jonctions de la chaîne : un processus de livraison est fait d’étapes successives, chacune nourrie par des ressources internes et tierces récupérées à distance. Le produit final dépend donc de multiples sources, étalées sur plusieurs étapes, fournies par plusieurs contributeurs : autant de points d’entrée par lesquels il peut être altéré.

→ Lire l’explication complète de la marmotte

Le mécanisme : ce qui passe une fois passe jusqu’au bout

La phrase du référentiel est la plus économique du document : si une ressource altérée s’infiltre dans le processus de livraison sans éveiller de soupçon ni rencontrer de barrière de sécurité, elle continuera très probablement à couler jusqu’en production, sous l’apparence d’une ressource légitime. Il n’y a pas d’attaque à décrire : un contrôle qui n’existe pas, un flux qui fait son travail. Les précédents cités montrent les quatre endroits où l’altération se produit.

Pendant la construction, sans toucher au code source. C’est SolarWinds : le code a été modifié dans le système de construction au moment de la construction, sans laisser de trace dans la base de code. Détail décisif, car il annule la défense à laquelle on pense d’abord : relire le dépôt ne sert à rien si l’altération a lieu après la récupération du dépôt.

Dans une ressource tierce récupérée par le pipeline. C’est Codecov : les attaquants ont obtenu l’accès au compte cloud hébergeant le script de l’outil et l’ont modifié. L’attaque a été identifiée par un client qui a comparé le condensat du script publié sur le dépôt de code à celui du script réellement téléchargé. À retenir tel quel : la détection n’est pas venue d’un outil de sécurité, mais d’une comparaison que cette entrée demande d’automatiser.

Dans un commit qui se fait passer pour un autre. C’est PHP : du code non relu poussé sur la branche principale, les commits étant enregistrés comme s’ils venaient de contributeurs connus du projet. L’identité d’auteur d’un commit est un champ de texte, et c’est ce que la signature corrige.

Dans une restauration. C’est Webmin, le cas le plus désagréable : une porte dérobée ajoutée à un script du projet a persisté après la mise hors service du serveur de construction compromis, le code ayant été restauré depuis une sauvegarde locale plutôt que depuis le gestionnaire de code source. Les utilisateurs y sont restés exposés plus de quinze mois. La leçon dépasse l’entrée : une sauvegarde n’est pas une source de vérité, et la tactique de persistance se nourrit de cette confusion.

Le même raisonnement s’applique au dépôt d’artefacts, jonction la plus facile à forcer : un paquet déposé à la main, ressemblant à ce que l’environnement de construction produit, est ramassé par le pipeline de déploiement comme s’il en sortait. C’est aussi une variante de CICD-SEC-1, et les deux entrées se recoupent volontairement : l’une décrit l’absence d’approbation, l’autre l’absence de vérification.

Ce que l’attaquant obtient

L’exécution de code malveillant, sur les systèmes de la chaîne ou, pire, en production. L’adversaire n’a besoin que d’un pied dans le processus de livraison, à n’importe quelle étape, pour faire voyager un artefact jusqu’au bout.

La gravité de l’entrée tient à l’apparence de légitimité acquise en chemin. L’artefact a été construit par le bon système, enregistré par le bon compte de service, déployé par le bon pipeline : son dossier est en règle, et c’est ce dossier que l’on consulte pendant une enquête. Sujet traité plus largement dans les attaques sur la chaîne d’approvisionnement.

Ce qu’on peut détecter, et par quoi

L’écart entre un condensat local et le condensat publié par le fournisseur. La détection qui a révélé Codecov, calculable à chaque exécution ; le principe est décrit dans le hachage et l’intégrité des systèmes.

Les commits non signés, non comme alerte mais comme condition de passage : un dépôt où la signature est exigée rend le cas PHP impossible, et la détection devient un refus.

La dérive de configuration en production, que le référentiel nomme explicitement comme mesure d’intégrité : une ressource cloud non gérée par un modèle d’infrastructure signé indique un déploiement par une source non fiable. L’inventaire réel contre la dérive décrit la méthode, la sécurité du code d’infrastructure le versant modèle.

Les artefacts sans attestation de provenance, à traiter comme suspects par défaut : c’est l’objet des attestations décrites dans les niveaux SLSA.

L’écart entre deux constructions du même code, enfin, détection la plus fondamentale et la plus difficile : si une construction est reproductible, toute différence est un signal, et la difficulté des builds reproductibles dit pourquoi ce signal manque presque toujours.

Ce que le défenseur fait

La recommandation générale tient en une boucle : lorsqu’une ressource est produite, la signer au moyen d’une infrastructure de signature externe ; avant de la consommer à l’étape suivante, valider son intégrité auprès de l’autorité de signature. Le reste applique cette boucle aux différents objets.

Signer les commits. Les gestionnaires de code source permettent de signer avec une clé propre à chaque contributeur, et cette signature sert ensuite à empêcher les commits non signés de descendre dans la chaîne. Seule mesure qui ferme la falsification d’identité d’auteur : signer commits et artefacts, qui dit aussi ce que la signature ne garantit pas.

Signer et vérifier les artefacts avec un outillage dédié : le référentiel nomme in-toto, SLSA et Sigstore, tous hébergés par la Linux Foundation. Le site traite l’attestation de provenance dans les niveaux SLSA et le geste complet dans signer et vérifier les artefacts de build ; quand la clé mérite un matériel dédié, c’est l’intégration d’un HSM à la signature CI/CD.

Vérifier le condensat de toute ressource tierce récupérée par un pipeline, scripts importés et exécutés compris, en le comparant au condensat officiel publié par le fournisseur : une ligne de contrôle qui aurait transformé Codecov en incident sans victime. Et détecter les dérives de configuration pour corriger toute ressource qui en présente une, version « production » du même principe.

Et restaurer depuis le code source, jamais depuis une sauvegarde locale : le référentiel ne le formule pas, le cas Webmin l’impose. La nomenclature logicielle aide à savoir ce qu’on a reconstruit : savoir ce qui tourne vraiment, la générer dans la chaîne.

Sources

CICD-SEC-9: Improper Artifact Integrity Validation, OWASP Top 10 CI/CD Security Risks, 2022 : définition, recommandations, mention d’in-toto, SLSA et Sigstore, et les incidents SolarWinds, Codecov, PHP et Webmin.

🐝 Ce qui arrive si on s’en passe

Sans validation d’intégrité, un paquet déposé à la main dans le dépôt d’artefacts est ramassé par le pipeline de déploiement comme s’il sortait de l’environnement de construction. Le journal n’enregistre pas une anomalie mais un déploiement, et « quand cet artefact est-il entré » reste sans réponse, faute d’un registre distinguant ce qui a été produit de ce qui a été déposé.

Le second coût est l’impossibilité de reconstruire la confiance après coup. Quand on apprend qu’une altération a eu lieu dans les six derniers mois et qu’aucune étape n’a signé son résultat, rien ne permet de désigner les artefacts sains : il faut tout reconstruire, depuis un code source dont on ne sait pas non plus s’il est intact, les commits n’étant pas signés. Le cas Webmin montre la variante la plus coûteuse de cette impasse : quinze mois d’exposition pour une erreur de procédure de restauration.

🦫 Explication de la marmotte 🍫

Un logiciel livré aux clients n’est pas fabriqué d’un seul geste : il passe par une série d’étapes, chacune recevant des morceaux venus d’ailleurs, écrits par des gens différents, parfois téléchargés sur Internet au moment de la fabrication. Entre ces étapes, il y a des jonctions, et une jonction est un endroit où l’on peut glisser quelque chose.

Le défaut décrit ici consiste à ne rien vérifier à ces jonctions. La conséquence est énoncée par les auteurs en une phrase : ce qui entre dans la chaîne sans être arrêté continue jusqu’au bout et arrive chez le client avec les apparences d’un produit normal. Le dossier est en règle : la bonne machine l’a fabriqué, le bon compte l’a enregistré, le bon programme l’a installé.

Quatre incidents publics montrent les quatre jonctions. Chez un éditeur de logiciels d’administration réseau, le code a été modifié pendant la fabrication, sans que le dépôt en garde trace : relire le code source ne servait à rien. Chez un fournisseur d’outil de mesure de qualité, le petit programme que ses clients téléchargeaient à chaque fabrication a été remplacé, et l’affaire a été découverte par un client qui a comparé l’empreinte du programme annoncé à celle du programme reçu. Dans le projet d’un langage très répandu, des modifications ont été enregistrées sous le nom de contributeurs connus, ce qu’un simple champ de texte permet. Et dans un outil d’administration de serveurs, une porte dérobée a survécu à la mise hors service de la machine compromise, le code ayant été restauré depuis une sauvegarde locale au lieu du dépôt officiel : plus de quinze mois d’exposition.

La réponse est une boucle simple à énoncer et longue à installer : chaque fois qu’une étape produit quelque chose, elle le signe ; chaque fois qu’elle reçoit quelque chose, elle vérifie la signature avant de s’en servir. Avec deux compléments : signer aussi les modifications de code, pour que personne ne se fasse passer pour un autre ; et comparer l’empreinte de tout ce qu’on télécharge à celle que son fournisseur publie, l’exacte vérification qui a permis de découvrir le second incident.

Pages voisines

La citent

CICD-SEC-4 : exécution de pipeline empoisonnée

CICD-SEC-9 : validation d'intégrité des artefacts défaillante

Elle cite

: les deux pages se citent l’une l’autre.