The Risk Rancher Field Manual, Ch. 7: Getting It Fixed

September 20, 2026 · 6 min read · #security, #vulnerability-management, #risk-rancher, #remediation

Part of The Risk Rancher Field Manual, a hands-on guide to starting, scaling, and running a vulnerability management program.

A prioritized queue is not a fixed vulnerability. It is a to-do list, and to-do lists do not patch themselves. This chapter is the handoff and the follow-through: getting the right fix to the right person, with the right context, and then making sure the thing actually happened. We will do it on the finding you ranked first in the last chapter.

Assign it to a human

You already have what you need. From chapter two you know who owns the asset. From chapter three you know how to write a ticket an engineer will actually pick up. Put them together: the item at the top of your queue becomes a ticket, routed to the owning team, with the four questions answered, what it is, why this one, exactly what to do, and by when.

The template is short. This is all of ticket-template.md:

# Remediation ticket

**Title:** <one line a developer can act on, not the scanner's string>
**Asset:** <system / repo / image>
**Owner:** <the team or person who can actually fix it>
**Priority:** <P1 / P2 / P3 / P4 from triage>
**Due:** <date, from the SLA table: P1 3d, P2 14d, P3 30d, P4 90d>

## What is wrong
<plain language. what the finding is, on which asset.>

## Why it matters here
<the context that set the priority: exposure, asset criticality, KEV. not the CVSS alone.>

## How to fix it
<the specific action. version to upgrade to, config to change, code to patch.>

## How we will verify
<the exact check that proves it is fixed: a re-scan, a curl, a config read. trust but verify.>

## Evidence
<link to the finding, the scan, the proof of fix.>

The top of your answer key is F001, Log4Shell on payments-api, a P1. Here is that row poured into the template:

Notice the title. Not “CVE-2021-44228 Log4Shell RCE,” the scanner’s string, but the action: upgrade this library on this host. A developer reads that and knows what to do without a translation step.

And assign it to a person, not a queue and not a void. A finding addressed to “the infrastructure team” diffuses into nobody’s problem. A finding addressed to Dana, with Dana’s name on it, gets done. Ownership is not bureaucracy; it is the difference between a fix and a hope.

Set an honest SLA

Every item gets a deadline, tied to the priority you assigned in triage, not the raw CVSS the scanner shipped. Use the same clock the whole book uses:

The exact numbers matter less than that they exist, that you apply them consistently, and that there is authority behind them. (These are also Risk Rancher’s defaults, so the by-hand clock and the tool’s clock are the same one.)

And understand what an SLA is for. It is not a threat you wave at engineering. It is a promise, and a prioritization aid: it tells a busy engineer how this work ranks against everything else on their plate. Treat it that way and it becomes a tool you share with IT, instead of a stick you hit them with.

Trust, but verify

This is the most-skipped step in the entire discipline, and it is the one that separates a real program from a pretty dashboard.

When IT marks a finding “Resolved,” you do not take their word for it. You confirm with your own eyes that the hole is actually closed. For the Log4Shell ticket, the verify step is written right into the ticket above: re-scan the image and confirm the version is 2.17.1 or later. Not because people lie, almost nobody lies, but because “I applied the patch” and “the vulnerability is gone” are two different claims, and the gap between them is full of ways to fail. The patch did not take. The service never restarted. The fix went on staging instead of production.

A finding you marked closed without checking is not closed; it is worse than open, because now you believe a thing that is not true, and you have stopped watching it.

Five moves from a ranked finding to a fix you can believe. The last one is the one everyone skips.

Try it. Take the top three findings from your answer key, F001, F005, and F029, and write a ticket for each using the template. For every one, fill the last two rows honestly: the exact fix, and the exact check that proves it worked. If you cannot name the verify step, you do not understand the finding well enough to hand it off yet.

Straight talk. Risk Rancher creates the ticket, assigns it to the owner, sets the SLA clock from the severity, and gives the owner a link to update it. Then it does the verify step the honest way: it does not take “Resolved” as the end. When your next scan export comes in without that finding, the ticket closes as patched. If the finding shows up again in a later scan, the ticket reopens on its own. That is trust-but-verify built into the ingest, and it is free. The manual version is this entire chapter, and you should run it by hand first, because when a tool tells you something is closed, you want to already know what “closed” means and exactly what it checked before you believe it.

When it will not get fixed

Sometimes the fix breaks a critical business app. Sometimes there is no patch yet. Sometimes the team honestly cannot get to it inside the SLA. Look down your own queue: F010, TLS 1.0 on legacy-billing, is exactly that case, the full fix is a six-month refactor. That is not a failure of the program; it is reality, and reality has its own disciplined process, one that keeps you honest and keeps you out of trouble with the auditors. That is the next chapter: accepting reality, on the record.

← Back to the blog