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 deadline, 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. So this chapter is about one artifact, the ticket: you will rewrite one ugly scanner finding into something an engineer would thank you for, and you will leave with the four questions every ticket has to answer.
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, findings the scanner got wrong. 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, or whatever ticket system engineering lives in. 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 14 days per our policy,” not “ASAP.” Chapter six sets the policy; for now, the point is that a deadline has a reason behind it that is not your mood.
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. Two words in that bad ticket will follow you through the book. A CVE is the public catalog number a known vulnerability gets, like CVE-2021-44228: useful for looking it up, useless as an explanation. CVSS is the scanner’s 0 to 10 badness score, and it says nothing about where the thing sits in your estate.
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.1n 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.1n 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. Where did “1.1.1n or later” come from? Not from the scanner, which only said “remediate.” Every CVE has a public page (search the id) that links to the vendor’s advisory, and the advisory names the version that fixes it. Looking that up is thirty seconds of your time that saves the engineer an hour of theirs, and it is the single most useful thing you can put in a ticket. (Chapter six will fold two more OpenSSL findings on this host into this one ticket; 1.1.1n is the version that closes all three, which is why it is the one named.)
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.
Writing tickets this good by hand for every finding does not scale, and half of the work is plumbing: creating the ticket, filling in the scanner’s fields, sending it to the owner, chasing it. In the tool that half is automatic, and the owner gets a link to update the ticket without an account. The plain-language rewrite, the fix looked up, the sentence about why this one matters: those stay yours. They are the empathy, not the plumbing.
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.
You leave this chapter with one finding rewritten as a ticket and a habit: four questions, answered before they are asked, with the fix version looked up. Every ticket in chapter seven follows that shape. With the herd mapped and the alliance built, we can finally turn on the machine that finds the holes. Next: casting the net.