A Piece of the Pi

You already paid for this bug.

Six months ago, someone on your team triaged and fixed an IDOR. They knew why it happened, fixed it, and moved on.

This morning, a researcher submitted a similar vulnerability, same root cause, different service. It landed in the queue like it's the first time anyone has ever seen it, because as far as the system was concerned, it was.

The engineer who fixed it last time has moved to another team. The reasoning was documented in a Slack thread when it happened but nobody will find it now. The report that taught you the lesson at the time  was archived. So you triage this “new” vulnerability from scratch, paying the bounty again.  Without the context from the previous fixed IDOR, the new fix doesn't quite match the old one, all because the person writing it never knew it existed. The knowledge you needed was there all along;it was just out of reach of your memory. .

Why are we paying for it again?

The problem isn't that vulnerabilities exist. That is a fact of building software.

The problem is the institutional knowledge needed and the moment it is needed are almost never in the same place at the same time.

The lessons learned from the past stay in the report. The reasoning behind a fix stays in a pull request nobody reopens, a Slack thread nobody reads, or in an engineer's head. So when the next vulnerability is found , none of that context comes with it. Every finding is handled from scratch, and that means the security team pays for it again: spending time rediscovering what it already knew, and often landing on a different, less-tested fix than the one that already worked.

The team is not slow or careless. It is relearning the same lesson over and over, because nothing it learns survives the trip to the next finding.

The thing that changed how I think about this

Security doesn't have a visibility problem anymore. It has a memory problem.

For a long stretch of my career I was the person raising these tickets: finding something real, routing it to a developer, and watching it go quiet. Not because the developer didn't care, but because "new security vulnerability" loses, every time, to the feature due Friday.

Then I changed one thing. Instead of "IDOR in the payments service" the ticket would say: a researcher abused this exact root cause last month, here is what it cost us, we are still exposed in three other services, and here is how we fixed it the first time. The response was immediate. Nothing about the workload had changed. The finding now arrived carrying its history, and nobody wants their name on the second version of a breach the company already paid for once.

The finding was always the same. What changed was the history attached to it, history that was just unreachable at the moment someone had to decide. That is when it clicked. We are not short on ways to find vulnerabilities. We have scanners, bug bounty programs, researchers, and AI models get better every year. We are short on ways to carry what one finding taught us into the next one.

Better detection has not fixed this. If anything it has made it louder: more findings than any team can work, most of them noise. Pi triages the flood so the duplicates, the unexploitable, and the low-blast-radius reports fall away, and what is left is what actually matters. But triage only decides what you work on now. It does nothing to keep what you learn while working on it.

That is not a failure of the tools. It is simply not what they were built for. They find issues. They were never meant to preserve a decision and apply it the next time it matters.

‍

Why linking is the point

A memory is a security decision your organization already paid to learn: the way a specific authorization flaw was fixed, for this reason, and approved by the team.

Sometimes it's a fix. Sometimes it's a decision not to fix something. Sometimes it's the reason a team chose one remediation pattern over another. Sometimes it's the fact that a vulnerability report turned out to be a false positive. None of those facts live in the code itself, but they shape every future security decision.

The discipline is in what gets kept. If a careful reviewer would reach the same conclusion straight from the code diff, it isn't a memory, it's just review. A memory on its own is just a note. The power isn't in storing them. It's in applying them.

When this morning's finding arrives, before you even open it, Pi has already identified its root cause from previous reports, so it treats the finding as a repeat rather than a discovery, and it drafts the remediation in the same shape your team accepted before, because the reasoning behind that fix is one of the things it kept. It honors the decisions you've already made, so an endpoint your team deliberately scoped out as intentional is left alone instead of flagged a second time. And it carries the pattern forward, hunting the same root cause through services that were never named in any report, and raising findings only where a genuine flaw.

That's three kinds of memory working at once: the fix your team accepted, the exception your team stood behind, and the pattern Pi knows to look for. None of them moved. The finding moved through them. You're not triaging from scratch. You're closing the class instead of the instance.

I'll be straight about where this stands. Institutional memory is how Pi reasons today, through root-cause analysis, recurrence elimination, variant hunting, and applying the decisions you've already made. The surface where you browse and curate every memory yourself is still being built. The conviction is shipped; the full interface is on its way.

The question for us was never whether Pi could find issues. Plenty of systems can do that. The question was whether linking organizational memory to every finding would actually change outcomes. We started measuring that directly.

What the work looks like once it's linked

• 441 Critical and High issues were fixed before they ever merged: 177 of them pull requests that would have shipped a vulnerability, stopped at the gate. Almost two of every three Critical fixes landed within an hour of the alert.
• Nearly every variant hunt found the same flaw somewhere no report had mentioned.
• The fixes hold: benchmarked independently against context-free patches, Pi's were 2.5 times more durable against re-exploitation.

And from the receiving end: one enterprise security team told us that when Pi generates a fix, it's good to ship 80% of the time.

The morning it stops costing you

As AI accelerates both software creation and vulnerability discovery, the cost of forgetting the past rises with it. Nothing about that morning asked you to remember anything. The system remembered for you, and for the engineer who'll hit this same root cause six months from now and never know they were about to.

That's what changes the arithmetic. A team that remembers its history is not doomed to repeat it and a team that isn't redoing that work over and over can finally move at the speed it ships. The point was never only to remember; it was to take security out of the critical path, so getting it right stops being the thing that slows you down.

We built Pi because the knowledge was always there. It just needed somewhere to live, and a way to reach the moment it mattered.

The longer-term goal is bigger than fixing vulnerabilities faster. We want security knowledge to accumulate the way code does. When the engineer who wrote a fix moves teams, or the security lead who made a call leaves the company, the reasoning stays with Pi, and the organization itself becomes the thing that remembers. That is when a fix stops being a one-time task and becomes guidance for the next engineer, the next pull request, the next service, and the next AI agent that touches the code. That's the future we're building toward at Pi.