A Security Reading List That Stays Useful

Every security reading list we have kept has gone stale, and ours went stale faster than the others. A list of AI tools survives a year because the tools get new names. A list of security links fails differently: the standard gets a new version, the project behind the write-up is abandoned, the page that explained a bug class moves behind a login, and the entry that still resolves teaches something that stopped being true in 2019. Forty links on a page feels like a service. Usually it is a liability with a publication date nobody updates.

What follows is not a canon. It is the method we use to decide what belongs on such a list, and then a short list we checked on 22 October 2026: fifteen entries, each with one line on why it earned its place. The method is meant to last. The entries are meant to change, and some of them will be gone the next time we do this.

Security lists rot faster than any other kind

The first reason is versioning. Security work is organised around documents that get replaced rather than amended. MITRE's ATT&CK is on version 20. The OWASP Application Security Verification Standard is on 5.0.0. The Web Security Testing Guide is on 4.2, with 5.0 in development. CWE lists 944 weaknesses and has 5.0 scheduled for 28 October 2026. A link to a superseded version is not merely old. It is a wrong answer delivered in a confident tone, and it is the kind of link that survives longest on a list, because nobody clicks it any more.

The second reason is the link itself. While preparing this piece we opened an address we had used for years, a well-known wiki of offensive techniques. It redirected to a host we did not recognise before serving any content. Perhaps a browser would have carried us through to the page we wanted. It does not matter. A link that surprises you on a clean fetch is not one you can put in front of a client, so it did not go on the list. Dead links are easy to spot. Links that quietly become something else are the expensive ones.

Six categories, and they decay at different speeds

Order the categories by how fast they go out of date, and you get the checking schedule for free.

• Offensive technique. How an attack is actually carried out, at the level of something you can run. It changes with the platforms, and it is the category most likely to be written by someone selling a course.
• Defensive engineering. Requirements, controls and practices that go into a build. Slow-moving, and the most useful category for a team that ships software rather than tests it.
• Vulnerability databases. What is broken, in which version, and whether anyone is exploiting it. The fastest category by far, which is why it belongs in a feed rather than a bookmark.
• Standards and taxonomies. ATT&CK, CWE, the OWASP projects. Slow, but the version number is the whole point.
• Vendor advisories. The only place a fix is described by the party that shipped it.
• Academic work. The slowest, and the only category that explains a mechanism before it has a product name attached.

A list with four entries in one category and none in the rest is a reading habit, not a reference. The imbalance usually shows where its author works.

Judging a source before it earns a line

Four questions, in this order.

• Who maintains it, by name? An organisation, a named editor, a project with a public repository. "The community" is not something you can check, and it is what people write when nobody is responsible.
• When was it last touched, and does the page say so? A standard shows a version. A blog shows dates. A page with no date anywhere is telling you it does not expect to be revisited.
• Does it cite primary material? CVE identifiers, commit hashes, vendor advisories, papers, the exact affected versions. A summary that cites nothing is a summary of other summaries, and it inherits their mistakes without their corrections.
• Does it survive a clean fetch? No login, no redirect to an unexpected host, no JavaScript shell that returns an empty document. This is the test that removed the most candidates while we built this list.

Two more, specific to security. Does the source distinguish a proof of concept from a working exploit, and does it say what it has not tested? Does it name affected versions rather than "older releases"? Both are the difference between a page you can act on this afternoon and one you have to re-verify from scratch, which in practice means you will not.

Pruning is a calendar job, not a mood

Every entry carries the date it was last checked, not the date it was added. The two drift apart quickly, and only the first is useful to a reader.

The check is a quarterly pass, and it is physical: fetch each URL, open the most recent item rather than the front page, and compare any version number against the publisher's own page. A front page can look alive while the archive stopped in 2023. Opening the newest item takes a few seconds and catches most of the decay.

Removal is the harder rule, because every entry has a reason it was added and that reason does not expire on its own. A "classics" section is where dead links go to be admired, and once it exists the list has two standards. When an entry leaves, it leaves. If it still matters it comes back through the same four questions, and it comes back with a better line.

Cap the list. Fifteen entries now. To add one, one leaves. Without a cap the list grows until nobody reads it, and the growth always follows the author's interests rather than the reader's needs.

Writing for the reader who is not a specialist

Write each line for the decision it supports, not for the topic it covers. "Use this when you need to know whether a vulnerability is being exploited right now" is a line a manager can act on. "A catalog of exploited vulnerabilities" only makes sense if you already know why the catalog exists.

Order entries inside a category by how often an ordinary team needs them, not by how impressive they are. Put the constraint in the line itself: which ecosystems a database covers, which platforms an advisory stream applies to, what a framework is not for. A non-specialist will not read a methodology page, so the limit has to travel with the link.

For a small company, the three entries worth opening first are CISA's exploited-vulnerability catalog, the OWASP Cheat Sheet Series, and the advisory stream for whatever you actually run. Our guide to cybersecurity basics for a small business covers the work those three support.

The list, checked 22 October 2026

Fifteen entries, grouped by the six categories above. Every URL below was fetched today and returned the page described in its line.

Offensive technique

• PortSwigger Web Security Academy: free, lab-based training from the makers of Burp Suite, where each topic explains a bug class and then makes you exploit it, which is why it beats reading about injection.
• OWASP Web Security Testing Guide: the checklist we work from during a review, at version 4.2 with 5.0 in development, and it names the test rather than the tool.

Defensive engineering

• OWASP Cheat Sheet Series: one page per control, short enough to paste into a code review, with named project leaders and a CC BY-SA 4.0 licence that lets you reuse it inside a company.
• OWASP ASVS: the requirements list to put in a contract or a definition of done, with 5.0.0 as the stable version and every requirement written to be testable.
• NIST SP 800-218, SSDF 1.1: secure development practices stated as outcomes rather than products, which makes them something a supplier can be asked to follow.
• SLSA: supply-chain levels for build artefacts, useful when the question is whether the binary you deploy came from the commit you reviewed; the current specification is v1.2.

Vulnerability databases

• CISA Known Exploited Vulnerabilities catalog: the shortest path from the full CVE stream to the ones being exploited, published as CSV and JSON so it can drive a patch queue instead of a reading list.
• OSV: one API over GitHub advisories, PyPA, RustSec and other ecosystems, with affected version ranges and commit hashes instead of prose.

Standards and taxonomies

• MITRE ATT&CK: the shared vocabulary for adversary behaviour, now at v20, best used to describe what you would detect rather than to score your maturity.
• CWE: the weakness taxonomy behind most CVE records, with 944 entries today and 5.0 plus schema 8.0 scheduled for 28 October 2026, so check which version a tool maps to.

Vendor advisories

• Microsoft Security Update Guide: Microsoft's advisory stream, published by the Microsoft Security Response Center, and the place where a Windows or Office fix is described by the party that shipped it.
• AWS Security Bulletins: AWS notices split into Important and Informational, with an RSS feed that covers only the last 30 days, which makes the site the archive.

Academic work

• USENIX Security '26 proceedings: the complete proceedings of the 2026 symposium, published by USENIX, and the place to read a mechanism before a vendor gives it a product name.

One blog and one newsletter

• Google Project Zero: relaunched in December 2025 and still publishing full exploit-chain write-ups, with posts from 6 October 2026 in the current archive.
• tl;dr sec: Clint Gibler's weekly newsletter, about seven minutes, and the only aggregator we keep because it links out to primary sources instead of rewriting them.

What would remove an entry

Three things, and any one of them is enough. A version is superseded and the page stops pointing at the current one. The category expects movement and the page shows none for six months. The page stops being fetchable without a login or an unexpected redirect.

There is a fourth, quieter one: the entry stops answering the question in its own line. That usually means the field moved and the line did not, and it is the failure a link checker will never catch.

This list is dated October 2026. When we check it again, some of these fifteen will be removed, and they will not move to an archive at the bottom of the page. A reading list with a graveyard is a list nobody prunes.

Where this fits our work

We keep the list because security review sits inside the research work we do for clients, and because a review that starts from a dead link wastes the first hour. Our research services describe how we run that review.

The same rule applies to the collections we publish. Bounty Atlas is our curated set of bug bounty programmes, and a programme stays listed while it is active and pays, not because it was interesting once.

The durable part here is not the fifteen links. It is four questions and a quarterly fetch. Keep those and your list will look different from ours, which is the correct outcome, because you run different systems.