GitGuardian helps developers, ops, security and compliance professionals to define and enforce policies consistently and globally across all their entire stack, be it their version control systems, their logs or their cloud systems and applications. Security is part of our DNA along with transparency. We're transparent with our security program so our users can be informed and feel safe using our products and services.

This security overview provides a high-level overview of the security practices put in place at GitGuardian.

Have questions or feedback? Feel free to reach out to us at [security@gitguardian.com]

Dedicated Security Team

We have a DevSecOps team dedicated to improving the security of our organization. Our employees are trained on security incident response and are on call 24/7.


Cloud infrastructure

All of our services run in the cloud. We don’t host or run our own servers, switches, routers, load balancers or DNS servers.

Our service is built on Amazon Web Services (AWS). They provide strong security measures to protect our infrastructure and are compliant with most certifications. You can read more about their practices here:

Data center security

Data center security is part of the services provided by AWS. They have been certified as ISO 27001, PCI/DSS Service Provider Level 1, and/or SOC II compliance.

AWS infrastructure services include back-up power, HVAC systems, and fire suppression equipment to help protect servers and ultimately your data.

Learn more about Data Center Controls at AWS.

Network level security monitoring and protection

Our network security architecture consists of multiple security zones. Each environment has its own VPC and each service is isolated on different subnets with strict control through security groups about allowed communication. By default:

all communication between services are denied
all communication from a subnet to another are denied

Security groups are regularly reviewed to ensure that only necessary communications are allowed (incoming and outgoing traffic, from inside or outside).
External access to the architecture:

Administrator access are made through SSH bastions which log access and executed commands
SSH connections are allowed through signed certificate
Certificates are issued after a connection to our IDP with 2FA steps
Access to our bastions are filtered with ACLs

DDoS protection

We use AWS Shield in front of our architecture to protect our service from Distributed Denial of Service (DDoS) attacks.

Data encryption

All data sent to or from our infrastructure is encrypted in transit via industry best-practices using Transport Layer Security (TLS). We use the most restrictive TLS policy available from AWS,  (ELBSecurityPolicy-FS-1-2-Res-2019-08, details available here, which enable only TLS 1.2.

All data sent inside our infrastructure is encrypted in transit via industry best-practices using Transport Layer Security (TLS) 1.2 only.

All our data (including user data, passwords, etc) is encrypted at rest using battled-proofed encryption algorithms.

Data retention and removal

We don’t retain your data after the end of the service. All data is then completely removed from the dashboard and server.

Every user can request the removal of usage data by contacting support.

Read more about our privacy settings.

Business continuity and disaster recovery

We back up all our critical assets and regularly attempt to restore the backup to guarantee a fast recovery in case of disaster. All our backups are encrypted.

Application security monitoring

We use technologies to monitor exceptions, logs and detect anomalies in our applications.

We collect and store logs to provide an audit trail of our applications activity.

We use a security monitoring solution to get visibility into our application security, identify attacks and respond quickly to a data breach.

Application security protection

We use a runtime protection system that identifies and blocks OWASP Top 10 and business logic attacks in real-time.

We use security headers to protect our users from attacks.

Secure development

We develop following security best practices and frameworks (OWASP Top 10, SANS Top 25).
We use the following best practices to ensure the highest level of security in our software:

Developers participate in regular security training to learn about common vulnerabilities and threats
We review our code for security vulnerabilities
We regularly update our dependencies and make sure none of them has known vulnerabilities
We use Static Application Security Testing (SAST) to detect basic security vulnerabilities in our codebase
We use Dynamic Application Security Testing (DAST) to scan our applications
We use Secrets Detection to scan our source code.

We rely on yearly third-party security experts to perform penetration tests of our applications.



We’re compliant to the General Data Protection Regulation (GDPR). The purpose of GDPR is to protect the private information of EU citizens and give them more control over their personal data. Contact us for more details on how we comply with GDPR.

Employee acess

Our strict internal procedure prevents any employee or administrator from gaining access to user data. Limited exceptions can be made for customer support.

All our employees sign a Non-Disclosure and Confidentiality Agreement when joining the company to protect our customers' sensitive information.