Remediation metrics
Remediation metrics show whether the triage and fix features are doing their job for your organisation. The page measures the success metrics of reachability and Security fixes on your own findings, over the last 30 or 90 days, and compares each period with the same number of days just before it.
Find it at Security › Reports › Remediation metrics
(/<org>/_admin/security/reports/remediation). Org owners and members of the
org’s Auditors team can open it. Choose Last 30 days or Last 90 days at
the top of the page.
Every number is about your organisation only. Nothing is compared with or computed from other organisations.
The same page has the Contribute anonymous counts card: an opt-in, off by default, that adds your organisation’s counts, anonymously, to the numbers fremforge publishes. See Anonymous counts.
What it shows
| Section | What it shows |
|---|---|
| Reachability | Open dependency findings per ecosystem, split by verdict: reachable, not reachable (unreachable) and unknown. Coverage is the share with a verdict other than unknown. No call path share is the share where the engine found no path from your code to the vulnerable function. The targets are 60 % coverage for Go and 30 % for npm, and 30 % not reachable for Go. Ecosystems without an engine are marked. |
| Coverage trend | Coverage and not-reachable share per day, from a daily snapshot of your organisation’s own findings. The snapshot started on 2026-10-14, so the chart fills in from then; until two days are stored the panel says it is collecting. |
| Security fix pull requests | Per engine, deterministic (dependency bumps) and AI-assisted (SAST, with your own model key): requests made in the period, pull requests opened, merged, closed and still awaiting review, and the merge rate (merged divided by opened). The targets are 70 % for deterministic and 40 % for AI-assisted pull requests. |
| Findings fixed by a security fix | Findings that a scan stopped reporting after their security fix pull request merged, per type and per day. The API also returns findings_fixed_by_renovate: findings whose package one of hosted Renovate’s own security pull requests bumped while they were open (counted from 2026-10-14). |
| Time to fix | The median number of days from when a high or critical dependency finding was first seen to when a scan no longer reported it. This period against the previous one, and within this period, fixed by AutoFix against fixed another way. |
| Known exploited | Open dependency and container image findings whose vulnerability is listed as exploited by ENISA’s EU Vulnerability Database or CISA’s Known Exploited Vulnerabilities catalogue, with links to the filtered finding lists. |
| SLA breaches | Per day, the findings of every scanner open past their SLA, all severities and high and critical, and the new breaches per day. Totals for this period and the previous one. |
How the numbers are made
- Unique findings. A dependency finding is one per repository, package and advisory, however many branches or pull requests report it. The open dependency findings are counted the same way on every day of the trend.
- The daily snapshot is taken once a day for your organisation only, from the same count as the coverage figures above, and is never combined with other organisations’ data. It is kept as long as your findings history setting when you have set one, otherwise for 18 months, and is deleted when your organisation is deleted. A legal hold keeps it.
- Verdicts are not dismissals. A finding that is not reachable stays open and is counted as open everywhere. See reachability.
- Security fix pull requests are counted by the date the fix was requested. A pull request still awaiting review lowers the merge rate until it is merged or closed.
- Time to fix and SLA breaches come from the finding history, which starts when your organisation’s history tracking started (the page states the date). A finding already open on that date counts from when it was first stored.
- SLA deadlines are the same effective deadlines as the SLA pills and the compliance report, including a longer SLA for findings that are not reachable when your SLA policy sets a multiplier. A finding breaches its SLA when the deadline passes while it is neither fixed nor dismissed.
API
The same numbers are available from the API with a token that has the
findings:read scope:
curl -H "Authorization: Bearer $FREMFORGE_TOKEN" \
"https://frem.sh/_app/api/v1/orgs/<org>/code-security/remediation-metrics?days=30"days is 30 (the default) or 90. The response has the sections above as
reachability, autofix, time_to_fix, known_exploited and sla, plus the
window and the targets. Percentages are numbers from 0 to 100 with one
decimal, or null when there is nothing to divide by. See the
OpenAPI spec for the schema.