Your CI system already records most of what you need: job start and end times, outcomes, retries and branch. Add a small results file from your scanner, collect both on a schedule, and store one row per run. That is enough for most security pipeline metrics.
What CI gives you for free
CI platforms track when a job was created, started and finished, which commit and branch it ran on, whether it passed and whether it was retried. GitLab's documentation notes that CI/CD analytics give a visual representation of pipeline health, that you can fetch specific pipeline health metrics from the API, and that external monitoring tools can poll the API to collect metrics. GitHub exposes workflow run and job data through its API too. The details differ, so read your own platform's API documentation.
What the scanner must add
CI cannot tell you what the scan found. Have the scanner emit a small summary file with:
- outcome code (clean, findings, policy, incomplete, error),
- counts by severity or level,
- scanner, rule and data feed versions,
- number of inputs scanned and skipped.
Attach it as a job artifact or send it straight to your store.
The pipeline for the data
- Emit. The security job writes the summary and uploads it, even when the scan fails.
- Collect. A scheduled script lists recent runs through the CI API and downloads each summary.
- Join. Combine CI facts (timing, retries, branch) with scanner facts (counts, versions) on the run identifier.
- Store. Write one row per run to a database table or a metrics system you control.
- Show. Point a dashboard at that table.
Run the collector more often than your CI retention allows, so nothing is lost before it is copied.
Which metrics you can build
| Metric | Source |
|---|---|
| Queue time and run time | CI timestamps |
| Median and high percentile scan time | CI timestamps |
| Re-run rate | CI attempts per commit |
| Gate outcome mix | Scanner summary |
| Findings introduced per change | Scanner summary against a baseline |
| Coverage | List of repositories versus runs found |
| Time to unblock | CI results plus change records |
Practical advice
- Use one identifier throughout, the CI run id, so joins are simple.
- Keep secrets out of the summaries and out of the store's access list.
- Version your schema, and add fields rather than renaming them.
- Start with three metrics, run them for a month and add more only if someone asks.
- Be honest about gaps: a missing run is a gap, not a zero.
When a tool is worth it
If you manage many repositories, need long retention with access control, or want results correlated across tools, a platform built for the job can save effort. Decide that after you have learned which metrics your team actually uses.
Quick check
Do I need a data warehouse?
No. A single database table or even a spreadsheet exported daily works for a small team.
What about private repositories and permissions?
Give the collector a read only credential scoped to run data, store it as a secret and review it like any other pipeline credential.
How Safeguard fits
Safeguard provides dependency and SBOM scanning, policies and gates and compliance evidence automation, so you can compare what you build yourself against a ready made view. Run a free scan at gold.safeguard.sh/scan.
Sources
- GitLab Docs, Pipeline efficiency (CI/CD analytics, pipeline health metrics from the API, external monitoring): https://docs.gitlab.com/ci/pipelines/pipeline_efficiency/
Last reviewed: 19 October 2026.
