Bonnes pratiques DevSecOps

Parcours Implémentation — Partie 1 : Évaluer

Chapitre 1.2 — Les 4 piliers d’un système de qualité DevSecOps.

Étape précédente : 1.1 Audit de maturité Prochaine étape : 2.1 Team Topologies

Adopter des outils sans méthode peut compromettre la sécurité, la fiabilité et la maintenabilité des systèmes. Installer Kubernetes ne rend pas votre application plus sûre. Mettre en place un pipeline CI/CD ne garantit pas des déploiements fiables. C’est la manière dont vous utilisez ces outils qui fait la différence.

Cette page rassemble les bonnes pratiques éprouvées pour construire des plateformes performantes et durables. Chaque recommandation est actionnable et issue de retours terrain. L’objectif n’est pas de tout appliquer immédiatement, mais de comprendre les principes pour les adapter à votre contexte.

Prérequis

Avant d’appliquer ces bonnes pratiques, maîtrisez les fondamentaux :

Fondamentaux DevSecOps Principes de sécurité intégrée au cycle de développement

Fondamentaux DevOps Culture, collaboration, automatisation

Infrastructure as Code Provisionnement automatisé et reproductible

Vue d’ensemble : les 4 piliers

Les bonnes pratiques DevSecOps s’organisent autour de quatre piliers complémentaires. Chacun répond à une question fondamentale que tout système en production doit se poser. Négliger l’un de ces piliers crée tôt ou tard des problèmes : une application peut être sécurisée mais impossible à déboguer, ou fiable mais impossible à maintenir.

Pilier	Objectif	Question clé
Sécurité	Protéger les données et systèmes	Comment détecter une vulnérabilité avant la production ?
Fiabilité	Garantir disponibilité et performance	Comment résister à une panne sans impact utilisateur ?
Exploitabilité	Surveiller, diagnostiquer, réagir	Comment identifier la cause d’un incident en 5 minutes ?
Maintenabilité	Faire évoluer et corriger facilement	Comment modifier ce système dans 6 mois ?

Le problème terrain

Pourquoi formaliser des bonnes pratiques ? Parce que sans cadre commun, chaque équipe invente ses propres solutions, souvent dans l’urgence. Les erreurs se répètent, la dette technique s’accumule, et les incidents deviennent la norme plutôt que l’exception.

Symptômes d'alerte

• Sécurité en afterthought : vulnérabilités découvertes en production, correctifs urgents
• Dette technique croissante : code non documenté, configurations dupliquées, scripts ad hoc
• Incidents récurrents : mêmes erreurs qui se répètent faute de capitalisation
• Environnements divergents : « ça marche sur ma machine » mais pas en production
• Restaurations non testées : sauvegardes inutilisables le jour J
• Monitoring inexistant ou inexploitable : alertes ignorées, dashboards abandonnés

Pilier 1 : Sécurité

La sécurité coûte moins cher quand elle est intégrée tôt. Une vulnérabilité détectée au moment du commit se corrige en quelques minutes. La même vulnérabilité découverte en production peut nécessiter des jours de travail, sans compter les impacts potentiels.

Le principe du shift-left consiste à déplacer les contrôles de sécurité le plus tôt possible dans le cycle de développement. Concrètement, cela signifie scanner les dépendances avant de merger une pull request, vérifier les secrets avant le commit, et bloquer les images vulnérables avant qu’elles n’atteignent la production.

Pratiques essentielles

Pratique	Action concrète
Shift-left security	Scanner les dépendances dans la CI (Trivy, Snyk, Grype)
Secrets management	Jamais de secrets en clair ; utiliser Vault, SOPS, ou Sealed Secrets
Moindre privilège	Comptes de service avec permissions minimales, révision trimestrielle
Scan d’images	Bloquer les images avec CVE critiques non corrigées
SAST/DAST	Analyse statique et dynamique intégrée au pipeline
Revue de code sécurité	Checklist sécurité dans les pull requests

Supply Chain Security : SBOM et SLSA

La sécurité de la chaîne d’approvisionnement logicielle est devenue critique après les attaques SolarWinds et Log4Shell. Ces incidents ont révélé une vérité inconfortable : vous pouvez avoir le code le plus sécurisé du monde, si une de vos dépendances est compromise, votre application l’est aussi.

Deux standards complémentaires émergent pour sécuriser la supply chain. Le SBOM répond à la question « de quoi est composé mon logiciel ? ». SLSA répond à « puis-je faire confiance à la manière dont il a été construit ? ».

SBOM

Le Software Bill of Materials (SBOM) est un inventaire complet des composants d’un logiciel :

• Quoi : Liste de toutes les dépendances (directes et transitives)
• Pourquoi : Traçabilité des CVE, conformité licences, audit sécurité
• Formats : SPDX (Linux Foundation), CycloneDX (OWASP)
• Outils : Syft, Trivy, Grype pour générer et scanner

# Générer un SBOM avec Syft
syft packages alpine:latest -o spdx-json > sbom.spdx.json

# Scanner le SBOM avec Grype
grype sbom:sbom.spdx.json

SLSA

SLSA (Supply-chain Levels for Software Artifacts) définit 4 niveaux de maturité :

Niveau	Exigences	Protège contre
Level 1	Documentation du processus de build	Erreurs humaines
Level 2	Build sur service hébergé + logs	Modifications non autorisées
Level 3	Build isolé + provenance vérifiable	Compromission du builder
Level 4	Review 2 personnes + build hermétique	Insiders malveillants

# Exemple attestation SLSA dans GitHub Actions
- uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v1.9.0
  with:
    base64-subjects: "${{ needs.build.outputs.digest }}"

Outils

Outil	Usage
Cosign	Signature et vérification d’images OCI
Syft	Génération de SBOM
Grype	Scan de vulnérabilités
in-toto	Attestations de provenance
Sigstore	PKI publique pour la signature

# Signer une image avec Cosign
cosign sign --key cosign.key myregistry/myimage:v1.0.0

# Vérifier la signature
cosign verify --key cosign.pub myregistry/myimage:v1.0.0

Pilier 2 : Fiabilité

La question n’est pas si une panne arrivera, mais quand. Un serveur tombera, un disque se corrompra, un datacenter subira une coupure. Les systèmes fiables ne sont pas ceux qui ne tombent jamais, mais ceux qui résistent aux pannes et se rétablissent rapidement.

La fiabilité repose sur deux principes fondamentaux : l’immutabilité et la redondance. L’immutabilité signifie qu’on ne modifie jamais un système en production — on le remplace par une nouvelle version. La redondance garantit qu’une panne d’un composant n’impacte pas le service global.

Pratiques essentielles

Pratique	Action concrète
Infrastructure as Code	100 % de l’infra versionnée (Terraform, Pulumi, Ansible)
Immutabilité	Pas de modification manuelle en production ; redéployer
Redondance	Multi-AZ ou multi-région pour les services critiques
Circuit breakers	Isoler les défaillances pour éviter les cascades
Chaos engineering	Tests de résilience réguliers (Chaos Monkey, Litmus)
Capacity planning	Projections de charge et tests de performance

Error Budgets : équilibrer vélocité et stabilité

L’Error Budget est un concept SRE qui transforme la fiabilité en décision business. Au lieu de viser 100% de disponibilité (impossible et coûteux), on définit un budget d’erreur acceptable.

L’idée est simple : si votre SLO est de 99.9% de disponibilité, vous « autorisez » 0.1% d’indisponibilité. Ce budget peut être « dépensé » pour livrer des features (qui comportent toujours un risque) ou « économisé » pour absorber les incidents imprévus. Quand le budget est épuisé, l’équipe se concentre exclusivement sur la stabilité.

1. Définir les SLI (Service Level Indicators)

   Métriques mesurables : latence p99, taux d’erreur, throughput.

   # Exemple SLI
   sli:
     latency_p99: "temps de réponse 99e percentile < 200ms"
     error_rate: "taux d'erreurs HTTP 5xx"
     availability: "succès des health checks"

2. Fixer les SLO (Service Level Objectives)

   Objectifs internes basés sur les SLI.

   # Exemple SLO
   slo:
     availability: 99.9%  # 8h45 de downtime autorisé par an
     latency_p99: 200ms
     error_rate: < 0.1%

3. Calculer l’Error Budget

   Error Budget = 100% - SLO
   
   Avec SLO = 99.9% → Error Budget = 0.1%
   Sur 30 jours = 43 minutes de downtime autorisées

4. Appliquer la politique Error Budget

   Budget restant	Action
   > 50%	Nouvelles features, expérimentations
   20-50%	Features + travail sur la fiabilité
   < 20%	Stop features, focus stabilité
   Épuisé	Gel complet, incident review

Pilier 3 : Exploitabilité

Vous ne pouvez pas réparer ce que vous ne voyez pas. L’observabilité consiste à instrumenter vos systèmes pour comprendre leur comportement en production. Sans elle, chaque incident devient une enquête à l’aveugle.

L’observabilité moderne repose sur trois piliers complémentaires : les métriques (que se passe-t-il en ce moment ?), les logs (qu’est-ce qui s’est passé ?), et les traces (comment les requêtes traversent-elles le système ?). La corrélation entre ces trois sources permet de diagnostiquer rapidement les problèmes les plus complexes.

Pratiques essentielles

Pratique	Action concrète
Observabilité 3 piliers	Métriques + Logs + Traces corrélés
Dashboards actionnables	Indicateurs clés visibles, pas de « vanity metrics »
Alertes pertinentes	Seuils basés sur SLO, pas sur des valeurs arbitraires
Runbooks	Procédures documentées pour chaque alerte critique
Post-mortems	Analyse blameless après chaque incident majeur
On-call rotation	Équipes formées et outillées pour l’astreinte

OpenTelemetry : observabilité standardisée

OpenTelemetry (OTel) est devenu le standard de facto pour l’instrumentation. Il offre une approche vendor-neutral pour collecter métriques, logs et traces.

L’avantage principal d’OpenTelemetry est sa portabilité : vous instrumentez une fois votre code, et vous pouvez envoyer les données vers n’importe quel backend (Jaeger, Zipkin, Datadog, New Relic…). Le Collector agit comme un point central qui reçoit, transforme et route les données vers les destinations appropriées.

Architecture

┌─────────────────────────────────────────────────────────────┐
│                      Applications                            │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐    │
│  │ Service A│  │ Service B│  │ Service C│  │ Service D│    │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘  └────┬─────┘    │
│       │             │             │             │           │
│       └─────────────┴─────────────┴─────────────┘           │
│                         │                                    │
│                    OTel SDK                                  │
│              (auto-instrumentation)                          │
└─────────────────────────┬───────────────────────────────────┘
                          │ OTLP
                          ▼
              ┌───────────────────────┐
              │   OTel Collector      │
              │  ┌─────────────────┐  │
              │  │   Receivers     │  │
              │  │   Processors    │  │
              │  │   Exporters     │  │
              │  └─────────────────┘  │
              └───────────┬───────────┘
                          │
        ┌─────────────────┼─────────────────┐
        ▼                 ▼                 ▼
   ┌─────────┐      ┌─────────┐      ┌─────────┐
   │ Jaeger  │      │Prometheus│     │  Loki   │
   │ Traces  │      │ Metrics  │     │  Logs   │
   └─────────┘      └─────────┘      └─────────┘

Implémentation

# Python avec OpenTelemetry
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

# Configuration
provider = TracerProvider()
processor = BatchSpanProcessor(OTLPSpanExporter(endpoint="otel-collector:4317"))
provider.add_span_processor(processor)
trace.set_tracer_provider(provider)

# Utilisation
tracer = trace.get_tracer(__name__)
with tracer.start_as_current_span("process_request") as span:
    span.set_attribute("user.id", user_id)
    # ... traitement

Collector config

otel-collector-config.yaml

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 1s
    send_batch_size: 1024
  memory_limiter:
    check_interval: 1s
    limit_mib: 1000

exporters:
  prometheus:
    endpoint: "0.0.0.0:8889"
  jaeger:
    endpoint: jaeger:14250
    tls:
      insecure: true
  loki:
    endpoint: http://loki:3100/loki/api/v1/push

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [jaeger]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [prometheus]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [loki]

Pilier 4 : Maintenabilité

Un système sera modifié bien plus souvent qu’il ne sera écrit. La maintenabilité consiste à faciliter ces modifications futures : documentation à jour, tests qui permettent de refactorer sereinement, sauvegardes qui fonctionnent vraiment.

La maintenabilité se joue souvent dans les détails : un README clair qui explique comment lancer le projet, des ADR (Architecture Decision Records) qui documentent les choix techniques, des tests qui servent de spécification vivante. C’est ce qui fait la différence entre un projet qu’on peut faire évoluer sereinement et un projet qu’on a peur de toucher.

Pratiques essentielles

Pratique	Action concrète
Documentation à jour	README, ADR, diagrammes
Sauvegardes testées	Restauration validée mensuellement
Plan de reprise (PRA/PCA)	Testé annuellement avec les équipes
Versioning sémantique	Contrats d’API clairs, breaking changes documentés
Refactoring continu	Budget temps dédié à la réduction de dette
Tests automatisés	Couverture suffisante pour refactorer sereinement

Golden Paths : standardiser sans contraindre

Les Golden Paths sont des chemins balisés qui permettent aux développeurs de livrer rapidement tout en respectant les bonnes pratiques de l’organisation. C’est le concept central du Platform Engineering.

L’idée est de réduire la charge cognitive des développeurs : au lieu de devoir choisir parmi des dizaines d’options pour chaque aspect technique (framework, CI/CD, monitoring…), ils suivent un chemin pré-validé. Ce n’est pas une contrainte rigide — c’est un raccourci vers les bonnes pratiques. Les équipes expérimentées peuvent toujours dévier si nécessaire.

Principe clé

Un Golden Path est une recommandation, pas une obligation. Les équipes peuvent dévier si elles ont une bonne raison — mais le chemin par défaut doit être le plus facile à suivre.

Composants d’un Golden Path

1. Template de projet

   Structure de repo, Dockerfile, CI/CD, configs de base pré-configurés.

   # Exemple avec Backstage
   backstage-cli create --template=microservice-template
   
   # Génère automatiquement :
   # ├── src/
   # ├── Dockerfile
   # ├── .gitlab-ci.yml
   # ├── kubernetes/
   # │   ├── deployment.yaml
   # │   └── service.yaml
   # ├── docs/
   # │   └── ADR/
   # └── README.md

2. Self-service portal

   Interface pour créer des ressources sans tickets.

   Outil	Type	Points forts
   Backstage	IDP open-source	Templates, catalog, plugins
   Port	SaaS	Rapide à déployer, scorecards
   Humanitec	SaaS	Focus déploiement

3. Documentation intégrée

   Guides dans le flux de travail, pas sur un wiki séparé. Voir Docs-as-Code.

4. Guardrails automatiques

   Policies qui préviennent les erreurs sans bloquer.

   # Kyverno policy exemple
   apiVersion: kyverno.io/v1
   kind: ClusterPolicy
   metadata:
     name: require-labels
   spec:
     validationFailureAction: Enforce
     rules:
       - name: check-team-label
         match:
           resources:
             kinds:
               - Deployment
         validate:
           message: "Le label 'team' est obligatoire"
           pattern:
             metadata:
               labels:
                 team: "?*"

Scénarios concrets

Scénario 1 : Fuite de secrets dans un commit

Contexte : Un développeur commit accidentellement une clé API dans le code source.

Sans bonnes pratiques

La clé reste dans l’historique Git. Elle est découverte 6 mois plus tard par un audit externe. Coût : rotation de tous les accès, analyse forensique, communication de crise.

Avec bonnes pratiques

1. Le hook pre-commit (git-secrets, detect-secrets) bloque le commit
2. Si le commit passe, le scan CI (Gitleaks, TruffleHog) échoue
3. La clé est révoquée immédiatement via Vault
4. Nouvelle clé générée et injectée automatiquement
5. L’incident est documenté, le processus amélioré

Scénario 2 : Incident production un vendredi soir

Contexte : L’application principale renvoie des erreurs 500. L’ingénieur d’astreinte est alerté.

Sans bonnes pratiques

4 heures de diagnostic dans les logs non structurés. Pas de runbook. Rollback manuel hasardeux. Weekend ruiné.

Avec bonnes pratiques

1. L’alerte contient un lien vers le runbook correspondant
2. Le dashboard montre la corrélation entre le déploiement de 17h et les erreurs
3. Le rollback automatique est déclenché en 2 clics
4. Le service est restauré en 15 minutes
5. Post-mortem planifié pour lundi

Pièges courants

Piège	Pourquoi c’est un problème	Correction
Sécurité en fin de cycle	Correctifs coûteux, retards de livraison	Shift-left : scanner dès le commit
Trop d’alertes	Alert fatigue, alertes ignorées	Seuils basés sur SLO, suppression du bruit
Backups non testés	Restauration impossible le jour J	Test de restauration mensuel
Documentation obsolète	Confiance perdue, erreurs de procédure	Docs dans le repo, revue à chaque PR
Environnements manuels	Divergences, « works on my machine »	Tout en IaC, environnements éphémères
Moindre privilège ignoré	Surface d’attaque étendue	Audit trimestriel des permissions
Post-mortems punitifs	Dissimulation des erreurs	Culture blameless, focus sur le système
Dette technique accumulée	Vélocité en chute libre	Budget dédié (20 % du sprint)

Critères de réussite

Comment savoir si vos pratiques sont matures ? Ces critères vous donnent une grille d’évaluation objective :

• Aucun secret en clair dans les repos ou les pipelines
• Les images Docker sont scannées et les CVE critiques bloquent le déploiement
• SBOM généré automatiquement pour chaque release
• 100 % de l’infrastructure est versionnée et reproductible
• Les SLO sont définis et l’Error Budget est suivi
• Les alertes déclenchent des actions documentées (runbooks)
• Les restaurations de backup sont testées au moins une fois par trimestre
• Un post-mortem blameless est rédigé après chaque incident majeur
• Les équipes peuvent déployer de manière autonome sans intervention manuelle
• Les métriques DORA (MTTD, MTTR, Deployment Frequency, Change Failure Rate) sont mesurées

À retenir

• La sécurité s’intègre dès le premier commit avec SBOM et SLSA
• La fiabilité se pilote avec des SLO et Error Budgets
• L’exploitabilité repose sur OpenTelemetry et des runbooks actionnables
• La maintenabilité nécessite documentation, tests et sauvegardes validées
• Les Golden Paths standardisent sans contraindre
• Ces pratiques se renforcent mutuellement : commencez par celles qui traitent vos incidents récurrents

Liens utiles

Indicateurs DORA Mesurer l'efficacité de vos pratiques

Observabilité Métriques, logs, traces avec OpenTelemetry

Gestion de configuration Ansible et outils associés

Pipelines CI/CD Automatiser les déploiements sécurisés

Documentation technique Runbooks, ADR, Service Overviews et bonnes pratiques

×

📖 Voir la documentation →