**Summary: Customers will be able to automatically verify the validity status of partner tokens detected in their codebase.** ## Proposal Validity Checks will expand to support partner platform tokens through direct API integration. The initial partners we will support are: - Amazon Web Services (AWS) IAM access keys (using STS GetCallerIdentity) - Google Cloud Platform (GCP) OAuth tokens (using OAuth2 tokeninfo) - Postman API tokens (using /me endpoint) _Additional partners can be added post-GA by implementing new client classes following the established pattern._ In addition to the aforementioned partners, we will be adding filtering by token status, see https://gitlab.com/groups/gitlab-org/-/epics/17407. Users will have the ability to filter by token status on the Vulnerability Report; [designs](https://gitlab.com/gitlab-org/gitlab/-/issues/479341/designs/Validity_check_filter.png). _Note: as of August 1st, 2025, this will only be available for .com._ ## Pattern Integration Technical Design ### Overview We're implementing direct partner API calls from the GitLab monolith using Sidekiq workers with explicit rate limiting. ### UX Flow 1. MR has been reviewed and merged 2. Secret detection job executes on the default branch 3. Detected secrets appear in Security Dashboard with "Checking..." status 4. Status updates to "Active", "Inactive", or "Unknown" after verification 5. Security team can filter/sort findings by token status ### Internal Flow 1. Secret Detection Analyzer runs and generates `gl-secret-detection-report.json` 2. Report ingestion triggers `UpdateTokenStatusWorker` 3. Worker delegates to `UpdateTokenStatusService` for token processing 4. Service identifies token type from finding metadata 5. For GitLab tokens: Uses existing `TokenLookupService` 6. For partner tokens: Queues `PartnerTokenVerificationWorker` 7. Worker checks `ApplicationRateLimiter` for rate limit compliance 8. If under limit: Makes direct API call to partner 9. If rate limited: Reschedules with `perform_in` (no exception) 10. Processes response and saves `FindingTokenStatus` to database ```mermaid sequenceDiagram box "Runner" participant SDA as Secret Detection Analyzer end box "GitLab Monolith" participant RW as Report Ingestion participant UTSW as UpdateTokenStatusWorker participant UTSS as UpdateTokenStatusService participant TLS as TokenLookupService participant PVW as PartnerTokenVerificationWorker participant RL as ApplicationRateLimiter participant PC as Partner Client participant DB as Database end box "External APIs" participant AWS as AWS STS API participant GCP as GCP OAuth2 API participant PM as Postman API end SDA->>RW: Submit gl-secret-detection-report.json RW->>UTSW: Trigger token status check UTSW->>UTSS: Process findings alt GitLab Token UTSS->>TLS: Query GitLab token TLS-->>UTSS: Return status UTSS->>DB: Save FindingTokenStatus else Partner Token UTSS->>PVW: Queue verification (finding_id, token_type) PVW->>RL: Check rate limit alt Rate Limited RL-->>PVW: Throttled PVW->>PVW: perform_in(delay) else Under Limit RL-->>PVW: Proceed PVW->>PC: Create client for token_type alt AWS Token PC->>AWS: POST /GetCallerIdentity AWS-->>PC: XML response else GCP Token PC->>GCP: GET /tokeninfo?access_token= GCP-->>PC: JSON response else Postman Token PC->>PM: GET /me (X-API-Key header) PM-->>PC: JSON response end PC-->>PVW: TokenStatus(valid, metadata) PVW->>DB: Save FindingTokenStatus end end ``` --- # Interlock Details ##### Executive Summary Customers will be able to automatically verify the validity status of partner tokens detected in their codebase through direct API integration with AWS, GCP, and Postman. #### Dependencies - Team dependencies: \~"group::application security" (review only) - Infrastructure: None (uses existing Redis/Sidekiq) - External: Partner API availability #### DRIs - **PM**: @abellucci - **EM**: @amarpatel - **ENGINEER**: @atiwari71 - **UX/PDM**: @beckalippert - **Group(s)**: ~"group::secret detection" - **Engineering Owner**: @twoodham