Linus : la security list du kernel Linux « presque entièrement ingérable » à cause de l'AI slop

Linus Torvalds, le créateur du kernel Linux, dit que la mailing list de sécurité du projet est « presque entièrement ingérable, avec une duplication énorme due à différentes personnes qui trouvent les mêmes choses avec les mêmes outils ». La cause, c'est la recherche de vulnérabilités AI-assisted qui produit un firehose de rapports basse qualité — les maintainers overworked passent des heures à trier les duplicates et les faux positifs avant d'arriver aux vrais problèmes. helpnetsecurity a sorti l'histoire le 18 mai. La même dynamique apparaît dans l'article ArsTechnica de cette semaine sur les businesses de bug-bounty bombardés d'AI slop. Surface différente, même mécanique : les mêmes outils que les défenseurs utilisent pour scanner leur propre code, les attaquants et les bounty hunters les utilisent pour flooder les canaux de disclosure de vulnérabilité.

Le shift structurel que ça représente, c'est l'effondrement du signal-to-noise dans l'infrastructure de reporting de vulnérabilités. Pre-LLM, un security report à un maintainer était un artefact coûteux — quelqu'un avec du skill passait des heures à en produire un. Les maintainers triaient par qualité de signal. Post-LLM, le coût de génération a baissé d'ordres de grandeur pendant que le coût de review est resté constant. Les workflows de mailing list et de bug-bounty platform ont été conçus en assumant que l'asymétrie de coût favorisait le signal ; là, elle est inversée. La « duplication due à différentes personnes qui trouvent les mêmes choses avec les mêmes outils » de Torvalds, c'est exactement ça — plusieurs submitters qui roulent les mêmes scanners AI off-the-shelf contre le même kernel et surface les mêmes outputs, souvent sans assez de compréhension pour dédupliquer.

Pair ça avec la couverture d'aujourd'hui sur Synack, Lyrie, MetaBackdoor et TeamPCP. Synack a rapporté l'AI qui compresse la fenêtre d'exploit — les adversaires weaponizent les CVEs en heures. Lyrie ship du probing autonome côté défense. MetaBackdoor montre des attaques training-time qui bypassent les défenses côté contenu. TeamPCP démontre du vol de clés supply-chain via Trivy. Le problème de noise, c'est la cinquième couche : même si le tooling défensif, la vitesse d'attaquant, les menaces training-time, et l'intégrité supply-chain étaient tous addressés, l'infrastructure de reporting elle-même est actuellement débordée. Pour les builders qui maintiennent des projets open-source, ton canal de reporting de vulnérabilité est maintenant un problème de coût de triage, pas un problème de coût de découverte.

Lundi matin : si tu maintiens un projet open-source avec du reporting de vulnérabilité public (security@tonprojet.org, GitHub Security Advisories, programme HackerOne), set up un filtre de triage qui demande aux reporters de démontrer qu'ils ont roulé l'exploit produit, pas juste l'output du scanner. « Montre-moi le PoC qui marche, pas le finding du scanner » c'est le filtre le moins cher. Le problème de mailing list de Torvalds suggère que les normes de disclosure GPG-signed existantes filtrent pas assez. Pour les programmes bug-bounty, considère du tiered intake — des paid triage credits gated sur des reports déjà acceptés, ou des pénalités de rejection sur les submissions AI-slop. La question plus profonde : à quel point la norme de disclosure de sécurité open-source a besoin d'être redessinée autour de la nouvelle asymétrie de coût ? Torvalds qui appelle la security list du kernel ingérable, c'est le canari ; le reste du monde open-source va frapper le même mur.