Module 10 Devsecops | DevOps Cyber Ops 🚀

🔐 DevSecOps

Security Shift-Left & Automation

"La sécurité ne peut plus être le douanier tatillon à la toute fin du processus. DevSecOps, c'est injecter la sécurité dès la conception pour qu'elle devienne l'affaire de tous, invisible mais omniprésente."

👮 Analogie : Garde du Corps vs Douanier

Sécurité traditionnelle = Douanier (Contrôle tout à la fin, juste avant de passer en production, créant un énorme goulot d'étranglement).
DevSecOps = Garde du Corps (Accompagne le code tout au long du trajet, vérifie chaque étape en continu pour détecter les menaces immédiatement).

⚠️ Rappel : Le Secret Management

Ne commitez jamais vos mots de passe, clés API ou certificats dans Git (même dans un `.env`). Un commit Git est éternel. Utilisez toujours un orchestrateur de secrets (ex: HashiCorp Vault, AWS Secrets Manager) pour injecter dynamiquement ces informations au runtime de votre application !

📖 DevSecOps : La Sécurité "Shift-Left"

Le DevSecOps est l'intégration de la sécurité tout au long du cycle de vie DevOps, et non plus comme une étape finale avant la prod. L'idée est de "shifter à gauche" (plus tôt dans le pipeline) pour détecter les failles au moment où elles coûtent le moins cher à corriger.

La sécurité n'est plus la responsabilité d'une équipe isolée, mais une responsabilité partagée entre Devs et Ops, automatisée via des outils dans la CI/CD.

💡 Le saviez-vous ? L'attaque SolarWinds (2020)

C'est l'un des plus grands piratages de l'histoire. Les hackers n'ont pas attaqué les serveurs des clients, mais le pipeline de build du logiciel Orion (SolarWinds). Ils ont injecté un malware directement dans le code source officiel.

Cela a prouvé que la sécurité du Pipeline est aussi importante que la sécurité de l'Application elle-même. C'est ce qu'on appelle la Supply Chain Security.

🔄 A. Sécurité dans le Pipeline

📝

Code

Pre-commit hooks

→

🔍

SAST

SonarQube

→

📦

SCA

Snyk

→

🐳

Image Scan

Trivy

→

🚀

DAST

OWASP ZAP

🛠️ B. Outils DevSecOps

📊 SAST vs DAST : Lequel choisir ?

🔍 SAST (Statique)

Cible : Code source, manifests IaC.
Timing : Très tôt (avant le build).
Avantage : Trouve la ligne de code précise à corriger.
Limite : Ne voit pas les problèmes de runtime/config.

🚀 DAST (Dynamique)

Cible : Application en cours d'exécution.
Timing : Tard (Staging/Prod).
Avantage : Trouve les vraies failles exploitables (ex: SQLi).
Limite : Boîte noire, ne sait pas où est le problème dans le code.

📊 Cas d'étude : Equifax - L'oubli à 1.4 milliard de dollars

147M Dossiers personnels volés

2 mois Délai avant détection

$1.4B Coût total du cleanup/amendes

Contexte : En 2017, Equifax subit l'une des plus grosses fuites de données de l'histoire. La cause ? Une vulnérabilité connue dans le framework Apache Struts.

Transformation :

SCA missing : Equifax n'avait pas d'outil d'analyse de dépendances (SCA) pour les prévenir qu'un patch de sécurité était disponible depuis des mois.
Patching manuel : Le processus de mise à jour était lent et manuel, laissant les serveurs exposés.

Résultat : Cette catastrophe a popularisé le terme DevSecOps. Aujourd'hui, un outil comme Snyk ou Dependabot aurait bloqué la CI/CD jusqu'à ce que la version de Struts soit mise à jour.

🔄 À Retenir - DevSecOps Essentials

Shift-Left : Plus tôt vous trouvez une faille, moins elle coûte cher.
Automate Everything : Un audit manuel une fois par an est inutile. Scannez à chaque commit.
Secret Management : Jamais de MDP ou Clés en clair. Utilisez Vault ou équivalent.
Software Bill of Materials (SBOM) : Sachez exactement ce qu'il y a dans vos containers (inventaire des libs).

🔗 C. Supply Chain Security

L'attaque SolarWinds a prouvé qu'un attaquant ne cible plus seulement votre code, mais aussi votre pipeline de build et vos dépendances. La Supply Chain Security consiste à sécuriser TOUT le processus de création du logiciel.

📋 SBOM (Software Bill of Materials)

Un inventaire complet de tous les composants (dépendances, libraries, versions) contenus dans votre application.

Format : CycloneDX, SPDX (standard ISO)
Génération : Syft, Trivy, Grype
Utilité : Détecter rapidement si vous êtes affecté par une CVE (ex: Log4Shell)
Réglementation : Exigé par certains contrats gouvernementaux (USA)

Générer un SBOM

# Avec Syft (Anchore)
syft packages myimage:v1.0 -o cyclonedx-json > sbom.json

# Avec Trivy
trivy image --format cyclonedx myimage:v1.0 > sbom.cdx

# Vérifier si Log4j vulnérable dans l'SBOM
grype sbom:sbom.json | grep log4j

🏅 SLSA Framework (Google)

Supply-chain Levels for Software Artifacts : Un framework de maturité sécurité pour builds reproductibles.

Level 0 : Pas de garantie de provenance
Level 1 : Build pipeline documenté
Level 2 : Build service hébergé (GitHub Actions) avec audit trail
Level 3 : Builds reproductibles bit-for-bit + signatures cryptographiques

🔏 Sigstore & Cosign

Signer cryptographiquement les artefacts (images, binaires) pour prouver leur authenticité.

Cosign : Signe des images OCI (Docker)
Fulcio : Autorité de certification éphémère
Rekor : Ledger public immuable (blockchain-like)
Utilisé par: Kubernetes, GitHub, npm

Signer & vérifier une image

# Signer une image Docker
cosign sign --key cosign.key gcr.io/myapp:v1.0

# Vérifier la signature avant déploiement
cosign verify --key cosign.pub gcr.io/myapp:v1.0

# Policy dans K8s : bloquer images non-signées
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image
spec:
  validationFailureAction: enforce
  rules:
  - name: check-signature
    verifyImages:
    - imageReferences:
      - "gcr.io/myapp:*"
      attestors:
      - entries:
        - keys:
            publicKeys: |-
              -----BEGIN PUBLIC KEY-----
              ...

🔐 D. Secrets Management

🚨 Le problème : Un secret (API key, password, token) commité sur GitHub est scanné par des bots en quelques secondes et exploité. 82% des breaches impliquent des credentials volées.

Solution	Use Case	Chiffrement	Rotation Auto
HashiCorp Vault	Multi-cloud, entreprise	✓ AES-256	✓ Dynamic secrets
AWS Secrets Manager	AWS uniquement	✓ KMS	✓ RDS/Lambda
Sealed Secrets (K8s)	GitOps workflows	✓ Asymétrique	✗ Manuel
SOPS (Mozilla)	Fichiers config chiffrés	✓ GPG/KMS	✗ Manuel
External Secrets Operator	Sync Vault → K8s	✓ Source + K8s	✓ Polling

vault-setup.sh

# Init Vault (dev mode)
vault server -dev

# Créer un secret
vault kv put secret/myapp/db \
  username="dbuser" \
  password="superSecret123"

# Dynamic secret: Créer un user MySQL temporaire
vault read database/creds/readonly
# → génère password valide 1h puis auto-révoqué

sealed-secret.yaml

# Chiffrer un Secret K8s pour le commiter dans Git
kubeseal --format yaml < secret.yaml > sealed-secret.yaml

# Dans sealed-secret.yaml (safe to commit):
apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: myapp-secret
spec:
  encryptedData:
    password: AgB7w8H3ks... # Chiffré

🔄 Best Practice : Secret Rotation Les secrets doivent être rotés régulièrement (30-90 jours). Automatisez cela avec Vault ou External Secrets Operator. Un secret compromis qui ne change jamais = porte ouverte permanente.

🛡️ E. Zero Trust Architecture

Le modèle traditionnel : "Trust but verify" (le réseau interne est sûr).
Zero Trust : "Never trust, always verify" (même à l'intérieur du réseau, tout doit être authentifié/autorisé).

🏰 Périmètre Traditionnel

Défense : Firewall externe fort, réseau interne "sûr".
Accès : VPN → accès total au réseau.
Latéral Movement : Facile une fois inside.
Problème : 1 breach = tout le réseau compromis.

🔒 Zero Trust

Défense : Chaque service/utilisateur est une frontière.
Accès : Identity-based, least privilege par défaut.
Latéral Movement : Impossible sans réauth.
Avantage : Breach confinée à un seul service.

🔑 BeyondCorp (Google)

Implémentation Zero Trust chez Google. Accès basé sur l'identité de l'utilisateur et l'état du device, pas le réseau.

Aucun VPN corporate
Chaque requête = auth + context-aware policy
Device inventory centralisé
Accès granulaire par service, pas par réseau

🕸️ Service Mesh (Istio/Linkerd)

Applique Zero Trust entre microservices K8s via mTLS automatique.

mTLS : Chiffrement service-to-service
Policy : "payment-svc peut appeler order-svc"
Observability : Traces distribuées automatiques
Micro-segmentation : Isolation par namespace

📜 F. Compliance as Code

⚖️ Open Policy Agent (OPA)

Moteur de policy généraliste. Écrivez des règles en Rego (DSL) pour valider des configs K8s, Terraform, API calls.

Bloque pods privileged
Force resource limits CPU/RAM
Vérifie que images viennent d'un registry approuvé
CNCF graduated project

policy.rego (OPA)

package kubernetes.admission

deny[msg] {
  # Bloquer containers tournant en root
  input.request.object.spec.containers[_].securityContext.runAsNonRoot != true
  msg := "Container must not run as root"
}

deny[msg] {
  # Images doivent venir de gcr.io uniquement
  image := input.request.object.spec.containers[_].image
  not startswith(image, "gcr.io/")
  msg := sprintf("Image %v not from approved registry", [image])
}

🔰 Kyverno (K8s native)

Alternative à OPA, policies écrites en YAML (pas de DSL). Plus facile pour les débutants.

Validate : Bloquer ressources non-conformes
Mutate : Auto-ajouter labels/annotations
Generate : Créer NetworkPolicies automatiquement
Verify : Vérifier signatures d'images (Cosign)

🚨 G. Runtime Security

SAST/DAST trouvent les failles AVANT la prod. Mais que se passe-t-il si un attaquant exploite une 0-day inconnue EN PRODUCTION ? C'est là qu'intervient la Runtime Security.

🦅 Falco (CNCF)

Détecteur d'intrusion pour containers. Surveille syscalls au niveau kernel.

Alerte : "Shell spawned in container" → suspect
Alerte : "File sensitive read (/etc/shadow)"
Alerte : "Connexion réseau inattendue"
Règles customisables en YAML

falco-rule.yaml

- rule: Shell in Container
  desc: Detecter un shell dans un container
  condition: >
    container.id != host
    and proc.name = bash
  output: >
    Shell opened in container
    (user=%user.name container=%container.name 
     image=%container.image)
  priority: WARNING

🔒 Pod Security Standards (K8s)

Privileged : Aucune restriction (dangereux)
Baseline : Bloque known privilege escalations
Restricted : Hardening maximal (runAsNonRoot, readOnlyRoot, drop ALL capabilities)

namespace-policy

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted

🌐 Network Policies

Firewall applicatif au niveau Pod. Par défaut, tout Pod peut parler à tout le monde.

Principe : Default deny, whitelist explicite
Exemple : "frontend peut → backend:8080"
Exemple : "Aucun pod ne peut → Internet sauf monitoring"
CNI required : Calico, Cilium, Weave

📊 Cas d'étude : Log4Shell (CVE-2021-44228) - La panique mondiale

10/10 CVSS Score (critique max)

72h Pour patcher 80% des systèmes

Millions Serveurs affectés mondialement

Contexte : En décembre 2021, une RCE (Remote Code Execution) est découverte dans Log4j 2, la bibliothèque Java de logging la plus utilisée au monde. Un simple string dans les logs = code arbitraire exécuté.

Impact DevSecOps :

SBOM critique : Les entreprises avec SBOM ont pu identifier en 10 minutes quelles apps étaient affectées. Les autres ont cherché pendant des semaines.
SCA en CI/CD : Snyk/Dependabot ont bloqué automatiquement les builds tant que Log4j n'était pas patché.
Signature d'images : Certaines entreprises ont temporairement bloqué le déploiement d'images non-vérifiées.

Leçon : Sans DevSecOps automation, cette crise aurait duré des mois. Les entreprises matures ont patché en 48-72h grâce à des pipelines automatisés et des SBOM à jour.

📊 Cas d'étude : CircleCI Breach (2023) - Le vol de secrets à grande échelle

1.6M Secrets potentiellement exposés

36K Organisations utilisatrices

30 jours Durée de l'infiltration

Contexte : Un attaquant a compromis un laptop d'employé CircleCI via malware, obtenant accès à la session de production et volant des secrets stockés (env vars, SSH keys, API tokens).

Lessons learned :

Ne jamais stocker secrets en clair : Même dans un "CI/CD sécurisé". Utilisez Vault avec injection runtime.
Rotation obligatoire : Secrets doivent expirer (TTL) et être rotés régulièrement.
Least Privilege : Limitez les permissions des secrets (ex: un token GitHub ne devrait pas avoir accès à tout l'org).

Résultat : CircleCI a demandé à TOUTES ses organisations de roter leurs secrets. Un rappel brutal que la sécurité des secrets est critique.

🔄 À Retenir - DevSecOps Essentials

Shift-Left : Plus tôt vous trouvez une faille, moins elle coûte cher.
Automate Everything : Un audit manuel une fois par an est inutile. Scannez à chaque commit.
Secret Management : Jamais de MDP ou Clés en clair. Utilisez Vault ou équivalent.
Software Bill of Materials (SBOM) : Sachez exactement ce qu'il y a dans vos containers (inventaire des libs).
Supply Chain Security : Signez vos artefacts (Cosign), suivez SLSA, générez des SBOMs.
Zero Trust : Ne faites confiance à rien, vérifiez tout (mTLS, identity-based access).
Compliance as Code : Policies OPA/Kyverno pour bloquer configs dangereuses automatiquement.
Runtime Security : Falco + Pod Security Standards pour détecter intrusions en production.

🛡️ Container Security

Distroless : Images minimales (pas de shell)
Non-root : USER 1000 dans Dockerfile
Read-only : readOnlyRootFilesystem: true
Scan Base Images : Trivy dans CI

⚠️ OWASP Top 10 (2024)

Broken Access Control
Cryptographic Failures
Injection (SQL, XSS)
Insecure Design
Security Misconfiguration

Les 5 autres: SSRF, Vulnerable Components, Auth Failures, Logging Failures, Security Testing

⚡ Secrets Management
Un AWS_KEY commité sur GitHub est piraté en 3 secondes. Utilisez un coffre-fort (Vault, SealedSecrets) injecté au runtime.

🛑 Troubleshooting : "J'ai commité un secret par erreur sur Git !"

Symptôme : Vous avez pushé un fichier .env ou un mot de passe en dur sur un dépôt distant (GitHub/GitLab).
Erreur courante : Faire un nouveau commit pour supprimer la ligne. Le secret reste visible dans l'historique (les anciens commits) !
Remède Immédiat (Urgence absolue) : 1. RÉVOQUEZ le secret immédiatement auprès du fournisseur (AWS, API, BDD). C'est la seule vraie sécurité.
2. Si vous devez nettoyer l'historique Git (pour la propreté), utilisez des outils comme BFG Repo-Cleaner ou git filter-repo, puis force pushez. (Mais considérez le secret comme déjà compromis de toute façon).

← Accueil