Quand les règles de sécurité vivent dans des documents, elles sont ignorées

Une équipe sécurité passe des semaines à rédiger une politique de scan d'images conteneurisées. Elle l'envoie par email, l'annonce lors de la réunion générale et la stocke dans le wiki de l'entreprise. Trois mois plus tard, quelqu'un vérifie le pipeline de production et découvre que le scan n'a jamais été activé. La configuration manquait dans un projet, et personne ne l'avait remarqué.

Ce n'est pas une histoire de mauvaises intentions. C'est une histoire de règles qui se brisent quand elles vivent en dehors du pipeline.

Le problème des règles sous forme de documents

Les politiques écrites ont une faiblesse fondamentale : elles dépendent des humains pour les lire, les mémoriser et les appliquer correctement. Chaque équipe interprète la même règle différemment. Chaque projet a ses propres particularités de configuration. Quand une règle change, quelqu'un doit mettre à jour manuellement chaque endroit où elle s'applique, et quelqu'un d'autre doit vérifier que la mise à jour a bien eu lieu.

Le résultat est prévisible. Certaines équipes suivent les règles. Certaines équipes suivent une version légèrement différente. Certaines équipes oublient complètement. Et personne ne sait quelle situation se produit jusqu'à ce que quelque chose tourne mal.

La différence entre ces deux approches devient claire quand on cartographie le flux :

Ce n'est pas un problème de personnes. C'est un problème de livraison. Les règles ne font pas partie du système qui livre le logiciel. Elles existent en dehors, sous forme de texte qui nécessite une traduction humaine en action.

Écrire les règles en tant que code

La politique en tant que code change le modèle de livraison des règles. Au lieu d'écrire des politiques dans des documents, vous les écrivez dans un format que les machines peuvent lire, vous les stockez dans un dépôt et vous les exécutez dans le cadre du pipeline. Le même workflow qui gère le code applicatif gère désormais vos règles de sécurité et de conformité.

Le format varie. Certaines équipes utilisent Rego d'Open Policy Agent. D'autres utilisent du YAML avec un schéma défini. D'autres encore utilisent les frameworks de politique intégrés de leurs outils de scan existants. Le langage importe moins que le principe : les règles sont écrites, versionnées, revues et exécutées automatiquement.

Prenons une règle simple : les conteneurs ne doivent pas s'exécuter en tant que root. En politique en tant que code, cela devient une déclaration claire qu'un moteur de politique peut évaluer. Le pipeline exécute le moteur sur chaque image conteneurisée avant le déploiement. Si l'image s'exécute en tant que root, le pipeline s'arrête. Si la règle doit changer, quelqu'un modifie le fichier de politique, ouvre une pull request et attend la revue. Le changement passe par le même processus que n'importe quel changement de code.

Ce qui change quand les règles deviennent du code

Le premier avantage est la cohérence. La même règle s'applique à chaque projet, chaque pipeline, chaque déploiement. Il n'y a pas d'écart parce que quelqu'un a oublié d'activer un scan ou parce que deux équipes ont configuré le même outil différemment. Quand une nouvelle règle est ajoutée, chaque pipeline la récupère automatiquement.

Le deuxième avantage est la testabilité. Avant la politique en tant que code, comment saviez-vous qu'une nouvelle règle était correcte ? Vous pouviez la tester dans un pipeline de production, ce qui est risqué. Ou vous pouviez sauter les tests et espérer le meilleur. Avec la politique en tant que code, vous écrivez des tests pour vos règles. Vous créez un cas de test où un conteneur avec un utilisateur root échoue à la politique, et un autre où un conteneur non-root réussit. Ces tests s'exécutent dans le CI, comme des tests unitaires. Si quelqu'un modifie la règle et casse la logique, les tests l'attrapent avant que la règle n'atteigne la production.

Le troisième avantage est l'auditabilité. Chaque changement de règle est enregistré dans le contrôle de version. Vous pouvez voir qui a changé quoi, quand et pourquoi. Vous pouvez annuler un mauvais changement de règle de la même manière que vous annulez un mauvais changement de code. Quand un auditeur demande si vos conteneurs s'exécutent en tant que root, vous pointez vers le fichier de politique et les logs du pipeline, pas vers un document qui pourrait être obsolète.

Vous n'avez pas besoin de tout écrire à partir de zéro

Une idée reçue courante est que la politique en tant que code signifie écrire chaque règle vous-même. En pratique, la plupart des règles proviennent de frameworks existants. Les outils de sécurité sont livrés avec des politiques pour les benchmarks CIS, les cadres réglementaires et les modèles de sécurité courants. Vous activez ceux qui s'appliquent à votre organisation et ajustez les seuils en fonction de votre tolérance au risque.

Ce que vous écrivez à partir de zéro est généralement spécifique à votre organisation. Peut-être que votre entreprise interdit le déploiement dans certaines régions cloud. Peut-être que chaque ressource doit avoir un ensemble spécifique d'étiquettes. Peut-être que les déploiements en production nécessitent une deuxième signature. Ce sont les règles que les frameworks existants ne couvrent pas, et ce sont celles qui bénéficient le plus d'être écrites en tant que code.

Le changement pratique

La politique en tant que code change la relation entre les équipes sécurité et les équipes d'ingénierie. La sécurité n'envoie plus de règles par-dessus le mur en espérant qu'elles soient implémentées. La sécurité écrit les règles en tant que code, les soumet via le même processus de revue que le code applicatif et voit les résultats dans chaque exécution de pipeline.

Les équipes d'ingénierie n'ont plus à deviner si elles suivent les règles. Le pipeline les informe immédiatement. Si un changement viole une politique, la build échoue avec un message clair. L'équipe corrige le problème avant qu'il n'atteigne la production, pas après qu'un audit ne le découvre six mois plus tard.

Une checklist rapide pour commencer

• Choisissez une règle actuellement documentée mais fréquemment violée.
• Écrivez cette règle en tant que code en utilisant le framework de politique de votre outil de sécurité existant.
• Ajoutez la vérification de politique à votre pipeline CI.
• Écrivez un test qui prouve que la règle détecte les violations.
• Écrivez un autre test qui prouve que la règle autorise les changements conformes.
• Supprimez l'ancien document et redirigez les gens vers le fichier de politique à la place.

Commencez par une règle. Prouvez que le workflow fonctionne. Ensuite, développez.

L'essentiel à retenir

Les règles qui vivent dans des documents sont des règles qui sont ignorées. Les règles qui vivent dans le pipeline sont des règles qui sont appliquées. La politique en tant que code ne consiste pas à écrire plus de règles. Il s'agit de faire en sorte que les règles que vous avez déjà fonctionnent réellement, à chaque fois, pour chaque changement, sans dépendre de quelqu'un qui se souvient d'avoir lu un email.