GitHub Security Assessments: Turn Protection Status Into Action

A repository can have security tooling enabled and still contain findings. Another can have no ongoing coverage at all. GitHub’s latest assessment update makes that distinction easier to see, but a protection label only becomes useful when someone turns it into a concrete next step.

Quick answer: GitHub security risk assessments now show repository protection status. Use it to separate a coverage decision from a remediation decision: identify where tooling is missing, then assign someone to investigate the actual findings. A protected label does not mean every reported issue has been fixed.

What changed in GitHub security risk assessments?

In its November 2 announcement, GitHub says code security and secret risk assessments now distinguish findings in protected and unprotected repositories. The improvement is available on GitHub Team and GitHub Enterprise Cloud. For the secret risk assessment, GitHub also names Enterprise Server 3.24 as a future availability point; do not assume that server release is already installed in your organization.

The practical change is extra context beside a finding. Instead of asking only which repository has the most issues, a review can also ask which repositories need an ongoing coverage decision.

Read the protection label correctly

GitHub’s code-assessment interpretation guide defines protected repositories in that report as those where GitHub Code Security is enabled. Unprotected means that product is not enabled. This label is about assessment coverage context; it is not a statement about branch rules, production access controls or whether a repository is free of vulnerabilities.

Read the finding and the protection state as two separate fields. If an issue appears in a protected repository, investigate the issue. If it appears in an unprotected repository, investigate the issue and record whether ongoing coverage should change. Enabling a product does not, by itself, demonstrate that the original problem was corrected.

GitHub’s guide also explains the report’s scanned-repository total, vulnerability counts, rule severity and Autofix eligibility. Eligibility identifies findings that may receive suggested fixes; it is not evidence that a particular fix has been reviewed, tested or deployed.

Find the report and check its scope

According to the report-viewing instructions, organization owners and security managers can open their organization’s Security and quality tab, choose Assessments in the sidebar and switch between the Code Security and Secret Protection reports. Labels can evolve, so follow the linked documentation if your interface differs.

Before discussing totals, record which assessment you are reading and when it ran. GitHub’s assessment overview describes different scopes: code assessment scans up to 20 selected repositories, while the secret assessment reviews the organization’s repositories. Avoid presenting a selected code sample as a complete inventory of every system your team operates.

For a review meeting, bring a short list of important repositories that were not included in the code scan. That list is not a finding, but it prevents silence in the report from being mistaken for evidence about unexamined code.

Turn each result into a useful triage note

Here is a proposed worksheet for a small engineering team. It is an editorial workflow, not a measured improvement or a replacement for your incident process.

• Repository and purpose: identify the maintained service or internal tool and its owner.
• Finding reference: link to the access-controlled result rather than copying sensitive details into a public ticket.
• Coverage state: record the report’s protection label and the date observed.
• Remediation task: name the person who will verify the finding and propose a correction.
• Coverage decision: separately record whether ongoing tooling needs review, who approves it and any budget question.
• Closure evidence: describe what will demonstrate the specific issue was addressed.

This format keeps two different owners from waiting on each other. A developer can investigate a result while an administrator reviews coverage options. Conversely, a coverage decision can be recorded without prematurely closing a technical finding.

A hypothetical review: two repositories, two decisions

Imagine an internal reporting service with an assigned maintainer and an older integration tool whose owner is unclear. Both appear in an assessment. These are fictional examples, not TechPulse scan results.

For the maintained service, ask the owner to validate the reported behavior and propose evidence for closure. For the older tool, first identify who can assess its current use and data access. Record missing ownership as an unresolved question rather than assigning a made-up risk score. Protection status adds context to both discussions, but does not answer either question automatically.

Keep the review record with your engineering evidence. Our release-evidence checklist offers a related approach to deciding what records you need to retain. Store sensitive assessment details in the appropriate restricted system.

Choose the next review before buying coverage

GitHub describes the assessment itself as free, including the Actions minutes used for code scans. Its overview treats enabling ongoing security products as a separate next step. Review current eligibility, licensing and estimated charges before approving that change; a free report is not permission to enable paid coverage across every repository.

For secret assessments, the rerun instructions specify a 90-day interval. That makes ownership and follow-up between reports worth recording. Do not leave a verified issue waiting merely for another assessment.

End the meeting with named owners, unresolved scope questions and a check-in date. The useful result is a list of decisions people can act on, with clear evidence for closure. The new label helps organize that work; it does not certify the security of your organization.

Editorial disclosure: Prepared with AI assistance and checked against the linked primary sources on November 3, 2026. TechPulse did not run an organization assessment, inspect private repositories or test remediation outcomes for this article. The worksheet and fictional review are source-based editorial analysis. See our editorial policy.