# The Linux kernel defence map is one DOT file whose edges mean related, not mitigated > Linux Kernel Defence Map is a graph relating kernel vulnerability classes, exploitation techniques, bug detection mechanisms and defence technologies, written in the DOT language and rendered with a single GraphViz command, committed as both source and SVG, and mirrored to three forges. The map targets kernel version 6.17, its edges are explicitly not claims of mitigation, and it excludes attack surface, userspace security and LSM policies. **a13xp0p0v/linux-kernel-defence-map** — Linux Kernel Defence Map shows the relationships between vulnerability classes, exploitation techniques, bug detection mechanisms, and defence technologies - Repository: https://github.com/a13xp0p0v/linux-kernel-defence-map - Stars: 2,323 · Forks: 146 - Language: Unknown - License: GPL-3.0 - Published: 2026-09-29 · Updated: 2026-09-29 · Language: en - Canonical page: https://hysenlabs.com/projects/a13xp0p0v-linux-kernel-defence-map ## The map is one DOT file and one rendered SVG, with nothing checking they agree The repository is five files. A licence, this readme, a file about issues, and the map in two forms: a DOT source file and an SVG rendered from it. The format was chosen for a reason that has nothing to do with diagrams, and the readme gives it: the DOT language makes maintenance and updating in Git convenient. That is the whole rationale. A graph written as text diffs line by line, so adding one defence or one edge is a reviewable commit instead of a binary replacement. For a project whose maintenance model is a series of small additions over years, that is the correct priority. Rendering is one command: ``` dot -Tsvg linux-kernel-defence-map.dot -o linux-kernel-defence-map.svg ``` And there is no automation around it. There is no continuous integration directory in the repository, no makefile, no script. The SVG is a committed build artefact produced by running that command by hand, and nothing in the project verifies that it matches the source it was generated from. So the format decision that makes the source reviewable also creates a second file that can drift, silently and indefinitely, with the graph people actually look at being the one that is checked in as an image. Regenerating is a two-second job; nothing schedules it. ## Edges mean related, and three areas are excluded by name The caveat that matters most is stated in two sentences near the top, and most diagrams of this kind do not state it. The connections between nodes do not mean full mitigation. Each connection represents some kind of relationship. So an edge from a vulnerability class to a defence is not a claim that the defence prevents that class; it is a claim that the two are worth reading about together. Given that the map's stated purpose is to help you navigate documentation and kernel sources, that is exactly the right semantics, and drawing it any stronger would have made the diagram more impressive and less true. The scope is bounded just as explicitly. The map describes kernel security hardening, and it does not cover three adjacent things: cutting attack surface, userspace security features, and policies enforced by the Linux Security Modules. That last exclusion is the one to notice. LSM policies are where access control, mandatory access control and container isolation live, and an engineer reading a hardening diagram would reasonably assume that surface is represented. It is not, by name, in one clause. The four categories the map does relate are vulnerability classes, exploitation techniques, bug detection mechanisms and defence technologies, and the readme notes the sources of the defences are mixed: some come from the kernel mainline, others live outside the tree for various reasons, some of them commercially, and some depend on special hardware features. That last category is the one a diagram handles worst, since a hardware requirement is not a graph edge. ## The map names one kernel release and gives no update cadence The final heading in the readme is the version statement: the map is for Linux kernel version 6.17. That is the entire version identity of this project. There are no GitHub releases recorded, and while the readme carries a badge linking to the repository's tags, nothing on the page ties a tag to a kernel version. So the diagram identifies itself by the kernel it was drawn against, and a reader has to compare that number against their own kernel to know whether it applies. The last push to the repository is dated 2026-05-24. There is no statement of how often the map is revised, no note about which kernel release triggers an update, and no indication of whether the diagram is complete for the release it names or is simply current as of whenever it was last touched. For a reference document this matters in a specific way. Hardening options are added across kernel releases and occasionally removed, so a diagram pinned to one version will drift in both directions: a control added since will be absent, and a control that has gone will still be drawn. Nothing in the page distinguishes the two cases, because nothing in the page tracks the kernel's own release history. The readme does not claim the map is current for any release. It says which one it was made for, which is the honest form of the claim and also the least convenient one to check. ## Issues are tracked in a file, and the project lives on three forges There is a file about issues in the repository root, and the readme lists three hosting locations. GitHub is listed first. Codeberg is listed second, with a parenthetical instruction to go there if something goes wrong with GitHub. SourceCraft is listed third. Same project, three forges, one explicit statement about why the mirror exists. That is a resilience strategy rather than an accident, and it is worth noting that the readme does not describe it as a mirror in the usual sense. Three copies of a repository can drift, and nothing on the page says which is authoritative or how they are synchronised. What it does say is that one of them is the fallback, which tells you the author's concern is availability of a forge rather than trust in a single operator. The issues file is the other half of that arrangement. Keeping an issues list in the repository means the content survives a forge outage and is forkable, and it means the canonical list is a file that a mirror carries with it. The trade is that the file and the forge's own issue tracker are two places to look, and the page does not say which is which. For a project this small, that is a lot of distribution engineering around a single diagram. It reads as a deliberate preference for not depending on one service, and it does cost readers who expect the usual single-tracker arrangement. ## Eight references, and the newest one named is from 2021 The references section is eight items, and they are not the same kind of thing. One is a feature list from a long-running distribution project. One is the kernel's own security documentation. Two are repositories: a mitigation checklist kept in a tutorial repository, and a decade-long study of kernel vulnerabilities kept in another. One is a checker for two specific speculative-execution vulnerabilities, by a named author. The remaining four are talks and slide decks from named researchers at named events, with years attached: two from 2019, one from 2020, one from 2021. So the newest reference named anywhere on the page is from 2021, and the map itself targets a much later kernel. The talks are the durable part, since a methodology presentation does not go stale the way a feature list does, but a reader looking for the current state of kernel hardening will not find it here. Two further details. The last reference is another checking tool, which means the list mixes the author's own project with a comparable one rather than curating only references. And the list is unranked and unannotated: eight links with author names and no sentence saying which to read first or why any of them is included. ## Configuration checking is a separate project, because distributions leave options off The readme has a section that is not about the map at all, and the reason it is there is the most practically useful thing in the document. The argument runs: there are plenty of security hardening options in the kernel; a lot of them are not enabled by the major distributions; we therefore have to configure them ourselves; and nobody likes verifying configurations by hand. The consequence is that the map and the checker answer different questions, and the readme is clear about which is which. The map tells you what exists and what relates to what. The separate checker tells you what your machine has switched on. The map explicitly does not do configuration. That split is the correct one for this kind of artefact. A diagram of available defences and a report on your build are different deliverables with different lifetimes, and combining them would have meant the diagram could not be drawn without knowing your configuration. Keeping them apart also means the checker can be run repeatedly after a distribution update while the diagram changes only when the kernel does. The invitation to try the checker is worded loosely, and there is no statement about what it checks, which kernel versions it understands, or whether it reads your current configuration or an intended one. Those details are on the checker's own page, not this one. ## CWE numbers are the machine-readable part, and the licence is stated three ways Two things in this repository are consistent, and both are worth naming because they are what make the artefact usable rather than merely readable. The first is the identification of vulnerability classes. The map provides the Common Weakness Enumeration numbers for them, which means the graph can be joined to any other database keyed on the same identifiers. That single feature turns a picture into something you can query, and it is mentioned in one clause with no elaboration. The second is licensing. The licence is stated three times and agrees each time: a badge linking to the GNU GPL version 3 text, a licence file at the root, and a line in the section describing how the map is made that names the same licence. There is no separate licence for the diagram, no separate licence for the reference material, and no ambiguity about which terms apply to the DOT source as opposed to the SVG derived from it. For a map that incorporates third-party projects' feature lists into its nodes, that consistency is doing real work. A reader who wants to reuse the graph knows immediately what the terms are, and a reader who wants to check a node against the upstream project's own documentation has a licence that permits it. ## Conclusion Use Linux Kernel Defence Map as a reading list rather than as a checklist, because that is what the author says it is: a diagram for navigating documentation and kernel sources, with edges that mean two concepts are related rather than that one prevents the other. Three things to check before you lean on it. Its currency, because the map is stated for one kernel release and the last push to the repository is dated 2026-05-24, so a hardening option added since then will not be on the diagram and one that has been removed may still be drawn. Its scope, because attack-surface reduction, userspace security features and LSM-enforced policies are excluded by name, and those are among the first controls an auditor asks about. And what it is not, because the map says nothing about your build configuration and the author directs that question to a separate checker, with the reasoning that distributions ship with many hardening options turned off, so the gap between what the kernel offers and what a given system actually uses is where the work is. Read the diagram to learn what to go and look up, then use the checker to find out what your machine has. ## FAQ ### What does the Linux Kernel Defence Map show? A graph relating four categories in Linux kernel security: vulnerability classes, exploitation techniques, bug detection mechanisms and defence technologies. It also provides the Common Weakness Enumeration numbers for the vulnerability classes, and is written in the DOT language and rendered to SVG with GraphViz. ### Does a connection in the defence map mean the vulnerability is mitigated? No. The readme states explicitly that the node connections do not mean full mitigation, and that each connection represents some kind of relationship. The map's stated purpose is to help navigate documentation and kernel sources rather than to make claims about prevention. ### What is not covered by the Linux Kernel Defence Map? Attack-surface reduction, userspace security features, and policies enforced by the Linux Security Modules. The map describes kernel security hardening only, and the readme names all three exclusions. ### How do I check my own kernel configuration for hardening options? Not with the map, which says nothing about configuration. The author points to a separate checker project for that, on the grounds that many hardening options are not enabled by the major distributions and that verifying configurations by hand is unpleasant. ## Sources - [a13xp0p0v/linux-kernel-defence-map on GitHub](https://github.com/a13xp0p0v/linux-kernel-defence-map) - [Issues](https://github.com/a13xp0p0v/linux-kernel-defence-map/issues) - [License: GPL-3.0](https://github.com/a13xp0p0v/linux-kernel-defence-map/blob/master/LICENSE) - [README](https://github.com/a13xp0p0v/linux-kernel-defence-map/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/a13xp0p0v-linux-kernel-defence-map