Skip to main content

Security recommendations and information

Common Vulnerabilities and Exposures

Chainguard stands as a leader in security technology, providing robust defenses against Common Vulnerabilities and Exposures (CVEs). In our commitment to heightened security, we utilize Chainguard-approved Base-OS images, which are specifically hardened, for constructing our GitGuardian self-hosted images. This strategic choice markedly diminishes the likelihood of security vulnerabilities that could affect our users.

At GitGuardian, we recognize the critical importance of robust security measures in protecting against Common Vulnerabilities and Exposures (CVEs). Our partnership with Chainguard, a leader in security technology, plays a pivotal role in this endeavor. By using Chainguard-approved, hardened Base-OS images for the construction of our GitGuardian self-hosted images, we significantly enhance our defense mechanisms against potential vulnerabilities.

Key Benefits:

  • Zero CVE Goal in Container Images: Our adoption of Chainguard-approved, hardened Base-OS images is a strategic effort towards achieving zero CVEs in our frontend and backend container images, thereby greatly strengthening their security against various vulnerabilities.
  • FIPS-Approved Cryptographic Modules: The integration with Chainguard incorporates Federal Information Processing Standards (FIPS) approved cryptographic modules into GitGuardian, ensuring top-tier encryption of sensitive data, both at rest and in transit.
  • Adherence to Compliance and Security Benchmarks: With this integration, GitGuardian aligns with the highest standards in compliance and security benchmarks, setting a new standard in the industry.

Runtime Image Configuration:

Our runtime image utilizes the Python FIPS image, enhanced with the following additional packages: src-fingerprint, libxml2, libxslt, xmlsec, xmlsec-openssl, and git.

KOTS admin and Replicated SDK utilize a distroless base image from Chainguard.

TLS certificate

To safeguard sensitive information, such as secrets and source code, the application mandates HTTPS access.

We advise using a valid certificate that corresponds with your chosen Fully Qualified Domain Name (FQDN), like dashboard.gitguardian.mycorp.local.

A TLS certificate is required to start the installation.

For configuring the TLS certificate, see the following section.

By default, we employ a robust cipher suite supporting only TLS 1.2 and TLS 1.3, ensuring compatibility with modern browsers. For any issues, please reach out to our support team.

Default protocols and ciphers include:

  • Protocols: TLS 1.2 / TLS 1.3
  • Ciphers:
    • ECDHE-RSA-AES128-GCM-SHA256
    • ECDHE-RSA-AES256-GCM-SHA384

Considerations for Self-Signed Certificates

Using a self-signed certificate requires additional SSL validation handling for GitLab or GitHub web hooks. SSL verification is enabled by default, and disabling it is necessary for integrating with GitLab or GitHub.

Encryption and Access Control

Considering the database will hold sensitive data (like source code and leaks), we strongly recommend encrypting the file system. Additionally, access to the host running the application should be limited to essential personnel (e.g., host and application deployment managers).

Signup restrictions

By default, joining the GitGuardian workspace requires a sign-up via SSO or an invitation link.

Disabling signup restrictions means anyone within the instance network can join your workspace and potentially access secrets. Should you opt to disable these restrictions, ensure your GitGuardian instance is only accessible within a restricted network, not from the Internet.

How can I help you ?