Learn more about how we're protecting your data
We understand that ingesting your software development data is a big responsibility. This page outlines some of the steps we are taking to keep your data secure.
We request a permission to access source code, but we never store it. For each commit, we store the size of the change per file. This allows us to estimate the complexity of the change, and also to ignore changes to automatically generated files (such as package-lock.json or Gemfile.lock).
In case you want to delete your data from our service permanently, you can request it through customer support.
Principle of least privilege
We apply principle of least privilege in all areas: asking only for permissions we absolutely need, giving employees access to systems they need for doing their job, and restricting service accounts of our microservices.
All code is stored in version control (GitHub). All code changes are reviewed by another developer before merging to the master branch. Our CI/CD pipeline handles deployments to production automatically after each change.
Security issues are treated with the highest priority.
We use modern libraries for GraphQL APIs, database access, and user interfaces, minimizing most common web application security issues.
We use the most common security-related HTTP headers in our application.
Our CI/CD pipeline includes static analysis tools for finding security issues early.
We're automatically following updates to library dependencies, and even non-critical updates are generally applied weekly, after being reviewed by developers.
All production infrastructure is configured as code, meaning that it also goes through the same review process as the rest of the software. We use mainly Google Cloud services for our production infrastructure.
Most of our code runs in a Kubernetes cluster that's been hardened according to best practices. Each microservice has its own service account with restricted permissions, and containers are run with unprivileged user accounts.
Our servers don't have public-facing IP addresses, and they're only reachable through the load balancer. All egress traffic goes through a set of known IP addresses using NAT.
We maintain an audit log of important activity in the production environment.
We do not commit secrets to repositories without encryption.
We audit our security practices and our application every year in December and in June based on OWASP ASVS 4.0. The results of the latest audit are available on request.
Security has been our focus since the very beginning, and we did our first security review only one month after starting the development.
Employees are trained to treat customer data with care. This includes:
Encrypting disks on their laptops
Using a password manager and a different strong password for each service
Using two-factor authentication for all work-related services
Not storing customer data on their own computers
Identifying typical security risks, such as phishing attacks
Employee onboarding and offboarding follows a checklist.
Security competency is a part of the hiring process for software engineers.
Informing customers about security incidents
We inform customers about security incidents in accordance with GDPR.