A way to handle this pragmatically is give board advisory shares to a person who straddles the following abilities (and listen to them), until you have enough funds to hire a sec eng:
- is technical enough to know what needs to get done and why
- has enough startup sec experience to know what pragmatic advice is in light of tight funding for startups
If you’re YC-backed this should be easy to source.
Why this thread matters and I’ll close it is dev-speak (“awesome, delightful, obsessed”) doesn’t matter at all for selling to a sec team, which is who is going to pay and vet this. That language just tells me it’s going to be a slog through VC sales-speak to answer the concerns I listed. It’s all about the above I mentioned, plus the tech setup which I think you have done with the right mindset (just plug into everything, parse it, ship it to the usual sources. Don’t try to reinvent Jira or Slack please).
The other reason you have to think about this is what market SOARs sell into. They aren’t needed until a lot of other due diligence is done - EDR deployments, enterprise sec, email sec, etc etc. So, that’s a decently established company, and if they’re paying for SOAR, it means they are either the lucky program with healthy budget support, or have a threat environment just justifying it all. A lot of places just get a bad MSSP and call it a day. So, if you are a company justifying SOAR (bc of implied budget and program maturity), you deal with threat actors who know their stuff well enough. And, as a fair number of exploits indicate this part 2-3 years, they know to evaluate SaaS vendors as the way in. Looking at the stack, they could try Okta, CrowdStike, MSFT, GSuite and all the difficulty there… or the two data engineers and their startup. Gotta take it seriously, a lot of sec is abstract risk but this is happening in the wild now.
Really appreciate the advice here. I also hate security theatre. We will make it triple clear that our Cloud version is JUST for preview, not production.
Repeat (as we mentioned in our README) for anybody reading this thread: Cloud is just for preview! Upload a known malware SHA-256 sample, send it off to VirusTotal, then pass the JSON response into a LLM action to summarize. There are plenty of workflows you can run to test our platform without exposing sensitive data.
Excited to work on securing our platform though. Thanks for the basic checklist. We have a lot more work to do and will find the best security professionals to work with. There are plenty of scary good practitioners, folks who have seen and responded to APTs in their previous work, within the YC network. The first thing we did when we got into YC was network with the YC security community.
Here are some shout outs who are helping YC companies and beyond truly improve their security posture:
- Oneleet: 10 year+ experienced red teamers, now building an all-in-one pentest, vCISO, vSOC, and compliance platform and service
- 0Pass: FIDO2 keys as service (ex-SpaceX, Amazon Cognito security engineers)
- Infisical: open source secrets management
Same sort of questions - if the whole YC suite is secured by other YC security startups, that’s raises the same questions about where does the risk recursion stop - is anyone using yubikeys, vetted secrets management platforms, plainjane google auth, is there an internal SOC + SSO anywhere, and done by hires with actual blue team experience?
Sec teams don’t want to sign vendors to support innovation. We sign them to not get hacked, increase the odds that we’re not, and save money after. The less bread and butter deployments seen, the more skepticism is needed. Again, this model is actively exploited currently bc threat actors do this same logic.
- is technical enough to know what needs to get done and why
- has enough startup sec experience to know what pragmatic advice is in light of tight funding for startups
If you’re YC-backed this should be easy to source.
Why this thread matters and I’ll close it is dev-speak (“awesome, delightful, obsessed”) doesn’t matter at all for selling to a sec team, which is who is going to pay and vet this. That language just tells me it’s going to be a slog through VC sales-speak to answer the concerns I listed. It’s all about the above I mentioned, plus the tech setup which I think you have done with the right mindset (just plug into everything, parse it, ship it to the usual sources. Don’t try to reinvent Jira or Slack please).
The other reason you have to think about this is what market SOARs sell into. They aren’t needed until a lot of other due diligence is done - EDR deployments, enterprise sec, email sec, etc etc. So, that’s a decently established company, and if they’re paying for SOAR, it means they are either the lucky program with healthy budget support, or have a threat environment just justifying it all. A lot of places just get a bad MSSP and call it a day. So, if you are a company justifying SOAR (bc of implied budget and program maturity), you deal with threat actors who know their stuff well enough. And, as a fair number of exploits indicate this part 2-3 years, they know to evaluate SaaS vendors as the way in. Looking at the stack, they could try Okta, CrowdStike, MSFT, GSuite and all the difficulty there… or the two data engineers and their startup. Gotta take it seriously, a lot of sec is abstract risk but this is happening in the wild now.