Automatiser la conformité (CI/CD · GitHub Actions)

Acte 3 · Audit Bonus 1h30 DevSecOps · GitHub Actions · Syft · Grype · Lynis

Auteur : Thibaut Fontaine — Kodetis Position : prolongement bonus du TP1 — Conformité & Hardening.

1. Objectifs et contexte

📡 Poste SOC · La Réunion — Acte 3, Prouver : un audit ponctuel prouve la posture à l’instant T. Un pipeline la maintient dans le temps, sans y penser.

🎯 Objectif métier — faire en sorte qu’une CVE critique introduite dans une image, ou une régression de conformité, arrête la chaîne avant la mise en production.

Un audit manuel se périme dès le prochain docker pull. L’idée du DevSecOps : déplacer les contrôles de sécurité au plus tôt (shift-left), dans la chaîne d’intégration continue, pour qu’ils tournent à chaque push. Vous allez reprendre les trois scans du TP1 — SBOM (Syft), CVE (Grype), conformité (Lynis) — et les faire exécuter automatiquement par GitHub Actions.

Objectifs pédagogiques

À l’issue de ce TP, vous serez capable de :

Écrire un workflow GitHub Actions (.github/workflows/*.yml).
Y intégrer un scan SBOM (Syft) et un scan CVE (Grype) avec seuil d’échec.
Y ajouter un audit de conformité Lynis produisant un artefact.
Déclencher le pipeline sur push, pull_request et sur une planification hebdomadaire.
Comprendre le quota gratuit GitHub (2000 min/mois) et pourquoi il suffit largement ici.

2. Prérequis

Un compte GitHub (personnel ou universitaire) et un dépôt (public ou privé).
Les notions du TP1 : ce que produisent Syft (inventaire des composants) et Grype (CVE), et ce que mesure Lynis (indice de durcissement).

3. Le workflow GitHub Actions

Créez le fichier .github/workflows/security-scan.yml à la racine de votre dépôt.

name: security-scan

# Déclencheurs : à chaque push, à chaque pull request, et tous les lundis à 6h UTC
on:
  push:
    branches: [ main ]
  pull_request:
  schedule:
    - cron: '0 6 * * 1'   # veille de sécurité hebdomadaire

jobs:
  # 1. Inventaire des composants (SBOM) avec Syft
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Générer le SBOM (CycloneDX)
        uses: anchore/sbom-action@v0
        with:
          image: nextcloud:latest
          format: cyclonedx-json
          output-file: sbom-nextcloud.json
      - name: Publier le SBOM en artefact
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom-nextcloud.json
          retention-days: 30

  # 2. Scan des vulnérabilités (CVE) avec Grype — échoue si une CVE critique est trouvée
  vuln-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Scanner l'image avec Grype
        uses: anchore/scan-action@v4
        with:
          image: nextcloud:latest
          fail-build: true          # arrête le pipeline...
          severity-cutoff: critical # ...uniquement sur les CVE 'critical'

  # 3. Audit de conformité du runner avec Lynis
  lynis-audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Installer et lancer Lynis
        run: |
          sudo apt-get update && sudo apt-get install -y lynis
          sudo lynis audit system --no-colors --quiet | tee lynis-report.txt
          grep "Hardening index" lynis-report.txt || true
      - name: Publier le rapport Lynis
        uses: actions/upload-artifact@v4
        with:
          name: lynis-report
          path: lynis-report.txt
          retention-days: 30

4. Déclencher et lire les résultats

Poussez le fichier : git add .github/workflows/security-scan.yml && git commit -m "ci: scan sécurité" && git push.
Ouvrez l’onglet Actions de votre dépôt sur GitHub. Le workflow security-scan apparaît et se lance.
Cliquez sur le run pour voir les trois jobs (sbom, vuln-scan, lynis-audit) et leurs logs.
En bas de la page du run, section Artifacts : téléchargez sbom et lynis-report.

📸 Capture obligatoire : l’onglet Actions montrant un run terminé, avec les trois jobs et les artefacts listés.

5. Aller plus loin

Planification : le schedule (cron) rejoue l’audit chaque semaine, même sans commit — une veille automatique sur les nouvelles CVE des images que vous utilisez.
SARIF + Code scanning : anchore/scan-action peut produire un rapport SARIF que GitHub affiche dans l’onglet Security → Code scanning, avec chaque CVE annotée. (Nécessite un dépôt public ou GitHub Advanced Security.)
Dependabot : activez-le (Settings → Code security) pour être alerté des dépendances vulnérables.

6. Livrables & validation

Livrables

Le fichier .github/workflows/security-scan.yml dans votre dépôt.
Une capture de l’onglet Actions avec un run réussi et ses artefacts.
Un court paragraphe : quelle CVE critique a (ou aurait) arrêté la chaîne, et votre décision (corriger l’image / accepter le risque avec justification / whitelister).

Questions de validation

[Facile] Combien de minutes de CI le forfait GitHub Free offre-t-il par mois ? Est-ce suffisant ici ?
[Facile] Que fait severity-cutoff: critical combiné à fail-build: true ?
[Moyen] Quelle est la différence entre un SBOM (Syft) et un scan de CVE (Grype) ? Pourquoi produire les deux ?
[Moyen] À quoi sert le déclencheur schedule (cron) alors qu’on a déjà push ?
[Avancé] Une image publique que vous utilisez a une CVE critique sans correctif disponible. Le pipeline bloque. Que faites-vous, concrètement ?
[Avancé] Comparez ce pipeline GitHub Actions avec le pipeline GitLab CI évoqué au wiki. Qu’est-ce qui change, qu’est-ce qui reste identique ?
[Expert] Dans le contexte TAAF (connectivité satellite intermittente), un pipeline CI hébergé chez GitHub est-il pertinent ? Quelle alternative pour un site déconnecté ?