After a secret is detected, GitLab supports "post-processing" hooks that can respond to the leak. GitLab.com integrates with cloud providers to automatically send them leaked credentials. This way, they can automatically mitigate risk or make proactive contact with the owner of the credential to protect their account. Starting in GitLab 15.9, GitLab also uses this type of post-processing to automatically revoke leaked Personal Access Tokens (https://gitlab.com/gitlab-org/gitlab/-/issues/371658). ## Want to protect your users? Third party cloud and SaaS providers can post in this epic or contact the Product Manager for Secret Detection, @abellucci (email: `abellucci@gitlab.com`). We'll work with you to protect your users if they leak credentials on GitLab. This epic includes individual implementation epics or issues (confidential if necessary) for each potential partner. Vendor support requires two parts: 1. Adding or updating support in GitLab Secret Detection for vendor-provided credential patterns. 2. Connecting to the vendor/partner notification API. ## Implementation details <details> <summary>Click to expand diagram</summary> ```mermaid sequenceDiagram autonumber Rails->>+Sidekiq: gl-secret-detection-report.json %% The recovable key list should be fetched and cached from RevocationAPI Sidekiq-->+Sidekiq: BuildFinishedWorker Sidekiq-->+RevocationAPI: GET fetch/cache revocable keys types RevocationAPI-->>-Sidekiq: OK Sidekiq->>+RevocationAPI: POST revoke revocable keys RevocationAPI-->>-Sidekiq: ACCEPTED RevocationAPI-->>+Cloud Vendor: revoke revocable keys Cloud Vendor->>+RevocationAPI: ACCEPTED ``` </details> ## Priorities for new integrations 1. https://gitlab.com/gitlab-org/gitlab/-/issues/403825+ 2. https://gitlab.com/groups/gitlab-org/-/epics/8236+ 3. https://gitlab.com/groups/gitlab-org/-/epics/9140+ 4. https://gitlab.com/groups/gitlab-org/-/epics/8237+