OWASP Kubernetes Top 10: a prioritised risk list maintained as markdown

A risk list for people who run clusters

The premise of the project is stated in the README: adopting Kubernetes introduces new risks to our applications and infrastructure. The OWASP Kubernetes Top 10 is aimed at helping security practitioners, system administrators and software developers prioritise risks around the Kubernetes ecosystem, and the Top Ten is defined as a prioritised list of those risks.

So it is a document, not a tool. There is nothing to install and nothing to run against a cluster. What it offers is a ranking, a set of descriptions, and a shared set of names to use when arguing about where the effort should go. For a platform team that has to explain to a product owner why policy enforcement deserves a quarter, a named, externally maintained list is a more useful artefact than a home grown risk register.

The three audiences named in the README are worth taking seriously, because the risk is that a list like this drifts toward one of them. A list written only for security practitioners will miss the operational realities that make a risk real. A list written only for developers will not survive contact with a platform team's runbook. The project also asks for organisations and individuals who can provide Kubernetes vulnerability and misconfiguration data, which points at the audience the list is missing.

The homepage is a public OWASP project page, and the repository is one of the Foundation's `www-project` sites, which is why the description reads as a web repository rather than as a software project.

What changed between the 2022 and 2025 lists

Both editions are in the repository, and comparing them is more informative than reading either alone. The 2025 list runs K01 to K10 with descriptive titles, while the 2022 edition runs K00 to K10 plus a separate document on other risks to consider.

The 2025 entries are insecure workload configurations, overly permissive authorization configurations, secrets management failures, lack of cluster level policy enforcement, missing network segmentation controls, overly exposed Kubernetes components, misconfigured and vulnerable cluster components, cluster to cloud lateral movement, broken authentication mechanisms, and inadequate logging and monitoring.

Set them against the 2022 numbering and the movement is visible. Logging and monitoring was K05 in 2022 and is K10 in 2025. Secrets management was K08 in 2022 and is K03 in 2025. RBAC configuration was K03 in 2022 and authorization configuration is K02 in 2025. Network segmentation was K07 and is K05. And the 2022 entry for supply chain vulnerabilities does not appear in the 2025 top ten at all, while cluster to cloud lateral movement is a new entry that has no direct 2022 counterpart.

The one clear conclusion to draw from that is about how to use the list. A K number is not a stable identifier across editions. A control that was K03 last time might be K02 now, and a risk that used to be in the list may have been moved out of the top ten without disappearing. Anything that references K numbers, a compliance mapping or a ticket template has to be rewritten against the edition it intends to use, and citing a risk by number alone is not safe across years.

The 2025 edition is the current one, and the README asks for issues or pull requests for changes, with feedback explicitly welcomed.

Documents in versioned folders, published as a Jekyll site

The repository layout is that of a documentation site rather than a code project. The top level holds `2022/` and `2025/` directories, each containing per-language source under `src/`, and the entries are linked directly to those files, for example `./2025/en/src/K01-Insecure-Workload-Configurations.md` and the 2022 equivalents under `2022/en/src/`.

Around that sit the Jekyll parts: `_config.yml`, `Gemfile`, `index.md`, `info.md`, `leaders.md`, `assets/`, a `404.html` page and a `CNAME` file that claims the custom domain for the published site. There are also governance files, `CODE_OF_CONDUCT.md`, a `.markdownlint.json` configuration, a `.textlintrc` and a `markdown-link-check-config.json`.

The version directories are the important structural decision. A security list that is revised every few years has to keep the old edition intact, because a control that was written against the 2022 wording is still referenced by people who read it last year. Splitting by edition means the 2022 text can be corrected without changing what the 2022 list says, and the 2025 text can be rewritten without invalidating the older citations.

The per-language `src` structure points the same way, since a risk description that is being translated into another language is a document with its own lifecycle, and the project lists translation efforts among the ways to contribute.

Markdown, text and link checks in the manifest

The `package.json` is small and reveals how the document is policed. There are no runtime dependencies at all, only development tools for checking the prose, and the scripts are linting commands rather than a build:

    "scripts": {
        "test": "npm run lint-markdown && npm run lint-terminology",
        "lint-terminology": "textlint ./2022",
        "lint-markdown": "markdownlint ./2022",

The development dependencies are the tools behind those scripts:

    "devDependencies": {
        "markdownlint-cli": "^0.32.2",
        "textlint": "^12.5.1",
        "textlint-filter-rule-comments": "^1.2.2",
        "textlint-filter-rule-allowlist": "^4.0.0",
        "textlint-rule-terminology": "^3.0.4",
        "markdown-link-check": "^3.10.3"
    },

Three things are worth noting. Markdownlint checks structure, textlint with a terminology rule checks wording, and markdown-link-check verifies that the links still resolve, which for a document full of references to Kubernetes API documentation is not a small job.

The filters in the textlint setup matter as much as the rules. `textlint-filter-rule-comments` and `textlint-filter-rule-allowlist` exist to exclude text from the terminology checks, which is how a rule set gets applied to prose without flagging quoted text or names that happen to trip a word list. For a security document full of API field names and vendor product names, that distinction is the difference between a usable check and one that gets disabled.

One observation from the scripts is worth recording rather than hiding: the lint commands point at `./2022`, not at both editions. The link-check script is also defined against the 2022 tree. Whatever the reason, a contributor editing a 2025 file is working in a path that the manifest's default checks do not cover, and the project relies on reviewers for that part.

The ranking is a judgement, and the project says so

The most quotable line in the README is the one about the future: in the future the project hopes for the Top Ten to be backed by data collected from organisations varying in maturity and complexity. The present tense is a prioritised list, and the data is what it hopes to have later.

That is an unusually candid framing, and it determines how the list should be used. A prioritised list without a data set is an expert consensus document. That is a legitimate and useful thing, and OWASP produces many of them, but it has consequences for the reader. The order of the entries is a claim about relative importance, and the basis for that claim is the judgement of the contributors rather than a measurement of how often each risk causes incidents.

The same applies to the individual entries. A risk description will say what the failure looks like and what to do about it, but it will not tell you how many clusters in the wild have that misconfiguration, because that number is not collected here.

This is where the list should be joined with other work, and the README points at the neighbours. It links the OWASP Kubernetes Security Cheatsheet, the OWASP Kubernetes Security Testing Guide and the OWASP Docker Security Cheatsheet, and it lists assisting in the development of those related tools and projects as a contribution in its own right. The cheatsheet is the practical checklist form of the same knowledge, the testing guide is the verification side, and the Top 10 is the prioritisation layer. Teams that use only one of the three get either a list without a method or a method without a priority.

The contribution model is similarly concrete: data from organisations, translations, and tool work, with issues and pull requests welcomed for changes.

Licence, editions and how to work with the list

On licensing, there are two statements to reconcile. The manifest records `CC-BY-SA-4.0` as the licence, which matches the nature of a Creative Commons licensed document that is meant to be reused and translated. The repository itself is recorded with a custom licence that GitHub cannot classify, with the LICENSE file named as the place to look. For a document intended for reuse inside corporate security documentation, read that file before copying sections into a policy, and keep the attribution the licence requires when you do.

The editions are the other practical consideration. The 2025 list is the current one, and the 2022 list remains in the repository as the previous edition. When you write internal guidance against this project, name the edition and the year in the citation, and treat the K numbers as edition specific.

On maintenance, the repository is not archived, and the last push was on 2026-09-11. There are no GitHub releases, which is normal for a continuously edited document site, and the practical version marker is the edition folder rather than a tag.

The community channels are documented too. The project has a Slack channel, `#project-k8s-top10`, and the project page is the published entry point. The leaders file in the repository root records who maintains the document, which is worth reading if you plan to contribute a change to a risk entry, since the review path for a security list runs through the project team rather than a pull request bot.

For a team adopting the list, the realistic use is as a review checklist: read the entries for the risks your platform actually has, mark the ones you have no control for, and treat the rest as a work list ordered by the list's own priorities rather than by your own.

Editorial conclusion

The OWASP Kubernetes Top 10 suits a team that needs a shared, prioritised vocabulary for Kubernetes risk in a design review or a hardening plan, and that can read a risk description and judge its own exposure. It does not suit anyone looking for a scanner, a compliance check or a data set of real-world cluster breaches, since the repository holds prose and the project states the ranking is not yet backed by collected data. Before adopting the 2025 list, read the entries for the risks your platform actually has, check the LICENSE file because the repository licence is recorded as a custom one while the site is published under CC-BY-SA-4.0, and note that the last push was on 2026-09-11.

Frequently asked questions

Official sources

1. Issues
2. OWASP/www-project-kubernetes-top-ten on GitHub
3. Project website
4. README