Quand faire échouer un pipeline et quand simplement avertir

Vous venez d'ajouter un scanner de sécurité à votre pipeline CI. La première analyse s'exécute et trouve 47 problèmes. Trois sont marqués comme critiques, douze comme élevés, et le reste est moyen ou faible. Vous devez maintenant prendre une décision : faire échouer le pipeline pour chaque résultat, ou tout laisser passer et simplement collecter des rapports ?

Si vous faites échouer sur tout, votre pipeline sera rouge plus souvent que vert. Les développeurs commenceront à ignorer le scanner, ou pire, ils trouveront des moyens de le contourner. Si vous ne faites jamais échouer le pipeline, le scanner devient du bruit. Personne ne lit les rapports, et les mêmes vulnérabilités restent dans votre codebase pendant des mois.

Aucun des deux extrêmes ne fonctionne. La réponse est un seuil de sévérité.

La sévérité vous indique ce qui compte

Chaque scanner de sécurité regroupe les résultats par sévérité. Les libellés varient légèrement entre les outils, mais le modèle est cohérent : critique, élevé, moyen, faible, et parfois info ou inconnu. Ces libellés ne sont pas décoratifs. Ils estiment la gravité potentielle si quelqu'un exploitait cette vulnérabilité.

Un résultat critique dans une bibliothèque qui gère l'authentification des utilisateurs est différent d'un résultat faible dans un morceau de code qui s'exécute une fois lors de la configuration et plus jamais. Les traiter de la même manière est une erreur.

La règle simple : faire échouer le pipeline sur les résultats critiques et élevés. Laisser passer les résultats moyens et faibles avec un avertissement.

L'arbre de décision ci-dessous résume la règle :

Pourquoi cela fonctionne en pratique

Lorsque vous faites échouer sur les résultats critiques et élevés, vous bloquez les problèmes les plus dangereux avant qu'ils n'atteignent la production. Ce sont les vulnérabilités que les attaquants recherchent activement. Ce sont celles qui causent des fuites de données, des prises de contrôle de service et des non-conformités.

Lorsque vous avertissez sur les résultats moyens et faibles, vous maintenez le pipeline en mouvement. Les développeurs peuvent continuer leur travail. L'équipe n'est pas bloquée par des problèmes qui pourraient ne jamais avoir d'importance en pratique. Mais les avertissements sont enregistrés, et quelqu'un doit les examiner plus tard.

Cet équilibre maintient l'utilité du pipeline sans en faire un goulot d'étranglement.

Des exceptions existent, mais elles nécessitent des règles

La règle simple est un bon point de départ, mais les projets réels ont des cas particuliers.

Parfois, un résultat élevé n'a pas encore de correctif disponible. L'éditeur n'a pas publié de correctif, et vous ne pouvez pas supprimer la dépendance car elle est centrale pour votre application. Dans ce cas, faire échouer le pipeline à chaque fois n'aide personne. Vous avez besoin d'un moyen d'accepter temporairement ce résultat tout en suivant l'éditeur pour un correctif.

Parfois, un résultat moyen se trouve dans un composant sensible comme le chiffrement ou l'authentification. Même si le scanner le note comme moyen, le risque est plus élevé en raison de son emplacement. Vous pourriez vouloir faire échouer le pipeline pour ce résultat spécifique même s'il n'est pas critique ou élevé.

C'est là qu'une porte de qualité basée sur le risque devient utile au lieu d'une simple porte basée sur le nombre.

Construisez une porte de qualité, pas une règle de zéro résultat

Une erreur courante est de définir la règle comme "le pipeline échoue s'il y a des résultats". Cela semble strict et sécurisé, mais en pratique, cela crée des problèmes. Les scanners produisent des faux positifs. Ils signalent des choses qui ne sont pas réellement exploitables dans votre configuration spécifique. Si vous faites échouer sur tout, les développeurs apprennent à ignorer le scanner ou à demander des exceptions pour tout. La porte perd son sens.

Une meilleure porte de qualité évalue si les résultats violent un seuil de risque. Exemples :

• Le pipeline échoue s'il y a des résultats critiques ou élevés sans exception approuvée.
• Le pipeline échoue s'il y a un résultat moyen dans le module d'authentification.
• Le pipeline échoue si le même résultat est ouvert depuis plus de 30 jours sans action.

Ces règles sont plus réalistes que "zéro résultat". Elles reconnaissent que certaines vulnérabilités peuvent être gérées, tandis que d'autres doivent être bloquées immédiatement.

Comment configurer votre seuil

Commencez par ce que votre scanner fournit déjà. La plupart des scanners vous permettent de configurer le code de sortie en fonction de la sévérité. Définissez les résultats critiques et élevés pour faire échouer la build. Définissez les résultats moyens et faibles pour réussir mais enregistrer un avertissement.

Ajoutez ensuite une notification. Lorsque des résultats moyens et faibles apparaissent, envoyez un message au canal de discussion de l'équipe ou créez un ticket dans votre système de suivi des problèmes. L'équipe doit examiner ces résultats périodiquement, peut-être à chaque sprint ou avant chaque version majeure. Ainsi, les résultats ne sont pas perdus, mais ils ne bloquent pas non plus le travail quotidien.

Après avoir mis en place le seuil de base, observez son comportement. Si le pipeline échoue trop souvent, vérifiez si les résultats sont réels ou des faux positifs. Si le pipeline n'échoue presque jamais, vérifiez si votre scanner est correctement configuré et scanne les bonnes choses.

Ce que fait réellement une porte

Une porte de sécurité dans votre pipeline n'est pas une garantie que votre application est parfaitement sécurisée. Aucun scanner automatisé ne peut trouver toutes les vulnérabilités. Aucune règle de pipeline ne peut empêcher toutes les erreurs.

Ce que fait une porte, c'est empêcher automatiquement les problèmes les plus dangereux d'atteindre la production. Elle attrape les choses qui vous empêcheraient de dormir si elles étaient déployées. Pour tout le reste, vous vous appuyez sur une revue manuelle, une correction planifiée et de bonnes pratiques d'ingénierie.

C'est plus réaliste et plus durable que d'essayer d'atteindre zéro résultat. Les équipes qui visent zéro résultat s'épuisent souvent ou commencent à contourner le système. Les équipes qui visent à bloquer les pires problèmes et à gérer le reste ont tendance à rester efficaces dans le temps.

Liste de contrôle pratique

• Définissez les résultats critiques et élevés pour faire échouer le pipeline.
• Définissez les résultats moyens et faibles pour réussir avec un avertissement.
• Configurez des notifications pour les résultats moyens et faibles afin que l'équipe puisse les examiner plus tard.
• Créez un processus pour approuver les exceptions lorsqu'un résultat ne peut pas être corrigé immédiatement.
• Examinez les demandes d'exception avec un petit groupe, pas une seule personne.
• Définissez des dates d'expiration sur les exceptions afin qu'elles ne restent pas ouvertes indéfiniment.
• Révisez votre seuil tous les quelques mois pour l'ajuster en fonction de l'expérience réelle.

L'essentiel à retenir

Votre porte de pipeline n'a pas besoin de tout attraper. Elle doit attraper les choses qui comptent le plus. Commencez par les résultats critiques et élevés comme blocages stricts. Laissez les résultats moyens et faibles être des avertissements que l'équipe examine selon un calendrier. Construisez un processus d'exception simple pour les cas où un correctif n'est pas immédiatement possible. Cette combinaison maintient votre pipeline en mouvement et votre environnement de production plus sûr que d'essayer de tout bloquer.