SAST et DAST dans les pipelines CI/CD

Le test de sécurité des applications permet d’identifier les vulnérabilités avant que le code n’arrive en production. Deux approches complémentaires existent : SAST (statique, sans exécuter le code) et DAST (dynamique, en testant une application en cours d’exécution). Toutes deux peuvent être intégrées aux chaînes d’intégration et de livraison continues afin d’intégrer la sécurité plus tôt.

SAST analyse le code source, le bytecode ou le binaire à la recherche de vulnérabilités de sécurité, sans exécuter le code. Il peut s’exécuter à chaque validation et fournir un retour rapide.

Points forts : détection précoce des bogues, couverture complète du code, aucun environnement d’exécution nécessaire.

Points faibles : taux élevé de faux positifs, dépendance au langage, problèmes de configuration à l’exécution non détectés.

Outils SAST à code source ouvert :

Exemple d’étape SAST de GitHub Actions :

DAST teste une application en cours d’exécution depuis l’extérieur, en simulant un attaquant. Il détecte les vulnérabilités visibles uniquement à l’exécution : problèmes d’authentification, failles de gestion des sessions et bogues de validation des entrées.

Points forts : peu de faux positifs, indépendant du langage, détection des problèmes de configuration à l’exécution.

Points faibles : nécessite un environnement en cours d’exécution, peut manquer certains chemins d’exécution.

Outils DAST pour l’intégration et la livraison continues :

IAST instrumente l’application à l’exécution à l’aide d’agents qui surveillent l’exécution du code pendant les tests fonctionnels. Il associe la précision de SAST à la couverture de DAST. Exemples : Contrast Security, Seeker. Nécessite des agents propres au langage et l’exécution de tests.

Intégrer la sécurité plus tôt signifie déplacer les tests de sécurité vers une étape plus précoce du cycle de développement — idéalement dans l’IDE du développeur et au moment de la validation, plutôt que de les réserver à une étape de contrôle distincte avant la mise en production. Une détection plus précoce = des corrections moins coûteuses.

Multiplicateur de coût : un bogue en développement coûte 1 fois plus cher ; en préproduction, 10 fois plus cher ; en production, 100 fois plus cher.

Les outils SAST produisent des faux positifs. Pour les gérer :

• Utilisez nosec (Bandit) ou des commentaires de suppression intégrés pour les problèmes confirmés comme inexistants
• Ajustez les ensembles de règles au contexte de l’application
• Consignez la justification des suppressions dans des commentaires du code
• Examinez régulièrement les suppressions

Une chaîne de sécurité complète :

1. Crochets avant validation : analyse des secrets (gitleaks), SAST (semgrep)
2. Contrôles de PR : résultats de SAST, analyse des dépendances (Dependabot)
3. Déploiement en préproduction : analyse DAST (base de référence ZAP)
4. Production : surveillance à l’exécution (RASP, WAF)

Indicateurs clés d’AppSec dans l’intégration et la livraison continues :

• Temps moyen de correction des constatations de sécurité
• Taux de constatations pour 1 000 lignes de code
• Taux de faux positifs (qui influence la confiance des développeurs)
• Taux de vulnérabilités passées inaperçues jusqu’à la production (trouvées en préproduction ou en production)

Quel type de test de sécurité analyse le code source sans l’exécuter et fournit un retour directement dans la chaîne d’intégration à chaque validation ?

SAST analyse le code de manière statique (retour précoce, nombreux faux positifs) ; DAST teste dynamiquement les applications en cours d’exécution (précision à l’exécution, environnement nécessaire). Tous deux ont leur place dans les chaînes d’intégration et de livraison continues. Intégrer la sécurité plus tôt permet de détecter les vulnérabilités lorsque les corrections coûtent le moins cher. Outils courants : Semgrep, Bandit (SAST) ; OWASP ZAP, Nuclei (DAST). Ajustez les ensembles de règles et suivez les suppressions pour gérer les faux positifs.