> have more insight into what, actually, the IAM Roles could do

We 100% do this, see https://eng.lyft.com/iam-whatever-you-say-iam-febce59d1e3b.

We evaluate the policies for the IAM principal against the resources to determine what actions they can perform on each resource. This is configurable too; here's the set of the default permission relationships shipped in OSS: https://github.com/cartography-cncf/cartography/blob/master/...

It doesn't cover conditions since those can be wacky complicated, and it doesn't cover resource policies (yet!) but in my experience this is still a very good heuristic that is already more accurate than AWS IAM Analyzer when I played with it.

The next step we're working on is to take this access map and correlate it with event data to see which permissions are used/unused so that we can prune them for ensuring least privilege. More to come here.

Edit: adding on for the part of your question about what features are paid or OSS, our paid offering is fully hosted and includes things like automatic suggested fixes, a natural language interface, customization with our dynamic schemas, and other bells and whistles. I'm not a fan of doing things like premium modules because I don't want to ever get in the position where I'm declining a pull request in open source because it covers a premium feature; that doesn't feel right.

Yes, that's why I linked to what I did and mentioned IAMSpy because the devil's in the details, especially with things like AWS SSO and OIDC providers, because those represent a whole class of principals that _could_ get into the Role but only a finite number of them that actually do, barring misconfiguration[1]

I think it would probably be unreasonable to say "IAM Conditions when?" in a Launch HN if one had to build those things from scratch. That would be ferociously hard and not a sane ask right out of the gate. But since IAMSpy already exists, and according to you there's some non-trivial amount of IAM evaluation already in Cartography, then what I'm asking is whether you envision your future as one of ("eh, it's good enough", "we're integrating more libraries that attempt to formalize IAM", or "we'll roll our own policy engine in python, how hard could it be")

Further illustrating my point, you linked to a .yaml file with "s3:GetObject" seemingly applied to an S3Bucket saying "can read" but that's for sure not systemically true for a monster list of reasons. I get the impression that Wiz makes their bread and butter on helping people understand when they actually have open S3 buckets and not just giving them a report full of false positives

I do appreciate this can come across as busting your chops, but I don't mean to shit on you, or your product, or your launch. I'm just pointing out that if you put "You can think of us as an open-core Wiz alternative" in the 2nd sentence of your announcement, there is a massive opportunity for expectations being out of alignment unless you have a plan to get from where you are to Industrial Grade Introspection. The other side of that coin is that if you do have the background for it, as your pseudo-resume implied, then it's a massive opportunity to give them a run for their $5 billion, too

1: and it's the misconfiguration that I would want a reasonable tool to chirp about, not "omfg token.actions.githubusercontent.com can get into your Role!"

Not at all, super appreciate the discussion and your detailed read!

> what I'm asking is whether you envision your future as one of ("eh, it's good enough", "we're integrating more libraries that attempt to formalize IAM", or "we'll roll our own policy engine in python, how hard could it be")

It's a combination of 2 and 3. Today we use the policyuniverse library for things like s3 bucket-policies, and we have that self-rolled policy engine described in that blog post I shared. I should've mentioned earlier that this is the first time I've seen IAMSpy, thanks for sharing.

I think we're currently pretty good at permissions evaluation since that feature gives lots of value as it is, but there is a lot more to do. Continuing to improve this and being able to connect that with other data is a priority since it's one of our main value propositions.

> there is a massive opportunity for expectations being out of alignment unless you have a plan to get from where you are to Industrial Grade Introspection.

Industrial Grade Introspection is absolutely the plan. I'll also add that we're especially interested in highlighting cases that involve permissions that go between providers - like Okta->AWS, Opal->AWS, etc - and we intend to be very competitive here.