Launch HN: Slauth (YC S22) – auto-generate secure IAM policies for AWS and GCP

Hi HN, We're Daniel and Bruno and working on https://slauth.io/ https://slauth.io/. Slauth.io is a CLI to auto-generate secure IAM policies for AWS, and GCP (Azure in the next few days!). We enable development teams to speed up creating secure policies and reduce over-permissive policies being deployed to the cloud. Check out the video or give our open-source CLI a try with one of the sample repo's on https://github.com/slauth-io/slauth-cli https://github.com/slauth-io/slauth-cli https://www.loom.com/share/bd02211659eb4c7f9b335e34094b57cb?sid=f5e84cb2-6939-4d7f-9ed8-90521c90f6de https://www.loom.com/share/bd02211659eb4c7f9b335e34094b57cb?... We got into the cloud access market by coincidence and were amazed by the amount of money spent on IAM. Current tooling such as http://Ermetic.com http://Ermetic.com and http://wiz.io/ http://wiz.io/ visualize IAM misconfigurations post deployment but don't actually change engineering behavior, leaving organizations in a constant loop of engineers deploying over-permissive policies ⇒ security engineers/CISO's getting alerts ⇒ Jira tickets created begging developers to remediate ⇒ New over-permissive policies being deployed again. We interviewed hundreds of developers and DevOps engineers and discovered two key pain points: 1. *IAM is a Hassle:* Developers despise dealing with IAM intricacies. 2. *Speed vs. Security:* IAM was slowing them down in deploying quality code swiftly. So the objective is automate policy creation so that developers don't have to deal with it, and harden IAM security pre-deployment. We employ Large Language Models (currently OpenAI GPT-4) to scan code in any language. Through a series of prompts, we identify service calls and the actions required. The resource name receives a placeholder unless its embedded in the code. We aim in the future to create a static code analyzer in order to not send any source code to LLM's but for now using LLM's is the fastest way to market and somewhat accepted by the industry through the use of Github Copilot etc. You can use the CLI in the terminal or actually integrate it in your CI/CD and have it become a part of your development team workflow. Three main questions we receive 1. *Security Concerns:* How can I trust [Slauth.io](http://slauth.io/ http://slauth.io/) to access my source code? 2. *Policy Accuracy:* How can I trust [Slauth.io](http://slauth.io/ http://slauth.io/) creates the right policies? 3. *Differentiation:* How are you different from IAMLive, IAMBic AccessAnalyzer or Policy Sentry? To address the first concern, we don't access your code directly. Instead, we offer a CLI that integrates into your CI/CD pipeline, allowing local code scanning. http://slauth.io/ http://slauth.io/ uses your OpenAI key to convert the code into a secure policy, with the option to output results to *`stdout`* or a file for artifact upload and download. That does mean OpenAI has access to the source code located in the path you set to be scanned as we need to know which SDK calls are performed to generate the policies. We have extensively tested it on AWS , Typescript and GPT 4 with very good results (>95% accuracy). We do know these accuracies drop when using GPT 3.5 so if possible, use GPT 4 as we are improving the prompts. GCP and Azure have been tested less but the results when using GPT 4 seem equally high. We also have experienced some hallucinations but they have not effected the outcome of a secure policy but merely the structure of how the policy is generated. That is not to say that it is 100% reliable hence we aim to provide toolings to double check policies through policy simulators and other means. Compared to competitors, we focus mainly on generating secure policies pre-deployment and automating as much as possible. We were inspired by IAMLive but it wasn't as scalable to use across development teams. Policy Sentry is great for templates but with http://Slauth.io http://Slauth.io you actually get a granular least privilege policy. Lastly, access analyzer is used to harden security policies which have already been deployed which is similar to other cloud scanning tools and creates a strange reactive process to security. The new access-analyzer feature checks policy diffs in your CDK but again doesn't actually generate the policy pre-deployment. We recognise some engineers are very capable of creating secure policies but similar to using Checkov and TFscan in the context of IaC deployment, we believe using Slauth.io will become a necessity in your CI/CD when deploying service permissions to make sure no IAM misconfiguration appear in the cloud. Would love to get your feedback and feel free to interact on our Github repo and join our Slack community.