Sécurité DevSecOps : Intégrer la Sécurité dans le CI/CD

# .github/workflows/sonarqube.yml
name: SonarQube Analysis
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  sonarqube:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Set up JDK 17
        uses: actions/setup-java@v4
        with:
          java-version: 17
          distribution: temurin

      - name: Cache SonarQube packages
        uses: actions/cache@v4
        with:
          path: ~/.sonar/cache
          key: ${{ runner.os }}-sonar

      - name: Build and analyze
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
          SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
        run: |
          mvn clean verify sonar:sonar 
            -Dsonar.projectKey=mon-projet 
            -Dsonar.qualitygate.wait=true 
            -Dsonar.coverage.jacoco.xmlReportPaths=target/site/jacoco/jacoco.xml

# .semgrep/custom-rules.yml
rules:
  - id: dangerous-eval-usage
    patterns:
      - pattern: eval($INPUT)
      - pattern-not: eval("literal_string")
    message: |
      Utilisation dangereuse de eval() avec une entree potentiellement
      non fiable. Cela peut mener a une execution de code arbitraire (RCE).
      Utilisez ast.literal_eval() pour les cas legitimes.
    severity: ERROR
    languages: [python]
    metadata:
      cwe:
        - CWE-95
      owasp:
        - A03:2021
      confidence: HIGH

# .github/workflows/semgrep.yml
name: Semgrep Security Scan
on:
  pull_request: {}
  push:
    branches: [main]

jobs:
  semgrep:
    runs-on: ubuntu-latest
    container:
      image: semgrep/semgrep
    steps:
      - uses: actions/checkout@v4
      - run: semgrep ci
        env:
          SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_APP_TOKEN }}
          # Ou en mode local avec des regles specifiques :
          # semgrep scan --config=p/owasp-top-ten --config=p/security-audit --error

# .github/workflows/codeql.yml
name: CodeQL Analysis
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
  schedule:
    - cron: '30 1 * * 1'  # Analyse hebdomadaire le lundi

jobs:
  analyze:
    runs-on: ubuntu-latest
    permissions:
      actions: read
      contents: read
      security-events: write
    strategy:
      matrix:
        language: [javascript, python]
    steps:
      - uses: actions/checkout@v4
      - name: Initialize CodeQL
        uses: github/codeql-action/init@v3
        with:
          languages: ${{ matrix.language }}
          queries: +security-and-quality
      - name: Autobuild
        uses: github/codeql-action/autobuild@v3
      - name: Perform CodeQL Analysis
        uses: github/codeql-action/analyze@v3
        with:
          category: "/language:${{ matrix.language }}"

4.1 Le risque des dependances open source

Les applications modernes reposent massivement sur des composants open source. Selon les etudes de Synopsys (rapport OSSRA 2025), 96% des applications commerciales contiennent du code open source, et celui-ci represente en moyenne 77% de la base de code totale. Un projet Node.js typique peut dependre de centaines, voire de milliers de packages npm, dont la majorite sont des dependances transitives (dependances de dependances) que les developpeurs ne connaissent meme pas.

Cette dependance massive a l'open source cree une surface d'attaque considerable. L'incident Log4Shell (CVE-2021-44228) a illustre de maniere spectaculaire les consequences d'une vulnerabilite critique dans une dependance largement utilisee. La bibliotheque Log4j etait presente dans des millions d'applications Java sans que leurs developpeurs en soient necessairement conscients. Plus recemment, des attaques de type typosquatting et dependency confusion ciblent directement les registres de packages pour injecter du code malveillant.

4.2 Snyk : la plateforme SCA orientee developpeur

Snyk est devenu l'un des leaders du marche SCA grace a son approche centree sur l'experience developpeur. La plateforme propose non seulement la detection de vulnerabilites dans les dependances, mais aussi des suggestions de remediation automatisees, incluant la version minimale a laquelle mettre a jour pour corriger une faille sans casser la compatibilite.

L'integration de Snyk dans un pipeline CI/CD peut se faire de plusieurs manieres. Voici un exemple avec GitHub Actions :

# .github/workflows/snyk.yml
name: Snyk Security Scan
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  snyk-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run Snyk to check for vulnerabilities
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: >
            --severity-threshold=high
            --fail-on=upgradable
            --json-file-output=snyk-results.json

      - name: Upload Snyk results to GitHub Code Scanning
        if: always()
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: snyk-results.json

La commande snyk test --severity-threshold=high --fail-on=upgradable configure le scan pour n'echouer que sur les vulnerabilites de severite elevee ou critique qui disposent d'une mise a jour corrective. Cela evite de bloquer le pipeline pour des vulnerabilites mineures ou sans correctif disponible, tout en maintenant un niveau de securite eleve.

Snyk propose egalement la commande snyk monitor qui prend un instantane des dependances et surveille l'apparition de nouvelles vulnerabilites, meme apres le deploiement. Cela permet d'etre alerte si une dependance utilisee en production est affectee par une nouvelle CVE.

4.3 Dependabot : l'automatisation native GitHub

Dependabot est l'outil de gestion des dependances integre nativement dans GitHub. Il surveille automatiquement les dependances declarees dans les fichiers de manifeste (package.json, pom.xml, requirements.txt, go.mod, Gemfile, etc.) et cree des pull requests automatiques lorsqu'une mise a jour de securite ou une nouvelle version est disponible.

La configuration de Dependabot se fait via un fichier .github/dependabot.yml a la racine du depot :

# .github/dependabot.yml
version: 2
updates:
  # Dependencies npm
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    open-pull-requests-limit: 10
    reviewers:
      - "security-team"
    labels:
      - "dependencies"
      - "security"
    ignore:
      - dependency-name: "lodash"
        versions: ["4.x"]
    groups:
      dev-dependencies:
        dependency-type: "development"
        update-types:
          - "minor"
          - "patch"

  # Images Docker
  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "weekly"

  # GitHub Actions
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

  # Dependencies Python
  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "daily"
    open-pull-requests-limit: 5

4.4 OWASP Dependency-Check

OWASP Dependency-Check est un outil open source et gratuit qui identifie les composants avec des vulnerabilites connues en les correlant avec la base de donnees NVD (National Vulnerability Database) du NIST. Contrairement a Snyk qui utilise sa propre base de vulnerabilites, Dependency-Check s'appuie principalement sur les CPE (Common Platform Enumeration) et les CVE publiques.

Voici un exemple d'integration dans un pipeline GitLab CI :

# .gitlab-ci.yml (extrait)
dependency-check:
  stage: security
  image: owasp/dependency-check:latest
  script:
    - /usr/share/dependency-check/bin/dependency-check.sh
      --project "MonProjet"
      --scan /builds/$CI_PROJECT_PATH
      --format HTML
      --format JSON
      --out dependency-check-report
      --failOnCVSS 7
      --enableExperimental
      --nvdApiKey $NVD_API_KEY
  artifacts:
    paths:
      - dependency-check-report/
    when: always
    expire_in: 7 days
  allow_failure: false

Le parametre --failOnCVSS 7 fait echouer le pipeline si une dependance presente une vulnerabilite avec un score CVSS superieur ou egal a 7 (severite elevee ou critique). Le parametre --nvdApiKey est recommande pour eviter les limitations de taux de l'API NVD publique.

Chapitre 5 : Securite des conteneurs et images Docker

5.1 Les vecteurs d'attaque sur les conteneurs

Les conteneurs Docker presentent des vecteurs d'attaque specifiques que les equipes DevSecOps doivent maitriser. L'image de base peut contenir des vulnerabilites dans les packages systeme (libc, openssl, curl). Les dependances applicatives ajoutees lors du build peuvent introduire des failles. Le Dockerfile lui-meme peut creer des faiblesses : execution en tant que root, exposition de secrets dans les couches de l'image, ports inutilement ouverts, absence de healthcheck. Enfin, la configuration du runtime (privileges, capabilities, montage de volumes) peut compromettre l'isolation du conteneur.

En 2025, les registres de conteneurs publics comme Docker Hub contiennent des millions d'images, dont une proportion significative presente des vulnerabilites critiques. Selon les analyses de Sysdig, plus de 75% des images en production contiennent des vulnerabilites de severite elevee ou critique. Cette realite impose un scan systematique des images a chaque etape : build, push vers le registre et deploiement.

5.2 Trivy : le scanner de securite polyvalent

Trivy, developpe par Aqua Security, est devenu le scanner de securite de conteneurs le plus populaire grace a sa polyvalence et sa facilite d'utilisation. Il detecte les vulnerabilites dans les packages OS et applicatifs, les erreurs de configuration, les secrets exposes et meme les problemes dans les fichiers d'Infrastructure as Code. Trivy supporte de multiples cibles : images Docker, systemes de fichiers, depots Git et clusters Kubernetes.

Un scan basique d'image Docker avec Trivy :

# Scan d'une image avec filtrage par severite
trivy image --severity HIGH,CRITICAL --exit-code 1 nginx:latest

# Scan avec generation d'un rapport SARIF pour GitHub
trivy image --format sarif --output trivy-results.sarif mon-registre/mon-app:v1.2.3

# Scan du filesystem local (utile dans le pipeline avant le build Docker)
trivy fs --security-checks vuln,secret,config .

# Scan d'un fichier Dockerfile pour les misconfiguration
trivy config --severity HIGH,CRITICAL ./Dockerfile

Integration complete dans un pipeline GitHub Actions avec cache et rapport :

# .github/workflows/trivy.yml
name: Container Security Scan
on:
  push:
    branches: [main]
  pull_request:

jobs:
  trivy-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

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

      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: mon-app:${{ github.sha }}
          format: table
          exit-code: 1
          severity: CRITICAL,HIGH
          ignore-unfixed: true

      - name: Run Trivy (SARIF report)
        if: always()
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: mon-app:${{ github.sha }}
          format: sarif
          output: trivy-results.sarif

      - name: Upload Trivy scan results
        if: always()
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: trivy-results.sarif

5.3 Durcissement des Dockerfiles

Un Dockerfile securise suit plusieurs principes fondamentaux. Voici un exemple complet d'un Dockerfile durci pour une application Node.js :

# Dockerfile durci - Application Node.js
# Etape 1 : Build avec multi-stage
FROM node:20-alpine AS builder

# Creer un utilisateur non-root pour le build
RUN addgroup -g 1001 -S appgroup && 
    adduser -S appuser -u 1001 -G appgroup

WORKDIR /app

# Copier uniquement les fichiers de dependances d'abord (cache Docker)
COPY --chown=appuser:appgroup package.json package-lock.json ./

# Installer les dependances avec audit
RUN npm ci --only=production --audit-level=high && 
    npm cache clean --force

# Copier le code source
COPY --chown=appuser:appgroup src/ ./src/

# Etape 2 : Image de production minimale
FROM node:20-alpine AS production

# Mettre a jour les packages systeme
RUN apk update && apk upgrade --no-cache && 
    apk add --no-cache dumb-init && 
    rm -rf /var/cache/apk/*

# Creer un utilisateur non-root
RUN addgroup -g 1001 -S appgroup && 
    adduser -S appuser -u 1001 -G appgroup

WORKDIR /app

# Copier uniquement les artefacts necessaires depuis le builder
COPY --from=builder --chown=appuser:appgroup /app/node_modules ./node_modules
COPY --from=builder --chown=appuser:appgroup /app/src ./src
COPY --from=builder --chown=appuser:appgroup /app/package.json ./

# Configurer le filesystem en lecture seule
RUN chmod -R 555 /app

# Basculer vers l'utilisateur non-root
USER appuser

# Exposer uniquement le port necessaire
EXPOSE 3000

# Healthcheck
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 
  CMD node -e "require('http').get('http://localhost:3000/health', (r) => { process.exit(r.statusCode === 200 ? 0 : 1) })"

# Utiliser dumb-init pour gerer les signaux proprement
ENTRYPOINT ["dumb-init", "--"]
CMD ["node", "src/server.js"]

5.4 Grype et la generation de SBOM avec Syft

Grype est le scanner de vulnerabilites d'Anchore, souvent utilise en combinaison avec Syft pour la generation de SBOM (Software Bill of Materials). Syft analyse une image Docker et genere un inventaire complet de tous les composants logiciels qu'elle contient. Grype utilise ensuite ce SBOM pour identifier les vulnerabilites connues.

# Generer un SBOM avec Syft
syft mon-app:latest -o spdx-json > sbom.spdx.json
syft mon-app:latest -o cyclonedx-json > sbom.cdx.json

# Scanner le SBOM avec Grype
grype sbom:sbom.cdx.json --fail-on high

# Scan direct d'une image
grype mon-registre/mon-app:v1.2.3 --only-fixed --fail-on critical

La generation systematique de SBOM est devenue une exigence reglementaire dans de nombreux contextes. L'Executive Order 14028 aux Etats-Unis et les recommandations de l'ANSSI en France imposent de plus en plus la transparence sur les composants logiciels utilises. Les formats standards sont SPDX (ISO/IEC 5962:2021) et CycloneDX (OWASP).

Chapitre 6 : Tests dynamiques et interactifs - DAST et IAST

6.1 Comprendre le DAST

Le DAST (Dynamic Application Security Testing) est une methodologie de test qui analyse une application en cours d'execution pour identifier des vulnerabilites exploitables. Contrairement au SAST qui examine le code source, le DAST interagit avec l'application comme le ferait un attaquant, en envoyant des requetes HTTP malformees, en injectant des payloads d'attaque et en analysant les reponses pour detecter des comportements anormaux.

Le DAST est particulierement efficace pour detecter les vulnerabilites liees a la configuration du serveur, les problemes d'authentification et d'autorisation, les failles d'injection qui ne sont pas detectables par analyse statique (par exemple lorsque l'injection passe par un composant tiers), les problemes de gestion de session et les headers de securite manquants. Son principal avantage est qu'il teste l'application dans des conditions reelles, incluant l'interaction entre tous les composants (frontend, backend, base de donnees, services tiers).

6.2 OWASP ZAP : le scanner DAST open source de reference

OWASP ZAP (Zed Attack Proxy) est le scanner DAST open source le plus utilise au monde. Maintenu par la communaute OWASP, il offre un ensemble complet de fonctionnalites : spider pour la decouverte automatique des URLs, scan passif pour la detection de problemes sans envoi de payloads d'attaque, scan actif avec injection de payloads pour les principales categories de vulnerabilites, et support des APIs REST et GraphQL.

L'integration de ZAP dans un pipeline CI/CD s'effectue typiquement via l'image Docker officielle et les scripts d'automatisation fournis :

# .github/workflows/zap-scan.yml
name: OWASP ZAP DAST Scan
on:
  push:
    branches: [main]

jobs:
  zap-scan:
    runs-on: ubuntu-latest
    services:
      app:
        image: mon-app:latest
        ports:
          - 8080:8080

    steps:
      - uses: actions/checkout@v4

      - name: ZAP Baseline Scan
        uses: zaproxy/action-baseline@v0.12.0
        with:
          target: "http://localhost:8080"
          rules_file_name: "zap-rules.tsv"
          cmd_options: >
            -a
            -j
            -l WARN
            -z "-config alert.maxInstances=10"

      - name: ZAP Full Scan (hebdomadaire)
        if: github.event.schedule
        uses: zaproxy/action-full-scan@v0.10.0
        with:
          target: "http://localhost:8080"
          cmd_options: "-a -j"

      - name: Upload ZAP Report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: zap-report
          path: report_html.html

Pour les APIs, ZAP peut importer une specification OpenAPI (Swagger) et scanner automatiquement tous les endpoints documentes :

# Scan d'API avec ZAP en ligne de commande
docker run --rm -v $(pwd):/zap/wrk/:rw 
  -t ghcr.io/zaproxy/zaproxy:stable 
  zap-api-scan.py 
    -t http://api.example.com/openapi.json 
    -f openapi 
    -r api-scan-report.html 
    -w api-scan-report.md 
    -J api-scan-report.json 
    -l WARN 
    -c zap-api-rules.conf

6.3 Nuclei : le scanner oriente templates

Nuclei, developpe par ProjectDiscovery, est un scanner de vulnerabilites rapide et extensible base sur des templates YAML. Sa force reside dans sa communaute qui maintient des milliers de templates couvrant les CVE recentes, les erreurs de configuration courantes et les technologies specifiques. Nuclei est particulierement utile pour les scans cibles et les verifications de conformite.

# Scan basique avec les templates par defaut
nuclei -u https://mon-app.example.com -severity critical,high

# Scan avec des templates specifiques
nuclei -u https://mon-app.example.com 
  -t cves/ 
  -t misconfigurations/ 
  -t exposed-panels/ 
  -severity critical,high,medium 
  -output nuclei-results.json 
  -jsonl

# Scan de plusieurs cibles depuis un fichier
nuclei -l targets.txt -t technologies/ -severity high,critical

6.4 IAST : la convergence SAST et DAST

L'IAST (Interactive Application Security Testing) combine les avantages du SAST et du DAST en instrumentant l'application avec un agent qui observe le comportement du code en temps reel pendant les tests fonctionnels. L'agent IAST suit le flux de donnees depuis l'entree utilisateur jusqu'aux operations sensibles (requetes SQL, acces fichiers, commandes systeme) et detecte les vulnerabilites avec un contexte complet, incluant la ligne de code exacte responsable.

L'avantage principal de l'IAST est son taux de faux positifs extremement bas (generalement inferieur a 5%) compare au SAST (qui peut atteindre 40-60% de faux positifs). Contrast Security est le leader du marche IAST, avec des agents disponibles pour Java, .NET, Node.js, Python et Ruby. L'instrumentation se fait simplement en ajoutant l'agent au runtime de l'application :

# Integration de Contrast Security en Java
java -javaagent:/opt/contrast/contrast-agent.jar 
  -Dcontrast.api.url=https://app.contrastsecurity.com 
  -Dcontrast.api.api_key=${CONTRAST_API_KEY} 
  -Dcontrast.api.service_key=${CONTRAST_SERVICE_KEY} 
  -Dcontrast.api.user_name=${CONTRAST_USERNAME} 
  -jar mon-application.jar

# Dans un Dockerfile
ENV JAVA_TOOL_OPTIONS="-javaagent:/opt/contrast/contrast-agent.jar"

Chapitre 7 : Infrastructure as Code securisee

7.1 Les risques de l'Infrastructure as Code non auditee

L'Infrastructure as Code (IaC) a transforme la gestion de l'infrastructure en permettant de definir et de provisionner des ressources cloud via des fichiers de configuration versionnees. Terraform, Ansible, CloudFormation, Pulumi et les manifestes Kubernetes sont devenus des composants essentiels des pipelines de deploiement modernes. Cependant, une configuration IaC mal securisee peut exposer l'organisation a des risques majeurs.

Les erreurs de configuration cloud (cloud misconfiguration) sont responsables de certaines des plus grandes breches de donnees de ces dernieres annees. Un bucket S3 rendu public par erreur, un security group autorisant l'acces SSH depuis n'importe quelle adresse IP, un cluster Kubernetes avec un RBAC trop permissif ou une base de donnees accessible depuis Internet sans chiffrement : ces erreurs, triviales en apparence, peuvent avoir des consequences desastreuses. Selon Gartner, d'ici 2025, 99% des failles de securite cloud seront imputables au client et non au fournisseur cloud.

7.2 Checkov : l'analyseur IaC de reference

Checkov, developpe par Bridgecrew (acquis par Palo Alto Networks / Prisma Cloud), est l'outil d'analyse IaC le plus complet. Il supporte Terraform, CloudFormation, Kubernetes, Helm, Dockerfile, Ansible et d'autres formats. Avec plus de 1000 regles integrees couvrant les benchmarks CIS, les bonnes pratiques AWS/Azure/GCP et les exigences de conformite (SOC2, HIPAA, PCI-DSS), Checkov fournit une couverture exhaustive.

# Installation
pip install checkov

# Scan d'un repertoire Terraform
checkov -d ./terraform/ --framework terraform --output cli --output json

# Scan avec baseline (ignorer les problemes connus acceptes)
checkov -d ./terraform/ --baseline .checkov.baseline

# Scan specifique aux regles CIS AWS
checkov -d ./terraform/ --check CKV_AWS_18,CKV_AWS_19,CKV_AWS_20

# Integration dans GitHub Actions
# .github/workflows/checkov.yml
name: Checkov IaC Scan
on:
  pull_request:
    paths:
      - 'terraform/**'
      - 'kubernetes/**'

jobs:
  checkov:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Checkov
        uses: bridgecrewio/checkov-action@master
        with:
          directory: terraform/
          framework: terraform
          output_format: sarif
          soft_fail: false
          skip_check: CKV_AWS_999  # Skip specific check if needed

Voici un exemple concret de configuration Terraform securisee pour un bucket S3, montrant les bonnes pratiques que Checkov verifie :

# terraform/s3.tf - Configuration securisee
resource "aws_s3_bucket" "data" {
  bucket = "mon-projet-data-${var.environment}"

  tags = {
    Environment = var.environment
    ManagedBy   = "terraform"
    Security    = "confidential"
  }
}

# Bloquer tout acces public
resource "aws_s3_bucket_public_access_block" "data" {
  bucket = aws_s3_bucket.data.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

# Activer le chiffrement cote serveur
resource "aws_s3_bucket_server_side_encryption_configuration" "data" {
  bucket = aws_s3_bucket.data.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.s3_key.arn
    }
    bucket_key_enabled = true
  }
}

# Activer le versioning
resource "aws_s3_bucket_versioning" "data" {
  bucket = aws_s3_bucket.data.id
  versioning_configuration {
    status = "Enabled"
  }
}

# Activer les logs d'acces
resource "aws_s3_bucket_logging" "data" {
  bucket = aws_s3_bucket.data.id

  target_bucket = aws_s3_bucket.logs.id
  target_prefix = "s3-access-logs/data/"
}

7.3 tfsec : l'analyse Terraform specialisee

tfsec, developpe par Aqua Security, est un analyseur statique specialise pour Terraform. Bien que Checkov couvre egalement Terraform, tfsec se distingue par sa rapidite d'execution et sa capacite a resoudre les references entre modules Terraform, offrant une analyse plus precise du contexte. tfsec a ete integre dans Trivy depuis la version 0.40, ce qui permet de l'utiliser via la meme commande :

# Scan avec tfsec (standalone)
tfsec ./terraform/ --format json --out tfsec-results.json

# Scan avec Trivy (tfsec integre)
trivy config --severity HIGH,CRITICAL ./terraform/

# Scan avec exclusion de regles specifiques
tfsec ./terraform/ --exclude-downloaded-modules --minimum-severity HIGH

# Integration GitLab CI
iac-security:
  stage: security
  image: aquasec/tfsec:latest
  script:
    - tfsec ./terraform/
      --format junit
      --out tfsec-report.xml
      --minimum-severity HIGH
  artifacts:
    reports:
      junit: tfsec-report.xml

7.4 OPA et Rego : les politiques de securite personnalisees

Open Policy Agent (OPA) est un moteur de politiques generique qui permet de definir des regles de securite personnalisees en langage Rego. OPA est particulierement utile lorsque les regles integrees des outils comme Checkov ou tfsec ne couvrent pas vos exigences specifiques, ou lorsque vous souhaitez appliquer des politiques d'entreprise uniformes sur l'ensemble de votre IaC.

# policy/terraform/s3_security.rego
package terraform.s3

# Verifier que tous les buckets S3 ont le chiffrement active
deny[msg] {
  resource := input.resource.aws_s3_bucket[name]
  not has_encryption(name)
  msg := sprintf("Le bucket S3 '%s' n'a pas de chiffrement configure", [name])
}

has_encryption(bucket_name) {
  input.resource.aws_s3_bucket_server_side_encryption_configuration[_].bucket == bucket_name
}

# Verifier que le versioning est active
deny[msg] {
  resource := input.resource.aws_s3_bucket[name]
  not has_versioning(name)
  msg := sprintf("Le bucket S3 '%s' n'a pas le versioning active", [name])
}

has_versioning(bucket_name) {
  config := input.resource.aws_s3_bucket_versioning[_]
  config.bucket == bucket_name
  config.versioning_configuration[_].status == "Enabled"
}

Chapitre 8 : Pipeline CI/CD securise - GitHub Actions, GitLab CI, Jenkins

8.1 Securisation du pipeline lui-meme

Le pipeline CI/CD est une cible de choix pour les attaquants car il dispose d'acces privilegies : il peut lire le code source, acceder aux secrets (tokens API, credentials de base de donnees, cles de signature), construire et deployer des artefacts en production. La compromission d'un pipeline CI/CD peut permettre a un attaquant d'injecter du code malveillant directement dans les artefacts de production, comme l'a demontre l'attaque SolarWinds.

La securisation du pipeline commence par le principe du moindre privilege. Chaque job du pipeline ne doit avoir acces qu'aux secrets et aux permissions strictement necessaires a son execution. Les tokens d'acces doivent avoir une duree de vie limitee et des permissions restreintes. Les runners CI/CD doivent etre ephemeres (detruits apres chaque execution) pour eviter la persistance d'un compromis.

8.2 Gestion des secrets dans le pipeline

La gestion des secrets est l'un des aspects les plus critiques de la securite CI/CD. Les secrets (tokens API, mots de passe de base de donnees, cles de chiffrement, certificats) ne doivent jamais apparaitre en clair dans le code source, les fichiers de configuration ou les logs du pipeline.

Plusieurs solutions existent pour gerer les secrets de maniere securisee :

Secrets natifs de la plateforme CI : GitHub Encrypted Secrets, GitLab CI/CD Variables (masked + protected), Jenkins Credentials Store. Ces solutions sont simples a installer mais limitees en fonctionnalites (pas de rotation automatique, pas d'audit detaille).

HashiCorp Vault : la solution de reference pour la gestion centralisee des secrets. Vault offre la generation dynamique de credentials, la rotation automatique, l'audit detaille de chaque acces et l'integration avec de nombreuses plateformes. Exemple d'utilisation dans GitHub Actions :

# Utilisation de Vault dans GitHub Actions
jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - name: Import secrets from Vault
        uses: hashicorp/vault-action@v3
        with:
          url: https://vault.example.com
          method: jwt
          role: github-actions-role
          secrets: |
            secret/data/production/db password | DB_PASSWORD ;
            secret/data/production/api token | API_TOKEN

      - name: Deploy with secrets
        run: |
          # Les secrets sont disponibles comme variables d'environnement
          # Ils sont automatiquement masques dans les logs
          ./deploy.sh

Detection de secrets dans le code : des outils comme gitleaks, trufflehog ou detect-secrets doivent etre integres en pre-commit hook et dans le pipeline pour empecher la publication accidentelle de secrets :

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks

# Pipeline GitHub Actions pour gitleaks
- name: Scan for secrets
  uses: gitleaks/gitleaks-action@v2
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE }}

8.3 Signature des artefacts et SLSA

La signature cryptographique des artefacts (images Docker, binaires, packages) garantit leur integrite et leur provenance. Le framework SLSA (Supply-chain Levels for Software Artifacts), developpe par Google, definit des niveaux de maturite pour la securisation de la chaine d'approvisionnement logicielle.

Cosign, faisant partie du projet Sigstore, est l'outil de reference pour signer les images de conteneurs. Il supporte la signature sans cle (keyless signing) via les identites OIDC, ce qui elimine le besoin de gerer des cles privees :

# Signature keyless avec Cosign et Sigstore
# Le developpeur s'authentifie via OIDC (GitHub, Google, etc.)
cosign sign --yes mon-registre/mon-app:v1.2.3

# Verification de la signature
cosign verify 
  --certificate-identity=deployer@example.com 
  --certificate-oidc-issuer=https://accounts.google.com 
  mon-registre/mon-app:v1.2.3

# Attacher un SBOM a l'image signee
cosign attach sbom --sbom sbom.cdx.json mon-registre/mon-app:v1.2.3

# Generer une attestation SLSA dans GitHub Actions
- name: Generate SLSA provenance
  uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v2.0.0
  with:
    image: mon-registre/mon-app
    digest: ${{ steps.build.outputs.digest }}

8.4 Pipeline DevSecOps complet : exemple de reference

Voici un exemple de pipeline GitHub Actions complet integrant l'ensemble des controles de securite decrits dans ce livre blanc :

# .github/workflows/devsecops-pipeline.yml
name: DevSecOps Pipeline
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

env:
  IMAGE_NAME: ghcr.io/${{ github.repository }}
  IMAGE_TAG: ${{ github.sha }}

jobs:
  # Etape 1 : Analyse statique du code (SAST)
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Semgrep SAST scan
        uses: semgrep/semgrep-action@v1
        with:
          config: >
            p/owasp-top-ten
            p/security-audit
            p/secrets

      - name: SonarQube scan
        uses: SonarSource/sonarqube-scan-action@v3
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
          SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}

  # Etape 2 : Analyse des dependances (SCA)
  sca:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

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

      - name: License compliance check
        run: |
          npx license-checker --failOn "GPL-3.0;AGPL-3.0"

  # Etape 3 : Build et scan de l'image Docker
  build-and-scan:
    needs: [sast, sca]
    runs-on: ubuntu-latest
    outputs:
      digest: ${{ steps.build.outputs.digest }}
    steps:
      - uses: actions/checkout@v4

      - name: Build Docker image
        id: build
        run: |
          docker build -t $IMAGE_NAME:$IMAGE_TAG .
          DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' $IMAGE_NAME:$IMAGE_TAG || echo "$IMAGE_TAG")
          echo "digest=$DIGEST" >> $GITHUB_OUTPUT

      - name: Trivy vulnerability scan
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: ${{ env.IMAGE_NAME }}:${{ env.IMAGE_TAG }}
          format: sarif
          output: trivy-results.sarif
          severity: CRITICAL,HIGH
          exit-code: 1

      - name: Generate SBOM
        run: |
          syft $IMAGE_NAME:$IMAGE_TAG -o cyclonedx-json > sbom.cdx.json

      - name: Sign image with Cosign
        if: github.ref == 'refs/heads/main'
        run: |
          cosign sign --yes $IMAGE_NAME@${{ steps.build.outputs.digest }}
          cosign attach sbom --sbom sbom.cdx.json $IMAGE_NAME@${{ steps.build.outputs.digest }}

  # Etape 4 : Analyse IaC
  iac-security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Checkov IaC scan
        uses: bridgecrewio/checkov-action@master
        with:
          directory: terraform/
          soft_fail: false

  # Etape 5 : DAST en staging
  dast:
    needs: [build-and-scan]
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to staging
        run: ./scripts/deploy-staging.sh

      - name: OWASP ZAP scan
        uses: zaproxy/action-baseline@v0.12.0
        with:
          target: "https://staging.example.com"

  # Etape 6 : Deploiement production
  deploy:
    needs: [build-and-scan, iac-security, dast]
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: Verify image signature
        run: |
          cosign verify 
            --certificate-identity-regexp=".*@example.com" 
            --certificate-oidc-issuer=https://token.actions.githubusercontent.com 
            $IMAGE_NAME@${{ needs.build-and-scan.outputs.digest }}

      - name: Deploy to production
        run: ./scripts/deploy-production.sh

Chapitre 9 : Monitoring de securite en production

9.1 La derniere ligne de defense

Malgre tous les controles de securite mis en place dans le pipeline CI/CD, des vulnerabilites peuvent passer en production. Des zero-days non encore detectes par les outils SAST/SCA, des erreurs de configuration specifiques a l'environnement de production, des attaques ciblant la logique metier plutot que des failles techniques : les raisons sont multiples. Le monitoring de securite en production constitue donc la derniere ligne de defense, essentielle pour detecter et bloquer les attaques en temps reel.

La strategie de monitoring de securite en production repose sur trois piliers complementaires : le WAF (Web Application Firewall) qui filtre le trafic malveillant en amont, le RASP (Runtime Application Self-Protection) qui protege l'application de l'interieur, et l'observabilite de securite qui fournit la visibilite necessaire pour detecter les comportements anormaux et investiguer les incidents.

9.2 Web Application Firewall (WAF)

Un WAF analyse le trafic HTTP/HTTPS entrant et bloque les requetes malveillantes avant qu'elles n'atteignent l'application. Les WAF modernes utilisent une combinaison de regles de signature (detection de patterns d'attaque connus), d'analyse comportementale (detection d'anomalies dans les patterns de trafic) et d'intelligence artificielle pour minimiser les faux positifs tout en maximisant la detection.

Les principales solutions WAF incluent les WAF cloud natifs (AWS WAF, Azure WAF, Cloudflare WAF, Fastly WAF), les WAF open source (ModSecurity avec le Core Rule Set OWASP) et les WAF applicatifs (Imperva, F5). Le choix depend de l'architecture, du budget et des exigences de conformite.

Exemple de configuration ModSecurity avec le Core Rule Set OWASP dans un reverse proxy Nginx :

# nginx.conf avec ModSecurity
load_module modules/ngx_http_modsecurity_module.so;

http {
    modsecurity on;
    modsecurity_rules_file /etc/modsecurity/modsecurity.conf;

    server {
        listen 443 ssl;
        server_name app.example.com;

        location / {
            modsecurity_rules '
                SecRuleEngine On
                SecAuditLog /var/log/modsecurity/audit.log
                SecAuditLogType Serial
                Include /etc/modsecurity/crs/crs-setup.conf
                Include /etc/modsecurity/crs/rules/*.conf

                # Regles personnalisees
                SecRule REQUEST_HEADERS:Content-Type "text/xml" 
                    "id:1001,phase:1,deny,status:403,msg:'XML content type blocked'"
            ';
            proxy_pass http://backend;
        }
    }
}

9.3 RASP : la protection runtime

Le RASP (Runtime Application Self-Protection) est une technologie qui s'integre directement dans l'application via un agent ou un module. Contrairement au WAF qui analyse le trafic reseau, le RASP observe le comportement de l'application de l'interieur et peut bloquer les attaques au niveau du code, avec un contexte complet sur la requete, le flux de donnees et l'operation ciblee.

Le RASP est particulierement efficace contre les attaques zero-day car il ne depend pas de signatures connues mais observe si une operation dangereuse (execution de commande systeme, acces fichier inattendu, requete SQL anormale) est declenchee par une entree utilisateur. Par exemple, si une requete HTTP provoque l'execution de Runtime.exec() en Java, le RASP peut bloquer l'appel et alerter l'equipe de securite.

Contrast Protect est le leader du marche RASP. Son integration en Java est transparente :

# Deploiement de Contrast Protect en production
java -javaagent:/opt/contrast/contrast-agent.jar 
  -Dcontrast.mode=protect 
  -Dcontrast.protect.rules.sql-injection=block 
  -Dcontrast.protect.rules.cmd-injection=block 
  -Dcontrast.protect.rules.path-traversal=block 
  -Dcontrast.protect.rules.xxe=block 
  -Dcontrast.protect.rules.untrusted-deserialization=block 
  -jar mon-application.jar

9.4 Observabilite de securite

L'observabilite de securite va au-dela du monitoring traditionnel en combinant les trois piliers de l'observabilite (logs, metriques, traces) avec un focus specifique sur les evenements de securite. L'objectif est de pouvoir detecter les attaques en cours, investiguer les incidents et repondre efficacement aux compromissions.

Logs de securite structures : les logs applicatifs doivent inclure les evenements de securite pertinents (tentatives d'authentification echouees, erreurs d'autorisation, inputs rejetes par la validation, exceptions de securite) dans un format structure (JSON) facilitant l'analyse automatisee :

// Exemple de log de securite structure (JSON)
{
  "timestamp": "2026-03-11T14:30:00.000Z",
  "level": "WARN",
  "event": "authentication.failed",
  "source_ip": "192.168.1.100",
  "user_agent": "Mozilla/5.0...",
  "username": "admin",
  "reason": "invalid_password",
  "attempt_count": 5,
  "geo": {
    "country": "FR",
    "city": "Paris"
  },
  "correlation_id": "req-abc123",
  "security_context": {
    "risk_score": 85,
    "indicators": ["brute_force_suspected", "unusual_geo"]
  }
}

Metriques de securite : des metriques cles doivent etre collectees et visualisees en temps reel : taux de requetes bloquees par le WAF, nombre de tentatives d'authentification echouees par intervalle, temps de reponse anormaux pouvant indiquer une attaque, taux d'erreurs 4xx/5xx par endpoint, utilisation CPU/memoire anormale pouvant indiquer un cryptomining.

Alerting intelligent : les alertes doivent etre configurees pour detecter les patterns d'attaque sans generer de fatigue d'alerte. Les mecanismes de detection doivent inclure des seuils dynamiques (baselines comportementales), des correlations multi-sources et des playbooks de reponse automatisee.

9.5 Reponse aux incidents

La reponse aux incidents de securite doit etre preparee, documentee et testee regulierement. Un plan de reponse aux incidents (IRP - Incident Response Plan) definit les roles et responsabilites, les procedures de detection, de confinement, d'eradication et de retour a la normale, ainsi que les canaux de communication internes et externes.

Dans un contexte DevSecOps, la reponse aux incidents s'appuie sur l'automatisation. Les playbooks de reponse automatisee peuvent inclure : le blocage automatique d'une adresse IP apres N tentatives d'intrusion, le rollback automatique d'un deploiement si des anomalies de securite sont detectees, l'isolation automatique d'un conteneur compromis, la rotation automatique des secrets potentiellement exposes et la notification automatique des equipes via les canaux Slack/Teams dedies.

# Exemple de playbook de reponse automatisee (pseudo-code)
# Script de reponse aux tentatives de brute force
#!/bin/bash
# auto-response-bruteforce.sh

THRESHOLD=10
TIMEFRAME="5m"

# Detecter les IPs avec trop de tentatives echouees
OFFENDING_IPS=$(curl -s "http://elasticsearch:9200/security-logs/_search" 
  -H "Content-Type: application/json" 
  -d "{
    "query": {
      "bool": {
        "must": [
          {"match": {"event": "authentication.failed"}},
          {"range": {"@timestamp": {"gte": "now-${TIMEFRAME}"}}}
        ]
      }
    },
    "aggs": {
      "by_ip": {
        "terms": {"field": "source_ip", "min_doc_count": ${THRESHOLD}}
      }
    }
  }" | jq -r '.aggregations.by_ip.buckets[].key')

# Bloquer les IPs via le WAF
for IP in $OFFENDING_IPS; do
  echo "Blocking IP: $IP"
  # AWS WAF
  aws wafv2 update-ip-set --name "blocked-ips" --scope REGIONAL 
    --addresses "${IP}/32" --lock-token $(aws wafv2 get-ip-set --name "blocked-ips" --scope REGIONAL --query "LockToken" --output text)

  # Notification Slack
  curl -X POST "$SLACK_WEBHOOK" -H "Content-Type: application/json" 
    -d "{"text": "[SECURITE] IP ${IP} bloquee automatiquement apres ${THRESHOLD} tentatives de brute force en ${TIMEFRAME}"}"
done

Chapitre 10 : Questions frequentes

Outils et Ressources DevSecOps

Decouvrez nos outils open source et modeles d''IA developpes pour les professionnels de la cybersecurite :

Questions Frequentes

Quels outils open source sont recommandes pour implementer le DevSecOps ?

Les outils open source essentiels pour le DevSecOps incluent : SAST avec SonarQube Community, Semgrep et Bandit (Python). DAST avec OWASP ZAP et Nuclei. SCA avec Dependency-Check et Trivy pour les vulnerabilites des dependances. Container scanning avec Trivy, Grype et Clair. Infrastructure as Code scanning avec Checkov, TFSec et KICS. Secret detection avec TruffleHog et GitLeaks. Orchestration avec DefectDojo pour centraliser les resultats. Ces outils s'integrent facilement dans les pipelines GitHub Actions, GitLab CI ou Jenkins.

Comment mesurer la maturite DevSecOps d'une organisation ?

La maturite DevSecOps se mesure selon plusieurs axes : le niveau d'automatisation des tests de securite dans le pipeline, la couverture des applications par les scans SAST/DAST/SCA, le temps moyen de remediation des vulnerabilites (MTTR), le pourcentage de vulnerabilites detectees avant la production, la culture de securite des equipes de developpement (frequence des formations, participation aux bug bounties), et l'integration de la securite dans les ceremonies Agile. Le modele OWASP SAMM (Software Assurance Maturity Model) fournit un cadre structure pour evaluer et ameliorer progressivement la maturite DevSecOps.

Conclusion : vers une maturite DevSecOps

L'integration de la securite dans le pipeline CI/CD n'est plus une option mais une necessite strategique pour toute organisation qui developpe et deploie des logiciels. Le DevSecOps represente bien plus qu'un ensemble d'outils : c'est une transformation culturelle profonde qui place la securite central dans chaque decision, de chaque ligne de code et de chaque deploiement.

Ce livre blanc a couvert l'ensemble du spectre DevSecOps, depuis les fondamentaux culturels (shift-left, Security Champions, threat modeling) jusqu'aux aspects les plus techniques (SAST avec SonarQube, Semgrep et CodeQL ; SCA avec Snyk et Dependabot ; securite des conteneurs avec Trivy et Grype ; DAST avec OWASP ZAP ; audit IaC avec Checkov et tfsec ; securisation du pipeline avec Vault, Cosign et SLSA ; monitoring en production avec WAF, RASP et observabilite).

La cle du succes reside dans une approche progressive et pragmatique. Ne tentez pas de tout implementer simultanement. Commencez par les fondamentaux (SAST et SCA dans le pipeline, programme Security Champions), mesurez les resultats, iterez et elargissez progressivement le perimetre. Chaque amelioration, meme minime, contribue a renforcer la posture de securite globale de votre organisation.

Les metriques sont essentielles pour piloter votre demarche DevSecOps. Suivez le MTTD (Mean Time To Detect) et le MTTR (Mean Time To Remediate) pour les vulnerabilites, le nombre de vulnerabilites detectees par phase du pipeline, le taux de couverture des scans de securite et le pourcentage de deploiements conformes aux quality gates. Ces indicateurs vous permettront de demontrer la valeur du DevSecOps a votre direction et d'identifier les axes d'amelioration prioritaires.

Enfin, rappelons que le DevSecOps est un voyage, pas une destination. Les menaces evoluent, les outils s'ameliorent, les pratiques se raffinent. L'amelioration continue, fondee sur le feedback des equipes, l'analyse des incidents et la veille technologique, est le moteur d'une posture de securite durable et efficace.

Les 10 commandements du DevSecOps

• Tu integreras la securite des la conception (shift-left), pas en fin de cycle.
• Tu automatiseras les controles de securite dans le pipeline CI/CD sans exception.
• Tu formeras tes equipes en continu et nommeras des Security Champions.
• Tu ne toléreras aucun secret en clair dans le code source ou les configurations.
• Tu scanneras systematiquement tes dependances open source et tes images de conteneurs.
• Tu definiras des quality gates de securite non-negociables pour les severites critiques.
• Tu signeras tes artefacts et genereras un SBOM pour chaque release.
• Tu testeras ton application en conditions reelles avec du DAST et de l'IAST.
• Tu monitoreras la securite en production avec WAF, RASP et observabilite.
• Tu mesureras ta maturite DevSecOps et t'amelioreras en continu.

Besoin d'accompagnement pour votre demarche DevSecOps ?

Nos experts en securite applicative et DevSecOps vous accompagnent dans l'audit de vos pipelines CI/CD, l'integration des outils de securite, la formation de vos equipes et la mise en œuvre d'un programme Security Champions adapte a votre organisation. De l'evaluation initiale de maturite jusqu'a l'implementation complete, nous vous guidons a chaque etape.

Contactez nos experts DevSecOps

Partager cet article

Twitter LinkedIn Copier le lien

Ayi NEDJIMI

Expert Cybersécurité & Intelligence Artificielle

Consultant et formateur spécialisé en tests d'intrusion, Active Directory, et développement de solutions IA. 15+ années d'expérience en sécurité offensive.

Articles connexes

DFIR : Réponse à Incident et Forensics | Guide Expert

Guide complet DFIR : méthodologie de réponse à incident, analyse forensique Windows/Linux/Cloud, collecte de preuves et outils avancés.

11/03/2026

Zero Trust : Architecture et Déploiement Entreprise

Guide complet sur l'architecture Zero Trust : principes fondamentaux, micro-segmentation, gestion des identités (IAM, MFA, PAM), déploiement cloud multi-provider et feuille de route pour les entreprises. Référence NIST SP 800-207.

11/03/2026

Red Team vs Blue Team : Méthodologies et Outils Expert

Guide complet Red Team vs Blue Team : methodologies d'attaque et defense, outils, MITRE ATT&CK et exercices Purple Team.

11/03/2026

Article précédent

Guide Complet du Pentest Cloud : AWS, Azure et GCP

Article suivant

IA Offensive et Défensive en Cybersécurité | Guide 2025

Commentaires (2)

D

Diane Faure 10/03/2026 à 11:20

Merci pour cet article détaillé sur ce guide complet. En tant que pentester, je me demande comment adapter ce cadre méthodologique à un contexte international. Avez-vous des retours d'expérience à partager sur ce point ?

D

Diane Faure 11/03/2026 à 03:05

Article intéressant sur ce référentiel. Je pense qu'il serait pertinent d'évoquer aussi le fait que la dimension organisationnelle est aussi bien couverte que la technique. C'est de plus en plus pertinent dans le contexte actuel.

Laisser un commentaire

Nom *

Email * (non publié)

Commentaire *

Publier