Open-source security #
At the core, we are an open-source company. All our fundamental and unique security technologies are open source, all cryptography is open source, often accompanied by the detailed scientific papers. Why so?
Security merits of open-source software are often conflicted by polar opinions and are subject to emotionally charged discussions.
We believe that despite troubled history and decades-long psyops by non-open-source vendors, in a segment we function, open-source-based products are not just possible but necessary.
Religiously open #
Open source is a work for public benefit that pushes the innovation forward, it can be made secure and responsible too.
It all starts with a mission.
We want to make the world a better place, safer and more responsible. Sharing what we know, making our products open source is the key to our way of work.
Open-core #
Our products are open-core, which means that all essential features are open-source. In our case, it means:
- All cryptography is open, especially “novel applied techniques”. Although we don’t bikeshed any particularly novel algorithms, we often use them in novel ways. We strive to describe these ways well and make visible in the code.
- All security-relevant code is open: from parsing user-generated inputs to configuring security controls and handling security-sensitive states.
- Core engine behind the products, so that the open-source community and security enthusiasts could benefit from our work.
We also document our work via whitepapers and engineering blog posts.
We maintain close-sourced software components too. They provide comfort, interoperability, compliance, and governance, because this is what larger customers need to properly benefit from our technologies.
But is it a sustainable business? #
It is, yet it enforces certain discipline on us as product creators.
There are plenty of companies willing to pay for the end result (good working solutions, support, consulting, convenient supporting tooling), as long as the end result is good and doesn’t try to justify its value through “we’re open”, “there’s a community behind us”, etc.
Licensing and custom security solutions allow us to keep Cossack Labs heading steadily into the future. Building security solutions with our products at the core gives us more real—world understanding than most security vendors have. We do not shy away from sharing it via pouring field knowledge back into open source.
Is open source a security risk? #
Open source or closed source is not a good predictor for product security at all.
There are indirect heuristics and arguments for and against open source that are subject to ongoing discussion. But if you are reading this section, asking yourself whether you should rely on our open-core products, this is how we think about it.
We don’t believe in cryptography that cannot be properly inspected. Neither should you. Examples are numerous. We neither believe that potential ability to inspect cryptography leads to its security. So we actively engage experts to review and aid us in improving our designs and implementations. We’re lucky to have some community attention, yet this is not a universally available thing.
Indeed, some open-source software is a disaster sitting in the open, and nobody is paying enough attention to it for various reasons. Sometimes, it takes 15 minutes to find disastrous bugs in software that sit everywhere for years.
Having reviewed a lot of software as security and cryptography auditors through the years, we never found any direct correlation between open/closed and number of bugs. But maybe it’s because we’ve reviewed good software, whose authors are willing to pay for a security audit in the first place?
The factor of “but code is visible!” #
There is one old argument that oversimplifies reality due to the fact that open-source code is available for anyone to inspect.
It could’ve been true 20 years ago, with simpler projects and products. But current open-source codebases are humongous, simple bugs are ironed out quickly, and many security vulnerability classes are comparably easy to find in closed-source software.
On the other hand, it takes huge initiatives from Google et al. to fund core open-source projects review (like OpenSSF) and improve security of open products—so there’s a very little low—hanging fruit.
Vulnerabilities like log4shell have shown that even despite closed-source-ness, there are high-risk open-source dependencies in every closed-source project anyway. So, by just guessing that you rely on Spring, OpenSSL or any of 200 most frequently used open-source projects, it’s still possible to try and attack.
Our approach to open source #
There is no silver bullet and the earlier you realize it, the earlier you build dynamic processes for maintaining security of your code. This is what we did:
- Our software is update-able and migrate-able by design. Not without challenges, because it’s cryptographic software.
- We run a proper SSDLC process around our software—and it pays off in having less bugs and less vulnerabilities.
- The open-source supply chain is risky, indeed. But only if you pick your dependencies blindly. Dependencies in our tooling are heavily vetted, validated, and reviewed, and we try to minimize them.
- We’ve built custom tools and sophisticated make & build pipelines to minimize some of the security risks and ensure quick turnover in case of a discovered security vulnerability.
We believe that open source is an effort for the greater shared good. It just has to be built and maintained in a secure way.
That’s what we do with our products: security issues and concerns have maximum priority vs everything else in our product roadmaps.