On a tenté de faire une revue de code sécurisée en interne mais on bloque — c'est quoi les pièges classiques ?

Paramétrez bien le « taint analysis » (suivi des données non fiables) dans vos outils d'analyse statique. Tracez la donnée saisie par l'utilisateur jusqu'à son arrivée en base ou dans une commande système. En virant les règles qui flaggent la moindre concaténation comme une injection SQL, vous éliminez direct deux tiers des alertes.

Faire relire son propre code sous l'angle de la sécurité par un dev qui n'a aucune formation là-dedans, c'est juste une formalité inutile. Celui qui a codé ne verra jamais ses propres erreurs de conception. Si votre budget est serré, ne faites pas auditer tout le système : un audit externe ciblé de 2-3 jours rien que sur l'authentification et le module de paiement sera bien moins cher et beaucoup plus efficace.

Ne refaites plus l'erreur d'analyser 12 000 lignes d'un coup. Découpez la revue de sécurité au niveau des pull requests. Pas plus de 300 lignes par merge, et une checklist limitée à 5 points de sécurité critiques. Il faut vérifier au fur et à mesure que le code s'écrit, pas en fin de sprint.

Au premier scan, on s'est retrouvés avec 410 alertes. L'équipe a ramé pendant deux semaines. Ensuite, on a calibré les filtres de sécurité pour ne cibler que le top 10 des failles web critiques ; le chiffre est tombé d'un coup à 19. Et sur ces 19 résultats, il n'y en avait que 4 qui représentaient un vrai risque et devaient être corrigés.

les outils d'automatisation comprennent rien à la logique métier du code ils font juste du pattern matching. du coup si vous utilisez des requêtes paramétrées dans vos bases de données, vous éliminez déjà quasi tous les risques d'injections sql, vous prenez pas la tête sur chaque alerte de l'outil.

Sur notre premier produit, on a passé des jours entiers à débattre de règles de validation regex ultra complexes avec l'équipe, tout fiers d'avoir fait une revue de code sécurisée. Trois jours après la mise en prod, un client a modifié la valeur d'un ID dans l'URL et a récupéré le bilan financier d'une autre boîte. C'est exactement ce genre de faille logique que les outils sont incapables de détecter.

Il y a trois pièges classiques dans lesquels vous tombez : 1) Prendre les résultats des outils pour parole d'évangile et perdre des heures sur des faux positifs, 2) Faire passer la revue de sécurité pour une évaluation de la perf du dev, ce qui le pousse à se braquer, 3) Confondre règles de style de code et vraies failles de sécurité.

En résumé : augmentez le seuil d'alerte des scanners automatiques pour limiter le bruit, découpez la revue en petits morceaux et testez manuellement via des scénarios les failles de logique d'autorisation que les outils ne peuvent pas voir.

j'y pensais aussi. du coup quand on décide sans mesuer on revient toujours au même point.

tout point non écrit est un point que les deux parties se rappelleront différemment plus tard... je le note au cas où.

Chez moi, c'est l'inverse qui s'est passé c'est pourquoi j'écris. La sécurité n'est pas absolue ; c'est rendre l'attaque trop coûteuse pour valoir l'effort.

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

je suis d'accord.

Résumé rapide pour les nouveaux : Une modification des coordonnées bancaires n'est jamais confirmée par le canal d'origine.

La sécurité n'est pas absolue ; c'est rendre l'attaque trop coûteuse pour valoir l'effort. Bon courage.

Chez nous, ça s'est passé comme ça. Une sauvegarde non testée n'est pas une sauvegarde.

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

Vous avez raison, je suis aussi passé par là. Les gens défendent l'habitude, pas le processus. La résistance vient de là.

Bon courage.

Je suis entièrement d'accord. Lors de la prise de décision, écrivez aussi le pire scénario, pas seulement le meilleur.

Si vous avez des questions, écrivez-moi, je répondrai au mieux.

Je vais résumer le sujet, car plusieurs réponses différentes ont été données. Les gens défendent l'habitude, pas le processus. La résistance vient de là.

je suis dans la même situation, c'est pourquoi je pose la question puis si c'est une première, commencez petit, l'échelle viendra plus tard.

si vous grondez les fausses alertes, plus personne ne signalera rien. c'est mon avis je ne l'écris pas comme une vérité absolue.

Ne manquez rien : La plupart des pertes de temps s'accumulent sur les tâches en attente de validation.

Commencez par un petit test ne vous engagez pas sur tout d'un coup. Bon courage.