DevSecOps : sécuriser la chaîne logicielle

1. Shift-left #

La sécurité est l'affaire de tous.

Principes #

Le DevSecOps intègre la sécurité à chaque étape au lieu d'un audit en fin de projet. Une vulnérabilité détectée dans la pull request coûte quelques minutes ; la même découverte en production coûte un incident.

• Modélisation des menaces au moment de la conception (STRIDE, quelques questions simples : que peut-il mal se passer ?).
• Contrôles automatiques et rapides dans le pipeline, avec des seuils clairs.
• Des correctifs proposés automatiquement (Dependabot, Renovate).
• Une équipe sécurité qui outille et accompagne plutôt qu'elle ne bloque en fin de chaîne.

2. Les contrôles #

Ce que l'on analyse et avec quoi.

Panorama #

En ligne de commande #

gitleaks detect --source . --redact                    # secrets
semgrep scan --config auto --error                      # SAST
trivy fs --scanners vuln,secret,misconfig --severity HIGH,CRITICAL --exit-code 1 .
trivy image --severity CRITICAL --exit-code 1 ghcr.io/mon-org/shop-api:3f9c2e1
checkov -d infra/                                       # IaC

Gérer les résultats #

Bonne Pratique : Bloquez seulement sur ce qui est grave et corrigeable (CRITICAL avec correctif disponible), affichez le reste. Un pipeline qui bloque sur des centaines d'alertes est rapidement contourné.

Documentez les exceptions (.trivyignore, annotations) avec une justification et une date d'expiration.

3. La chaîne d'approvisionnement logicielle #

Savoir ce que l'on livre, et le prouver.

SBOM #

Une SBOM (Software Bill of Materials) est l'inventaire de tous les composants d'un artefact, aux formats SPDX ou CycloneDX. Quand une nouvelle faille est publiée (Log4Shell), elle permet de savoir en minutes quelles images sont concernées.

syft ghcr.io/mon-org/shop-api:3f9c2e1 -o spdx-json > sbom.spdx.json
grype sbom:sbom.spdx.json       # analyser une SBOM existante

Signature et provenance #

# Cosign (Sigstore) : signature sans clé avec l'identité OIDC de la CI
cosign sign --yes ghcr.io/mon-org/shop-api@sha256:4b1c...
cosign attest --yes --type spdxjson --predicate sbom.spdx.json ghcr.io/mon-org/shop-api@sha256:4b1c...
cosign verify ghcr.io/mon-org/shop-api@sha256:4b1c... \
  --certificate-identity-regexp 'https://github.com/mon-org/.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

Le cadre SLSA définit des niveaux de garantie sur la provenance : build scripté, exécuté sur une plateforme de CI, attestation de provenance signée, build isolé et non falsifiable.

Politiques à l'admission #

# Kyverno : n'accepter que des images signées par notre CI
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata: { name: images-signees }
spec:
  validationFailureAction: Enforce
  rules:
    - name: verifier-signature
      match: { any: [{ resources: { kinds: [Pod] } }] }
      verifyImages:
        - imageReferences: ["ghcr.io/mon-org/*"]
          attestors:
            - entries:
                - keyless:
                    subject: "https://github.com/mon-org/*"
                    issuer: "https://token.actions.githubusercontent.com"

4. Secrets #

Le premier vecteur de compromission.

Règles #

• Aucun secret dans Git, les images ou les journaux ; détection en pre-commit et dans la CI.
• Un gestionnaire de secrets (Vault, AWS Secrets Manager, Azure Key Vault, External Secrets Operator).
• Des identifiants courts et automatiques (OIDC, rôles cloud) plutôt que des clés longues.
• Rotation régulière et immédiate en cas de fuite : supprimer le commit ne suffit pas, le secret doit être révoqué.

Erreur Courante : Un secret poussé sur un dépôt public est collecté par des robots en quelques minutes. Révoquez-le d'abord, nettoyez l'historique ensuite.