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.
Although few companies have minimum ticket size for enterprise clients and that is a bad thing IMO.
We did not get certified because we wanted it, we did because the enterprise scale customers forced us to. Due to their internal bureaucracy.
https://news.ycombinator.com/item?id=41304228
This SSO cost post is also interesting:
Not just in software but in general?
I think this is a hold over from toxic masculinity era when men were expected to get into fist fights at the sight of a womans tears.
This line of thinking has lead to many foreign wars of choice, where we send young men to die and our nation recieved nothing in exchange. "It was the right thing to do" is uttered by those who did nothing.
Safety/Security isn't free, if you can't provide for it yourself you need to pay tribute to those who can.
> This line of thinking has lead to many foreign wars of choice, where we send young men to die and our nation recieved nothing in exchange. "It was the right thing to do" is uttered by those who did nothing
I am not able to find any references to the war of regression or the battle of cve-2021-44228, so I'll have to call nonsense on this one.
What was paid that now this is owed?
Demand your money back.
Side note: Security in these discussions is often something more like "It works with my single sign on system" or "It lets me check this box on my audit form". Security doesn't only have to happen at the app layer and it's completely doable to isolate any software in a way that is is secure despite itself. So it's less security and more convenient security that is being demanded for free most often by people who offer nothing for free themselves. The entitlement is really extreme.
Agreed and once an application has differentiation between a “super user” and users of fewer privileges, it needs an application security model. Additionally once there are differences in which data a user may access, it needs a data security model.
We’re all on the same internet, people getting taken over and used as ddos nodes, leveraged for further attacks, or leaking PII is a pain for everybody.
Skimping on security is always easier, and security is hard to detect for the end user. We shouldn’t have a race to the bottom on this stuff.
For volunteer projects, like a lot of open source, we can’t really make demands. But I think it is still unethical to release an open source project that invites itself to used in an insecure manner. It is like an “attractive nuisance” (typical example: In some jurisdictions, you might be responsible for an un-fenced pool on your property if a kid falls in it, even if getting to it required trespassing, because we don’t want a society where uninformed people die avoidably). Without a customer service relationship, open source developers don’t have an obligation to make something useful, but nobody should put harmful things out into the world.
People don't want to get hurt, physically, emotionally, financially.
> Not just in software but in general?
People being harmed is very expensive.
> you need to pay tribute to those who can
This is a very primordial view of things. Security and safety are literally the underpinning of modern, western society. The cost of that security is baked into prices for services and products, taxes and law.
People don't want to be hungry, people don't want to be cold, people don't want to be bored.
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"
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.
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