Project Memory at Corridor · Yousef AbuHashem

Corridor reviews every pull request for security issues. When it flags something a developer disagrees with, they can dismiss the finding and say why. The problem was that it never remembered any of it.

Say it flags a missing auth check on an admin page, and the developer dismisses it with “this is behind Okta, only admins can get here.” A few days later someone opens another PR that touches the same code, and Corridor flags the exact same thing. That is a fair thing for a security reviewer to flag, but it gets old fast, and a reviewer that repeats itself is one people learn to ignore.

Corridor before memory, more or less.

So I worked on giving it a memory. Every dismissal and the reason behind it gets saved, and when a new PR comes in, the reviewer pulls up what that project has taught it before. It is built on Hindsight, an open-source memory engine. A big reason we picked it is that it notices when three developers say the same thing in three different ways and keeps it as one lesson, with a count of how many times we heard it.

Admin routes are behind Okta. Dev A · March · api/admin/users.ts
Okta SSO gates all of /admin. Dev B · April · api/admin/billing.ts
Only admins can reach this. Dev C · May · api/admin/export.ts

One lesson ×3

Routes under api/admin/ sit behind Okta SSO, so only admins reach them.

A later PR

Missing auth check in api/admin/export.ts

Already explained

Three people dismissing findings in their own words become one lesson, backed by all three. Illustrative example.

When the memory is wrong

A memory that is wrong is much worse in a security tool than in a chatbot. If that team later drops Okta, the memory still says admin pages are safe, and the next missing auth check goes straight through.

So Corridor does not save a dismissal just because someone made it. It re-reads the code first and decides whether the developer was actually right. When we replayed our own history, saving every dismissal as-is would have hidden 14 of 102 real vulnerabilities. With that check, it hid 2. Lessons also come back with the file and commit they were learned from, and the reviewer treats them as hints to verify, not as rules.

Does it work

We ran it next to the old approach on PRs from some of our biggest customers.

−62%findings reported as false positives

−39%findings ignored at merge

½the cost of the false-positive step

It also dropped slightly fewer real findings than before (5.4% vs. 6.3%), so the drop in noise did not come from hiding more real bugs. The full post on Corridor’s research page goes into how we tuned it and where it goes next.