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 avez lancé (afin que des commandes comme `/scan` y fassent référence 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 indicateurs comme `--project`, `--continue` et `--model` — voir `raptor --help`.

Lancer simplement `claude` depuis l'intérieur du répertoire du dépôt fonctionne aussi — Claude Code récupère la configuration de RAPTOR depuis le checkout — mais vous sautez tout ce que le lanceur fait ci-dessus : aucune vérification préalable, aucun suivi de couverture, et les commandes qui utilisent par défaut « le répertoire depuis lequel vous avez lancé » ne peuvent pas le voir.

**Important :** RAPTOR charge sa configuration depuis le répertoire du dépôt. Si vous exécutez `claude` depuis tout autre répertoire, vous obtenez un 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 aux zones de votre système de fichiers auxquelles vous ne voulez pas qu'ils accèdent, tout en limitant le rayon d'impact de tout code malveillant qui pourrait s'exécuter (par exemple via une attaque sur la chaîne d'approvisionnement). L'image est volumineuse (environ 6 Go). Elle part du devcontainer Microsoft Python 3.12 et y 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 attend que le framework RAPTOR (ce dépôt) soit monté dans `/workspaces/raptor` au démarrage. Vous pouvez éventuellement monter un dossier cible pour une 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"
]

D'une manière ou d'une autre, 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

Ceci exécute le pipeline complet : scan, déduplication, puis envoi de chaque résultat à travers les étapes de validation (A-F). Sur une base de code de taille moyenne avec ~50 résultats, prévoyez 10 à 30 minutes et 2 à 8 $ de coûts LLM de la couche d'analyse (selon le modèle). Le plafond de coût par défaut est de 10 $ par exécution ; ajustez-le 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 par jeton. 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 à 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 dans des sandbox utilisant les espaces de noms Linux, Landlock et seccomp. Le sandbox bloque l'accès réseau, restreint la visibilité du système de fichiers et limite la consommation de ressources. Consultez `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 issus 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 basés sur des listes.

---

## Ce que RAPTOR peut faire

| Commande | Ce qu'elle fait | Statut |
|---------|-------------|--------|
| `/agentic` | Workflow autonome complet : scan, 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 des variantes de vulnérabilités | Stable |
| `/binary` | Investigation binaire en boîte noire, preuves d'exécution, requêtes de graphe et transfert | Bêta |
| `/ghidra` | Pont RE Ghidra : attacher/importer des projets `.gpr`, diff entre versions, export des résultats | Bêta |
| `/audit` | Revue de code systématique guidée par hypothèses et fondée sur les outils | Bêta |
| `/review` | Interroger l'état de l'audit : résultats, lacunes, couverture, notes de l'opérateur | Stable |
| `/annotate` | Attacher des annotations prosaïques libres par fonction (notes de revue de l'opérateur) | Stable |
| `/validate` | Pipeline de validation d'exploitabilité en plusieurs étapes (Étapes 0-F) | Stable |
| `/diagram` | Cartes visuelles Mermaid à partir des sorties JSON de `/understand` et `/validate` | Bêta |
| `/codeql` | Analyse approfondie CodeQL uniquement avec pré-filtrage de flux de données SMT | Stable |
| `/analyze` | Analyser des résultats SARIF existants avec LLM, sans re-scan | Stable |
| `/sca` | Analyse de composition logicielle : dépendances, avis de sécurité, signaux de chaîne d'approvisionnement, SBOM et correctifs | Bêta |
| `/cve-diff` | Découvrir et différencier le commit de correctif d'une CVE sur OSV, NVD, GitHub et GitLab | Bêta |
| `/cve-env` | Construire et vérifier un environnement Docker exécutant l'application affectée par une CVE à sa version pré-correctif | Expérimental |
| `/exploit` | Générer du code de preuve de concept d'exploitation | Bêta |
| `/patch` | Générer des correctifs sécurisés pour les vulnérabilités confirmées | Bêta |
| `/fuzz` | Fuzzing binaire avec AFL++ et analyse des crashs | Stable |
| `/crash-analysis` | Analyse de cause racine autonome pour les crashs C/C++ | Stable |
| `/oss-forensics` | Investigation forensique fondée sur 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 : mélange de langages, système de build, lacunes d'outillage, estimation des coûts (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 une invite 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` | Scan d'applications web : crawl, intégration ffuf/nuclei, injection vérifiée par oracle, rappels SSRF aveugles | Bêta |

---

## Comment fonctionne le pipeline

Commencez par créer un projet afin que toutes vos exécutions soient regroupées 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 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 en utilisant 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 alimente une version compacte dans `/understand`, l'analyse autonome et `/validate`. Les modèles de menace 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 contrôlés cartographiés en SARIF candidat afin que les manques du scanner ne tuent pas l'exécution. Il s'agit d'un contexte détenu par l'opérateur, pas d'une preuve magique : les résultats nécessitent toujours une preuve de 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 bruit de correspondance de motifs ?
- É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 : décision finale — s'agit-il de code de test, nécessite-t-il des préconditions irréalistes, le modèle esquive-t-il ?
- Étape E : faisabilité de l'exploitation binaire (lorsqu'un artefact compilé est disponible)
- Étape F : auto-examen — une étape antérieure a-t-elle esquivé ou s'est-elle contredite ?

Les résultats qui passent la validation reçoivent des PoC d'exploitation et des correctifs générés. Une analyse transversale des résultats s'exécute à la fin pour trouver les causes racines partagées et les chaînes d'attaque.

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

Pour un artefact compilé, `/binary <path>` exécute désormais une
investigation axée sur les preuves plutôt que de déverser un tas d'artefacts
bruts de rétro-ingénierie sur l'opérateur. En dessous, il construit toujours le manifeste lié à SHA-256,
le registre de preuves, la carte de contexte, la liste de contrôle et le graphe SQLite à partir des métadonnées de fichier,
des imports et des xrefs radare2. Les applications Mach-O reçoivent également un inventaire de tranches, des
métadonnées de bundle et des sélecteurs de classes Objective-C / Swift ; le pseudocode à forte valeur est
conservé 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'ingress, l'architecture PE étant lue depuis l'en-tête
COFF plutôt que devinée. La couche d'investigation interroge ensuite ce graphe,
classe l'ingress externe avant les pistes génériques de sink, découvre les
binaires helpers/frères déclarés et écrit un rapport compact réparti entre 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
plus tard. RAPTOR conserve également le graphe d'appels interne nécessaire pour récupérer les
candidats bornés ingress-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 Frida étroite du parseur, puis actualise la même carte de contexte,
le handoff, le graphe et le rapport d'investigation en place. `/binary investigate --active` cartographie d'abord et ne lance une véritable
campagne de fuzzing que lorsqu'une frontière de harnais concrète existe ; les cibles app, DLL et
pilote reçoivent une étape de harnais ou de snapshot à la place. `/binary harness` écrit une
spécification de harnais adossée aux preuves pour l'ingress choisi et n'émet du code source candidat
que lorsque le contrat ABI ou IOCTL est explicite. Il ne bluffe pas son chemin 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 la composition logicielle

`/sca` analyse le côté dépendances et chaîne d'approvisionnement d'un projet. Il ne s'agit pas simplement d'une recherche de CVE dans les fichiers d'exigences : RAPTOR découvre les manifests, les lockfiles, les commandes d'installation en ligne, les dépendances de workflows 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'exploitation, les vérifications d'hygiène, les heuristiques de chaîne d'approvisionnement, les conclusions de politique de licence et un examen/tri LLM facultatif. Il émet des résultats natifs RAPTOR ainsi qu'un SBOM et une sortie compatible CI :

- `findings.json` - résultats canoniques RAPTOR
- `report.md` - résumé lisible par l'humain
- `sbom.cdx.json` - SBOM CycloneDX avec données VEX
- `findings.sarif` - sortie de scan de code 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 de registre depuis semgrep.dev au moment de l'analyse ; si hors ligne, il abandonne proprement les packs non mis en cache et s'exécute uniquement avec les règles personnalisées.

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 adversarial pour éliminer les faux positifs :

- **Semgrep (145 règles)** — règles de suivi de flux de données (taint) 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 logs/en-têtes, injection eval, ReDoS, pollution de prototype, mauvaise configuration JWT, crypto faible, TLS non sécurisé et secrets codés en dur.
- **Coccinelle (63 règles)** — correspondance structurelle pour C/C++. Sécurité mémoire (double free, use-after-free, free de pointeur non-base, free de tableau de pile, mémoire mmap, use-after-close), bugs d'entiers (dépassement, extension de signe, double sizeof), fuites de ressources (inadéquation popen/fclose, double fermeture fdopendir), gestion des tampons (strncpy sans NUL, inadéquation de taille copy_user, off-by-one malloc/strlen), sécurité des gestionnaires de signaux, mauvaise utilisation d'API (domaine de drapeau fcntl, SIGKILL/SIGSTOP, double inversion d'octets, tampon statique inet_ntoa), élimination des dead-stores par le compilateur, confusion IS_ERR/PTR_ERR du noyau, injection de chaînes de format, courses TOCTOU, et plus encore.
- **CodeQL (8 requêtes)** — suivi de flux de données interprocédural pour C++ (injection de chaînes de format, troncature d'entiers, use-after-move, invalidation d'itérateurs) et Java (XXE, désérialisation non sécurisée, injection de logs, SSRF Spring).

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

---

## Comment RAPTOR s'auto-vérifie

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 une porte stricte, une partie est une vérification planifiée, et une partie n'est qu'un benchmark que nous conservons pour savoir quand nous avons aggravé les choses. La ventilation complète, y compris les paramètres réels et la manière de 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`) | Porte de diff PR, plus audit hebdomadaire de l'arborescence complète | `pyproject.toml`, `.github/workflows/lint.yml` |
| Pytest | Limites rapides d'unité/intégration, niveaux spécifiques au sous-système (via dispatch par graphe d'imports), audit de l'enveloppe de prompt | PR, pushs vers `main`, file d'attente 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 rétrécissement de portée par graphe d'imports | PR, pushs vers `main`, file d'attente 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 étiquettes de corpus | Validation du schéma des étiquettes de corpus d'audit et vérification des épinglages amont | PR (étiquettes modifiées), balayage complet hebdomadaire | `.github/workflows/corpus-labels.yml` |
| Porte PR SCA RAPTOR | Régressions de dépendances et de chaîne d'approvisionnement introduites par une PR | Modifications de manifeste / fichier de verrouillage / workflow | `.github/workflows/sca-pr-gate.yml` |
| Auto-mise à niveau SCA RAPTOR | Durcissement mécanique des dépendances et propositions de mises à niveau sûres | Planification hebdomadaire, exécution manuelle | `.github/workflows/sca-self-bump.yml` |
| Corpus de compromission SCA | Vérifie 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` |
| Analyse de mauvais câblage | Détection de code mort / mauvais appel, dérive de documentation de variables d'environnement, garde-fous de liste de vocabulaire, lint d'imports de dépendances optionnelles | Planification quotidienne | `.github/workflows/miswiring-scan.yml`, `.github/scripts/*_baseline.json` |
| Calibration SCA + corpus de stress | Vérifie si la notation des risques et la couverture du parseur dérivent au fil du temps | Tâches planifiées hebdomadaires / mensuelles | `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égories de faux positifs pour le comportement du validateur | Benchmark exécuté par les développeurs et tests de corpus | `core/dataflow/corpus/`, `core/dataflow/scripts/corpus-metrics` |
| Garde du document de contrôles CI | Les chemins documentés existent, la config ruff correspond, le README pointe vers le document | PR | `.github/tests/test_ci_controls_docs.py` |

Non appliqué actuellement : `mypy` est installé dans `requirements-dev.txt` mais ne bloque rien ; le formatage Ruff n'est pas appliqué ; Semgrep fait partie de la surface de scan de RAPTOR, mais nous n'avons pas encore de workflow Semgrep dédié « scanner RAPTOR avec RAPTOR ».

---

## Utiliser un LLM différent

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 toujours Claude Code. Le CLAUDE.md, les compétences et les commandes s'exécutent tous comme des instructions Claude Code. Pour changer le modèle Claude qui orchestre RAPTOR, utilisez le drapeau `--model` de Claude Code ou la commande `/model` dans une session.

La **couche de dispatch d'analyse** est le LLM qui analyse les constatations de vulnérabilités individuelles. 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"
    }
  ]
}

| Rôle | Ce qu'il fait |
|------|-------------|
| `analysis` | Valide et analyse chaque résultat (É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 par-dessus la corrélation déterministe multi-modèles, écrite dans `aggregation.json` et le rapport 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 pour l’analyse mais produit des codes d’exploit et de patch peu fiables. Pour les tâches de génération de code, utilisez un modèle de pointe.

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

Lorsque votre modèle du niveau d’analyse dispose d’un équivalent 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 connectés au substrat (codeql aujourd’hui ; SCA et autres à venir). Le modèle bon marché ne court-circuite que sur les **faux positifs certains** ; les cas ambigus et les vrais positifs certains déclenchent toujours l’analyse complète. La confiance s’accumule par cellule `(modèle, classe_de_décision)` — RAPTOR enregistre l’accord entre le modèle bon marché et le modèle complet et ne court-circuite que lorsque la borne supérieure de Wilson à 95 % sur le taux d’erreur de la cellule tombe à 5 % ou moins.

Pour inspecter les points forts de vos modèles, utilisez `/scorecard` (ou directement : `libexec/raptor-llm-scorecard list`). Le tableau de bord est global (les enseignements s’appliquent à tous les 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 est regroupé au même endroit et vous obtenez des résultats fusionnés, un suivi de couverture et des différences 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 flux de travail agentique complet.

---

## Forensique OSS

`/oss-forensics` enquête sur les dépôts GitHub publics en utilisant des preuves provenant de multiples sources : l’API GitHub, GH Archive (historique immuable des événements via BigQuery), la Wayback Machine et l’historique git local. Il exécute un pipeline structuré allant de la collecte de preuves à la formulation 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 experts

Sept personas experts sont disponibles à la demande. Chargez-en un 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
Fuzzing Strategist                             Corpus design and triage
Binary Exploitation Specialist                 ROP, heap, and memory corruption