CISSP Domaine 8 — Software Development Security : DevSecOps et chaîne logicielle pas-à-pas

Article principal de la série : Décrocher la certification CISSP 2026. Ce tutoriel approfondit le domaine 8 du CBK 2024 — 10 % de l’examen. Il porte sur l’intégration de la sécurité dans le cycle de vie logiciel : SDLC, modèles de maturité (BSIMM, OWASP SAMM), DevSecOps, sécurité des API et des conteneurs, chaîne d’approvisionnement logicielle, sécurité des bases de données.

Prérequis

• Domaines 1 à 7 maîtrisés (notamment SAST/DAST du domaine 6)
• Expérience d’un pipeline CI/CD ou d’un projet de développement
• Temps estimé : 15 à 20 heures sur deux semaines

Étape 1 — Distinguer les modèles SDLC

Cinq modèles examinables avec leurs caractéristiques sécurité.

Le piège classique demande quel modèle prévoit la sécurité dès la phase d’exigences. La réponse moderne est DevSecOps, mais le Waterfall avec une phase d’exigences sécurité formalisée (NIST SP 800-160 v1) répond aussi à la question. Si la question demande la réactivité maximale aux vulnérabilités, DevSecOps est la bonne réponse.

Étape 2 — Modèles de maturité applicative

Deux modèles à connaître. BSIMM (Building Security In Maturity Model, désormais publié par Black Duck après cession de la division Synopsys SIG en 2024) est descriptif : il décrit ce que font les organisations matures à travers près de 130 activités regroupées en 12 pratiques et 4 domaines (Gouvernance, Intelligence, SSDL Touchpoints, Déploiement). La dernière édition BSIMM15 (publiée le 14 janvier 2025) couvre 121 organisations et sert de benchmark sectoriel.

OWASP SAMM (Software Assurance Maturity Model, version 2.0 publiée en 2020) est prescriptif : il propose 5 fonctions métier (Gouvernance, Conception, Implémentation, Vérification, Opérations), chacune avec 3 pratiques évaluées sur 3 niveaux de maturité. Plus accessible que BSIMM pour les organisations de taille modeste, OWASP SAMM aide à construire une roadmap d’amélioration.

À l’examen, BSIMM = descriptif, comparaison sectorielle ; OWASP SAMM = prescriptif, roadmap d’amélioration. Les deux sont complémentaires.

Étape 3 — Maîtriser l’OWASP Top 10 2021

L’OWASP Top 10 web a été refresh en novembre 2025 sous forme de Release Candidate (RC1), encore en phase de stabilisation au moment de l’examen 2026 — la version 2021 reste la référence stable. Les dix catégories de 2021 à connaître :

1. A01 Broken Access Control
2. A02 Cryptographic Failures
3. A03 Injection (SQL, command, LDAP)
4. A04 Insecure Design
5. A05 Security Misconfiguration
6. A06 Vulnerable and Outdated Components
7. A07 Identification and Authentication Failures
8. A08 Software and Data Integrity Failures
9. A09 Security Logging and Monitoring Failures
10. A10 Server-Side Request Forgery (SSRF)

Trois pièges typiques. Broken Access Control est désormais en tête (au lieu d’Injection historiquement) — c’est l’angle attaque le plus rentable. Insecure Design (A04) est une nouvelle catégorie qui souligne que les failles ne sont pas toutes implémentation : un design défaillant ne se patche pas, il se redessine. A08 couvre les attaques supply chain type SolarWinds et XZ Utils.

Étape 4 — Sécurité des API et OWASP API Security Top 10 2023

Les API REST et GraphQL sont devenues l’angle d’attaque dominant des applications modernes. L’OWASP API Security Top 10 version 2023 actualise la liste de 2019 :

1. API1 Broken Object Level Authorization (BOLA)
2. API2 Broken Authentication
3. API3 Broken Object Property Level Authorization
4. API4 Unrestricted Resource Consumption
5. API5 Broken Function Level Authorization
6. API6 Unrestricted Access to Sensitive Business Flows
7. API7 Server Side Request Forgery
8. API8 Security Misconfiguration
9. API9 Improper Inventory Management
10. API10 Unsafe Consumption of APIs

BOLA reste la première menace : un utilisateur authentifié accède à des objets qui ne lui appartiennent pas par manipulation de l’identifiant dans l’URL. La parade est la vérification systématique de l’autorisation au niveau de chaque ressource, indépendamment de l’authentification globale.

Étape 5 — Pipeline CI/CD sécurisé

Un pipeline DevSecOps moderne en 2026 chaîne plusieurs contrôles automatisés à chaque commit. Pre-commit : linting, secrets scan (gitleaks, TruffleHog), conventional commits. Build : SAST sur le code (Semgrep, SonarQube), SCA sur les dépendances (Snyk, Dependabot, Renovate). Test : tests unitaires et d’intégration avec couverture minimum, IAST si applicable. Package : signature des artefacts (Sigstore Cosign), génération de SBOM (Syft, CycloneDX). Deploy : DAST sur l’environnement de staging (ZAP by Checkmarx, Burp Suite), policy-as-code (OPA Gatekeeper, Kyverno) en admission Kubernetes. Runtime : monitoring (Falco, eBPF), WAF inline, observabilité.

Le concept de shift-left rapproche les contrôles du développeur (IDE, pre-commit, PR review) pour réduire le coût de la correction — une faille trouvée en commit coûte ~10× moins cher qu’une faille trouvée en production. À l’opposé, le shift-right reconnaît qu’on ne peut pas tout trouver en amont et investit aussi dans la détection runtime (RASP, EDR application).

Étape 6 — Sécurité des conteneurs et Kubernetes

La sécurité conteneurs s’organise en quatre couches : image (scan de vulnérabilité avec Trivy/Grype, signature Cosign, base minimale Alpine ou Distroless), runtime conteneur (sandbox gVisor/Kata, capabilities Linux restreintes, read-only filesystem, non-root), orchestration Kubernetes (RBAC strict, NetworkPolicies, Pod Security Standards) et cloud (IAM minimal, secrets externalisés).

Trois pratiques modernes à connaître. Les distroless images de Google réduisent la surface d’attaque en supprimant shell, package manager et utilitaires — un attaquant exploitant la vulnérabilité ne dispose plus d’outils pour pivoter. Les signed images via Cosign et la policy controller (Sigstore Policy Controller, Kyverno) empêchent l’exécution d’images non signées. Les admission controllers Kubernetes (OPA Gatekeeper, Kyverno) appliquent des politiques déclaratives avant l’admission du pod (pas de capability NET_ADMIN, pas de hostNetwork, image issue d’un registre approuvé).

Étape 7 — Chaîne d’approvisionnement logicielle et SLSA

Le framework SLSA (Supply-chain Levels for Software Artifacts) version 1.0 publié en avril 2023 par l’OpenSSF définit quatre niveaux croissants de garanties sur la provenance et l’intégrité des artefacts logiciels. SLSA 1 exige une documentation de provenance ; SLSA 2 ajoute la signature ; SLSA 3 exige une infrastructure de build isolée et auditable ; SLSA 4 ajoute une revue à deux personnes et une reproductibilité du build.

La SBOM (Software Bill of Materials) en SPDX ou CycloneDX accompagne désormais les livraisons aux clients exigeants. La VEX (Vulnerability Exploitability eXchange) complète la SBOM en indiquant si une CVE détectée dans un composant est réellement exploitable dans le contexte du produit — réduit drastiquement le bruit de scan.

Étape 8 — Sécurité des bases de données

Quatre angles à maîtriser. Authentification : pas de comptes partagés ni de mot de passe en clair dans le code applicatif (vault obligatoire), MFA pour les comptes administrateurs DBA. Autorisation : principe du moindre privilège (rôles applicatifs sans GRANT GLOBAL, séparation lecture/écriture, vues sur les colonnes sensibles). Chiffrement : TDE (Transparent Data Encryption) pour at-rest, TLS pour in-transit, Always Encrypted ou client-side encryption pour les colonnes hyper-sensibles (numéros de carte, données médicales). Audit : journalisation des accès aux tables sensibles avec corrélation SIEM, alerte sur volumes anormaux exportés.

Trois attaques à connaître. SQL injection classique reste dominante — la parade est l’usage exclusif de requêtes paramétrées (PreparedStatement Java, parameterized queries Python). NoSQL injection touche MongoDB et autres bases via opérateurs ($where, $regex) — parade par validation stricte des entrées et désactivation des opérateurs serveur. Inference attacks sur les statistiques agrégées d’une base partagée — parade par differential privacy ou suppression des cellules à faible cardinalité.

Étape 9 — Gestion du changement et release management

Le change management discipline les modifications applicatives en production pour éviter les régressions de sécurité. Quatre niveaux à connaître. Le standard change est pré-approuvé, à faible risque, exécuté à la demande (rotation de certificat, ajout d’utilisateur). Le normal change suit le processus complet (CAB, tests, fenêtre planifiée). L’emergency change contourne le processus normal pour répondre à un incident critique, avec validation a posteriori. Le major change demande une analyse d’impact étendue et un plan de rollback formel.

Le feature flag est devenu un outil central. Il permet de déployer du code en production sans l’activer pour les utilisateurs, puis de l’activer progressivement (canary release, ring deployment). Avantage sécurité majeur : possibilité de désactiver instantanément une fonctionnalité défaillante sans rollback de version.

Le blue-green deployment et le canary deployment sont deux stratégies complémentaires. Blue-green bascule 100 % du trafic d’un environnement à l’autre, avec rollback instantané possible. Canary expose la nouvelle version à un sous-ensemble d’utilisateurs (1 %, puis 5 %, puis 25 %, puis 100 %) avec monitoring continu — toute dégradation déclenche le rollback automatique avant impact massif.

Étape 10 — Sécurité des dépôts de code et intégrité du build

Le dépôt de code source est un actif critique sous-protégé dans beaucoup d’organisations. Cinq mesures examinables. Premièrement, MFA obligatoire avec passkeys ou clés FIDO2 sur toutes les organisations GitHub/GitLab/Bitbucket — bannir les SSH keys non-protégées par phrase. Deuxièmement, signing des commits obligatoire avec clé GPG ou SSH signing, vérification automatique en CI. Troisièmement, branch protection sur main/release : reviews obligatoires, status checks verts, signed commits, linear history. Quatrièmement, séparation stricte des droits : pas de force-push sur main, restriction des admins, audit log activé. Cinquièmement, scanning automatique des secrets sur tous les commits avec rejection en pre-receive hook côté serveur.

Pour les artefacts de build, la signature avec Sigstore Cosign et la conservation en registre dédié protégé contre la modification (immutability flag) sont les pratiques modernes. Les images poussées en registre OCI doivent être attestées via in-toto attestations qui décrivent comment et avec quoi elles ont été construites — préalable nécessaire pour atteindre SLSA niveau 3.

Étape 11 — Modélisation des menaces dès la conception

La threat modeling est une démarche structurée d’identification des menaces dès la phase de conception. Trois méthodes examinables. STRIDE (Microsoft) classe les menaces en six catégories : Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege — utile pour les architectures applicatives classiques. PASTA (Process for Attack Simulation and Threat Analysis) est plus orienté risque métier en sept phases. LINDDUN est spécialisée pour les enjeux de vie privée.

La pratique moderne intègre la modélisation dans le processus de conception via des outils comme OWASP Threat Dragon ou Microsoft Threat Modeling Tool. Le livrable est un Data Flow Diagram annoté des menaces identifiées, des contre-mesures planifiées, et des risques résiduels acceptés explicitement par le product owner.

Étape 12 — IDE sécurisé et plugins développeurs

L’environnement de développement local est souvent ignoré. Trois mesures à retenir. Premièrement, plugins SAST intégrés à l’IDE (SonarLint, Snyk Code, Semgrep VS Code) qui détectent les anti-patterns sécurité au moment où le développeur écrit le code, bien avant le commit. Deuxièmement, validation de la signature des plugins eux-mêmes — un plugin compromis sur VS Code ou JetBrains a accès au code source, aux credentials git, aux variables d’environnement. Troisièmement, sandboxing du build local via dev containers reproductibles pour éviter qu’un make malicieux dans une dépendance ne compromette le poste développeur. La pratique mature combine pre-commit hooks, IDE plugins et CI distant pour multiplier les filets de sécurité avant la production.

Erreurs fréquentes

Tutoriels frères

• Retour au guide principal : Décrocher la certification CISSP 2026
• Précédent : Domaine 7 — Security Operations
• Premier de la série : Domaine 1 — Security and Risk Management

Ressources et références

• OWASP Top 10 2021
• OWASP API Security Top 10 2023
• OWASP SAMM 2.0
• BSIMM
• SLSA — Supply-chain Levels for Software Artifacts
• CISA — SBOM
• Kubernetes Pod Security Standards
• Sigstore Cosign — Container Signing

Foire aux questions

DevSecOps est-il une rupture ou une évolution du DevOps ?

Une évolution. DevSecOps reconnaît que le DevOps avait laissé de côté la sécurité par défaut. Il ajoute des contrôles automatisés dans le pipeline et change la culture pour rendre la sécurité responsable de tout le monde, pas seulement d’une équipe dédiée.

OWASP Top 10 ou OWASP API Top 10 en priorité ?

Les deux selon votre stack. Application web monolithique : OWASP Top 10 d’abord. Architecture microservices avec API exposées : OWASP API Top 10 prioritaire. La majorité des organisations modernes ont besoin des deux.

SLSA 4 est-il atteignable en pratique ?

Atteignable mais coûteux. SLSA 3 est l’objectif réaliste de la plupart des organisations matures. SLSA 4 est attendu sur les composants critiques de chaîne d’approvisionnement (compilateurs, librairies cryptographiques) et pour quelques produits gouvernementaux.

SBOM est-il obligatoire en 2026 ?

Aux États-Unis pour les fournisseurs fédéraux (EO 14028) oui. Dans l’UE, la Cyber Resilience Act le rendra obligatoire à compter de décembre 2027 pour tout produit numérique vendu sur le marché. En attendant, c’est une bonne pratique fortement recommandée.