Check leaked Asana, IBM, and MessageBird tokens faster with GitHub secret scanning

GitHub secret scanning now supports validity checks for several Asana, IBM, and MessageBird secret patterns. Confidence level: confirmed. The practical change is triage speed: when one of these supported secrets appears in code, security teams can get a stronger signal on whether the credential is still active instead of treating every alert with the same urgency.

What changed

GitHub announced on July 1, 2026 that secret scanning now runs validity checks for Asana, IBM, and MessageBird secrets. The changelog names asana_legacy_format_personal_access_token explicitly and points users to GitHub's supported-patterns documentation for the full list.

Validity checks do not remove the need to rotate leaked credentials. They help responders separate likely-active secrets from stale or revoked ones, which is useful when a repository, fork, issue, or pull request exposes several tokens at once.

Why this is early

This is early because the validator update is fresh in GitHub's July changelog and the operational impact depends on which secret types your organization actually uses. GitHub is the primary source for the release, and GitHub Docs provides the supporting reference for the broader secret scanning pattern catalog.

There is no independent incident report tied to this update. Treat it as a platform security improvement, not evidence that Asana, IBM, or MessageBird tokens are currently being exploited at unusual scale.

Key takeaways

• GitHub secret scanning added validity checks for Asana, IBM, and MessageBird secret patterns.
• Validity checks help prioritize exposed credentials that may still work.
• Rotation and revocation remain required when a real credential leaks.
• Teams should update incident runbooks so "valid secret" alerts trigger faster owner notification.
• The supported-patterns page remains the reference for which secret types GitHub can detect.

Availability and access

The update is available through GitHub secret scanning where the relevant secret patterns are supported. Organizations using GitHub Advanced Security or eligible secret scanning features should check whether these providers appear in their alert coverage and whether validity status is visible in their normal triage workflow.

Teams using Asana, IBM services, or MessageBird should also confirm internal ownership. A validity check is most useful when alerts can route to the team that owns the token, the app, and the external provider account.

Practical LinkLoot angle

This is a small release with a direct runbook payoff. Add a branch to the incident workflow: if GitHub marks one of these secrets as active, notify the service owner, revoke the token, inspect recent provider-side activity, and search for copies in forks, packages, logs, and tickets.

For agent-assisted development, the same rule applies to automation. If coding agents can create branches, issues, or pull requests, include secret scanning alerts in the review loop before generated changes move into production. LinkLoot's AI workflow automation guide is a useful place to connect code-generation controls with credential hygiene.

What to verify before you act

• Confirm the exact Asana, IBM, and MessageBird token patterns your organization uses.
• Check whether GitHub marks those patterns with validity status in your plan and repository scope.
• Make sure alert routing reaches the service owner, not only the repository owner.
• Keep provider-side revocation and audit-log steps in the runbook.
• Add custom patterns for internal tokens or unsupported SaaS credentials.

Source check

Confirmed by: GitHub's July 1, 2026 changelog confirms the validator expansion for Asana, IBM, and MessageBird secrets and links the update to secret scanning.

Supporting context: GitHub Docs provides the supported secret scanning pattern reference and explains the broader coverage surface. LinkLoot treats the docs as coverage context, while the dated changelog is the release source.