# Planning and measuring remediation

Remediation means changing a system so the reported issue no longer applies. The Remediation chapter groups findings into practical work, then shows progress where the source supplies enough history to measure it.

## Findings, fixes and workstreams

These are different levels:

```text
Several findings → one fix → a workstream of similar changes
```

For example, several findings on one dependency may be addressed by one package update. That fix belongs to **Update dependencies**. The number of findings is not the number of tickets or changes you need.

## Plan

The app has seven workstreams:

| Workstream | Typical work |
| --- | --- |
| Update dependencies | Move affected packages to an appropriate fixed version |
| Fix cloud configuration | Correct a resource or account configuration |
| Rebuild container images | Refresh and deploy an image containing the fix |
| Harden external hosts | Address externally visible service or host exposure |
| Patch hosts | Apply the relevant host or operating-system remediation |
| Fix code | Change the affected application logic |
| Other fixes | Findings outside the other categories |

Open a workstream to see its largest fixes. Compare open findings, breached deadlines and distinct fixes before choosing work. Volume alone does not account for exposure or impact.

## How fixes are grouped

A fix is identified by its workstream, scope and fix title. Dependency, code and image fixes use the target as scope; other workstreams can group the same fix across targets. The owner team is not part of the fix identity.

That means one fix can span teams. Check the affected targets and ownership before [filing its Jira ticket](/docs/secops/tickets): a mixed-team fix uses the fallback project rather than automatically selecting one team.

## Progress

**Progress** compares findings found and fixed, time to fix, how many were fixed within their deadline, weekly movement and team results. Read the period and source coverage before interpreting a trend.

Timing measures use resolved findings with a known fixed date, looking back 90 days. Per-severity time-to-fix values are medians. The overall time-to-fix summary combines those medians weighted by their finding counts, so it is not an exact median of every individual duration.

GitHub scratch findings currently have no fixed date in the app model. Those resolutions do not contribute to fixed-per-week or time-to-fix measures. An empty timing chart therefore does not prove no work was completed. Target-specific historical trends are also unavailable, so not every measure follows every filter in the same way.

For example, if you fixed ten dependency alerts in GitHub but the app lacks their resolution dates, the open backlog can shrink while the timing view cannot describe how quickly those ten were fixed.

## Exceptions

The **Exceptions** view lists decisions to accept risk or classify false positives, with their reasons and recheck dates. Read [Exceptions](/docs/secops/exceptions) to understand why those counts are separate from verified remediation.

## A useful review

Pick a small set of fixes, confirm their owners and deadlines, and verify the scanner's result after deployment. Compare progress only across periods and sources with comparable coverage. Avoid treating a team's backlog count as a ranking of its performance.