### Release notes Automatic revocation of leaked GitLab personal access tokens currently applies only to the legacy token format as mentioned in this documentation (https://docs.gitlab.com/user/application_security/secret_detection/automatic_response/#supported-secret-types-and-actions). > ## **Supported secret types and actions** > > GitLab supports automatic response for the following types of secrets: > > | Secret type | Action taken | Supported on GitLab.com | Supported in GitLab Self-Managed | > |-------------|--------------|-------------------------|----------------------------------| > | **GitLab **[**personal access tokens**](https://docs.gitlab.com/user/profile/personal_access_tokens/) | **Immediately revoke token, send email to owner. ¹** | **✅** | **✅** | > | Amazon Web Services (AWS) [IAM access keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html) | Notify AWS. | ✅ | ⚙ | > | Google Cloud [service account keys](https://cloud.google.com/iam/docs/best-practices-for-managing-service-account-keys), [API keys](https://cloud.google.com/docs/authentication/api-keys), and [OAuth client secrets](https://support.google.com/cloud/answer/6158849#rotate-client-secret) | Notify Google Cloud. | ✅ | ⚙ | > | Postman [API keys](https://learning.postman.com/docs/developer/postman-api/authentication/) | Notify Postman. Postman [notifies the key owner](https://learning.postman.com/docs/administration/managing-your-team/secret-scanner/#protect-postman-api-keys-in-gitlab). | ✅ | ⚙ | > > **Footnotes**: > > 1. **Supported only for **[**`gitlab_personal_access_token`**](https://gitlab.com/gitlab-org/security-products/secret-detection/secret-detection-rules/-/blob/a9ea19d0d9e06f266a80975467b4b3a8360c04eb/rules/mit/gitlab/gitlab.toml#L2)**.** > > **Component legend**: > > * ✅ - Available by default > * ⚙ - Requires manual integration using a Token Revocation API Tokens issued by GitLab 18.3 and later use the routable and versioned routable formats, which the secret detection analyzer detects correctly but which the revocation step does not act on. Extending revocation to the `gitlab_personal_access_token_routable` and `gitlab_personal_access_token_routable_versioned` rules would make the feature work for tokens that current GitLab versions actually issue. ### Problem to solve An administrator on GitLab Self-Managed turns on automatic token revocation and leaks a personal access token into a public project. Secret detection finds it, the vulnerability appears in the report, and the token is not revoked. Nothing in the UI or logs explains why, and no configuration change makes it work. The cause is a rule ID mismatch. The revocation service matches a single identifier: ```ruby GLPAT_KEY_TYPE = 'gitleaks_rule_id_gitlab_personal_access_token' ``` Findings are keyed as `<external_type>_<external_id>`, so a token detected by the versioned routable rule produces `gitleaks_rule_id_gitlab_personal_access_token_routable_versioned`, which does not match. The finding then falls through to the external Token Revocation API branch and fails with `Missing revocation token data` when no such service is configured. Routable tokens are not optional. `PersonalAccessToken` declared `routable_token:` behind the `routable_pat` feature flag in 18.0 and unconditionally from 18.3, so every token minted by a current version has the format that revocation does not act on. Tokens created before that keep their original format and still revoke correctly, which means the gap is invisible on long-lived upgraded instances and total on new installs. The detection side already expects revocation to apply here. In the shipped ruleset (v0.25.1), both routable rules carry: ```toml [rules.postDetectionActions] autoRevocation = true validityCheck = true ``` ### Proposal Extend the revocation service to recognise all three GitLab personal access token rule IDs rather than one: - `gitleaks_rule_id_gitlab_personal_access_token` - `gitleaks_rule_id_gitlab_personal_access_token_routable` - `gitleaks_rule_id_gitlab_personal_access_token_routable_versioned` `Security::TokenRevocationService#execute` partitions GitLab tokens out of the revocable keys by equality against the single constant, then revokes them in process through `PersonalAccessTokens::RevokeService`. Matching against a set of identifiers instead would be enough; the revocation path itself already works, as the verification below shows. There is a direct precedent for the same gap in a sibling feature: gitlab-org/gitlab#561658, "versioned routable tokens are not supported by validity checks", accepted as `type::feature` and shipped in 18.6. `Security::SecretDetection::TokenLookupService` already maps all three identifiers, so the mapping exists in tree and only the revocation service lags. ### Verification Both cases below were run on the same clean 19.2.0 instance (Ultimate, real `Jobs/Secret-Detection.gitlab-ci.yml` template, analyzer v7.39.0, ruleset v0.25.1), in a public project, with `secret_detection_token_revocation_enabled` set to `true`. Only the token format differs. **Case 1: legacy format, revoked as expected.** Create a token with the legacy format in the Rails console: ```ruby user = User.find_by_username('root') pat = user.personal_access_tokens.create!(scopes: ['read_api'], name: 'my-legacy-token', expires_at: 7.days.from_now) raw = 'glpat-' + SecureRandom.alphanumeric(20) pat.set_token(raw) pat.save! puts raw ``` Confirm it authenticates: ```shell curl --silent --output /dev/null --write-out "%{http_code}\n" \ --header "PRIVATE-TOKEN: $TOKEN" --url "$GITLAB_URL/api/v4/user" ``` `200`. Then in a public project, add `.gitlab-ci.yml`: ```yaml include: - template: Jobs/Secret-Detection.gitlab-ci.yml ``` and a `leaked.txt` containing the token, committed so the secret is inside the pipeline's scanned commit range. After the pipeline completes, the token is listed as revoked under **Edit profile \> Access tokens**, and the same curl returns: ``` 401 ``` **Case 2: current format, not revoked.** Repeat with a token created normally on 19.2.0, for example `glpat-<32 chars>.01.<9 chars>`. Detection succeeds and the finding is ingested, but the identifier is the versioned routable rule and the token stays active: ``` identifiers: [{:name=>"Gitleaks rule ID gitlab_personal_access_token_routable_versioned", :external_id=>"gitlab_personal_access_token_routable_versioned", :external_type=>"gitleaks_rule_id"}] computed key = "gitleaks_rule_id_gitlab_personal_access_token_routable_versioned" GLPAT_KEY_TYPE = "gitleaks_rule_id_gitlab_personal_access_token" match? false ``` | Token format | Detected | Rule ID applied | Revoked | |--------------|----------|-----------------|---------| | Legacy (`glpat-` + 20 chars) | yes | `gitlab_personal_access_token` | yes | | Versioned routable (18.3+ default) | yes | `..._routable_versioned` | no | ### Workaround There is a working but unattractive workaround, verified on the same 19.2.0 instance. A project-level ruleset customisation can relabel the routable rule so that it carries the identifier the revocation service matches. `.gitlab/secret-detection-ruleset.toml`: ```toml [secrets] [[secrets.passthrough]] type = "raw" target = "gitleaks.toml" value = """ title = '''relabelled GitLab PAT rule''' [[rules]] id = '''gitlab_personal_access_token''' description = '''GitLab Personal Access Token (routable, relabelled)''' keywords = ['''glpat-'''] regex = '''\\bglpat-[0-9a-zA-Z_-]{27,300}\\.[0-9a-z]{2}\\.[0-9a-z]{2}[0-9a-z]{7}\\b''' """ ``` With that file committed alongside the standard `Jobs/Secret-Detection.gitlab-ci.yml` include, a leaked token in the versioned routable format produces: ``` external_type="gitleaks_rule_id" external_id="gitlab_personal_access_token" computed key = gitleaks_rule_id_gitlab_personal_access_token matches GLPAT_KEY_TYPE? true token revoked=true ``` This confirms two things: the identifier is derived from the rule `id` as written in the ruleset, and the revocation path itself works correctly for routable tokens once the identifier matches. Only the identifier comparison stands in the way. It is not a solution worth recommending, for four reasons: - A `raw` passthrough **replaces the default ruleset**, so every other secret type stops being detected unless the full upstream ruleset is reproduced alongside the relabelled rule. - It is per project. Each project needing revocation must carry the file. - Findings are reported under a rule identifier that does not describe what matched, which is misleading in the vulnerability report and in any downstream audit. - It depends on identifier derivation that is an implementation detail rather than a documented contract. ### Intended users - [Sidney (Systems Administrator)](https://handbook.gitlab.com/handbook/product/personas/#sidney-systems-administrator) - [Amy (Application Security Engineer)](https://handbook.gitlab.com/handbook/product/personas/#amy-application-security-engineer) - [Alex (Security Operations Engineer)](https://handbook.gitlab.com/handbook/product/personas/#alex-security-operations-engineer) ### Feature Usage Metrics The revocation service already emits internal events that would show this directly: `revoke_leaked_token_after_vulnerability_report_is_ingested` on success, and `leaked_token_unable_to_be_revoked_after_vulnerability_report_is_ingested` with a reason label on failure. A successful change should move volume from the second to the first for GitLab token types. ### Does this feature require an audit event? Worth considering separately. No audit event is currently recorded when secret detection revokes a token, so an administrator cannot tell from the audit trail that the security bot revoked a credential. That is out of scope here, but it came up while verifying this. ### Documentation [Supported secret types and actions](https://docs.gitlab.com/user/application_security/secret_detection/automatic_response/#supported-secret-types-and-actions) marks GitLab personal access tokens as available by default on GitLab Self-Managed, with footnote 1 reading "Supported only for `gitlab_personal_access_token`". The footnote is accurate about today's behaviour, but a reader cannot reasonably get from it to "this will not work for any token my instance issues". If the scope is intentional for now, the page would benefit from saying that the legacy format is the only one covered. Related: gitlab-org/gitlab#537281 added the versioned routable detection rule, and gitlab-org/gitlab#561658 extended validity checks to it. Related settings-API defect: gitlab-org/gitlab#621994.