Réponse courte : Utilisez le SAST en continu pour les motifs répétables et les politiques de code ; utilisez la revue manuelle quand la sécurité dépend du métier, de l'identité, de flux entre composants ou de l'exploitabilité réelle. Les équipes matures combinent les deux.
1. Ce que chaque méthode voit réellement
Le SAST inspecte la source ou une représentation intermédiaire avec des règles et modèles de flux. Il se répète rapidement à chaque changement et repère API dangereuses connues, chemins sans neutralisation, secrets codés et motifs interdits. La qualité dépend du langage, du framework et de la configuration.
Une personne peut demander pourquoi une route existe, comparer les rôles, suivre un parcours entre dépôts et juger si le contrôle correspond à la règle produit. Ce contexte est précieux pour contrôle d'accès, isolation tenant, authentification, concurrence et intégrations.
2. Choisir selon la question
| Question | SAST | Revue manuelle |
|---|---|---|
| Ce diff ajoute-t-il une fonction dangereuse connue ? | Fort et répétable | Utile pour confirmer |
| Le tenant A peut-il atteindre le tenant B ? | Souvent faible sans modèle custom | Fort avec contexte produit |
| Tous les dépôts suivent-ils une règle de code ? | Fort à l'échelle | Coûteux à répéter |
| Le candidat reste-t-il exploitable ? | Contexte parfois absent | Validation possible |
3. Les combiner sans dupliquer
- Exécuter un petit jeu SAST maintenu sur les pull requests et bloquer seulement les violations fiables.
- Trier les nouvelles alertes selon propriété, atteignabilité et contrôles existants ; noter les faux positifs.
- Planifier la revue manuelle autour des releases à risque et nouvelles frontières de confiance.
- Transformer les findings confirmés en tests de non-régression puis, si stable, en règles SAST.
- Suivre couverture et délai de correction, pas le nombre brut d'alertes.
pull request : SAST rapide + secrets + dépendances
nuit : analyse inter-fichiers plus profonde
jalon release : tests négatifs d'autorisation
changement risqué : threat model et revue manuelle ciblée
finding confirmé : test puis règle réutilisable si possibleErreurs fréquentes
- Acheter un scanner et appeler sa sortie non triée audit.
- Bloquer les builds avec des règles bruyantes jusqu'à ce qu'elles soient ignorées.
- Faire redécouvrir manuellement les mêmes motifs simples à chaque commit.
- Mesurer la sécurité au volume d'alertes plutôt qu'aux preuves et corrections.
- Exécuter l'une ou l'autre méthode sans threat model ni inventaire.
Checklist de décision
- Le support SAST correspond aux langages et frameworks.
- Chaque règle a un responsable, une sévérité et un processus de faux positifs.
- Les parcours métier à risque sont identifiés pour la revue manuelle.
- Les findings manuels comportent preuves et remédiation.
- Les problèmes confirmés deviennent des tests.
- Les métriques distinguent alertes candidates et findings validés.
- Code généré, dépendances et configuration ont une couverture séparée.
Limites
Aucune méthode ne prouve que le système déployé est sûr. Le SAST ignore de nombreuses configurations d'exécution ; la revue manuelle est limitée dans le temps. Tests dynamiques, dépendances, secrets et contrôles opérationnels apportent des preuves différentes.
Sources primaires
Ressources liées
Choisir la couverture d'une release
Appliquer ces contrôles au code et aux frontières produit réelles.