GitHub security risk assessment reports now identify whether findings are in protected or unprotected repositories. The November 2 change can help GitHub Team and Enterprise Cloud organizations spot coverage gaps, but it does not automatically enable protection or eliminate vulnerabilities.
Source announcement: November 2, 2026 · Publisher: GitHub · Editorial review: November 3, 2026
What Happened
On November 2, 2026, GitHub announced an update to its code security risk assessment and secret risk assessment reports. Both now indicate whether findings belong to repositories with security protection enabled or to repositories without that coverage. The distinction helps security managers identify not only what an assessment found, but also where preventive tooling may need attention.
GitHub describes this as an improvement to assessment reporting. It is not an announcement that all repositories have become protected, nor proof that a particular organization’s vulnerabilities have been fixed.
Who Is Affected and When
The release is available to organizations on GitHub Team and GitHub Enterprise Cloud. Organization owners and security managers can access assessments under their organization’s Security → Assessments area. GitHub also says the improvement will become available for the secret risk assessment in GitHub Enterprise Server 3.24. That is a future product-version condition, not a claim that every self-hosted installation has received it today.
For teams operating on other plans or earlier Enterprise Server versions, the announcement should not be read as a universal rollout. Administrators should confirm which security products and assessment views their organization can access before preparing a reporting change.
What Changes in Practice
Previously, a list of detected issues could direct attention toward counts and severity without immediately answering another management question: which affected repositories already have protection in place? The new repository-protection status adds that context to the two risk-assessment views. A security lead can use it to distinguish a finding that appears within an already protected area from an exposure in a repository where coverage may be missing.
A sensible review begins with a fresh assessment, then groups findings by protection status. Teams can investigate unprotected repositories first, verify whether appropriate tools are available and enabled, and establish owners for follow-up. They should also investigate high-severity issues inside protected repositories: protection status is not the same as a clean bill of health.
Understanding the Two Assessments
GitHub’s official documentation describes the code security risk assessment as a free, self-service scan for supported organizations. It can examine up to 20 selected private or internal repositories and produces a report on detected vulnerabilities and severity. GitHub normally preselects candidates using recent commit activity, but administrators can adjust the set before scanning. A code assessment can be rerun every 90 days, so the results are not a continuously refreshed inventory.
The separate secret risk assessment is a free point-in-time check for exposed credentials such as tokens, API keys and passwords. GitHub’s documentation explains that reports can include total secrets, publicly exposed secrets, types of secrets and potentially preventable leaks. The two assessments operate independently. Their results should not be combined as though they came from one identical detector.
Why This Matters to Software Teams
For an engineering organization with multiple repositories, a security backlog is hard to prioritize when it mixes findings from different projects, owners and protection policies. Status information can make triage more actionable: a team may decide to review an unprotected repository’s security settings while another team investigates a critical vulnerability already detected in a protected codebase.
This is especially relevant to buyers comparing developer platforms and their security administration features. Assessment availability, coverage and follow-up workflow can matter as much as the raw number of findings. But the new label should be treated as a decision aid rather than a score that proves an organization is secure.
What to Check Before Acting
Start by verifying the organization plan, your permissions and whether the assessment was recently run. Review the repositories included: GitHub’s code assessment has selection and language-support limits, and a report covering up to 20 repositories may not reflect a much larger organization. Look at the separate secret assessment for credential exposures rather than assuming the code scan finds every kind of leaked secret.
Next, confirm how GitHub defines the displayed protection state in your actual assessment and check the repository settings and licensing before making a change. Do not infer that a protected repository contains no vulnerabilities, or that an unprotected one is already compromised. Where a report identifies leaked secrets, follow the relevant credential-rotation and incident-response process instead of relying on an interface label alone.
Our Take
The useful part of this update is the connection between findings and coverage. It gives security managers another way to prioritize questions about risk and the reach of protective tooling. The value is operational rather than cosmetic, provided teams verify the underlying assessment scope and act on confirmed gaps.
This is editorial analysis of GitHub’s release note and documentation. DigiOffly did not run a hands-on code or secret assessment in a customer’s repository, audit GitHub’s detection accuracy or independently measure risk reduction from the new status field.
Verification note. DigiOffly reviewed the original dated vendor announcement and accompanying GitHub documentation. This is source-based news analysis, not first-hand software testing. Product rollouts and documentation may change.
Official Sources and Dates
Announcement date: November 2, 2026. GitHub’s code and secret risk assessment documentation was checked on November 3, 2026. Enterprise Server 3.24 availability is described as future-facing in the original announcement.