[_pdp_]

Unfortunately many companies charge extra for security where security should be the default. Truth to be told there some some situations where extra security costs could be justified but there are not many if charge is necessary it should be considered as a temporary measure. My $0.02.

[cduzz]

I'm not sure what you mean by "security" in this context.

Identity management, role based access control, useful audit logs; all "enterprise" features, probably are very expensive to implement, and make for obvious "up-charge" product segmentation.

I suspect there's some combination of "the community doesn't add useful implementations of these features" and "we can't possibly risk our reputation based on some community contribution" and "we can use this to segment our product to sell to some and give it away to some."

This set of features seems to always get put in the "enterprise, only for licensed / supported customers" and it stinks.... I can understand why, though, and none of these are strictly speaking "security" as much as "compliance"

[fieldcny]

Using your yardstick, we wouldn’t have any open source software, everything costs time to implement, that’s the point of open source, we donate time to the collective community. All those security features are not enterprise specific, they are rudimentary for any modern open source product

[cduzz]

I'm saying that companies that opensource their products tend to distinguish "enterprise" and non-enterprise based on things like RBAC and audit mechanisms, neither of which is "security" as much as "compliance".

The original license owner, if a commercial enterprise trying to sell the product alongside the "open" version, has less incentive to accept those features from the community as it would reduce their sales of the enterprise version of the same thing, and may not align with their long-term product roadmap.

In open source, the team managing a codebase isn't under any obligation to accept contributions the community and you are welcome to fork the project, if you like.

[ang_cire]

RBAC is absolutely a practical security control, even for non-commercial users. Least necessary privilege is not a checkbox, it will 100% save your butt in a breach by limiting blast radius.

[cduzz]

I'm not really sure what you're talking about.

Let's say you work at a company that uses Elasticsearch. Let's say you're running a newspaper and you've got your logs in elasticsearch. Let's say one of your reporters ends up getting chopped up while they're visiting the Ostrich embassy to get a marriage license. Now let's say you're then asked "who looked at the logs of the CMS who searched for and found the IP address that was used by that reporter on October 1st 2018"

That example, purely hypothetical, is an example of "security" but not the typical security you'll see in some open source application -- it's an enterprise "compliance" feature that won't be trivial to implement and will be judged not just on completeness but on user interface, ease of use, ease of implementation, etc.

"security" means different things to different people

[tstenner]

Sure. But for smaller users it's easier to breathe the accounts by hand rather than manage an entire active directory installation.

[paulddraper]

RBAC and Active Directory are different things.

[originalvichy]

I think it's fair to say most security is built-in by your average developer. However, the security side of things needs efforts from a far smaller pool of experts that can make your tool as secure as is possible. I don't imagine it is as cheap to find feature developers as well as security experts or security developers. Practically speaking, cheaping out on security might cost you the reputation of the app, so doing it well will be expensive but worth it, but might never be worth it if you offer everything by default but in the end only a fraction of your customer base uses the features.

[thelittleone]

Including the recent trend of access to SOC2 reports requiring an "Enterprise" tier subscription.

[eknkc]

We got a SOC2 cert in our bootstrapped small saas company. Then we hid the report behind Enterprise subscriptions because it takes too much time, effort and money to obtain and maintain it.

We did not get certified because we wanted it, we did because the enterprise scale customers forced us to. Due to their internal bureaucracy.

[julesvr]

I have the same problem at the moment with Supabase. We're a startup trying to get ISO 27001 certified and need to upload Supabase's SOC2 report to Vanta, but we can't because we're on the Pro tier and they don't give access to that, even after emailing them. It's ridiculous.

[_pdp_]

It is even more ridiculous because it costs them nothing to issue an extra copy of this pdf report. They need to certify anyway because their enterprise customers will demand it.

[christinac]

(I work at/started Vanta. Email [e-mail] and they should be able to give you guidance and help out. If that doesn't work, email me -- christina at vanta)

[YetAnotherNick]

In fact I like the change. This allows them to make almost everything free of charge to individual/small companies, but could fund it from revenue of larger organization, who generally don't have problem paying.

[ensignavenger]

I don't mind them requiring a paid tier to get the detailed compliance level reports, but requiring the most uber expensive "call us" plan is probably too much for many smaller companies that might still benefit from easier SOC2 complaince.

[lsaferite]

And what of small companies that need things like SOC2 reports from vendors?

If you want to work with large companies, being SOC certified makes it easier. Part of that is ensuring your vendors are also compliant with good standards and that's best done with SOC reports.

[YetAnotherNick]

Getting SOC 2 compliance alone takes ~10k USD apart from vendor reports. Yes they may be small with employee count, but when I said small I just meant someone running something for small set of users for free or close to free. Not someone working with other enterprises.

[lsaferite]

My point is that even small companies may need SOC reports from their vendors but still not be able to financially support enterprise level plans with every one of them. By being supportive of hiding those reports behind enterprise level contracts you are effectively supporting pricing those companies out and potentially making them unable to work with larger clients.

[YetAnotherNick]

SOC reports are only needed for SOC compliance and compliance costs 10k USD. It depends on the subscription cost, but if the company could afford the compliance they could afford extra 100 USD/month. No one expects small companies to pay few 1000 dollars per month.

Although few companies have minimum ticket size for enterprise clients and that is a bad thing IMO.

[FireBeyond]

Or worse, "SSO" as an Enterprise feature. You're a 2-3 person startup, you set up GSuite, you want to set things up right, oh, "$Call us" for a tier with SSO. Nope, I guess disparate users for now. Not the worst in the world to be clear, but an entirely arbitrary gate, in my experience.

[d0gsg0w00f]

Yeah, the SSO gates are common and borderline criminal. "The only way you can use our software is insecurely"

[thelittleone]

I have long held that view also, although the post below about the cost of supporting SSO was interesting. Unlike withholding SOC2 reports which cost nothing to incremental to give to your lowest tier, SSO may increase the cost of support. I wonder how it would go offering SSO as an addon to entry level tiers that covers the incremental support cost.

https://news.ycombinator.com/item?id=41304228

This SSO cost post is also interesting:

https://news.ycombinator.com/item?id=40752518