Security scanning sounds like something that should always run, even when a repository is no longer being actively developed.

But running a scheduled security scan against every repository in a large organization can also create unnecessary work. Some repositories may be archived, experimental, abandoned, or simply untouched for months.

GitHub has changed how scheduled code scanning works for inactive repositories. With CodeQL default setup, weekly scheduled scans now run only after a push or pull request has triggered a scan within the relevant activity window. For repositories without that activity, weekly scheduled scanning is paused by default.

This does not mean GitHub stops security analysis completely.

The initial scan still runs when default setup is enabled, and scans triggered by pushes or pull requests continue to work. Organizations can also choose to keep scheduled scans running for inactive repositories.

For security teams, the change is mainly about making scheduled scanning more predictable and avoiding unnecessary scans on repositories that are no longer active.

What Changed?

Previously, repository activity used to determine scheduled scanning could be influenced by different types of analysis activity.

GitHub has changed that behavior.

With the current default setup behavior, a repository is considered active for weekly scheduled scanning when a push or pull request triggers a default setup scan within the previous 180 days. Initial validation scans, configuration or language-change scans, and scheduled scans themselves do not count as activity.

The basic behavior can be represented like this:

Code
Repository
    |
    v
Was a push or pull request
triggering a scan seen recently?
    |
    +---- Yes ----> Weekly scheduled scans continue
    |
    +---- No -----> Weekly scheduled scans pause

This is important because simply enabling code scanning does not mean a dormant repository will continue receiving weekly scheduled scans indefinitely.

Why Did GitHub Make This Change?

Imagine an organization with 2,000 repositories.

Many of them may be active, but some could be:

  • Old prototypes

  • Archived projects

  • Proof-of-concept applications

  • Deprecated services

  • Internal experiments

  • Repositories maintained only occasionally

Now imagine an organization administrator enables default setup across a large collection of repositories.

An initial scan is useful because it establishes the security baseline.

But if that initial scan were enough to keep the repository classified as active for months, dormant repositories could continue generating scheduled scans even when nobody is developing them.

GitHub's updated behavior separates initial analysis from development activity.

The initial scan still provides immediate findings, but weekly scanning starts only after a push or pull request triggers an analysis.

What Counts as Activity?

This is one of the most important details for developers and security administrators.

A push or pull request that triggers a default setup scan counts as activity.

Other types of analysis do not necessarily extend the weekly schedule.

For example:

Activity

Keeps Weekly Scheduled Scans Active?

Push triggering a scan

Yes

Pull request triggering a scan

Yes

Initial validation scan

No

Configuration change scan

No

Language change scan

No

Scheduled scan itself

No

Old push from before setup was enabled

No

GitHub's documentation specifically notes that pushes and pull requests from before default setup was enabled do not count as activity.

This distinction matters when organizations roll out CodeQL across existing repositories.

What Happens When a Repository Becomes Inactive?

Suppose a repository has CodeQL default setup enabled.

During normal development:

Code
Push
 |
 v
CodeQL Scan
 |
 v
Repository Active
 |
 v
Weekly Scheduled Scan

If development stops:

Code
Last Push / PR
      |
      v
180 Days Pass
      |
      v
Repository Becomes Inactive
      |
      v
Weekly Scheduled Scans Pause

The repository does not lose its existing configuration simply because it becomes inactive.

The key change is the behavior of the recurring scheduled scan.

This distinction is important when reviewing security coverage reports. A repository can still have code scanning configured while not receiving weekly scheduled scans because it has not had recent development activity.

What Happens When Development Starts Again?

Suppose a repository has been inactive for several months.

A developer eventually opens a pull request.

The pull request triggers code scanning again.

That new activity can make the repository active for scheduled scanning.

The workflow becomes:

Code
Inactive Repository
       |
       v
New Push / Pull Request
       |
       v
Code Scanning Runs
       |
       v
Repository Active
       |
       v
Weekly Scheduled Scans Resume

This makes scheduled scanning follow actual development activity rather than simply following the age of the code-scanning configuration.

Does This Mean Inactive Code Is No Longer Secure?

Not necessarily.

This change affects scheduled scanning behavior. It does not mean that every security mechanism stops working.

For example, when a developer creates a pull request, that activity can trigger a scan.

This means a dormant repository can still receive analysis when development starts again.

However, security teams should think carefully about repositories that are inactive but still deployed or otherwise important.

An application can be inactive from a Git perspective while still running in production.

That is an important distinction.

Inactive Does Not Always Mean Unimportant

Consider an internal payment service.

The repository has not received a commit in eight months because the application is stable.

From GitHub's perspective, it may be inactive.

From the business's perspective, however, the application could still be critical.

This creates an important security question:

Should a repository's scan frequency depend only on development activity?

For many organizations, the answer may be no.

A production application that rarely changes can still be exposed to newly discovered vulnerabilities in its dependencies, runtime, framework, or surrounding environment.

Security teams should therefore classify repositories based on business risk, not only commit frequency.

How Organizations Can Continue Scanning Inactive Repositories

GitHub provides an organization-level setting to keep scheduled scans running for inactive repositories.

The setting is:

Code
Keep scheduled scans running every 30 days
for inactive repositories

When enabled, inactive repositories continue receiving scheduled scans every 30 days. The scan period itself is not configurable.

The setting can be managed from the organization's security configuration area.

The general path is:

Code
Organization Settings
       |
       v
Security
       |
       v
Advanced Security
       |
       v
Global Settings
       |
       v
Code Scanning
       |
       v
Keep scheduled scans running
for inactive repositories

This gives organizations a choice between reducing unnecessary scans and maintaining continuous scanning coverage.

When Should You Keep Scanning Inactive Repositories?

There is no single answer for every repository.

A useful classification is:

Repository Type

Suggested Approach

Archived project

Usually no recurring scan needed

Old prototype

Usually no recurring scan needed

Active development project

Weekly scanning

Production service with little code change

Consider continued scanning

Security-sensitive application

Strong case for continued scanning

Compliance-sensitive repository

Follow organizational requirements

Deprecated but still deployed system

Consider continued scanning

The important point is that repository activity and application risk are different measurements.

A repository with very few commits can still contain highly valuable software.

What About Newly Enabled Default Setup?

When default setup is enabled, GitHub still performs an initial validation scan and populates findings.

However, that initial scan does not itself start the weekly scheduled scanning cycle.

A push or pull request must trigger a scan for the repository to become active for weekly scheduled scanning.

This can surprise teams performing large-scale security rollouts.

For example:

Code
Enable Default Setup
        |
        v
Initial Scan
        |
        v
Findings Available
        |
        v
No Recent Push / PR
        |
        v
Weekly Schedule Does Not Start

That behavior is intentional.

A Practical Example

Suppose a team enables default setup on a repository on Monday.

The initial scan runs successfully.

The team then does nothing with the repository for several months.

No pull requests are opened and no new commits trigger analysis.

The repository eventually becomes inactive for scheduled scanning.

Later, a developer opens a pull request.

The pull request triggers a new scan.

Now the repository is active again for weekly scheduled scanning.

This means the scan lifecycle follows actual repository development activity.

What Security Teams Should Check

If you manage code scanning across many repositories, review your security inventory.

Start by identifying:

  1. Which repositories are production systems?

  2. Which repositories are inactive?

  3. Which inactive repositories are still deployed?

  4. Which repositories contain sensitive data?

  5. Which repositories have compliance requirements?

  6. Which repositories are archived?

  7. Which repositories are actively maintained?

This creates a better basis for deciding whether continued scheduled scanning is necessary.

Common Mistakes

Assuming Every Enabled Repository Is Scanned Weekly Forever

Enabling default setup does not mean weekly scanning continues indefinitely without development activity.

Check the repository's actual scan activity.

Treating an Inactive Repository as a Low-Risk Repository

A repository can be inactive while its application is still running in production.

Do not use commit frequency as the only risk metric.

Assuming the Initial Scan Starts the Weekly Schedule

The initial validation scan does not count as the activity that starts weekly scheduled scanning.

A push or pull request triggering analysis is required.

Forgetting About Organization-Level Settings

If continuous scanning of inactive repositories is important, security administrators should review the organization-level setting.

Looking Only at Git Activity

Security teams should also consider deployment status, business criticality, exposure, and data sensitivity.

Troubleshooting

Weekly Scans Stopped

First check whether the repository has had a push or pull request triggering a default setup scan within the last 180 days.

If not, the repository may simply be considered inactive.

Initial Scan Worked but Weekly Scans Never Started

This can be expected behavior.

An initial scan does not itself establish the activity required for weekly scheduled scanning.

Check whether a push or pull request has triggered a scan.

A Repository Is Still Important Even Though It Is Inactive

Review the organization-level setting for continuing scans on inactive repositories.

If the application is production-critical, continuous scanning may be more appropriate than relying on development activity.

Security Dashboard Shows No Recent Scheduled Scan

Do not immediately assume code scanning is broken.

First check:

Code
Code Scanning Enabled?
        |
        v
Default Setup Active?
        |
        v
Recent Push / PR Triggered Scan?
        |
        v
Repository Active?
        |
        v
Scheduled Scan Expected?

This helps separate configuration problems from the expected inactive-repository behavior.

Advantages

Fewer Unnecessary Scheduled Scans

Dormant repositories do not automatically continue receiving weekly scans simply because scanning was enabled months ago.

More Predictable Behavior

Organizations can better understand why scheduled scans are running or paused.

Better Alignment With Development Activity

Weekly scanning follows repositories that are actually being changed.

Organization-Level Control

Security teams can override the default behavior when continuous scanning of inactive repositories is important.

Disadvantages and Trade-Offs

Inactive Production Systems May Be Missed Between Scheduled Scans

A repository can be inactive while its application remains important.

Security Teams Need Better Classification

Organizations need to distinguish development activity from business risk.

Developers May Misinterpret "Inactive"

An old repository is not automatically a safe repository.

Additional Governance May Be Required

Large organizations may need policies that identify which inactive repositories must continue receiving scheduled scans.

Best Practices

  1. Do not equate inactivity with low security risk.

  2. Identify production repositories that rarely change.

  3. Review the organization's inactive-repository scanning policy.

  4. Use pull request scanning as part of the normal development workflow.

  5. Monitor repositories that remain deployed even when development slows down.

  6. Classify repositories by business criticality, not only commit frequency.

  7. Review scan activity periodically across the organization.

  8. Keep continuous scanning enabled for inactive repositories when business or compliance requirements justify it.

  9. Do not assume an initial scan means weekly scanning has started.

  10. Investigate missing scans only after checking repository activity and configuration.

Summary

GitHub Code Scanning default setup now treats repository activity more carefully when deciding whether weekly scheduled scans should continue.

A push or pull request that triggers a default setup scan within the previous 180 days keeps the repository active for weekly scanning. Initial scans, configuration or language-change scans, and scheduled scans do not count as activity.

Organizations that need continuous scanning can enable the setting that keeps scheduled scans running every 30 days for inactive repositories.

For developers and security teams, the main lesson is to separate development activity from security importance. A repository that rarely changes may still run a critical production application, and those systems deserve a security strategy that does not depend entirely on how often developers commit code.