Summary: On November 2, 2026, GitHub’s changelog announced that its code security and secret risk assessments now report whether findings sit in protected or unprotected repositories. If you run security reviews across an org, this turns a raw vulnerability count into a prioritized worklist: fix unprotected repos first.
What changed
Both free assessments — the code security risk assessment and the secret risk assessment — now annotate every finding with the protection status of the repository it came from. The stated goal is practical: helping org admins and security managers see where security coverage should be extended.
Admins and security managers start an assessment from the Assessments view under their organization’s Security tab. The feature is available in GitHub Enterprise Cloud and GitHub Team now, and the secret risk assessment version lands in GitHub Enterprise Server 3.24.
Why the distinction matters
A vulnerability in a repo with branch protections, required reviews, and restricted push access is a different class of risk than the same vulnerability in a repo where anyone can merge code. Before this change, the assessment reports aggregated findings by severity, which flattens that difference. Now the report effectively answers two questions at once: what did we find, and how easy would it be for someone to exploit or introduce it?
For triage, that means you can stop treating all critical findings as equally urgent. A critical code-scanning alert in an unprotected, actively-developed repo deserves attention today; the same alert behind strong protections might reasonably wait in the queue.
Useful context on how assessments work
The GitHub docs describe the code security risk assessment as a free, self-serve scan for organizations on Team and Enterprise plans. It scans up to 20 private and internal repositories, pre-selected by commit activity over the last 90 days, and reports vulnerabilities, severities, and how many are fixable with Copilot Autofix. Scans have a one-hour timeout per run, and each assessment can be rerun every 90 days with a different repository selection.
The code and secret assessments run independently and show results in separate tabs, so the new protection-status labeling applies to both sides of the picture — leaked credentials and vulnerable code alike.
The takeaway for builders
The pattern here is worth noticing even outside GitHub: risk reporting that includes the guardrails around an asset, not just the flaws in it, is more actionable than severity alone. It’s the same instinct behind GitHub surfacing PR security metrics for admins in one place, which we covered in Measuring AI Scan: GitHub Puts PR Security Metrics Where Admins Can See Them.
One limitation to keep in mind: assessments cover at most 20 repositories per run, so large orgs get a sample, not a census. Use the protection-status breakdown to guide where you extend real security configuration — branch rules, push protection, code scanning defaults — rather than treating the report itself as the fix.
Sources
- Security risk assessments include repository protection status - GitHub Changelog
- Code security risk assessment - GitHub Docs
View the original post on X