DevSecOps : intégrer la sécurité dès le pipeline CI/CD

La sécurité applicative ne peut plus être une étape de fin de cycle gérée par une équipe distincte. Avec l'explosion des attaques sur la chaîne d'approvisionnement logicielle — SolarWinds, Log4Shell, XZ Utils en 2024 — la pression réglementaire (CRA européen, EO 14028 américain) impose désormais une approche DevSecOps mature. Voici comment structurer concrètement ce changement dans vos pipelines.

Shift-left : décaler la sécurité au plus tôt

Le principe est simple : plus une vulnérabilité est détectée tard, plus elle coûte cher à corriger. Selon les chiffres du NIST, corriger un bug en production coûte 30 à 100 fois plus qu'en phase de développement. Le shift-left consiste à intégrer les contrôles de sécurité dès l'IDE et le commit.

Concrètement, cela se traduit par :

• Pre-commit hooks avec pre-commit + gitleaks pour bloquer les secrets avant qu'ils n'atteignent le dépôt
• Plugins IDE comme Snyk, SonarLint ou Semgrep qui remontent les vulnérabilités en temps réel
• Policies as code avec OPA/Rego ou Checkov pour valider l'IaC (Terraform, Kubernetes) avant merge

SAST et DAST dans la CI : la combinaison gagnante

Le SAST (analyse statique) et le DAST (analyse dynamique) sont complémentaires. Le premier examine le code source, le second teste l'application en cours d'exécution.

| Aspect | SAST | DAST | |--------|------|------| | Moment | Build / PR | Post-déploiement (staging) | | Cible | Code source | Application en cours d'exécution | | Faux positifs | Élevés | Faibles | | Outils | Semgrep, SonarQube, CodeQL | OWASP ZAP, Burp Suite, Nuclei | | Durée typique | 2-10 min | 15-60 min |

Voici un exemple minimaliste d'intégration Semgrep dans GitHub Actions :

name: SAST
on: [pull_request]
jobs:
  semgrep:
    runs-on: ubuntu-latest
    container: returntocorp/semgrep
    steps:
      - uses: actions/checkout@v4
      - run: semgrep ci --config=p/owasp-top-ten --config=p/cwe-top-25
        env:
          SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_TOKEN }}

La règle d'or : faire échouer le build sur les findings HIGH et CRITICAL, mais ne pas bloquer sur les MEDIUM et LOW pour éviter la fatigue des équipes. Cette dernière catégorie remonte dans un dashboard de dette technique.

SBOM : la photographie obligatoire de votre supply chain

Le Software Bill of Materials est devenu incontournable. Le Cyber Resilience Act européen (entrée en application en 2027) et l'Executive Order 14028 américain l'imposent déjà pour de nombreux secteurs.

Deux formats dominent : CycloneDX (OWASP) et SPDX (Linux Foundation). Génération avec Syft :

# Génération du SBOM
syft packages dir:. -o cyclonedx-json > sbom.json

# Scan des vulnérabilités à partir du SBOM
grype sbom:./sbom.json --fail-on high

Intégrez la génération du SBOM à chaque build et signez-le avec Cosign (projet Sigstore). Stocké à côté de l'image dans le registry OCI, il devient la source de vérité auditable. Couplé à cosign verify-attestation, vous obtenez une chaîne de confiance vérifiable jusqu'au déploiement Kubernetes via Kyverno ou des admission controllers.

Gestion des secrets : éliminer la dette

Les secrets en clair dans le code restent la cause #1 des fuites. Trois niveaux à mettre en place :

1. Détection rétroactive : gitleaks detect --source . --log-opts="--all" sur l'historique complet du dépôt
2. Prévention : hook pre-commit + scan obligatoire sur les PR
3. Centralisation : HashiCorp Vault, AWS Secrets Manager ou Doppler avec rotation automatique

Pour Kubernetes, l'External Secrets Operator (ESO) couplé à Vault permet de bannir totalement les Secret natifs en clair dans les manifestes Git. C'est aussi la base de toute stratégie GitOps sécurisée avec ArgoCD ou Flux.

Sécuriser la supply chain : au-delà du SBOM

La supply chain ne s'arrête pas aux dépendances applicatives. Pensez aussi à :

• Pinning des actions GitHub par SHA, pas par tag (uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11)
• Build provenance avec SLSA niveau 3 minimum (attestations via GitHub Artifact Attestations ou Tekton Chains)
• Images de base minimales : distroless, chainguard/static ou wolfi pour réduire la surface d'attaque
• Verrouillage des registres : interdire les pulls depuis Docker Hub public en production, miroir interne obligatoire (Harbor, JFrog)

Checklist d'audit DevSecOps

• [ ] Scan SAST automatique sur chaque PR avec seuil bloquant configuré
• [ ] DAST hebdomadaire minimum sur l'environnement de staging
• [ ] SBOM généré et signé pour chaque artefact de production
• [ ] Aucun secret dans le code (vérifié par gitleaks sur tout l'historique)
• [ ] Vault ou équivalent en place avec rotation < 90 jours
• [ ] Images de base scannées quotidiennement (Trivy, Grype)
• [ ] Politique de mise à jour des dépendances avec Dependabot/Renovate
• [ ] Attestations SLSA niveau 2 ou 3 sur tous les builds critiques

À retenir

• Le shift-left n'est pas une option : la pression réglementaire (CRA, NIS2) en fait une obligation à court terme pour la majorité des éditeurs européens.
• SAST + DAST + SBOM forment le triptyque minimal d'un pipeline DevSecOps moderne, à compléter par la signature d'artefacts (Cosign/Sigstore).
• La gestion des secrets centralisée (Vault, ESO) doit précéder toute initiative GitOps sérieuse, sinon vous propagez le risque.
• Mesurez la friction développeur : un pipeline qui bloque sur 200 findings LOW sera contourné. Priorisez HIGH/CRITICAL et capitalisez sur les outils intégrés à l'IDE.
• La supply chain est le nouveau périmètre : pinning, provenance SLSA et images minimales sont aussi importants que vos WAF historiques.