Bonnes pratiques de sécurité de la chaîne d'approvisionnement logicielle

Source

• Exigez une authentification forte. Utilisez l'authentification multifacteur pour chaque compte d'hébergement de code.
• Protégez la branche principale. Exigez une revue avant la fusion, et ne laissez personne pousser directement sur une branche de release.
• Gardez les secrets hors du code. Recherchez-les à chaque push, et renouvelez tout ce qui a été exposé.
• Traitez les fichiers de workflow comme du code. Une modification de pipeline peut atteindre vos secrets : exigez donc une revue par leurs responsables.

Dépendances

• Commitez un lockfile et installez à partir de celui-ci. Utilisez npm ci et ses équivalents, pour que les builds ne récupèrent pas de nouvelles versions par accident. Un lockfile a ses limites, mais c'est le point de départ.
• Ajoutez un délai d'attente pour les nouvelles versions. Les releases malveillantes sont souvent repérées peu après leur apparition : ne pas adopter une version le jour de sa publication laisse à cette détection une chance d'avoir lieu.
• Limitez les scripts d'installation. Désactivez-les quand c'est possible. Les scripts exécutés à l'installation sont le moyen par lequel les vers npm se propagent.
• Vérifiez les nouvelles dépendances. Contrôlez le nom pour écarter le typosquatting, et examinez la maintenance et la popularité. OpenSSF Scorecard automatise une partie de ce travail.
• Protégez les noms de paquets internes. Utilisez les scopes et la configuration du registre, pour qu'un paquet public ne puisse pas prendre la place d'un paquet interne par confusion de dépendances.
• Supprimez ce dont vous n'avez pas besoin. Chaque dépendance est un élément de plus à surveiller.

Build et CI/CD

• Épinglez les GitHub Actions sur un hash de commit complet. Les tags peuvent être déplacés, comme l'a montré la compromission de tj-actions.
• Limitez ce que chaque job peut faire. Donnez au token du workflow le minimum de permissions nécessaire, et utilisez des identifiants de courte durée plutôt que des secrets de longue durée.
• Restreignez le trafic sortant. Un build a besoin de paquets provenant de sources connues et publie vers des destinations connues. Bloquez tout le reste, et les secrets volés n'auront nulle part où aller. Consultez la politique de trafic sortant GitHub Actions.
• Exécutez chaque job dans un environnement neuf et isolé. Rien ne doit passer d'un job au suivant, surtout pas depuis une pull request d'un contributeur externe.
• Traitez les caches comme une entrée. Un cache empoisonné survit d'un build à l'autre, et ce qu'il restaure passe facilement inaperçu. Consultez le cache GitHub Actions.

Pour la liste complète, consultez la checklist de sécurité du pipeline CI/CD et le comparatif de la sécurité des runners.

Release

• Générez une SBOM pour chaque release, à partir du build. Conservez-la avec l'artefact. Consultez les bonnes pratiques SBOM.
• Signez les artefacts et publiez la provenance. Les consommateurs peuvent alors vérifier d'où vient une release. SLSA définit les niveaux.
• Construisez les releases uniquement en CI. Une release issue d'un ordinateur portable ne repose sur aucune trace fiable.
• Utilisez un seul artefact du test à la production. Promouvez ce que vous avez testé plutôt que de le reconstruire, pour que l'enregistrement reste exact.

Après la release

• Surveillez ce que vous avez livré. Continuez à vérifier les SBOM des releases prises en charge par rapport aux nouvelles vulnérabilités.
• Priorisez au-delà du seul CVSS. Utilisez CISA KEV, EPSS et le contexte. Voir comment prioriser les vulnérabilités.
• Sachez combien de temps vous avez été exposé. L'historique des builds montre quelles releases contenaient un paquet, et depuis quand.
• Ayez un plan avant d'en avoir besoin. Décidez qui trie, qui corrige et qui parle aux clients. Consultez le cycle de vie de la gestion des vulnérabilités.
• Entraînez-vous sur un scénario réel. Demandez-vous combien de temps il faudrait pour trouver toutes les releases contenant un paquet donné. Si la réponse se compte en jours, commencez par là.

Par quoi commencer

Quand	À faire
Cette semaine	Authentification multifacteur, lockfiles en CI, GitHub Actions épinglées, tokens de workflow à privilèges minimaux
Ce mois-ci	SBOM de chaque build de release, alertes de dépendances avec un responsable, détection de secrets
Ce trimestre	Règles de trafic sortant pour les builds, surveillance des releases livrées, plan de réponse testé
Ensuite	Provenance signée, revue formelle de la couverture SLSA ou NIST SSDF, SBOM des fournisseurs

Ce que CRACI prend en charge

CRACI couvre le build et tout ce qui suit. En tant que runner GitHub Actions, il exécute chaque job dans sa propre machine virtuelle isolée, enregistre dans une SBOM chaque paquet récupéré par le job, signale les paquets restaurés depuis les caches CI et applique une politique de trafic sortant qui bloque les connexions dont votre build n'a pas besoin. Il continue ensuite de vérifier ce qui a été livré, montre quels builds contenaient un paquet vulnérable et peut bloquer des builds grâce aux gates de politique.

Le reste relève de vos autres outils : CRACI n'analyse pas le code source ni les secrets, ne détecte pas les nouveaux paquets malveillants par leur comportement, et ne signe ni les SBOM ni la provenance. Consultez le comparatif des outils de sécurité de la chaîne d'approvisionnement logicielle pour savoir ce qui comble chaque lacune.

Bonnes pratiques de sécurité de la chaîne logicielle : questions fréquentes

Comment sécuriser une chaîne d'approvisionnement logicielle ?

Sachez ce que vous livrez grâce à une SBOM issue de chaque build de release, contrôlez ce qui entre avec des lockfiles et des vérifications, protégez le build en limitant les secrets et le trafic sortant, et continuez à surveiller ce que vous avez publié.

Que doit faire une petite équipe en premier ?

Activez l'authentification multifacteur, installez à partir des lockfiles en CI, épinglez les GitHub Actions sur des hashes de commit et donnez aux tokens de workflow le minimum de permissions nécessaire. Ces mesures prennent quelques jours et ferment des chemins d'attaque courants.

Comment se prémunir contre les paquets malveillants ?

Aucune mesure n'y suffit à elle seule. Retardez l'adoption des nouvelles versions, limitez les scripts d'installation et vérifiez les nouvelles dépendances. Restreindre le trafic sortant des builds limite les dégâts si un paquet malveillant passe entre les mailles du filet.

Pourquoi épingler les GitHub Actions sur un hash de commit ?

Parce qu'un tag de version peut être déplacé vers un autre code. Un hash de commit complet désigne toujours le même code : un tag détourné n'atteint donc pas votre pipeline.

À quelle fréquence faut-il passer en revue votre chaîne d'approvisionnement ?

La surveillance doit être continue. Passez en revue votre politique de dépendances, les permissions de vos workflows et votre plan de réponse au moins une fois par an, ainsi qu'après tout incident touchant votre stack.