If you’ve ever waded through a swamp of secret scanning alerts wondering, “Which of these are actually dangerous right now?” — this enhancement is for you.

Secret validity checks in GitHub Advanced Security for Azure DevOps (and the standalone Secret Protection experience) add a high‑signal field to each alert: Active (still usable), or Unknown (couldn’t be verified).

Instead of treating every alert like a five‑alarm fire, you can now fast‑path the truly risky stuff and spend less time chasing ghosts.

TL;DR

Why This Matters

Traditional secret scanning:

Found something → raise alert → you investigate → sometimes it was revoked months ago → wasted cycles.

Secret scanning + validity checks:

Found something → provider queried automatically → you know if it still opens doors.

This feature doesn’t revoke secrets for you—it improves prioritization. You spend your time on “living” (Active) secrets first, not archaeological specimens.

How It Works

• Secret scanning detects a string matching a supported partner/provider pattern.
• The platform securely queries the provider to confirm whether the credential still works.
• You get a status: Active or Unknown.
• You trigger an on‑demand verification after remediation to confirm it is no longer active.

Supported provider patterns are listed here (bookmark it; it will evolve). If a pattern isn’t supported, the alert may remain Unknown—that’s expected.

Before You Start

Make sure:

• GitHub Advanced Security for Azure DevOps is enabled for the project/repository (or Secret protection is enabled in the standalone experience).
• Secret scanning is turned on (validity checks are an enhancement, not a standalone feature).

Once those are true, validity checks just start for newly detected supported secret types. No extra toggle. No YAML fiddling.

Typical Workflow

1. Filter for Active secrets

   

   I see list filters to only results that are Active

   

2. Open an Active alert and see when it was last verified

   

   I then proceed with the recommended remediation, including rotation/revocation and code removal.

3. Run on‑demand verification by clicking “Verify Secret”

   

   Wait a couple of minutes, verification has updated

   

4. Sweep Unknown secrets

   • Strategy: Retry verification later, or treat as Active if it’s high‑privilege or high‑impact.

5. Close alerts according to your policy once remediation + verification (if applicable) are complete.

Dealing with “Unknown”

Unknown ≠ safe. Classify Unknown secrets with three quick questions:

1. What is the potential blast radius? (Production infrastructure vs. internal sandbox.)
2. How sensitive is the data it gates?
3. What’s the rotation cost? (Cheap to rotate? Do it.)

If 2+ factors lean “risky,” act as if Active and remediate.

FAQ Quick Hits

• Does this revoke secrets automatically?
  No. It informs prioritization; remediation is manual (or via your automation).

• Will all secret types support validation?
  More partners will onboard over time—track the supported patterns list.

Final Call to Action

• Confirm secret scanning is enabled.
• Filter for Active secrets today.
• Use built-in Recommendations & Remediation.
• Run on-demand verification to validate your fix.
• Track how quickly you neutralize live credentials, then improve from there.

Fewer ghosts. More real wins.

Happy hunting.

Appendix: Reference Link

• Explore secret scanning in greater depth
• Supported provider patterns for validation
• Configure GitHub Advanced Security for Azure DevOps features – Azure Repos | Microsoft Learn
• Curious what’s new? Our release notes have the highlights