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.

Cosign for image signing

Starting with the 2024.3.0 release, GitGuardian has enhanced the security of our images through the implementation of Cosign for image signing, aligning with SLSA 2 standards. This ensures all images are secure from their creation to deployment. You can also verify the provenance validation process for the Replicated SDK.

info

You can enhance your Kubernetes security by using the Sigstore Policy Controller. For more details, please visit the Sigstore Policy Controller documentation.

Before You Start: Download Cosign for image verification: Download Cosign

Verification Steps:

1. Save the provided public key into a file named gg_cosign.pub.

echo "-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEnVzZQr8D9OgkgZcf9z0v67yrd2pg
+yQtJur1OgetAwij8T8g8VH+IegI6Y+1E3ZEqMast934R35UCzOiiyIadQ==
-----END PUBLIC KEY-----" > gg_cosign.pub

2. Retrieve your License ID from your license file, where it's labeled as licenseID. Use this ID to authenticate with the GitGuardian image repository by executing the command below. Replace <your_licenseID> with your actual License ID.

LICENSE_ID="<your_licenseID>";
echo "{\"auths\": {\"proxy.replicated.com\": {\"auth\": \"$(echo -n "${LICENSE_ID}:${LICENSE_ID}" | base64)\"}, \"registry.replicated.com\": {\"auth\": \"$(echo -n "${LICENSE_ID}:${LICENSE_ID}" | base64)\"}}}" > ~/.docker/config.json

3. Execute the following command, replacing <IMAGE>:<TAG> with the image's name and tag.

cosign verify --key gg_cosign.pub <IMAGE>:<TAG>

This command verifies the image against the signatures stored with it, using the provided public key.

Below is a list of images you can verify:

Image Type	Repository and image name
Front	proxy.replicated.com/proxy/gitguardian/513715405986.dkr.ecr.us-west-2.amazonaws.com/prm/static-chainguard
Backend	proxy.replicated.com/proxy/gitguardian/513715405986.dkr.ecr.us-west-2.amazonaws.com/prm/app-chainguard
Helm Tooling	proxy.replicated.com/proxy/gitguardian/513715405986.dkr.ecr.us-west-2.amazonaws.com/prm/helm-tooling
Used for custom CA	proxy.replicated.com/proxy/gitguardian/513715405986.dkr.ecr.us-west-2.amazonaws.com/services/nginx-unprivileged

Example:

cosign verify --key gg_cosign.pub proxy.replicated.com/proxy/gitguardian/513715405986.dkr.ecr.us-west-2.amazonaws.com/prm/app-chainguard:2024.11.0 | jq .

Verification for proxy.replicated.com/proxy/gitguardian/513715405986.dkr.ecr.us-west-2.amazonaws.com/prm/app-chainguard:2024.11.0 --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The signatures were verified against the specified public key

Expected output:

[
  {
    "critical": {
      "identity": {
        "docker-reference": "513715405986.dkr.ecr.us-west-2.amazonaws.com/prm/app-chainguard"
      },
      "image": {
        "docker-manifest-digest": "sha256:b842813ffb597a67c..."
      },
      "type": "cosign container image signature"
    },
    "optional": {
      "Bundle": {
        "SignedEntryTimestamp": "",
        "Payload": {
          "body": "",
          "integratedTime": 1709632488,
          "logIndex": 75773529,
          "logID": "c0d23d6ad406..."
        }
      }
    }
  }
]

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 contact support@gitguardian.com.

The default protocols and ciphers, compliant with both modern browsers and FIPS requirements, include:

• Protocols: TLS 1.2 / TLS 1.3
• Ciphers:
  • TLS 1.3:
    • TLS_AES_256_GCM_SHA384
  • TLS 1.2:
    • ECDHE-ECDSA-AES256-GCM-SHA384
    • 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.