DevSecOps : Ce que vous faites détruit votre sécurité

Tutoriel DO / DON’T — Cybersécurité & DevSecOps

[HOOK]

Vous avez un pipeline CI/CD. Vous avez des scanners. Vous avez une politique de sécurité.

Pourtant, vous serez compromis. Pas parce que vous manquez d’outils — mais parce que vous prenez les mauvaises décisions au mauvais moment.

La sécurité ne se joue pas dans les audits. Elle se joue dans les choix quotidiens de développement, d’architecture et d’opération. Chaque décision a un coût. Ce tutoriel vous force à les voir.

—

[CONCEPT 1] — Shift-Left : intégrer la sécurité dans le code, pas après

La tension

Sécuriser en fin de cycle semble plus simple. En pratique, c’est cinq fois plus cher à corriger et rarement fait.

—

✅ DO — Intégrer les contrôles de sécurité dans la boucle du développeur

# .github/workflows/security.yml
jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: SAST Scan
        uses: returntocorp/semgrep-action@v1
      - name: Dependency Check
        run: pip-audit --requirement requirements.txt
      - name: Secret Scan
        uses: trufflesecurity/trufflehog@main

# .github/workflows/security.yml
jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: SAST Scan
        uses: returntocorp/semgrep-action@v1
      - name: Dependency Check
        run: pip-audit --requirement requirements.txt
      - name: Secret Scan
        uses: trufflesecurity/trufflehog@main

❌ DON’T — Réserver les scans de sécurité à la phase de release ou aux audits annuels

# Anti-pattern classique
# → scan manuel déclenché 2 jours avant la mise en production
# → 47 vulnérabilités critiques découvertes
# → rollback ou livraison sous contrainte

EXEMPLE — Google Project Zero a documenté que 70 % des vulnérabilités critiques exploitées en production existaient depuis plus de 6 mois dans le code source, visibles par un scanner statique basique.

IMPACT — Sans shift-left : délai de détection moyen = 197 jours (IBM CODB 2023). Avec shift-left intégré au PR : < 24h.

—

[CONCEPT 2] — Secrets Management : ce qui tue le plus vite

La tension

Mettre une clé API en dur est rapide. La retrouver dans un repo public 6 mois plus tard est catastrophique — et irréversible.

—

✅ DO — Externaliser tous les secrets dans un vault, jamais dans le code ni les variables d’environnement en clair

# Correct : récupération dynamique depuis Vault
import hvac

client = hvac.Client(url='https://vault.internal')
client.auth.aws.iam_login(role="app-prod")
secret = client.secrets.kv.v2.read_secret_version(
    path="app/database",
    mount_point="secret"
)
db_password = secret['data']['data']['password']

❌ DON’T — Stocker des secrets dans le code, les .env versionnés, ou les variables CI/CD en texte clair

# Ce pattern est dans 40 % des repos privés audités
DATABASE_URL=postgres://admin:MonSuperMotDePasse@prod-db:5432/app
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

EXEMPLE — En 2023, Samsung a exposé des clés AWS internes via un repo GitHub public suite à un push accidentel d’un fichier .env. Coût estimé : > 1 M$ en investigation et rotation d’accès.

IMPACT — Un secret exposé sur GitHub est détecté par des bots malveillants en moyenne 24 secondes après le push (GitGuardian State of Secrets Sprawl 2024).

—

[CONCEPT 3] — SBOM & Supply Chain : la vulnérabilité que vous n’avez pas écrite

La tension

Vous contrôlez votre code. Vous ne contrôlez pas vos dépendances. Et c’est là que les attaquants entrent.

✅ DO — Générer et auditer un SBOM à chaque build, bloquer les dépendances à CVE critique

# Génération SBOM (CycloneDX)
syft . -o cyclonedx-json > sbom.json

# Audit des vulnérabilités connues
grype sbom:./sbom.json --fail-on critical

# Politique : bloquer le merge si score CVSS >= 9.0

❌ DON’T — Accepter des dépendances sans audit de provenance ni politique de version minimale

# pyproject.toml sans contrainte de version = bombe à retardement
[dependencies]
requests = "*"
cryptography = "*"
paramiko = "*"

EXEMPLE — L’attaque SolarWinds (2020) a compromis 18 000 organisations via une dépendance de build corrompue. La CISA impose désormais un SBOM pour tout logiciel vendu au gouvernement américain (Executive Order 14028).

IMPACT — 91 % des applications contiennent des dépendances open source avec au moins une vulnérabilité connue (Synopsys OSSRA 2024). Sans politique de SBOM, vous ne savez pas lesquelles.

—

[CONCEPT 4] — Infrastructure as Code : la sécurité doit être déclarative

La tension

Configurer manuellement une règle de firewall est rapide. La reproduire identiquement sur 12 environnements sans erreur est impossible.

✅ DO — Valider la conformité sécurité de l’IaC avant le déploiement, via des outils de policy-as-code

# Checkov — scan Terraform avant apply
checkov -d ./terraform --framework terraform \
  --check CKV_AWS_18,CKV_AWS_20,CKV_AWS_57 \
  --compact --quiet

# OPA / Conftest — politique custom
conftest test terraform/main.tf --policy policies/

❌ DON’T — Déployer de l’IaC non validée et corriger les dérives de configuration manuellement après incident

# Terraform permissif — pattern à haut risque
resource "aws_s3_bucket" "data" {
  bucket = "prod-data-lake"
  # ← pas de chiffrement, pas de versioning, accès public non bloqué
}

EXEMPLE — En 2019, Capital One a subi une fuite de 100 millions de données clients via une mauvaise configuration d’un rôle IAM AWS, déployée via un template CloudFormation non audité. Amende : 80 M$.

IMPACT — Les erreurs de configuration cloud représentent 82 % des violations de données cloud (IBM X-Force 2023). Toutes sont détectables en pré-déploiement.

—

[CONCEPT 5] — DORA & NIS2 : la conformité n’est pas un projet, c’est une posture

La tension

Traiter DORA ou NIS2 comme un audit ponctuel vous expose à deux risques simultanés : la sanction réglementaire et l’incident opérationnel.

—

✅ DO — Opérationnaliser les exigences DORA/NIS2 en contrôles continus mesurables dans vos pipelines

# Exemple : contrôle DORA Article 9 — tests de résilience
controls:
  - id: DORA-ART9-RES
    type: chaos-engineering
    schedule: quarterly
    tool: chaos-mesh
    scope: [payment-service, auth-service]
    success_criteria:
      rto: "< 4h"
      rpo: "< 1h"
    evidence: chaos_report_{{ date }}.pdf

# Exemple : contrôle DORA Article 9 — tests de résilience
controls:
  - id: DORA-ART9-RES
    type: chaos-engineering
    schedule: quarterly
    tool: chaos-mesh
    scope: [payment-service, auth-service]
    success_criteria:
      rto: "< 4h"
      rpo: "< 1h"
    evidence: chaos_report_{{ date }}.pdf

❌ DON’T — Produire de la documentation de conformité déconnectée des pratiques réelles de vos équipes

# Ce que font 70 % des organisations
→ Politique de sécurité rédigée en 2021
→ DPIA mis à jour jamais
→ Tests de reprise d'activité simulés sur papier
→ Audit externe : "conforme"
→ Incident réel : RTO = 72h

# Ce que font 70 % des organisations
→ Politique de sécurité rédigée en 2021
→ DPIA mis à jour jamais
→ Tests de reprise d'activité simulés sur papier
→ Audit externe : "conforme"
→ Incident réel : RTO = 72h

EXEMPLE — Le règlement DORA (applicable depuis janvier 2025) impose aux entités financières de l’UE des tests de pénétration TLPT (Threat-Led Penetration Testing) avec preuve d’exécution. Une politique sur papier ne satisfait pas cette exigence.

IMPACT — NIS2 prévoit des amendes jusqu’à 10 M€ ou 2 % du CA mondial. DORA : responsabilité personnelle des dirigeants en cas de défaillance ICT grave. La conformité doit être prouvable en temps réel, pas reconstituée après coup.

—

[CONCEPT 6] — Zero Trust : ne jamais supposer que le réseau est sûr

La tension

Le périmètre réseau rassure. Il est illusoire. Chaque accès implicitement accordé est une surface d’attaque.

—

✅ DO — Appliquer le principe de moindre privilège à chaque identité, chaque service, chaque requête — avec vérification continue

# Implémentation Zero Trust avec vérification contextuelle
def authorize_request(token: str, resource: str, context: dict) -> bool:
    claims = verify_jwt(token)  # validation systématique
    risk_score = evaluate_risk(
        user_id=claims["sub"],
        device_posture=context["device_health"],
        location=context["ip"],
        time=context["timestamp"]
    )
    policy = load_policy(resource)
    return policy.allows(claims["roles"], risk_score)

# Implémentation Zero Trust avec vérification contextuelle
def authorize_request(token: str, resource: str, context: dict) -> bool:
    claims = verify_jwt(token)  # validation systématique
    risk_score = evaluate_risk(
        user_id=claims["sub"],
        device_posture=context["device_health"],
        location=context["ip"],
        time=context["timestamp"]
    )
    policy = load_policy(resource)
    return policy.allows(claims["roles"], risk_score)

❌ DON’T — Faire confiance au trafic interne par défaut et segmenter uniquement le périmètre externe

# Architecture "castle-and-moat" — compromise totale dès un poste compromis
# → Tout le réseau interne est accessible sans re-authentification
# → Mouvement latéral trivial pour un attaquant
# → Détection moyenne : 207 jours (IBM CODB 2023)

# Architecture "castle-and-moat" — compromise totale dès un poste compromis
# → Tout le réseau interne est accessible sans re-authentification
# → Mouvement latéral trivial pour un attaquant
# → Détection moyenne : 207 jours (IBM CODB 2023)

EXEMPLE — L’attaque NotPetya (2017) a paralysé Maersk en moins de 7 minutes grâce au mouvement latéral non contraint sur un réseau interne plat. Coût : 300 M$. Un modèle Zero Trust avec micro-segmentation aurait contenu la propagation.

IMPACT — Le NIST SP 800-207 (Zero Trust Architecture) est désormais la référence pour les systèmes fédéraux US et recommandé explicitement par ANSSI pour NIS2. Chaque heure de retard à l’adoption = surface d’attaque latérale maintenue.

—

[CONCLUSION]

La sécurité DevSecOps ne se perd pas dans un grand incident. Elle se perd dans six décisions quotidiennes :

Le bon réflexe n’est pas de tout faire. C’est de ne jamais laisser une décision sans politique déclarée, mesurable, et automatisée.

Sécurité = contrainte par défaut. Pas exception à la demande.

Sources : IBM Cost of a Data Breach 2023 — GitGuardian State of Secrets Sprawl 2024 — Synopsys OSSRA 2024 — NIST SP 800-207 — ANSSI Guide DevSecOps — Règlement DORA (UE) 2022/2554 — Directive NIS2 (UE) 2022/2555