Le pentest a trouvé 40 vulnérabilités — comment s'organiser pour les corriger sans couler ?

Ne vous fiez pas aveuglément aux scores CVSS. Par exemple, une faille avec un score élevé sur un endpoint API interne accessible uniquement après authentification présente un risque réel plus faible. À l'inverse, une fuite d'infos moyenne sur un paramètre exposé publiquement sur internet peut vous porter préjudice bien plus vite. Prenez toujours en compte le contexte d'exploitabilité.

On a vécu la même chose l'an dernier avec un rapport de 38 vulnérabilités. Au début, l'équipe pensait être bloquée sur les nouvelles features pendant des semaines. En analysant bien, on a vu que 14 des 38 failles se réglaient simplement en mettant à jour deux vieilles dépendances. Ces updates ont éliminé un tiers de la charge en 3 heures chrono.

Vérifiez tout de suite avec la boîte d'audit le délai accordé pour le re-test inclus dans votre contrat. En général, les contrats prévoient une fenêtre de 30 ou 45 jours gratuits pour valider les correctifs. Si vous ne patchez pas les failles critiques et élevées avant cette date limite pour obtenir le rapport de validation, vous allez devoir repayer.

Pour préserver le flux de travail, règle de capacité du sprint : 1) Allouez 30 % du prochain sprint uniquement aux failles critiques. 2) Utilisez les 70 % restants pour continuer vos livrables principaux promis aux clients. 3) Basculez les vulnérabilités de faible priorité dans le backlog de dette technique pour les résorber sur les cycles suivants.

Lors de notre premier pentest, quand le rapport de 50 pages est tombé, les devs l'ont pris personnellement et se sont mis sur la défensive, en mode « les gars de la sécu abusent ». Le plus important ici, c'est de préserver le moral de l'équipe. Il faut présenter le rapport aux développeurs non pas comme un bulletin de notes, mais comme une liste classique de dette technique repérée par un œil extérieur. Sinon, ça crée des frictions inutiles entre les devs et l'équipe sécu.

Sur ces 11 vulnérabilités faibles, au moins 5 sont sûrement des points génériques du genre support TLS, flags de cookies ou version du serveur. Ça ne va pas aider un attaquant, ne perdez pas de temps là-dessus et concentrez-vous direct sur la gestion des sessions et les failles d'autorisation.

Est-ce que votre client grand compte vous a imposé un délai officiel contractuel (SLA) pour les correctifs ? S'il n'y a pas de clause contraignante genre 14 jours pour les critiques et 30 jours pour les élevées, vous pouvez tout à fait adapter le calendrier selon votre propre rythme de dev.

Le plan résumé est clair : faites les màj de bibliothèques tout de suite pour réduire le volume, casez les failles critiques et élevées dans la fenêtre de re-test de la boîte, et envoyez au client un planning de remédiation d'une seule page avec des dates précises.

Résumé rapide pour les nouveaux : Ne comptez pas sur une seule mesure de sécurité ; allez par couches.

Bien sûr, cela change si votre situation est différente.

Nous avons vécu presque la même chose l'année dernière. bref commencez par un petit test ne vous engagez pas sur tout d'un coup.

Ne comptez pas sur une seule mesure de sécurité ; allez par couches.

Exactement, et ce n'est pas si connu que ça. Tous ceux qui se pressent sur processus de correction des vulnérabilités se heurtent au même obstacle.

Je suis passé par là, laissez-moi vous raconter. Si l'autorisation et le périmètre ne sont pas écrits, ne lancez pas ce test.

Si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.

Je partage mon expérience. La plupart des incidents ne viennent pas d'une faille, mais d'un mot de passe divulgué.

Ce conseil ne convient pas à tout le monde, je pense. Prendre des notes pendant deux semaines donne de meilleurs résultats qu'une estimation de six mois.

C'est mon avis, je ne l'écris pas comme une vérité absolue.

je ne savais pas ça.

Merci de partager le résultat.

Je me pose aussi la question.

je vais résumer le sujet, car plusieurs réponses différentes ont été données... ce qui nous faisait perdre le plus de temps c'était l'absence de clarté sur qui prenait les décisions.

une modification des coordonnées bancaires n'est jamais confirmée par le canal d'origine.. puis c'est mon avis, je ne l'écris pas comme une vérité absolue.