DevSecOps avec GitHub Actions : intégrer la sécurité dans vos pipelines

Pourquoi DevSecOps ?

Selon le rapport DORA 2024, les équipes high-performing détectent les problèmes de sécurité 60 fois plus vite lorsqu'ils sont intégrés dans le pipeline CI/CD plutôt que traités en phase finale. Le coût de correction d'une vulnérabilité découverte en production est 100 fois supérieur à celle découverte lors d'un commit. Le DevSecOps n'est pas une contrainte supplémentaire — c'est une accélération et une réduction de risque simultanées.

GitHub Actions est la plateforme idéale pour implémenter le DevSecOps : elle s'intègre nativement avec GitHub (où votre code vit), dispose d'un marketplace d'actions de sécurité riche, et permet de mettre en place des vérifications sans friction pour les développeurs.

Les 5 couches de sécurité dans un pipeline GitHub Actions

1. Analyse statique du code (SAST)

Le SAST analyse le code source sans l'exécuter pour détecter des vulnérabilités : injections SQL, XSS, désérialisations non sécurisées, gestion incorrecte des secrets. GitHub CodeQL est gratuit pour les dépôts publics et inclus dans GitHub Advanced Security pour les privés.

- name: Initialize CodeQL
  uses: github/codeql-action/init@v3
  with:
    languages: javascript, python, java
    queries: security-extended  # Inclut les requêtes OWASP Top 10

- name: Perform CodeQL Analysis
  uses: github/codeql-action/analyze@v3
  with:
    upload: true  # Résultats dans GitHub Security tab

2. Scan des dépendances (SCA)

Les dépendances tierces sont la source de 70 % des vulnérabilités selon les rapports Snyk. Le SCA (Software Composition Analysis) vérifie chaque dépendance contre des bases de CVE.

- name: Audit npm dependencies
  run: npm audit --audit-level=high

- name: Snyk vulnerability scan
  uses: snyk/actions/node@master
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
  with:
    args: --severity-threshold=high --fail-on=upgradable

- name: OWASP Dependency Check
  uses: dependency-check/Dependency-Check_Action@main
  with:
    project: 'my-app'
    format: 'SARIF'
    out: 'reports'

3. Détection de secrets

Les secrets hardcodés (clés API, mots de passe, tokens JWT) représentent l'un des vecteurs d'attaque les plus fréquents. Il faut les détecter avant qu'ils n'atteignent le dépôt.

- name: Scan for secrets with Gitleaks
  uses: gitleaks/gitleaks-action@v2
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

- name: TruffleHog deep scan
  uses: trufflesecurity/trufflehog@main
  with:
    path: ./
    base: ${{ github.event.repository.default_branch }}
    head: HEAD
    extra_args: --debug --only-verified

4. Sécurité des conteneurs (CSPM)

Si votre application est containerisée, l'image Docker elle-même peut contenir des vulnérabilités dans ses packages système. Trivy scanne l'image complète : OS packages, bibliothèques applicatives, fichiers de configuration.

- name: Build Docker image
  run: docker build -t app:${{ github.sha }} .

- name: Scan with Trivy
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: app:${{ github.sha }}
    format: sarif
    output: trivy-results.sarif
    severity: CRITICAL,HIGH
    exit-code: 1  # Fail the pipeline

- name: Upload Trivy results
  uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: trivy-results.sarif

5. Sécurité de la supply chain (SLSA)

Les attaques de supply chain (comme SolarWinds) compromettent le processus de build lui-même. SLSA (Supply-chain Levels for Software Artifacts) définit des niveaux de confiance pour la provenance des artefacts.

- name: Build and push image
  id: push
  uses: docker/build-push-action@v5
  with:
    push: true
    tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }}

- name: Attest build provenance (SLSA Level 3)
  uses: actions/attest-build-provenance@v1
  with:
    subject-name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
    subject-digest: ${{ steps.push.outputs.digest }}
    push-to-registry: true

Politique de blocage recommandée

Toutes les vérifications ne doivent pas bloquer de la même manière. Voici la politique que nous appliquons chez Move2Cloud :

• CRITICAL : blocage immédiat du merge, notification canal Slack #security, création automatique d'un GitHub Issue
• HIGH : blocage du merge + notification équipe sécurité. Doit être résolu ou accepté explicitement avant merge.
• MEDIUM : warning visible dans la PR, merge autorisé avec justification documentée dans un commentaire
• LOW : rapport dans le Security Dashboard uniquement, aucun blocage

Gestion des secrets dans le pipeline

Les secrets du pipeline (tokens, clés API pour les scans) doivent eux-mêmes être gérés de manière sécurisée :

• Utiliser GitHub Secrets pour stocker les tokens (jamais dans le code ou les variables d'environnement en clair)
• Préférer l'authentification OIDC pour AWS/Azure — élimine les clés à longue durée de vie dans les secrets GitHub
• Restreindre les secrets aux environnements spécifiques (pas de clé de production accessible depuis les PR de forks)

- name: Configure AWS credentials via OIDC
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::123456789:role/GitHubActionsSecurityScan
    aws-region: eu-west-1
    # Aucune clé stockée — authentification via token OIDC

Conclusion

Un pipeline DevSecOps complet avec GitHub Actions peut être mis en place en une à deux journées. La clé est de commencer par les vérifications à plus fort impact (secrets, CRITICAL/HIGH CVE) et d'introduire progressivement les contrôles plus fins. L'objectif n'est pas la perfection immédiate, mais un cycle d'amélioration continue où chaque sprint réduit le surface d'attaque. Les équipes qui font du DevSecOps réduisent leur temps de réponse aux incidents de sécurité d'un facteur 6 — c'est un investissement qui se rembourse rapidement.