We understand that security is critical when working with software development data. Hundreds of development teams trust us with their data, and we take our responsibility very seriously.
System and organization control (SOC) 2 is an audit designed to ensure that service providers have the internal controls in place to securely manage data and protect the interests and privacy of their customers.
An independent auditor has confirmed that we adhere to the highest industry standards when it comes to data security and privacy.
If you're a Swarmia customer and want to learn more, you can reach out to your Customer Success Manager to get access to the full report. If you’re only just beginning to evaluate whether Swarmia might be the right solution for you, you can email us at email@example.com to request your copy.
In order to provide our service, we access metadata about your organization's activities in GitHub and Jira/Linear. This includes Pull Requests, Git commits, automated test runs and issues.
We request permission to access source code but 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).
Our stored data is physically located in Frankfurt, Germany. Some data (mainly names and emails) are shared with our subprocessors in accordance with GDPR, and they have data centers in the US.
In case you want to delete your data from our service permanently, you can request it through customer support.
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 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 do not commit secrets to repositories without encryption.
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 of our production systems have logs and monitoring. We pay attention to both daily, and on top of this we generate automatic alerts from anomalies. We use an incident response system to respond to alerts.
We have a documented business continuity and disaster recovery plan, which we review and test annually.
We know how to recover our production environment in the unlikely event of a production disaster, and there are detailed instructions for doing this.
This includes keeping backups of our production data, and monitoring the backup process. We also regularly test restoring production data from backups.
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.
We use a systematic approach to software development where changes to customer impacting services are reviewed, tested, approved, and well communicated.
We develop features in a development environment segregated from the production environment. We do not use customer data in test and development environments.
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.
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:
Employee onboarding and offboarding follows a checklist.
Security competency is a part of the hiring process for software engineers.
We inform customers about security incidents in accordance with the GDPR.