Glossaire DevSecOps

Intégration de la sécurité dans l'ensemble du cycle DevOps, de la conception à la production.

Le DevSecOps fait de la sécurité une responsabilité partagée entre développeurs, ops et sécurité. L'objectif est de détecter et corriger les vulnérabilités au plus tôt (shift left) sans ralentir la livraison.

Analyse dynamique qui teste l'application en exécution, comme un attaquant externe.

Le DAST envoie des requêtes malveillantes vers l'application déployée pour détecter injections, auth cassée, misconfig. Complémentaire du SAST car il teste la réalité d'exécution.

Analyse des fichiers Terraform, CloudFormation, Kubernetes pour détecter des configurations dangereuses.

L'IaC scanning applique la logique du SAST à l'infrastructure : chiffrement désactivé, ports ouverts, IAM trop permissif, absence de logs. Corriger dans le code plutôt qu'en runtime réduit la dette.

Analyse hybride qui instrumente l'application à l'exécution pour détecter des vulnérabilités avec contexte.

L'IAST combine les forces du SAST et du DAST en instrumentant l'app pendant les tests. Moins de faux positifs mais nécessite un runtime dédié.

Protection embarquée dans l'application en production qui bloque les attaques en temps réel.

Le RASP est intégré à l'application et peut détecter / bloquer des exploits (RCE, SQLi…) au moment de leur exécution. Contrairement au WAF, il a le contexte applicatif.

Analyse statique du code source pour détecter des vulnérabilités sans exécuter l'application.

Le SAST inspecte le code source (ou le bytecode) à la recherche de patterns vulnérables : injections, XSS, deserialization, cryptographie faible. Rapide en CI, mais génère des faux positifs qu'il faut trier.

Analyse des dépendances open-source pour détecter vulnérabilités connues et problèmes de licence.

Le SCA compare les dépendances de votre projet (npm, Maven, pip…) à des bases comme CVE/GHSA. Indispensable quand 80 à 90 % du code d'une app moderne est open source.

Détection de secrets (API keys, tokens, credentials) committés dans le code.

Les secrets committés sont la première cause de compromission cloud. Les outils scannent git (hook pre-commit, CI, historique) et comparent à des patterns ou modèles ML. Doivent être couplés à une rotation automatique.

Étude descriptive comparative des pratiques sécurité réelles d'entreprises matures.

Le BSIMM n'est pas un modèle normatif : c'est un benchmark de ce que font effectivement ~130 entreprises. Utile pour se comparer à des pairs, moins pour construire un programme from scratch.

Framework open-source OWASP pour mesurer la maturité DevSecOps par dimensions.

Le DSOMM structure la maturité en 4 dimensions (Build & Deployment, Culture & Organization, Implementation, Test & Verification) et 4 niveaux. Il est plus opérationnel que le SAMM, plus adapté aux équipes DevOps.

Temps moyen entre la détection d'une vulnérabilité et sa correction en production.

KPI central du DevSecOps. Objectifs usuels : < 7 jours pour les critiques, < 30 pour les hautes. Le MTTR chute quand la priorisation est contextuelle et que la remédiation est intégrée aux workflows dev.

Framework OWASP de maturité sécurité logicielle structuré en 5 fonctions business.

Le SAMM couvre Governance, Design, Implementation, Verification, Operations avec 3 niveaux. Plus stratégique que le DSOMM, adapté aux CISOs qui veulent un programme AppSec complet.

Identifiant unique standardisé attribué à chaque vulnérabilité publique.

Format : CVE-AAAA-NNNNN. Maintenu par MITRE. Chaque CVE est associé à un score CVSS et éventuellement EPSS. Base obligatoire pour la gestion des vulnérabilités.

Système standard de notation de la gravité d'une vulnérabilité de 0 à 10.

Le CVSS mesure l'impact théorique (confidentialité, intégrité, disponibilité) et la facilité d'exploitation. Critique : il ne reflète pas l'exploitabilité réelle — d'où l'importance de le croiser avec l'EPSS et le contexte.

Probabilité qu'une vulnérabilité soit effectivement exploitée dans les 30 prochains jours.

Contrairement au CVSS, l'EPSS est data-driven : basé sur des signaux réels (exploit kits, mentions dark web, scans). Permet de prioriser les ~5 % de CVEs qui comptent vraiment. Maintenu par FIRST.

Directive européenne qui renforce les obligations cybersécurité des entités critiques et importantes.

NIS2 étend le périmètre à ~160 000 entités en Europe, impose gestion des risques, notification d'incidents sous 24/72h, et responsabilité personnelle des dirigeants. Transposée en droit français en 2025.

Inventaire détaillé de tous les composants logiciels d'une application.

Le SBOM liste dépendances, versions, licences et origines. Exigé par la réglementation US (Executive Order 14028) et européenne (Cyber Resilience Act). Formats standards : SPDX, CycloneDX.

Programme de développeurs référents sécurité au sein des équipes produit.

Les security champions sont des devs volontaires qui relaient la culture sécurité dans leur équipe. Modèle indispensable quand le ratio CISO/devs est < 1/100. Besoin de formation continue et de reconnaissance.

Plateforme de consolidation et de priorisation des risques applicatifs cross-outils.

Une ASPM unifie les findings de SAST, DAST, SCA, secrets, IaC dans un référentiel unique, dédoublonne, priorise par contexte business et suit la remédiation. C'est le cockpit de l'AppSec moderne.

Plateforme unifiée de sécurité cloud-native couvrant workloads, configurations et identités.

Le CNAPP combine CSPM, CWPP, CIEM et parfois KSPM pour protéger les applications cloud de bout en bout. Centré runtime/infra là où l'ASPM est centrée sur le code applicatif.

Sécurisation des images Docker et workloads Kubernetes à toutes les étapes.

Couvre le scan d'images (vulns dans les layers), les politiques d'admission (OPA, Kyverno), le runtime (Falco) et le network (mTLS, service mesh). Nécessite une approche multi-outils orchestrée.

Détection et correction des misconfigurations dans les environnements cloud.

Le CSPM surveille en continu les comptes AWS/Azure/GCP pour détecter des configurations dangereuses (buckets publics, IAM trop permissif, chiffrement désactivé) et les corriger automatiquement.

Pare-feu applicatif filtrant les requêtes HTTP pour bloquer les attaques web.

Le WAF applique des règles (OWASP CRS, custom) pour bloquer SQLi, XSS, path traversal. Utile comme rempart mais ne remplace pas un code sûr : les attaquants contournent souvent via des techniques d'évasion.

Déplacer les contrôles sécurité le plus tôt possible dans le cycle de développement.

Shift left = sécurité dans l'IDE, le commit, la PR, la CI — plutôt qu'en pré-prod ou en prod. Réduit drastiquement le coût de correction (x100 entre design et production).

Analyse structurée des menaces sur un système pour identifier les risques et contre-mesures.

Méthodologies : STRIDE (Microsoft), PASTA, LINDDUN. Se fait idéalement en phase de design, avec les devs. Les outils modernes (OWASP Threat Dragon, IriusRisk) permettent de l'automatiser partiellement.