score by collisions, patch by panic :: Himanshu Anand :: Threat Notes
score by collisions, patch by panic
2026-05-19 ::
[Updated :: 2026-05-19]
Himanshu Anand
:: 9 min read (1763 words)
#security
#llm
#disclosure
#defense
#blue-team
#blog
Table of Contents
TLDR;⌗
Score severity by collision count. Researchers ship patches not just reports. Companies redesign for a world where the exploit lands before the patch. No magic. No vendor pitch. Just the playbook.
The last post went further than I expected. NYT’s Hard Fork picked it up. The Lobsters thread had sharp questions. A few people made a fair point. “The model is broken” is a complaint not a proposal.
So here is the proposal.
a new severity model⌗
The current model treats every report as if it lives in a vacuum, One reporter, One bug, One timeline. That was the assumption the old playbook ran on It no longer holds.<br>Here is what severity should look like in 2026.
One reporter and No exploit. Standard severity. Standard window. Business as usual.
Two or more reporters of the same bug. Severity goes up a notch. If unrelated researchers are finding the same flaw a less friendly party probably has it too. Shrink the window.
Working exploit attached. Critical. The patch window collapses from weeks to days.
Working exploit and a public PoC. P0. Stop the line. Patch now.
The collision count is the signal. Use it.
Linus said the quiet part out loud last week on LKML:
So just to make it really clear: if you found a bug using AI tools, the chances are somebody else found it too.
If you needed proof, Searchlight Cyber’s cPanel writeup just made the case better than I can, Strong team. Years of experience on the target. A real head start. Custom tooling that decompiled cPanel’s Perl binaries back to source. They still got beaten by a threat actor by two months. Two months.
If a team operating at that level can be late, the math has changed for everyone.
the independent researcher problem⌗
Here is the part my proposal does not solve cleanly.
If you are a solo researcher you have no telemetry, No customer logs, No threat feed. You find a bug You filed a report and You sit on it. You have no clue if the bug is already being burned in the wild while you wait.<br>I do not have a clean fix the best I can offer is this assume the worst, Assume you are not the only one, File the report and Push hard for a short window. If the vendor stalls that is now a vendor problem.
The other thing Linus said is worth quoting in full:
If you actually want to add value, read the documentation, create a patch too and add some real value on top of what the AI did. Don’t be the drive-by “send a random report with no real understanding” kind of person.
I have been guilty of the drive-by. You find a bug you have the impact you want to ship and move on. But a report with a patch attached gets fixed faster, every single time and it builds trust you will need next time you walk into that vendor’s inbox.
If the project is open source read the code. Find the fix. Send a PR. Even a wrong patch gives the maintainer a starting point. A blank page does not.
for the bug hunters who feel cooked⌗
I get it duplicates everywhere the bounty pools shrinking and the model ships faster than your weekend project.
Look at this year’s Pwn2Own Orange Tsai dropped a full chain Logic bugs only No memory corruption No LLM in the loop No collisions.
That’s my chain. A full chain w/ logic bugs only! No memory corruption, no AI, and of course no collisions at all
@orange_8361
The skill ceiling is still up there. LLMs eat the bottom of the pyramid. The work that needs three months of context, weird intuition and a deep feel for how a system actually behaves is still very human. Sharpen up.
There is light at the end of the tunnel. Not very bright at the moment. Maybe because of the current Strait of Hormuz situation. But it is there.
for the corporates⌗
This part is going to hurt because the answer is “do more work”, I do not have a shortcut.
Your code is yours your dependencies are not. Your dependencies’ dependencies are definitely not, The world your stack runs in now has automated bug finders that are getting better every quarter.<br>The plan has to account for that.
the basics⌗
If you are not doing these yet start here.
Stop npm update on autopilot. Supply chain is a real risk not a slide deck risk, Pin versions, Read changelogs. Scan the diff before you accept it. The next compromised package is already in someone’s repo.
Defense in depth. One control will fail, Always. The next one needs to catch it. If your only protection is “the WAF will block it” you have one control.
Validate before deploy. Every environment, Staging that does not mirror prod is a placebo. The bug that hits prod is the one that did not exist in staging.
Continuous runtime validation. Stop treating...