Late March 2024, a Microsoft engineer chasing down sluggish SSH logins tripped over one of the most elaborate supply chain attacks ever attempted. The xz Utils backdoor, planted over years by a patient adversary who earned trust inside an open source project, could have handed its creator covert access to millions of servers worldwide. The security community responded with detailed technical postmortems—timelines, code diffs, build process analyses. Those documents were thorough, precise, and almost entirely unreadable to anyone outside the field.
That gap between expert knowledge and public understanding isn’t a curiosity. It’s a structural failure. When security write-ups speak only to other security professionals, they abandon the broader public that depends on that knowledge to make decisions about their own digital safety. The xz backdoor was a near-miss with consequences that would have rippled through hospitals, banks, and government systems. Yet the public narrative remains fragmented: a vague sense that something bad almost happened, with no clear picture of what it was, why it mattered, or what anyone should do differently.
This isn’t a problem of technical complexity alone. It’s a problem of documentation culture. Security professionals write for each other, in a dialect dense with acronyms, tool names, and unspoken assumptions about prior knowledge. The result is a form of obscurity that undermines the field’s stated goal of public protection. If security knowledge can’t travel beyond the in-group, it can’t inform the policy debates, procurement decisions, and personal practices that actually reduce harm.
The xz Backdoor: A Case Study in Fragmented Understanding
The technical facts of the xz backdoor are well-documented within the security community. A contributor using the name Jia Tan spent years building credibility in the xz Utils project, eventually gaining commit access and maintainer trust. They inserted obfuscated malicious code into the build process that would have allowed remote code execution via SSH on systems running specific versions of liblzma. The backdoor was discovered before it reached most production systems, but the timeline of the compromise stretched back to 2021.
For security engineers, the postmortems were exemplary. They traced the attacker’s social engineering, the technical mechanism of the backdoor, and the specific conditions required for exploitation. For everyone else, those documents were walls of jargon: “IFUNC resolvers,” “CRC32 polynomial tables,” “GNU indirect function hijacking.” The public was left with headlines and anxiety, but no actionable understanding.
This matters because the xz backdoor was not just a technical event. It was a story about trust in open source infrastructure, about the precarity of volunteer maintainers, about the incentives that make supply chain attacks attractive. Those are public questions, not just engineering questions. When security documentation fails to translate them, it cedes the narrative to whoever fills the vacuum—vendors selling fear, policymakers reaching for blunt instruments, or platforms that profit from confusion.
How Security Documentation Became Its Own Language
Security writing has developed a house style that prioritizes precision for peers over comprehension for outsiders. Vulnerability disclosures follow templates designed for CVE databases, not human readers. Incident postmortems are written to satisfy legal and engineering stakeholders, not to explain what happened to the people whose data was exposed. Threat intelligence reports assume familiarity with MITRE ATT&CK frameworks, APT naming conventions, and the difference between TTPs and IOCs.
This style isn’t malicious. It emerges from legitimate needs: to communicate unambiguously with colleagues, to meet disclosure deadlines, to avoid legal liability for imprecise language. But the cumulative effect is a body of knowledge that is functionally encrypted for anyone without years of domain expertise. The very people who most need to understand a vulnerability—system administrators at small organizations, journalists covering tech policy, citizens evaluating their own risk—are locked out.
The Authors Guild, in its AI Best Practices for Authors, grapples with a parallel tension: how to maintain professional standards while making complex technical topics understandable to a broader audience. Their guidelines emphasize that “it is your original voice, thinking, and creativity that make you the writer that you are”—a reminder that clarity is not a compromise of expertise, but an expression of it. Security writing could learn from this. The goal is not to dumb down technical content, but to structure it so that readers can enter at different levels of expertise and still find a path through.
What Other Fields Know About Making Knowledge Accessible
Education research offers a useful mirror. The field has spent decades studying how to translate dense, specialized knowledge into formats that diverse audiences can understand and act upon. Edutopia, a publication focused on evidence-based teaching strategies, regularly features methods for structuring complex information so that learners can build understanding incrementally. One consistent finding: narrative structure matters. People retain and act on information better when it is presented as a story with a clear sequence of events, characters with motivations, and consequences that follow from decisions.
Security incidents are already stories. The xz backdoor had a protagonist (Jia Tan, the patient adversary), a setting (the open source maintenance ecosystem), a conflict (the tension between trust and verification), and a resolution (the accidental discovery). But most security write-ups strip out the narrative elements in favor of technical chronology. They tell you what happened in what order, but not why it mattered, who was affected, or what choices led to the outcome. The result is information without understanding.
This is not a call for security professionals to become novelists. It is a call to recognize that narrative structure is a tool for clarity, not a concession to entertainment. A well-structured incident report can lead with the human stakes, explain the mechanism in plain terms, and then layer in technical detail for those who need it. The key is to design documentation for multiple audiences from the start, rather than writing for peers and hoping others will catch up.
The Obscurity Problem That Security Refuses to Name
Security professionals are quick to condemn “security by obscurity”—the practice of relying on secrecy rather than sound design to protect systems. But the field practices its own form of obscurity in how it communicates. When vulnerability disclosures, threat reports, and incident postmortems are written in a dialect that excludes non-specialists, the knowledge they contain is obscured from the public that needs it. This is not a technical failure; it is a communication failure with technical consequences.
Consider the typical CVE entry. It includes a severity score, a brief description, and references to patches or mitigations. For a security engineer, that is enough to triage and act. For a journalist trying to explain the risk to readers, or a small business owner deciding whether to panic, it is nearly useless. The severity score is a number without context. The description uses terms like “remote code execution” without explaining what that means in practice. The references point to technical mailing lists, not to plain-language summaries.
This gap is not inevitable. It is a choice—a choice to prioritize the needs of the most expert readers over everyone else. And it has consequences. When the public cannot understand security risks, they cannot evaluate the claims of vendors, the promises of policymakers, or the trade-offs of their own technology use. They are left to trust or distrust based on vibes, not evidence.
Building Documentation That Serves Multiple Audiences
Fixing this does not require abandoning technical precision. It requires designing documentation with layered entry points. A vulnerability disclosure could open with a plain-language summary of what happened, who is affected, and what to do. It could then provide a more detailed technical analysis for engineers, and finally link to raw data for researchers. Each layer serves a different audience without forcing any reader to wade through material they cannot use.
This approach is common in other fields. Medical journals publish abstracts for clinicians and plain-language summaries for patients. Legal documents include executive summaries for non-lawyers. Security documentation rarely does the same, in part because the field has not invested in the editorial skills required. Writing for multiple audiences is a craft, not an afterthought. It requires understanding what different readers need to know, what they already know, and what they will do with the information.
Some organizations are beginning to experiment with this. The Open Source Security Foundation has published plain-language guides to supply chain risks. A few CERTs now include non-technical summaries in their advisories. But these remain exceptions. The dominant culture still treats accessibility as a nice-to-have, not a core responsibility.
Tools can help, but they are not a substitute for editorial judgment. An AI writing app might assist in drafting plain-language summaries or restructuring technical prose into narrative form, but the decisions about what to emphasize, what to omit, and how to frame the stakes remain human judgments. An AI writing app that respects editorial control can be useful for generating initial drafts of accessible explanations, but only if the writer already understands the material and the audience. The risk is that automation produces the appearance of clarity without the substance—a security write-up that sounds plain but still assumes too much or explains too little.
The Cost of Inaccessible Documentation
When security knowledge stays locked inside the profession, the public pays the price. Policymakers draft laws based on misunderstandings of encryption. Organizations buy security products they cannot evaluate. Individuals make privacy decisions based on fear rather than fact. The xz backdoor was a near-miss, but the next supply chain attack may not be. If the public cannot understand what happened and why, they cannot demand the structural changes—funding for open source maintainers, transparency in build processes, accountability for software vendors—that would prevent the next one.
This is not a hypothetical concern. After the Log4j vulnerability in 2021, the security community produced excellent technical analyses. But the public narrative was dominated by panic and vendor marketing. Organizations spent millions on “Log4j remediation” without understanding whether they were actually vulnerable. The gap between expert knowledge and public action was filled by whoever shouted loudest.
Security documentation that serves only the in-group is not neutral. It actively shapes who can participate in security decisions and who is left to trust or distrust without evidence. In a democratic society, that is a political problem, not just a technical one.
What Security Can Learn From Narrative Nonfiction
Narrative nonfiction offers a model for how to translate complex technical material without sacrificing accuracy. The best science writers, for example, do not dumb down the science. They find the human story inside it: the researchers who made a discovery, the patients affected by a disease, the historical context that makes a finding significant. They use concrete scenes, specific people, and clear sequences of cause and effect.
Security incidents have all of these elements. The xz backdoor involved a real person (or persona) who spent years building trust. It involved maintainers who were overworked and under-resourced. It involved a discovery that was almost accidental. These are not distractions from the technical content; they are the structure that makes the technical content comprehensible. When readers understand why someone would spend years inserting a backdoor, they understand the incentives that make supply chain attacks possible. When they understand how the backdoor was discovered, they understand the role of observability and anomaly detection.
This approach does not require every security professional to become a journalist. It requires the field to value communication as a core competency, not a soft skill. It requires organizations to invest in editorial roles that bridge the gap between technical teams and public audiences. And it requires a cultural shift: from treating accessibility as a dilution of expertise to treating it as an expression of responsibility.
Conclusion: Documentation as Democratic Infrastructure
Security documentation is infrastructure. It shapes what the public knows, what policymakers understand, and what organizations do. When that infrastructure is built only for experts, it fails the broader public that security claims to protect. The xz backdoor postmortems were technically excellent, but they did not fulfill the field’s obligation to public understanding. They explained the mechanism but not the meaning.
Fixing this requires more than plain-language summaries appended to technical reports. It requires rethinking who security documentation is for and what it is supposed to accomplish. It requires adopting narrative structures that make cause and effect visible. It requires investing in the editorial craft of translation between expert and public audiences. And it requires recognizing that inaccessible documentation is its own form of security by obscurity—one that leaves the public in the dark about the systems that shape their lives.
The next supply chain attack is already being planned. The question is whether the public will understand it when it arrives, or whether they will once again be left with headlines and anxiety while the knowledge they need stays locked inside the profession.