Security Harness

Un harnais de revue de sécurité applicative multi-agents pour Claude Code (et, à terme, d'autres agents IA). Une compétence de routage unique dispatche vers un pipeline complet de sécurité offensive qui cartographie une base de code, traque les vulnérabilités avec une base de connaissances par classe, enchaîne les découvertes en escalades, vérifie l'impact réel, et rapporte vers README / JSON / SARIF / doc / PDF.

Périmètre : ce harnais effectue une analyse statique (revue de code source, traçage de flux de données, construction de PoC/payload) sur du code que vous possédez ou êtes autorisé à tester. Il n'attaque pas de systèmes tiers en production.

Contenu```

security-harness/ # a plugin marketplace └── plugins/security-harness/ ├── skills/ │ ├── sh-router # single entry point - routes any appsec request │ ├── sh-security-review # the pipeline orchestrator (Stages 0-5) │ └── sh-kb-* (15) # per-vuln-class knowledge bases ├── agents/ │ ├── sh-recon # map: Graft graph + stack/SBOM/CVE + attack surface │ ├── sh-hunter # find: source→sink hunting, one per class (parallel) │ ├── sh-chainer # escalate: combine findings into attack chains │ ├── sh-verifier # confirm: offensive + seceng + dev verification + PoC │ └── sh-reporter # deliver: README/JSON/SARIF/HTML/PDF/doc └── references/ # shared contracts (finding schema, SARIF map, state files, rubrics)

### Classes de vulnérabilités couvertes (les compétences `sh-kb-*`)

contrôle d'accès (IDOR/BOLA/élévation de privilèges) · sqli · xss · ssrf · injection (cmd/code/SSTI/LDAP) · auth (session/JWT)
· désérialisation · path-traversal (LFI/RFI) · secrets · csrf · xxe · open-redirect · crypto · race-conditions
· file-upload. Les CVE de dépendances/SBOM sont gérés par l'étape de reconnaissance.

## Installation

Le harness est fourni pour plusieurs agents. Les détails complets du packaging et la checklist
de release sont dans [`docs/DISTRIBUTION.md`](https://github.com/dmdhrumilmistry/security-harness/blob/main/docs/DISTRIBUTION.md).

**Claude Code** - ajoutez ce dépôt comme marketplace de plugins et installez le plugin :```
/plugin marketplace add dmdhrumilmistry/security-harness
/plugin install security-harness

/plugin marketplace add accepte l'un des éléments suivants : un owner/repo GitHub (comme ci-dessus), une URL git complète (https://github.com/dmdhrumilmistry/security-harness.git), ou un chemin local vers un clone (par exemple /plugin marketplace add ./security-harness depuis le répertoire contenant votre copie de travail). Exécutez ensuite /plugin install security-harness et rechargez lorsque cela vous est demandé.

Gemini CLI - une extension native, manifeste à la racine du dépôt :```bash gemini extensions install https://github.com/dmdhrumilmistry/security-harness

**opencode, Codex, ou tout agent [agentskills.io](https://agentskills.io)** - copiez les
skills dans un répertoire de découverte. Codex récupère en outre `AGENTS.md` de lui-même :```bash
git clone https://github.com/dmdhrumilmistry/security-harness
cd security-harness
python3 scripts/sync-agent-skills.py --install agents     # ~/.agents/skills
python3 scripts/sync-agent-skills.py --install opencode   # ~/.config/opencode/skills

Graft est installé et configuré automatiquement par le pipeline. L'étape 0 exécute npm install -g @nanonets/graft s'il est absent (nécessite Node/npm), puis graft init <target> --no-agents --no-global pour enregistrer le serveur MCP Graft et les hooks de fraîcheur pour le dépôt cible. Le graphe lui-même (<target>/graft/, auto-gitignoré) est construit pendant la reconnaissance. Pour pré-installer manuellement : npm install -g @nanonets/graft. La construction structurelle de Graft est gratuite et ne nécessite aucune clé API ; la passe LLM optionnelle --deep utilise GRAFT_API_KEY / GRAFT_PROVIDER / GRAFT_MODEL lorsqu'ils sont définis.

Les autres outils sont également auto-installés par l'étape 0 lorsqu'ils sont absents (via le gestionnaire de paquets présent sur la machine - winget/choco/scoop, brew, apt, npm/pip/go - voir references/tooling-setup.md). Les installations sont annoncées, privilégient les méthodes sans élévation de privilèges et ne bloquent jamais l'exécution : tout ce qui ne peut pas être installé est simplement marqué comme indisponible et le pipeline se rabat sur une alternative. L'étape 0 n'installe que ce qui comble un groupe de capacités manquant :

• SBOM : syft · CVE : l'un de grype (préféré), trivy, ou osv-scanner
• Rapports : wkhtmltopdf ou pandoc (pour PDF/DOCX) ; sinon vous obtenez report.html (ou un PDF via Chrome headless).

Tous sont optionnels - le pipeline se dégrade gracieusement vers la recherche native + l'analyse des manifestes si aucun ne s'installe.

Utilisation

Invoquez le routeur avec une requête en langage naturel :``` /sh-router full security review of ./api /sh-router find SQLi and IDOR in src/ /sh-router just map this codebase # recon only

Ou appelez directement le pipeline :```
/sh-security-review . classes:sqli,access-control,ssrf depth:deep
/sh-security-review . stage:report       # regenerate reports for the latest run

Contrôle des modèles et des coûts

Chaque étape s'exécute sur un modèle adapté à sa charge cognitive, de sorte que les tokens sont dépensés là où la qualité de la découverte en dépend réellement et économisés sur le travail mécanique. C'est le comportement par défaut - aucun argument nécessaire.

Étape	Modèle par défaut
recon	sonnet
hunt (par classe)	haiku pour les classes de motifs (secrets, crypto, open-redirect, csrf) · sonnet pour le traçage source→sink (sqli, xss, ssrf, injection, path-traversal, xxe, file-upload, auth) · opus pour les classes de logique profonde (access-control, race-conditions, deserialization)
chain	opus
verify	opus (le filtre de précision - maintenu robuste)
report	haiku

Remplacer avec l'argument models: (également transmis au routeur) :``` /sh-security-review . # default tiered map above /sh-security-review . models:max # every stage + hunter on opus (max quality, max cost) /sh-security-review . models:cheap # aggressive downshift (trades some verify precision) /sh-security-review . models:verify=opus,hunt=sonnet # per-stage overrides /sh-security-review . models:report=sonnet,hunt.pattern=sonnet # per-hunter-tier override

Stages : `setup, recon, hunt, chain, verify, report`. Modèles : `opus, sonnet, haiku, inherit`. Pour `hunt`,
un modèle seul aplatit tous les hunters sur celui-ci ; `hunt.pattern` / `hunt.trace` / `hunt.logic` ciblent un seul tier.
D'autres économiseurs de tokens sont intégrés : recon ne génère des hunters que pour les classes ayant une surface d'attaque réelle, les hunters
interrogent le graphe Graft au lieu de lire des fichiers entiers, et `findings.json`/SARIF sont générés par un
script déterministe plutôt que par le modèle.

### Sortie

Tout atterrit sous `<target>/.security-harness/<run-id>/` :

- `recon.md`, `codebase-map.json` - la carte (stack, SBOM, CVE, surface d'attaque).
- `findings.jsonl` → `chains.md` → `verified.jsonl` - l'état de travail (voir `references/state-files.md`).
- `reports/` - `README.md`, `findings.json`, `results.sarif`, `report.html`, `report.pdf` (+ `report.docx`).

Chaque finding publié porte une charge utile, un PoC, le verdict de vérification, les identifiants CWE/OWASP, le CVSS, et une
atténuation au niveau du code.

## Revue de pull request