9 min read - GitHub inactive repositories: set a reactivation scan gate

On 1 October 2026, GitHub changed how it decides whether an inactive repository should receive weekly scans under code scanning default setup and GitHub Code Quality. An initial validation scan, a configuration scan or a scan caused by detected language changes no longer makes a dormant repository look active. Weekly scanning starts after a push or pull request triggers analysis, according to the GitHub announcement.

GitHub's current documentation defines an active repository for this purpose as one where a push or pull request triggered a default-setup analysis within the last 180 days. Organisation owners can override the default and keep scans running every 30 days on inactive repositories, but they cannot choose another interval through that setting. The default-setup configuration guide records both rules.

The change measures analysis activity, not risk or lifecycle state. A repository can be quiet while its built artefact still runs in production, ships inside a customer deployment, provides a shared library or remains available for a rapid restart. That difference between development activity and business use is the decision teams need to resolve.

Classify dormant code, preserve recurring analysis where exposure warrants it and make a fresh security result part of any reactivation decision. Forcing weekly scans across every old experiment would only create work without resolving ownership.

Read the change narrowly

Default setup still runs an initial validation analysis when it is enabled. Under the new activity calculation, however, that initial result does not start the weekly schedule. Nor does a scan caused only by a configuration or language-detection change. A push or pull request must trigger analysis first. GitHub says the change applies to GitHub Enterprise Cloud now and GitHub Enterprise Server 3.24 later.

The distinction matters during a security-configuration rollout. Applying default setup to hundreds of repositories can populate findings immediately without committing the organisation to six months of weekly scans for code nobody is changing. GitHub describes that reduction in unexpected work as the purpose of the update.

It also removes a comforting but weak signal. A dashboard showing default setup as enabled does not, by itself, prove that scheduled scans are still running. The effective state depends on qualifying analysis history and the organisation's inactive repository setting. Record those separately.

Advanced setup follows the workflow checked into the repository. GitHub's workflow configuration reference explains that an advanced CodeQL workflow can combine push, pull-request and scheduled events. A schedule runs only when the workflow file exists on the default branch. Teams should therefore identify the setup type before drawing conclusions from the 180 day rule.

Classify dormant code by use, not commit date

A commit timestamp is a poor lifecycle record. Start with four operational classes and assign an owner to each repository:

Do not infer production status from GitHub activity. Ask the service owner whether a deployed binary, container image, package, infrastructure definition or recovery plan still depends on the repository. Check release registries and deployment records rather than accepting "no recent commits" as evidence that nothing uses it.

Quiet but supported repositories deserve particular attention. Scheduled code analysis can apply newer queries to unchanged source. GitHub's workflow guide describes this as the reason for scheduled scanning: it can report vulnerabilities and errors discovered after the last code change. If the software remains a supported release, the absence of new commits does not remove that benefit.

The NIST Secure Software Development Framework recommends choosing code review and analysis according to the software's stage, recording and triaging discovered issues, and performing automated analysis regularly or continuously for supported releases. NIST does not prescribe a GitHub setting. It does support the underlying policy choice: scanning cadence should follow support and risk, not repository age alone.

Put a gate in front of reactivation

An inactive repository often returns under time pressure. A customer asks for a small change, a team revives an internal tool, or a replacement project slips. The first pull request then combines a business restart, dependency catch-up, CI restoration and a security review. Treating it as an ordinary patch hides too many decisions in one merge.

Define reactivation as a lifecycle event. Before the first release, require a named owner, the intended use, the supported branch and runtime, the data and credentials the software can reach, and the date of the last trusted deployment. Mark assumptions that cannot be confirmed. A former proof of concept should not regain production access because its build happens to pass.

Next, trigger a fresh analysis through the repository's approved path and retain the run URL, commit, query or tool version, languages covered and final alert dispositions. With default setup, a qualifying push or pull request can restart analysis; block the reactivation merge until the result exists and reviewers have triaged it. If policy requires a scan before any code change, keep monthly analysis on the repository or use an approved advanced workflow that supplies that evidence.

CodeQL is one control, not the whole gate. Review dependency state, build provenance, workflow permissions, secrets and deployment credentials with the tools assigned by your security process. Re-establish branch protection and required reviews before granting the pipeline access to production. Our GitHub Actions trust-boundary review shows why an old workflow deserves its own examination when execution resumes.

Do not let the first feature deadline decide which findings are acceptable. The service owner and security reviewer should record one of three outcomes for each material issue: remediate before release, accept for a stated period with an accountable approver, or stop the reactivation. Those are governance decisions; a green scan cannot make them automatically.

Make coverage visible at portfolio level

Repository-by-repository settings are hard to interpret once an organisation has more projects than its security team can recall. Build a small inventory from observable fields:

• repository and accountable owner;
• lifecycle class and last confirmation date;
• deployed or distributed artefacts that depend on it;
• default or advanced code-scanning setup;
• last push or pull-request analysis and last scheduled analysis;
• covered languages, open alerts and documented exceptions;
• reactivation approval state.

The inventory should distinguish "configured" from "recently executed". It should also flag repositories where the setup cannot analyse the main language, the workflow no longer runs, or findings have no reviewer. A licence assignment and a configuration toggle are inputs, not proof of coverage.

Review exceptions in groups. If ten low-risk training repositories share the same lifecycle and access controls, one documented policy may be enough. A dormant payment service, identity component or infrastructure repository needs its own owner and evidence because its exposure and reactivation cost differ.

For teams already testing AI-assisted findings, keep that experiment separate from the baseline. Our GitHub AI Scan pilot framework explains how to validate tool output without weakening existing merge controls. A new detector does not repair missing ownership or an unobserved scan schedule.

Review the setting without creating busywork

Start with repositories that GitHub considers inactive, then join that list to service, release and asset records. The first review should answer two questions: which inactive repositories still support something, and which supposedly active repositories lack a recent successful analysis?

Keep monthly scans for quiet repositories where new analysis can change a support or deployment decision. Use a reactivation-only gate for frozen reference code that cannot run or ship. Retire repositories that have no owner and no retention need through the organisation's normal records process. The correct mix will vary, but every exception should state who made it and when it expires.

Finally, test the gate with one dormant repository before applying it across the portfolio. Confirm that a pull request triggers the expected analysis, required checks block the merge, reviewers can see the result and the evidence remains available after the decision. If the test exposes a missing runner, unsupported language or broken workflow, fix the process before a real restart depends on it.

Exceev's services approach connects technical assessment, implementation and team handover when repository governance reveals a wider ownership problem.

Sources and limitations

We opened and reviewed every source below on 2 October 2026.

• GitHub's 1 October announcement establishes the changed activity calculation, initial validation behavior, current product scope and stated reason for the update.
• GitHub's default-setup configuration guide defines the 180 day activity window and the optional 30 day scanning setting for inactive repositories.
• GitHub's CodeQL workflow reference explains event and scheduled triggers for advanced setup and the requirement that the workflow file exist on the default branch.
• NIST SP 800-218, Secure Software Development Framework supplies independent guidance on stage-appropriate analysis, issue triage and regular or continuous analysis for supported releases.

GitHub is the authority for its product behavior; NIST does not endorse GitHub or this proposed operating model. We did not inspect a customer's repositories, licences, workflows, runners, alerts or production dependencies. GitHub may revise its service and documentation after the review date. Code scanning cannot establish that software is free of vulnerabilities, and this article is not a security certification or legal advice.