Code scanning is an important part of modern application security. It helps developers identify vulnerabilities and coding problems before they reach production.

But security scanning also consumes computing resources. Large organizations can have thousands of repositories, and not every repository is actively developed.

Scanning an abandoned or inactive repository on every scheduled run may provide little value while consuming runner time and producing alerts that nobody is likely to address.

GitHub has introduced changes that allow code scanning to skip repositories that are inactive under the applicable scanning policy. For development teams, this means the way scheduled security scans run can change depending on repository activity.

This article explains what inactive repositories mean in the context of code scanning, why skipping them can be useful, what teams should consider before relying on this behavior, and how to design a security process that does not accidentally leave important code unprotected.

What Is GitHub Code Scanning?

GitHub Code Scanning is a security feature that analyzes source code to identify potential vulnerabilities and coding problems.

A scanning tool examines code and looks for patterns that could indicate security issues.

For example, a simple application might contain:

public string BuildQuery(string userInput)
{
    return "SELECT * FROM Users WHERE Name = '" + userInput + "'";
}

This type of code can create SQL injection risk when used with an actual database query.

A static analysis tool can identify suspicious patterns before the application is deployed.

Code scanning can therefore become part of the development workflow:

Developer
   |
   v
Pull Request
   |
   v
Code Scanning
   |
   v
Security Findings
   |
   v
Fix
   |
   v
Merge

Why Scan Inactive Repositories?

At first glance, scanning every repository continuously sounds like the safest approach.

However, large organizations may have repositories that are:

Consider an organization with 5,000 repositories.

Only 1,200 may be actively developed.

Running the same scheduled analysis across every repository can consume considerable CI/CD resources.

The organization may instead prioritize active repositories while applying different controls to inactive code.

What Does "Inactive" Mean?

Inactive does not simply mean:

"Nobody pushed code today."

Repository activity can involve multiple signals.

Depending on the scanning configuration and GitHub behavior, activity can include things such as:

The exact definition and behavior should be checked against the current GitHub configuration available to the organization.

The important operational idea is that repository activity can influence whether scheduled scanning continues to run.

Why This Change Matters

Skipping inactive repositories can improve the efficiency of security scanning.

Instead of:

All Repositories
      |
      v
Scan Everything
      |
      +--> Active
      +--> Inactive
      +--> Archived
      +--> Experimental

an organization can prioritize:

Repositories
     |
     +--> Active
     |      |
     |      v
     |   Regular Scanning
     |
     +--> Inactive
            |
            v
       Reduced Scanning

This can reduce unnecessary scanning work.

However, it also creates an important security question:

What happens if an inactive repository becomes important again?

That question should be part of the organization's repository lifecycle process.

Code Scanning Is Not the Same as Dependency Scanning

Developers sometimes combine several security concepts under the word "scanning."

Code scanning focuses primarily on source-code analysis.

Dependency security focuses on third-party packages.

For example:

Application
   |
   +--> Source Code
   |      |
   |      v
   |   Code Scanning
   |
   +--> Dependencies
          |
          v
      Dependency Scanning

A repository may therefore need multiple security controls.

Skipping code scanning for an inactive repository does not necessarily mean every other security process stops.

A Simple Example

Suppose a .NET repository contains:

public async Task<User?> GetUser(string name)
{
    var sql = $"SELECT * FROM Users WHERE Name = '{name}'";

    return await database.QuerySingleOrDefaultAsync<User>(sql);
}

A static analyzer may identify the construction of SQL from untrusted input as a security concern.

A developer can fix the problem by using a parameterized query:

public async Task<User?> GetUser(string name)
{
    const string sql =
        "SELECT * FROM Users WHERE Name = @Name";

    return await database.QuerySingleOrDefaultAsync<User>(
        sql,
        new { Name = name });
}

The scanner provides value when the repository is actively maintained.

But if the repository has not changed for years and the application is retired, repeatedly analyzing the same unchanged source may not provide the same operational value.

Inactive Does Not Mean Safe

This is the most important point.

A repository being inactive does not mean that its code is secure.

A vulnerability can exist in code that has not changed for years.

For example:

Repository last changed:
3 years ago

Vulnerability discovered:
Today

The code has not changed, but the risk may have changed.

This is why teams need to distinguish between:

These are not equivalent.

An Inactive Production Repository Can Still Be a Risk

Consider a production application that has not received source-code changes for six months.

The repository may appear inactive.

But the application is still running:

GitHub Repository
       |
       v
No recent commits
       |
       v
Production application
       |
       v
Internet users

If the repository stops receiving regular code-scanning attention simply because there has been little development activity, the organization needs another way to ensure the running application remains secure.

Security decisions should therefore consider runtime exposure, not just repository activity.

Repository Lifecycle Matters

A better security process classifies repositories according to lifecycle.

For example:

Repository State

Security Approach

Active development

Regular code scanning

Production but low change rate

Continue security monitoring

Maintenance only

Scheduled security checks

Temporarily inactive

Review before reducing scanning

Archived

Follow archive policy

Retired application

Confirm shutdown before reducing controls

This is more useful than treating all inactive repositories as identical.

Common Mistakes

Assuming No Commits Means No Risk

A production application can run unchanged for years.

Security vulnerabilities do not require new commits.

Forgetting About Inactive Production Systems

Teams sometimes classify a repository as inactive without checking whether its application is still deployed.

Treating Scanning as the Only Security Control

Security requires multiple layers.

Code scanning is only one part of the process.

Failing to Define Repository Ownership

If nobody owns an inactive repository, it becomes difficult to decide whether the repository should remain protected.

Never Reviewing Archived Repositories

An archived repository may still contain credentials, sensitive code, or information that should be handled appropriately.

How to Decide Whether a Repository Can Be Safely Scanned Less Often

Before reducing security scanning, ask:

  1. Is the application still running?

  2. Is the repository still deployed anywhere?

  3. Is the repository publicly accessible?

  4. Does it contain sensitive information?

  5. Does it contain production infrastructure code?

  6. Does another application depend on it?

  7. Is it still receiving security updates?

  8. Does it have an active owner?

  9. Has the application officially been retired?

  10. Are other security controls still active?

If the answer to the first few questions is yes, inactivity alone should not be treated as a reason to reduce security protection.

Scheduled Scanning vs Event-Based Scanning

Code scanning can be integrated into different development workflows.

An event-based approach might scan when code changes:

Pull Request
     |
     v
Code Scanning

A scheduled approach can scan periodically:

Scheduled Job
     |
     v
Code Scanning

A mature security program may use both.

Pull-request scanning helps prevent new problems from entering the codebase.

Scheduled scanning helps identify vulnerabilities that become known after the code was originally written.

This distinction is important because a vulnerability can be discovered long after the last code change.

Why Scheduled Scanning Still Matters

Consider this timeline:

January
Application released
       |
       v
June
New vulnerability discovered
       |
       v
July
Security advisory published

The application code did not change in June.

A pull-request-only security process may not automatically reanalyze the old code.

Scheduled scanning can provide another opportunity to detect issues that become known later.

This is one reason organizations should be careful when reducing scheduled scans for repositories that remain operationally important.

Best Practices

Track Repository Ownership

Every important repository should have a clear owner.

For example:

Repository: payments-api
Owner: Payments Engineering
Status: Production
Lifecycle: Active

This makes security decisions easier.

Track Application Deployment Status

Do not infer production status only from Git activity.

Maintain information about whether the repository is deployed.

Separate Repository Activity From Application Activity

A repository can be inactive while the application is active.

These are two different signals.

Use Repository Lifecycle Labels

Organizations can define categories such as:

Active
Maintenance
Inactive
Archived
Retired

Security policies can then be aligned with those categories.

Review Inactive Repositories Periodically

An inactive repository should not disappear from organizational awareness.

A periodic review can determine whether it should:

Protecting a Repository That Becomes Active Again

Suppose a repository has been inactive for several months.

Then a developer opens a new pull request.

The security process should make sure scanning is part of the workflow again.

A practical model is:

Inactive Repository
       |
       v
Development Resumes
       |
       v
Security Controls Re-enabled
       |
       v
Code Scanning
       |
       v
Review Findings
       |
       v
Merge

The team should not assume that old security results are still sufficient.

Security Debt in Inactive Repositories

Inactive repositories can accumulate security debt.

For example:

Repository created
      |
      v
Application deployed
      |
      v
Development slows
      |
      v
Security updates stop
      |
      v
Repository becomes inactive
      |
      v
Vulnerabilities accumulate

This can become dangerous if the application is still running.

Organizations should therefore distinguish between inactive development and retired software.

Troubleshooting Unexpected Scanning Behavior

If a repository is no longer being scanned as expected, check:

  1. Repository activity.

  2. Repository archival status.

  3. Code-scanning configuration.

  4. Workflow schedules.

  5. Workflow permissions.

  6. Branch configuration.

  7. Whether the repository is still considered active under the applicable policy.

  8. Whether the application is still deployed.

  9. Whether security monitoring exists elsewhere.

  10. Whether a recent repository change should have triggered scanning.

Also check the workflow execution history before assuming the scanner itself is broken.

Advantages

Better Resource Usage

Skipping unnecessary scans can reduce CI/CD and security-analysis workload.

Less Noise

Inactive repositories may produce fewer irrelevant security results when they are no longer actively maintained.

Easier Security Prioritization

Teams can focus more attention on actively developed software.

Better Repository Lifecycle Management

The change encourages organizations to think about which repositories are actually active and important.

Disadvantages and Risks

Inactive Code Can Still Be Vulnerable

Lack of development activity does not remove security risk.

Production Applications Can Look Inactive

A stable application may have few commits while still serving users.

Security Coverage Can Become Unclear

Teams may incorrectly assume that reduced scanning means reduced risk.

Repository Classification Requires Maintenance

Organizations need accurate information about repository status and ownership.

Newly Discovered Vulnerabilities Still Matter

A vulnerability can be discovered after the repository becomes inactive.

A Better Security Model

Instead of basing security entirely on repository activity, combine several signals:

Repository Activity
        |
        +---- Application Deployment
        |
        +---- Data Sensitivity
        |
        +---- Internet Exposure
        |
        +---- Repository Ownership
        |
        +---- Dependency Risk
        |
        v
Security Scanning Policy

This provides a more accurate picture of actual risk.

For example, an inactive internal prototype may need less scanning than an inactive production API handling sensitive data.

Production Checklist

Before reducing code-scanning coverage for an inactive repository, verify:

Summary

GitHub's approach to inactive repositories can help organizations use code-scanning resources more efficiently. Not every repository needs identical treatment, especially when thousands of repositories exist across a large organization.

However, repository inactivity should never be treated as proof that software is safe.

The most important distinction is between inactive development and inactive software. A repository may have no recent commits while its application is still running in production.

A mature security strategy should therefore combine repository activity with deployment status, ownership, application exposure, data sensitivity, and other risk signals.

Use reduced scanning for truly inactive or retired software according to your organization's security policy, but keep appropriate protection around applications that remain operational.

The goal is not to scan everything forever. The goal is to make sure important software continues to receive the security attention it needs, even when its Git activity is low.