OWASP LLM Top 10 旧仓库：一份已经迁址的安全清单，还值不值得进你的依赖树

这个仓库现在解决的是链接问题，不是安全问题

多数人第一次搜到它，是想找一份可以直接贴进设计文档的 LLM 风险清单。但 README 顶部那段 IMPORTANT 说明已经把定位讲清楚了：本仓库作为 legacy entry point 和 historical archive 维护，活跃开发已经迁到 GenAI-Security-Project/GenAI-LLM-Top10。它继续存在，是为了让既有的链接、引用和历史材料不失效。

所以它解决的问题是引用稳定性，而不是风险分类本身。这个区别很实际：如果你的代码仓库、内部 Wiki 或客户交付物里写的是这个仓库的地址，链接今天仍然能打开，但打开之后看到的内容按 README 的说法属于历史版本。真正面向当前工作的读者，应该去 GenAI-LLM-Top10 的 2026/final 目录。

适用人群因此被切成两块。一块是仍在维护旧版对照材料的团队，另一块是需要引用历史发布物的人。如果你只是想了解当下 LLM 应用的主要风险类别，这个仓库不是入口，它是入口被搬迁后留下的门牌。

从仓库布局看内容形态：文档，不是可安装的库

仓库的 Primary language 标为 Python，但 README 通篇没有任何安装步骤、依赖声明或运行时接口。它列出的内容类型是历史发布物、翻译、工作文件和辅助材料，历史材料放在 Archive 目录下。这更像一个文档与出版物的托管点，而不是一个你能 pip install 之后调用 API 的组件。

这一点值得在选型时提前想清楚。如果你的评估流程默认「开源项目等于可引入的依赖」，这个项目会在第一步就卡住：没有版本号可以锁，没有函数可以调用，也没有运行时行为可以测试。你能从它这里拿到的，是一份分类框架和围绕它的说明文本。

发布节奏也印证了这个形态。Recent releases 里的三个标签分别是 2024（对应 2025 版）、2023-v1.1 和 2023-v1，时间集中在 2024 年 11 月。README 补充说明当前版本是 2026，于 2026 年 8 月 4 日发布，但发布位置指向 genai.owasp.org 的资源页，而不是这个仓库的 release。也就是说，版本演进仍在继续，只是不再落在这里。

许可证标注与仓库实际声明不一致，这点必须先解决

仓库元数据里的 License 字段是 NOASSERTION，含义是平台无法自动识别出一个标准许可证。但 README 底部的 License 段落写得很明确：本项目采用 Creative Commons Attribution-ShareAlike 4.0 International License，并附了 creativecommons.org 的链接，README 顶部的徽章也标着 CC BY-SA 4.0。

两个信号冲突时，工程上应该按更具体的文本走，也就是 README 里的 CC BY-SA 4.0，同时把 NOASSERTION 当作一个需要人工确认的标记，而不是当作「无许可证」。这个区别影响很大：如果被理解成没有许可证，默认就没有再分发授权；按 CC BY-SA 4.0 理解，则允许再分发和改编，但附带署名和相同方式共享的条件。

CC BY-SA 的 ShareAlike 条款对文档类项目是常见的，但对工程团队有具体后果：你把清单内容改编后放进自己的内部规范或对外材料，改编版本通常需要以相同许可证发布。这不是法律意见，具体适用要看你所在法域和实际使用方式，但至少不要让 NOASSERTION 这个字段在合规评审里被误读成「随便用」。

真正会踩的坑：引用了一个内容已经冻结的地址

这个仓库最现实的失败模式不是崩溃，而是静默过期。链接可用，页面能打开，内容看起来完整，但按 README 的说法，新的 issue、pull request 和发布工作都应该转到活跃仓库。这意味着你在这里提的勘误大概率不会被处理，你在这里读到的条目也可能不是当前版本。

对安全类清单来说，这种过期比普通文档更麻烦。风险分类会随攻击手法和模型能力变化而调整，条目顺序、命名和覆盖范围在不同版本之间并不保证一致。如果你把旧版本当作当前基线写进威胁模型，评审时不会报错，但你的对照表可能已经和团队实际引用的版本对不上。

另一个容易忽略的点是贡献路径。README 明确给出了活跃仓库的三种模板链接：release-errata.yml 用于报告 2026 版的更正，release-feedback.yml 用于更宽泛的发布反馈，以及直接开 pull request。如果你按旧习惯在这个仓库开 issue，等于把反馈投进了一个只做归档的地方。

和 NIST AI RMF 相比，差别在分类粒度与治理层级

同类的替代选择里，NIST AI Risk Management Framework 走的是另一条路。它组织的是治理流程：把风险管理拆成 govern、map、measure、manage 这类持续活动，面向的是组织如何建立可重复的风险管理机制，输出偏流程和角色职责。

这份 LLM Top 10 的组织方式不同。它按应用层风险条目来编号，2023-v1、2023-v1.1、2025、2026 都是围绕具体风险类别做的版本迭代，输出偏条目清单。工程团队可以直接把条目对应到代码评审检查项或设计文档章节，而不必先建立一套治理流程。

代价是覆盖范围窄。它不处理组织层面的责任划分、度量指标定义和持续监控机制，这些恰好是 NIST 框架的主线。反过来，NIST 框架不会告诉你某个具体 LLM 风险条目应该在哪一层拦截。两者不是互相替代的关系，选哪个取决于你要的是一份可勾选的条目表，还是一套要长期运转的管理框架。

怎么把它接进你的工作流：只有链接，没有命令

这一点必须说清楚：README 里没有任何安装命令、配置文件或 API 调用示例，因此不存在「怎么跑起来」这一步。你能做的接入动作只有引用。

具体路径有三条。第一条，把文档里的旧链接改成 README 指向的当前资源页 genai.owasp.org/resource/owasp-genai-llm-top-10-2026/，这是 2026 版的发布位置。第二条，如果你需要的是源文件而不是网页，去 GenAI-Security-Project/GenAI-LLM-Top10 仓库的 2026/final 目录。第三条，如果确实需要历史版本，这个仓库的 Archive 目录按 README 的说法保存了较早的发布物和翻译。

贡献路径同样是链接级的。勘误走 GenAI-LLM-Top10 的 release-errata.yml 模板，发布反馈走 release-feedback.yml 模板，代码或文本改动直接提 pull request。更宽泛的项目参与流程在 genai.owasp.org/contribute。日常沟通渠道是 OWASP Slack 的 #team-genai-top-10-llm 频道。

如果你的组织有内部链接检查或文档引用审计，建议把旧域名加进替换清单，而不是等某个评审会上有人发现两个文档引用了不同版本。

维护与升级成本：低到几乎为零，代价是内容不再前进

从维护角度看，这个仓库的持有成本很低。它不编译、不打包、没有依赖需要定期升级，也没有运行时需要打补丁。README 描述的状态是只做归档和链接兼容，新工作全部转到别处。对引用方来说，这意味着不会因为上游重构而突然构建失败。

成本转移到了别的地方。第一是版本对齐成本：你得自己维护一张「我的文档引用的是哪一版」的对照表，因为上游不再在这个仓库里推进版本。第二是贡献成本：想改内容必须换仓库、换模板，多一次跳转，团队里不熟悉迁移情况的人很容易走错。第三是许可证成本：CC BY-SA 4.0 的署名和相同方式共享义务不会因为仓库归档而消失，历史材料的再分发同样受约束。

真正需要警惕的是把「归档」误读成「稳定」。内容冻结和接口稳定是两回事：这里冻结的是文本，不是标准。当 2026 版调整了条目，旧版本的文本不会跟着更新，也不会在仓库里出现提示。

编辑结论

如果你的目的是引用最新版 LLM 风险清单、提交勘误或参与编写，这个仓库不该是你的目标：README 已把当前版本指向 OWASP GenAI LLM Top 10 2026，活跃仓库是 GenAI-Security-Project/GenAI-LLM-Top10。它仍然适合两类人：需要 2023-v1、2023-v1.1 等历史版本做旧文档对照或合规留档的团队，以及需要 Archive 目录下翻译材料的人。采用前先确认三件事：你引用的链接指向的是 2026 版还是历史版本，你的再分发方式是否满足 CC BY-SA 4.0 的署名与相同方式共享要求，以及你是否接受这个仓库只做链接兼容、不会再收到内容更新。

官方来源

1. Issues
2. OWASP/www-project-top-10-for-large-language-model-applications on GitHub
3. Project website
4. README
5. Releases