Quand un résultat de sécurité doit-il faire échouer le build, et comment gérer les faux positifs ?

Une porte de sécurité n'a de valeur que si les développeurs la respectent. La partie difficile du DevSecOps n'est pas d'exécuter des scanners — c'est de décider ce qui doit réellement stopper une release.

Ce qui doit faire échouer le build

Réservez un échec strict aux résultats qui sont simultanément :

• À forte gravité — exploitables, à impact réel.
• À forte confiance — faible taux de faux positifs pour cette règle.
• Nouvellement introduits — ajoutés par ce changement, et non hérités.

Tout le reste devrait avertir plutôt que bloquer : remonté dans la PR, suivi, mais sans stopper le pipeline. Cela garde le signal « stop » de la porte rare et significatif.

Le problème des faux positifs

C'est le nœud du sujet. Un scanner qui bloque les builds sur du bruit entraîne les développeurs à s'en méfier — ils tamponneront les suppressions sans réfléchir, exigeront sa désactivation ou le contourneront. La qualité du signal détermine si l'outillage de sécurité survit au contact d'une véritable équipe. Vous gérez le bruit en :

• Ajustant les règles à la base de code et au langage.
• Mettant en référence les problèmes préexistants lorsque vous déployez le scan sur un dépôt existant, afin que le premier jour ne soit pas un mur de rouge pour du code que personne n'a touché — puis en empêchant les nouveaux et en réduisant délibérément le backlog.
• Suppressions auditables — lorsqu'un résultat est réellement un faux positif ou un risque accepté, consignez une exception documentée, revue et limitée dans le temps (avec auteur et justification) au lieu de désactiver le contrôle. Des // nosec silencieux partout, c'est le mode de défaillance.

La boucle de rétroaction

Les résultats doivent atterrir là où les développeurs travaillent déjà — la pull request — avec des conseils de remédiation clairs. Un retour rapide, précis et contextualisé, c'est ce qui fait que le shift-left s'ancre réellement.

Ce que recherchent les recruteurs

Ils veulent le seuil gravité-plus-confiance-plus-nouveauté, une prise en compte honnête de la fatigue liée aux faux positifs, et des suppressions qui restent auditables plutôt que de devenir un interrupteur d'arrêt discret.