wif.tax

GitGuardian

D GitGuardian Platform (API, ggshield)

The secrets-detection company authenticates your CI jobs with a static API key you store as a CI secret; service accounts can be set to never expire, and GitGuardian is not a GitHub secret-scanning partner for its own keys. Outbound it is ahead of its inbound: it is an OIDC issuer for AWS, GCP and Entra, but GitLab, Bitbucket, Azure Repos and most registries still want a pasted token.

Docs: docs.gitguardian.com · Checked 2026-10-13 · source YAML · dispute via PR

Inbound D

How a workload running anywhere authenticates to this product.

Static API keys only: a service account token (Business plan) or a personal access token, sent as "Authorization: Token <key>"; no workload federation is accepted.

The public OpenAPI spec defines a single security scheme (the static "Token" key). The OAuth2 endpoints it documents (/v1/oauth/token, dynamic client registration) are an authorization-code + PKCE flow for interactive MCP clients that mints a personal access token, which can itself be non-expiring; there is no client-credentials or token-exchange grant. /v1/auth/jwt mints a short-lived JWT only for HasMySecretLeaked and requires an API key to call. ggshield in CI (GitHub Actions, GitLab, Jenkins, etc.) is documented only with GITGUARDIAN_API_KEY stored as a CI secret, despite GitHub and GitLab both issuing OIDC tokens to the same jobs. The deployable ggscout collector (NHI inventory, secrets-manager sync) also authenticates back with a static GitGuardian API token ("GitGuardian API token with NHI permissions"). Free-plan users get personal access tokens only; service accounts are Business-plan.

Outbound B

How this product reaches into your cloud, repos, or other SaaS.

GitGuardian acts as its own OIDC issuer for AWS (IAM role via AssumeRoleWithWebIdentity), GCP (Workload Identity Federation) and Entra (federated credential), plus External ID roles for ECR and vendor-app installs for GitHub, Slack, Teams, Jira and Confluence Cloud; GitLab, Bitbucket, Azure Repos, Docker Hub, ACR, JFrog and ServiceNow still want a customer-created token or password.

Checked: GitHub (vendor GitHub App, keyless); GitHub Enterprise Server (customer-created GitHub App, so the customer holds the app's private key); GitLab (personal access token with api scope, bot user recommended); Bitbucket Cloud (Atlassian API token with listed scopes); Bitbucket Server and Azure Repos (personal access tokens); Slack, Microsoft Teams, SharePoint/OneDrive, Jira Cloud and Confluence Cloud (vendor app install / admin consent, keyless); ServiceNow (a generated password for a GitGuardian user); AWS S3 and AWS IAM NHI (GitGuardian OIDC issuer + AssumeRoleWithWebIdentity, keyless); Amazon ECR (IAM role with External ID, keyless); Google Artifact Registry (WIF keyless, recommended, or an optional service-account JSON key); Entra NHI (federated credential, keyless); Azure Container Registry (ACR repository token), Docker Hub (PAT), JFrog (access token) - static. Grade is B: keyless into every cloud it reaches, static tokens for several SaaS/VCS sources. No Okta or Google Workspace source connector is documented. Secrets-manager integrations (Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, CyberArk, Delinea, Akeyless) run through ggscout, a collector the customer deploys in their own environment with its own local credentials (Vault token or Kubernetes auth; AWS default credential chain), so they are not GitGuardian holding a secret. Notably, GitGuardian publishes an OIDC issuer and JWKS (/v1/auth/jwks) for others to trust, but does not accept OIDC tokens on its own API.

Hygiene for any static credential the product still issues

✗ Expiry enforceable
Expiry is optional and "never" is offered for both token types. A Business-plan workspace policy can cap personal access token lifetime, but the documented policy covers PATs only; nothing documents a way to force expiry on service account tokens, which GitGuardian recommends for CI. Failed on the machine credential. (The public API's create endpoint does require a lifetime of at least one day, but the dashboard still offers "never".) A reader who credits the PAT policy would pass this; it does not change the grade.
  • docs.gitguardian.com checked 2026-10-13
    “Set an expiry date for your token (in 1 week, 1 month, 3 months, 6 months, 1 year, or never).”
  • docs.gitguardian.com checked 2026-10-13
    “Managers can enforce a maximum lifetime for API personal access tokens created within their workspace.”
  • docs.gitguardian.com checked 2026-10-13
    “By default, there is no enforced maximum lifetime for API personal access tokens.”
✓ Rotation via API
POST /v1/api_tokens creates tokens (same type as the caller, scopes a subset of the caller's) and DELETE /v1/api_tokens/{token_id} revokes them. A service account token cannot revoke itself.
  • api.gitguardian.com checked 2026-10-13
    “Create a new personal access token or service account token in the workspace.”
  • docs.gitguardian.com checked 2026-10-13
    “A service account token can be revoked from the Service accounts page by a workspace Manager, or through the Public API by another token holding the api_tokens:write scope.”
✓ Scoped keys
Service accounts are a non-human principal with per-token scopes (e.g. scan only). PATs are further limited to what the owning user can see in the UI.
  • docs.gitguardian.com checked 2026-10-13
    “Scopes are tied to an API key and control the access to resources and scan capability.”
  • docs.gitguardian.com checked 2026-10-13
    “Choose one or several scopes for your service account.”
✓ Last-used visible
The API token list exposes last_used_at and can be ordered by it.
✗ Leak revocation
GitGuardian does not appear anywhere in GitHub's supported patterns list (partner or user pattern), so a GitGuardian API key pushed to a public GitHub repo is not reported to GitGuardian for revocation by GitHub. The vendor's own docs carry a plea instead: "(Please do not push GitGuardian's API keys to public GitHub repositories ^^)". GitGuardian runs its own public GitHub monitoring, but no public doc says it auto-revokes its own leaked keys.
  • docs.github.com checked 2026-10-13
    “Partner alerts: Reported directly to secret providers that are part of secret scanning's partner program.”

Notes

Grades the GitGuardian SaaS platform API and ggshield (the CLI that wraps it). Docs and the OpenAPI spec are fully public; nothing was gated. Self-hosted GitGuardian follows the same token model. The HasMySecretLeaked service uses short-lived JWTs minted from an API key, which does not change the grade. The grade moves to B or A the day ggshield can exchange a GitHub Actions or GitLab CI OIDC token for a GitGuardian session, which the company already has the issuer plumbing to understand.

Badge

wif.tax grade D

[![wif.tax grade](https://wif.tax/badge/gitguardian-platform.svg)](https://wif.tax/p/gitguardian-platform/)