Classic, selling the poison and the cure. Access controls shouldn't be so convoluted and opaque that it requires a separate service to analyze your configurations. Crazy that we've made such a mess of the security landscape that we need AI systems to tell us if we're leaking info.
Not the case. I've seen seasoned developers (not to single them out) make simple stupid mistakes with the S3 bucket ACL, Permissions, and Policies. The issue has to do with the sheer laziness of "let's create unstructured data buckets, write once and forget it all" mentality. At some point, this sort of service can be useful in identifying the "crown jewels" within the buckets. Beyond that, the ACL is noAccess by default, so I can't agree with your assertion that AWS is somehow making it difficult to sell more services in favor of vendor lockin.
Yes, thank you for linking, but fail to see the correlation. This tool is scanning public HTTPS endpoints based on keywords in its dictionary to discover misconfigured buckets. AWS doesn't manage the bucket Perms/ACL, the customer does. AWS' shared-responsibility model clearly defines all of this. The customer is responsible for the bucket ACL, the same would apply if I ran my stack in a data center and went on to configure Apache/NGNIX with open Directory indexes that allowed anyone to traverse them.
If you have data that matters, it needs dual controls. The idea that a company would place PII on a site publicly accessible and protected only by ACL is ridiculous.
Instead of futzing with machine learning, use network or crypto controls to prevent access, and have a different chain of command manage that access in your company.
