OSS-CRS: Liberating AIxCC Cyber Reasoning Systems for Real-World Open-Source Security

Ce papier présente OSS-CRS, un cadre open-source et localement déployable qui rend les systèmes de raisonnement cybernétique (CRS) de la compétition DARPA AIxCC utilisables pour la sécurité réelle, permettant notamment de découvrir dix nouveaux bugs dans des projets open-source.

L'essentiel

🏠 Le Problème : Des Super-Héros coincés dans une cage

Imaginez que le gouvernement américain (DARPA) organise un grand concours de "Super-Héros de la cybersécurité". L'objectif ? Créer des robots intelligents capables de trouver des failles dans des logiciels (comme des trous dans un mur) et de les réparer tout seuls, sans aide humaine.

Sept équipes ont gagné. Leurs robots étaient incroyables ! Mais il y avait un gros problème : ces robots étaient prisonniers d'une cage dorée.

• La cage : Ils ne fonctionnaient que sur des serveurs cloud très spécifiques (comme des immeubles géants en Azure) qui ont été démolis juste après le concours.
• Le résultat : Aujourd'hui, même si le code est gratuit, personne ne peut utiliser ces robots. C'est comme si vous aviez la recette du meilleur gâteau du monde, mais qu'elle nécessitait un four qui n'existe plus. De plus, chaque robot était un "monstre" unique : on ne pouvait pas prendre le moteur de l'un et le mettre dans l'autre.

🔨 La Solution : OSS-CRS, le "Kit de Déménagement Universel"

Les auteurs de l'article (des chercheurs du Georgia Tech et de Microsoft) ont créé OSS-CRS.

Imaginez que vous avez sept voitures de course différentes, chacune conçue pour rouler sur une piste de Formule 1 spécifique qui n'existe plus. OSS-CRS, c'est comme un garage universel et modulaire qui permet de :

1. Sortir les voitures de leur cage : On peut les faire rouler sur n'importe quel terrain (votre propre ordinateur ou un serveur local).
2. Mélanger les pièces : Si la voiture A a le meilleur moteur (pour trouver les bugs) et la voiture B a le meilleur système de freinage (pour réparer les bugs), on peut les assembler pour créer une voiture encore plus performante.
3. Gérer le budget : Ces robots utilisent des intelligences artificielles (LLM) qui coûtent cher en "essence" (argent). OSS-CRS agit comme un comptable rigoureux qui s'assure que chaque robot ne dépasse pas son budget, pour ne pas vous ruiner.

🚀 Comment ça marche ? (L'analogie de l'usine)

Pour faire fonctionner ces robots sur de vrais logiciels (comme ceux utilisés par les pompiers, les banques, etc.), OSS-CRS utilise trois étapes clés :

1. La Préparation (Le Menu) : On dit au système : "Voici le logiciel à réparer, et voici quels robots on veut utiliser."
2. La Construction (L'Usine) : Le système prépare l'usine. Il installe les outils nécessaires sans toucher au logiciel lui-même.
3. L'Action (La Chasse) : Les robots se mettent au travail.
   • Le Fuzzer (le détective) cherche les bugs en jetant des milliers de pièces de monnaie sur le logiciel pour voir si ça casse.
   • Le Patcheur (le réparateur) utilise l'IA pour écrire le code qui répare le trou.
   • Le Vérificateur (le contrôleur) s'assure que la réparation fonctionne et n'a pas cassé autre chose.

Tout cela se passe dans des boîtes isolées (des conteneurs Docker). Si un robot plante, les autres continuent de travailler. Ils échangent leurs trouvailles via un tableau d'affichage commun (un dossier partagé) sans avoir besoin de se parler directement.

🏆 Les Résultats : La Preuve par l'Exemple

Pour prouver que leur idée fonctionne, les chercheurs ont pris le robot gagnant du concours (appelé ATLANTIS), l'ont sorti de sa cage, et l'ont fait courir sur 8 vrais projets open-source (comme des bibliothèques de code utilisées par des millions de personnes).

Le résultat ?

• Ils ont trouvé 10 nouveaux bugs (des failles de sécurité) que personne ne connaissait.
• 3 de ces bugs étaient très graves (comme des portes ouvertes dans un coffre-fort).
• Le système a non seulement trouvé les bugs, mais a aussi proposé des réparations validées.

💡 En résumé

OSS-CRS, c'est le pont entre la science-fiction des compétitions de cybersécurité et la réalité du terrain.

• Avant : Des robots géniaux mais inutilisables, coincés dans un cloud qui a disparu.
• Maintenant : Une boîte à outils ouverte où l'on peut installer, mélanger et faire tourner ces robots intelligents sur n'importe quel logiciel, tout en surveillant les coûts.

C'est comme passer d'une collection de voitures de course enfermées dans un musée à un garage où n'importe quel mécanicien peut assembler les meilleures pièces pour construire la voiture de sécurité la plus efficace du monde. Et le meilleur ? Tout est gratuit et ouvert à tout le monde !

Résumé technique

1. Problématique

Le papier identifie un fossé critique entre les avancées théoriques démontrées lors du défi AIxCC (AI Cyber Challenge) de la DARPA et leur applicabilité réelle dans l'écosystème du logiciel libre (Open Source).

• Contexte : Sept équipes ont développé des Systèmes de Raisonnement Cybernétique (CRS) autonomes capables non seulement de découvrir des vulnérabilités, mais aussi de générer des preuves d'exploitation (PoV) et de synthétiser des correctifs (patches) validés.
• Obstacles à l'adoption : Malgré l'open-sourcing de ces systèmes, ils restent inutilisables en dehors des équipes originales pour trois raisons principales :
  1. Duplication d'infrastructure : Chaque équipe a réimplémenté indépendamment les mêmes services de plateforme (orchestration, gestion de base de données, proxy LLM), gaspillant des efforts de développement.
  2. Verrouillage Cloud (Cloud Lock-in) : Les systèmes sont conçus pour l'infrastructure Azure/Kubernetes spécifique du concours, désormais démantelée. Par exemple, le système gagnant (ATLANTIS) nécessitait plus de 20 machines virtuelles Azure et ne peut pas fonctionner localement sans son environnement d'origine.
  3. Conception Monolithique : Les techniques d'analyse sont encapsulées dans des systèmes monolithiques, empêchant les chercheurs de comparer, de combiner ou de réutiliser des composants spécifiques (ex: un fuzzer d'une équipe avec un correcteur d'une autre).

2. Méthodologie : OSS-CRS

Les auteurs proposent OSS-CRS, un cadre open-source, localement déployable et modulaire conçu pour exécuter et composer des techniques de CRS sur des projets réels (format OSS-Fuzz).

Architecture et Composants Clés :

• Interface Standardisée (libCRS) : Une bibliothèque Python injectée dans chaque conteneur CRS, fournissant une API unifiée pour la gestion des artefacts (soumission de PoV, patches, seeds) et la validation des correctifs, indépendamment de l'infrastructure sous-jacente.
• Modèle d'Exécution en Trois Phases :
  1. Prepare : Construction des images conteneurs des CRS (indépendantes du projet cible).
  2. Build-Target : Compilation du projet cible avec instrumentation (sanitizers) et création d'images de base.
  3. Run : Exécution des conteneurs CRS isolés, échange d'artefacts et analyse.
• Gestion des Ressources et Budgets :
  • Isolation : Chaque CRS tourne dans des conteneurs Docker isolés avec des limites strictes de CPU, de mémoire et de réseau.
  • Budget LLM : Le système intègre un proxy (basé sur LiteLLM) qui gère les coûts des appels aux modèles de langage (LLM) par CRS, empêchant les dépassements de budget et permettant des comparaisons équitables.
• Échange d'Artefacts (Artifact Exchange) : Un mécanisme basé sur le système de fichiers (via un "sidecar") permet aux différents CRS d'échanger des données (seeds, PoV, patches) sans communication directe, favorisant l'exécution en ensemble (ensemble execution).
• Validation de Correctifs : Utilisation d'un "Builder Sidecar" qui applique les patches, reconstruit le projet de manière incrémentielle et exécute les tests de régression pour valider la correction sans casser la fonctionnalité existante.

3. Contributions Clés

1. Analyse Empirique : Identification et documentation des trois barrières de déploiement (duplication, cloud lock-in, monolithisme) à travers l'analyse des sept systèmes finalistes de l'AIxCC.
2. Framework OSS-CRS : Développement d'une infrastructure unifiée qui :
   • Abstrait la complexité de l'orchestration.
   • Permet l'exécution locale sans dépendance cloud.
   • Facilite la composition de techniques hétérogènes (ex: fuzzer + LLM + analyse statique).
3. Portage et Validation Réelle : Portage réussi du système gagnant ATLANTIS (et d'autres systèmes) vers OSS-CRS, démontrant que la logique de découverte de bugs peut être découpée de son infrastructure d'origine.
4. Outils et Documentation : Publication du code source, des spécifications d'interface (crs.yaml) et des scripts de configuration pour permettre à la communauté de porter d'autres systèmes.

4. Résultats Expérimentaux

Les auteurs ont évalué OSS-CRS en exécutant le portage d'ATLANTIS sur 8 projets OSS-Fuzz (C/C++ et Java) de tailles et de complexités variées.

• Découverte de Vulnérabilités : Le système a découvert 10 bugs previously unknown (zéro-jour) sur les 8 projets.
  • Parmi eux, 3 sont de haute sévérité.
  • Les bugs incluent des problèmes de sécurité mémoire, des erreurs de logique, des comportements non définis (CWE-476, CWE-674, CWE-681), et non seulement des crashes classiques.
• Validation des Correctifs : Pour chaque bug, le système a généré un patch candidat, validé automatiquement via le pipeline de reconstruction et de test, et soumis aux mainteneurs.
• Statut des Rapports : Au moment de la rédaction, 3 bugs ont été corrigés par les mainteneurs, 1 confirmé, et 6 en attente de réponse.
• Efficacité du Portage : Le portage d'ATLANTIS a nécessité environ 3 à 4 jours-homme par sous-système, confirmant que la logique d'analyse centrale est indépendante de l'infrastructure de déploiement.

5. Signification et Impact

• Démocratisation de la Sécurité Autonome : OSS-CRS transforme des systèmes de recherche fermés et dépendants du cloud en outils pratiques et déployables localement pour la communauté open-source.
• Passage de la Découverte à la Remédiation : Contrairement aux outils actuels qui s'arrêtent souvent à la découverte (laissant les mainteneurs avec des rapports non vérifiés), OSS-CRS fournit des correctifs validés, réduisant la charge de travail des mainteneurs et le risque de "CVE slop" (rapports non pertinents).
• Reproductibilité et Comparaison : En fournissant une interface standardisée et une gestion des ressources, le framework permet aux chercheurs de comparer objectivement différentes techniques (fuzzing, LLM, analyse statique) et d'expérimenter des combinaisons (ensembles) pour optimiser les résultats.
• Avenir de la Recherche : Le papier pose les bases pour un benchmarking systématique des CRS (similaire à FuzzBench pour les fuzzers) et encourage une collaboration communautaire pour améliorer la sécurité des logiciels libres à grande échelle.

En résumé, OSS-CRS ne se contente pas de répliquer les résultats du concours AIxCC ; il résout les problèmes d'ingénierie qui empêchaient leur adoption, ouvrant la voie à une sécurité logicielle autonome, abordable et collaborative pour l'écosystème open-source mondial.