Analyse statique de code pour la sécurité : comment l’analyse statique de code (SAST) répond aux 10 principales vulnérabilités de l’OWASP

Il est plus facile de prévenir les failles de sécurité que de les corriger. Une faille d'injection SQL détectée lors d'une revue de code se corrige en quelques minutes. La même faille, découverte après une violation de données, engendre des semaines de gestion d'incident, d'enquête réglementaire et de remédiation, sans compter les données exfiltrées entre-temps. L'analyse statique de code consiste à identifier ces problèmes avant l'exécution du code, en examinant la structure du code source, le flux de données et les schémas de comportement par rapport aux signatures de vulnérabilités connues. Appliquée systématiquement, elle transforme la sécurité d'une pratique réactive en une composante essentielle du processus de développement.

Le Top 10 de l'OWASP est le catalogue de référence des risques de sécurité les plus critiques pour les applications web. Mis à jour par l'Open Web Application Security Project à partir de données de vulnérabilités réelles issues de milliers d'applications, il recense tous les éléments, à des degrés divers, détectables par les outils d'analyse statique. Ce guide établit une correspondance entre chaque catégorie OWASP et les vulnérabilités que l'analyse statique peut identifier, présente le schéma de code vulnérable et son équivalent sécurisé, et explique quels outils appliquent chaque technique.

Qu’est-ce que le test de sécurité statique des applications (SAST) ?

Les tests statiques de sécurité des applications (SAST) analysent le code source, le bytecode ou le binaire sans exécuter le programme. L'analyse examine le flux de données au sein de l'application, les opérations sensibles auxquelles ces données sont associées et vérifie si un chemin quelconque à partir d'une entrée externe (saisie utilisateur, paramètres HTTP, contenu de fichier, variables d'environnement) conduit à une opération dangereuse (requête de base de données, commande système, sortie HTML, fonction cryptographique) sans validation ni nettoyage approprié.

SAST constitue une couche parmi d'autres au sein d'un programme complet de sécurité des applications. Pour comprendre son rôle, il est nécessaire de la comparer aux solutions alternatives :

Approche	Quand ça marche	Ce qu'il trouve	Ce qui manque
SAST (Statique)	Avant l'exécution, sur le code source	Vulnérabilités au niveau du code, schémas d'injection, utilisation abusive de la cryptographie, secrets codés en dur	Vulnérabilités d'exécution uniquement, problèmes de configuration lors du déploiement
DAST (Dynamique)	Contre une application en cours d'exécution	Comportement en cours d'exécution, failles d'authentification, problèmes de configuration du serveur	Modèles au niveau du code non déclenchés lors des tests
SCA (Analyse de la composition logicielle)	Sur les manifestations de dépendance	CVE connues dans les bibliothèques tierces	vulnérabilités du code personnalisé
IAST (Interactif)	Lors de l'exécution des tests avec instrumentation	Flux de données d'exécution avec une grande précision	Nécessite l'exécution de l'application, retour d'information plus lent

L'analyse statique de code (SAST) fournit un retour d'information précoce ; elle s'exécute sur du code non encore déployé, ni dans le pipeline CI/CD, ni même dans l'IDE, avant même que la vulnérabilité n'atteigne un environnement de test. Cette précocité constitue son principal atout en matière de sécurité.

Quels types de menaces l'analyse statique du code peut-elle atténuer ?

Voici l'une des questions les plus fréquemment posées concernant SAST. La réponse directe :

L'analyse statique de code permet d'atténuer les menaces qui se manifestent dans les schémas du code source : vulnérabilités d'injection (SQL, commandes, XSS), utilisation abusive de la cryptographie, identifiants codés en dur, implémentations d'authentification non sécurisées, contrôle d'accès défaillant dans la logique du code et atteintes à l'intégrité des données. Elle ne peut cependant pas atténuer les menaces liées à la configuration d'exécution, à la topologie du réseau ou à l'infrastructure ; celles-ci nécessitent une analyse dynamique du code (DAST), des tests d'intrusion ou une analyse de sécurité de l'infrastructure.

Analyse statique vs. analyse dynamique de la couverture OWASP

L'analyse dynamique (DAST) et l'analyse statique (SAST) détectent différents sous-ensembles de vulnérabilités OWASP. Aucune n'est exhaustive. Le guide de test de sécurité web OWASP (WSTG) constitue le cadre méthodologique des tests dynamiques ; les outils SAST tels que CodeQL, Semgrep et SonarQube analysent la couche source.

Les 10 meilleures catégories de l'OWASP	Couverture SAST	Couverture DAST
Contrôle d'accès cassé	Lacunes partielles dans la logique du code	Bon, tests de comportement en cours d'exécution
Échecs cryptographiques	Détection algorithmique robuste	Faible, difficile à observer de l'extérieur
Injection	Analyse de la contamination solide	Tests de charge utile robustes et actifs
Conception non sécurisée	Détection partielle de motifs	Faible, nécessite des connaissances en conception
Mauvaise configuration de la sécurité	Partiel, configuration dans le code	Tests robustes en environnement réel
Composants vulnérables	Faible, SCA est meilleur	Faible, SCA est meilleur
Échecs d'authentification	Crédits partiels et codés en dur, modèles faibles	Tests robustes de session et d'authentification
Défaillances d'intégrité des données	Modèles de désérialisation partiels	Faible, difficile à détecter de l'extérieur
Échecs de journalisation	Instructions de journalisation partielles et manquantes	Faible absence, difficile à observer
SSRF	Forte contamination de l'appel HTTP	Tests de requêtes robustes et actifs

En conclusion, les outils SAST et DAST sont complémentaires. Pour une couverture OWASP optimale, il est recommandé d'utiliser les deux. Pour les équipes disposant d'un budget limité et partant de zéro, il est conseillé de commencer par le SAST : il offre un retour d'information plus rapide aux développeurs et une couverture d'injection plus étendue.

Les 10 principaux résultats de l'OWASP : que révèle l'analyse statique et comment ?

A01, Contrôle d'accès défectueux

Le contrôle d'accès défaillant constitue le principal risque selon l'OWASP. L'analyse statique permet d'identifier les manifestations au niveau du code : absence de contrôles d'autorisation sur les fonctions et les points de terminaison, références d'objets exposant des identifiants internes sans validation et attributions de rôles codées en dur contournant les structures d'autorisation prévues.

Ce que l'analyse statique détecte : les méthodes qui gèrent des opérations sensibles sans contrôle d'autorisation correspondant ; les références directes à des objets dont l'identifiant provient d'une saisie utilisateur sans validation d'accès ; les modèles de navigation forcée où l'état authentifié est vérifié mais pas la propriété de l'objet.

Java

// Vulnerable: no ownership check -- any authenticated user can access any order
@GetMapping("/orders/{orderId}")
public Order getOrder(@PathVariable Long orderId) {
    return orderRepository.findById(orderId).orElseThrow();
}

// Secure: verify the order belongs to the requesting user
@GetMapping("/orders/{orderId}")
public Order getOrder(@PathVariable Long orderId,
                      @AuthenticationPrincipal UserDetails user) {
    Order order = orderRepository.findById(orderId).orElseThrow();
    if (!order.getOwnerId().equals(user.getUserId())) {
        throw new AccessDeniedException("Order does not belong to requesting user");
    }
    return order;
}

Ce que l'analyse statique ne peut pas détecter : les défaillances du contrôle d'accès à l'exécution, lorsque la logique est correcte mais que les données utilisées pour prendre la décision sont compromises. Dans ce cas, les tests d'analyse dynamique des données (DAST) et les tests d'intrusion sont nécessaires.

A02, Défaillances cryptographiques

La cryptographie faible est détectable de manière fiable par analyse statique car les modèles vulnérables, MD5, SHA-1, DES, mode ECB, clés codées en dur, sont identifiables lexicalement dans le code source.

python

# Vulnerable: MD5 for password hashing (broken algorithm)
import hashlib
password_hash = hashlib.md5(password.encode()).hexdigest()

# Vulnerable: hardcoded encryption key
KEY = b"mysecretkey12345"
cipher = AES.new(KEY, AES.MODE_ECB)  # ECB mode also vulnerable

# Secure: bcrypt for passwords, environment-sourced keys
import bcrypt, os
password_hash = bcrypt.hashpw(password.encode(), bcrypt.gensalt(rounds=12))

# Secure: AES-GCM with environment-sourced key
import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
key = os.environ["ENCRYPTION_KEY"].encode()
aesgcm = AESGCM(key)

Règles d'analyse statique : MD5/SHA-1 pour les données sensibles, mode DES/3DES/RC4/ECB, clés et secrets cryptographiques codés en dur, HTTP au lieu de HTTPS pour la transmission de données sensibles et vérification de certificat désactivée (verify=False dans les requêtes Python, setHostnameVerifier(ALLOW_ALL_HOSTNAME_VERIFIER) en Java).

A03, Injection

L'analyse de contamination interprocédurale (ITA) apporte une valeur ajoutée directe aux injections SQL, aux commandes système, à LDAP, aux attaques XSS et aux injections de modèles. La détection de ces vulnérabilités nécessite le suivi des entrées non fiables depuis leur source jusqu'à une cible dangereuse, en passant par les appels de fonction.

javascript

// Vulnerable: direct string interpolation in SQL (SQL injection)
app.get('/users', async (req, res) => {
    const name = req.query.name;
    const result = await db.query(`SELECT * FROM users WHERE name = '${name}'`);
    res.json(result.rows);
});

// Secure: parameterized query
app.get('/users', async (req, res) => {
    const name = req.query.name;
    const result = await db.query('SELECT * FROM users WHERE name = $1', [name]);
    res.json(result.rows);
});

php

// Vulnerable: unescaped output (XSS)
echo "Welcome, " . $_GET['username'];

// Secure: context-appropriate escaping
echo "Welcome, " . htmlspecialchars($_GET['username'], ENT_QUOTES, 'UTF-8');

tranchant

// Vulnerable: command injection in C#
var process = new Process();
process.StartInfo.FileName = "cmd.exe";
process.StartInfo.Arguments = "/c " + userInput;
process.Start();

// Secure: avoid shell interpretation, validate and whitelist inputs
var allowedCommands = new HashSet<string> { "report", "export" };
if (!allowedCommands.Contains(userInput))
    throw new ArgumentException("Invalid command");

Outils effectuant une analyse de contamination interprocédurale pour l'injection : CodeQL (le plus précis), Semgrep avec mode de contamination, Snyk Code, SonarQube avec règles de sécurité.

A04, Conception non sécurisée

La conception non sécurisée est la catégorie OWASP la plus difficile à analyser statiquement car elle concerne les décisions architecturales plutôt que les modèles de code. L'analyse statique peut révéler les symptômes suivants :

Absence de limitation du débit sur les points de terminaison d'authentification, absence de verrouillage des comptes après des tentatives infructueuses, logique métier ignorant les étapes de validation et fonctions exécutant des opérations privilégiées sans journalisation d'audit : autant de problèmes détectables par une analyse statique qui signale les absences plutôt que les présences.

Certains outils SAST prennent en charge des règles personnalisées permettant d'intégrer les exigences de sécurité de l'organisation : chaque méthode de contrôleur doit appeler une fonction d'autorisation, chaque écriture dans la base de données doit être précédée d'une validation des données, chaque appel d'API externe doit utiliser un délai d'expiration. Ces règles personnalisées transforment les exigences de sécurité en contraintes de code applicables.

A05, Mauvaise configuration de sécurité

Une mauvaise configuration de sécurité dans le code inclut : des fonctionnalités de sécurité désactivées, des en-têtes CORS permissifs, des en-têtes de réponse de sécurité manquants, le mode débogage activé en production et des messages d’erreur verbeux qui exposent les traces de pile.

python

# Vulnerable: Flask debug mode enables interactive debugger in production
app = Flask(__name__)
app.run(debug=True)  # exposes console access if error occurs

# Vulnerable: overly permissive CORS
from flask_cors import CORS
CORS(app, origins="*")  # allows any origin

# Secure: environment-controlled debug, restricted CORS
import os
debug_mode = os.environ.get("FLASK_DEBUG", "false").lower() == "true"
CORS(app, origins=os.environ.get("ALLOWED_ORIGINS", "").split(","))
app.run(debug=debug_mode)

Indicateur des règles d'analyse statique : mode débogage activé True Dans le code source, des origines CORS génériques, des en-têtes de sécurité manquants dans les configurations de réponse HTTP, une vérification de certificat SSL désactivée et des informations d'identification par défaut dans les fichiers de configuration.

A06, Composants vulnérables et obsolètes

Cette catégorie est principalement traitée par l'analyse de la composition logicielle (SCA) plutôt que par l'analyse SAST traditionnelle. Analyses SCA package.json, pom.xml, requirements.txt, et des manifestations similaires contre les bases de données de vulnérabilités (National Vulnerability Database, GitHub Advisory Database).

SAST contribue en identifiant l'utilisation d'API obsolètes, les appels à des fonctions de bibliothèque qui ont été remplacées en raison de failles de sécurité, ou l'utilisation directe de modèles vulnérables que même les bibliothèques à jour ne recommandent plus.

Outils spécifiques pour A06 : npm audit, pip-audit, snyk test, OWASP Dependency-Check, GitHub Dependabot et Mend (anciennement WhiteSource).

A07, Échecs d'identification et d'authentification

L'analyse statique révèle les anti-modèles d'authentification au niveau du code : mots de passe codés en dur, validation de mots de passe faible, jetons de session générés avec un aléatoire non cryptographique, absence d'invalidation de session lors de la déconnexion et implémentations JWT qui acceptent les none algorithme.

javascript

// Vulnerable: JWT accepting 'none' algorithm -- allows signature bypass
const decoded = jwt.verify(token, secret, { algorithms: ['HS256', 'none'] });

// Vulnerable: hardcoded admin credentials
if (username === 'admin' && password === 'admin123') {
    grantAccess();
}

// Secure: algorithm whitelist, no hardcoded credentials
const decoded = jwt.verify(token, process.env.JWT_SECRET, {
    algorithms: ['HS256']  // explicit allowlist only
});

tranchant

// Vulnerable: weak random for session token generation in C#
var sessionToken = new Random().Next().ToString();

// Secure: cryptographically secure random
using var rng = RandomNumberGenerator.Create();
var bytes = new byte[32];
rng.GetBytes(bytes);
var sessionToken = Convert.ToBase64String(bytes);

A08, Défaillances d'intégrité des logiciels et des données

Cette catégorie concerne la désérialisation non sécurisée et les mises à jour logicielles non vérifiées. L'analyse statique détecte : Java ObjectInputStream désérialisation de données provenant de sources non fiables, Python pickle.loads() sur des données externes, PHP unserialize() avec des entrées contrôlées par l'utilisateur et des analyseurs YAML utilisant des chargeurs non sécurisés.

python

# Vulnerable: pickle deserialization of untrusted data
import pickle
data = pickle.loads(request.data)  # arbitrary code execution risk

# Vulnerable: unsafe YAML loader
import yaml
config = yaml.load(user_input)  # yaml.load without Loader is unsafe

# Secure: safe alternatives
import json
data = json.loads(request.data)  # JSON cannot execute code

import yaml
config = yaml.safe_load(user_input)  # safe_load disables arbitrary object creation

A09, Journalisation et surveillance des défaillances de sécurité

Les défaillances de journalisation sont détectables par analyse statique sous forme de schémas absents : opérations sensibles, événements d’authentification, décisions de contrôle d’accès, modifications de données, qui se produisent sans instructions de journalisation correspondantes. Les règles d’analyse statique peuvent exiger que certains appels de fonction soient toujours concomitants aux appels au journal d’audit.

Ce que l'analyse statique signale : la journalisation des mots de passe ou des jetons (la journalisation de données sensibles constitue également une vulnérabilité), les gestionnaires d'exceptions qui ignorent silencieusement les erreurs sans les consigner, et les blocs catch qui enregistrent le message d'exception brut (qui peut contenir des données sensibles).

Java

// Vulnerable: swallowed exception, no logging
try {
    authenticateUser(username, password);
} catch (Exception e) {
    // silent failure -- no log, no audit trail
}

// Vulnerable: logging sensitive data
log.info("User logged in with password: " + password);

// Secure: log the event, not the credential
try {
    authenticateUser(username, password);
    auditLog.info("Authentication success for user: {}", username);
} catch (AuthenticationException e) {
    auditLog.warn("Authentication failure for user: {}", username);
    throw e;  // do not swallow
}

A10, Falsification de requête côté serveur (SSRF)

L'attaque SSRF constitue un cas d'école pour l'analyse de contamination interprocédurale. Cette vulnérabilité nécessite le suivi des entrées utilisateur jusqu'à la requête HTTP, souvent via plusieurs appels de fonction. Un outil analysant uniquement les fonctions individuelles ne peut détecter une attaque SSRF lorsque la construction de l'URL et l'appel HTTP sont effectués dans des fonctions différentes.

python

# Vulnerable: user-controlled URL in HTTP request (SSRF)
import requests

def fetch_resource(url):
    return requests.get(url).content  # no validation

def api_endpoint(request):
    target = request.json().get("url")    # attacker controls this
    return fetch_resource(target)          # SSRF across function boundary

# Secure: allowlist validation before making the request
from urllib.parse import urlparse

ALLOWED_HOSTS = {"api.internal.example.com", "cdn.example.com"}

def fetch_resource(url: str) -> bytes:
    parsed = urlparse(url)
    if parsed.hostname not in ALLOWED_HOSTS:
        raise ValueError(f"URL host not allowed: {parsed.hostname}")
    return requests.get(url, timeout=5).content

Outils d'analyse statique de code pour la sécurité OWASP

Le tableau ci-dessous associe les principaux outils SAST aux catégories OWASP qu'ils traitent le plus efficacement :

Outil	Langues principales	Points forts d'OWASP	Approche
CodeQL	Java, JS/TS, Python, C/C++, Go, Ruby	Injection A03, SSRF A10 (tache profonde)	Analyse sémantique interprocédurale
SemgrepName	Plus de 30 langues	A03, A02, A07 (mode basé sur un motif + contamination)	Correspondance des motifs + légère coloration
Code Snyk	Java, JS/TS, Python, C#	A03, A07, A08	Analyse de contamination basée sur l'apprentissage automatique
SonarQube	Plus de 30 langues	A02, A03, A05, A07, A09	Flux de données basé sur des règles
Checkmarx	Plus de 30 langues	Couverture complète de l'OWASP	contamination interprocédurale
Véracode	Java, .NET, JS, PHP	Couverture complète de l'OWASP	Bytecode + analyse de contamination
OWASP ZAP	Indépendant de la langue	A01, A05, A07 (durée d'exécution)	DAST, tests dynamiques
SMART TS XL	COBOL, JCL, Java, Python, RPG, SQL	Contamination interlinguistique, risque de dépendance	structurel interlingue + contamination

Comment SMART TS XL Amélioration de la sécurité des bases de code d'entreprise

Les programmes de sécurité des entreprises sont confrontés à un défi que les outils SAST monolangages ne peuvent relever : la surface d’attaque s’étend sur plusieurs langages. Une application web peut accepter des entrées utilisateur en JavaScript, les traiter en Java, puis les transmettre via une file d’attente de messages à un programme COBOL qui exécute des requêtes SQL sur une base de données DB2. La vulnérabilité d’injection existe à la frontière de quatre langages. Aucun analyseur SAST monolangage ne permet de visualiser l’intégralité du chemin d’attaque.

SMART TS XL's analyse de code statique couvre simultanément tous les langages de cette chaîne. Lorsque des données non fiables transitent d'un gestionnaire d'API JavaScript à un service Java, puis à un programme COBOL qui construit une requête SQL dynamique, SMART TS XL trace ce chemin à travers l'ensemble du graphe d'appels inter-langages, le même suivi de contamination interprocédural que CodeQL applique en Java, appliqué à Java, COBOL et SQL ensemble.

La fonctionnalité de cartographie des dépendances applicatives offre une vue pertinente en matière de sécurité : elle permet de déterminer quels composants du système interagissent avec des entrées externes, lesquels accèdent à des opérations privilégiées et quelle est la surface d’attaque complète du système. Cette vision architecturale de la sécurité est essentielle à la modélisation des menaces ; or, il est impossible de modéliser les menaces contre un système dont on ignore la structure.

La fonctionnalité d'analyse d'impact est essentielle aux programmes de correction de sécurité : lorsqu'une vulnérabilité est détectée dans un composant, l'analyse d'impact identifie tous les autres composants qui en dépendent, permettant ainsi de définir précisément le périmètre de la correction avant toute modification du code. Pour les vastes bases de code existantes où un programme COBOL présentant une faille de sécurité est intégré à des centaines d'autres programmes, connaître l'étendue complète de la correction avant de commencer fait toute la différence entre une solution maîtrisée et un incident en cascade.

Pour les organisations gérant modernisation de l'héritage Pour les programmes, l'analyse de sécurité du code source existant est une condition préalable, et non une simple formalité. Migrer des programmes COBOL vulnérables vers Java engendre des programmes Java vulnérables. SMART TS XLL'analyse de sécurité de [Nom de l'entreprise] garantit que les vulnérabilités sont identifiées et corrigées dans le cadre du processus de modernisation, et non découvertes dans le système migré.

Intégration de SAST dans le cycle de vie du développement

L'analyse de sécurité statique est la plus efficace lorsqu'elle est exécutée au moment de la décision, c'est-à-dire lors de l'écriture et de la révision du code, et non après son déploiement.

Dans l'IDE : SonarLint, les extensions IDE de Snyk et l'extension CodeQL pour VS Code détectent les failles directement dans le code pendant que les développeurs écrivent. Corriger une injection SQL signalée dès qu'un développeur saisit le motif vulnérable ne prend que quelques secondes.

Dans les demandes de fusion : l’analyse statique de code (SAST) intégrée à GitHub Actions, GitLab CI ou Jenkins s’exécute à chaque demande et publie les résultats sous forme de commentaires de revue de code. Le développeur voit ainsi le résultat dans son contexte, à côté du code qui l’a provoqué.

En tant que contrôle qualité : le modèle de contrôle qualité de SonarQube bloque les fusions dès l’apparition de nouvelles failles de sécurité critiques. La sécurité devient ainsi une exigence structurelle du processus de fusion et non une étape de vérification facultative.

De manière planifiée : l’analyse interprocédurale approfondie, CodeQL, Checkmarx, les ensembles de règles Semgrep complets, est généralement trop lente pour une exécution par commit, mais s’exécute chaque nuit ou chaque semaine sur la branche principale, trouvant des vulnérabilités qui nécessitent une analyse complète du graphe d’appels pour être détectées.

L'approche par couches, les règles rapides basées sur des modèles dans l'IDE et sur les commits, l'analyse approfondie de la contamination sur les demandes d'extraction et les analyses nocturnes, offrent à la fois l'immédiateté dont les développeurs ont besoin et la rigueur requise par les programmes de sécurité.