The quote you use got me to further research the market and speak to users of those toolings. From speaking to the users it was evident that the amount of misconfigurations being deployed wasn't being reduced.

I imagine users of cloud scanning tools would also use a pro-active tool like Slauth or any other shift-left tool that would aim at preventing as opposed to reacting.

Again, I understand the skepticism using LLM's but currently everything is done manually and it shows that doesn't work well. So using LLM's is a quick way to improve the current situation and hopefully we can further compliment it with checks and balances

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://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 and 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/) to access my source code? 2. *Policy Accuracy:* How can I trust [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/ 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 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.

Comments URL: https://news.ycombinator.com/item?id=38516795

Points: 122

# Comments: 77

We conducted a lot of interviews and honestly were confused about the best place to start. How can we best ingest data in order to generate a “least-privilege” policy. We started with integrating with Github actions to intercept traffic and generate the policies that can be used for deployments.

Our roadmap includes a multi-layered approach of analyzing data through traffic, static code and patterns/context in order to address more use-cases.

For now, we would love to learn from AWS partners and heavy AWS users how they currently deal with IAM and what an ideal solution would look like for them.

Comments URL: https://news.ycombinator.com/item?id=36195525

Points: 2

# Comments: 0

If you're an engineer, you probably know how tedious and error-prone it can be to manually write IAM policies. We surveyed over 70 engineers and found out that a majority are using or have used wildcards (*) in order to quickly write IAM policies.

By using client-side monitoring or via a proxy, Slauth.io observes all of the API activity and generates a policy based on functionality and least privileges.

Once deployed in a remote environment, or run locally, you will need to run an end-to-end test using a wildcard policy. Slauth will observe the activity, apply its logic based on large amounts of behavioral patterns of the service you deploy, and create a high quality IAM policy.

The IAM policy will be presented through the Slauth Dashboard where it can be copy/pasted or as a pull-request into your Git repository ready to be reviewed. Integrations with IaC services such as Terraform are also available.

Our objective is to automate manual error-prone IAM policy writing in order to increase engineering velocity, reduce friction and harden security.

Would love your feedback on the value proposition and if you would use the AWS SDK or Slauth proxy for onboarding.

Feel free to also sign up for Beta usage! https://www.slauth.io

Comments URL: https://news.ycombinator.com/item?id=34038663

Points: 63

# Comments: 32