The Risk Rancher Field Manual, Ch. 3: Don't Throw PDFs Over the Fence
Part of The Risk Rancher Field Manual, a hands-on guide to starting, scaling, and running a vulnerability management program.
Here is a fact that no tool will fix for you: you do not fix vulnerabilities. Somebody else does. You find the hole; an engineer, a sysadmin, a platform team closes it. Which means your entire program, every scanner and score and SLA, ultimately runs on one thing you cannot buy: whether the people holding the wrenches are willing to pick them up when you ask.
If they hate you, they will not. And they will be right to.
How security earns its reputation
Picture the standard move. The security team runs a scan, exports the result, and emails engineering a three-hundred-page PDF with four thousand findings sorted by a severity score the engineers did not choose and do not trust. Attached is a note: “Please remediate the Criticals by end of quarter.” Then the security team goes back to its dashboard, satisfied that the work has been “handed off.”
From the other side of the fence, here is what just happened. Someone who does not know your system, has never run your deploy, and does not share your deadline just dropped an unsortable wall of homework on your desk and told you to drop everything. Half of it is false positives. A third of it is on systems you decommissioned last year. The “Critical” at the top is a theoretical issue on an internal tool nobody can reach. And there is no way to tell which of the four thousand is the one that actually matters.
So the engineer does the rational thing. They close the email. They learn that security’s output is noise, and they tune you out. Now every real finding you send after that lands in the same ignored pile as the garbage. You did not just waste that one report. You spent down the trust you needed for the entire program, and you will not get it back by sending a bigger PDF.
The fence is the problem
The whole “throw it over the fence” posture is the bug. It casts security as the Department of No, an external body that shows up to grade everyone else’s homework and then leaves. Nobody collaborates with the grader. They either ignore you or they route around you.
The rancher does the opposite. You do not stand at the fence; you walk through the gate. You learn how the builders actually work, where their tickets live, what their sprint looks like, what “done” means to them. You find out that the reason the patch did not get applied was not laziness, it was that applying it breaks an integration, and nobody told you because you never asked. Your job is not to hand them more problems. It is to remove the friction between a problem and its fix. Provide the iron and the tack, not another stack of reports.
Write the ticket you would want to receive
Most of this comes down to the quality of a single artifact: the ticket. A good vulnerability ticket is not a scanner finding copy-pasted into Jira. It is a small act of empathy. It answers, before the engineer has to ask, the four questions every engineer asks:
- What is it, in one plain sentence? Not the CVE boilerplate. “The version of this library we use has a flaw that lets an attacker run their own code on this server.”
- Why do I care about this one? The context. “This is on the public-facing payments app, so it is actually reachable, which is why it is near the top of your list and not the forty others.”
- Exactly what do I do? The fix, as specifically as you can make it. “Upgrade the library from 2.4.1 to 2.4.6. No API changes. Here is the diff.” If you can open the pull request yourself, open it.
- By when, and says who? The deadline and the authority behind it. “Due in 30 days per our policy,” not “ASAP.”
A ticket like that is one an engineer can pick up and close on their lunch break. A ticket that is just “CVE-2024-XXXX, CVSS 9.8, remediate” is one they will push to the bottom of the pile forever, and you will spend your week nagging instead of ranching.
Before and after
Here is a finding from the sample file you will triage later, F023, as the scanner shipped it:
OpenSSL SM2 buffer overflow. CVE-2021-3711. CVSS 9.8. Asset: customer-db. Remediate.
Now the same finding, written for the human who has to fix it:
Upgrade OpenSSL on customer-db to 1.1.1l or later. The version on our primary customer database has a flaw (CVE-2021-3711) that can crash it or possibly let an attacker run code. It holds customer PII, which is why this one is near the top of your list and not the forty others. Upgrade the OpenSSL package to 1.1.1l or later, restart the service, and we will confirm with a re-scan. Due in 14 days per our SLA.
Same facts. One of them gets closed on a lunch break; the other gets pushed to the bottom of the pile forever.
The four questions, answered before they are asked. The title is the action, and the owner is a person.
Try it. Pick the ugliest finding in sample-findings.csv and rewrite it with the four questions, using ticket-template.md. If you cannot fill in “exactly what do I do,” you have found a finding you do not understand well enough to hand off yet, which is far better to learn here than in front of an engineer.
Straight talk. Writing tickets this good, by hand, for every finding, does not scale past a certain point. The part of it that is robot work is the plumbing: creating the ticket, filling the fields, routing it, chasing it. Risk Rancher turns each finding into a ticket with the scanner’s title, description, and fix already in the right places, assigns it by rule to the owner you named, hands that owner a link to update it, and watches for the resolution to come back. The plain-language rewrite is still yours; the tool saves you the copy-paste, not the empathy. It is free, all of it; I built it to get exactly this grunt work off your plate. Everything in this chapter you can also do by hand, and should learn to first, so you know what the tool is doing in your name.
The alliance is the program
None of the chapters after this one work without this one. You can have the best scanner, the sharpest triage, the most elegant risk formula in the industry, and if engineering has decided you are a nuisance, your beautiful findings will die in a backlog. Conversely, a mediocre program with a great relationship will quietly close more real risk than a brilliant one that everybody ignores.
So spend the relationship capital early and deliberately. Send fewer, better tickets. Take a false positive off their plate before they have to argue with you about it. Say thank you when something gets fixed. Be the person who makes their job easier, not the one who makes it longer. Do that, and when you walk up with a finding that genuinely matters, they will already be reaching for the wrench.
With the herd mapped and the alliance built, we can finally turn on the machine that finds the holes. Next: casting the net.