How Was the OWASP Top 10 for LLM Selected? — Tracing the Process of Voting, Data, and Consensus

When looking at the OWASP Top 10 for LLM, questions naturally arise. Why is Prompt Injection ranked #1, and System Prompt Leakage #7? Who selected these ten items precisely, and based on what statistics and formulas?

To put it simply, the 2025 list is not a ranking automatically generated by a single company sorting confidential incident statistics or using a single scoring formula. It is a community-consensus-driven risk list created by the OWASP GenAI Security Project through a process of reviewing existing items, proposing public candidates, community voting, item consolidation and compression, data analysis, ranking votes, and documentation by item owners.

However, there are also important limitations. While official documents outline the stages, timelines, participation methods, candidates, and voting results, a single weighted formula that anyone can use to precisely reproduce the final rankings from #1 to #10 is not publicly available. Therefore, it is more accurate to interpret this list not as a precise probability table of occurrences, but rather as a guide for security awareness and prioritization that the community at the time agreed should be focused on for LLM applications.

First, Confirm: The Current List is the 2025 Version

Older OWASP project pages still contain the 2023-2024 version lists, making it easy to confuse versions if you only look at search results. The current official GenAI Security Project presents the 2025 Top 10 for LLMs and Gen AI Apps in the following order:


Rank	2025 Item	Core Meaning

—	—	—
LLM01	Prompt Injection	The risk of input or external content altering the model’s intended instructions
LLM02	Sensitive Information Disclosure	Exposure of sensitive information through the model and application
LLM03	Supply Chain	Vulnerabilities in the supply chain of models, data, plugins, and dependencies
LLM04	Data and Model Poisoning	Contamination of training, fine-tuning, embedding data, or the model itself
LLM05	Improper Output Handling	The risk of subsequent systems processing model output without validation or sanitization
LLM06	Excessive Agency	The risk of granting models and agents excessive functionality, permissions, or autonomy
LLM07	System Prompt Leakage	Issues where system prompts are exposed or security relies on their content
LLM08	Vector and Embedding Weaknesses	Authorization and integrity vulnerabilities in RAG and vector/embedding processing layers
LLM09	Misinformation	The risk arising from trusting incorrect or misleading output
LLM10	Unbounded Consumption	Cost and availability risks due to unlimited inference resources, tokens, and API usage

The project leader’s preface in the official 2025 PDF explains that this revision combined brainstorming sessions, voting, and real-world feedback from field experts, with a larger and more diverse global group of contributors than before. In other words, ‘Top’ is not merely a descending order of incident counts, but a priority list combining field experience, newly emerging threats, data, and expert judgment.

The Actual Selection Process Can Be Seen in Seven Stages

By combining the v2 update released in April 2024 and the GitHub Wiki roadmap, the process by which the 2025 list was created can be reconstructed as follows:

Figure: OWASP LLM Top 10 2025 Selection Process · Reconstructed based on v2 update and V2 Core List Roadmap

1. Existing Ten Items Were Re-evaluated First

The first stage was not to simply maintain the existing 2023-2024 list, but for the community to vote on whether each item remained important. A schedule was set to receive votes on existing items from April 15 to 30, 2024, and to compile and release the results in early May.

This stage was necessary due to the rapid pace of change in the LLM ecosystem. Even within a year, as the focus shifts from simple chatbots to RAG, Tool Calling, and autonomous agents, the scope and names of threats also change.

2. New Risk Candidates Were Publicly Solicited

Next, new items were proposed from mid-May to mid-June. The Wiki’s new item submission guidelines instructed proposals to use a candidate directory and template, and brainstorming also took place on the Slack Top 10 channel.

This stage was not a closed-ended survey where participants chose from a fixed set of options, but a generative stage where new risks not present in the existing list could be freely proposed. Topics such as RAG risks, Backdoor Attack, System Prompt Leakage, and Insecure Design emerged in the candidate discussions at the time, and some became independent items in the final list or were integrated into other items.

3. New Candidates Were Filtered by Vote

Not all proposed ideas immediately become Top 10 items. The roadmap planned for new candidate voting from June 16 to 30, and the compilation and release of results in early July. The July 2024 project newsletter also announced that the candidate and voting stages were complete and that Raw Candidate, Raw Results, and Collated Results had been released.

This process also revealed where the community’s interest had shifted. The newsletter summarized that Prompt Injection continued to maintain a high priority, and interest in Agent, RAG, and System Prompt Exploit-related issues grew.

4. Overlapping Items Were Merged and Compressed into Ten Candidates

Even if risk names differ, their causes and countermeasures can overlap. For example, Model Denial of Service can be expanded into Unbounded Consumption, which encompasses cost surges, resource exhaustion, and service disruptions. Similarly, Training Data Poisoning was broadened to Data and Model Poisoning to include not only training data but also fine-tuning, embedding, and tampering with the model itself.

The roadmap specifies a stage from July 15 to August 1 for merging existing and new items and performing a “down-select.” This task is more crucial than simply cutting the list to ten items based on vote count. It requires grouping overlapping candidates into a single category and determining whether their causes, attack paths, and countermeasures can be described as independent items.

5. Data Analysis and Final Ranking Vote Were Conducted

In August, data analysis and a Ranking Vote were scheduled. The data referred to in OWASP documents includes industry reports, research papers, public vulnerabilities and actual attack cases, and field information provided by the community and partners. The approach involves reviewing the impact, exploitability, and prevalence of candidates and supplementing them with expert feedback.

But here, caution is needed. The following formula cannot be confirmed from currently available public data:

최종 점수 = 발생 빈도 40% + 영향도 30% + 악용 가능성 30%

It is difficult to find official OWASP documentation explicitly stating that such fixed weights and cutoffs were applied to the 2025 LLM Top 10. The official terms are Data Analysis and Ranking Vote, and the PDF preface emphasizes Brainstorming, Voting, and Real-world Feedback. Therefore, “data was reviewed” and “the ranking can be reproduced with a single public formula” are different claims.

6. Item Owners Documented Explanations and Countermeasures

After the rankings were determined, the Entry Cleanup stage followed in September. This process involved organizing the definition, common vulnerability examples, prevention/mitigation strategies, and reference materials for each item, as well as adjusting redundant phrasing. GitHub Issues track proposed changes by using item-specific labels, checking for duplication, and assigning them to the item owners registered in CODEOWNERS.

The Top 10 is not merely a voting result announcing ten item names. It includes an editing and peer review process to document the boundaries and examples of each item, enabling practitioners to identify risks and design controls.

7. Published After Layout and Pre-announcement

The roadmap aimed for an October publication after document cleanup, layout, and pre-announcement in September. The actual 2025 PDF shows a release date of November 18, 2024. Since planned and actual publication dates can differ, the schedule should be viewed as a basis for understanding the “design of the selection process,” and the final version and date should be confirmed in the PDF.

Where Can It Be Verified?

When verifying the selection process, it is necessary to consult different types of records left by OWASP, rather than just summary blogs.

Figure: Paths to Verify OWASP LLM Top 10 Selection Basis · Reconstructed based on OWASP official PDF, project site, and GitHub records


What to Verify	Most Direct Official Resource	Content Verified Here

—	—	—
Final 2025 list and revision intent	OWASP Top 10 for LLMs 2025 PDF	Final rankings, item definitions, leader’s preface, contributors, release date
Entire selection stages and planned schedule	V2 Update	From existing item voting to new call for proposals, consolidation, analysis/ranking vote, and publication
Work schedule with responsible parties indicated	V2 Core List Roadmap	Period for each stage and roles of Community, Core Team, Entry Lead
Method for proposing new items	V2 New Entry Submissions-New-Entry-Submissions)	Public candidate submission, templates, brainstorming, and candidate traces
Contemporary record of candidate/voting results being public	July 2024 Project Newsletter	Announcement of candidate/voting stages completion and Raw/Collated Results
How the final document is modified	GitHub Issues and Feedback Wiki	Item-specific error/improvement proposals, labels, duplication checks, and owner review
Who participates and how feedback is given	Contribute and Project Governance	General principles of Slack, meetings, Working Group, consensus, and voting

The most practical order for verification is Final PDF → v2 Update → GitHub Wiki Roadmap → Contemporary Newsletter → Issues and Commit History. While the PDF provides the final results, the selection process is briefly summarized. The Wiki shows the plans, but there might be differences from the actual published version.

Distinguishing Between What Is Publicly Available and What Is Not

What Is Publicly Available

The major stages: existing item voting, new item call for proposals and voting, consolidation/compression, data analysis, and ranking vote.
The planned duration of each stage and the roles of the Core Team, Data Gathering Team, Entry Lead, and the entire community.
Some traces of new candidates and changes to the final items.
Contributors and item-specific explanations in the final PDF.
GitHub Issues, Pull Requests, and Commit History tracking error/improvement proposals after publication.

What Is Difficult to Clearly Reproduce with Current Data Alone

A single official formula and fixed weights used to calculate the final score for each candidate.
Detailed statistics to evaluate the entire voter population, respondent composition, and sample bias for each vote.
Complete decision-making logs of all meetings where candidates were merged or excluded during the down-select process.
The long-term preservation status of the Raw and Collated Results referred to in the 2024 newsletter.

While a Data Gathering Methodology document also exists on the GitHub Wiki, its edit history is constantly changing, and some page content is incomplete. Furthermore, the general data collection descriptions in that document should not be immediately considered as the definitive formula applied to the 2025 rankings. The most reliable basis for the 2025 selection is to cross-reference the v2 roadmap, update articles, newsletters, and the final PDF from that period.

This distinction is not meant to distrust OWASP. It means that when evaluating the trustworthiness of a public project, whether the process is public and whether the results can be fully reproduced from raw data represent different levels of transparency.

Is It the Same Method as the General OWASP Web Top 10?

No, it is not. Even though the name OWASP is the same, the projects and data environments are different.


Comparison Item	OWASP Web Top 10:2021	OWASP Top 10 for LLM:2025

—	—	—
Primary Input	Large-scale application vulnerability data provided by organizations, CWE·CVE·CVSS, community surveys	Review of existing items, proposal of new candidates, community voting, industry/research/real-world case data, and field feedback
Method for Selecting Ten	Explicitly states 8 items selected from contributed data, 2 from community surveys	Combines candidate voting, consolidation/down-select, data analysis, and Ranking Vote
Level of Public Formula	Relatively detailed disclosure of data elements and calculation procedures such as Incidence Rate, Coverage, Exploit, and Impact	Major procedures are public, but a single formula/weight table to reproduce the final ranking is not clear
Data Maturity	Years of accumulated web vulnerability classifications and contributed data from over 500,000 applications	Rapidly changing LLM·RAG·Agent environment; standardized incident/vulnerability data is still limited
Correct Interpretation	A web application risk awareness list combining data and surveys	An LLM application priority checklist reflecting the consensus of the expert community and field signals at the time

The official methodology for Web Top 10:2021 clearly explains that 8 categories were chosen from contributed data and 2 from community surveys. It also uses Incidence Rate, which is the percentage of applications where a specific CWE was found at least once, instead of occurrence frequency.

In contrast, the LLM domain does not have as long an accumulation of common CWEs or incident data as web vulnerabilities, and system risks combining prompts, models, RAG, tools, and permissions are rapidly evolving. Therefore, the weight of public candidates, expert judgment, and field feedback is greater. It would be incorrect to state that the metrics from the Web Top 10 were directly applied to the LLM list.

Does ‘Rank 1’ Mean the Highest Number of Occurrences?

No, it does not. The fact that Prompt Injection is LLM01 does not mean it accounts for an exact percentage of global security incidents. This is not a ranking like insurance statistics calculated solely using publicly available populations and incident counts.

LLM01 should be understood as a priority combining the following:

Does it repeatedly appear in various LLM application architectures?
Can its impact lead to data leakage, privilege misuse, and subsequent system compromise?
Is it currently being closely observed by practitioners?
Does it serve as an attack vector or trigger point for other risks?
Is it valuable to describe as an independent category and provide mitigation guidelines for?

Therefore, it should not be interpreted as LLM07 being less important than LLM03, or that resolving only LLM10 makes a system safer than addressing the preceding nine. While the numbers help in establishing an inspection order, the actual risk level varies depending on an organization’s data, functions, permissions, and deployment structure.

How Should Enterprises Utilize It?

Rather than simply copying the Top 10 as a compliance checklist, it should be used as a starting point for threat modeling.

1. Map Risks to System Components

사용자 입력 → Prompt Injection
모델·데이터 공급망 → Supply Chain, Data and Model Poisoning
RAG 검색 → Vector and Embedding Weaknesses
출력 후속 처리 → Improper Output Handling
도구 호출과 권한 → Excessive Agency
로그·응답·학습 데이터 → Sensitive Information Disclosure
토큰·GPU·API 비용 → Unbounded Consumption

2. Re-evaluate Organizational Impact and Exposure

The priorities for an internal knowledge search chatbot and an agent capable of payment or account changes are different. For each item, data sensitivity, exposure to external input, model permissions, scope of automated execution, detectability, and cost of recovery from damage must be evaluated.

3. Maintain Risks Outside the Top 10

The ten items are a boundary, not the entire universe. Risks critical to an organization, such as model theft, privacy regulations, bias, copyright, availability, model updates, and vendor lock-in, may not be independent items in the current list. The OWASP AI Security and Privacy Guide, MITRE ATLAS, NIST AI RMF, and internal threat models should be used in conjunction.

4. Document Version and Source

In policies or checklists, do not simply write ‘OWASP LLM Top 10’; instead, specify the version, such as OWASP Top 10 for LLM Applications 2025. In previous versions, Insecure Plugin Design, Model Theft, and Overreliance were independent items, but their names and scopes were reorganized in 2025.

To Use It Properly, Its Limitations Must Also Be Understood

The community consensus approach has the advantage of quickly reflecting new risks and not being dependent on the product interests of a single company. Conversely, priorities can change depending on the composition of participants and the timing of votes, and in areas with few public incidents, expert judgment carries more weight. How candidate names and scopes are merged also influences the ranking.

Therefore, it is best to avoid both of the following statements:

“OWASP has statistically proven that these ten are the exact order of global LLM incidents.”

“It was created by voting, so it’s just an unsubstantiated popularity ranking.”

The actual process lies somewhere in between. There were public candidate proposals and community voting, data and real-world field feedback were reviewed, and item owners and contributors organized the items. At the same time, a detailed quantitative model that can fully reproduce the final ranking is difficult to find in publicly available materials.

Conclusion

The OWASP Top 10 for LLM 2025 was created through review of existing items → call for new candidates → candidate voting → item consolidation and compression → data analysis and ranking vote → expert documentation → public review. It is neither a confidential list arbitrarily determined by someone, nor a ranking solely based on a single incident statistic.

For the question of where to verify, the following four points are key answers:

The final list and revision intent can be found in the 2025 PDF.
The selection stages and schedule can be found in the v2 update and the GitHub Wiki roadmap.
Candidate traces and contemporary voting records can be found in the New Entry Submissions Wiki and the July 2024 newsletter.
Changes and discussions after publication can be found in GitHub Issues, Pull Requests, and Commit History.

And the most important interpretation is this:

The OWASP Top 10 for LLM is not an absolute ranking determined solely by the number of occurrences, but a priority checklist created by combining community votes, data, and field experience in the rapidly changing LLM security environment.

The most appropriate way to utilize this list is not to treat it as the ultimate security solution, but as a common language to initiate threat modeling tailored to our system’s data, permissions, RAG, and Agent structures.