GitHub’s secret scanning service now recognises five additional credential patterns – lovable_api_key from Lovable Labs, logfire_token and pydantic_ai_gateway_api_key from Pydantic Services Inc., and supabase_oauth_access_token plus supabase_scoped_personal_access_token from Supabase – and a new provider has joined the secret‑scanning partnership program. Practitioners who rely on automated detection of exposed secrets gain broader coverage and an automatic hand‑off to the issuing service for revocation or rotation when a secret appears in a public repository.
New detectors and partner integration
The expanded detector list is a direct addition to the existing secret‑scanning engine. When a matching pattern is found, GitHub raises an alert in the same way it does for previously supported types. For public repositories, the alert is also forwarded to the corresponding provider, which can then invalidate the credential without requiring the repository owner to intervene. This partnership mirrors the existing model for other providers, but the source only confirms the addition of the new partner and the five secret types.
Operational impact for CI/CD and repository hygiene
Teams that already enable secret scanning will see alerts for the new patterns without any configuration change. However, the broader detection surface means a higher likelihood of false positives or legitimate alerts that need triage. Practitioners should verify that their CI/CD pipelines are set to fail builds on new secret‑scanning alerts if that aligns with their risk posture. Private repositories continue to generate alerts, but they are not automatically reported to the provider; the responsibility for remediation stays with the repository owner.
Security workflow adjustments
Because the partnership now includes Lovable Labs, Pydantic Services Inc., and Supabase, security teams should update their incident‑response playbooks to incorporate the provider‑initiated revocation step. When an alert arrives, the team can confirm that the provider has been notified and that the credential has been rotated or revoked. If the provider does not automatically act, the alert still provides a clear indicator that a secret has been exposed and must be rotated manually.
Related CloudNinjas coverage: security.
What This Means For Practitioners
- Confirm that secret scanning is enabled across all public and private repositories.
- Monitor the alert feed for the newly added
lovable_api_key,logfire_token,pydantic_ai_gateway_api_key,supabase_oauth_access_token, andsupabase_scoped_personal_access_tokenpatterns. - Update CI/CD policies to treat new alerts as build‑breakers if your security baseline requires it.
- Document the automatic provider notification flow in your incident‑response runbooks, noting that public‑repo alerts will be forwarded to the issuer.
- Plan periodic reviews of the secret‑scanning provider list to capture future additions.
