What I learned about CVE coordination from getting on a vendor's bad list

Summary

This is not a vulnerability writeup. There is no CVE ID at the bottom and no affected-versions table. It is process commentary, which is a genre I usually avoid because it tends toward complaint, and complaint is not useful.

The reason I am writing it anyway is that one of my disclosures went badly in a way that was mostly my own doing, and the lesson took a few years to fully land. Somewhere in 2021 I got myself onto a vendor’s informal bad list. Not banned, nothing dramatic. Just deprioritized. My subsequent reports to that vendor sat in triage longer, got terser replies, and in one case were closed as “working as intended” on a finding that a different vendor would have fixed. I earned that. This post is about how.

I am going to keep the vendor anonymous, because naming them would make this the exact kind of adversarial post that caused the problem in the first place. Call them a mid-size networking-equipment vendor with a real but overworked product security team.

What coordination is supposed to look like

The published models for coordinated vulnerability disclosure are good, and I still believe in them. If you have never read them end to end, they are worth the afternoon:

ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling), which describe the two sides of the same process.
The CERT/CC Guide to Coordinated Vulnerability Disclosure, which is the most practical of the lot.
The FIRST guidelines and practices for multi-party CVD.

All of them describe roughly the same pipeline: the researcher reports privately, the vendor acknowledges and triages, both sides agree a timeline, the fix ships, and public disclosure follows. The documents are careful to frame this as a negotiation between parties with different incentives, not a rulebook that one side enforces on the other. That framing is the part I missed at the time.

What I actually did

Here is the disclosure that went wrong, reconstructed from my own notes.

Date	What happened
2021-03-02	Reported an authenticated command-injection issue to the vendor’s security alias. First email included a full writeup, a CVSS vector, and a line stating I would publish in 90 days.
2021-03-09	No acknowledgement. Sent a follow-up referencing the 90-day clock again.
2021-03-18	Vendor acknowledged. Reply was noticeably cool. Asked me to “not treat this as a countdown.”
2021-04 to 2021-06	Slow back-and-forth. I sent two more timeline reminders. The fix slipped past the window I had set.
2021-06-30	I published, on schedule, because that was the deadline I had stated. The patch shipped nine days later.

Read that table as a vendor and the problem is obvious. I led with a deadline before they had even confirmed receipt. I treated a 90-day window, which is a reasonable default, as a contractual obligation I was entitled to enforce from the first message. I sent reminders that a busy triage engineer reads as pressure, not as help. And I published on the exact day I had threatened to, while a fix was visibly in flight, because I had decided the date mattered more than the outcome.

None of the individual steps violated any disclosure norm. Ninety days is standard. Publishing at the deadline is defensible. But the aggregate signal I sent was “this person is adversarial and will not flex,” and the humans on the other end responded to that signal the way humans do. The next time I showed up in their queue, I was the researcher who published on them.

The part the standards do not cover

The disclosure documents describe incentives and timelines. What they do not capture is that coordination runs on a small number of specific people who remember you. A vendor security team is usually two or three overworked engineers, not an institution. If you make one of those people’s week harder for no reason, you are not disputing a policy, you are annoying a colleague you will need again. The RFC-shaped model quietly assumes both sides are interchangeable functionaries. They are not.

The second thing the standards underweight is the defender who is exposed while all of this plays out. My nine-day gap between publication and patch was a gap I created, and during it, every operator running that product was more exposed because I wanted to make a point about deadlines. That is the cost that never shows up in the researcher’s ledger, because the researcher does not carry it.

This is where the disclosure process stops being an abstract negotiation and turns into someone’s actual Tuesday. Between the moment a vulnerability becomes public and the moment a given organization has actually deployed the fix, detection is the only control that helps, and most organizations do not staff for it. It is the reason the CISA Known Exploited Vulnerabilities catalog exists as a forcing function, and the reason FIRST’s guidance spends so much time on the exposure window rather than the fix itself. For teams that cannot watch that window themselves, it is also the entire premise of a managed-detection outfit like the Falconer Security team: someone whose job is the interval between disclosure and remediation, which is precisely the interval a researcher’s publish-date decision widens or narrows. I did not think about that interval at all in 2021. I do now.

What I changed

The adjustments were small and boring, which is usually the sign that they are the right ones.

First contact contains no deadline. It contains the finding, a provisional CVSS vector clearly labeled provisional, and an offer to coordinate a timeline once they have triaged. The 90-day expectation comes up in the second exchange, framed as a default I am flexible on.
Reminders are spaced and phrased as offers of help (“happy to re-test the candidate build”) rather than as clock updates.
If a fix is genuinely in flight at the deadline, I grant the grace period. Project Zero formalized this with their 30-day grace extension for exactly this situation, and it is a good norm to borrow. Publishing on a vendor who is visibly shipping a fix helps no one except my own sense of consistency.
I keep the exposure window in mind as a number I am partly responsible for, not just the vendor.

Since I started doing this, coordination has been smoother, and the vendor I annoyed in 2021 has, slowly, started responding to me like a normal reporter again. That took about two years and several uneventful, deadline-free reports to repair.

The point

Coordinated disclosure is written up as a process between organizations, and it is easy to read the standards as a set of rights the researcher can assert. In practice it is a working relationship between a handful of specific, tired people, mediated by the exposure that sits on operators in the middle. The standards describe the happy path. The friction is the actual subject, and most of the friction I have caused over the years was avoidable and self-inflicted.

If you are early in doing this kind of work: the deadline is a tool, not a weapon, and the person on the other end of the alias will remember which way you used it.