╔═══════════════════════════════════════════════════════════════════════════╗
║                                                                           ║
║             ██████╗  █████╗ ██████╗ ████████╗ ██████╗ ██████╗             ║
║             ██╔══██╗██╔══██╗██╔══██╗╚══██╔══╝██╔═══██╗██╔══██╗            ║
║             ██████╔╝███████║██████╔╝   ██║   ██║   ██║██████╔╝            ║
║             ██╔══██╗██╔══██║██╔═══╝    ██║   ██║   ██║██╔══██╗            ║
║             ██║  ██║██║  ██║██║        ██║   ╚██████╔╝██║  ██║            ║
║             ╚═╝  ╚═╝╚═╝  ╚═╝╚═╝        ╚═╝    ╚═════╝ ╚═╝  ╚═╝            ║
║                                                                           ║
║             Autonomous Offensive/Defensive Research Framework             ║
║             Based on Claude Code (v3.1.0)                                 ║
║                                                                           ║
║             Gadi Evron, Daniel Cuthbert, Thomas Dullien (Halvar Flake)    ║
║             Michael Bargury, John Cartwright                              ║
║                                                                           ║
╚═══════════════════════════════════════════════════════════════════════════╝

⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣠⣤⣤⣀⣀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣾⣿⣿⠿⠿⠟
⠀⠀⠀⠀⠀⠀⠀⠀⢀⣀⣀⣀⣀⣀⣀⣤⣴⣶⣶⣶⣤⣿⡿⠁⠀⠀⠀
⣀⠤⠴⠒⠒⠛⠛⠛⠛⠛⠿⢿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠟⠁⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠉⠛⣿⣿⣿⡟⠻⢿⡀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣾⢿⣿⠟⠀⠸⣊⡽⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸⡇⣿⡁⠀⠀⠀⠉⠁⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⠻⠿⣿⣧⠀ Get them bugs.....⠀⠀⠀⠀⠀

Le lanceur `raptor` est la méthode recommandée pour démarrer une session, et il fonctionne depuis n'importe quel répertoire -- il résout l'installation de RAPTOR, mémorise le répertoire depuis lequel vous l'avez lancé (afin que des commandes comme `/scan` l'utilisent par défaut), exécute les vérifications préalables de confiance et de projet, charge le plugin de suivi de couverture, et assainit l'environnement avant de passer la main à Claude Code. Il accepte également un chemin cible optionnel et des options comme `--project`, `--continue` et `--model` -- voir `raptor --help`.

Exécuter simplement `claude` depuis le répertoire du dépôt fonctionne aussi -- Claude Code récupère la configuration de RAPTOR depuis le checkout -- mais vous passez à côté de tout ce que fait le lanceur ci-dessus : pas de vérifications préalables, pas de suivi de couverture, et les commandes qui utilisent par défaut « le répertoire depuis lequel vous avez exécuté ceci » ne peuvent pas le voir.

**Important :** RAPTOR charge sa configuration depuis le répertoire du dépôt. Si vous exécutez `claude` depuis n'importe quel autre répertoire, vous obtenez Claude Code standard, pas RAPTOR. Le lanceur `raptor` évite entièrement ce mode de défaillance.

### Option 2 : Exécuter dans un conteneur (recommandé)

L'utilisation de conteneurs est une pratique de sécurité courante pour empêcher les agents d'accéder à des zones de votre système de fichiers auxquelles vous ne voulez pas qu'ils accèdent, ainsi que pour limiter le rayon d'impact de tout code malveillant susceptible de s'exécuter (par exemple via une attaque de chaîne d'approvisionnement). L'image est volumineuse (environ 6 Go). Elle part du devcontainer Microsoft Python 3.12 et ajoute des outils d'analyse statique, de fuzzing et d'automatisation de navigateur.

Vous pouvez récupérer une image pré-construite :```bash
docker pull danielcuthbert/raptor:latest

L'image s'attend à ce que le framework RAPTOR (ce dépôt) soit monté dans `/workspaces/raptor` au démarrage. Vous pouvez éventuellement monter un dossier cible pour l'analyse locale.

Pour démarrer le conteneur :```bash
docker run -it \
  -v "$(pwd):/workspaces/raptor" \
  raptor:latest

Ajoutez `--privileged` si vous avez besoin du débogueur déterministe `rr`.

Les devcontainers VS Code sont également pris en charge. Pour monter un dossier cible, ajoutez-le à la section `mounts` de `.devcontainer/devcontainer.json` :```jsonc
"mounts": [
  // ...existing entries...
  "source=/path/to/target-folder,target=/workspaces/target,type=bind,consistency=cached"
]

Quoi qu'il en soit, une fois à l'intérieur du conteneur, exécutez `raptor` pour commencer.

---

## À quoi s'attendre lors d'une première exécution

La chose la plus simple que vous puissiez faire :```
/scan /path/to/code

Cela exécute le pipeline complet : analyse, déduplication, puis envoi de chaque résultat à travers les étapes de validation (A-F). Sur une base de code de taille moyenne avec environ 50 résultats, comptez 10 à 30 minutes et 2 à 8 $ de coûts LLM pour la couche d'analyse (selon le modèle). Le plafond de coût par défaut est de 10 $ par exécution ; ajustez avec `--max-cost-usd`.

**Note sur les coûts :** La couche d'orchestration Claude Code utilise votre abonnement Claude. La couche de répartition d'analyse effectue des appels API LLM distincts facturés au token. Si vous utilisez uniquement Claude Code comme modèle d'analyse (par défaut), il n'y a aucun coût supplémentaire au-delà de votre abonnement. Si vous configurez des modèles externes (OpenAI, Gemini, etc.), ces appels API sont facturés par ces fournisseurs.

---

## Modèle de sécurité

RAPTOR exécute du code généré par LLM et analyse des dépôts non fiables. Les sous-processus qui traitent du contenu non fiable sont isolés à l'aide de namespaces Linux, Landlock et seccomp. Le bac à sable bloque l'accès réseau, restreint la visibilité du système de fichiers et limite la consommation de ressources. Voir `docs/sandbox.md` pour le modèle de menace complet et la configuration.

Les variables d'environnement susceptibles d'injecter du code dans la chaîne de lancement sont supprimées au démarrage (`core/security/_dangerous_env_strip.sh`). Les chemins de fichiers provenant des dépôts analysés ne sont jamais interpolés dans des chaînes shell — tous les appels de sous-processus utilisent des arguments sous forme de listes.

---

## Ce que RAPTOR peut faire

| Commande | Ce qu'elle fait | Statut |
|---------|-------------|--------|
| `/agentic` | Flux de travail autonome complet : analyse, validation, exploitation, correctif | Stable |
| `/scan` | Analyse statique avec Semgrep et CodeQL | Stable |
| `/understand` | Cartographier la surface d'attaque, tracer les flux de données, rechercher les variantes de vulnérabilités | Stable |
| `/binary` | Investigation de binaires en boîte noire, preuves d'exécution, requêtes de graphes et transfert | Beta |
| `/ghidra` | Pont RE Ghidra : attacher/importer des projets `.gpr`, diff inter-versions, export de résultats | Beta |
| `/audit` | Revue de code systématique guidée par hypothèses et ancrée dans les outils | Beta |
| `/review` | Interroger l'état d'audit : résultats, lacunes, couverture, notes d'opérateur | Stable |
| `/annotate` | Attacher des annotations en prose libres par fonction (notes de revue d'opérateur) | Stable |
| `/validate` | Pipeline de validation d'exploitabilité multi-étapes (Étapes 0-F) | Stable |
| `/diagram` | Cartes visuelles Mermaid à partir des sorties JSON de `/understand` et `/validate` | Beta |
| `/codeql` | Analyse approfondie CodeQL uniquement avec pré-filtrage SMT dataflow | Stable |
| `/analyze` | Analyser les résultats SARIF existants avec LLM, sans réanalyse | Stable |
| `/openant` | Analyse de code source par LLM OpenAnt : analyse AST plus raisonnement LLM par fonction | Beta |
| `/sca` | Analyse de composition logicielle : dépendances, avis, signaux de chaîne d'approvisionnement, SBOMs et correctifs | Beta |
| `/cve-diff` | Découvrir et différencier le commit de correction d'un CVE à travers OSV, NVD, GitHub et GitLab | Beta |
| `/cve-env` | Construire et vérifier un environnement Docker exécutant l'application affectée par un CVE à sa version pré-correctif | Expérimental |
| `/exploit` | Générer du code d'exploit de preuve de concept | Beta |
| `/patch` | Générer des correctifs sécurisés pour les vulnérabilités confirmées | Beta |
| `/fuzz` | Fuzzing de binaires avec AFL++ et analyse de crash | Stable |
| `/crash-analysis` | Analyse autonome de cause racine pour les crashes C/C++ | Stable |
| `/oss-forensics` | Investigation forensique étayée par des preuves pour les dépôts GitHub | Stable |
| `/project` | Espaces de travail nommés pour organiser les exécutions et suivre les résultats dans le temps | Stable |
| `/describe` | Décrire une cible : mix de langages, système de build, lacunes d'outils, estimation de coût (lecture seule) | Stable |
| `/threat-model` | Créer, inspecter et maintenir des modèles de menace par projet | Stable |
| `/sage` | Couche de mémoire persistante (stocker, rappeler, lier, corroborer) | Stable |
| `/ask` | Envoyer un prompt libre à n'importe quel modèle LLM configuré | Stable |
| `/scorecard` | Inspecter la fiabilité par modèle à travers les classes de décision | Stable |
| `/frida` | Instrumentation dynamique via Frida | Alpha |
| `/web` | Analyse d'applications web : crawl, intégration ffuf/nuclei, injection vérifiée par oracle, callbacks SSRF aveugles | Beta |

---

## Comment fonctionne le pipeline

Commencez par créer un projet pour que toutes vos exécutions aboutissent au même endroit :```
/project create myapp --target /path/to/code   # create a project first
/project use myapp                             # set it as active
/understand --map                              # map the attack surface
/agentic --threat-model --validate             # map, model, scan, validate
/project findings                              # review everything in one place

`/understand` construit une carte de contexte des points d'entrée, des frontières de confiance et des sinks avant qu'une seule ligne de scan ne soit exécutée. `/agentic` exécute ensuite Semgrep et CodeQL, déduplique les résultats et envoie chacun d'eux pour validation selon la méthodologie exploitation-validator :

Avec `--threat-model`, RAPTOR exécute d'abord la carte, crée `threat-model.json` et `THREAT_MODEL.md` si le projet ne les possède pas déjà, puis injecte une version compacte dans `/understand`, l'analyse autonome et `/validate`. Les threat models existants du projet sont préservés sauf si vous passez `--threat-model-refresh` ; les cartes de repli obsolètes sont refusées sauf si vous passez explicitement `--threat-model-use-stale`. Il transforme également les flux non vérifiés cartographiés en SARIF candidats afin que les oublis des scanners ne tuent pas l'exécution. C'est un contexte détenu par l'opérateur, pas une preuve magique : les résultats nécessitent toujours des preuves dans le code ou une confirmation adossée à un oracle. Voir `docs/threat-model.md`.

- Étape A : le motif est-il réellement une vulnérabilité, ou l'outil fait-il du pattern-matching sur du bruit ?
- Étape B : de quoi un attaquant a-t-il besoin pour l'atteindre, et qu'est-ce qui fait obstacle ?
- Étape C : le chemin de code existe-t-il réellement ? peut-il être atteint depuis l'extérieur ?
- Étape D : verdict final -- s'agit-il de code de test, nécessite-t-il des préconditions irréalistes, le modèle se dérobe-t-il ?
- Étape E : faisabilité d'un exploit binaire (lorsqu'un artefact compilé est disponible)
- Étape F : auto-revue -- une étape antérieure s'est-elle dérobée ou s'est-elle contredite ?

Les résultats qui passent la validation obtiennent des PoC d'exploit et des correctifs générés. Une analyse croisée des résultats s'exécute à la fin pour identifier les causes racines partagées et les chaînes d'attaque.

`/validate` exécute ce même pipeline comme étape autonome si vous disposez déjà de résultats d'un scan précédent.

Pour un artefact compilé, `/binary <path>` exécute désormais une
investigation fondée sur les preuves plutôt que de déverser une pile d'artefacts
de reverse engineering bruts sur l'opérateur. En dessous, il construit toujours le manifeste lié par SHA-256,
le registre de preuves, la carte de contexte, la checklist et le graphe SQLite à partir des métadonnées de fichier,
des imports et des xrefs radare2. Les applications Mach-O bénéficient également d'un inventaire de slices, des métadonnées de bundle
et des sélecteurs de classes Objective-C / Swift ; le pseudocode à forte valeur est
persisté plutôt que de disparaître pendant l'exécution. Les exports de DLL PE, les dispatchers de pilotes Windows et les gestionnaires ioctl de modules du noyau Linux sont également traités comme
leurs propres candidats d'entrée, avec l'architecture PE lue depuis l'en-tête
COFF plutôt que devinée. La couche d'investigation interroge ensuite ce graphe,
classe les entrées externes avant les pistes de sinks génériques, découvre les binaires
auxiliaires/frères déclarés, et écrit un rapport compact divisé en faits,
inférences structurelles et hypothèses non prouvées. Les observations Frida, les témoins de crash de fuzzing,
les vérifications Z3 explicites et les diffs binaires peuvent ensuite ajouter des preuves plus solides.
RAPTOR conserve également le graphe d'appels interne nécessaire pour récupérer des candidats bornés
d'entrée-vers-parseur, afin qu'un callback d'application puisse être réduit à la
fonction interne qui appelle réellement `XML_Parse`, `d2i_X509`,
`jpeg_read_header` ou une autre surface de parseur réelle sans prétendre qu'il s'agit d'une
preuve de taint. `/binary trace-parser <run-dir>` est le suivi dynamique explicite :
il exécute la trace de parseur Frida ciblée, puis rafraîchit en place la même carte de contexte,
le handoff, le graphe et le rapport d'investigation. `/binary investigate --active` cartographie d'abord et ne lance une véritable
campagne de fuzzing que lorsqu'une frontière de harness concrète existe ; les cibles d'application, de DLL et de pilote obtiennent une étape de harness ou de snapshot à la place. `/binary harness` écrit une
spécification de harness adossée à des preuves pour l'entrée choisie et n'émet du code source candidat que lorsque le contrat ABI ou IOCTL est explicite. Il ne passe pas de « `memcpy` existe » à « c'est
exploitable » : les imports, les sélecteurs et les arêtes d'appel restent des candidats jusqu'à ce que
quelque chose de mécanique prouve davantage. Voir `docs/binary-analysis.md`.

---

## Analyse de composition logicielle

`/sca` analyse le volet dépendances et chaîne d'approvisionnement d'un projet. Ce n'est pas un simple lookup de CVE dans un fichier de requirements : RAPTOR découvre les manifestes, les lockfiles, les commandes d'installation en ligne, les dépendances de workflow et les sources de paquets de conteneurs/images de base, puis les normalise en une vue unique des dépendances.

Le scan enrichit les dépendances avec les avis OSV, CISA KEV, EPSS, CISA Vulnrichment/SSVC, l'atteignabilité, les signaux de preuve d'exploit, les contrôles d'hygiène, les heuristiques de chaîne d'approvisionnement, les résultats de politique de licence, et une revue/triage LLM optionnelle. Il émet des résultats natifs RAPTOR ainsi qu'une sortie SBOM et compatible CI :

- `findings.json` - résultats RAPTOR canoniques
- `report.md` - résumé lisible par un humain
- `sbom.cdx.json` - SBOM CycloneDX avec données VEX
- `findings.sarif` - sortie de code-scanning GitHub/GitLab

Commandes courantes :```bash
python3 raptor.py sca --repo /path/to/project
python3 raptor.py sca --repo /path/to/project --no-llm
python3 raptor.py sca --repo /path/to/project --fail-on-severity high --fail-on-kev
python3 raptor.py sca --repo /path/to/project fix
python3 raptor.py sca check PyPI django 4.2.10

Une fois rempli, le scanner résout les ID de packs vers des fichiers locaux et aucun appel réseau n'a lieu. Sans le cache, RAPTOR tentera de récupérer les packs du registre depuis semgrep.dev au moment du scan ; s'il est hors ligne, il abandonne gracieusement les packs non mis en cache et s'exécute avec les règles personnalisées uniquement.

CodeQL nécessite un accès réseau uniquement lors de la configuration initiale pour télécharger le CLI et les packs de requêtes. Une fois installé, il fonctionne hors ligne.

---

## Règles personnalisées

RAPTOR embarque plus de 200 règles d'analyse statique personnalisées, testées de manière adversariale pour éliminer les faux positifs :

- **Semgrep (~150 règles)** — règles de suivi de teinte (taint-tracking) et de motifs pour Python, Go, Java et JS/TS. Couvre SQLi, XSS, SSRF, SSTI, injection de commandes, désérialisation, XXE, injection LDAP/NoSQL, traversée de chemin, redirection ouverte, injection de log/en-tête, injection eval, ReDoS, pollution de prototype, mauvaise configuration JWT, cryptographie faible, TLS non sécurisé et secrets codés en dur.
- **Coccinelle (68 règles)** — correspondance structurelle pour C/C++. Sécurité mémoire (double free, use-after-free, free d'un pointeur non-base, free d'un tableau sur la pile, mémoire mmap'd, use-after-close), bugs d'entiers (débordement, extension de signe, double sizeof), fuites de ressources (incohérence popen/fclose, double close de fdopendir), gestion des tampons (strncpy sans NUL, incohérence de taille copy_user, off-by-one malloc/strlen), sécurité des gestionnaires de signaux, mauvaise utilisation d'API (domaine de drapeaux fcntl, SIGKILL/SIGSTOP, double byte-swap, tampon statique inet_ntoa), élimination des dead-store par le compilateur, confusion IS_ERR/PTR_ERR du noyau, injection de chaîne de format, courses TOCTOU, et plus encore.
- **CodeQL (8 requêtes)** — suivi de teinte interprocédural pour C++ (injection de chaîne de format, troncature d'entier, use-after-move, invalidation d'itérateur) et Java (XXE, désérialisation non sécurisée, injection de log, SSRF Spring).

Parcourez les règles directement : `engine/semgrep/rules/`, `engine/coccinelle/rules/`, `engine/codeql/queries/`. Celles-ci complètent les packs du registre Semgrep que RAPTOR récupère (`p/security-audit`, `p/owasp-top-ten`, `p/secrets` toujours ; packs par groupe de politiques comme `p/command-injection`, `p/jwt`, `p/xss` en plus) — le chevauchement est minime.

---

## Comment RAPTOR se vérifie lui-même

RAPTOR utilise une bonne partie de ses propres outils de sécurité, mais il vaut la peine d'être honnête sur ce qui bloque réellement une PR et ce qui s'exécute simplement en arrière-plan pour nous garder honnêtes. Une partie de cela est un verrou strict, une partie est une vérification planifiée, et une partie n'est qu'un benchmark que nous conservons pour pouvoir dire quand nous avons empiré les choses. La ventilation plus complète, y compris les paramètres réels et comment reproduire les vérifications, se trouve dans `docs/ci-controls.md`.

| Contrôle | Ce qu'il vérifie | Déclencheur | Config / preuve |
|---|---|---|---|
| Ruff | Linting de correction Python (`F401`, `F811`, `F821`, `F841`) | Verrou de diff PR, plus audit hebdomadaire de l'arborescence complète | `pyproject.toml`, `.github/workflows/lint.yml` |
| Pytest | Frontières rapides unitaires/intégration, niveaux spécifiques aux sous-systèmes (via répartition par graphe d'imports), audit d'enveloppe de prompt | PRs, pushes vers `main`, file de fusion, suite complète planifiée | `pytest.ini`, `.github/workflows/tests.yml`, `.github/workflows/nightly.yml` |
| CodeQL Advanced | Analyse de code Python, C/C++ et GitHub Actions avec restriction de portée par graphe d'imports | PRs, pushes vers `main`, file de fusion, planification hebdomadaire | `.github/workflows/codeql.yml`, `.github/codeql/codeql-config.yml` |
| Durcissement des workflows | Actions tierces épinglées par SHA, permissions au moindre privilège, linting des métadonnées de commandes | Chaque modification de workflow et chaque exécution de lint | `.github/workflows/`, `.github/scripts/check_command_metadata.py` |
| Lint des labels de corpus | Validation du schéma des labels du corpus d'audit et vérification des épingles upstream | PRs (labels modifiés), balayage complet hebdomadaire | `.github/workflows/corpus-labels.yml` |
| Verrou PR SCA de RAPTOR | Régressions de dépendances et de chaîne d'approvisionnement introduites par une PR | Modifications de manifeste / lockfile / workflow | `.github/workflows/sca-pr-gate.yml` |
| Auto-bump SCA de RAPTOR | Durcissement mécanique des dépendances et propositions de mise à niveau sûres | Planification hebdomadaire, exécution manuelle | `.github/workflows/sca-self-bump.yml` |
| Corpus de compromission SCA | Si les compromissions de dépendances connues déclenchent toujours le signal attendu | Planification hebdomadaire, modifications de PR pertinentes | `test/data/sca-e2e/compromise-corpus/`, `.github/workflows/sca-compromise-check.yml` |
| Détecteurs d'invariants de dépôt | Détection de code mort / d'appel erroné, dérive de documentation des variables d'environnement, garde-fous de liste de vocabulaire, formes d'octets JSON canoniques, lint d'import de dépendances optionnelles | Verrou PR (job `repo-invariants` de `lint.yml`), plus balayage quotidien | `.github/workflows/lint.yml`, `.github/workflows/miswiring-scan.yml`, `.github/scripts/*_baseline.json` |
| Calibration SCA + corpus de stress | Si la notation des risques et la couverture du parseur dérivent au fil du temps | Jobs planifiés hebdomadaires / mensuels | `packages/sca/data/calibration/`, `.github/workflows/refresh-sca-calibration.yml`, `.github/workflows/sca-stress-sweep.yml` |
| Corpus de flux de données | Suivi de précision / rappel / catégorie de FP pour le comportement du validateur | Benchmark exécuté par le développeur et tests de corpus | `core/dataflow/corpus/`, `core/dataflow/scripts/corpus-metrics` |
| Garde du doc des contrôles CI | Les chemins documentés existent, la config ruff correspond, le README pointe vers le doc | PRs | `.github/tests/test_ci_controls_docs.py` |

Actuellement non appliqué : `mypy` est épinglé dans `pyproject.toml` mais ne bloque rien ; le formatage Ruff n'est pas appliqué ; Semgrep fait partie de la surface de scanner de RAPTOR, mais nous n'avons pas encore de workflow Semgrep dédié « scanner RAPTOR avec RAPTOR ».

---

## Utiliser un autre LLM

RAPTOR possède deux couches de modèles distinctes, et il vaut la peine de comprendre comment les deux fonctionnent avant de modifier quoi que ce soit.

La **couche d'orchestration** est Claude Code -- mais uniquement pour le shell interactif `raptor` (cette couche conversationnelle à slash-commandes). Le CLAUDE.md, les skills et les commandes s'exécutent tous comme instructions Claude Code à cet endroit. Pour changer quel modèle Claude orchestre cette couche, utilisez le drapeau `--model` de Claude Code ou la commande `/model` dans une session. Si vous ne voulez pas du tout de cette couche, voir [Exécution entièrement autonome](#running-fully-standalone-no-claude-code) ci-dessous.

La **couche de répartition d'analyse** est le LLM qui analyse les constats de vulnérabilité individuels. Elle est distincte de la couche d'orchestration et peut être n'importe quel fournisseur pris en charge. Configurez-la dans `~/.config/raptor/models.json` :```json
{
  "models": [
    {
      "provider": "anthropic",
      "model": "claude-opus-4-6",
      "api_key": "sk-ant-...",
      "role": "analysis"
    },
    {
      "provider": "openai",
      "model": "gpt-5.4",
      "api_key": "sk-...",
      "role": "analysis"
    },
    {
      "provider": "anthropic",
      "model": "claude-sonnet-4-6",
      "api_key": "sk-ant-...",
      "role": "aggregate"
    }
  ]
}

Les rôles de modèle vous permettent d'attribuer différents modèles à différentes tâches :

| Rôle | Ce qu'il fait |
|------|-------------|
| `analysis` | Valide et analyse chaque constatation (Étapes A-F) |
| `code` | Écrit les PoC d'exploitation et le code de correctif |
| `consensus` | Vote de second avis sur les vrais positifs |
| `aggregate` | Optionnel. Synthèse narrative rédigée par LLM en complément de la corrélation déterministe multi-modèles, écrite dans `aggregation.json` et le fichier final `agentic-report.md` |
| `fallback` | Utilisé si le modèle principal échoue ou atteint les limites de débit |

Si aucun rôle n'est défini, le premier modèle de la liste gère tout. Pour l'analyse de code source multi-modèles, configurez deux modèles `analysis` ou plus — vous obtiendrez la corrélation déterministe par défaut. Le rôle `aggregate` est optionnel et ajoute un résumé rédigé par LLM par-dessus :```bash
python3 raptor.py agentic --repo /code \
  --model claude-opus-4-6 \
  --model gpt-5.4 \
  --aggregate claude-sonnet-4-6

Ollama fonctionne bien pour l'analyse ; la fiabilité pour la génération de code d'exploit/patch dépend de l'échelle du modèle et de la quantification plutôt que d'être une propriété fixe des modèles locaux — voir [Quality Tradeoffs](https://github.com/gadievron/raptor/blob/main/llm.md#quality-tradeoffs) dans le guide LLM, et consultez `/scorecard` pour ce que votre modèle spécifique mesure réellement.

### Exécution entièrement autonome (sans Claude Code)

`bin/raptor` -- le shell interactif avec la bannière et les commandes slash, c'est-à-dire cette couche conversationnelle -- s'exécute directement dans le CLI Claude Code et nécessite toujours sa propre connexion. Les mécanismes réels en dessous n'en ont pas besoin : `python3 raptor.py <mode>` est un CLI Python simple sans aucune dépendance à Claude Code.```bash
# No `claude` process involved at any point
python3 raptor.py doctor                        # status check -- explicitly "no claude needed"
python3 raptor.py agentic --repo /path/to/code   # scan -> dedup -> analysis
python3 raptor.py scan --repo /path/to/code

Pointez `models.json` / `OLLAMA_HOST` vers une instance Ollama locale (voir ci-dessus) et tout ce chemin ne communique jamais avec Anthropic -- utile pour les machines isolées ou le matériel local uniquement. Vous perdez la couche conversationnelle de commandes slash (ce chat) ; le pipeline scan/analyse/exploit lui-même n'est pas affecté.

### Court-circuit du tier rapide + le tableau de bord des modèles

Lorsque votre modèle de tier d'analyse a un frère moins cher chez le même fournisseur (Anthropic Opus → Haiku, OpenAI 5.x → 4o-mini, Gemini Pro → Flash-Lite, Mistral Large → Small), RAPTOR l'utilisera comme préfiltre sur les consommateurs qui se connectent au substrat (codeql aujourd'hui ; SCA et autres à mesure que les suivis arrivent). Le modèle bon marché ne court-circuite que sur des **faux positifs confiants** ; les cas ambigus et les vrais positifs confiants exécutent toujours l'analyse complète. La confiance s'accumule par cellule `(model, decision_class)` — RAPTOR enregistre l'accord entre le modèle bon marché et le modèle complet et ne court-circuite qu'une fois que la borne supérieure de Wilson à 95 % sur le taux d'erreur de la cellule tombe à 5 % ou moins.

Pour inspecter ce dans quoi vos modèles excellent, utilisez `/scorecard` (ou directement : `libexec/raptor-llm-scorecard list`). Le tableau de bord est global (les leçons se transmettent entre projets) et persiste dans `out/llm_scorecard.json`.

---

## Projets

Sans projet, chaque exécution obtient son propre répertoire horodaté sous `out/`. Avec un projet, tout va au même endroit et vous obtenez des résultats fusionnés, un suivi de couverture et des diffs entre les exécutions.```bash
/project create myapp --target /path/to/code -d "Short description"
/project use myapp

/scan
/understand --map
/validate

/project status                # all runs, pass/fail, timestamps
/project findings              # merged findings across all runs
/project findings --detailed   # per-finding detail
/project coverage --detailed   # which files were reviewed
/project diff myapp run1 run2  # compare two runs
/project report                # full merged report
/project clean --keep 3        # remove old runs, keep the last 3
/project export myapp /tmp/myapp.zip
/project none                  # clear active project

La séparation signifie que vous pouvez exécuter la couche Python depuis un pipeline CI (`python3 raptor.py scan --repo ...`) et obtenir une sortie SARIF structurée sans Claude Code, ou l'exécuter de manière interactive avec le workflow agentique complet.

---

## Forensique OSS

`/oss-forensics` enquête sur les dépôts GitHub publics en utilisant des preuves provenant de plusieurs sources : l'API GitHub, GH Archive (historique d'événements immuable via BigQuery), la Wayback Machine et l'historique git local. Il exécute un pipeline structuré allant de la collecte de preuves à la formation d'hypothèses jusqu'à un rapport forensique final.

Nécessite `GOOGLE_APPLICATION_CREDENTIALS` pour l'accès à BigQuery. Voir `.claude/commands/oss-forensics.md` pour plus de détails.

---

## Personas expertes

Huit personas expertes sont disponibles à la demande. Chargez-en une lorsque vous souhaitez une perspective différente sur une découverte ou une technique spécifique :```
Exploit Developer (Mark Dowd)                  Exploit PoC generation
Crash Analyst (Charlie Miller / Halvar Flake)  Crash analysis and exploitability assessment
Security Researcher                            General adversarial code review
Patch Engineer                                 Secure fix generation
Penetration Tester                             Realistic attack scenario assessment
Web Researcher (James Kettle)                  Web endpoint research (smuggling, cache poisoning, SSRF)
Fuzzing Strategist                             Corpus design and triage
Binary Exploitation Specialist                 ROP, heap, and memory corruption

Conserver `/web`, Z3, SAGE et les SDK des fournisseurs cloud comme extras optionnels évite de rendre l'installation RAPTOR par défaut plus lourde et plus fragile qu'elle ne doit l'être.