The OWASP LLM Top 10 repository is an archive now, and its tags disagree with their titles

The repository's remaining job is to keep old links resolving

The first thing on the page is a notice that this repository is maintained as a legacy entry point and a historical archive, and that active development has moved to another repository under a different organisation. The reason it is still online is stated plainly: so that existing links, citations and historical artifacts continue to work.

That framing explains the rest of the page. New issues, pull requests and release work are directed to the active repository, and the contributions section does not ask you to open a pull request here at all. It lists three things to do in the new place: report a correction to the 2026 release, submit broader release feedback, or open a pull request. Two of those three are issue templates rather than a plain issue, which is the detail that tells you the current edition has a formal correction process attached to it.

The current release is named and dated on the page, published on August 4, 2026, with a link to the publication, a link to the current source tree in the active repository, and the errata form. The most recent commit in this repository is dated 2026-08-05, the day after that publication, which is what you would expect from a repository whose last action was to point at its successor.

The tag names and the release titles do not match

The three releases listed here are a small lesson in why archives are harder to search than they look. The newest tag is named with a bare year, 2024, and its release title calls it the 2025 edition. It was published on 2024-11-18. Below it sit two tags named for the previous year with a version suffix, both published on 2024-11-11, roughly a minute apart, one at version 1 and one at version 1.1.

So the sequence reads, oldest to newest, as 2023-v1, 2023-v1.1 and 2024, while the titles read as 2023, 2023 revised, and 2025. Two different naming conventions in one list, a bare year in the newest tag, and an edition year in the title that the tag does not carry.

For a document whose entire purpose is to be cited, that is worth knowing before you cite it. If you are looking for the 2025 edition of the Top 10 for LLM applications, the tag to look for is the one named for the previous year, and if you are looking for the current edition you need the other repository and the 2026 publication. The page also lists an archived release link for the 2025 edition and a directory of earlier releases and translations for everything before that.

Corrections are routed through a template, not the issue tracker

The contributions section is short and its structure carries most of the information. Instead of a contribution guide for this repository, it points at three actions in the active repository, and two of them are issue forms with their own templates.

The first is a correction form scoped to the 2026 release. That is a deliberate narrowing: reporting an error in a published edition is a different job from suggesting a change, and it gets its own intake rather than competing with feature requests. The second is a broader feedback form for the release as a whole, which is where substantive suggestions go. The third is the ordinary pull request link.

The rest of the process lives outside the repository entirely. The page points at the broader project's contribution page, and names a working group channel on the foundation's Slack instance, with a channel identifier specific to this top 10 effort. That is the whole contributor surface: two structured forms, one code path, one documentation link and one chat channel.

For an archive that no longer accepts changes, having no local contribution instructions is correct. What is slightly odd is that the repository still carries governance files of its own, which is the subject of a later section.

The page names a licence, the root file agrees, and the metadata asserts nothing

There are three sources of licensing information here and they do not all say the same thing. The page states a Creative Commons Attribution-ShareAlike 4.0 International licence and links it. A licence file sits at the root of the repository, named with a markdown extension rather than the bare filename most tools look for. And the repository's declared licence field is left unasserted rather than set to a value.

The two that speak agree with each other, so there is no real conflict about terms. What is missing is the machine-readable half. Automated tooling that reads licence metadata will find nothing, and a script that looks for a file called LICENSE will not find one either, because the file carries an extension.

For a document that people cite, that is a small but real friction point, and it is worth reporting upstream rather than working around silently. The same pattern shows up in how the archive is licensed rather than the software, which is the correct choice for a standards document, but it does mean a repository scanner and a human reading the page can reach different conclusions about what they are allowed to do with it.

The primary language is Python and the site is a Jekyll blog

The repository is a static website, and the language metadata says Python. Both facts are true and they describe different things.

The site itself is a Jekyll project with a configuration file, a data directory, a markdown index at the root, a custom not-found page, a theme override file, and an assets directory. A Gemfile sits beside them, which is the Ruby dependency manifest, and a pre-commit configuration file plus hooks and scripts directories cover the repository tooling. An editor directory and a Ruby-style ignore file complete the picture of a documentation site maintained by people who write both languages.

So the Python classification comes from the tooling directories rather than from any content a reader would execute. There is no application here, no library and no service. Everything a visitor sees is markdown, a stylesheet and static assets, which is the right shape for an archive that has to keep rendering for years without maintenance.

It also explains why the repository can afford to be a legacy entry point. A Jekyll site that only builds when someone rebuilds it is the cheapest possible thing to leave running, and the page links at the top are to a deployment workflow rather than to a release pipeline.

The archive is a directory, a tabbed page and a changelog, all at once

Historical material is organised three different ways in the same tree, and knowing which is which saves time.

The archive directory holds earlier releases and translations, and it is where the page sends anyone looking for an old edition or a non-English version. The tabbed archive page at the root appears to be the same material presented as tabs rather than as a directory listing, which is what a Jekyll site would do to make a long list navigable. A changes file sits beside them as the running record of what changed between editions.

Then there is the material that is not about editions at all: a documentation directory, a resources directory, an initiatives directory, a directory whose name refers to a second version of the vulnerability list, and four files about the project rather than the document, covering project information, leadership, an initiatives page and a core team page. A codeowners file and a security policy sit at the root next to a contributing file.

For a reader, the useful split is this: the archive directory is content, the four project files are governance, and everything else is site machinery. The readme on the page you are reading is the one file that explains which is which.

Governance files stayed behind when the work moved

Three details are worth flagging to anyone citing or mirroring this repository.

First, the governance layer never left. The tree still carries a contributing file, a codeowners file, a security policy and a core team page, while the page directs every contribution to a different repository and to a chat channel. That is a normal consequence of archiving a project, but it means a reader who opens the contributing file locally gets instructions for a repository that is no longer the place to make changes.

Second, the homepage recorded for the repository uses plain HTTP, while every link the page itself offers is HTTPS. For a project whose entire value is that people follow its links, that inconsistency is worth a one-line fix in the repository settings rather than in the content.

Third, the last section of the readme is not content at all. It is a popularity chart, embedded from a third-party service, rendered once for a dark background and once for a light one. It is the only dynamic element on the page, and it is a reminder that what this repository now serves is attention and citations rather than guidance.

Editorial conclusion

Use this repository for what it is good for, which is citation and lookup of the earlier editions, and go to the active repository for anything current. Nothing here is a defect: the page says plainly that it exists so existing links, citations and historical artifacts keep working, and it names where each kind of contribution belongs, including a dedicated template for reporting a correction to the 2026 release rather than a general issue. Two cautions. Anyone citing the Top 10 should cite the edition they actually mean, because the tag names and release titles in this archive do not line up and the current list lives in a different repository with a different name. And anyone treating the repository metadata as the licensing source will find nothing asserted there, while the page and the root licence file both name a Creative Commons Attribution-ShareAlike licence.

Frequently asked questions

Official sources

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