Traitez votre pipeline CI et vos dépendances comme une surface d'attaque_

La plupart des équipes considèrent le risque de chaîne d'approvisionnement comme "est-ce que npm audit a trouvé quelque chose de mauvais ?"

C'est une petite partie du problème.

Un pipeline de livraison JavaScript moderne fait confiance à :

• les packages que vous installez
• les packages transitifs qu'ils installent
• les GitHub Actions que vous exécutez
• les jetons auxquels ces flux de travail peuvent accéder

C'est une surface d'attaque significative, surtout une fois que CI a la permission de commenter sur les PR, de publier des packages, de déployer des infrastructures ou de pousser sur la branche par défaut.

La première victoire facile : Fixer les actions externes

C'est plus faible que ce que de nombreuses équipes réalisent :

uses: vendor/example-action@v2

Le tag peut être modifié.

Si vous dépendez d'actions tierces, fixez un SHA de commit complet et examiné les mises à jour intentionnellement :

uses: vendor/example-action@8f4b7f84864484a7bf31766abe9204da3cbe65b3

Cela ne rend pas l'action sécurisée. Cela rend la décision de confiance explicite et examinable.

Séparer l'exécution non fiable de l'exécution privilégiée

Un des meilleurs modèles de flux de travail est :

1. exécuter les tests et les étapes de construction dans un flux de travail non privilégié
2. télécharger les artefacts
3. laisser un flux de travail séparé et de confiance consommer ces artefacts s'il a besoin de secrets ou de permissions d'écriture

Cela réduit la chance que le code de pull-request non fiable s'exécute avec un jeton qui peut muter le dépôt ou l'environnement de déploiement.

Minimiser la portée des jetons

Si un flux de travail a seulement besoin d'un accès en lecture, donnez-lui un accès en lecture.

S'il doit commenter sur une PR, ne lui permettez pas aussi d'écrire des contenus, d'administrer des packages ou de déployer des infrastructures.

Trop de pipelines échouent à la règle la plus simple en ingénierie de la sécurité : rendre le rayon d'impact petit.

La sécurité des packages en fait toujours partie

Vous devez également traiter l'hygiène des dépendances comme un travail opérationnel normal :

• gardez les fichiers de verrouillage engagés
• examinez les changements majeurs de dépendances
• supprimez les packages dont vous n'avez pas besoin
• privilégiez les mainteneurs établis pour les chemins critiques

Ce n'est pas un travail glamour. C'est ainsi que les logiciels restent défensibles.

Lectures complémentaires

• GitHub : Utilisez des versions immuables et le verrouillage par SHA
• GitHub : Renforcement de la sécurité pour GitHub Actions
• npm : À propos des rapports d'audit