Hi HN! I’m Aman and along with my cofounder Aarya, we're building Jungl (https://jungl.cloud), an event-driven security tool for detecting and remediating AWS misconfigurations.

Most cloud security programs we've spoken to fall into one of two patterns: periodic scanners that find issues hours later and generate tickets to fix resource misconfigurations, or restrictive IaC/approval workflows that slow developers down.

Jungl's approach is to evaluate the operational and security risks for resources that are created/updated and take quick action by monitoring and/or applying a remediation - automatically. The goal is to reduce the number of manual, hands-on fixes of resource non-compliance, giving developers the freedom to create/update resources however they want on AWS while still allowing cyber teams to ensure enterprise security. Think of us as a cloud engineer who works with every developer behind the scenes to monitor (and fix) each resource to make sure it won’t cause a security issue.

How it works: - We ingest relevant CloudTrail events for the 6 services we support right now - We evaluate rules (that you enable at a service-level) that produce: discovery (what’s wrong + evidence), recommended actions, and whether the discovery is eligible for automated remediation - If automated remediation is enabled, Jungl applies only explicit, scoped remediations. Otherwise, it generates a ticket for a human to accept or reject.

What we mean by "context": A big challenge with remediation is avoiding breaking systems. We use context to understand the intent behind each resource by looking at: - the resource’s exposure surface - dependency graph (what other resources it is connected to) - how the resource is being called or used in your codebase - the severity of the rule - historical logs of how the resource was being used

A concrete example: A bucket policy with access to the public - the last thing you want is for a developer to accidentally forget to remove public access and then 12 hours later, you see that the bucket was inviting unsolicited traffic. Jungl would immediately remove that bucket policy statement if the rule was enabled due to the criticality of it.

(We recorded a short demo here: https://youtu.be/P_GMyNwBZ5k?t=252)

We're early and still increasing coverage and the rule library. Some resources have multiple plausible fixes and choosing the least disruptive option is the hard part so we're building the workflows for that now, and building the application to support more context-aware decision making.

If you want to give us a try, here's the creds: Website: https://jungl.cloud/sign-in Username: hn@jungl.cloud Password: RG^J$T2!huMsF2c

And if you run AWS infra and have opinions about automated remediation (good or bad) or what we're doing, we'd love feedback.

Thanks for reading!