security-audit

name	security-audit
description	Audit sécurité OWASP applicatif (secrets, injection, auth, IDOR, dépendances). Findings uniquement, pas d'autofix. Opus, invocation explicite.
version	1.0.0
platforms	["linux","macos"]
metadata	{"hermes":{"tags":["security","owasp","secrets","injection","auth","audit"],"related_skills":["github","verify-conformance","code-audit"],"model":"deepseek-v4-full"}}

security-audit

Adaptation de ed209 (52) — ULK → Hermes. Carte : docs/backlog/2026-06-28-SPEC-HERMES-SECURITY-AUDIT/CARD.md (P2, GitHub #265).

Audit sécurité OWASP Top 10 + secrets exposés + auth + dépendances vulnérables. Skill la plus coûteuse : scope restreint par défaut (PR diff / fichiers désignés), invocation explicite, politique no-autofix.

Runtime & modèles

• DeepSeek V4 full : raisonnement sécurité profond, détection de patterns subtils (injection indirecte, IDOR logique). Tier ULK opus → DeepSeek full — ne pas sous-doser l'effort de raisonnement, la détection chute sinon.
• Pas de délégation coding : politique no-autofix stricte. La skill émet des findings ; aucun correctif appliqué sans validation manuelle explicite → aucune écriture de code.

Vault

• rapport → <vault>/logs/security-audit/ horodaté + SHA du commit audité (idempotent sur SHA).

Procédure

1. Scope d'entrée : repo + fichiers ou PR diff (github) + profondeur (quick / full).
2. Checklist OWASP Top 10 adaptée au code applicatif (pas infra).
3. Détection secrets : regex entropy-based + patterns courants (API keys, tokens, passwords).
4. Dépendances : lecture lockfile + advisories GitHub Security si scope token disponible.
5. Rapport : finding · CWE/CVE · sévérité (CRITICAL/HIGH/MEDIUM/LOW) · fichier:ligne · recommandation.
6. Log vault avec SHA (idempotent).

Critères d'acceptation

• ≥ 8 des 10 catégories OWASP Top 10 couvertes.
• Détection secrets en clair (≥ 5 patterns).
• Chaque finding : CWE/CVE si applicable + fichier:ligne.
• Aucun correctif automatique sans validation explicite.
• Log vault horodaté avec SHA du commit.
• Refuse de s'exécuter si verify-conformance retourne CRITICAL.

Pièges

• Forcer un scope restreint par défaut ; avertir si l'utilisateur tente « tout le repo » (coût).
• Advisories via API GitHub Security = scope security_events : vérifier le token, sinon fallback lockfile.
• Pas de faux négatifs rassurants : un WARNING ambigu vaut mieux qu'un silence sur une injection.