LLM Security

Formation sécurité IA pour DevSecOps : intégrer l'IA dans la CI/CD

DevSecOps + IA : pipeline CI/CD sécurisé pour LLM (scanners ML, AI BOM, adversarial testing, IaC, GitOps), Kubernetes pour inference, blue-green canary, plan 12 semaines.

Naim Aouaichia
14 min de lecture
  • DevSecOps
  • CI/CD
  • IaC
  • GitOps
  • Kubernetes
  • LLM security

Le DevSecOps IA n'est pas une discipline indépendante, c'est l'extension du DevSecOps classique à de nouveaux artefacts (modèles ML, datasets, tokenizers, inference servers, prompts versionnés). 70% des pratiques restent identiques (CI/CD, IaC, GitOps, scanning, signing) ; 30% sont ML-spécifiques (scanners ML, AI BOM, adversarial testing, model signing). Pour un DevSecOps senior, la montée en compétence prend 3-6 mois avec un plan structuré. Cet article documente la roadmap formation 12 semaines, la stack outillage, les patterns CI/CD, les patterns Kubernetes, et les erreurs fréquentes.

Pour le pendant AppSec : LLM security pour AppSec. Pour le pendant dev backend : formation sécurité IA dev backend.

Le bon mental model : extension, pas réinvention

DevSecOps IA = DevSecOps classique étendu à de nouveaux artefacts :

Artefact classiqueArtefact IA équivalent
Code source (.py, .ts)+ System prompts versionnés (.md, .yml)
Dépendances (requirements.txt, package.json)+ Modèles ML (Hugging Face) + datasets
Containers Docker+ Inference servers (vLLM, TGI, Ollama)
SBOM (CycloneDX, SPDX)+ AI BOM (CycloneDX 1.6+ AI extension)
Scanners (Trivy, pip-audit, Snyk)+ scanners ML (picklescan, Trivy ML)
SAST/DAST+ adversarial testing (Garak, PyRIT)
Signing (Sigstore)+ Sigstore for ML / OpenSSF Model Signing
IaC (Terraform, Helm)+ IaC pour inference servers + vector DB
GitOps (ArgoCD, Flux)+ GitOps pour AI configs (prompts, ABAC, BOM)
Observabilité (OTel)+ OTel GenAI semantic conventions

Renforcer le DevSecOps classique d'abord, ajouter les spécificités IA ensuite. Si vous n'êtes pas à l'aise sur SLSA ou Sigstore, commencer par là, c'est 50% du chemin pour la supply chain ML.

Tip, DevSecOps IA n'est pas un nouveau métier, c'est une évolution du métier DevSecOps. Les seniors qui s'y forment en 3-6 mois sont en pénurie sur le marché 2026.

Quatre piliers DevSecOps IA

Pilier 1, Supply chain ML

Étendre le SBOM, le scanning, et le signing aux artefacts IA :

  • AI BOM (CycloneDX 1.6+) : modèles, datasets, tokenizers, libraries ML versionnées avec hashes.
  • Scanners ML : picklescan, transformers safety, Trivy ML, JFrog Xray.
  • Mirror interne : Artifactory ML, Nexus, S3 privé pour modèles audités.
  • Signing : Sigstore for ML / OpenSSF Model Signing (en pilote 2025-2026).
# .github/workflows/ml-supply-chain.yml
name: ML Supply Chain
 
on:
  pull_request:
  schedule:
    - cron: '0 2 * * *'  # daily
 
jobs:
  scan-libraries:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Pip audit
        run: pip-audit -r requirements.txt
      - name: Snyk scan
        uses: snyk/actions/python@master
 
  scan-models:
    runs-on: ubuntu-latest
    steps:
      - name: Picklescan
        run: |
          pip install picklescan
          picklescan --recursive ./models/
      - name: Hash check
        run: |
          python scripts/verify_model_hashes.py
 
  scan-images:
    runs-on: ubuntu-latest
    steps:
      - name: Trivy on inference images
        run: |
          trivy image vllm/vllm-openai:0.6.0 --exit-code 1 --severity HIGH,CRITICAL
          trivy image ghcr.io/huggingface/text-generation-inference:2.4.0 --exit-code 1
 
  generate-aibom:
    runs-on: ubuntu-latest
    steps:
      - name: Generate AI BOM
        run: |
          pip install cyclonedx-aibom
          cyclonedx-py requirements -i requirements.txt -o aibom.json
          # Append models from manifest
          python scripts/append_models_to_bom.py aibom.json
 
      - name: Upload AI BOM
        uses: actions/upload-artifact@v4
        with:
          name: aibom
          path: aibom.json

Pour le détail : supply chain attack ML.

Pilier 2, Adversarial testing en CI

Tester les défenses LLM automatiquement à chaque PR + nightly complet.

# .github/workflows/adversarial-testing.yml
name: Adversarial Testing
 
on:
  pull_request:
    paths:
      - 'prompts/**'
      - 'app/**'
  schedule:
    - cron: '0 3 * * *'  # nightly
 
jobs:
  fast-adversarial:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@v4
      - name: Run Garak fast probes
        run: |
          pip install garak
          garak --model_type ${{ env.MODEL_TYPE }} \
                --model_name ${{ env.MODEL_NAME }} \
                --probes promptinject,dan,encoding,leakage \
                --report_prefix garak_pr
      - name: Check regression
        run: python scripts/check_adversarial_regression.py
 
  full-adversarial-nightly:
    if: github.event_name == 'schedule'
    runs-on: ubuntu-latest
    timeout-minutes: 120
    steps:
      - uses: actions/checkout@v4
      - name: Run PyRIT full campaign
        run: |
          python scripts/pyrit_nightly_campaign.py \
            --orchestrator crescendo \
            --orchestrator multi_turn \
            --datasets harmbench,jailbreakbench
      - name: Upload report
        uses: actions/upload-artifact@v4
        with:
          name: pyrit-nightly-report
          path: reports/
      - name: Alert SOC if new bypasses
        if: failure()
        run: python scripts/alert_soc.py reports/

Outils clés :

  • Garak (NVIDIA) : probes adversariales rapides, idéal CI PR.
  • PyRIT (Microsoft) : orchestration multi-tour, idéal nightly.
  • HarmBench / JailbreakBench / AILuminate : datasets standard.

Voir Microsoft AI Red Team playbook.

Pilier 3, IaC pour infrastructure IA

Infrastructure as Code étendue aux composants IA.

# terraform/modules/inference-server/main.tf
resource "kubernetes_deployment" "vllm" {
  metadata {
    name      = "vllm-inference"
    namespace = var.namespace
    labels = {
      app = "vllm"
      "ai.security.tier" = "production"
    }
  }
  
  spec {
    replicas = var.replicas
    
    selector {
      match_labels = {
        app = "vllm"
      }
    }
    
    template {
      metadata {
        labels = {
          app = "vllm"
        }
      }
      
      spec {
        # Pod Security Standards strict
        security_context {
          run_as_non_root = true
          run_as_user     = 1001
          fs_group        = 1001
        }
        
        container {
          name  = "vllm"
          # Image pinned with SHA digest, mirror interne
          image = "registry.internal/vllm@sha256:${var.vllm_digest}"
          
          security_context {
            allow_privilege_escalation = false
            read_only_root_filesystem  = true
            capabilities {
              drop = ["ALL"]
            }
          }
          
          resources {
            requests = {
              "nvidia.com/gpu" = "1"
              "memory"          = "16Gi"
              "cpu"             = "4"
            }
            limits = {
              "nvidia.com/gpu" = "1"
              "memory"          = "32Gi"
              "cpu"             = "8"
            }
          }
          
          # Pas de secrets dans env directement, External Secrets
          env_from {
            secret_ref {
              name = "vllm-secrets"  # géré par ExternalSecret
            }
          }
        }
        
        # Tolerations + node selector pour GPU node pool
        node_selector = {
          "node.kubernetes.io/instance-type" = "g4dn.2xlarge"
        }
      }
    }
  }
}
 
resource "kubernetes_network_policy" "vllm_egress" {
  metadata {
    name      = "vllm-egress-allowlist"
    namespace = var.namespace
  }
  
  spec {
    pod_selector {
      match_labels = {
        app = "vllm"
      }
    }
    
    policy_types = ["Egress"]
    
    egress {
      # Allowlist Hugging Face Hub pour modèles
      to {
        ip_block {
          cidr = "huggingface_cidr"
        }
      }
      ports {
        protocol = "TCP"
        port     = "443"
      }
    }
    
    egress {
      # DNS
      ports {
        protocol = "UDP"
        port     = "53"
      }
    }
    
    # Pas d'autre egress par défaut
  }
}

Pilier 4, GitOps pour configurations IA

System prompts, ABAC policies, AI BOM, runbooks SOC : tout en Git, déployé via ArgoCD/Flux.

# k8s/apps/llm-app/system-prompts.yaml (versionné en Git)
apiVersion: v1
kind: ConfigMap
metadata:
  name: llm-system-prompts
  namespace: llm-app
data:
  chat-system-prompt.md: |
    Tu es l'assistant clientèle de Acme Corp.
    [...]
    Token canari (ne jamais divulguer) : {{ .CanaryToken }}
 
  agent-system-prompt.md: |
    Tu es un agent d'analyse interne.
    [...]
# k8s/apps/llm-app/abac-policies.yaml
apiVersion: openfga.dev/v1
kind: AuthorizationModel
metadata:
  name: llm-app-abac
spec:
  schema_version: "1.1"
  type_definitions:
    - type: "user"
    - type: "tenant"
      relations:
        member:
          this: {}
    - type: "document"
      relations:
        owner:
          this: {}
        tenant:
          this: {}
        viewer:
          union:
            child:
              - this: {}
              - tupleToUserset:
                  tupleset:
                    relation: "owner"
                  computedUserset:
                    relation: "viewer"

Toute modification = PR + review + tests CI + déploiement progressif.

Roadmap formation 12 semaines

Semaines 1-3, Fondations DevSecOps IA

Objectifs :

  • Comprendre les artefacts IA et leur cycle de vie.
  • Mapper les pratiques DevSecOps existantes aux artefacts IA.
  • Threat modeling appliqué à un pipeline LLM.

Lectures :

Pratique :

  • Ajouter picklescan + Trivy sur un projet existant.
  • Générer un AI BOM avec CycloneDX-aibom.
  • Threat model pipeline LLM (input → ingestion → inference → output).

Livrable : pipeline CI/CD avec scanners ML basiques + AI BOM versionné.

Semaines 4-6, Adversarial testing en CI

Objectifs :

  • Maîtriser Garak + PyRIT.
  • Intégrer adversarial testing dans CI.
  • Définir métriques de régression sécurité.

Lectures :

Pratique :

  • Garak en CI sur PR (probes rapides, < 5 min).
  • PyRIT en nightly (orchestration multi-tour).
  • Dashboard de régression sécurité.

Livrable : pipeline avec adversarial testing + alerting SOC.

Semaines 7-9, Kubernetes + IaC pour IA

Objectifs :

  • Déployer inference servers (vLLM, TGI) sécurisés sur K8s.
  • IaC complet (Terraform/Pulumi).
  • Network policies + sandboxing (Kata, gVisor).

Lectures :

Pratique :

  • Cluster K8s avec node pool GPU dédié.
  • Inference server (vLLM ou TGI) avec Pod Security Standards strict.
  • Network policies (Cilium ou Calico).
  • KServe ou Ray Serve pour serving avec scaling auto.

Livrable : infra IA production-ready as code.

Semaines 10-12, GitOps + observabilité + spécialisation

Objectifs :

  • GitOps avec ArgoCD/Flux pour configs IA.
  • Observabilité OTel GenAI complète.
  • Spécialisation : agents OU multi-tenant OU sectoriel.

Lectures :

Pratique :

  • ArgoCD pour déploiement progressif (canary 5% → 50% → 100%).
  • External Secrets Operator + Vault.
  • Stack observabilité complète : Langfuse + OTel collector + Splunk/Sentinel.
  • Runbooks SOC versionnés.

Livrable : système production-ready end-to-end avec GitOps + observabilité + spécialisation choisie.

Stack outillage recommandée

Indispensables (semaines 1-6)

CatégorieOutilUsage
Scanners MLpicklescan (HF)Détection pickle malveillants
Scanners MLtransformers safety scannerAudit modèles
Scanners libspip-audit, SnykCVE libraries Python
Scanners containersTrivyCVE inference servers
Adversarial CIGarak (NVIDIA)Probes rapides
Adversarial nightlyPyRIT (Microsoft)Orchestration multi-tour
AI BOMcyclonedx-aibomSBOM IA

Production (semaines 7-9)

CatégorieOutilUsage
K8s servingKServe, Ray Serve, vLLM, TGIInference servers
SandboxingKata Containers, gVisor, FirecrackerIsolation forte
Network policiesCilium (eBPF), CalicoEgress allowlist
IaCTerraform, Pulumi, HelmInfra as code
Pod SecurityKyverno, OPA GatekeeperPolicies K8s

Spécialisation (semaines 10-12)

CatégorieOutilUsage
GitOpsArgoCD, FluxDéploiement Git-driven
SecretsExternal Secrets Operator + VaultGestion secrets K8s
ObservabilitéOpenTelemetry collector + Langfuse + Splunk/SentinelStack complète
SigningSigstore (Cosign)Signature artefacts
ABACOpenFGA, AWS Cedar, Permit.ioPolicies fine

Pipeline CI/CD complet de référence

# .github/workflows/llm-app-cicd.yml
name: LLM App CI/CD
 
on:
  push:
    branches: [main]
  pull_request:
 
jobs:
  # ─── 1. SECURITY SCANS ─────────────────────────
  
  scan-supply-chain:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Pip audit
        run: pip-audit -r requirements.txt
      - name: Picklescan
        run: |
          pip install picklescan
          picklescan --recursive ./models/
      - name: Generate AI BOM
        run: |
          pip install cyclonedx-aibom
          cyclonedx-py requirements -i requirements.txt -o aibom.json
      - uses: actions/upload-artifact@v4
        with:
          name: aibom
          path: aibom.json
 
  scan-images:
    runs-on: ubuntu-latest
    steps:
      - name: Trivy
        run: |
          trivy image vllm/vllm-openai:0.6.0 \
                --exit-code 1 \
                --severity HIGH,CRITICAL
 
  # ─── 2. ADVERSARIAL TESTING ──────────────────
  
  adversarial-pr:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@v4
      - name: Garak fast probes
        run: |
          pip install garak
          garak --model_type ${{ env.MODEL_TYPE }} \
                --probes promptinject,dan,encoding \
                --report_prefix garak_pr
      - name: Regression check
        run: python scripts/check_adversarial_regression.py
 
  # ─── 3. UNIT TESTS ──────────────────────────
  
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run pytest
        run: pytest tests/ -v --cov=app
 
  # ─── 4. BUILD + SIGN ─────────────────────────
  
  build-and-sign:
    if: github.ref == 'refs/heads/main'
    needs: [scan-supply-chain, scan-images, test]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t ${{ env.IMAGE }}:${{ github.sha }} .
      - name: Cosign sign
        run: |
          cosign sign --yes ${{ env.IMAGE }}:${{ github.sha }}
      - name: Attest AI BOM
        run: |
          cosign attest --yes \
                       --predicate aibom.json \
                       --type cyclonedx \
                       ${{ env.IMAGE }}:${{ github.sha }}
 
  # ─── 5. DEPLOY (GitOps) ──────────────────────
  
  deploy-canary:
    if: github.ref == 'refs/heads/main'
    needs: [build-and-sign]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Update GitOps repo
        run: |
          # Update image tag in GitOps repo
          # ArgoCD/Flux détecte et déploie en canary 5%
          python scripts/update_gitops_canary.py ${{ github.sha }}
      - name: Wait for canary metrics
        run: python scripts/wait_canary_health.py --duration 30m
      - name: Promote to 50%
        run: python scripts/promote_canary.py 50
 
# ─── NIGHTLY ───────────────────────────────────
 
  adversarial-nightly:
    if: github.event_name == 'schedule'
    runs-on: ubuntu-latest
    timeout-minutes: 120
    steps:
      - name: PyRIT full campaign
        run: python scripts/pyrit_nightly.py

Patterns Kubernetes pour IA

Pod Security Standards

ProfilInference serversCode execution agents
PrivilegedRefuséRefusé
BaselineAcceptableRefusé
RestrictedRecommandéRefusé sans Kata/gVisor
# Pod Security Admission au namespace level
apiVersion: v1
kind: Namespace
metadata:
  name: llm-production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest

Runtime classes pour code execution

# Pour agents qui exécutent du code généré
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata-fc
handler: kata-fc  # Firecracker via Kata
---
apiVersion: v1
kind: Pod
spec:
  runtimeClassName: kata-fc
  containers:
    - name: code-executor
      image: code-executor:latest

Network policies stricts

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: llm-app-egress-strict
spec:
  podSelector:
    matchLabels:
      app: llm-app
  policyTypes:
    - Egress
  egress:
    # Vers AI gateway interne uniquement
    - to:
        - podSelector:
            matchLabels:
              app: ai-gateway
      ports:
        - protocol: TCP
          port: 8080
    # DNS
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53

Erreurs fréquentes en formation DevSecOps IA

ErreurSymptômeFix
Sauter SLSA / SigstoreSupply chain non-vérifiableRenforcer fondamentaux supply chain d'abord
Adversarial testing manuelPas de régression automatiqueGarak en CI dès le départ
Pas d'AI BOMInvisibilité supply chain MLCycloneDX-aibom à chaque build
Inference server sans Pod SecurityÉvasion possiblePod Security Standards "restricted"
Secrets en env-vars K8s clearCompromission au bootExternal Secrets Operator + Vault
Pas de canary deployRollout risquéArgoCD progressive sync ou Flagger
Logs LLM en stdout uniquementPas de SIEMOTel → SIEM obligatoire
GPU drivers non patchésCVE NVIDIA exploitableImage patching automatique

Plan de carrière DevSecOps → DevSecOps IA

NiveauDuréeCompétences clés
DevSecOps + IA-aware0-6 moisLectures + outils ajoutés au pipeline
DevSecOps IA opérationnel6-18 moisStack complète production + GitOps
Senior DevSecOps IA18 mois - 3 ansArchitecture multi-cluster + sectoriel
Platform engineer LLM3+ ansPlateforme IA centrale d'entreprise

Marché 2026 : pénurie significative sur ces profils, particulièrement Senior+ avec expérience pratique de PyRIT/Garak/Sigstore for ML.

Pour aller plus loin

Points clés à retenir

  • DevSecOps IA = DevSecOps classique étendu à de nouveaux artefacts (modèles, datasets, prompts, inference servers, AI BOM). 70% reste identique.
  • 4 piliers : supply chain ML, adversarial testing CI, IaC pour infra IA, GitOps pour configs.
  • Stack outillage : picklescan + Trivy (scanners), Garak + PyRIT (adversarial), CycloneDX-aibom (BOM), KServe + vLLM + Kata (K8s), ArgoCD + ExternalSecrets (GitOps).
  • Pipeline CI/CD complet : scans → adversarial → tests → build + sign → deploy canary. Bloquer merges sur findings critiques.
  • Pod Security Standards "restricted" pour inference servers ; Kata/gVisor/Firecracker pour code execution agents.
  • Plan 12 semaines : Fondations → Adversarial CI → K8s/IaC → GitOps + obs + spécialisation.
  • 8 erreurs fréquentes : sauter SLSA, adversarial manuel, pas d'AI BOM, Pod Security default, secrets env-clear, pas de canary, logs stdout, GPU drivers non patchés.
  • Plan de carrière : DevSecOps IA-aware (0-6m) → opérationnel (6-18m) → Senior (18m-3y) → Platform engineer LLM (3+y). Marché 2026 en pénurie.

DevSecOps IA est l'évolution naturelle du métier DevSecOps en 2026. Pour un senior, 3-6 mois d'investissement structuré transforment significativement la valeur sur le marché. Pour les organisations, c'est le pivot stratégique entre projets IA pilotes et déploiements production sécurisés à l'échelle.

Questions fréquentes

  • Quelle différence entre DevSecOps classique et DevSecOps IA ?
    DevSecOps IA étend DevSecOps classique avec des **artefacts spécifiques** : modèles ML, datasets, tokenizers, inference servers, prompts versionnés. Les pratiques restent les mêmes (CI/CD, IaC, GitOps, scanning, signing) mais les **outils** s'étendent : `picklescan` en plus de `pip-audit`, `Trivy ML scanner` en plus de scan containers classique, `Garak/PyRIT` en plus de SAST/DAST, AI BOM en plus de SBOM. 70% est du DevSecOps standard, 30% est ML-spécifique. Pour un DevSecOps senior, montée en compétence en 3-6 mois.
  • Quels scanners ML intégrer en CI/CD prioritairement ?
    Quatre scanners minimum. (1) **picklescan** (Hugging Face) : détecte pickle malveillants au moment du build. (2) **transformers safety scanner** : audit des modèles téléchargés. (3) **Trivy** avec ML extensions : scan containers d'inference (vLLM, TGI, Ollama) pour CVE. (4) **pip-audit / Snyk** : libraries ML (transformers, torch, diffusers). À ajouter selon contexte : **JFrog Xray ML**, **Wiz**, **HiddenLayer Model Scanner**. Bloquer les merges en cas de finding critique. Re-scan automatique sur les modèles ré-téléchargés.
  • Comment intégrer adversarial testing en CI ?
    Pattern recommandé en 2 niveaux. **Niveau 1 (rapide, à chaque PR)** : Garak avec probes ciblées (50-100 attaques sur OWASP LLM Top 10), durée &lt; 5 min, blocage si régression > seuil défini. **Niveau 2 (complet, nightly ou weekly)** : PyRIT avec orchestrators Crescendo, attaques compositionnelles, durée 30-60 min, alertes SOC si nouveaux bypass. Stocker les résultats dans un dashboard versionné. Ajouter au corpus régression chaque nouvelle attaque découverte (en interne ou en threat intel). Ne pas ré-inventer, utiliser les datasets HarmBench, JailbreakBench, AILuminate.
  • Faut-il un Kubernetes dédié pour les inference servers ?
    Pour les déploiements à l'échelle, oui, souvent un node pool dédié au minimum. Avantages : (1) Sizing GPU séparé du reste. (2) Isolation réseau (network policies strictes). (3) Patching/upgrade indépendant. (4) Sandboxing (Kata Containers, gVisor) si code execution. (5) RBAC dédié. Pour PME : un namespace bien isolé suffit souvent. Outils : KServe (anciennement KFServing) pour serving, Ray Serve pour scaling, NVIDIA Triton pour multi-modèle, vLLM/TGI directement. Ajouter Cilium pour eBPF network policies.
  • GitOps pour les configurations LLM, comment faire ?
    Pattern simple. **System prompts** versionnés en Git, déployés via ArgoCD/Flux comme du code. **Configurations agents** (allowlist tools, ABAC policies) dans le même repo. **AI BOM** (CycloneDX 1.6+) versionné. **Secrets** via External Secrets Operator + Vault, jamais en clair en Git. Reviews via PR, tests CI sur chaque modification, déploiement progressif (canary 5% → 50% → 100%). Le pattern est identique au GitOps applicatif standard, étendu aux artefacts IA. Outils : ArgoCD, Flux, Sealed Secrets, External Secrets Operator.
  • Comment sécuriser un déploiement multi-modèle (Llama + Claude + GPT) ?
    Trois principes. (1) **AI Gateway centralisé** (LiteLLM, Portkey) : routage + auth + observabilité unifiés. Ne jamais appeler les API directement depuis chaque service. (2) **Allowlist par tenant** : pas tous les modèles sont accessibles à tous les tenants, politique fine. (3) **Cost tracking + rate limiting par modèle** : chaque modèle a son cost/token, tracker séparément. Pour les modèles self-hosted (Llama via vLLM/TGI) : sandboxing kernel-level (gVisor, Kata), supply chain ML stricte (hash matching, signed manifests). Multi-modèle = surface ×3, discipline stricte requise.

Écrit par

Naim Aouaichia

Cyber Security Engineer et fondateur de Zeroday Cyber Academy

Ingénieur cybersécurité avec un parcours hybride : développement, DevOps Capgemini, DevSecOps IN Groupe (sécurité des documents d'identité régaliens), audits CAC 40. Fondateur de Hash24Security et Zeroday Cyber Academy. Présence LinkedIn 43 000 abonnés, Substack Zeroday Notes 23 000 abonnés.