This seems to be an increasingly popular model: Make an open source project on the one hand and selling a hosted, managed version of the open source product on the other.
IMO the key to doing it right is ensuring that your hosted solution actually provides value: either because its difficult to operate at scale, there are certain regulatory/compliance requirements that need to be met, because certain features are restricted to a hosted product or under an enterprise license, etc.
I've seen a decent number of people create a hosted version of their product, slap SAML/SSO behind an "enterprise" plan, and wonder why nobody their successful OSS product doesn't translate to meaningful hosted revenue.
> Well, it makes sense, you can outsource bug fixing and reporting for free.
In the long term, maybe. In the short to medium term, most of the development ends up being done by the company who created the project.
I guess for simple stuff like typo bugs, people will submit PRs, and maybe organisations with weird use-cases will merge their integrations etc into the project, though.
Kubescape, an end-to-end open-source Kubernetes security platform, embarks on a new journey. Kubescape, created by ARMO, will fully migrate to the CNCF. This coincides with the launch of ARMO Platform, a hosted, managed security solution powered by Kubescape.
What's not too like. It's highly polished and comes with a very permissive license, which will be no issue since most companies prefer to pay for support and accountability.
The question you're asking is missing the important piece: how useful are they _to whom_.
To a developer, think of them as glorified linters (most of them are, including Kubescape, I believe). Someone on your team chooses which included things should be flagged (e.g. "require resource limits to be set on pods", see the list here: https://github.com/kubescape/regolibrary), and then the tool yells at you when you try to do something it doesn't like. It's then up to you to figure out how to comply with the tool's decisions. Some people really like them, some people really hate them.
To an engineering manager or SRE team, I think they're great at preventing common errors that would otherwise be enforced through code reviews or other processes; they're basically the remediation after an outage where a pod OOMed ("if we set sane resource limits and enforce them, this won't happen" --> enforce resource limits policy).
To your company's legal and compliance team, they usually fulfill a checkbox requirement along the way to $COMPLIANCE_FRAMEWORK. By the time your company is at sufficient scale, you'll have a number of these, and automation is the only way to keep everyone sane (developers and auditors alike).
In general, I think they're well intentioned, and can be useful, but aren't a panacea--they aren't going to catch anything you're not already looking for, they're just going to make it easier to remedy/enforce the problems you already know about.
We’re using Trivy but have also been evaluating Snyk and Grype. All these can do container image scan, but these are, in my opinion, nearly useless, as the vulnerability exists in the base image I don’t control. Apart from using a newer base image (maybe based on a newer version of Ubuntu/Debian/Alpine) there’s little to do.
Scanning for language-specific vulnerabilities in third party packages is useful, as that’s something we can control and the fix is usually to update some python or node package (but this is also something dependabot can also help with, albeit in a different manner).