[bavarianbob]

Awesome project!

As someone deeply familiar with this problem (ex-JupiterOne), I'd caution against asserting that 'deep level of customization' is a differentiator. Your buyer (CISO) and userbase (Sec Engs) are drowning. They (and I) don't want yet another product to build on top of. This is a key reason why Wiz is so successful -- an operator can turn Wiz on and immediately receive value, no adjustments or additions needed.

I'd strategically focus on making the 'actionability' part the cornerstone of the product and really become obsessed with making that part of your product incredible. The Goliath-killing story you need will be formed by figuring out how to get your product to the point where someone can turn it on and immediately receive value for the most impactful security problems first (ex: Log4J) and the total surface area of problems the product solves for second.

[mike_d]

I would second this. No security person says "I don't have enough problems to look into."

Security spending is down, so navel gazing products are going to be a really hard sell. Figure out how to actually solve problems in an automated/semi-automated way and ship that instead.

The other issue with all of these tools is handling onboarding/integrations and getting terrible visibility as a result. A big market gap I see is a tool that can use the vulnerabilities it discovers to further information collection just like a real attacker would. Found Splunk creds in a log? Awesome, start using them. Syslog in an S3 bucket... boom. You are now hitting the stuff that every other ASM/visualization tool has missed.

[alexchantavy]

Makes sense -- we're focused on fixing problems over just being yet another Jira ticket generator.

> Found Splunk creds in a log? Awesome, start using them. Syslog in an S3 bucket... boom. You are now hitting the stuff that every other ASM/visualization tool has missed.

This is my dream :). This past weekend I was playing around with something where if I clicked on a SecretsManagerSecret node then it'd give me the CLI commands to assume the roles and then retrieve the secret. It'd be neat to take it a step further and be able to click here and get a shell -- I don't think we're _that_ far off from that (but for now to be very clear we're focusing on read-only actions only since a security tool with permissions to do scary things in your environment kinda defeats the purpose).

[alexchantavy]

Thank you, this is very helpful especially given your experience in the space. I intended to frame this like "there are many tools that let a security team can pull in data from the cloud providers and detect misconfigurations, but this becomes soo much more useful when they're able to contextualize it against their internal data". If I'm responding to log4j, I want to know all of the services that are running that affected library, which ones are internet open, and who in the organization owns it. That last part is key for actionability.