GitHub Dependabot Closed Alerts: September 25 Retention Change Checklist

Work from the safest step to the harder repair.

1. Step 1. Inventory every workflow that reads closed Dependabot alerts: scheduled API exports, SIEM ingestion, audit evidence jobs, compliance dashboards, incident-response scripts and data-warehouse pipelines. Record whether any query expects alerts closed more than two years ago.
2. Step 2. Before September 25, run representative queries against the current Dependabot REST API and document the historical range your systems actually consume. Do not assume a job only needs recent data because its present result set happens to be small.
3. Step 3. Separate operational alert monitoring from historical evidence. Continue to use the normal UI/API for open alerts and closed alerts inside the two-year window; plan an archive workflow only where older closed-alert history has a real audit, regulatory, forensic or reporting purpose.
4. Step 4. For older closed alerts, use GitHub's supported downloadable CSV archive from the security-alerts page at the applicable enterprise, organization or repository level. GitHub says administrators and security managers can download archived alerts there after they leave the ordinary UI/API.
5. Step 5. Update downstream logic so an API result that no longer includes a two-plus-year-old closed alert is treated as an archival boundary, not automatically as deletion, remediation failure or proof the alert never existed.
6. Step 6. Preserve record identity when moving data into an internal archive or evidence store. Keep the repository/organization context, alert identifiers, timestamps and remediation state needed by the consuming process without copying unrelated secrets or access tokens into the export workflow.
7. Step 7. Review access controls for exported CSV files. Historical security alerts can contain sensitive repository, dependency and vulnerability context even though they are not credentials; store exports only where authorized security, audit or compliance users can retrieve them.
8. Step 8. Do not build a permanent bulk-export process unless the organization actually needs historical data outside GitHub. GitHub says archived alerts stay at full fidelity for the life of the account, so avoid duplicating sensitive security data merely because export is possible.
9. Step 9. Account for deletion boundaries. GitHub says alert data is removed when the associated repository, organization or account is deleted, or when an enterprise agreement ends; an archive plan cannot rely on records remaining in GitHub after those lifecycle events.
10. Step 10. Keep GitHub Enterprise Server separate. The September 25 policy does not apply to GHES according to GitHub's announcement; verify GHES release documentation independently before changing self-hosted retention assumptions.
11. Step 11. Recheck GitHub's changelog before expanding this workflow to code scanning, secret scanning or other alert types. GitHub says Dependabot is first and that later security-alert retention changes will be announced with at least 60 days' advance notice.

Need the actual code? Go to GenesisCodeDoctor.com to search the Code Store or request code for the exact platform, error, and repair you are working on.

Protect the working site first.

• Use least-privilege credentials for pre-change API inventory and never print access tokens in logs, tickets or examples.
• Keep historical CSV exports in approved access-controlled storage and apply the organization's retention policy rather than leaving ad hoc local copies.
• Test reporting and API jobs with known old and recent closed-alert cases so the archival boundary cannot silently turn into a false zero-count or false deletion signal.

Do not turn a repair into a larger outage.

• Do not interpret an older closed alert disappearing from the normal UI/API after September 25 as evidence that GitHub deleted the historical record.
• Do not claim the September 25 policy applies to GitHub Enterprise Server; GitHub explicitly excludes GHES from this rollout.
• Do not publish exported security-alert CSV files or attach them to public issues, chat threads or documentation.
• Do not bulk-copy archived alerts into another system without a defined audit, compliance, forensic or reporting need and appropriate retention/access controls.
• Do not assume all GitHub security-alert types switch on September 25; GitHub says Dependabot is first and later types will have separate advance notice.

Diagnose the exact failure before choosing a repair.

Genesis separates the visible symptom from the underlying technical cause. Run the supported diagnostic first, review the evidence, and then use a matching repair only when the failure is actually verified.

Platform scope

GitHub.com · GitHub Enterprise Cloud · Dependabot security alerts · REST API · compliance reporting

Category

GitHub security · Dependabot · Data retention

Last updated

2026-09-22

Know the complexity before you edit.

Difficulty

Intermediate

Change risk

Medium

These labels describe implementation complexity and blast radius, not a guaranteed repair time.

Verify time-sensitive platform details at the source.

• GitHub Changelog — Upcoming cloud data retention policy for closed security alerts (June 30, 2026)
• GitHub Docs — REST API endpoints for Dependabot alerts

Before you make the change

Continue from easy to harder.

• GitHub Enterprise Credential Inventory: Export & Incident Checklist
• GitHub Actions Node 20 Removal: Node 24 Migration Checklist
• API Connected? Use This Go-Live Checklist Before You Press Publish
• API Key vs. Secret Key: What You Can Show an AI — and What You Never Should