GitHub Changes When Quiet Repositories Get Weekly Security Scans

Turning on code scanning across a collection of old GitHub repositories will no longer start weekly scans everywhere. Each repository still gets its initial validation scan, but recurring scans now wait for an analysis triggered by a push or pull request.

GitHub announced the change on October 1 for code scanning default setup and GitHub Code Quality. It applies to Enterprise Cloud now, with Enterprise Server support planned for 3.24. Earlier Git activity does not satisfy the requirement: the decision uses analysis history. Activity remains shared between the two products.

Previously, an initial validation scan or a detected-language change could make a dormant repository count as active for another six months. Applying a security configuration across an organization could therefore bring a lot of weekly scanning along with it. GitHub says no configuration change is required for the new behavior.

A quiet repository can still be running in production

I work with hundreds of repositories. The uncomfortable part of any estate that size is that development activity and operational importance are different inventories. A repository can go untouched for months while its last build continues serving requests every day.

That makes this a sensible reduction in background work, with a qualification for anyone reporting security coverage: “enabled” and “scanned recently” need separate columns.

I would put four things next to each other before drawing conclusions from a dashboard: the repository owner, the deployed service, the latest successful analysis, and the event that caused it. An old timestamp on retired code might be entirely appropriate. The same timestamp on an internet-facing service deserves a decision from the person responsible for it.

The initial scan still provides findings. What I would avoid is taking that successful rollout as evidence of an ongoing review cadence across every repository.

Decide the cadence before changing workflows

This announcement concerns default setup and Code Quality. It is not a statement that GitHub has disabled every scheduled security workflow or every dependency alert. Check the mechanism a repository actually uses before changing it.

GitHub’s default-setup documentation is the starting point for its managed configuration. If a service needs a scan schedule independent of development activity, review the supported configuration options for that requirement rather than manufacturing empty commits to keep it looking busy.

I would make that a service policy. Which deployed systems need recurring analysis even without code changes? Who follows up on the results? Which repositories are truly retired? A template can carry those decisions into configuration, but it cannot decide them from the age of the last commit.

There is also a practical reason to keep the rollout small. Pick one quiet but deployed service and one actively developed repository. Confirm the initial results, then check the analysis history after a normal development event. That gives the person maintaining the rollout something concrete to compare with the rest of the organization.

Fewer unexpected scans is welcome. I would use the change to clean up ownership and coverage reporting at the same time, so a reduction in background jobs does not silently become a change in the review schedule somebody thought they had.