This page provides an overview of the security measures taken by GuardRails to protect source code, vulnerability data and user data hosted on our platform from unauthorized access. Where relevant, we include links to security guidelines and resources developed by third parties.
GuardRails is using GoogleCloud to provide its services. All data is stored encrypted at rest and continuously backed up to an offsite backup storage.
Google's data centers employ a set of advanced physical, network and software security measures to ensure integrity and safety of customers’ data. Among others, these measures include:
- Secure access: Data transferred between GuardRails servers and GitHubs facilities is secured via SSL endpoints using the HTTPS protocol.
- Multi-factor authentication: Use of multi-factor authentication is enforced for all services used by GuardRails thus reducing the risk of unauthorized access.
Source code under test is only stored for the duration of the security scans, which is a maximum of 10 minutes. After the scans have completed the source code repository is deleted immediately.
GuardRails does not store any sensitive GitHub data. All user data across systems can be deleted within 30 days upon request.
GuardRails uses a secure channel using 256-bit SSL (Secure Socket Layers) encryption, the standard for secure Internet connections for all the traffic between desktop clients, mobile devices and our servers as well. All SSL termination points are hardened to provide highest levels of security.
GuardRails uses Let's Encrypt certificates to ensure secure and short lived certificates.
GuardRails relies on GoogleCloud Kubernetes Engine (GKE), which manages all updates and security fixes automatically and in the most timely fashion possible. GuardRails has an internal Vulnerability Management Policy to ensure all un-managed systems are kept up-to-date and free of known vulnerabilities.
GuardRails uses GuardRails to continuously check for security issues in code, known vulnerabilities in dependencies and hard-coded secrets. It's our policy to fix all issues in a PR, before the changes can be merged. For critical repositories, a peer-review workflow is required to merge changes.
Incident Response Plan
GuardRails has an internal Data Breach Response Policy and an Incident Response Plan to ensure timely action in the unlikely event of a breach.
Logging and Monitoring
Both application logs and production system logs are sent in real time to a centralized logging infrastructure. These logs are not directly accessible outside our organization. Logs do not contain sensitive data, or passwords.
We encourage responsible reporting of security vulnerabilities and software bugs. In the case that you found a vulnerability, please report it to email@example.com and abstain from publicly announcing it before it is fixed. Please note that we discourage attempts to gain illegitimate access to another user's account or data, compromise the reliability and/or integrity of our services, and use of automated tools to find vulnerabilities.
Our community plays an important role in helping us stay bug-free and secure.