Security at GuardRails
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 operating on the Amazon Web Services (AWS) platform. All data is stored encrypted at rest and continuously backed up securely.
The AWS data centers employ a set of advanced physical, network and software security measures to ensure integrity and safety of customers’ data. Additionally, GuardRails follows all applicable security best practices, such as:
- Secure access: Data transferred between GuardRails servers on AWS and GitHubs facilities is secured via SSL endpoints using the HTTPS protocol.
- Multi-factor authentication: Use of multi-factor authentication is enforced for all critical 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 30 minutes. After the scans have completed the source code repository is deleted immediately and securely.
GuardRails does not store any sensitive GitHub data. All user data across systems can be deleted 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 that are automatically renewed on a quarterly basis.
Wherever possible, GuardRails relies on managed services, which take care of 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 and are retained for 15 months.
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.