Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Security Regression Testing

devsecops

Définition

Les Security Regression Tests (tests de non-régression de sécurité) sont des tests automatisés ajoutés dans les suites de tests d'un projet pour vérifier qu'une vulnérabilité de sécurité précédemment découverte et corrigée ne réapparaît pas dans les versions futures du logiciel. Inspirés du concept de regression testing général, les security regression tests transforment chaque vulnérabilité corrigée en un test permanent de la suite CI/CD, garantissant que le correctif reste effectif et que la vulnérabilité ne peut pas être réintroduite accidentellement lors de refactorisations ou de nouvelles fonctionnalités. Le processus de création d'un security regression test suit le cycle : 1) Découverte de la vulnérabilité (via bug bounty, audit, SAST/DAST, rapport d'incident), 2) Développement du correctif, 3) Écriture d'un test reproduisant la vulnérabilité avant le correctif (le test doit échouer sans le correctif et passer avec le correctif), 4) Vérification que le test passe avec le correctif appliqué, 5) Merge du correctif ET du test ensemble (les deux sont liés — on ne peut pas supprimer le test sans supprimer la protection), 6) Le test s'exécute à chaque build suivant, détectant immédiatement toute régression. Les security regression tests prennent différentes formes selon la nature de la vulnérabilité. Pour une injection SQL : un test qui envoie une payload SQL injection connue vers l'endpoint vulnérable et vérifie que la réponse ne contient pas de données de la base (le test reproduit l'exploitation). Pour un SSRF : un test qui envoie une URL pointant vers un service interne (169.254.169.254 pour les metadata cloud) et vérifie que la réponse est refusée. Pour un accès non autorisé : un test qui tente d'accéder à une ressource sans les permissions requises et vérifie le code 403. Les security regression tests sont complémentaires des outils SAST et DAST : là où SAST détecte des patterns de code potentiellement vulnérables et DAST teste le comportement dynamique général, les security regression tests sont des tests précis et ciblés sur des vulnérabilités connues et corrigées, fournissant une assurance forte que ces vulnérabilités spécifiques ne réapparaissent pas.

Écrire un security regression test

Exemple de security regression test pour une injection SQL corrigée (Python/pytest) : def test_sql_injection_regression_CVE_2024_1234(): # Test: SQL injection in user search must not be reachable (CVE-2024-1234 regression) payload = "' OR 1=1 --" response = client.get(f"/api/users?search={payload}") assert response.status_code in [400, 200] data = response.json() assert len(data.get("users", [])) < 100 # no data dump assert "admin" not in str(data) # admin creds not leaked Le test est nommé avec la CVE ou le ticket de bug pour la traçabilité, documenté avec une docstring expliquant la vulnérabilité corrigée.

Security Regression dans les pipelines CI

Les security regression tests s'intègrent dans les suites de tests existantes avec un tag spécifique (pytest -m "security_regression", Ginkgo --label-filter="security") permettant de les identifier et rapporter séparément. Une pratique recommandée : créer un fichier de test dédié (test_security_regressions.py ou security_regressions_test.go) regroupant tous les regression tests de sécurité, avec un commentaire référençant le ticket de bug ou la CVE pour chaque test. Ces tests doivent s'exécuter à chaque build (ils sont généralement rapides — ils testent des comportements spécifiques).

Intégration avec les Bug Trackers et les CVEs

La traçabilité entre vulnerability reports, correctifs, et security regression tests est assurée par : le référencement croisé (le ticket de bug référence le commit du correctif ET le commit du test de régression), les labels Git (le commit du test contient "security-regression: CVE-2024-XXXX" dans le message), et les rapports de tests CI (les résultats des security regression tests sont exportés en JUnit XML et archivés — un historique des tests passants prouve l'absence de régression dans le temps). DefectDojo permet de lier les findings de sécurité aux tests de régression correspondants.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis