Security Testing
Tester la sécurité applicative comme on teste le reste : en continu.
01 — Le problème
Vous faites un test d'intrusion une fois par an, avant une échéance. Le rapport arrive, une partie est corrigée, le reste est reporté et oublié. Entre deux campagnes, l'application évolue chaque semaine sans qu'aucun contrôle de sécurité ne tourne. Les dépendances vieillissent sans que personne ne surveille.
02 — Ce que nous faisons
- 01
Cartographier la surface d’attaque réelle
Points d’entrée, authentification, autorisations, dépôts de fichiers, API exposées. On ne teste bien que ce qu’on a listé.
- 02
Tester les autorisations systématiquement
C’est la faille la plus fréquente et la moins couverte : chaque rôle × chaque ressource × chaque opération. Ce test s’automatise et doit tourner à chaque livraison.
- 03
Intégrer l’analyse dynamique à la chaîne
Un balayage DAST automatisé contre la préproduction, à chaque nuit, plutôt qu’un audit annuel manuel.
- 04
Traiter la chaîne de dépendances
Détection des vulnérabilités connues, politique de mise à jour, détection de secrets versionnés.
- 05
Aligner sur l’OWASP Top 10 sans s’y limiter
Le Top 10 est un point de départ, pas un périmètre. La logique métier produit des failles qu’aucune liste générique ne couvre.
04 — Ce que vous recevez
Des livrables nommés, pas des promesses. Vous savez ce que vous recevez avant de commencer.
Cartographie de la surface d’attaque
Suite de tests d’autorisation automatisée
Intégration DAST dans la chaîne CI/CD
Rapport de constats priorisés par exploitabilité
05 — Écosystème technique
Les outils ne font pas la qualité. Nous les maîtrisons pour pouvoir choisir le bon, pas pour en faire un argument.
- OWASP ZAP
- Burp Suite
- Trivy
- Gitleaks
- CodeQL
- Dependabot