L’approche reposait sur des intentions : encourager les développeurs à utiliser des actions Github sécurisées, sans les y contraindre.
Aucune vérification n’était imposée sur le type d’action utilisée, ni sur la présence d’un hash ou d’une provenance approuvée.
Des actions référencées par tag mutable passaient en production sans alerte, exposant les workflows à des modifications silencieuses.
L’absence de mécanisme technique ouvrait la porte à des erreurs humaines systématiques.
Les intentions ont été remplacées par des mécanismes applicables (e.g. github-actions-scanner) à chaque commit ou merge.
L’usage d’actions GitHub est désormais encadré par des règles techniques : seul le hash-pinning est autorisé, les actions doivent provenir d’une allowlist, et tout écart déclenche un blocage automatique du pipeline.
La politique de sécurité est codée dans l’infrastructure CI elle-même, plus dans des documents internes ou des pratiques implicites.
Le système est fiable parce qu’il ne dépend plus des intentions individuelles.
Et vous, quelles sont vos retours d'expérience concernant l'application de ce principe ?