CI platforms keep run history and logs for a limited time, so a trend chart built on live queries will lose its past. Export a small, structured record per security job into storage you control, and keep it for as long as your own policy says.
Why this bites
Teams build a dashboard that queries the CI API directly. It works for months. Then someone asks for a year over year comparison, or an auditor asks for evidence from a past period, and the older runs are gone or only partly available.
Platforms set their own limits. GitHub's documentation, for example, states that a workflow run can be re-run up to 30 days after its initial run, which is one visible sign that run data is not meant as a permanent archive. Check your own platform's retention settings for logs and artifacts, and note that administrators may be able to change them.
What to export
Do not archive full logs. Store a compact record per security job.
| Field | Why |
|---|---|
| Run identifier and link | To find the original while it exists |
| Repository and branch type | For slicing |
| Commit identifier | To tie results to a change |
| Start, queue and end times | For timing metrics |
| Outcome state and reason code | For gate and failure metrics |
| Counts by severity or level | For trends |
| Scanner, rule and data feed versions | To explain shifts |
| Exception or override reference | For audit trail |
Keep the record free of secrets and personal data. Findings details can stay in the scanner's own store, and the record can link to them.
How to export
- Add a final step to the security job that writes the record as JSON.
- Send it to a store you control, such as a database table, object storage or a metrics system, with the same credentials discipline as any pipeline output.
- Make the step run even when the scan fails, otherwise the worst runs are missing from your history.
- Add a nightly job that backfills runs the export step missed, while the platform still has them.
If your CI platform exposes an API for run history, a scheduled collector is a good safety net.
Retention policy
Choose retention on purpose.
- Operational metrics might need a year or two to show trends.
- Audit evidence may need to cover your whole audit period plus a margin. Ask your auditor or compliance lead what applies to you, and do not guess.
- Delete what you do not need, since stored data is also a liability.
Write the decision down with an owner and a review date.
Integrity
If records will serve as evidence, protect them from silent edits. Restrict who can write or alter them, log changes and keep timestamps from a trusted source. Evidence that anyone can quietly rewrite is weak evidence.
Quick check
Can't I just raise the platform retention?
That helps, but logs are bulky and may contain sensitive text. A compact exported record is cheaper and safer to keep for long periods.
Should failed scans be exported too?
Yes, especially. Missing failures make your history look healthier than it was.
How Safeguard fits
Safeguard includes compliance and evidence automation and continuous monitoring, so scan results and gate decisions can be kept as evidence tied to your controls. Try a free scan at gold.safeguard.sh/scan.
Sources
- GitHub Docs, Re-running workflows and jobs (30 day re-run window): https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/re-running-workflows-and-jobs
Last reviewed: 19 October 2026.
