sottlmarek/DevSecOps: an open source tool index for cloud security work

What the DevSecOps library actually is, and who it is for

This repository is not a scanner, an agent or a CI plugin. It is a Markdown document, with the README as the product, that collects open source security tools and arranges them by where they sit in a delivery pipeline. The README states the goal directly: "The main goal is to provide to the engineers a guide through opensource DevSecOps tooling." The scope is bounded on purpose. The same paragraph says the repository "covers only cyber security in the cloud and the DevSecOps scope", so general application security, endpoint tooling and compliance paperwork are out of frame.

The audience follows from that. A platform or security engineer who has been told to add scanning to a pipeline, and who does not yet know the names of the tools, gets the most from it. The table of contents doubles as a checklist of stages: pre-commit, secrets management, dependency management, supply chain, SAST, DAST, continuous deployment security, Kubernetes, containers, multi-cloud, AWS, GCP, Azure, policy as code, chaos engineering, infrastructure as code security, orchestration and AI. Someone building a security programme from scratch can walk that list and ask which stages they have nothing for.

It is less useful to a team that already runs a scanner and wants to compare two specific tools in depth. Each row is a name, a URL, a one-line description and a star badge. There is no comparison column, no version, no note on which tools overlap.

How the library is structured and how entries get in

The whole artefact is a set of Markdown tables. Each row carries a tool name, a link to its repository or documentation, a short description, and a badge image that pulls the GitHub star count at render time. The pre-commit section, for example, lists git-secrets for preventing secret commits, Talisman for detecting and preventing secrets from being checked in, Threat Dragon as an OWASP threat modelling tool, and pytm as "a Pythonic framework for threat modeling". Threat modelling sits in that early section on the argument that models are built before or during development, not after.

The contribution rules are the interesting part, because they describe the editorial policy rather than the content. A pull request must state the tool, the reason for adding it, the star count, the maturity and the topic. The rules ask for "Fact over feelings or personal opinions", for a source, and for the library style to be followed. Duplicates are rejected: "one tool, one topic". Two constraints shape what can appear at all: "Currently open-source only" and "Add only active projects". There is also a note that this is "an early version of the library" and that the author recommends submitting pull requests after the first official release.

That last line is worth reading twice. The repository invites contributions and then asks contributors to wait. In practice the rule set is a quality filter that is only as good as the reviewers applying it, and the README does not describe a review process, a cadence for re-checking whether a listed project is still active, or a way for readers to see when a row was last validated.

Using the library: no install, just a clone and a read

There is nothing to install. The repository has no package manifest, no build step and no executable. The top level contains .github/, LICENSE, README.md, assets/ and devsecopsmanifesto.md, which is the layout of a documentation project. The content lives in README.md, so the practical first step is to get the file locally or open it on the repository page.

To keep a copy next to your own pipeline configuration, clone the default branch:

git clone https://github.com/sottlmarek/DevSecOps.git

After the clone you get the README and the assets directory used by the sponsor logos and badges. The README is what you read; assets/ only holds images.

A realistic first use is picking one stage and turning its rows into a shortlist. If your immediate problem is secrets reaching the repository, the pre-commit table names git-secrets and Talisman, and the secrets management section is the next place to look. From there you leave this repository and go to the linked project, because that is where installation, configuration and version information lives. The library gives you the candidate list and the one-line reason each candidate is there; it does not give you the commands to run any of them.

If you want to contribute, the rules require more than a link. A pull request should carry the tool, why it belongs, its star count, its maturity and its topic, and it should follow the existing table style. The README explicitly asks that typos be reported as an issue rather than through a pull request, which keeps the review queue for content changes.

Where the library stops being enough

The first limitation is that a curated list ages silently. The contribution rules say to add only active projects, but the README does not record when a row was added or last checked, and it does not say what happens when a listed tool is abandoned. A reader has no in-repo signal that a row is stale. The badge next to each name shows a star count, and a star count is not a maintenance signal; a project can be popular and unmaintained at the same time. Anyone using the list as a procurement shortlist should open the linked repository and read its own recent activity before committing.

The second limitation is depth. Descriptions are one line. For a tool like Threagile, described as "A Go framework for threat modeling", the row tells you the language and the category and nothing about inputs, outputs or how it fits a CI job. There is no indication of which tools in the same section overlap, so a reader who picks two secret scanners from the pre-commit table gets no warning that they solve the same problem.

The third is scope. The README is explicit that the library covers cloud and DevSecOps security only. If your question is about mobile application security, endpoint detection or secure code review training, this is the wrong index. It is also the wrong tool if you need a policy decision: the library lists policy-as-code tooling as a category but does not tell you which policy set to adopt or how to write one.

How it compares with OWASP and CNCF project indexes

The closest alternatives are the curated project lists published by foundations, such as the OWASP project inventory or the CNCF landscape for cloud native tooling. The difference is editorial control and breadth. Foundation indexes are backed by a governance process and, in the CNCF case, a maturity level assigned to each project after review. This repository assigns no maturity level of its own; it asks contributors to state maturity in the pull request description, which means the claim comes from the submitter rather than from a review body.

In exchange, the DevSecOps library is narrower in a useful way. It is organised around pipeline stages rather than around project hosting or vendor categories, so the structure itself answers the question "what do I need at the commit stage" or "what do I need for Kubernetes". A general cloud native landscape is organised around project type and scope, and finding the subset that fits a security pipeline takes more work. The trade is breadth and governance for a pipeline-shaped index.

A second alternative is simply the tool documentation of whatever you already run. If you already use a container scanner, its own docs will tell you about its Kubernetes integration more accurately than any list. The library is for the stage before that, when you do not yet know which names to look up.

Maintenance, contributions and the MIT licence

The repository is not archived, and the last push was on 2026-08-12. The README describes the project as an early version and recommends holding pull requests until the first official release, which suggests the maintainer expects the structure to change. There are no releases listed, so there is no version to pin and no changelog to read; the default branch is master and the README is the artefact.

The upgrade cost is therefore close to zero and also close to meaningless. Nothing here runs, so nothing breaks on upgrade. If you fork the library to keep an internal shortlist, you take on the job the repository does not do: recording when each entry was last checked and which entries your team has actually adopted. That is real work, and it is the work the contribution rules push onto submitters rather than onto the project.

The licence is MIT, which permits reuse and modification with the licence and copyright notice retained. Because the repository is a collection of links and short descriptions rather than bundled code, the licence on this repository does not extend to the tools it lists; each linked project carries its own licence, and those vary widely. Check the licence of any tool you adopt separately, and treat the MIT notice here as covering the README and the manifesto file.

Editorial conclusion

Use sottlmarek/DevSecOps when you are mapping a pipeline stage to candidate open source tools and want a starting shortlist: the pre-commit table alone lists git-secrets, Talisman, Threat Dragon, pytm and Threagile with one-line descriptions. Skip it if you need install instructions, version pins or a maintained compatibility matrix; the README carries none of those. Before relying on any entry, open the linked repository and check its own last commit date, because the library's contribution rules ask for active projects but the README does not say when each row was last verified.

Frequently asked questions

Official sources

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