Dependabot alerts are useful because they help development teams identify vulnerable dependencies in their repositories. But security data also needs a clear retention policy.

GitHub is changing how long certain closed Dependabot alerts are retained. For teams that rely on Dependabot for vulnerability tracking, reporting, audits, or historical analysis, this makes it important to understand what happens after an alert is closed.

The key distinction is between an alert being closed and the underlying security information being retained indefinitely.

Developers and repository administrators should understand the retention behavior before relying on closed alerts as a permanent security history.

What Is a Dependabot Alert?

Dependabot alerts identify dependencies that GitHub associates with known security vulnerabilities.

For example, a .NET project might contain:

<ItemGroup>
    <PackageReference Include="Example.Package" Version="1.2.0" />
</ItemGroup>

If that package version is associated with a known vulnerability, Dependabot may raise an alert.

A simplified workflow looks like this:

Repository
    |
    v
Dependency Graph
    |
    v
Vulnerability Information
    |
    v
Dependabot Alert
    |
    v
Developer Investigation
    |
    v
Update Dependency
    |
    v
Alert Closed

Closing the alert means the repository no longer needs the alert in its active state.

It does not necessarily mean that every associated record remains available forever.

Why Alert Retention Matters

Security teams often use historical alerts for more than immediate remediation.

They may need to answer questions such as:

When was this vulnerability detected?

When was it fixed?

Which repository was affected?

How many alerts were open?

Which dependencies caused recurring problems?

If historical alert information is removed after a defined retention period, teams may no longer be able to answer these questions directly from the GitHub interface or API.

This is why retention should be considered part of a broader security-record strategy.

Open Alerts and Closed Alerts Are Different

The important distinction is the state of the alert.

Open Alert
    |
    v
Investigation
    |
    v
Dependency Updated
    |
    v
Closed Alert

An open alert represents an unresolved security finding.

A closed alert represents an alert that has been resolved or otherwise closed according to the repository's workflow.

Retention policies can treat these states differently.

Therefore, teams should not assume that a closed alert has the same availability as an active alert.

What Does "Retention" Mean?

Retention describes how long information remains available after it reaches a particular state.

For example:

Alert Created
     |
     v
Alert Open
     |
     v
Alert Closed
     |
     v
Retention Period
     |
     v
Data Removed

The exact retention period and behavior depend on GitHub's current policies and the relevant alert type.

For teams affected by a policy change, the important action is to verify the current GitHub documentation and account behavior rather than assuming closed alerts remain permanently accessible.

Why Security Teams Should Care

Consider an organization with thousands of repositories.

Over time, its security history might look like:

2024
  |
  +-- Vulnerability A
  +-- Vulnerability B
  |
2025
  |
  +-- Vulnerability C
  +-- Vulnerability D
  |
2026
  |
  +-- Vulnerability E

If closed alert records are retained for only a defined period, historical reporting becomes dependent on whatever information the organization has exported or stored separately.

This can affect:

  • Internal security reporting

  • Compliance evidence

  • Incident investigations

  • Vulnerability trend analysis

  • Engineering metrics

  • Security audits

Should You Treat GitHub as Your Long-Term Security Archive?

Not necessarily.

GitHub's security features are designed to help manage vulnerabilities, but organizations with long-term reporting requirements may need their own security-data retention strategy.

For example:

GitHub
   |
   v
Dependabot Alerts
   |
   +----> Active Remediation
   |
   +----> Security Data Pipeline
                |
                v
          Long-Term Storage

The exact architecture depends on the organization's requirements.

The important principle is to distinguish between:

Security management

and

Long-term security record retention.

They are related, but they are not necessarily the same system.

What Should Teams Preserve?

If your organization needs historical vulnerability information, consider preserving the information required for future investigations.

Useful fields can include:

Information

Why It Matters

Repository

Identifies affected project

Dependency

Identifies vulnerable component

Vulnerability identifier

Connects finding to vulnerability record

Alert state

Shows whether it was active or closed

Detection date

Establishes timeline

Resolution date

Measures remediation

Affected version

Identifies vulnerable release

Fixed version

Records remediation target

Severity

Supports prioritization

Advisory information

Provides technical context

The exact fields available depend on the GitHub feature and API being used.

Exporting Security Data

Organizations that require longer retention can periodically export relevant security information into an approved internal system.

A conceptual workflow is:

GitHub
   |
   v
Security API / Export
   |
   v
Security Data Store
   |
   +--> Reporting
   +--> Auditing
   +--> Historical Analysis

This allows teams to maintain their own historical record instead of depending entirely on the retention behavior of a hosted platform.

The implementation should follow the organization's security and data-retention policies.

Example: Tracking a .NET Dependency

Suppose a C# project contains:

<ItemGroup>
    <PackageReference Include="Example.Library" Version="4.1.0" />
</ItemGroup>

A vulnerability is identified in that version.

The development team updates the dependency:

<ItemGroup>
    <PackageReference Include="Example.Library" Version="4.2.0" />
</ItemGroup>

The Dependabot alert can then move through the appropriate remediation workflow.

A security record might capture:

Repository: ExampleApi
Package: Example.Library
Previous Version: 4.1.0
Fixed Version: 4.2.0
Detected: [date]
Resolved: [date]
Status: Closed

The organization can retain this information independently if its policies require long-term historical records.

Closed Does Not Mean "No Longer Important"

A closed alert may still be useful for understanding the security history of a project.

For example:

Current Dependencies
        |
        v
No Active Alert
        |
        X
        |
Historical Security Record

A dependency can be secure today while still having had a vulnerability in the past.

Historical information can help explain:

  • Why a dependency was upgraded

  • How quickly the team responded

  • Whether the same component has recurring issues

  • Whether a repository repeatedly introduces vulnerable versions

Retention and Audit Requirements Are Different

Security teams should distinguish between platform retention and organizational requirements.

For example:

GitHub Retention Policy
        |
        v
What GitHub keeps

Organization Policy
        |
        v
What the organization needs to retain

The organization may need records for a longer period than the platform provides.

If so, the organization needs another mechanism for preserving those records.

The appropriate retention period depends on business requirements, contractual obligations, applicable regulations, and internal security policies.

What Happens When a Record Is Deleted?

The important question is not simply:

Is the alert closed?

It is:

What information remains available after the retention period?

Teams should understand whether historical data is:

  • Removed from the user interface

  • Removed from APIs

  • Removed from indexes

  • Retained in another form

  • Available only through exported records

Do not assume that data visible today will remain available indefinitely.

Common Mistakes

Assuming Closed Alerts Are Permanent

A closed state does not automatically imply indefinite retention.

Using GitHub as the Only Security Archive

Organizations with long-term historical requirements may need independent storage.

Waiting Until an Audit

Retention requirements should be addressed before historical records are needed.

Exporting Only Alert Counts

A count such as:

Closed alerts = 127

is not enough to reconstruct security history.

Preserve the fields required by the organization's reporting needs.

Ignoring API Access

If historical reporting depends on API data, teams should verify how retention changes affect API availability.

Confusing Current Security With Historical Security

A repository without active alerts does not mean it never had security issues.

Best Practices for Dependabot Alert Retention

Define What Security History You Need

Decide which information should remain available after alerts are closed.

Determine the Required Retention Period

Align retention with organizational, legal, contractual, and audit requirements.

Export Important Security Data

If GitHub's retention does not meet those requirements, store the necessary information in an approved internal system.

Automate Where Appropriate

A scheduled process can collect relevant security information before it falls outside the platform's retention window.

Protect Historical Data

Security history can itself contain sensitive repository information. Apply appropriate access controls.

Test Your Reporting Pipeline

Do not assume that an export works simply because the API call succeeds.

Verify that the resulting records can actually answer the questions your security team needs.

A Practical Security-Data Workflow

A simple architecture could look like this:

GitHub Repository
       |
       v
Dependabot
       |
       v
Security Alert
       |
       +----> Engineering Remediation
       |
       +----> Security Data Collection
                    |
                    v
              Internal Storage
                    |
          +---------+---------+
          |                   |
          v                   v
       Reporting            Audit

This separates day-to-day vulnerability remediation from long-term historical retention.

Advantages of Independent Retention

Maintaining an internal security history can provide:

  • Longer retention

  • Organization-specific reporting

  • Historical trend analysis

  • Centralized security records

  • Better control over audit evidence

  • Consistent reporting across multiple repositories

Disadvantages and Trade-Offs

Independent retention also introduces additional responsibilities:

  • Storage costs

  • Data protection requirements

  • API maintenance

  • Data normalization

  • Access control

  • Monitoring

  • Backup requirements

The organization becomes responsible for protecting the historical data it chooses to retain.

Troubleshooting Missing Historical Alerts

If a previously closed Dependabot alert is no longer visible:

  1. Confirm the repository and dependency.

  2. Check whether the alert is still within the applicable retention period.

  3. Check whether the alert was closed, dismissed, or otherwise changed state.

  4. Review available security APIs.

  5. Check internal security-data exports.

  6. Search centralized security or SIEM records if applicable.

  7. Review previous reports or audit records.

  8. Check repository-level security permissions.

  9. Verify whether the data was retained elsewhere.

  10. Update the organization's retention process if the required historical information is unavailable.

Avoid assuming that a missing alert means the vulnerability never existed.

Summary

Dependabot alerts are useful for identifying and remediating vulnerable dependencies, but closed security alerts should not automatically be treated as permanent historical records.

Changes to alert retention make it important for organizations to understand exactly what happens to closed alerts over time and whether the available retention period meets their security, audit, compliance, and reporting requirements.

For teams that need long-term vulnerability history, an independent security-data retention process can preserve important information such as repository, dependency, vulnerability identifier, detection date, resolution date, affected version, and fixed version.

The main lesson is simple: use Dependabot to manage vulnerabilities, but do not assume that a hosted security tool is automatically your permanent security archive.