L'un des risques de la chaîne d'approvisionnement en logiciels est la fuite de secrets. Les secrets sont omniprésents dans la chaîne d'approvisionnement des logiciels ; les développeurs et les pipelines CI\CD doivent utiliser des secrets pour accéder au SCM, au pipeline, aux registres d'artefacts, aux environnements cloud et aux services externes. Et quand les secrets sont partout, ce n’est qu’une question de temps avant qu’ils ne soient divulgués.
Ce risque est bien identifié et de nombreux cadres de chaîne d'approvisionnement logiciels y répondent en exigeant une analyse des secrets et une auto-expiration des secrets.
Alors, qu’est-ce qui pourrait mal se passer si vous, en tant que praticien de la sécurité, aviez mis ces garde-fous en place ?
Cette semaine, en recherchant des outils d'analyse secrets, je suis tombé sur une réponse. Cette réponse est simple : étant donné que les scanners de secrets recherchent des modèles de secrets, lorsque le format du secret change, la détection peut échouer. Et c'est exactement ce qui s'est passé lorsque GitHub a introduit une nouvelle fonctionnalité de sécurité : le jetons à grain fin. Cette fonctionnalité bêta est l'un des moyens utilisés par GitHub pour réduire les risques de fuite de secrets ; limiter les autorisations des jetons d'accès personnels limite également les risques si ces secrets avaient été compromis.
Il s'avère que le format des nouveaux jetons est un peu différent, alors que le format des anciens jetons ressemblait à ceci :
ghp_123456789012345678901234567890123456
Le nouveau format de jeton ressemble à :
github_pat_123456789012345678901234567890123456789012345678901234567890…
Le préfixe et la longueur du secret sont différents.
Et en effet, certains scanners secrets ne parviennent pas à détecter le nouveau format ;
Pour expérimenter, j'ai créé un dépôt avec un Dockerfile avec un secret et un workflow qui exécute l'action Trivy. Voici à quoi ressemble le Dockerfile au début de l'expérience :
Voici un instantané du GitHub Secret Scanner, qui détecte le secret nouvellement formaté :
Comme nous pouvons le voir, le scanner de secrets de GitHub détecte le secret, mais aucune alerte n'apparaît dans la section Analyse du code.
Pour vérifier que les outils sont correctement définis, je vais maintenant ajouter un secret classique au Dockerfile (voir ci-dessous) et relancer l'analyse. Nous recevons maintenant une alerte d'analyse de code (uniquement sur le secret classique !)
Le scanner de Github, en revanche, détecte désormais deux secrets :
J'ai ouvert un problème de sécurité pour Trivy ; L'équipe de Trivy a répondu qu'il ne s'agissait pas d'une vulnérabilité ni d'un problème de sécurité. Il ne restait plus qu'à ouvrir un numéro.
Cette expérience soulève de nombreuses inquiétudes ;
- Pourquoi un utilisateur de GitHub devrait-il soupçonner que le format du jeton serait modifié en raison d'une nouvelle fonctionnalité ?
- Étant donné que les secrets sont censés ressembler à des chaînes aléatoires, pourquoi un utilisateur de GitHub devrait-il se soucier du format des secrets ?
- GitHub devrait-il être responsable d’informer ses clients d’un tel changement ?
- Cet échec de détection de secrets est-il une vulnérabilité des secrets fins de GitHub, une vulnérabilité de Trivy ou, comme le voit Aqua Security, pas une vulnérabilité du tout ?
- Aqua Security, la société derrière Trivy, devrait-elle être responsable de sa mise à jour ?
- Puisque Trivy est un projet open source, fourni tel quel, quelqu'un serait-il responsable si des secrets avaient été divulgués d'un pipeline protégé par Trivy ? Qui serait-ce ? GitHub ? Aqua-sécurité ? L'utilisateur de Trivy ?
- Que nous apprend cette expérience sur la confiance dans les outils de sécurité installés pour protéger les chaînes d’approvisionnement logicielles ?
Je laisserai ces questions ouvertes.
Une chose est cependant claire; protéger la chaîne d’approvisionnement des logiciels est compliqué et nous avons besoin d’une communauté hautement professionnelle pour réussir durablement dans cette tâche.
Cet article a été co-écrit par Avi Waxman, stagiaire chez Scribe Security
Ce contenu vous est proposé par Scribe Security, l'un des principaux fournisseurs de solutions de sécurité de bout en bout pour la chaîne d'approvisionnement logicielle, offrant une sécurité de pointe aux artefacts de code ainsi qu'aux processus de développement et de livraison de code tout au long des chaînes d'approvisionnement logicielles. En savoir plus.
articles similaires
