Aikido

Guide pratique pour se prémunir contre attaques de la chaîne d’approvisionnement

Une liste de contrôle pratique destinée aux équipes d'ingénieurs confrontées à la génération actuelle attaques de la chaîne d’approvisionnement. Les recommandations retracent le parcours d'un paquet compromis jusqu'à son arrivée en production, depuis le registre jusqu'aux machines sur lesquelles travaille votre équipe, en passant par votre pipeline. Elles abordent les bonnes pratiques spécifiques qui permettent d'éviter qu'un paquet compromis ne se transforme en incident.

Comment se protéger contre attaques de la chaîne d’approvisionnement

  • Appliquer une politique relative à l'ancienneté des paquets avant toute installation

    Les installations de paquets exécutent des scripts contrôlés par l'éditeur avec les droits de l' développeur avant même qu'une seule ligne de code ne soit importée. Une politique imposant un délai minimum de 48 heures bloque les logiciels malveillants à propagation rapide avant qu'ils n'atteignent vos développeurs.

  • Associer les dépendances du pipeline aux SHA des commits

    Les balises et les noms de branches sont modifiables. Un pirate qui parvient à compromettre une action peut déplacer la balise sans toucher à votre fichier de workflow. Fixez plutôt chaque action et chaque dépendance du pipeline à un SHA de commit immuable.

  • Mettre en place une authentification multifactorielle (MFA) résistante au phishing

    FIDO2 et les clés d'accès constituent la norme à adopter. Les codes TOTP et SMS peuvent être interceptés sur une fausse page de connexion puis réutilisés en temps réel sur le site authentique ; les comptes des administrateurs constituent d'ailleurs une cible privilégiée.

  • Considérer les serveurs MCP comme des dépendances tierces

    Les serveurs MCP présentent les mêmes risques liés à la chaîne d'approvisionnement que toute autre dépendance, et ils disposent souvent de droits d'accès plus étendus. N'installez des serveurs MCP qu'à partir de sources vérifiées, validez-les à l'aide d'un hachage d'intégrité ou d'un SHA de commit, et assurez-vous, avant l'installation, que le serveur dispose d'un dépôt régulièrement mis à jour et d'un éditeur connu.

Résumé

Les attaquants ne ciblent plus les applications de production, mais les systèmes qui les développent ; pourtant, ce sont toujours les défenseurs qui contrôlent ce qui entre dans ces systèmes. Vous contrôlez votre fichier de verrouillage, la configuration de votre pipeline, les portées de vos jetons et les outils installés sur les machines de vos développeurs. Les équipes d’ingénierie qui prennent une longueur d’avance sont celles qui exercent ce contrôle avant que quelqu’un ne découvre les points d’entrée vulnérables. Cette liste de contrôle contient des mesures de défense concrètes couvrant les dépendances, les pipelines, les conteneurs, les environnements de développement et les outils agents sur lesquels votre équipe commence à s’appuyer.

Ce que vous apprendrez

Rédigé par :
Nicholas Thomson

Nicholas Thomson est rédacteur de contenu marketing chez Aikido Security. Auparavant, il a travaillé comme rédacteur technique chez Datadog et Edge Delta. Avant d'entrer dans le secteur de la technologie, il a été éditeur chez Penguin Random House.

Principales conclusions

  • Appliquer une politique relative à l'ancienneté des paquets avant toute installation

    Les installations de paquets exécutent des scripts contrôlés par l'éditeur avec les droits de l' développeur avant même qu'une seule ligne de code ne soit importée. Une politique imposant un délai minimum de 48 heures bloque les logiciels malveillants à propagation rapide avant qu'ils n'atteignent vos développeurs.

  • Associer les dépendances du pipeline aux SHA des commits

    Les balises et les noms de branches sont modifiables. Un pirate qui parvient à compromettre une action peut déplacer la balise sans toucher à votre fichier de workflow. Fixez plutôt chaque action et chaque dépendance du pipeline à un SHA de commit immuable.

  • Mettre en place une authentification multifactorielle (MFA) résistante au phishing

    FIDO2 et les clés d'accès constituent la norme à adopter. Les codes TOTP et SMS peuvent être interceptés sur une fausse page de connexion puis réutilisés en temps réel sur le site authentique ; les comptes des administrateurs constituent d'ailleurs une cible privilégiée.

  • Considérer les serveurs MCP comme des dépendances tierces

    Les serveurs MCP présentent les mêmes risques liés à la chaîne d'approvisionnement que toute autre dépendance, et ils disposent souvent de droits d'accès plus étendus. N'installez des serveurs MCP qu'à partir de sources vérifiées, validez-les à l'aide d'un hachage d'intégrité ou d'un SHA de commit, et assurez-vous, avant l'installation, que le serveur dispose d'un dépôt régulièrement mis à jour et d'un éditeur connu.

Résumé

Les attaquants ne ciblent plus les applications de production, mais les systèmes qui les développent ; pourtant, ce sont toujours les défenseurs qui contrôlent ce qui entre dans ces systèmes. Vous contrôlez votre fichier de verrouillage, la configuration de votre pipeline, les portées de vos jetons et les outils installés sur les machines de vos développeurs. Les équipes d’ingénierie qui prennent une longueur d’avance sont celles qui exercent ce contrôle avant que quelqu’un ne découvre les points d’entrée vulnérables. Cette liste de contrôle contient des mesures de défense concrètes couvrant les dépendances, les pipelines, les conteneurs, les environnements de développement et les outils agents sur lesquels votre équipe commence à s’appuyer.

Ce que vous apprendrez

Une liste de contrôle pratique destinée aux équipes d'ingénieurs confrontées à la génération actuelle attaques de la chaîne d’approvisionnement. Les recommandations retracent le parcours d'un paquet compromis jusqu'à son arrivée en production, depuis le registre jusqu'aux machines sur lesquelles travaille votre équipe, en passant par votre pipeline. Elles abordent les bonnes pratiques spécifiques qui permettent d'éviter qu'un paquet compromis ne se transforme en incident.

Rédigé par :
Nicholas Thomson

Nicholas Thomson est rédacteur de contenu marketing chez Aikido Security. Auparavant, il a travaillé comme rédacteur technique chez Datadog et Edge Delta. Avant d'entrer dans le secteur de la technologie, il a été éditeur chez Penguin Random House.