Closing a Dependabot alert usually means the vulnerability has been addressed or the alert no longer requires active remediation.
But closing an alert raises another practical question:
How long should the security record remain available?
For a small project, this may not seem important. For organizations managing hundreds or thousands of repositories, historical vulnerability data can become valuable for audits, incident investigations, security reporting, and dependency management.
The answer is not simply "keep everything forever."
A useful retention strategy should balance security history, business requirements, compliance needs, storage, privacy, and operational effort.
Why Closed Dependabot Alerts Still Matter
Consider a dependency vulnerability that was discovered in an application.
The development team updates the package:
Vulnerable Version
|
v
Dependabot Alert
|
v
Dependency Update
|
v
Alert ClosedThe alert is no longer active, but its history can still answer important questions.
For example:
When was the vulnerability detected?
How quickly was it fixed?
Which version was affected?
Which version resolved it?
Was the same dependency vulnerable again later?This information can be useful even after the active security issue is gone.
What Does Alert Retention Actually Mean?
Retention is the period for which security information remains available after a particular event or state change.
A simplified lifecycle looks like this:
Alert Created
|
v
Alert Open
|
v
Investigation
|
v
Dependency Updated
|
v
Alert Closed
|
v
Retention Period
|
v
Historical Record RemovedThe exact retention behavior depends on the platform and security feature being used.
Therefore, teams should verify the current GitHub behavior instead of assuming that closed alerts remain available indefinitely.
There Is No Universal Retention Period
A common mistake is to ask:
What is the correct number of years?
There is no single answer that applies to every organization.
A startup maintaining a public application may have very different requirements from:
Financial services
Healthcare
Government
Enterprise software
Regulated infrastructureRetention should be based on the organization's actual requirements.
A useful decision model is:
Business Requirements
+
Security Requirements
+
Audit Requirements
+
Legal / Contractual Requirements
+
Platform Capabilities
|
v
Retention PolicySecurity Retention vs Platform Retention
These are two different concepts.
Platform Retention
This answers:
How long does GitHub keep the information available through its services?
Organizational Retention
This answers:
How long does our organization need to preserve the information?
For example:
GitHub
|
v
Platform Retention
|
X
Data no longer availablewhile the organization may require:
GitHub
|
v
Security Data Collection
|
v
Internal Security Archive
|
v
Long-Term RetentionIf organizational requirements exceed platform retention, another storage mechanism may be necessary.
What Information Should You Keep?
Keeping only a total alert count is usually not enough.
For example:
Closed Dependabot Alerts: 248does not tell a security team much about what actually happened.
A more useful historical record can contain:
Field | Purpose |
|---|---|
Repository | Identifies the affected project |
Dependency | Identifies the vulnerable component |
Vulnerability ID | Identifies the security issue |
Severity | Supports historical prioritization |
Affected version | Records the vulnerable release |
Fixed version | Records the remediation |
Alert state | Shows lifecycle status |
Detection date | Establishes when it was identified |
Resolution date | Establishes when it was addressed |
Advisory details | Provides technical context |
The exact fields available depend on the GitHub feature and integration being used.
Why Resolution Time Is Useful
Security teams often want to measure how quickly vulnerabilities are addressed.
For example:
Detected
|
| 3 days
v
FixedThis provides a remediation interval.
Over time, an organization could analyze:
Vulnerability
|
+--> Detection
+--> Investigation
+--> Dependency Update
+--> Verification
+--> ClosureHistorical alert data can therefore support security-process analysis.
Example With a C# Project
Suppose a .NET application uses:
<ItemGroup>
<PackageReference Include="Example.Library" Version="5.1.0" />
</ItemGroup>A vulnerability is identified in version 5.1.0.
The team updates the package:
<ItemGroup>
<PackageReference Include="Example.Library" Version="5.2.0" />
</ItemGroup>After validation, the Dependabot alert is closed.
A useful historical record could look like:
Repository: OrderApi
Dependency: Example.Library
Affected Version: 5.1.0
Fixed Version: 5.2.0
Status: Closed
Detected: [date]
Resolved: [date]Even though the alert is no longer active, this information can explain why the dependency changed.
Why Historical Dependency Data Helps
Suppose the same dependency produces another vulnerability later.
Without history:
New Alert
|
v
Investigate From ScratchWith historical data:
New Alert
|
v
Previous Vulnerability History
|
v
Compare RemediationHistorical information can help teams understand recurring dependency problems and identify components that repeatedly require security attention.
Retention Can Support Incident Investigations
Imagine a security incident involving a vulnerable package.
The investigation may ask:
Was this package used before?
When was the vulnerability first detected?
Which repositories were affected?
When was the package upgraded?
Was the vulnerable version deployed?Current dependency state may not answer all of these questions.
Historical security records can provide additional evidence.
However, Dependabot history alone should not be treated as a complete incident record. Deployment systems, source control, CI logs, artifact repositories, and other systems may also be required.
Compliance Can Change the Requirement
Some organizations have formal requirements for retaining security and audit records.
The relevant period may depend on:
Industry
Jurisdiction
Contract
Internal policy
Audit requirements
Security program requirements
Therefore, developers should not choose a retention period based only on convenience.
Security and compliance teams should define the applicable requirements.
Should You Keep Everything Forever?
Usually, "keep everything forever" is not a complete retention strategy.
Long-term storage also creates responsibilities.
Historical security data can contain:
Repository names
Dependency information
Internal project details
Security findings
Development timelinesKeeping this information indefinitely can increase the amount of sensitive data that must be protected.
A good retention policy therefore asks both:
How long do we need this information?and:
When should we securely remove it?A Practical Retention Model
An organization can classify security information into different retention periods.
For example:
Active Security Data
|
v
Operational Retention
|
v
Historical Security Records
|
v
Long-Term Audit Records
|
v
Secure DisposalThe actual periods should be determined by the organization's requirements rather than copied from an arbitrary example.
What Should Be Exported?
If the organization needs historical records beyond the platform's available retention, it can collect relevant information through approved APIs or security-data pipelines.
A simplified process is:
GitHub
|
v
Security Data Collection
|
v
Normalization
|
v
Internal Security Store
|
+--> Reports
+--> Dashboards
+--> Audit
+--> InvestigationsThe data collection process should itself be protected.
Security data should not be copied into an uncontrolled spreadsheet or shared location simply to extend retention.
Protect the Security Archive
A long-term vulnerability archive can become a sensitive system.
Use appropriate controls for:
Access
Only authorized users should be able to retrieve historical security records.
Encryption
Protect data both during transmission and while stored.
Backups
If historical records are important, backups should be part of the retention design.
Audit Logging
Track access to sensitive historical security information where appropriate.
Data Disposal
When records reach the end of their required retention period, remove them according to the organization's disposal policy.
Closed Alerts Should Not Be Used as the Only Evidence
Suppose an alert was closed because a dependency was upgraded.
That does not necessarily prove that the vulnerable version was never deployed.
Other evidence may be needed:
Dependabot
+
Git History
+
CI Records
+
Artifact Repository
+
Deployment RecordsTogether, these can provide a more complete timeline.
This distinction matters during security investigations.
Common Mistakes
Choosing a Retention Period Without Requirements
A random number of months or years may not satisfy business or compliance needs.
Assuming GitHub Keeps Everything Forever
Hosted services have their own retention behavior.
Saving Only Alert Counts
Counts do not preserve enough information for detailed investigations.
Keeping Security Data Indefinitely Without a Policy
Long-term retention also creates privacy and security responsibilities.
Storing Exports in Unprotected Files
Security records should receive appropriate access controls.
Ignoring API Availability
If historical reporting depends on an API, verify that required data remains accessible through that interface.
Treating Closed Alerts as Deployment Evidence
A closed alert shows security-alert lifecycle information, not necessarily the complete deployment history.
Best Practices for Dependabot Alert Retention
Define the Business Requirement
Ask what historical questions the organization needs to answer.
Define the Security Requirement
Determine which vulnerability information needs to remain available for investigations.
Check Compliance Requirements
Security and compliance teams should identify applicable obligations.
Understand Platform Retention
Know what GitHub retains and for how long under the relevant security feature.
Export Critical Information
If the required retention period is longer, preserve the necessary information in an approved system.
Automate Collection
Manual exports are difficult to maintain across many repositories.
Protect Historical Records
Use appropriate authorization, encryption, monitoring, and backup controls.
Review the Policy Periodically
Platform behavior and organizational requirements can change.
A Simple Retention Architecture
A practical architecture might look like this:
GitHub Repositories
|
v
Dependabot Alerts
|
+-------------------+
| |
v v
Remediation Data Collection
|
v
Security Archive
|
+---------+---------+
| |
v v
Reporting AuditThis allows GitHub to remain the operational security tool while a separate system handles long-term historical requirements.
Advantages of Longer Retention
Longer retention can provide:
Better historical security visibility
More useful audit evidence
Improved vulnerability trend analysis
Easier incident investigation
Better understanding of dependency history
More complete security reporting
Disadvantages of Longer Retention
Longer retention also means:
More storage
More sensitive information to protect
Higher maintenance requirements
Additional access-control requirements
More complicated data-management processes
Potentially greater privacy exposure
Retention should therefore be intentional.
How to Decide Your Retention Period
Use a structured process:
Identify the security information you need.
Identify audit and compliance requirements.
Check the platform's retention capabilities.
Determine whether those capabilities meet your requirements.
Identify information that must be retained separately.
Define access controls for retained records.
Define backup and recovery requirements.
Define the final disposal process.
Automate collection where practical.
Review the policy periodically.
This produces a defensible retention strategy instead of an arbitrary number.
Troubleshooting Missing Closed Alerts
If a historical Dependabot alert is no longer available:
Confirm the repository.
Identify the dependency and vulnerability.
Check the alert's previous state.
Determine when it was closed.
Check whether it falls outside the applicable retention period.
Review internal security exports.
Search security reporting systems.
Review Git history for the remediation.
Check CI and deployment records if necessary.
Update the retention process if required historical information was not preserved.
A missing alert should not automatically be interpreted as evidence that no vulnerability existed.
Summary of the Article
There is no universal answer to how long closed Dependabot alerts should be retained. The right period depends on the organization's security requirements, business needs, audit expectations, applicable regulations, contractual obligations, and the retention capabilities of the platform.
Closed alerts can remain valuable because they provide historical information about vulnerabilities, affected dependencies, remediation activity, and security timelines. However, organizations should not assume that a hosted security platform is a permanent archive.
For teams that need longer-term records, the practical approach is to define the required security history, understand GitHub's retention behavior, and preserve necessary information in an approved security-data store when required.
The goal is not to keep every security record forever. The goal is to retain the right information for the right amount of time, protect it while it is retained, and dispose of it when the retention requirement ends.
Join the conversation! Your thoughts help the community grow.