DevSecOps : intégrer la sécurité dès le premier commit

Votre CTO recevait des questions de sécurité d'une manière simple:

1. Développeur commit du code
2. Code arrive en production après tests
3. 6 mois plus tard, on découvre une vulnérabilité
4. Il faut patcher en urgence, peut-être un hot-fix, peut-être un incident

C'est le vieux modèle. Sécurité arrive à la fin (ou pas du tout).

DevSecOps veut dire : sécurité dès le premier commit. Avant même que le code ne soit testé, vous savez s'il y a des vulnérabilités connues. Avant que ça n'arrive en production, vous savez si la configuration est vulnérable.

C'est plus rapide, moins cher, et ça évite les incidents. Mais ça demande une discipline et de l'outillage.

Le vrai coût d'une vulnérabilité trouvée trop tard

Imaginons : une vulnérabilité SQL injection découverte 6 mois après deployment.

Coûts réels :

• Audit de données volées : CHF 50,000-100,000
• Notification clients (GDPR) : CHF 100,000+ en legal
• Reputation damage : difficile à quantifier mais réel
• Patcher en urgence, hotfix, tests expedited : CHF 50,000
• Potential fines GDPR : jusqu'à CHF 10 millions (mais généralement moins)
• Total réaliste : CHF 200,000-500,000 minimum

Découverte au commit ? Développeur fixe en 30 minutes. Coût : 0.

ROI de DevSecOps : 100,000:1 si vous l'utilisez correctement.

Architecture DevSecOps : 4 layers

Layer 1 : Static Application Security Testing (SAST)

Ça veut dire : analyzer le code source AVANT qu'il ne soit compilé.

Outils populaires :

• SonarQube (gratuit ou commercial, bon pour généraliste)
• Semgrep (gratuit, très bon pour custom rules)
• Snyk (commercial, bon pour dépendances)
• GitHub Advanced Security (si vous êtes sur GitHub)

Qu'est-ce qu'elles trouvent :

• SQL injection patterns
• XSS vulnerabilities
• Hardcoded passwords
• Unsafe crypto
• etc.

Implémentation :

# GitHub Actions example
name: SAST Security Scan
on: [pull_request]
jobs:
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: SonarQube Scan
        uses: SonarSource/sonarqube-scan-action@master
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

Quand un développeur ouvre une PR, le scan lance automatiquement. S'il y a des vulnérabilités, la PR est bloquée jusqu'à fix.

Important : Vous devez avoir moins de 10% faux positifs. Sinon les développeurs ignorent simplement les résultats.

Layer 2 : Software Composition Analysis (SCA)

SAST analyse votre code. SCA analyse vos dépendances.

Vous utilisez la version 5.1 de cette library JavaScript qui a une vulnérabilité découverte dans la version 5.0 ? SCA vous le dit.

Outils populaires :

• Snyk (bon, commercial)
• GitHub Dependabot (gratuit si GitHub)
• Whitesource/JFrog (bon)
• Trivy (gratuit, open source)

Implémentation :

# Trivy dépendances
- name: Run Trivy SCA
  run: trivy fs --format json --output sbom.json .

S'il y a une dépendance vulnérable, vous avez deux options :

1. Upgrade la dépendance (prendre la version fixed)
2. Accepter le risque (si fixed version casse quelque chose)

Pro tip : Générez un SBOM (Software Bill of Materials). ça devient régulièrement compulsory pour les contrats gouvernementaux / EU.

Layer 3 : Container Image Scanning

Si vous utilisez Kubernetes (et vous devriez), vos applications tournent dans des images Docker. Ces images contiennent des couches du système d'exploitation + votre code + vos dépendances.

Si la couche OS a une vulnérabilité CVE, vous le savez ?

Outils populaires :

• Trivy (gratuit, très bon)
• Harbor (gratuit, registry avec scanning intégré)
• Snyk (commercial)

Implémentation :

# Trivy container image scan
- name: Scan Docker image
  run: trivy image --format json myrepo.azurecr.io/myapp:${{ github.sha }}

Vous scannez l'image AVANT qu'elle n'arrive en production. Si y'a une critique CVE, la deploy est bloquée.

Best practice : Scannez aussi vos images déjà en production régulièrement. Les CVE changent tous les jours, une image safe aujourd'hui peut être vulnérable demain.

Layer 4 : Policy-as-Code

SAST, SCA, container scanning, c'est bon, mais ça check que pour known vulnérabilités.

Et si vous avez une politique d'entreprise : "pas de secrets en hardcoded", "déploiements seulement en Suisse", "toutes les replicas doivent être >= 2"?

Policy-as-Code vérifie ça automatiquement.

Tools populaires :

• OPA/Conftest (gratuit, powerful)
• Kyverno (gratuit, pour Kubernetes)
• HashiCorp Sentinel (commercial)

Exemple : Kyverno policy

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-security-context
spec:
  validationFailureAction: enforce
  rules:
  - name: check-security-context
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "Security context required"
      pattern:
        spec:
          containers:
          - securityContext:
              runAsNonRoot: true
              readOnlyRootFilesystem: true

Quand quelqu'un essaie de déployer un Pod sans security context, ça bloque automatiquement. Pas de discussion.

Pipeline DevSecOps complet

Voici à quoi ça ressemble dans GitHub Actions :

name: DevSecOps Pipeline
on: [push, pull_request]

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      # Source code scan
      - uses: actions/checkout@v2
      - name: SAST with SonarQube
        run: sonar-scanner

      # Dependency scan
      - name: Dependency check with Snyk
        run: snyk test --severity-threshold=high

      # Build and scan image
      - name: Build Docker image
        run: docker build -t myapp:${{ github.sha }} .
      - name: Scan image with Trivy
        run: trivy image --severity CRITICAL myapp:${{ github.sha }}

      # Policy check
      - name: Apply OPA policies
        run: conftest test deployment.yaml -p policies/

      # If all pass, proceed to deploy
      - name: Deploy
        if: success()
        run: kubectl apply -f deployment.yaml

Quelques améliorations :

1. Tous les scans en parallèle. Pas séquentiel (sinon le pipeline dure 30 min)
2. Fail fast. Si SAST échoue, n'allez pas builder l'image. C'est stupide.
3. Autofix quand possible. Certains outils (Snyk, Dependabot) peuvent auto-créer des PRs avec les fixes.

Mesure du succès

Vous devez tracker :

1. MTTR (Mean Time To Remediate). Moyenne du temps entre découverte d'une vulnérabilité et fix deployed. Target : < 7 jours. Si > 30 jours, quelque chose ne marche pas.

2. Coverage. Quel pourcentage de votre codebase est scanné ? Target : 100%.

3. Faux positifs. Si > 10% des alertes sont faux positifs, les développeurs vont ignorer. Tuner les règles.

4. Dépendances outdated. Quelle pct de vos dépendances sont à jour ? Target : > 90%.

Pièges à éviter

Piège 1 : Trop de faux positifs

Vous lancez SonarQube, 5000 violations remontent. Développeurs disent "c'est du bruit", désactivent l'outil.

Solution : Commencez avec une baseline conservative. 10-20 règles critiques. Croissez lentement.

Piège 2 : Security theatre

Vous avez SAST + SCA + Trivy + OPA + policy checks. Mais vous déployez vos apps sans user isolation (tous les conteneurs tournent en root). Ça c'est security theatre.

DevSecOps ne remplace pas une infra sécurisée. C'est complémentaire.

Piège 3 : Pas de supply chain security

Même si votre code est sûr, une dépendance que vous utilisez peut être compromise. Vous tracez la supply chain ?

Mitigation : SBOM + signature verification. Vérifiez que l'artifact vient bien du package official.

Pour les entreprises suisses : considérations compliance

La nLPD et la NIS2 exigent que vous démontriez une "reasonable security effort". DevSecOps est l'evidence qu'il faut :

• Vous scannez régulièrement pour vulnérabilités
• Vous avez un process pour fixer rapidement
• Vous loggez tout (qui a déployé quoi, quand, avec quels scans)

Si vous allez en audit, vous montrez votre DevSecOps pipeline et l'auditeur est heureux. Facile.

En résumé

DevSecOps n'est pas un luxe. C'est table-stakes:

1. SAST au commit pour code vulnérable
2. SCA pour dépendances vulnérable
3. Container scanning pour images vulnérables
4. Policy-as-Code pour règles métier

Implémentation complète : 2-4 mois, CHF 50,000-100,000. Économies sur incidents évités : CHF 200,000+/an facilement.

Si vous n'avez pas ça, votre infrastructure n'est pas production-ready.

À lire aussi :

• Kubernetes security checklist : 10 choses à faire demain
• GitOps : théorie et production

Cet article vous a été utile ? Découvrez comment Hidora peut vous accompagner : Professional Services · Managed Services · SLA Expert