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
Status
What it really means
First instinct
Active
The credential still works right now.
Fix immediately.
Unknown
Couldn’t verify (no activity, unsupported, provider issue, throttling, network).
Treat as possibly active; retry or rotate if sensitive.
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
Filter for Active secrets
I see list filters to only results that are Active
Open an Active alert and see when it was last verified
I then proceed with the recommended remediation, including rotation/revocation and code removal.
Run on‑demand verification by clicking “Verify Secret”
Wait a couple of minutes, verification has updated
Sweep Unknown secrets
Strategy: Retry verification later, or treat as Active if it’s high‑privilege or high‑impact.
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:
What is the potential blast radius? (Production infrastructure vs. internal sandbox.)
How sensitive is the data it gates?
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
The post Hunting Living Secrets: Secret Validity Checks Arrive in GitHub Advanced Security for Azure DevOps appeared first on Azure DevOps Blog.