Votre application est en production depuis six mois.
Vos développeurs ont livré dans les délais, les tests fonctionnels sont verts, le client est satisfait. Et pourtant, quelque part dans ce code, une vulnérabilité critique attend patiemment d'être exploitée, peut-être depuis la première ligne écrite.
Ce scénario n'est pas hypothétique. C'est la réalité de 84 % des bases de code selon le rapport Synopsys 2024 : elles contiennent au moins une vulnérabilité connue dans leurs dépendances open source. Et la majorité de ces failles n'ont jamais été auditées par un humain, elles ont simplement été importées, silencieusement, via un package npm, une librairie Python ou un jar Maven.
SAST et SCA sont les deux outils qui permettent de traiter ce problème à la source dans le code, avant la mise en production. Mais la confusion entre les deux est fréquente, leur déploiement souvent mal calibré, et leur valeur réelle rarement exploitée au maximum.
Cet article vous explique ce que sont réellement le SAST et le SCA, en quoi ils se complètent, comment les intégrer sans ralentir vos équipes et pourquoi, seuls, ils ne suffisent pas.
|
Ce que vous allez apprendre → Ce que sont le SAST et le SCA et la différence fondamentale entre les deux → Les types de vulnérabilités que chacun détecte (et ceux qu'il manque) → Comment intégrer SAST et SCA dans un pipeline CI/CD sans bloquer les équipes → Les 5 erreurs d'implémentation les plus fréquentes → Pourquoi SAST + SCA ne remplacent pas un pentest applicatif → La complémentarité avec l'approche offensive de Piirates |
Partie 1 SAST et SCA : deux outils, deux natures de risques
Le SAST : analyser ce que votre code fait vraiment
Le SAST (Static Application Security Testing), ou analyse statique de sécurité consiste à examiner le code source d'une application sans l'exécuter. L'outil parcourt l'intégralité du code à la recherche de patterns connus comme dangereux : injections SQL, failles XSS, mauvaise gestion des secrets, désérialisation non sécurisée, mauvais contrôle des entrées...
C'est un peu comme relire un contrat ligne par ligne à la recherche de clauses abusives sans avoir besoin de le signer pour en trouver.
|
Définition SAST Static Application Security Testing : analyse du code source, bytecode ou binaire d'une application SANS l'exécuter, à la recherche de vulnérabilités de sécurité connues dans la logique applicative. Quand ? Pendant le développement, à chaque commit, dans la CI/CD. Ce qu'il analyse : votre propre code — la logique métier, les flux de données, les appels aux API, la gestion des sessions et des droits. |
Ce que le SAST détecte
- Injections (SQL, LDAP, commande OS, XPath) — le code passe-t-il des données utilisateur non filtrées à des fonctions sensibles ?
- Cross-Site Scripting (XSS) — les sorties HTML sont-elles correctement encodées ?
- Mauvaise gestion des secrets — mots de passe, clés API ou tokens en dur dans le code
- Désérialisation non sécurisée — traitement de données sérialisées sans validation
- Contrôle d'accès défaillant — logique d'autorisation insuffisante ou contournable
- Erreurs cryptographiques — algorithmes dépréciés, mauvaise gestion des IV, entropie faible
- Gestion d'erreurs exposant des informations — stack traces renvoyées au client
Ce que le SAST ne détecte pas
|
Angles morts du SAST Le SAST ne peut pas analyser ce qui n'est pas dans votre code source propre : ✗ Les vulnérabilités dans vos dépendances tierces (librairies, frameworks, packages) ✗ Les failles de configuration d'infrastructure (serveur, cloud, réseau) ✗ Les vulnérabilités de logique métier complexes qui nécessitent une compréhension du contexte ✗ Les failles qui n'apparaissent qu'à l'exécution (race conditions, timing attacks) |
Le SCA : auditer ce que vous importez
Le SCA (Software Composition Analysis) répond à une réalité moderne du développement : une application d'entreprise est rarement composée à 100 % de code maison. En moyenne, 70 à 90 % du code d'une application moderne provient de dépendances open source.
Le SCA inventorie l'ensemble de ces composants tiers, bibliothèques, frameworks, packages, modules et les compare à des bases de données de vulnérabilités connues (CVE, NVD, GitHub Advisory, OSV...) pour identifier celles qui présentent un risque.
|
Définition SCA Software Composition Analysis : analyse de la composition logicielle d'une application pour identifier les composants open source utilisés, leurs versions, leurs licences et les vulnérabilités connues qui les affectent. Quand ? En continu — à chaque ajout de dépendance ET en monitoring permanent des CVE publiés. Ce qu'il analyse : vos dépendances directes et transitives — tout ce que vous importez, même indirectement. |
Ce que le SCA détecte
- CVE connues dans les versions de packages utilisés (ex : Log4Shell dans log4j 2.14.1)
- Dépendances transitives vulnérables — une librairie que vous importez peut elle-même importer quelque chose de compromis
- Composants abandonnés — plus maintenus, donc plus corrigés
- Licences non conformes — GPL dans du code propriétaire, licences restrictives incompatibles
- Versions obsolètes avec historique de vulnérabilités non corrigées
Ce que le SCA ne détecte pas
|
Angles morts du SCA Le SCA ne regarde que les composants connus et répertoriés : ✗ Les vulnérabilités de type 0-day non encore publiées dans les bases CVE ✗ Les failles dans votre propre code (c'est le rôle du SAST) ✗ Les supply chain attacks sophistiquées (typosquatting, packages malveillants non encore détectés) ✗ Les failles de configuration et de déploiement |
SAST vs SCA : la comparaison structurée
|
Critère |
SAST |
SCA |
|
Ce qu'il analyse |
Votre code source (logique applicative) |
Vos dépendances tierces (composants importés) |
|
Quand l'utiliser |
À chaque commit, en CI/CD |
En continu, y compris après déploiement |
|
Vulnérabilités détectées |
XSS, injections, secrets exposés, logique d'accès défaillante... |
CVE connues, licences non conformes, composants abandonnés... |
|
Faux positifs |
Nombreux — nécessite calibration et triage |
Moins nombreux mais peut manquer le contexte d'exploitation |
|
Exemples d'outils |
Semgrep, SonarQube, Checkmarx, CodeQL |
Snyk, Dependabot, OWASP Dependency-Check, Trivy |
|
Ce qu'il ne voit pas |
Les failles dans les libs tierces |
Les failles dans votre propre code |
« SAST et SCA ne sont pas concurrents. Ils sont complémentaires par construction : l'un audite ce que vous écrivez, l'autre audite ce que vous importez. Ensemble, ils couvrent la surface d'attaque statique de votre application. »
Toutes nos missions sont spécifiques
Parce que vos enjeux le sont !
Le pentest est avant tout une philosophie qui, couplé avec nos compétences techniques multiples peut s’adapter aux diffférentes cibles.
Indépendance totale
Expertise
Professionnalisme
Partie 2 : Intégration dans le pipeline : de la théorie à la pratique
Le shift-left : détecter tôt pour corriger moins cher
Le principe du shift-left en sécurité applicative est simple : plus une vulnérabilité est détectée tôt dans le cycle de développement, moins elle coûte cher à corriger.
|
Phase de détection |
Coût relatif de correction |
Impact opérationnel |
|
Pendant le développement (IDE) |
×1 correction immédiate |
Nul |
|
En CI/CD (avant merge) |
×6 |
Retard de livraison limité |
|
En recette / staging |
×15 |
Délai de mise en production |
|
En production (pentest ou incident) |
×100 ou plus |
Incident, patch d'urgence, exposition publique |
Architecture type d'un pipeline DevSecOps avec SAST et SCA
Configurer les Quality Gates sans paralyser les équipes
L'erreur la plus fréquente lors du déploiement d'un SAST ou d'un SCA est de bloquer le pipeline sur chaque alerte, quelle que soit sa sévérité. Résultat : les développeurs désactivent les outils ou apprennent à ignorer les alertes l'effet inverse de celui recherché.
Une configuration efficace repose sur une segmentation par criticité :
|
Sévérité CVSS |
Comportement recommandé |
Délai de correction cible |
|
Critical / High |
Bloque le merge |
Immédiat avant toute mise en production |
|
Medium |
Alerte + ticket créé automatiquement |
Sous 30 jours |
|
Low / Info |
Logged — traité lors des sprints de dette technique |
Sous 90 jours ou accepté documenté |
SAST : les points de configuration critiques
1. Définir les règles pertinentes pour votre stack
Un SAST générique appliqué à un projet Python Django avec des règles conçues pour du C++ va produire un volume de faux positifs ingérable. La première étape est de configurer le ruleset en fonction de votre langage, votre framework et votre contexte :
- semgrep --config p/python pour Python, --config p/django pour les patterns Django spécifiques
- Désactiver les règles non applicables à votre contexte (ex : règles de désérialisation Java si vous êtes en Go)
- Ajouter des règles custom pour vos patterns d'entreprise spécifiques (ex : utilisation d'une lib interne de validation)
2. Gérer les faux positifs avec des annotations structurées
Plutôt que de désactiver une règle globalement, annotez le code pour documenter pourquoi une alerte est acceptée :
|
# nosemgrep: python.lang.security.audit.hardcoded-password-string # Justification: valeur de test uniquement non utilisée en production # Approuvé par: security@company.com — 2024-11-15 TEST_PASSWORD = 'test_password_fixture' |
Cette approche préserve la traçabilité : on sait quelles alertes ont été supprimées, par qui, et pourquoi.
SCA : au-delà du scan initial
Le problème des dépendances transitives
Votre application importe directement 47 packages. Chacun de ces packages en importe d'autres. Au total, votre surface réelle peut dépasser 500 composants et vous n'en connaissez directement que moins de 10 %.
Un SCA efficace doit analyser l'arbre de dépendances complet, pas seulement le fichier package.json ou requirements.txt de surface. La commande suivante illustre cette profondeur :
|
$ npm ls --all 2>/dev/null | wc -l 847 # <-- dépendances directes + transitives dans un projet React moyen
$ snyk test --all-projects Testing /app... Found 12 vulnerabilities (3 critical, 5 high, 4 medium) in 847 dependencies |
Le monitoring continu : la fonction souvent oubliée du SCA
Un scan SCA au moment du développement est nécessaire mais insuffisant. Une CVE critique peut être publiée demain sur une dépendance que vous utilisez en production depuis deux ans et qui était parfaitement saine lors de votre dernier audit.
Le SCA doit donc fonctionner en deux modes complémentaires :
- Mode CI/CD : scan à chaque build pour bloquer l'introduction de nouvelles vulnérabilités
- Mode monitoring : surveillance continue des CVE publiées sur les composants déjà déployés — avec alertes automatiques vers l'équipe responsable
|
Exemple concret : Log4Shell (CVE-2021-44228) En décembre 2021, une CVE critique (CVSS 10.0) est publiée dans log4j — une librairie Java utilisée dans des millions d'applications. Les organisations équipées d'un SCA en monitoring continu ont reçu une alerte automatique le jour même et ont pu prioriser leur réponse. Les autres ont découvert leur exposition des semaines plus tard, lors d'audits manuels ou pire après une exploitation. |
Partie 3 : Les 5 erreurs d'implémentation les plus fréquentes
Erreur 1 : Scanner sans trier : le piège du volume d'alertes
Un SAST non calibré sur un projet de taille moyenne peut générer plusieurs centaines d'alertes au premier scan. Si chaque alerte exige une action, les développeurs sont submergés et ils apprennent rapidement à ignorer les notifications.
Solution : commencez par un scope restreint. Sur un nouveau projet, configurez uniquement les règles High/Critical. Sur un projet existant, scannez uniquement le code modifié (diff scanning) avant d'élargir progressivement au code legacy.
Erreur 2 : Confondre présence d'une CVE et exploitabilité réelle
Le SCA vous dit qu'une dépendance contient une vulnérabilité. Il ne vous dit pas si cette vulnérabilité est accessible dans votre contexte d'utilisation. Une CVE critique dans une fonction que vous n'appelez jamais n'a pas le même niveau de risque qu'une CVE medium dans un endpoint exposé à Internet.
Solution : utilisez la notion de reachability analysis proposée par les SCA modernes (Snyk, Socket). Elle analyse si le code vulnérable est réellement appelé dans votre application avant de scorer la sévérité.
Erreur 3 : Négliger les dépendances de développement
Les packages installés uniquement pour le développement (devDependencies en Node.js, dev-dependencies en Python/Poetry) sont souvent exclus des scans SCA. Or, un outil de build ou de test compromis peut être utilisé pour exfiltrer des secrets, injecter du code malveillant dans le build, ou compromettre la chaîne de déploiement.
Solution : incluez systématiquement les dépendances de développement dans le périmètre SCA, en les classant séparément pour prioriser différemment.
Erreur 4 : Traiter SAST et SCA comme des audits ponctuels
De nombreuses organisations effectuent un scan SAST/SCA avant chaque release majeure et l'oublient entre-temps. C'est insuffisant : les nouvelles CVE sont publiées en continu, le code évolue quotidiennement, et les dépendances sont mises à jour à chaque sprint.
Solution : intégrez SAST et SCA dans le pipeline CI/CD comme des étapes automatiques non optionnelles, et activez le monitoring continu SCA en production.
Erreur 5 : Penser que SAST + SCA = sécurité applicative complète
C'est l'erreur la plus dangereuse. SAST et SCA couvrent la surface statique de votre application. Ils ne peuvent pas détecter les vulnérabilités de logique métier, les failles qui n'apparaissent qu'à l'exécution, les mauvaises configurations de déploiement, ou les comportements anormaux en contexte réel d'exploitation.
Solution : SAST et SCA sont la première ligne de défense, pas la dernière. Ils doivent être complétés par du DAST, des tests de pénétration réguliers, et des revues de sécurité humaines ciblées sur la logique métier.
Partie 4 : Ce que SAST et SCA ne voient pas : le rôle du pentest
La surface d'attaque invisible des outils automatiques
Les outils SAST et SCA sont excellents pour détecter les patterns connus et les composants vulnérables. Mais un attaquant réel ne se limite pas aux CVE publiées. Il cherche à comprendre votre logique métier, à combiner plusieurs comportements normaux en une chaîne d'exploitation anormale, à trouver les angles que vos outils ne savent pas modéliser.
Voici ce qu'un pentest applicatif révèle et que SAST et SCA ne peuvent pas voir :
|
Ce que SAST + SCA couvrent bien |
Ce qu'un pentest couvre en plus |
|
Injections SQL, XSS, SSRF dans le code source |
Injections complexes combinant plusieurs paramètres ou étapes |
|
CVE connues dans les dépendances |
0-days, techniques d'exploitation non documentées |
|
Secrets en dur dans le code |
Secrets exposés dans les réponses API, les logs, les erreurs |
|
Mauvaise gestion des droits dans le code |
Escalade de privilèges via logique métier (ex : accéder aux données d'un autre utilisateur) |
|
Algorithmes crypto dépréciés |
Attaques sur l'implémentation réelle : timing, oracle, rejeu de session |
|
Composants open source non maintenus |
Chaînes d'attaque multi-composants (ex : SSRF → accès metadata cloud → exfiltration) |
« Un outil SAST ne comprend pas votre métier. Il ne sait pas que dans votre application, un utilisateur avec le rôle 'viewer' ne devrait jamais pouvoir accéder à l'endpoint /admin/export même si le code ne lève aucune exception. »
L'approche Piirates : de l'outil à l'attaquant réel
Piirates est une entreprise de cybersécurité offensive indépendante spécialisée en pentest et en formation. Notre approche du pentest applicatif va au-delà de la vérification des alertes SAST/SCA non traitées.
Nos pentesters raisonnent comme des attaquants : ils partent des fonctionnalités exposées, remontent vers les mécanismes d'authentification et d'autorisation, testent les transitions d'état, manipulent les paramètres, chaînent les comportements inattendus. Ils opèrent avec ou sans code source selon le périmètre défini.
Ce qu'un pentest applicatif Piirates couvre
- Tests d'authentification et de session : force brute, fixation de session, token prévisible, logout insuffisant
- Tests d'autorisation : IDOR, escalade horizontale et verticale, contournement de logique d'accès
- Tests d'injection : SQL, NoSQL, LDAP, commandes OS, template, XPath dans le contexte réel d'exécution
- Tests de logique métier : manipulation de prix, contournement de workflows, abus de fonctionnalités légitimes
- Tests d'API : REST, GraphQL, WebSocket exposition excessive, lack of rate limiting, mass assignment
- Tests de supply chain : vérification de l'intégrité des librairies, des fichiers de build, des scripts de déploiement
Le pentest peut également s'appuyer sur les résultats de votre SAST/SCA pour prioriser les zones d'investigation et inversement, les conclusions du pentest peuvent affiner vos règles SAST et vos seuils SCA.
|
L'articulation idéale : SAST + SCA + Pentest Piirates SAST en CI/CD → détecte les patterns dangereux dans votre code à chaque commit SCA en continu → surveille vos dépendances et alerte sur les nouvelles CVE Pentest Piirates → valide ce que les outils ne voient pas logique métier, chaînes d'exploitation, 0-days, comportement réel d'un attaquant Ces trois couches ensemble donnent une couverture de sécurité applicative réellement complète. |
Partie 5 : Choisir ses outils, panorama et critères de sélection
Critères de sélection : les questions à se poser
- Stack technologique : l'outil supporte-t-il vos langages et frameworks (Go, Rust, Kotlin, React, Django...) ?
- Intégration CI/CD : plugin natif pour votre outil (GitHub Actions, GitLab CI, Jenkins, Azure DevOps) ?
- Faux positifs : quel est le ratio signal/bruit par défaut ? Peut-on le calibrer facilement ?
- Reachability analysis : pour le SCA, l'outil analyse-t-il si le code vulnérable est réellement appelé ?
- Fix automatique : l'outil peut-il ouvrir des PR de correction automatiquement (montée de version, patch) ?
- Monitoring continu : pour le SCA, alerte-t-il en temps réel sur les nouvelles CVE publiées sur vos composants déployés ?
- Compliance : les rapports sont-ils exploitables pour NIS2, ISO 27001, PCI-DSS, HDS ?
Partie 6 : Cas pratique : mise en place d'un pipeline SAST + SCA
Contexte
Une scale-up SaaS de 120 personnes développant une plateforme B2B en Python/Django + React. Aucun outil de sécurité applicative en place. Un pentest Piirates réalisé 6 mois plus tôt avait révélé plusieurs vulnérabilités IDOR et une injection SQL toutes corrigées, mais la direction voulait s'assurer que ces patterns ne réapparaissent pas.
Ce qui a été mis en place en 4 semaines
- Semaine 1 : Audit de la dette existante / scan SCA initial avec Snyk sur l'ensemble du projet. Résultat : 3 CVE critiques (dont une dans une version de Django non maintenue), 12 High. Priorisation et correction immédiate des critiques.
- Semaine 2 : Intégration SAST en CI/CD / Semgrep configuré sur les règles python + django + custom (patterns d'injection identifiés lors du pentest Piirates). Quality Gate : bloque si Critical ou High. Scan de diff uniquement pour ne pas ralentir les MR.
- Semaine 3 : Intégration SCA en CI/CD + monitoring / Dependabot activé pour les PR de mise à jour automatique. Snyk configuré en monitoring continu sur le projet de production.
- Semaine 4 : Formation des développeurs / session de sensibilisation Piirates d'une demi-journée sur les patterns OWASP Top 10 les plus fréquents dans leur stack avec les vrais exemples détectés dans leur propre code.
Résultats à 3 mois
|
Résultats observés → 0 injection SQL ou IDOR introduite depuis l'activation du SAST (vs 3 détectées lors du pentest initial) → Délai moyen de correction des CVE High : 8 jours (vs corrections manuelles ad hoc auparavant) → 2 CVE critiques détectées et corrigées en monitoring continu avant tout signalement externe → Réduction de 60 % du temps passé en revue de sécurité manuelle lors des code reviews → Pentest de validation Piirates à 3 mois aucune vulnérabilité liée aux patterns précédemment détectés |
À lire également sur piirates.fr
|
Nos expertises Pentest → Pentest Application Web & Mobile → Pentest Système d'information |
Nos formations cybersécurité → Sécurité des applications Web & Mobile → Gestion de crise cyber — parcours complet |
Automatiser la détection, conserver le jugement humain
SAST et SCA sont devenus incontournables dans tout processus de développement sécurisé. Ils permettent de détecter automatiquement, à grande échelle, les vulnérabilités connues dans votre code et vos dépendances bien avant qu'elles n'atteignent la production.
Mais ils ne remplacent pas le jugement d'un expert. Les failles de logique métier, les chaînes d'exploitation multi-étapes, les comportements anormaux en contexte réel d'attaque tout cela échappe aux outils automatiques par nature. C'est pourquoi les organisations les plus matures combinent l'automatisation SAST/SCA avec des pentests offensifs réguliers.
La bonne question n'est pas « SAST ou pentest ? » c'est « comment les articuler pour une couverture maximale avec un effort raisonnable ? »
« Un outil détecte ce qu'il a appris à chercher. Un attaquant cherche ce que personne n'a encore pensé à détecter. »
Votre code est probablement déjà en production. La vraie question est : savez-vous ce qu'il contient ?
Ce que nous ne faisons pas
(Liste non exhaustive)
Piratage de boite mail
Piratage comptes réseaux sociaux
Espionnage
Exfiltration de sms
Récupération de Cryptomonnaies
Prise en main à distance de véhicules
Suivi GPS de véhicule
Envoyez nous un ping
Non. SAST et SCA couvrent la surface statique et les composants connus. Un pentest teste le comportement réel de l'application face à un attaquant qui raisonne, improvise et enchaîne les vulnérabilités. Les deux sont complémentaires : SAST/SCA réduisent la surface avant le pentest, le pentest révèle ce que les outils ne voient pas.
Idéalement, à chaque commit ou pull request en mode diff (analyse uniquement le code modifié) pour ne pas pénaliser la vitesse des équipes. Un scan complet peut être schedulé hebdomadairement ou avant chaque release majeure.
Pour le SAST, Semgrep (open source) est un excellent point de départ rapide, multi-langages, avec des règles communautaires de qualité. Pour le SCA, Dependabot (natif GitHub) ou OWASP Dependency-Check sont gratuits et couvrent les cas d'usage essentiels. Ces outils peuvent ensuite être complétés par des solutions commerciales à mesure que votre maturité DevSecOps augmente.
La combinaison la plus efficace : d'abord un scan SAST/SCA initial pour identifier les patterns vulnérables réels dans votre code, puis une formation Piirates ciblée sur ces patterns spécifiques (OWASP Top 10 appliqué à votre stack). Les développeurs apprennent sur leurs propres erreurs la rétention est bien meilleure que sur des exemples génériques.
SAST et SCA ne sont pas interchangeables. Découvrez comment ces deux outils se complètent, comment les intégrer sans bloquer vos équipes et pourquoi ils ne remplacent pas un pentest applicatif.
