hahwul's DevSecOps roadmap: a link index sorted by lifecycle stage

A roadmap image and a link list, with no code behind it

A DevSecOps repository with no source directory is not a contradiction. This one is a curated index, and the file tree tells you what you are dealing with before you read a word of prose: `README.md` alongside `README.ko.md` and `README.jp.md`, a `tools/` directory, an `assets/` folder holding the logo variants, two graphics named `DevSecOps.png` and `DevSecOps.xml`, `CONTRIBUTORS.svg`, `CONTRIBUTING.md`, a `LICENSE`, a `justfile`, and a `.github/` directory. There is no package manifest and no build step.

GitHub classifies the primary language as Just, which sounds odd for a reading list until you look at that recipe file. The classification turns out to be accurate, because the only executable content in the repository is a pair of recipes that lint GitHub Actions YAML. The project is licensed MIT, is not archived, and its last push was on 2026-09-18. It publishes no GitHub releases at all, which is normal for this genre and also means there is no changelog to check when a link goes stale.

The README opens with a picture element that switches between `assets/devsecops-dark.png` and `assets/devsecops-light.png` based on the reader's colour scheme, then states the purpose in one line: a roadmap for everyone who wants DevSecOps. What follows is the standard definition. DevSecOps is described as a culture and practice that integrates security into every phase of the software development lifecycle, with collaboration between development, security and operations teams, and the goal of building secure software from the ground up so that deployment is both faster and safer. Every framework linked later in the document is an elaboration of that sentence, not a disagreement with it.

Seven numbered stages, from overview to operate and monitor

The bulk of the work is a numbered resource path. The table of contents lists stage zero through stage six: DevSecOps Overview, Design, Develop, Build, Test, Deploy, and Operate and Monitor. Underneath that sit four further sections titled Security of CICD, Awesome resources, Other roadmaps, and Wrap Up, followed by a contributor roster and a link to the contribution guide.

Stage zero is the shortest and the most useful for a newcomer, because it points at the primary sources rather than commentary. It links the Wikipedia and Grokipedia sections on security shifting left, an OWASP Belgium meetup deck called Zero to DevSecOps, a Black Hat USA 2019 presentation on what, why and how, and a MITRE publication on security and test automation in DevSecOps. A reader who wants the argument rather than the tooling can start there.

The staging is the useful editorial decision in the document. Security work that arrives as an undifferentiated pile of links is hard to act on, because nobody owns it. Sorting the same material by the phase where it applies gives it an owner, which is the whole point of shifting security left. The README says outright that you do not have to follow the path linearly, and that you should jump to whichever section matches the problem in front of you.

Design stage: maturity models next to threat modelling tools

The Design stage splits into two labelled groups. The first is Development Lifecycle, and it is a list of maturity and practice frameworks: Microsoft's Secure Development Lifecycle practices page, OWASP's Software Assurance Maturity Model, the Building Security In Maturity Model, and NIST's Secure Software Development Framework white paper. Three of those four are maturity models, which tells you the emphasis. The question this stage asks is not which scanner to run but where your process currently stands and what the next rung looks like.

The second group is Threat Model, and it is a different genre entirely: the Wikipedia article on threat modelling, OWASP's community pages on threat modelling and on application threat modelling, the Agile Threat Modelling Toolkit at threagile.io, and OWASP Threat Dragon. The first two Design groups sit next to each other for a reason. A maturity model tells you whether you do threat modelling; the tools are what you use on the day you decide to.

That pairing is worth copying even if you never open this repository again, because most internal security reading lists pick one side and leave you to find the other yourself. If your organisation already has a SAMM score, the Threat Dragon entry gives a free modelling tool with a maintained web interface. If you have never modelled anything, the threagile.io toolkit is the more realistic starting point, because it is built around agile delivery cycles rather than a quarterly exercise.

Develop stage leads to vendor secure coding guides

The Develop stage opens with a Secure Coding group, and this is where the list stops being about process and starts being about language-specific documentation. The entries visible in that group are Apple's secure coding guide, Oracle's secure coding guidelines for Java SE, the OWASP Go secure coding practices guide, and Google's Android application security best practices. Microsoft and Apple supply both the secure development lifecycle material and per-language secure coding material, which is the pairing that makes those lists useful to an engineer rather than only to a programme manager.

The signal to take from this group is that secure coding guidance is treated as a per-language artefact. A single house style document will not cover memory safety in Go and XSS in an Android WebView, so the README's choice to link each platform's own guidance is a practical one. Nothing here is a new rule. It is a routing table.

What the README does not do at this stage is connect the coding guidance back to a policy. There is no section mapping a language rule to an enforcement point in a pipeline, and no code scanning configuration to copy. If you are the person who has to make secure coding stick, this list tells you which documents to treat as authoritative and leaves the enforcement mechanism to you.

The tools list lives in its own directory, not in the README

Product recommendations are deliberately kept out of the main document. The Tools section is a single paragraph and a single link to `./tools/README.md`. The README's description of that directory is specific about scope: static application security testing, dynamic application security testing, secret management, threat modelling, component analysis, and more, covering various stages of the lifecycle. The stated purpose is to reduce the time spent searching and deciding.

Separating the two is the correct call for a project at this size. Mature tools lists rot quickly, because every product changes tiers and renames editions. Putting the vendor names in their own file means a routine maintenance pass touches one document instead of the roadmap that people bookmark for the stage structure.

The one piece of automation in the repository belongs here too. The `justfile` holds two recipes, and both exist to keep the GitHub Actions directory tidy:

setup:
    brew install yamlfix

fix:
    yamlfix .github/workflows/*

Running the first recipe installs the formatter through Homebrew, which tells you the maintainer's own machine is macOS. Running the second rewrites the workflow files in place. That is the whole build story: a link list whose maintainer wanted the automation YAML to stay formatted.

Three language READMEs and a contribution guide

The README carries badges for contributions, English, Korean, and Japanese, and the tree confirms that both translated files exist as `README.ko.md` and `README.jp.md` rather than being aspirational links. For a list whose audience includes teams outside English-speaking markets, that is a meaningful amount of work, because a translated link list has to be re-checked against the same upstream pages rather than mechanically converted.

The README also spells out how to use itself, in six numbered steps: read the definition section if you are new, use the main roadmap image to orient yourself, explore the tools section, dig into the lifecycle resources, focus on the CI/CD security section if pipelines are your problem, and contribute if you find a broken link. The instruction to skip straight to a relevant section is the honest one. Nobody implements a security practice in six ordered steps, and a reader who pretends otherwise wastes a week.

Contributions run through `CONTRIBUTING.md`, which the badges and the table of contents both link to. A project of this kind lives or dies on link maintenance, and the repository makes that the explicit ask: suggestions, broken link reports, and new resources. It is MIT licensed, so the text is reusable, though the linked third-party material keeps its own terms and this repository says nothing about those.

Editorial conclusion

This repository is worth bookmarking as an index and nothing more. It is good at one thing: pointing a reader at the frameworks and vendor material that already exist, in an order that matches how software gets built. It cannot settle whether your team should adopt SAMM over the NIST SSDF, because it never argues for a choice, and it has no releases, so nothing tells you when a link was last verified. Read the seven numbered resource stages to see what your own gaps look like, then open the `tools/README.md` index when you are ready to evaluate specific products, and check whether the projects you adopt there document their own integration steps before assuming this list covered them.

Frequently asked questions

Official sources

1. hahwul/DevSecOps on GitHub
2. Issues
3. License: MIT
4. README