OWASP Top 10 for LLM Applications : un dépôt devenu archive
OWASP Top 10 for Large Language Model Apps (Part of the GenAI Security Project)
En bref
- De quoi s’agit-il ?
- Le dépôt historique du Top 10 OWASP pour les applications LLM ne reçoit plus de développement actif : le README renvoie vers GenAI-LLM-Top10 et vers la publication 2026. Voici ce qu'il contient encore, et pourquoi on peut malgré tout l'utiliser.
- À qui s’adresse-t-il ?
- Ce dépôt s'adresse à ceux qui citent, archivent ou traduisent une version figée du Top 10 LLM, pas à ceux qui veulent contribuer ou suivre les corrections. Les seconds doivent aller sur GenAI-Security-Project/GenAI-LLM-Top10.
- Puis-je l’utiliser commercialement ?
- À vérifier. La licence de ce dépôt n’entre pas dans les catégories que nous classons automatiquement : lisez son fichier LICENSE avant tout usage commercial.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 41 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Un dépôt dont le README annonce lui-même la fin
La première information utile ne se trouve pas dans le code mais dans l'avertissement en tête du README : ce dépôt est maintenu comme point d'entrée historique et archive. Le développement actif a migré vers GenAI-Security-Project/GenAI-LLM-Top10. Le README précise aussi que la release courante est l'OWASP GenAI LLM Top 10 2026, publiée le 4 août 2026. Autrement dit, le dépôt que l'on trouve en cherchant le nom du projet n'est plus celui où les choses se décident. Les nouvelles issues, les pull requests et le travail de release doivent être dirigés vers le dépôt actif, et le README fournit les liens correspondants, y compris un formulaire dédié aux errata de la release 2026. Ce n'est pas une mise en sommeil silencieuse : c'est une migration documentée, avec des badges qui indiquent la release courante et le dépôt actif. La dernière poussée enregistrée sur la branche main date du 5 août 2026, soit le lendemain de la publication 2026, ce qui est cohérent avec un dépôt qui sert surtout à rediriger et à conserver.
Ce que ce dépôt contient encore réellement
Le README décrit le contenu sans ambiguïté : des releases historiques, des traductions, des fichiers de travail et des supports associés. Le dossier Archive/ est cité comme l'endroit où trouver les publications antérieures et les traductions. Les releases listées confirment cette fonction d'archive : 2023-v1 et 2023-v1.1 datées du 11 novembre 2024, puis la release 2024 intitulée OWASP Top 10 for Large Language Model Applications - 2025, datée du 18 novembre 2024. Ces dates de publication GitHub ne correspondent pas aux millésimes des documents, ce qui est courant lorsque du contenu est importé après coup. Pour un lecteur qui doit citer une version précise dans un audit ou une politique interne, cette sédimentation est exploitable : chaque millésime a une étiquette de release identifiable, et les liens anciens continuent de fonctionner, ce que le README présente comme la raison d'être du dépôt. Le langage principal déclaré est Python, mais le matériel décrit reste documentaire : le README ne documente aucune bibliothèque, aucun module importable, aucune interface en ligne de commande. Il faut le dire franchement : chercher ici un package à installer est une erreur d'aiguillage.
Pourquoi le dépôt est en Python alors que le livrable est un document
L'écart entre le langage principal affiché et la nature du livrable mérite d'être signalé, car il induit en erreur au moment de l'évaluation. Un dépôt marqué Python laisse penser qu'on va trouver du code de détection, des règles, un scanner. Le README, lui, ne mentionne que des releases, des traductions, des fichiers de travail et un dossier Archive/. Le workflow visible dans le README est un pages-build-deployment, avec un badge d'état lié à la branche main. C'est donc une chaîne de publication de site statique, pas une chaîne de test ou de packaging. La conséquence pratique est simple : les outils habituels d'évaluation d'une dépendance logicielle, comme la lecture d'un fichier de dépendances ou l'examen d'une surface d'API, ne s'appliquent pas ici. Ce qu'on évalue, c'est la stabilité d'une URL, la disponibilité des artefacts historiques et la clarté de la redirection vers le dépôt actif. Sur ces trois points, le README est explicite et fournit les liens nécessaires.
Rien à installer, mais des chemins à connaître
Il n'existe pas de commande d'installation pour ce dépôt. Le README ne donne ni pip install, ni fichier de configuration, ni variable d'environnement. Prétendre le contraire serait inventer. Ce qu'un utilisateur peut faire, en revanche, est reproductible : cloner le dépôt pour conserver une copie locale des millésimes, ou pointer directement vers les ressources publiées. Les points d'entrée cités dans le README sont la page de la release 2026 sur genai.owasp.org, l'arborescence 2026/final du dépôt actif, et le formulaire d'errata de ce même dépôt actif. Pour le contenu historique, le chemin indiqué est ./Archive/. Pour le canal de discussion, le README mentionne le canal OWASP Slack #team-genai-top-10-llm, avec le lien d'invitation owasp.org/slack/invite. Pour le processus de contribution au sens large, l'adresse donnée est genai.owasp.org/contribute. Ces cinq ou six références suffisent à construire une procédure interne de veille : on fige une version dans ./Archive/, on cite la release 2026 via son URL, et on route toute correction vers le formulaire d'errata du dépôt actif.
La limite structurelle : un dépôt qui ne corrige plus
La limitation est inscrite dans la conception même du dépôt, et elle est sérieuse pour certains usages. Si une erreur est découverte dans la release 2026, elle ne sera pas corrigée ici. Le README dirige explicitement vers le formulaire release-errata.yml du dépôt GenAI-LLM-Top10. Une équipe qui aurait intégré ce dépôt dans un pipeline de conformité, avec une vérification automatique des mises à jour, surveillerait donc un dépôt dont la branche main ne bougera plus au rythme des publications. Le badge de release courante pointe vers genai.owasp.org, pas vers une release GitHub de ce dépôt. Autre point de friction : la licence. Le README annonce Creative Commons Attribution-ShareAlike 4.0 International, avec un badge CC BY-SA 4.0. L'API GitHub renvoie pourtant NOASSERTION, ce qui signifie que le fichier de licence n'a pas été reconnu automatiquement. Les deux informations ne sont pas contradictoires en soi, mais elles obligent à ouvrir le fichier LICENSE avant de réutiliser le contenu. La clause ShareAlike a des conséquences concrètes pour une traduction ou une adaptation interne, et je ne peux que renvoyer à la lecture du texte de licence plutôt que de trancher ici.
Face au dépôt actif, et face à un référentiel générique
La comparaison la plus directe est interne au projet : ce dépôt contre GenAI-Security-Project/GenAI-LLM-Top10. La différence n'est pas une question de fonctionnalités mais de cycle de vie. Le dépôt actif reçoit les issues, les pull requests et les errata, et héberge l'arborescence 2026/final. Le dépôt historique reçoit le trafic des liens anciens et conserve les traductions. Choisir l'un ou l'autre revient à choisir entre contribuer et citer. Un second point de comparaison, plus large, est celui d'un référentiel de vulnérabilités classique orienté composants et versions. Un tel référentiel énumère des failles identifiées dans des bibliothèques précises, avec des identifiants et des plages de versions affectées. Le Top 10 LLM fonctionne autrement : c'est une liste de catégories de risques, sans identifiant de vulnérabilité et sans correspondance directe avec un numéro de version de bibliothèque. Il ne remplace donc pas une base de CVE pour le tri automatisé, et il n'a pas été conçu pour cela. Il sert à structurer une revue de conception et une politique de risque, pas à alimenter un scanner.
Coût de maintenance et implications de licence
Le coût de maintenance de ce dépôt, pour un utilisateur, se réduit à la surveillance des liens. Comme le développement est ailleurs, il n'y a pas de montée de version à suivre ici, pas de rupture d'API à anticiper, pas de correctif de sécurité à appliquer. Le seul risque est celui d'une référence périmée : citer ce dépôt comme source de la version courante revient à citer une archive. Le coût réel se déplace donc vers le dépôt actif, où les errata et les retours sont traités. Sur la licence, le README indique CC BY-SA 4.0. Cette licence autorise la réutilisation et l'adaptation sous conditions d'attribution et de partage à l'identique. Pour une traduction, la clause de partage à l'identique implique que l'œuvre dérivée soit diffusée sous une licence compatible. Le dossier Archive/ contient justement des traductions, ce qui montre que l'exercice est prévu par le projet. Je ne donne pas de conseil juridique : la seule vérification fiable consiste à lire le fichier LICENSE du dépôt concerné et, pour les dérivés, à confirmer la licence applicable au millésime utilisé.
Conclusion éditoriale
Ce dépôt s'adresse à ceux qui citent, archivent ou traduisent une version figée du Top 10 LLM, pas à ceux qui veulent contribuer ou suivre les corrections. Les seconds doivent aller sur GenAI-Security-Project/GenAI-LLM-Top10. Avant toute reprise, vérifiez le fichier LICENSE du dépôt actif plutôt que le badge du README, qui annonce CC BY-SA 4.0 là où l'API GitHub renvoie NOASSERTION.
Notes de la communauté