Quand votre pipeline de sécurité bloque tout : gérer les exceptions sans créer de failles

Vous avez un scan de sécurité qui s'exécute dans votre pipeline CI. Il détecte une vulnérabilité dans une bibliothèque dont votre équipe dépend. La sévérité est moyenne, mais aucune version corrigée n'est encore disponible. Votre pipeline échoue. Votre équipe ne peut pas déployer.

Vous avez alors un choix. Vous pouvez désactiver complètement le scan, abaisser le seuil jusqu'à ce que tout passe, ou commencer à ignorer les résultats du pipeline. Aucune de ces options n'est bonne. Mais si vous rendez trop facile le contournement des constatations individuelles, le pipeline cesse d'être utile comme filet de sécurité.

C'est le problème des exceptions. Toute équipe qui applique des règles de sécurité ou de conformité dans un pipeline finit par le rencontrer. La solution n'est pas de supprimer la barrière. La solution est de construire un mécanisme clair et responsable pour gérer les exceptions.

Pourquoi les exceptions existent

Les exceptions ne sont pas des signes d'un processus défaillant. Ce sont des signes que le monde réel ne correspond pas toujours à vos règles. Une bibliothèque a une vulnérabilité connue, mais le mainteneur n'a pas encore publié de correctif. Une règle de conformité interdit une certaine configuration, mais votre infrastructure ne peut pas supporter l'alternative pour le moment. Une constatation de sécurité est techniquement valide, mais le risque est acceptable dans votre contexte spécifique.

Si votre pipeline n'a aucun moyen de gérer ces situations, votre équipe trouvera un moyen de le contourner. Elle désactivera le scan. Elle affaiblira le seuil. Elle commencera à considérer les pipelines rouges comme normaux. Le pipeline devient une formalité, et les failles de sécurité persistent.

L'objectif est de maintenir le pipeline strict tout en offrant aux équipes une voie légitime pour avancer lorsqu'elles rencontrent un véritable blocage.

Quatre règles pour gérer les exceptions

Un bon mécanisme d'exception possède quatre propriétés. Chacune empêche un mode de défaillance spécifique que les équipes rencontrent couramment.

Le diagramme suivant illustre le cycle de vie complet d'une exception décrit par les quatre règles :

flowchart TD A[Finding Blocks Pipeline] --> B[Record Exception Who, What, Why] B --> C[Submit for Approval] C --> D{Approved?} D -- No --> E[Pipeline Remains Blocked] D -- Yes --> F[Set Expiration Date] F --> G[Exception Active Pipeline Passes] G --> H{Expired?} H -- No --> G H -- Yes --> I[Pipeline Fails Exception Expired] I --> J[Review & Resolve] J --> K{Blocker Resolved?} K -- Yes --> L[Remove Exception] K -- No --> B

1. Les exceptions doivent être enregistrées

La première règle est la plus simple : écrivez-la. Une exception n'est pas un commentaire dans une pull request ou un message dans un canal de discussion. Elle doit vivre dans un endroit où tout le monde peut la voir. L'équipe sécurité, l'équipe conformité et l'équipe qui exécute le pipeline doivent toutes avoir accès au même enregistrement.

L'endroit où vous la stockez importe moins que le fait de la stocker. Un fichier de configuration dans le dépôt fonctionne. Une entrée dans votre outil de suivi des tickets fonctionne. Ce qui compte, c'est que l'enregistrement contienne trois choses : qui a soumis l'exception, ce qui est exclu, et pourquoi.

2. Les exceptions doivent être approuvées

Une seule personne ne devrait pas décider de contourner une barrière de sécurité. Le développeur qui trouve le blocage peut soumettre l'exception, mais l'approbation doit venir de quelqu'un qui comprend le risque. Un ingénieur sécurité approuve les exceptions liées à la sécurité. Un responsable conformité approuve les violations de politique. L'approbation elle-même peut se faire via une pull request séparée ou via une étape d'approbation dans le pipeline.

Cette étape empêche l'abus le plus courant des exceptions : un développeur marquant sa propre constatation comme acceptable sans que personne d'autre ne révise le raisonnement.

3. Les exceptions doivent expirer

C'est la règle que la plupart des équipes oublient. Une exception est créée parce que quelque chose est temporairement bloqué. Six mois plus tard, la bibliothèque pourrait avoir un correctif. La limitation d'infrastructure pourrait être résolue. Mais l'exception est toujours en place, permettant silencieusement à la même vulnérabilité de passer à chaque déploiement.

Chaque exception a besoin d'une limite de temps. Pour une vulnérabilité critique, une semaine peut être appropriée. Pour une constatation de faible sévérité, un mois ou trois mois est raisonnable. La durée dépend du type de constatation et du contexte, mais elle doit exister.

4. Les exceptions expirées doivent faire échouer le pipeline

L'expiration est inutile si personne ne l'applique. Lorsqu'une exception expire, le pipeline doit automatiquement échouer à la barrière concernée. L'équipe n'a pas besoin de penser à vérifier. Le pipeline lui-même devient le rappel. Si le blocage est toujours là, l'équipe soumet une nouvelle exception avec une justification mise à jour. Si le blocage est résolu, l'exception est supprimée et le pipeline passe à nouveau.

Cela crée un cycle de révision naturel. Chaque exception est revue au moins une fois avant de pouvoir continuer.

L'analogie avec la dette technique

Ce modèle n'est pas nouveau. C'est la même façon dont les bonnes équipes gèrent la dette technique. Vous ne faites pas comme si la dette n'existait pas. Vous l'enregistrez, la priorisez et planifiez du temps pour la rembourser. Les exceptions de sécurité fonctionnent de la même manière. Vous n'ignorez pas la vulnérabilité. Vous la reconnaissez, documentez la décision et fixez une date limite pour la traiter.

La différence est que la dette technique est souvent invisible jusqu'à ce qu'elle cause des problèmes. Une exception de sécurité est visible dès sa création. Le pipeline la consigne. L'approbation l'enregistre. La date d'expiration la rend impossible à oublier.

Une liste de contrôle pratique

Si vous mettez en place un mécanisme d'exception pour votre pipeline, voici une courte liste de contrôle pour commencer :

  • Choisissez un emplacement de stockage pour les exceptions accessible aux équipes sécurité, conformité et ingénierie
  • Définissez qui peut approuver chaque type d'exception (constatations de sécurité, violations de conformité, limitations d'infrastructure)
  • Définissez des durées d'expiration par défaut pour différents niveaux de sévérité
  • Faites en sorte que le pipeline vérifie automatiquement les dates d'expiration et échoue lorsqu'une exception expire
  • Testez le flux : soumettez une exception, approuvez-la, laissez-la expirer et confirmez le comportement du pipeline

Et ensuite

Un bon mécanisme d'exception maintient votre pipeline strict sans le rendre rigide. Les équipes peuvent avancer lorsqu'elles rencontrent un véritable blocage, mais elles ne peuvent pas contourner la barrière sans laisser de trace. Le pipeline reste utile comme garde-fou, pas comme une formalité.

Une fois ce mécanisme en place, la prochaine étape consiste à coder toutes vos règles. Les politiques écrites dans des documents ou énoncées dans des réunions sont difficiles à appliquer de manière cohérente. Les règles écrites sous forme de code peuvent être testées, révisées et exécutées automatiquement. C'est là que les barrières de sécurité et de conformité deviennent vraiment fiables.