# OWASP DevGuide: requirements you can turn into an acceptance test > The OWASP Developer Guide is a requirements catalogue for secure development, written as verifiable statements rather than advice. Version 4.2.0 reorganised its checklists around the OWASP Proactive Controls and added identifier codes. **OWASP/DevGuide** — The OWASP Developer Guide - Repository: https://github.com/OWASP/DevGuide - Website: https://devguide.owasp.org - Stars: 2,184 · Forks: 408 - Language: Unknown - License: CC-BY-SA-4.0 - Published: 2026-10-08 · Updated: 2026-10-08 · Language: en - Canonical page: https://hysenlabs.com/projects/owasp-devguide ## A document about twenty-four years old, still on the same repository The DevGuide is one of the original OWASP documents, and the README makes a point of the archive behind it: the repository holds previous versions going all the way back to the very first 1.0 release from 2002, as a PDF still reachable in the repository history. That is unusual for a security document and it is genuinely useful when you need to show what the advice was at a given point in an audit. The published form is a web document at devguide.owasp.org, with a PDF download attached to each release. The content itself lives in a docs/ directory alongside mkdocs.yaml, which is the site generator configuration, and four separate PDF configurations. ```yaml mkdocs-pdf-en.yaml mkdocs-pdf-es.yaml mkdocs-pdf-fa.yaml mkdocs-pdf-pt-br.yaml ``` One configuration per language tells you something about how the translations are handled: English, Spanish, Persian and Brazilian Portuguese each get their own PDF build with their own spell checker. The repository carries .spellcheck-en.yaml, .spellcheck-es.yaml and .spellcheck-pt-br.yaml alongside matching word lists, so a misspelling in one language does not fail the build for the others. The tagline at the bottom of the README is accessible security for developers, and it is the design constraint that shapes the whole document. Guidance that a developer cannot act on without specialist knowledge fails the brief, which is why much of the text is phrased as something you can check rather than something you should consider. ## Checklists restructured around the Proactive Controls The most consequential change in recent versions is to the checklists, described in the v4.1.9 release notes as large scale revisions that now follow the later versions of the OWASP Secure Coding Practices quick reference guide more closely, with the checklist sections organised according to the latest version of the OWASP Top 10 Proactive Controls. That is a reorganisation of the guide's spine rather than a set of new recommendations. If you mapped requirements to controls before 4.1.9, that mapping needs redoing. If you are starting fresh, the alignment is a genuine advantage: a checklist section and a proactive control now line up, so a project already reporting against Proactive Controls can use the DevGuide as the implementation detail rather than as a second reporting taxonomy. Version 4.2.0 added the piece that makes requirements usable in a review. Identifiers were added for each headline in the checklist, and the checklist gained information about the OWASP Secure Coding Practices, including an explicit addition of SCP 115. Several requirements around session management were also generalised, and a missing requirement was identified and closed for one specific item, digital identities, in a change described as moving session management to chapter C7. Requirements that carry a code can be quoted in a ticket, referenced in a test name, or tracked in a compliance spreadsheet without paraphrasing. The practical difference is between an audit finding that says follow the OWASP guide and one that says the control for concurrent sessions was not implemented. Only the second one can be closed. ## Where the content lives moved at version 4.1.8 This is the detail most likely to waste an afternoon. The v4.1.8 release notes say that following a reboot of the guide in 2023, versions 4.0 through 4.1.7 were published in the www-project-developer-guide repository, and that starting from 4.1.8 the guide was brought back into the DevGuide repository. So for a stretch of versions there were two repositories holding parts of the same document, and the wiki collects the old versions. The README states the same split in its own way: the content for the Developer Guide project pages is in its own repository, at OWASP/www-project-developer-guide, while this repository holds the guide itself. Two things in the repository still point at the old location and are worth knowing before you trust a link. The build status badge in the README resolves to actions/workflows in www-project-developer-guide rather than to this repository, and the v4.1.8 release notes link their PDF to a download path under threat-dragon rather than under OWASP/DevGuide. Both are almost certainly copy and paste leftovers from the move. Neither changes the content, and both are the kind of thing that makes a new contributor file an issue about a broken link that is not broken for anyone else. If you are pinning an audit reference, pin the version number and download the PDF attached to that release rather than linking devguide.owasp.org, which always shows whatever is current. ## Requirements, not a tutorial library The DevGuide sits in an awkward and useful middle position. It is not a framework cookbook. It will not tell you the exact header to set in a particular web framework's security middleware, and it is not organised by language or stack in the way a tutorial site is. What it does give you is a statement of what must be true, phrased so that a reader can decide whether it is. The v4.2.0 notes show the granularity: one change clarified a password sending recommendation, another added a page on Java security libraries, another fixed a Pytm description, and another added new pages for the Threat Model Library and Threat Modeling projects. Those are small edits, and together they describe the document's shape. Java security libraries get their own page because choosing a vetted crypto provider is a requirement that cannot be satisfied by saying be careful. Pytm, a threat modelling tool, gets a description fix because an inaccurate tool description misleads the reader doing the modelling. The threat modelling pages point at other OWASP projects rather than duplicating their material, which keeps the DevGuide from becoming a stale copy of everything else in the foundation. The result is a document you would pair with something else. Requirements here, framework specifics from the framework, threat modelling from Threat Modeler, and a code review process of your own. Trying to use DevGuide as a standalone curriculum is where people get disappointed. ## Contributing, review and who signs off The contribution path is documented rather than implied. contributing.md holds the guidelines, code_of_conduct.md the conduct expectations, security.md exists for reporting, and release-process.md describes how a version becomes a release. Issues and pull requests both go to the DevGuide repository itself, and the issue link points at a chooser template rather than a bare new issue form. Five people are listed as project leaders and editors: Andra Lezza, Shruti Kulkarni, Vandana Verma Sehgal, Harold Blankenship and Jon Gadsden. For a document that ends up quoted in audit findings and procurement responses, knowing who reviews a change before it ships is part of trusting it, and the leaders are the contact point the release notes themselves give for queries about a version. The repository also carries a .markdownlint.yaml and a .lycheeignore, the latter being a list of URLs to skip in link checking. That detail says something honest about a long-lived document with two decades of accumulated links: some of them are going to be dead and there is a decision about which failures matter. The build badge for continuous integration is present, and the project is an OWASP Lab project with an OpenSSF Best Practices badge pointing at the project entry. Licensing is CC-BY-SA-4.0, with license.txt in the repository. That matters more than it first appears: a Creative Commons share-alike licence lets you copy the requirements into your own internal standards document, and the share-alike condition applies to adaptations of the material. Attribution is required. ## What this document will not do for you The DevGuide cannot tell you whether your system is secure. It enumerates requirements, and a requirement is satisfied or not against a specific implementation, which means somebody still has to check. A team that adopts the guide without building the check has adopted a longer document. It is also not current by default. This is a security guide that has been revised over two decades, and a static PDF is a snapshot of an editorial position at a point in time. The 4.2.0 release from March 2026 is the newest, and the repository's last push was on 2026-09-23, so there is work on main that no PDF reflects yet. Anyone citing it in a control mapping should cite the version, not the URL. Then there is the scope question. OWASP guidance is written for web applications, and the topics on the repository are simply owasp and owasp-developer-guide, which is a fair signal that there is no broader application security coverage here. Native mobile, embedded, industrial control and machine learning systems have their own OWASP projects, and for most of those a different document is the correct starting point. The honest summary is that this is a requirements baseline, well maintained by named people, with a version history you can cite and a checklist structure aligned to Proactive Controls. Treating it as a checklist to work through is the use it was designed for. ## Conclusion The DevGuide is worth adopting when your team needs to argue about whether a control is done, because it is written as checkable statements with identifiers rather than as narrative guidance. It is the wrong document for a threat model, a code review or a specific framework tutorial, and it will not tell you how to configure your framework. Two things to settle before you build a process on it. Pin a version, since 4.1.8, 4.1.9 and 4.2.0 reorganised checklists substantially and a document that moves under you makes a compliance argument fragile. And note where the requirement actually lives, because content moved between the DevGuide and www-project-developer-guide repositories at 4.1.8 and the README still links build status to the older location. Start with the checklist chapter for the language you write in, then map one requirement to one test. ## FAQ ### What is the OWASP Developer Guide used for? It is a catalogue of secure development requirements written so a developer can tell whether something is done, published as a web document at devguide.owasp.org with a PDF per release. Version 4.2.0 added identifiers to checklist headlines so requirements can be referenced in reviews and tickets. ### How is the DevGuide different from the OWASP Top 10 or ASVS? The Top 10 is a short awareness list of broad risk categories and ASVS is a verification standard with numbered requirements to audit against. The DevGuide is requirements written for people building software, and since version 4.1.9 its checklist sections have been organised according to the latest OWASP Top 10 Proactive Controls, so the two line up more closely than they used to. ### Which version of the OWASP Developer Guide should I use? The newest release is 4.2.0 from March 2026, and each release attaches a PDF you can download and cite. Note that versions 4.0 through 4.1.7 were published in the www-project-developer-guide repository and were brought back into the DevGuide repository from 4.1.8, so older material lives in two places. ### Can I translate the OWASP Developer Guide? Contributions are welcome through the contributing guidelines and the code of conduct in the repository, with issues and pull requests handled on GitHub. Translations exist for several languages, with separate PDF builds and spell checkers for English, Spanish, Persian and Brazilian Portuguese, and past releases include a Farsi translation for chapter 2. ## Sources - [License: CC-BY-SA-4.0](https://github.com/OWASP/DevGuide/blob/main/LICENSE) - [OWASP/DevGuide on GitHub](https://github.com/OWASP/DevGuide) - [Project website](https://devguide.owasp.org) - [README](https://github.com/OWASP/DevGuide/blob/main/README.md) - [Releases](https://github.com/OWASP/DevGuide/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/owasp-devguide