Le domaine Sécurité applicative (APP) traite ce que tous les autres domaines finissent par protéger : le code applicatif lui-même. On peut durcir le pipeline, signer les artefacts, isoler la production ; si le code embarque une injection ou un contrôle d'accès défaillant, toute cette chaîne se contente de livrer proprement une application vulnérable. APP s'attaque donc à la source de la majorité des failles réellement exploitées.
Le domaine couvre trois moments du cycle : avant d'écrire le code (exigences et modélisation des menaces), pendant (pratiques de codage sûr), et à chaque build (tests automatisés SAST, DAST, SCA, IAST). Il se décline en trois familles, précédées de cinq exigences générales qui posent le socle commun, soit 19 exigences SOCLE au total. C'est l'un des domaines les plus essentiels du référentiel : presque toutes ses exigences fondamentales sont marquées comme telles.
Concrètement, les exigences de ce domaine parent : la faille de code (injection, XSS) partie en production, la dépendance vulnérable livrée par l'application, la faille de conception coûteuse à rattraper faute de modèle de menace, et le défaut d'exécution invisible au code source sans test dynamique. Elles vont des fondamentales (R1) aux souveraines (R3).
Le code applicatif porte la majorité des vulnérabilités exploitées ; sans sécurité dès la conception et tests AST, le reste de la chaîne protège un code faillible.
Pourquoi le code concentre le risque
Section intitulée « Pourquoi le code concentre le risque »Les grands incidents applicatifs des dernières années partagent un point commun : la faille était dans le code ou ses dépendances, pas dans l'infrastructure. Une injection (OWASP Top 10, A03), un contrôle d'accès cassé (A01), une désérialisation non maîtrisée : ces classes reviennent année après année parce qu'elles naissent au moment où l'on écrit la logique métier. Aucun pare-feu ne les arrête, car la requête malveillante ressemble à une requête légitime.
C'est pourquoi SOCLE place la sécurité applicative au plus tôt et au plus près du code. L'idée directrice est connue mais rarement appliquée : plus une faille est détectée tard, plus elle coûte cher. Une exigence oubliée à la conception devient un correctif d'urgence en production, parfois un incident public. Le domaine APP organise donc une défense en profondeur sur le code, du cahier des charges jusqu'au test avant mise en service.
La sécurité commence à la conception
Section intitulée « La sécurité commence à la conception »La première exigence générale (SOCLE-APP-GEN-1, essentielle) demande des
exigences de sécurité définies et tracées dès la conception. Concrètement, avant
d'écrire une fonctionnalité sensible (authentification, paiement, données
personnelles), l'équipe formule ce que la sécurité attend : quelles données
protéger, quels contrôles d'accès, quelles validations. Ces exigences sont tracées
dans le backlog, au même titre que les besoins fonctionnels.
Sans cette étape, la sécurité reste implicite, donc absente. On code d'abord, on
patche ensuite. La modélisation des menaces (SOCLE-APP-GEN-4) prolonge cette
logique : pour les composants sensibles, on identifie comment un attaquant s'y
prendrait avant de coder. C'est le seul moyen de détecter les failles de
logique métier, celles qu'aucun scanner ne voit parce qu'elles relèvent de la
conception, pas de la syntaxe.
Analyser et tester à chaque build
Section intitulée « Analyser et tester à chaque build »Trois exigences générales outillent le pipeline. Le SAST (SOCLE-APP-GEN-2),
analyse statique du code source, s'exécute à chaque build et détecte les motifs
dangereux (injection, fonctions risquées) directement dans le code. Le SCA
(SOCLE-APP-GEN-3), analyse de composition, inspecte les dépendances et bloque
sur les vulnérabilités connues au-delà d'un seuil défini : c'est la parade aux
Log4Shell et autres CVE de bibliothèques. Le DAST (SOCLE-APP-GEN-5) teste
l'application exposée, en boîte noire, avant la mise en production.
Ces trois techniques sont complémentaires, pas interchangeables. Le SAST voit le code mais pas le comportement réel ; le DAST voit l'application qui tourne mais pas le code ; le SCA couvre l'angle mort des composants tiers, qui forment souvent l'essentiel d'une application moderne. SOCLE attend que les trois soient présentes et bloquantes selon le niveau de criticité, avec des rapports datés comme preuve.
Comment lire ce domaine
Section intitulée « Comment lire ce domaine »Les cinq exigences générales se déclinent ensuite en trois familles qui suivent le cycle de vie du code. Conception & modélisation des menaces pose les bases en amont : référentiel ASVS, modèles de menace, revue d'architecture. Codage sûr couvre l'écriture : règles documentées, zéro secret, fonctions sûres, revue de code. Tests de sécurité applicative (AST) outille la vérification continue : SAST, DAST, SCA, IAST, avec mesure de couverture.
Le lecteur pressé peut retenir une progression simple : concevoir sûr, puis coder sûr, puis prouver par les tests. Chaque famille détaille ses exigences par niveau (R1 à R3) et les menaces qu'elle neutralise.
Ce domaine ne vit pas isolé. Il s'appuie sur la gestion des vulnérabilités pour traiter les findings que les tests produisent, et sur la culture pour que les équipes produit portent ces exigences au quotidien plutôt que de les subir. APP fournit les contrôles techniques ; ces deux domaines fournissent le carburant humain et organisationnel qui les rend durables. Un SAST bloquant sans personne pour trier ses alertes finit désactivé, et une revue de sécurité sans développeurs formés tourne à vide.
Les pièges à éviter
Section intitulée « Les pièges à éviter »Les erreurs les plus fréquentes sur ce périmètre :
Exigences générales
Section intitulée « Exigences générales »exigences de sécurité applicative définies et tracées dès la conception.#
Une sécurité ajoutée à la fin se heurte à des choix d'architecture déjà figés et coûte cher à rattraper. Définir et tracer les exigences de sécurité dès la conception les intègre quand elles sont encore bon marché, et donne un référentiel vérifiable contre lequel mesurer le produit livré.
- Preuve attendue
- Liste d'exigences de sécurité par fonctionnalité ; trace en backlog.
- Outillage
- Semgrep OSV-Scanner
Correspondances & menaces parées 4 standards · 2 menaces
Une faille de conception ou de logique métier (contrôles manquants, hypothèses erronées) passe inaperçue faute de modélisation des menaces et de revue de sécurité. Aucun scanner ne la détecte : elle relève de la conception (Microsoft SDL, OWASP SAMM) Microsoft SDL OWASP SAMM OWASP ASVS. Un contrôle d'accès incomplet ou contournable laisse un utilisateur accéder à des données ou actions non autorisées (élévation horizontale ou verticale). C'est la première catégorie du Top 10 OWASP 2025 (A01) OWASP Top 10 2025 (A01) OWASP ASVS.
analyse statique (SAST) intégrée au pipeline et exécutée à chaque build.#
Une vulnérabilité de code non détectée part en production et y reste exploitable. Le SAST intégré et exécuté à chaque build repère les motifs dangereux (injection, désérialisation) au plus tôt, transformant une faille potentiellement publique en simple correction de revue, avant qu'elle n'atteigne les utilisateurs.
- Preuve attendue
- Configuration CI montrant le job SAST ; rapport daté.
- Outillage
- Semgrep OSV-Scanner
Correspondances & menaces parées 4 standards · 2 menaces
Une entrée non validée est interprétée comme du code ou une requête (SQL, commande, XSS, LDAP), permettant l'exécution ou l'accès non autorisé. C'est la classe de failles applicatives la plus répandue (OWASP Top 10 2025, A03) OWASP Top 10 2025 (A03 Injection) OWASP ASVS OWASP CICD-SEC. Des données non fiables sont désérialisées sans contrôle, permettant l'exécution de code ou la manipulation d'objets. Les frameworks qui désérialisent automatiquement amplifient le risque (cas Spring4Shell, GoAnywhere) OWASP Top 10 2025 OWASP ASVS.
analyse de composition (SCA) des dépendances applicatives, avec seuils de blocage.#
Les dépendances applicatives portent l'essentiel du risque connu. La SCA avec seuils de blocage empêche de livrer un composant à vulnérabilité critique : la décision « on corrige avant de sortir » est prise par le pipeline, pas oubliée dans un backlog où la faille reste exploitable.
- Preuve attendue
- Rapport SCA ; politique de seuils ; build bloqué sur vulnérabilité critique.
- Outillage
- Semgrep OSV-Scanner
Correspondances & menaces parées 4 standards · 1 menace
Une bibliothèque applicative porteuse d'une vulnérabilité connue est exploitée faute de détection (SCA) et de mise à jour. L'absence d'inventaire et de correctif transforme une CVE publique en brèche (cas Log4Shell, Equifax) OWASP Top 10 2025 OWASP CICD-SEC-3 OWASP ASVS.
modélisation des menaces des composants sensibles, revue et tenue à jour.#
Sans modèle de menace, on protège au hasard et on découvre les angles morts en production. Modéliser les menaces des composants sensibles, en le tenant à jour, révèle où un attaquant frappera et concentre l'effort là où il compte, plutôt que de saupoudrer des contrôles génériques.
- Preuve attendue
- Modèle de menace daté pour les fonctionnalités sensibles.
- Outillage
- Semgrep OSV-Scanner
Correspondances & menaces parées 4 standards · 1 menace
Une faille de conception ou de logique métier (contrôles manquants, hypothèses erronées) passe inaperçue faute de modélisation des menaces et de revue de sécurité. Aucun scanner ne la détecte : elle relève de la conception (Microsoft SDL, OWASP SAMM) Microsoft SDL OWASP SAMM OWASP ASVS.
tests dynamiques (DAST) des applications exposées avant mise en production.#
Le SAST voit le code mais pas l'application en fonctionnement : configuration, authentification, chaînage réel. Le DAST des surfaces exposées avant mise en production teste l'appli comme un attaquant, de l'extérieur, et attrape des failles d'exécution qu'aucune analyse statique ne révèle.
- Preuve attendue
- Rapport DAST avant release ; suivi des findings.
- Outillage
- Semgrep OSV-Scanner
Correspondances & menaces parées 4 standards · 1 menace
Une vulnérabilité exploitable atteint la production parce qu'aucun test dynamique (DAST / IAST) ne l'a détectée avant la mise en service. Le test des surfaces exposées avant release est la parade (OWASP DSOMM) OWASP DSOMM OWASP ASVS.