[dogman144]

You’re not measuring against Splunk, you should be measuring against Tines. And tines is def broader than fortune 10, they sell the heck out to startups, so I think you’ve got your market wrong. Expensive boogeyman Splunk is replaced by a lot of solid vendors now that aren’t $100k+.

This flow isn’t really accurate either “ A security engineer would use it to build alert automations that look like this…”

Also, you’re competing against the difficult rep of other open source sec tools, namely Elastisearch. It’s not used much for a reason.

**But my very very top of mind, and what you’ll get asked by any sec team worth its salt, is what is your own security program, team of 2 data engineers?

Literally, do you have anyone hired to do it? Who? Why should I ship you any of my data, let you tag it, and plug into my sec platforms, when I assume it’s basically nonexistent. Your environment becomes my env if I do, and we all know startup security posture bc we’ve worked on that side of the coin in the past. So don’t sell us nonsense around what audits you’ve passed. Open Source adds an interesting margin of safety here, but you’re a YC company with plans to make revenue, so the exposure is there somewhere.

SaaS vendors are a massive supply chain vector right into a company, happens all the time and is growing, and the teams trying to sell me security tools with a 0.0% security program themselves are humorously many.

[dogman144]

Just to drive the point home as I parsed through the details and looks like yall know the tech side well.

Roadmap - you’re asking to plug into every mission critical sec tool. Nowhere on your roadmap is sec program details, who is doing it now, when will you get some from of pentest/audit (so so even then) or hire someone, or what yall know about security yourselves vs Facebook data eng.

Tech descriptions - nowhere in it are you describing how youve done your appsec, or more accurately who has done it. Why should I give you api keys to crowdstrike and defender in that light. And you’re offering a cloud version already, depsite hitting on 0 of this.

I think a big jump devs have trouble making when looking at security is this specific area. Sure, you’re saving me money and building slick tech. But Splunk isn’t going to get me hacked and roast my Saturday night. You (or more fairly vendors in the same profile as you) will. None of the data eng finesse and $50k in cost savings is worth that risk, or rather I price that risk at $50k haha. If the founders aren’t in the right headspace about their own security, I stay away - and you haven’t mentioned it once.

Obviously im a little crusty from SaaS vendors burning firms over and over this way. But that’s the candid feedback.

Deeper dive - The extent you discuss prodsec of your own sec tool is a token security.md file with nothing of value in it. If you are “practitioner obsessed” as mentioned in there too, then SaaS vendors owning the company and how/if/when id find out is a big part of what we obsess about. Look up the Jumpcloud hack for an example of this.

[neochris]

We're going to work with these guys: https://www.oneleet.com/. They are awesome.

[dogman144]

I see that and I see a bad security posture, and the responsibility passed up chain and even harder to answer the same questions about oneleet. Will they secure your gsuite email I assume you’re using? Will they respond to phishing attacks at you? Will they prevent SMS 2FA? Will they get you into SSO? Is a password manager in place? Are y’all using personal laptops still? Segregated logins? Will they tell you not to share publicly as a VC-backed startup about who is doing your infrasec and by a pretty clear implication what your infra likely looks like?

How to not turn you into me hacked is a balance of the prod/infrasec (like the company you linked), and bread and butter enterprise sec, which only comes from in house. So, in house team, or at least a 1x hire, such that there is at least a more than vague indicator that someone in house there day to day knows how to do security, or it doesn’t matter from a vendor risk point of views.

The list of vendors that have passed audits with complaint environments and gotten hacked is very long.

[dogman144]

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.

[neochris]

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

[dogman144]

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.

[neochris]

Appreciate the Tines comparison.