Comment abordez-vous une revue de code sécurisée ?

La revue de code sécurisée est là où l'appsec gagne sa place, parce qu'elle peut attraper une faille avant qu'elle ne soit jamais livrée. Les recruteurs interrogent dessus pour voir si vous savez utiliser les outils comme un multiplicateur de force sans confondre leur sortie avec le vrai travail — qui est le jugement humain sur le contexte.

Commencer par le contexte

Avant de lire le code, comprenez l'application : que fait-elle, quelles données sont sensibles, et par où entre l'entrée non fiable ? Appuyez-vous sur (ou construisez) un modèle de menace rapide. Cela vous dit où dépenser votre attention limitée — il n'y a pas le temps de tout lire avec un soin égal, alors vous ciblez la surface à risque.

Les outils : des pistes, pas des verdicts

• Le SAST lit le source de manière statique et excelle pour l'ampleur : secrets codés en dur, sinks propices aux injections, désérialisation non sécurisée, API crypto faibles. Mais il produit des faux positifs et ne peut pas comprendre l'intention.
• Le DAST sollicite l'application en cours d'exécution depuis l'extérieur et confirme l'exploitabilité de classes entières de bugs, mais a une visibilité du code superficielle.

Utilisez les deux pour générer des pistes, puis triez. Ouvrir des bugs à partir de la sortie brute du SAST est le moyen le plus rapide de perdre la confiance des développeurs — chaque faux positif que vous transmettez l'érode.

Là où les humains gagnent

Consacrez l'effort manuel à ce que les outils ne peuvent structurellement pas juger :

• Logique d'autorisation — l'utilisateur A peut-il atteindre les données de l'utilisateur B ? Les outils voient le code, pas l'intention de contrôle d'accès derrière.
• Logique métier — abuser de fonctionnalités légitimes (bugs du type sauter-l'étape-de-paiement).
• Usage de la cryptographie — le bon algorithme mal utilisé (mode ECB, IV statiques, schémas maison).
• Frontières de confiance — là où les données passent du non fiable au fiable, vérifier qu'elles sont réellement assainies.

La technique centrale est de tracer le flux de données de la source au sink : suivre l'entrée non fiable de l'entrée jusqu'à l'opération dangereuse, en vérifiant chaque transformation au passage pour validation et encodage.

Ce que recherchent les recruteurs

Ils veulent une attention guidée par le modèle de menace, le SAST/DAST traités comme des pistes à trier, l'attention manuelle sur l'authz et la logique métier, et le raisonnement de flux de données source-vers-sink — plus l'empathie de protéger la confiance de l'équipe en filtrant les faux positifs.