This week one of our competitors announced that there was a critical security vulnerability identified earlier this year that allowed for remote code execution in their system. If harnessed by bad agents, this could be used to do nefarious things, specifically, to expose customers’ code.
No one is ever fully protected from security vulnerabilities. However, we find it important to share with our customers how we’re different and how we thought of this years ago.
The problem
The issue resides on how code analysis tools, like Rubocop, use extensions. The extensions can be arbitrary code that when run can execute, well, whatever you want.
So in this particular case, since Rubocop used Ruby extensions, a security firm injected code through an extension that allowed them to see all environment variables containing passwords, tokens, etc required to access the database, Github tokens which allows the App to access customers code, etc. Extremely sensitive stuff.
How we're different
We spent years designing our solution. We understand that tool execution is a very sensitive environment. Our system is composed of more than 50 tools. As such we thought carefully on how to create an environment where we could feed these tools our most sensitive critical part of our company: our customers’ code.
As such, this is how our system is designed:
We have a Kubernetes cluster. We launch new pods for each new analysis we want to run, each for a specific tool and a commit of our customers’ code. An attacker can’t get information out of a pod (in a trivial way) because:
- It doesn't have access to the internet.
- It doesn't have any sensitive information as environment variables.
- It doesn't have access to other pods in the cluster.
Further, our security policies are role-based. And tool pods do not have a role with DB access.
We’ve isolated the execution of the tools in sandbox environments. Obviously, extensions can be unsafe and can make the tools behave badly. But we are confident that we contained the problem because of our design decisions years ago.
We took no shortcuts here. It took us a long time to build a safe system that is both secure and scalable.
But nothing is perfectly secure
We don’t want to tempt the gods here. No system is perfect. We’re open to any firm that wants to help us get better. Our biggest priority is the safety of the IP of our customers.
However, we do feel confident that the design decisions and time to develop a secure platform now can benefit from trust from our customers and partners.
If you do have any inquiries or questions, let us know.
.svg)
