My Arsenal of AWS Security Tools: a curated index of AWS security tooling

What the list actually is, and the problem it removes

AWS security tooling is scattered. A practitioner looking for an S3 bucket auditor, a CloudTrail triage script, an IAM enumeration utility and an adversary emulation framework normally ends up with four browser tabs, three blog posts and a half-remembered GitHub search. This repository compresses that search into a single Markdown file organised by task. The README's table of contents runs through Defensive (hardening, security assessment and inventory), Offensive, Purple Teaming and Adversary Emulation, Continuous Security Auditing, Digital Forensics and Incident Response, Development Security, S3 Buckets Auditing, Training, and a catch-all Other interesting tools/code section.

The audience is narrow and identifiable: cloud security engineers, penetration testers working against AWS accounts, and incident responders who need to know which open source project covers a given AWS service. It assumes the reader already knows what CloudTrail, IAM and S3 are. Nothing in the repository explains AWS concepts, and nothing in it configures a tool for you. The value is selection and grouping, not execution.

How the catalogue is structured: tables, badges and language tags

Every category is a Markdown table with four columns: Name, Description, Popularity and Metadata. The Name cell links to the project's GitHub repository. The Description cell is one sentence, often lifted from the project's own README, and frequently ends with the implementation language in parentheses, for example CloudMapper is described as helping you analyze your AWS environments (Python). The Popularity column holds a stars badge rendered by badgen.net, and the Metadata column stacks contributor, watcher, last-commit, open-issue and closed-issue badges for the same repository.

That badge-driven design is the whole mechanism. There is no build step, no script that regenerates the tables, and no index file beyond README.md. The repository's top level contains LICENSE, README.md, ami/, former-list.md and kreator/. The presence of former-list.md suggests entries get moved out rather than deleted when the maintainer decides they no longer belong in the main table, though the README does not describe the criteria for that move. The ami/ and kreator/ directories are not explained in the README text provided.

Because the tables reference badges rather than storing values, the freshness of any number depends on badgen.net and on GitHub's API, not on this repository's commit history. A row can look current while the linked project has been dormant for years.

Using the list: no install, just the README and its tables

There is no installer, no package and no CLI. The README gives no installation steps because there is nothing to install. The project is consumed by reading it, and the only sensible workflow is to keep a local copy of the README so you can search the tables offline and diff them over time.

The repository's top-level entries are LICENSE, README.md, ami/, former-list.md and kreator/. The README is the artefact you actually use. Its tables are the interface: Name, Description, Popularity and Metadata. To find entries that mention a service you care about, open README.md and search it for the term, then read the matching rows.

Each match gives you a project name, a one-line description and, in many rows, the implementation language in parentheses. From there you open the linked repository and read its own documentation. Treat the result as a shortlist, not a recommendation: the list records that a project exists and what it is written in, and nothing about whether it still works against the current AWS APIs.

Where the list stops being useful

The first limitation is that a catalogue cannot evaluate. Two entries in the Defensive table can be described in equally positive terms while one has been abandoned and the other is actively developed. The README does not carry a maintenance verdict, a last-release date, or a compatibility statement for any entry. The badges point at live GitHub data, which means the reader has to click through and interpret a last-commit timestamp themselves.

The second is scope drift. The README's own Prowler entry, for example, describes a tool that covers AWS, Azure and GCP, and ScoutSuite is described as multi-cloud. The repository is titled as an AWS list, so a reader who wants strictly AWS-only tooling has to filter multi-cloud projects out by reading descriptions rather than by trusting the category.

The third is that the list is a single point of failure for its own accuracy. If the maintainer stops pushing, the tables freeze while the linked projects keep moving. The last push to this repository was on 2026-07-07, which is recent enough that the list is not stale, but that says nothing about the state of the projects it links to.

Finally, this is the wrong tool entirely if you need reproducible output. There is no version to pin, no changelog in the retrieved material, and no release. If your compliance process requires an artefact with a version number, this repository will not satisfy it.

Alternatives, and how their approach differs

The closest functional alternative is to skip the list and go straight to a scanner that also ships its own documentation and checks. Prowler, which this repository lists first under Defensive, is a security assessment tool for AWS, Azure and GCP covering CIS, NIST 800, NIST CSF, CISA, FedRAMP, PCI-DSS, GDPR, HIPAA, FFIEC, SOC2, GXP, Well-Architected Security and ENS. The difference in approach is fundamental: Prowler executes checks against an account and produces findings, while this repository only tells you Prowler exists. If your question is what is misconfigured in my account, the list is the wrong starting point.

A second alternative is a policy engine such as Cloud Custodian, described here as a rules engine for cloud security, cost optimization and governance with a YAML DSL for policies that query, filter and take actions on resources. That is declarative and continuous, and it produces enforcement rather than a reading list. A third is ScoutSuite, a multi-cloud security auditing tool for AWS, Google Cloud and Azure, which generates an assessment report from API data.

The honest comparison is that all three are tools and this is an index of tools. What the index does that none of them do is place offensive, defensive, DFIR and training projects in one taxonomy, which matters when you are assembling a programme rather than running a single scan.

Licence, contribution and the cost of keeping it current

The repository is licensed Apache-2.0, and the LICENSE file sits at the top level. That covers the list content itself. It does not cover the projects the list points to, each of which carries its own licence and its own obligations, so a reader who follows a link and deploys that tool inherits that tool's terms. Nothing here is legal advice; check the linked repository's licence before you vendor anything.

The contribution path is stated plainly in the README: send a PR, and make sure your tool is open source. There is no stated review checklist beyond that, and the README does not document how entries are removed or how dead links are handled. The existence of former-list.md implies a retirement mechanism but the README does not describe it.

The real maintenance cost falls on the reader, not the maintainer. Because the tables carry badges instead of pinned metadata, every time you consult the list you are doing a fresh evaluation of the underlying projects. That is cheap for a one-off search and expensive if you want a stable, auditable inventory of approved tooling.

Editorial conclusion

Adopt it as a starting map if you are building an AWS security toolchain and want one page that names Prowler, ScoutSuite, CloudMapper and Cloud Custodian side by side with their languages and categories. Do not adopt it if you need a maintained, versioned dependency, an SBOM, or anything you can pin in CI: the repository has no releases, no package, and its content is a Markdown table. Before relying on any entry, open the linked repository and verify its own last-commit badge and licence, because the list itself only tells you the tool exists and what language it is written in.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. toniblyx/my-arsenal-of-aws-security-tools on GitHub