La famille Codage sûr traite le moment où la sécurité se joue vraiment : l'écriture du code. La conception a posé les exigences ; encore faut-il que la ligne effectivement tapée ne réintroduise pas la faille qu'on cherchait à éviter. Cette famille codifie les réflexes qui font la différence entre un code robuste et un code vulnérable, et elle les rend vérifiables plutôt que laissés à la mémoire de chacun.
Son fil directeur : transformer les bonnes pratiques en règles explicites, outillées et contrôlées. Règles de codage documentées, zéro secret en clair, fonctions sûres imposées, linting de sécurité, et au plus haut niveau revue de code orientée sécurité sur les composants sensibles. L'objectif n'est pas de brider les développeurs, mais de leur donner un chemin sûr par défaut.
Concrètement, ces exigences parent : l'injection SQL née d'une requête concaténée, le secret en clair dans le code, les classes de failles (XSS, désérialisation) répétées faute de règles, et la faille de logique métier que seul un humain repère. Cinq exigences, des fondamentales (R1) aux souveraines (R3).
Les vulnérabilités classiques (injection, désérialisation) viennent de pratiques de code non maîtrisées.
Les pièges à éviter
Section intitulée « Les pièges à éviter »Les erreurs les plus fréquentes sur ce périmètre :
Exigences
Section intitulée « Exigences »règles de codage sûr documentées (validation des entrées, encodage des sorties, gestion des erreurs).#
Sans règles explicites, chaque développeur réinvente la validation des entrées et l'encodage des sorties, avec des trous. Des règles de codage sûr documentées (validation, encodage, gestion d'erreurs) donnent une référence commune qui prévient les failles les plus fréquentes (injection, XSS) avant même la revue.
- Preuve attendue
- Guide de codage sûr ; adoption vérifiée en revue.
Correspondances & menaces parées 3 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. 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.
aucun secret en clair dans le code, détecté en pré-commit et en CI.#
Un secret en clair dans le code part dans le dépôt et tous ses clones, et survit à l'historique. Le détecter en pré-commit et en CI l'arrête avant la poussée ou alerte immédiatement : c'est la fuite la plus banale, et la plus systématiquement exploitée par les scanners d'attaquants.
- Preuve attendue
- Configuration de détection de secrets ; historique nettoyé.
- Outillage
- Semgrep CodeQL Gitleaks
Correspondances & menaces parées 2 standards · 1 menace
Une clé, un jeton ou un mot de passe est commité dans le code et exposé à quiconque accède au dépôt ou à l'artefact. La détection en pré-commit et en CI est la parade OWASP CICD-SEC-6 OWASP ASVS.
usage de fonctions et requêtes sûres (requêtes paramétrées, anti-patterns proscrits).#
L'injection SQL reste en tête des risques applicatifs, et vient presque toujours d'une requête concaténée. Imposer des requêtes paramétrées et proscrire les anti-patterns connus supprime la classe entière de failles à la racine, plutôt que de filtrer des entrées hostiles au cas par cas.
- Preuve attendue
- Règles d'analyse interdisant les fonctions dangereuses.
- Outillage
- Semgrep CodeQL Gitleaks
Correspondances & menaces parées 3 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.
linting de sécurité avec règles adaptées au contexte applicatif.#
Un linting générique noie les vrais risques sous le bruit et ignore le contexte. Des règles de linting de sécurité adaptées au langage et au cadre applicatif remontent les motifs réellement dangereux du projet, gardant le signal utile et l'adoption par les développeurs.
- Preuve attendue
- Configuration de linting de sécurité dans le dépôt.
- Outillage
- Semgrep CodeQL Gitleaks
Correspondances & menaces parées 2 standards · 1 menace
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.
revue de code orientée sécurité obligatoire sur les composants sensibles.#
L'outillage automatique manque les failles de logique métier : seul un humain voit qu'un contrôle d'autorisation est contournable. Une revue de code orientée sécurité obligatoire sur les composants sensibles ajoute ce regard là où l'enjeu le justifie, complétant SAST et linting sans les remplacer.
- Preuve attendue
- Politique de revue ; trace de revue sécurité sur composants sensibles.
- Outillage
- Semgrep CodeQL Gitleaks
Correspondances & menaces parées 2 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.