Google Secure AI Framework (SAIF) : application concrète

Le Google Secure AI Framework (SAIF), publié en juin 2023, est un cadre conceptuel pour sécuriser les systèmes IA. À la différence des frameworks de gouvernance (NIST AI RMF, ISO 42001), SAIF est orienté ingénieur : il parle de SOC, de CI/CD, de threat detection, d'automation. Pour les équipes ingénieurs ML/AppSec qui cherchent un cadre pragmatique et architectural (sans la lourdeur d'une certification), SAIF est devenu une référence largement adoptée par l'industrie tech depuis 2023-2024. Combiné à OWASP LLM Top 10 (tactique) et NIST AI RMF (gouvernance), il forme un trio cohérent pour structurer un programme sécurité IA.

Cet article documente les 6 éléments SAIF, la SAIF Risk Map (publiée 2024), les mappings vers NIST/OWASP/MITRE ATLAS, un plan d'implémentation, et la position de Google dans CoSAI (Coalition for Secure AI). Pour le pendant gouvernance : NIST AI RMF guide d'implémentation. Pour le pendant tactique dev : OWASP LLM Top 10 développeurs.

Vue d'ensemble : les 6 éléments SAIF

Info — Site officiel : safety.google/cybersecurity-advancements/saif. Document principal : Google Secure AI Framework — A Practical Guide for Securing Your AI Systems. Mises à jour régulières.

Détail par élément

Élément 1 — Expand strong security foundations

Idée : la sécurité IA n'est pas une discipline indépendante. Étendre les bonnes pratiques DevSecOps existantes (IAM, secrets management, supply chain, code review) à la chaîne IA.

Application concrète :

# Extension DevSecOps → AI
foundations:
  identity_access_management:
    extend_to:
      - service accounts pour pipelines training/inference
      - RBAC sur modèles (download, deploy, fine-tune)
      - ABAC pour multi-tenancy IA
  
  secrets_management:
    extend_to:
      - clés API LLMs (OpenAI, Anthropic, etc.)
      - pas de secrets dans system prompts
      - vault + ephemeral creds pour agents
  
  supply_chain:
    extend_to:
      - AI BOM (CycloneDX 1.6+ AI extension)
      - Sigstore for ML
      - Hash matching modèles téléchargés
      - Mirror interne (Artifactory ML)
  
  code_review:
    extend_to:
      - prompts versionnés et reviewés en MR/PR
      - threat model par feature ML
      - tests adversariaux en PR
  
  network_segmentation:
    extend_to:
      - inference servers isolés
      - egress allowlist pour agents
      - mTLS inter-services IA

Recommandation pragmatique : commencer par auditer ce qui existe déjà côté infra/sécurité — beaucoup s'applique déjà partiellement. Le travail est d'étendre, pas de réinventer.

Élément 2 — Extend detection and response

Idée : l'IA doit faire partie du threat universe de l'organisation, donc du SOC. Détection runtime + response coordonnée avec le reste de la sécurité.

Application concrète :

• Logs structurés IA vers SIEM (Splunk, Sentinel, Elastic) avec OpenTelemetry GenAI semantic conventions.
• Règles de corrélation : référencer MITRE ATLAS dans les rules SIEM.
• Alertes spécifiques : prompt injection détectée, canary token leaké, anomalie volume requêtes, drift comportemental.
• Runbooks par classe d'incident OWASP/SAIF.
• Playbooks SOAR : automation de la réponse (rate limit ciblé, suspension session, escalade).

# Exemple : règle de détection envoyée au SIEM
detection_rule = {
    "title": "AI System — Possible Prompt Injection (LLM01 / AML.T0051)",
    "category": "ai_threat",
    "data_source": "llm_app_logs",
    "conditions": [
        "input_classifier_score > 0.7",
        "OR canary_token in output",
        "OR same_user_threshold_reached(detection_count > 5, window='10m')",
    ],
    "mitre_atlas": ["AML.T0051", "AML.T0070"],
    "owasp_llm": ["LLM01"],
    "severity": "medium",
    "action": "alert_soc + rate_limit_user",
    "runbook": "./runbooks/IR-AI-LLM01.md",
}

Élément 3 — Automate defenses

Idée : la vitesse des menaces (nouvelles techniques chaque mois) impose l'automation des défenses. Pas de revue manuelle exhaustive — automatiser ce qui peut l'être.

Application concrète :

• CI/CD security IA :

  • Scanners ML (picklescan, transformers safety, Trivy sur containers).
  • Tests adversariaux automatisés (Garak, PyRIT).
  • Régression sur corpus connus à chaque PR.
  • Gates de promotion (canary deploy → progressive rollout).

• Runtime defenses automatisées :

  • Input filter (LLM Guard, Lakera) toujours actif.
  • Output filter (DLP, canary detection) toujours actif.
  • Limits (max_steps, max_cost) auto-appliquées.
  • Auto-rollback sur anomalie.

• Threat intelligence :

  • Feed automatique CVE / divulgations responsables → mise à jour scanners.
  • Patches dépendances ML automatisés (Dependabot étendu ML).

# .github/workflows/ai-defense-automation.yml
name: AI Defense Automation
 
on:
  pull_request:
  schedule:
    - cron: '0 2 * * *'  # daily
  workflow_dispatch:
 
jobs:
  automated-scans:
    runs-on: ubuntu-latest
    steps:
      - name: ML supply chain scan
        run: |
          picklescan --recursive ./models/
          pip-audit -r requirements.txt
          trivy image ${{ env.INFERENCE_IMAGE }}
      
      - name: Adversarial regression
        run: |
          garak --model_type ${{ env.MODEL_TYPE }} \
                --probes promptinject,dan,encoding,leakage
          pytest tests/test_adversarial_regression.py
      
      - name: Threat feed update
        run: |
          curl -s ${{ env.THREAT_FEED_URL }} | \
            python scripts/update_detection_rules.py

Élément 4 — Harmonize platform-level controls

Idée : éviter les silos par projet IA. Mettre en place des contrôles plateforme-level réutilisables.

Application concrète :

• Plateforme IA centrale : tous les projets IA passent par une plateforme commune (vs chaque équipe construit en local).

• Composants partagés :

  • Gateway IA centralisé (LiteLLM, Portkey) avec auth + rate limit + observability.
  • Vector DB partagé (avec isolation tenant native).
  • Inference servers managés.
  • Pipeline d'audit standardisé.

• Politiques cross-projets :

  • Sources de modèles allowlist commune.
  • Standards d'observabilité homogènes.
  • Tests adversariaux requis.

• Bénéfices : économie d'échelle, cohérence sécurité, audit simplifié, expertise mutualisée.

              ┌──────────────────────────────────┐
              │   Plateforme IA centrale          │
              │   - AI Gateway (auth, ratelimit) │
              │   - Vector DB (multi-tenant)     │
              │   - Inference servers managés    │
              │   - Observabilité centralisée    │
              │   - Sécurité standardisée        │
              └────────────┬─────────────────────┘
                           │
            ┌──────────────┼──────────────┐
            │              │              │
    ┌───────▼─────┐ ┌──────▼─────┐ ┌─────▼──────┐
    │ Projet IA A │ │ Projet IA B│ │ Projet IA C│
    └─────────────┘ └────────────┘ └────────────┘

Élément 5 — Adapt controls

Idée : les défenses IA doivent être adaptatives. Boucles de feedback rapides entre red team / blue team / production.

Application concrète :

• Red teaming continu : pas un événement annuel, mais des campagnes régulières (mensuelles minimum sur systèmes critiques).

• Feedback loops :

  • Découverte technique d'attaque → mise à jour scanners + détecteurs.
  • Incident production → enrichissement corpus de tests adversariaux.
  • Drift en production → ré-évaluation modèle.

• Tests A/B sécurité : déployer des variants avec et sans nouvelle mitigation, mesurer impact sur attaque vs faux positifs.

• Versioning des défenses : règles de détection, system prompts, classifiers — tout versionné comme du code.

# Exemple : feedback loop attack → defense
def on_new_attack_pattern(attack_signature: str, source: str):
    """Boucle feedback : nouvelle attaque → mise à jour défenses."""
    
    # 1. Ajouter au corpus régression
    add_to_test_corpus(attack_signature, category="adversarial_regression")
    
    # 2. Mettre à jour classifier
    if classifier_supports_online_update():
        classifier.add_training_example(attack_signature, label="injection")
    else:
        schedule_retraining(reason=f"new_pattern from {source}")
    
    # 3. Mettre à jour règles détection
    add_detection_rule(attack_signature)
    
    # 4. Notifier autres équipes (CoSAI, threat intel)
    if is_novel_pattern(attack_signature):
        notify_threat_intel(attack_signature, severity="medium")
    
    # 5. Re-tester corpus complet en CI
    trigger_ci_run("regression-suite")

Élément 6 — Contextualize AI system risks

Idée : les risques techniques s'évaluent dans le contexte business. Un même risque (ex: hallucination) a un impact différent selon l'usage (chatbot FAQ vs outil médical).

Application concrète :

• Risk register contextualisé : pour chaque système IA, risque technique + impact business + probabilité.
• Threat modeling avec business : équipes métier impliquées dans le threat model.
• Métriques business-aware : pas seulement TPR/FPR mais aussi NPS, satisfaction, taux d'erreur métier.
• Communication avec les parties prenantes : Direction, métiers, juridique impliqués dans les décisions de mitigation.

# Risk register contextualisé
system_id: AS-002-recruitment-ai
technical_risks:
  - LLM01_prompt_injection:
      technical_severity: "high"
      business_context: "Recrutement = haut risque légal + image"
      contextualized_severity: "critical"
      mitigation_priority: 1
 
  - LLM09_hallucination:
      technical_severity: "medium"
      business_context: "Décision sur candidat — droit du travail strict"
      contextualized_severity: "high"
      mitigation_priority: 2
      additional_mitigation: "HITL obligatoire sur tout rejet"
 
  - LLM06_excessive_agency:
      technical_severity: "low"  # tools limités
      business_context: "Acceptable si périmètre bien borné"
      contextualized_severity: "medium"
      mitigation_priority: 3

SAIF Risk Map (2024+)

Google a publié en 2024 une SAIF Risk Map — graphique structuré des risques IA avec attaques et mitigations.

Catégories de la Risk Map

• Training data risks : data poisoning, contamination, biais.
• Model risks : model extraction, backdoor, adversarial examples.
• Application risks : prompt injection, jailbreak, hallucination.
• Agent risks : tool misuse, memory poisoning, multi-agent collusion.
• Operational risks : DoS, supply chain, key compromise.

Vue défensive

À chaque attaque, mitigations associées (input/output filtering, sandboxing, monitoring, etc.). Distinct de MITRE ATLAS (qui catalogue les attaques sans focus défensif).

Combinaison recommandée : MITRE ATLAS pour red team + SAIF Risk Map pour blue team architectural.

Mappings vers autres frameworks

SAIF ↔ NIST AI RMF

SAIF ↔ OWASP LLM Top 10

SAIF ↔ ISO 42001

SAIF ↔ MITRE ATLAS

SAIF est stratégique, ATLAS est tactique. SAIF Element 5 (Adapt) référence implicitement les techniques ATLAS comme catalogue d'attaques à tester en boucle.

Coalition for Secure AI (CoSAI)

Lancée en juillet 2024 par Google + Anthropic + Microsoft + IBM + autres. Objectif : standardiser les pratiques de sécurité IA sous égide OASIS (Organization for the Advancement of Structured Information Standards).

Workstreams :

• Software Supply Chain Security for AI Systems.
• Preparing Defenders for a Changing Cybersecurity Landscape.
• AI Security Governance.

Implication : SAIF transforme progressivement de framework Google → standard plus large via CoSAI. Les organisations qui adoptent SAIF participent à l'effort de standardisation.

Plan d'implémentation 6 mois

Mois 1 — Lecture critique et mapping

• Lire SAIF + Risk Map en équipe sécurité IA.
• Mapper chaque élément à l'existant (DevSecOps, SOC, CI/CD).
• Identifier les gaps spécifiques IA.

Mois 2-3 — Element 1 (Foundations)

• Extension IAM, secrets, supply chain à l'IA.
• AI BOM versionné.
• Mirror interne pour modèles/datasets.

Mois 3-4 — Elements 2 + 3 (Detection + Automation)

• Logs IA → SIEM avec OpenTelemetry GenAI.
• Règles de corrélation référençant ATLAS.
• CI/CD security IA (scanners, adversarial automatisés).

Mois 4-5 — Element 4 (Harmonize)

• Plateforme IA centrale (gateway, observabilité partagée).
• Politiques cross-projets.

Mois 5-6 — Elements 5 + 6 (Adapt + Contextualize)

• Boucles de feedback red team / blue team.
• Risk register contextualisé business.
• Cadence de revue trimestrielle.

Comparaison opérationnelle des frameworks

Recommandation : combiner les 4 plutôt que choisir l'un. Chacun couvre un angle différent.

Limites de SAIF

À connaître pour ne pas surinvestir :

• Vendor-driven : Google a ses propres incentives. CoSAI atténue mais ne neutralise pas.
• Pas certifiable : pas d'audit externe formel, contrairement à ISO 42001.
• Conceptuel : le framework est plus une vision architecturale que des prescriptions précises.
• Maturité : introduit en 2023, encore en évolution (Risk Map en 2024, intégration CoSAI 2024+).

Ces limites se réduisent avec la maturation de CoSAI. SAIF reste utile comme inspiration architecturale même si non utilisé comme référentiel formel.

Outils et ressources

Points clés à retenir

• Google SAIF = framework conceptuel pour sécuriser les systèmes IA, 6 éléments : Foundations, Detect & Response, Automate, Harmonize, Adapt, Contextualize.
• Niveau architectural/ingénieur — distinct de NIST AI RMF (gouvernance), ISO 42001 (certifiable), OWASP LLM Top 10 (tactique). Complémentaires.
• SAIF Risk Map (2024+) : visualisation structurée des risques IA avec mitigations. Combinable avec MITRE ATLAS (red team) en blue team architectural.
• Idée centrale Element 1 : étendre les pratiques DevSecOps existantes (IAM, secrets, supply chain) à l'IA, pas réinventer.
• Element 2 : intégrer l'IA au SOC (logs, alertes, runbooks). OpenTelemetry GenAI + référencement MITRE ATLAS.
• Element 4 : plateforme IA centrale vs silos par projet. Gateway, vector DB, observabilité partagés.
• Element 6 : contextualiser les risques techniques avec le contexte business (impact, probabilité dans l'usage réel).
• CoSAI (Coalition for Secure AI, juillet 2024) : Google + Anthropic + Microsoft + IBM standardisent via OASIS. SAIF s'inscrit dans cet effort.
• Mappings : SAIF couvre des angles complémentaires de NIST/ISO/OWASP — ne se substitue à aucun.
• Limites : vendor-driven, pas certifiable, conceptuel.

SAIF est aujourd'hui une référence opérationnelle largement adoptée dans l'industrie tech. Pas un standard certifiable, mais un cadre architectural précieux pour structurer un programme sécurité IA. Combiné avec NIST + ISO 42001 + OWASP + ATLAS, il complète la palette de référentiels pour une organisation IA-mature.