« On a 12 000 constats ouverts. » Cette phrase ne décrit pas une posture de sécurité. Elle décrit un outil qui est allumé.
Le problème n’est pas le volume en soi. C’est que le volume, présenté sans hiérarchie, enseigne aux équipes de développement que la liste n’est pas à lire. Et cette leçon-là survit longtemps après que vous ayez corrigé le classement.
Pourquoi la sévérité de l’outil ne vous sert à rien
La sévérité rapportée par un analyseur est une propriété de la classe de vulnérabilité, calculée dans l’abstrait. Elle est calculée une fois, par le mainteneur du catalogue, pour tout le monde.
Elle n’a jamais vu votre architecture. Elle ignore lequel de vos services est exposé sur Internet. Elle ne sait pas si la fonction vulnérable est appelée par votre code. Elle ne sait pas si la donnée traitée est un catalogue de produits ou un dossier d’usager.
Deux constats « critiques » peuvent donc être, dans votre environnement, un incident imminent et une ligne de bruit. L’outil ne peut pas faire la différence. Vous, oui — mais seulement si vous décidez de la faire.
Les risques d’une liste non hiérarchisée
L’effort part au mauvais endroit. Un trimestre consacré à des vulnérabilités jamais atteignables est un trimestre pendant lequel le chemin réellement exploitable est resté ouvert.
Les équipes cessent de lire. C’est le coût durable. Une fois qu’une équipe a appris qu’un tableau de bord de sécurité est du bruit, la reconquête de son attention prend beaucoup plus de temps que la correction du classement.
La discussion se déplace vers l’outil. Faute de critères partagés, chaque constat se négocie individuellement. La sécurité affirme que c’est critique, l’équipe répond que ce n’est pas exploitable, et personne n’a de référence commune pour trancher. Ce débat se rejoue à chaque constat, indéfiniment.
Le constat sans propriétaire vieillit. Un constat qui n’est pas attribué n’est corrigé par personne. Il est simplement compté.
Trois questions qui font l’essentiel du classement
1. Le chemin de code est-il atteignable ?
La question la plus rentable, et de loin. Une dépendance vulnérable dont la fonction fautive n’est jamais appelée par votre application n’est pas un risque exploitable — c’est de la dette à traiter au rythme normal des mises à jour.
L’analyse d’accessibilité est maintenant offerte par la plupart des outils de composition logicielle. Activez-la avant d’ajuster quoi que ce soit d’autre : elle retire généralement plus de bruit que tous les ajustements de sévérité réunis.
2. Le service est-il exposé ?
Un service accessible depuis Internet et un service interne, atteignable uniquement après authentification depuis le réseau d’entreprise, ne présentent pas le même risque pour une même vulnérabilité.
Cette information existe déjà dans votre organisation — dans la configuration réseau, dans l’inventaire applicatif — mais elle n’est presque jamais reliée aux constats. C’est un travail de jointure, pas d’analyse.
3. Quelles données sont derrière ?
Une compromission qui atteint un catalogue public et une compromission qui atteint des renseignements personnels ne sont pas comparables, quelle que soit la note attribuée par l’outil.
Si vous avez une classification des données, servez-vous-en. Sinon, une approximation grossière — renseignements personnels, financier, opérationnel, public — suffit largement pour classer.
Construire la matrice avec les équipes, pas pour elles
C’est le point qui détermine si la démarche tient.
Une matrice de priorisation imposée par la sécurité sera contestée constat par constat. La même matrice, construite avec les responsables de livraison, devient la référence qu’ils invoquent eux-mêmes pour justifier leur ordre de travail.
Concrètement : une séance de deux heures avec les responsables des principales applications, où l’on convient ensemble des seuils. Ce que vous perdez en rigueur théorique, vous le regagnez au centuple en application réelle.
Le cas québécois : quand le code n’est pas le vôtre
Une part importante des constats, dans le secteur public et chez les organisations qui s’appuient sur des intégrateurs, porte sur du code que vous n’avez pas écrit et que vous ne pouvez pas corriger.
C’est la partie du problème que les démarches de priorisation ignorent presque toujours, et elle bloque plus de corrections que n’importe quel débat sur la sévérité.
Trois choses à régler, idéalement avant l’appel d’offres suivant :
- Qui corrige. Le contrat doit le dire. En son absence, chaque constat devient une négociation commerciale menée par des gens qui ne sont pas outillés pour ça.
- Dans quel délai. Exprimé en jours, distinct pour les vulnérabilités critiques. Un engagement de « meilleurs efforts » n’est pas un délai.
- Aux frais de qui. C’est la question qui bloque le plus souvent en pratique. Si la correction de sécurité est facturée comme une évolution, elle sera reportée.
Et pour l’existant, où le contrat est déjà signé : classez ces constats séparément. Les mélanger à ceux que vos équipes peuvent corriger produit une liste dont une partie n’est actionnable par personne — ce qui décrédibilise l’ensemble.
Ce qu’il faut réellement livrer à une équipe
Pas un tableau de bord. Une liste courte.
Cinq à dix éléments, ordonnés, avec pour chacun ce qui est atteignable, pourquoi c’est classé là, et ce qu’il faut faire. Une équipe qui reçoit dix éléments les traite. La même équipe, devant quatre cents, n’en traite aucun et vous soupçonne d’avoir simplement exporté un rapport.
Le reste demeure disponible, consultable, compté. Mais ce n’est pas ce que vous mettez devant les gens.
La mesure qui compte
Pas le nombre de constats ouverts — il montera quand vous améliorerez la couverture, ce qui est un progrès qui ressemble à une régression.
Mesurez plutôt le délai médian de correction des constats atteignables et exposés. C’est le seul chiffre qui décrit ce que vous vouliez améliorer, et le seul qui ne se dégrade pas quand vous branchez un nouvel outil.
Besoin d’aide pour mettre cela en œuvre ?
Nous travaillons avec votre équipe pour concevoir, construire et exploiter les contrôles décrits ci-dessus.