CI/CD sécurisé avec GitHub Actions : de zéro à la production

Lors de mon stage DevSecOps chez Bifora Data Consulting, j'ai été chargé de mettre en place des pipelines CI/CD sécurisés pour l'application KPITN. Voici ce que j'ai appris.

Pourquoi sécuriser dès le pipeline ?

L'approche "shift left" consiste à détecter les vulnérabilités le plus tôt possible dans le cycle de développement — au moment du commit, pas en production. Cela réduit drastiquement le coût de correction.

Un bug corrigé en développement coûte 10x moins cher qu'en production.

La structure du pipeline

name: CI/CD Sécurisé

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Analyse SAST avec Semgrep
        uses: semgrep/semgrep-action@v1
        with:
          config: >-
            p/owasp-top-ten
            p/docker

  build-and-push:
    needs: sast
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Build image Docker
        run: docker build -t ${{ env.IMAGE_NAME }}:${{ github.sha }} .
        
      - name: Scan image avec Trivy
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: ${{ env.IMAGE_NAME }}:${{ github.sha }}
          format: 'sarif'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'

  deploy:
    needs: build-and-push
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.VPS_HOST }}
          username: ${{ secrets.VPS_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            docker pull ${{ env.IMAGE_NAME }}:${{ github.sha }}
            docker compose up -d --no-deps app

Les éléments clés

1. SAST (Static Application Security Testing)

J'ai utilisé Semgrep avec les rulesets OWASP Top 10 et Docker. Il détecte notamment :

• Les secrets hardcodés dans le code
• Les injections SQL potentielles
• Les mauvaises pratiques Docker (USER root, etc.)

2. Scan d'image Docker avec Trivy

Avant tout déploiement, Trivy scanne l'image Docker pour détecter les CVE connues dans les dépendances. Le pipeline échoue si une vulnérabilité CRITICAL ou HIGH est détectée.

3. Environnements GitHub avec approbation manuelle

Pour la production, j'ai configuré un environnement protégé dans GitHub qui requiert une approbation manuelle. Simple mais efficace.

Durcissement du VPS Linux

En parallèle du pipeline, j'ai durci le VPS de déploiement :

• Désactivation de l'accès root SSH — uniquement clés SSH
• fail2ban pour bloquer les tentatives de brute force
• UFW avec règles minimales (80, 443, 22 uniquement depuis IPs connues)
• ModSecurity comme WAF devant Nginx

Résultats

• 0 secret leakés depuis la mise en place
• Délai de détection des vulnérabilités : build-time au lieu de post-déploiement
• Conformité automatique avec les standards OWASP

Conclusion

La sécurité dans le CI/CD n'est pas une contrainte — c'est un filet de sécurité automatisé qui vous évite les cauchemars en production. Le coût en temps de setup (quelques heures) vaut largement la tranquillité d'esprit.

Article basé sur mon expérience chez Bifora Data Consulting (2026).