GitHub changes what counts as activity for scheduled code scans

A narrower definition of activity

GitHub’s October 1 change makes weekly scheduled scanning for default code scanning and Code Quality depend on analysis triggered by a push or pull request. Enabling default setup still runs an initial validation and populates findings. Previously, validation and language-detection changes could make a dormant repository count as active. GitHub says the new behavior applies to Enterprise Cloud and will be supported in Enterprise Server 3.24.

The relevant distinction is analysis history, not simply whether a repository contains recent commits. A fleet administrator enabling scanning across many repositories should therefore understand what the initial run establishes and what starts the recurring schedule. Fewer unexpected scans can make resource use easier to explain, but a quiet repository still requires an owner who understands its role.

Source: GitHub: Scheduled scans and inactive repositories

Analysis: Dormant code can remain operationally important

A repository can stop receiving changes while its software continues to run. Conversely, an active repository may be an experiment that nobody deploys. Development activity is useful for scheduling work, but it is not a complete inventory of operational exposure. An organization should avoid treating the absence of weekly scanning as a statement that a system is safe or unused.

That matters when reporting coverage. A dashboard counting repositories with scanning enabled might hide differences between an initial analysis and repeated runs. A more useful record could show the last actual analysis, the code revision it examined and the deployment status of the associated service. Those details help a security team decide whether a quiet project needs a separate review, an upgrade or retirement.

Practical implications: Verify the schedule’s meaning

Fleet owners can sample repositories that recently received default setup and check which analysis event started their schedule. They can also identify maintained services whose source repositories have little development activity. This does not require assuming the platform’s rule is wrong; it requires matching the rule to the organization’s own definition of what deserves continuing attention.

A meaningful report should explain both coverage and freshness. If an initial scan found issues that remain unresolved, stopping extra routine scans does not close those issues. If an application is no longer used, the inventory should say so explicitly. GitHub’s change makes one scheduling decision more predictable. The security outcome still depends on whether people know which software is in use, what evidence they have about it and who is responsible for its remaining findings.

An inventory review can flag services still deployed from quiet repositories and record the reason for keeping them. That connects scheduling to an actual operating decision, instead of allowing inactivity to become an accidental substitute for retirement.