Bloquer une pipeline n'améliore pas la sécurité

L’équipe sécurité est fière de son travail. Après des mois d’efforts, chaque pipeline intègre désormais un scanner de vulnérabilités. Le résultat est immédiat : 87% des builds échouent. Les développeurs ne peuvent plus livrer. Les tickets s’accumulent. La pression monte.

Deux semaines plus tard, une “exception temporaire” est accordée pour le projet prioritaire. Puis une autre. Puis encore une autre. Six mois après, la moitié des projets bénéficient d’exceptions. Les développeurs ont appris à taguer leurs commits pour contourner les scans. Le scanner tourne toujours, mais plus personne ne regarde ses résultats.

Cette histoire n’est pas un cas isolé. C’est le pattern dominant de l’implémentation de la sécurité dans les pipelines CI/CD.

En résumé : Un contrôle de sécurité qui bloque systématiquement génère des contournements systématiques. La vraie sécurité ne vient pas de l’obstruction mais de l’accompagnement des équipes vers de meilleures pratiques.

L’illusion du gate de sécurité

L’idée semble logique : si une pipeline échoue quand il y a un problème de sécurité, alors les problèmes de sécurité ne seront jamais déployés. En théorie, c’est imparable. En pratique, c’est un échec prévisible.

Pourquoi ça ne fonctionne pas

Le volume d’alertes : un scanner de vulnérabilités moderne génère des dizaines, parfois des centaines d’alertes par projet. Selon les études du secteur, les équipes de sécurité reçoivent en moyenne 11 000 alertes par jour, mais n’en traitent que 4%. Le reste est ignoré par manque de temps et de contexte.

Les faux positifs : une proportion significative des alertes ne représente pas un risque réel. Une vulnérabilité dans une fonction non utilisée, une dépendance de test, un composant non exposé au réseau. Bloquer pour un faux positif est punitif et injuste.

L’absence de contexte : un scanner ne sait pas si une vulnérabilité est exploitable dans votre contexte. Il signale tout, à l’équipe de trier. Mais l’équipe n’a pas le temps de trier.

La pression de livraison : les développeurs ont des deadlines. Une pipeline bloquée n’arrête pas ces deadlines. Elle crée une pression pour contourner le blocage.

Les statistiques qui dérangent

Les chiffres du rapport BlackDuck 2025 sont révélateurs :

• 53% des organisations déclarent que la sécurité applicative ralentit leurs pipelines
• Le délai moyen de correction d’une vulnérabilité reste de plusieurs semaines
• Les équipes passent plus de temps à gérer les exceptions qu’à corriger les problèmes

Ces chiffres montrent un dysfonctionnement systémique. Les outils sont là, mais ils ne produisent pas le résultat attendu.

La spirale des contournements

Quand un contrôle bloque sans accompagnement, les équipes développent des stratégies de contournement.

Contournements explicites

Technique	Justification apparente
Demander une exception “temporaire"	"On corrigera après la release”
Désactiver le scan pour ce projet	”C’est un projet interne, pas critique”
Ajouter des commentaires pour ignorer les alertes	”C’est un faux positif, on vérifiera plus tard”
Merger avant que le scan ne termine	”Le scan est trop lent, on ne peut pas attendre”

Contournements implicites

Plus insidieux, les contournements implicites modifient le comportement sans désactiver explicitement les contrôles :

• Éviter les mises à jour : si chaque mise à jour de dépendance déclenche de nouvelles alertes, l’équipe arrête de mettre à jour. La dette s’accumule silencieusement.

• Empiler les changements : pour ne pas subir le scan plusieurs fois, les développeurs accumulent les modifications dans des commits massifs. Ces commits sont plus difficiles à revoir et à débuguer.

• Développer des “astuces” : les équipes découvrent comment structurer le code pour éviter certaines alertes, même si ces structures sont moins optimales.

Le cercle vicieux

1. Un contrôle bloque trop souvent
2. Les équipes développent des contournements
3. Le contrôle devient inefficace
4. L’équipe sécurité ajoute plus de contrôles
5. Les contournements se sophistiquent
6. Retour à l’étape 1

Ce cercle crée une course aux armements entre sécurité et développement. Les deux camps finissent épuisés, la sécurité réelle ne s’améliore pas.

Le problème de l’alert fatigue

L’alert fatigue (fatigue des alertes) est un phénomène documenté : quand le volume d’alertes dépasse la capacité de traitement, toutes les alertes finissent ignorées, y compris les critiques.

Comment ça se manifeste

Au début, chaque alerte est examinée avec attention. L’équipe trie, priorise, corrige. Mais le flux ne tarit pas. Chaque jour apporte de nouvelles alertes. Les anciennes s’accumulent.

Progressivement, l’équipe développe des raccourcis mentaux :

• “Cette bibliothèque génère toujours des faux positifs, on peut ignorer”
• “Les vulnérabilités de sévérité moyenne, on verra plus tard”
• “C’est le même type d’alerte que d’habitude, pas besoin de vérifier”

Un jour, une alerte critique passe inaperçue. Elle ressemblait aux centaines d’alertes ignorées quotidiennement. Personne n’a pris le temps de la regarder de près.

Le paradoxe du scanner sensible

Plus un scanner est sensible, plus il génère d’alertes. Plus il génère d’alertes, moins chaque alerte est prise au sérieux. Un scanner très sensible peut donc réduire la sécurité effective en noyant les vrais problèmes dans le bruit.

Gates vs Guardrails

La distinction entre “gate” (barrière) et “guardrail” (garde-fou) illustre deux philosophies opposées.

Le modèle Gate (barrière)

La barrière bloque le passage tant que les conditions ne sont pas remplies. C’est binaire : tu passes ou tu ne passes pas.

Avantages apparents :

• Garantie que rien de non-conforme ne passe
• Clarté des règles
• Responsabilité claire (le gate a dit non)

Problèmes réels :

• Crée de la friction et de la frustration
• Pousse aux contournements
• Transfère la responsabilité vers un système automatisé
• Ne résout pas le problème, le bloque simplement

Le modèle Guardrail (garde-fou)

Le garde-fou guide sans bloquer systématiquement. Il signale le danger, suggère la correction, mais laisse la décision finale à l’humain.

Caractéristiques :

• Alertes contextualisées : “cette vulnérabilité est critique car…”
• Suggestions de correction : “voici comment résoudre ce problème”
• Escalade graduée : avertissement → discussion → blocage pour les cas critiques
• Responsabilité partagée : l’équipe décide en connaissance de cause

Tableau comparatif

Aspect	Gate	Guardrail
Réponse par défaut	Bloquer	Informer
Posture	Punitive	Habilitante
Responsabilité	Système	Équipe
Effet sur le comportement	Contournements	Apprentissage
Résultat long terme	Course aux armements	Amélioration culturelle

Vers une approche habilitante

Une approche habilitante ne signifie pas abandonner les contrôles. Elle signifie les concevoir pour aider les équipes à mieux faire plutôt que pour les punir quand elles font mal.

Prioriser plutôt que tout signaler

Tous les problèmes de sécurité ne se valent pas. Une vulnérabilité critique dans une fonction exposée au réseau n’a pas le même impact qu’une vulnérabilité moyenne dans une dépendance de test.

Une approche efficace :

• Bloque uniquement les problèmes critiques et exploitables
• Alerte sur les problèmes importants avec un délai de correction
• Informe sur les problèmes mineurs sans bloquer

Fournir le contexte

Une alerte “CVE-2024-XXXXX dans libfoo” n’aide personne. Une alerte utile explique :

• Pourquoi c’est un problème (type de vulnérabilité, vecteur d’attaque)
• Si c’est exploitable dans ce contexte (la fonction vulnérable est-elle utilisée ?)
• Comment corriger (mise à jour disponible, patch, workaround)
• Quel est le délai acceptable pour la correction

Intégrer tôt, pas tard

Découvrir 200 vulnérabilités au moment du déploiement est paralysant. Découvrir 2 vulnérabilités pendant le développement est gérable.

La stratégie du “shift-left” (déplacer vers la gauche) consiste à détecter les problèmes au plus tôt dans le cycle de développement :

• Dans l’IDE du développeur
• Au moment du commit
• À l’ouverture de la pull request

Plus tôt le problème est détecté, plus facile et moins coûteuse est sa correction.

Accompagner, pas punir

Quand une équipe a un problème de sécurité récurrent, la bonne réponse n’est pas d’ajouter plus de contrôles bloquants. C’est de comprendre pourquoi le problème existe et d’aider à le résoudre à la racine.

Questions à poser :

• L’équipe a-t-elle les compétences pour corriger ce type de problème ?
• Les outils disponibles rendent-ils la correction facile ?
• Les priorités de l’équipe lui permettent-elles de traiter la sécurité ?
• La dette existante est-elle trop importante pour être traitée sans aide ?

Mesurer ce qui compte

Les mauvaises métriques encouragent les mauvais comportements.

Mauvaise métrique	Bon comportement qu’elle décourage
Nombre de vulnérabilités détectées	Utiliser des bibliothèques (plus de dépendances = plus de vulnérabilités détectées)
Temps de blocage du pipeline	Prendre le temps de bien corriger
Nombre d’exceptions accordées	Demander de l’aide quand c’est nécessaire

Les bonnes métriques se concentrent sur les résultats :

• Temps moyen de correction des vulnérabilités critiques
• Pourcentage de projets avec des dépendances à jour
• Nombre d’incidents de sécurité évités ou détectés tôt

La sécurité comme culture, pas comme contrainte

Les organisations où la sécurité fonctionne ne sont pas celles qui ont les contrôles les plus stricts. Ce sont celles où la sécurité fait partie de la culture.

Signes d’une culture sécurité saine

• Les développeurs demandent des revues de sécurité, ils ne les subissent pas
• Les équipes sécurité sont perçues comme des alliées, pas des obstacles
• Les incidents sont des opportunités d’apprentissage, pas des occasions de blâme
• La formation sécurité est continue, pas ponctuelle
• Les bonnes pratiques sont intégrées aux outils, pas ajoutées après coup

Comment y arriver

La transformation culturelle prend du temps. Elle commence par des actions concrètes :

• Impliquer les développeurs dans le choix et la configuration des outils de sécurité
• Célébrer les corrections de vulnérabilités autant que les nouvelles fonctionnalités
• Rendre visible l’impact positif de la sécurité (incidents évités, confiance client)
• Former régulièrement en rendant la formation pratique et applicable
• Réduire la friction : chaque étape de sécurité doit être la plus simple possible

À retenir

• Un gate qui bloque systématiquement génère des contournements systématiques. La sécurité apparente masque une absence de sécurité réelle.

• L’alert fatigue est un risque majeur : trop d’alertes mènent à ignorer toutes les alertes, y compris les critiques.

• Les guardrails (garde-fous) sont plus efficaces que les gates (barrières) : ils guident sans bloquer, responsabilisent sans punir.

• Le shift-left fonctionne quand il est accompagné : détecter tôt sans accompagnement ne fait que déplacer le problème.

• La vraie sécurité vient d’une culture où les équipes veulent bien faire, pas d’un système qui les empêche de mal faire.

• Les bonnes métriques mesurent les résultats (temps de correction, incidents évités) pas les activités (alertes générées, builds bloqués).

Liens utiles

• Pourquoi la sécurité échoue en pratique — les dynamiques organisationnelles de l’échec
• DevSecOps — intégrer la sécurité dans le cycle DevOps
• La boucle de rétroaction — l’importance du feedback rapide
• Dette de sécurité — comprendre l’accumulation des risques
• Indicateurs DORA — mesurer la performance sans sacrifier la sécurité
• Comprendre le SAST — analyse statique et ses limites
• Comprendre le SCA — analyse des dépendances et ses limites