A path, not a verdict

Today, most findings get a verdict. A score, a severity, a deadline, a ticket. It’s decided on day one, with the least information the finding will ever have, and then it mostly sits there until the deadline or the next scan.

This series has been arguing for something else. Part 1 made the bet: share the questions and the answers across teams, early, wherever the data behind them lives. Part 2 said which answers matter: seven questions. Part 2½ added findings that arrive with no name at all. Part 3 said who may know and who may act.

This part puts it together. Not a verdict: a path.

The paths

Not every finding should take the same path. The first pull of data says which kind of finding this is: whether there’s a quick exit, or one factor that matters more than everything else. So first pick the pattern, then work the finding through it.

That first pull is mostly cheap. Part 2 said to ask the cheap questions first. Sharper: most answers are already cached somewhere. Only two are costly.

So the order follows what matters most. Here are four patterns to start with, each named for what drives it. Code gets copied and libraries get shared, so a flaw, known or novel, is rarely in one place, which is why one of them is about the one fix.

Our example: the quick exit

The Redis client library from part 2 pulls up like this: a fix exists, nobody’s attacking it, and it sits on an internal system. That’s a quick exit. Here it is, stop by stop.

Two loops make it a path and not a verdict. A fix that isn’t proven goes back to act. And when a claim expires, the finding comes back to the first look on its own. Every pattern has both loops; what changes is which questions go first.

Follow one finding

Same finding, day by day. In part 2 it wasn’t urgent: the service didn’t call the flawed function, so it went to the next normal release. A good call. Here’s what happens next.

Under a verdict, this finding had two bad endings. A deadline forces a fire drill on day 0 for something nobody could reach. Or it gets marked “accepted”, and nobody notices on day 9 that a new feature made it reachable. The path got it right both times, and nobody had to remember to check.

Everyone’s part

Same stops, five players, one of them a service that looks things up. Nobody does all of it, and security does less of the work, not less of the deciding.

The incentive flips

In my experience, today it mostly runs one way. A list arrives with a deadline. The team on the other end has little room to push back or add what they know, so they do whatever closes it fastest: patch it, mark it done, or file an exception. Closed is the goal, not safe. Those aren’t the same thing, and the spreadsheet can’t tell them apart.

On a path, it runs both ways. A team can answer back: “not reachable, here’s why, and here’s my name on it.” Every answer has a name, a date and an expiry, and done means proven by a system. The easy way off the list becomes the honest one. That might be the biggest change of all, and it’s cultural, not technical.

“They won’t open up”

The pushback I hear most, including from people I respect: organizations won’t open up. The teams won’t share, and the walls are there for a reason.

Fair. It’s a real change, and part 1 said the friction grows faster than the sharing. But the bet isn’t all or nothing. There are three lanes:

If the system can change → put doors in the walls. That’s where the most lift is.

If it can only bend → a one-way mirror still lets security see in early and make better calls, while every team keeps its walls.

If the walls stay exactly as they are → each team can still run the path for what it owns: the first look, the receipts, and the watch for claims that expire.

How you run a lane is a separate dial: by hand, with bootleg scripts, or with agents.

What a path doesn’t fix

Deadlines don’t go away → Regulators and contracts still have them. A path is how you meet them honestly, with a receipt that shows what each call rested on.

Somebody has to build it → The lookups, the board, the watch. That’s Series 2.

Where this goes

Series 1 was seeing the problem. Series 2 is the how, lane by lane and tool by tool: bootleg scripts you can build without buying anything, automating the lookups with agents, and what to build, and who builds it.

Before that, the whole series will go on one page you can take with you.