1. Le problème : beaucoup d’alertes, peu d’attention
Un scanner sait produire des centaines de lignes. Cela ne veut pas dire que chacune mérite une interruption. Le vrai produit doit répondre à trois questions : est-ce réel, est-ce important maintenant, et peut-on le corriger sans casser autre chose ?
Agent Security a donc été conçu comme un cockpit transversal : un endroit indépendant des applications surveillées, capable de couvrir plusieurs comptes et organisations GitHub sans disposer d’un accès illimité.
2. Ce qui fonctionne aujourd’hui
- Quatre moteurs déterministes : Gitleaks pour les secrets, OSV-Scanner pour les dépendances, Trivy pour les vulnérabilités et configurations, Semgrep Community pour les motifs dangereux.
- Quatre profondeurs : contrôle ciblé des PR, audit light hebdomadaire, deep mensuel et adversarial trimestriel.
- Multi-GitHub : chaque compte ou organisation est un domaine de confiance distinct, avec sa propre installation et une liste explicite de dépôts.
- Mémoire : chaque finding reçoit une empreinte stable ; le système sait s’il est nouveau, récurrent, résolu ou rouvert.
- Priorité explicable : sévérité, criticité du dépôt, confiance du scanner, zone sensible et récidive alimentent le score.
- Cockpit dans HL-OS : score global, cadran par projet, date, lien vers les preuves, état des corrections et lecture rouge → vert.
- IA maîtrisée : OpenRouter analyse uniquement des métadonnées minimisées en Zero Data Retention. Un second, puis si besoin un troisième modèle d’une autre famille valide les cas incertains.
3. Les protections ne reposent pas sur la bonne volonté de l’IA
- Permissions minimales : l’agent d’audit lit les métadonnées, le contenu, les PR et les Actions — rien de plus.
- Allowlist explicite : aucun enrôlement automatique de tous les dépôts privés.
- Identifiants isolés : compromettre un domaine GitHub ne doit pas ouvrir les autres.
- Secrets hors du code : clés et identifiants restent dans les secrets GitHub, jamais dans le dépôt.
- Chaîne reproductible : Actions sensibles fixées sur des SHA immuables ; outils vérifiés et mises à jour par PR.
- Verdict déterministe : aucun modèle ne peut transformer seul un finding HIGH ou CRITICAL en « OK ».
4. Ce qu’on a repris — et ce qu’on a fait autrement
Blume a inspiré l’expérience : une posture globale immédiatement lisible, un cadran par projet, l’historique et la trajectoire avant/après correction. L’objectif n’est pas de reproduire son produit, centré sur l’observation des agents, mais d’appliquer sa clarté à la sécurité des dépôts.
Detail.dev a inspiré la logique produit : trouver des bugs est facile, sélectionner ceux qui comptent est difficile. D’où la mémoire des findings, la priorité contextuelle et, à terme, l’apprentissage à partir des corrections acceptées ou refusées.
La différence structurante d’Agent Security tient à ses frontières de confiance : scanners open source reproductibles, accès cloisonnés, verdict indépendant des LLM et agent de correction séparé.
5. Voir une faille ne suffit pas : il faut une boucle de correction
Le premier agent observe. Agent Security Fix, installé séparément, prépare un plan ou une PR brouillon. La branche principale n’est pas modifiée directement. La correction doit apporter ses preuves : tests, nouveau scan et diff limité.
Lorsqu’une correction est ambiguë, plusieurs modèles de familles différentes la relisent. En cas de désaccord, le système conserve le risque le plus prudent et demande davantage de preuves. L’objectif futur est d’autoriser l’auto-merge uniquement pour des changements faibles en risque, réversibles et entièrement validés.
6. Ce qui n’est pas présenté comme terminé
- La remédiation automatique ne couvre pas encore toutes les familles de findings.
- Les secrets, l’authentification, les paiements, les permissions, l’infrastructure et les migrations restent hors auto-merge.
- L’analyse adversariale doit encore être enrichie par des tests dynamiques : autorisations, rejeu de webhooks, SSRF, traversée de chemins et fuzzing.
- L’apprentissage à partir du délai de correction et des décisions d’équipe est une direction produit, pas une capacité annoncée comme acquise.