DevSecOps : industrialiser le shift-left sans freiner la CI

La sécurité applicative ne se traite plus en fin de cycle. Depuis l'attaque SolarWinds, les compromissions de paquets npm (event-stream, ua-parser-js, plus récemment l'affaire XZ Utils en 2024) et l'entrée en vigueur du Cyber Resilience Act européen, les équipes n'ont plus le luxe de découvrir une CVE critique deux semaines avant la mise en production. Le shift-left est devenu un impératif opérationnel — encore faut-il l'implémenter sans transformer chaque pull request en parcours du combattant.

Voici comment nous structurons un pipeline DevSecOps réellement utilisable sur nos missions.

1. Cartographier la supply chain avec un SBOM

Un SBOM (Software Bill of Materials) au format CycloneDX ou SPDX est aujourd'hui le socle minimal. Sans inventaire signé de vos dépendances, impossible de répondre en 2 heures à un nouveau Log4Shell.

Génération avec syft puis analyse des vulnérabilités avec grype, intégrés dans GitHub Actions :

- name: Generate SBOM
  uses: anchore/sbom-action@v0
  with:
    format: cyclonedx-json
    output-file: sbom.cdx.json

- name: Scan vulnerabilities
  uses: anchore/scan-action@v3
  with:
    sbom: sbom.cdx.json
    fail-build: true
    severity-cutoff: high

Le SBOM doit être signé (cosign + Sigstore) et stocké comme artefact immuable. Couplé à une attestation SLSA niveau 3, il prouve l'intégrité de la chaîne de build face à un auditeur ou un client grand compte.

2. Verrouiller les secrets avant qu'ils ne fuient

Les secrets en clair dans un repo restent la première cause d'incident chez nos clients. Trois lignes de défense :

• Pré-commit : gitleaks ou trufflehog en hook local, bloquant le commit avant qu'il n'atteigne l'origin.
• CI : re-scan systématique de l'historique sur chaque PR (un dev peut contourner le hook).
• Runtime : centralisation dans HashiCorp Vault, AWS Secrets Manager ou Doppler, avec rotation automatique et injection via OIDC plutôt que des credentials statiques.

Pour les workflows GitHub Actions vers AWS, l'authentification OIDC élimine purement et simplement les AWS_ACCESS_KEY_ID stockées en secret de repo :

permissions:
  id-token: write
steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::123456789012:role/ci-deploy
      aws-region: eu-west-3

3. SAST, DAST, IaC scanning : choisir ses combats

Empiler les scanners produit du bruit, des faux positifs et une fatigue d'équipe. Voici la répartition que nous recommandons :

| Étape | Outil(s) | Bloquant ? | Temps cible | |---|---|---|---| | SAST code | Semgrep, SonarQube | Oui sur règles critiques | < 3 min | | Dépendances | Dependabot, Renovate, grype | Oui si CVE ≥ High exploitable | < 2 min | | IaC | Checkov, tfsec, KICS | Oui sur misconfigs critiques | < 1 min | | Container | Trivy | Oui si CVE OS ≥ Critical | < 2 min | | DAST | OWASP ZAP, Burp Enterprise | Non (nightly) | 15-30 min | | Secrets | gitleaks | Oui, toujours | < 30 s |

Le DAST mérite une mention particulière : trop lent pour bloquer une PR, il trouve sa place sur l'environnement de staging en job nocturne, avec un rapport agrégé dans DefectDojo ou OWASP Glue.

4. Politique as Code : la règle du non-contournable

Un pipeline sécurisé qu'on peut désactiver d'un clic ne sert à rien. Avec OPA/Conftest ou Kyverno côté Kubernetes, on encode les politiques (pas de :latest, pas de runAsRoot, image signée obligatoire) et on les applique en admission controller. Le contrôle ne dépend plus de la discipline du dev.

Exemple de politique Kyverno refusant tout pod sans signature cosign vérifiée :

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-images
spec:
  validationFailureAction: Enforce
  rules:
    - name: verify-signature
      match:
        any:
        - resources:
            kinds: [Pod]
      verifyImages:
      - imageReferences: ["registry.dct.io/*"]
        attestors:
        - entries:
          - keys:
              publicKeys: |-
                -----BEGIN PUBLIC KEY-----
                ...
                -----END PUBLIC KEY-----

5. Mesurer pour piloter

Un programme DevSecOps sans métriques tourne au théâtre de sécurité. Les KPI que nous suivons :

• MTTR vulnérabilité critique : objectif < 48 h pour les Critical, < 7 jours pour les High.
• Taux d'échec des builds pour cause sécurité : doit décroître après 3 mois (signe d'apprentissage).
• Couverture SBOM : 100 % des services en production.
• Densité de findings par 1 000 lignes de code, par équipe.

Ces chiffres remontent dans un tableau Grafana alimenté par DefectDojo ou directement par les APIs des scanners.

Checklist de mise en route

• [ ] SBOM CycloneDX généré à chaque build et signé
• [ ] Scan secrets en pré-commit et en CI
• [ ] Authentification OIDC pour tous les déploiements cloud
• [ ] SAST + IaC scan bloquants sur sévérité High+
• [ ] DAST nocturne sur staging
• [ ] Politiques OPA/Kyverno en admission controller
• [ ] Rotation automatique des secrets via Vault
• [ ] Dashboard de métriques sécurité partagé avec les équipes produit

À retenir

• Le SBOM signé est non négociable : sans inventaire, pas de réponse rapide à la prochaine CVE majeure.
• L'authentification OIDC élimine la classe entière des credentials statiques en CI.
• Choisir un scanner par étape, pas trois : la fatigue d'alertes tue le programme plus vite que les attaquants.
• Encoder les politiques en code (OPA, Kyverno) pour rendre le contrôle non contournable.
• Mesurer le MTTR sécurité comme on mesure le MTTR incident : sans métrique, pas d'amélioration.