I decided to create this tool for more pragmatic reasons. First, I've been at AWS for several years now, and security has always been a major issue in many companies I've worked for. Second, even if you're a specialist with a memory like a movie's mind, you can't manually check every corner of your environment to realistically assess whether a real problem exists. Third, existing scanners are great, but they're full of noise, and I suspect you know what such an "audit" looks like. You open a report, see that your account has 300+ findings, review the first ten, which turn out to be insignificant, and then dismiss the report. Here, I wanted to focus on truly realistic scenarios (although I suspect there's still a lot to refine).
That's why I didn't focus on an incredible number of checks, but rather on the correlation between them. Something like a vulnerability based on findings (Public Security Group with port 22 -> IMDSv1 -> IAM Roles on EC2 with high access), which individually might not seem dangerous, but when combined, they create a real opportunity for attackers. Taking a bit of inspiration from other scanners, I've also added an option to automatically fix the issue (of course, this is just a hint on how to do it, but it's always more convenient to get a ready-made Terraform snippet instead of searching for fixes in the documentation).
I still have a lot of ideas for developing this, so I'd like to show you what it looks like now and would love to hear your feedback on whether you think it makes sense or whether tools like Prowler have already completely covered this sector in terms of security. I've recently added CIS 3.0 and SOC 2 compliance reports. This isn't SaaS—it's completely open source with the simplest possible installation. Documentation is available on the repo.
If you have any questions or ideas, I would be extremely grateful for each one.
The 40% acceleration in the second half is the number that jumps out. That is not just "more groups", something changed operationally in the ecosystem around September 2025.
SafePay dominating Germany with 72 claims is worth watching. Most ransomware analysis focuses on US-heavy groups, but a group concentrating on a single non-US market suggests either language capability, specific supply chain access, or targeting of regulatory environments where disclosure pressure increases payment rates. Germany's strict GDPR enforcement could make the threat of a leak more effective than in markets where fines are lower.
The 35% of claims with no sector attribution is a significant gap. If those ~2700 unattributed claims skew toward smaller organizations without public sector classification, the actual concentration in SMB targets could be much higher than the data shows.
The point about ecosystem resilience is the most important takeaway for defenders. 129 active groups means the threat model is not "prevent group X" but "assume breach and limit blast radius." That shifts investment from detection toward segmentation, backup isolation, and recovery speed.
I use Claude Code a lot, especially when building infrastructure. The most important thing in my work isn't so much the memory architecture, but rather the good structure of CLAUDE.md (architectural decisions, file paths, rules like "do X, don't do Y"). And generally, the model follows these rules quite well. As for memory, storing feedback (corrections with explanations) is much more effective than storing just the facts. It's better to write something like "Don't simulate the database in integration tests because the tests passed, but the migration failed" than "the database is PostgreSQL 16."
It's the "healthy cluster" aspect that makes this scary. Partition errors are expected—that's what Jepsen is testing. However, stale reads during normal operation mean that most Galera deployments behind a round-robin load balancer silently encounter this problem. The classic scenario: we create a user on node A, the next request goes to node B, and the user doesn't exist yet. The solution is wsrep_sync_wait or pinning reads to the writer node, but most setups don't use either of these methods because they assume a healthy cluster equals consistent reads.
Well, this all makes sense for application code, but not necessarily for infrastructure changes. Imagine a failed Terraform merge that deletes the production database but opens the inbound at 0.0.0.0/0, and you can't undo it for 10 minutes. In my opinion, you need to pay attention to the narrow scope specific to a given project.
Generally, yes, the guidelines specify scope to repos and branches. However, the main problem is that the default policy only checks the recipient declaration when creating an OIDC. If you didn't manually create the second condition, you were/are vulnerable to this bug. And unless someone manually fixed it and created the policy before June 2025, you will still be vulnerable.
I see the UK government hasn't been on a good run lately. Google recently released the Cloud Threat Horizons H1 2026 report. A vulnerability in the OIDC trust policy can be exploited to gain admin access to AWS. The UK Government Digital Service was one of the affected organizations. Datadog found their IAM role misconfigured the same way.
Overall, it's interesting. OIDC is probably the most common practice for inter-service authentication today. The problem is that in practice, I've seen many configurations where OIDC could be used as an attack vector (missing sub claim condition, which effectively allows any token to assume the role).
In AWS, for example, DNSSEC Route53 signing is possible, but almost no one configures it. Generally, most people do a lot of good things about security, but they somehow forget about DNS.
That's why I didn't focus on an incredible number of checks, but rather on the correlation between them. Something like a vulnerability based on findings (Public Security Group with port 22 -> IMDSv1 -> IAM Roles on EC2 with high access), which individually might not seem dangerous, but when combined, they create a real opportunity for attackers. Taking a bit of inspiration from other scanners, I've also added an option to automatically fix the issue (of course, this is just a hint on how to do it, but it's always more convenient to get a ready-made Terraform snippet instead of searching for fixes in the documentation).
I still have a lot of ideas for developing this, so I'd like to show you what it looks like now and would love to hear your feedback on whether you think it makes sense or whether tools like Prowler have already completely covered this sector in terms of security. I've recently added CIS 3.0 and SOC 2 compliance reports. This isn't SaaS—it's completely open source with the simplest possible installation. Documentation is available on the repo.
If you have any questions or ideas, I would be extremely grateful for each one.