Finding the flaw is rarely the difficult part. What follows is: deciding who to tell and in what order, resisting the urge to prove it publicly, and holding a line when the organisation that should fix it would prefer the problem were quieter.
Coordinated vulnerability disclosure exists because the alternatives are worse. This run is about following it when it is inconvenient.
No trivia and no right answers — a narrative run about disclosing a vulnerability responsibly.
Four archetypes, four starting hands. Your pick sets the stats you begin with — not the ones you end with.
Seven decisions, each one nudging skill, wealth, reputation, and wellbeing. No take-backs.
Your choices resolve into one of six outcomes — and an honest read on what that pattern costs.
Each archetype begins with a different balance of strengths. Your pick sets the stats you start with — not the ones you end with.
Below is the whole run — every chapter, every option, and where each one leads. Press Play this run above to take it as a game instead, with stats that move as you choose and an ending scored from how you played.
Poking at a third-party service your company depends on, you find an endpoint returning records that are not yours. No authentication. Other customers' data.
It is 11pm. You have confirmed it twice with your own account and stopped.
Your own security team should know, because your company's data is exposed. The vendor should know, because only they can fix it.
It is midnight and you have a group chat open with three colleagues who would find this fascinating.
Four days. The vendor's security address has auto-acknowledged and nothing else. Your own team has patched around it where they can, which is not everywhere.
Other customers of this vendor have no idea.
The vendor responds at last — through their lawyers. The letter is about unauthorised access and does not mention fixing anything.
This is the point where most people go quiet permanently.
Day fifty-two. A patch appears, quietly, with release notes describing "stability improvements." No advisory, no customer notification.
The endpoint is closed. Nobody who was exposed has been told they were.
You have material for a genuinely good technical post. It would be read widely, it would help other engineers, and it would be the most visible thing you have ever published.
It would also be about a named company that sent you a legal letter.
Eight months later, a colleague finds something similar in a different dependency. They come to you first, because you are the person this happened to.
What you tell them is the whole outcome of this run.
No ending is the “best” one — only the one your decisions earned.
Textbook, under pressure, when it cost you.
Testing stopped at proof, access documented, both parties told the same night, a timeline set in writing, a coordinator brought in when the vendor went silent, and the fix verified before anything was published. It is the slow route and the one that ends with the flaw closed and you unharmed.
You kept pushing after the patch landed.
You treated the quiet fix as half a job and pressed for an advisory and customer notification. Nothing about that helped you. It served the people whose data had already moved and who had no way of learning that it had — which is the part of disclosure most often skipped.
You published the pattern, not the grudge.
The technical lesson went out after notification, without a named vendor and without the legal correspondence. It was read, it changed how other people build, and it cost you nothing — because the useful content was never the name of the company.
You handed it to the people whose job it was.
Official channel, minimum access, and the legal letter passed straight to your own counsel without a personal reply. You did not become the story, the exposure got closed, and you were still employed and unlitigated at the end of it. That is a genuine outcome, not a lesser one.
You were right, loudly, at the worst moment.
Enumerated past proof, posted in a group chat, tweeted about the silence and published while customers were unpatched. The frustration was earned — the vendor behaved badly throughout. But every escalation was taken by the one person in the story with no legal protection and no institutional cover.
Reported, escalated, fixed, and told.
Proof and nothing more, both parties informed together, a written timeline, a coordinator when it stalled, legal handled by legal, the fix verified, notification pushed for, and the pattern published without the name. Slow, unglamorous, and it is what the process is for.
This is a fictional vulnerability report. It does not authorise testing, establish safe harbour, determine whether a flaw is real, or tell a reader what they may access. The score and ending are storytelling devices. They must never be used to justify probing a system, accessing data, publishing proof of concept code, delaying a report, or ignoring a legal notice.
The useful distinction is between discovering a possible issue and choosing a responsible next step. A real researcher should first determine whether the system owner has a vulnerability-disclosure policy, what it permits, which channel it names, and whether the work is authorised. The CISA materials describe coordinated disclosure processes and policy concepts, but an organisation's actual policy and the law that applies to the researcher control. Policies and protections differ by country and may be absent.
The run's "proof" chapter is intentionally conservative. Demonstrating impact can be useful to a defender, but collecting additional data or extending access can increase harm and legal risk. A page cannot supply a universal boundary. Stop when the information needed for a good-faith report has been obtained, preserve a clear record of what was observed, and seek qualified advice or a coordinating body when the situation is unclear.
A disclosure timeline is also not a weapon. The appropriate sequence depends on active exploitation, affected users, vendor responsiveness, legal constraints and the severity of the issue. Immediate publication can expose users; indefinite silence can leave them exposed too. A neutral coordinator may help in some cases, but does not guarantee an outcome.
Use the scenario as a report-writing prompt: describe the affected asset, the conditions observed, a minimal reproducible demonstration that does not expose people, the date and channel used, and any policy consulted. Remove unnecessary sensitive details. Then follow the authorised process. The references below are educational background, not security or legal advice, and nothing on this page grants permission to test a system you do not own.
When the owner's policy is absent, unclear, or unresponsive, the only alternatives are not continued testing or immediate public disclosure. A reporter may be able to stop activity, preserve the minimal existing record, seek qualified legal or organisational guidance, or approach an appropriate neutral coordinator. Availability and protection vary by jurisdiction and case, and a coordinator cannot manufacture authorisation. The bounded principle is to avoid creating new access or harm while the reporting route is being clarified.
Without testing any system, practise with a fictional report outline: asset owner, policy location, authorised contact channel, observed condition, minimal evidence needed for reproduction, potential affected users, and details that should not be published. Mark unknown legal or policy questions for a qualified source rather than resolving them with the game. This exercise is deliberately non-operational: it teaches careful reporting structure and does not grant permission, produce exploit instructions or replace security or legal advice.
Ask whether a written policy authorises the work, which reporting channel the owner requests, what evidence is necessary without collecting more data, and what law or contract may apply. Ask who can provide qualified advice if the policy is absent or unclear. These questions help keep a report bounded. They do not create safe harbour, authorise testing or decide whether publication is appropriate.
Use the authored links below to examine the main trade-off from another angle.
Coordinated vulnerability disclosure exists because the two obvious alternatives both fail. Saying nothing leaves users exposed indefinitely. Publishing immediately arms whoever reads it first, before anyone can patch. The coordinated middle — report privately, set a timeline, escalate to a neutral coordinator if the vendor goes quiet, publish after a fix and notification — is slower than either and is the only route that reliably protects the people who are actually affected.
Two details do most of the work for the finder personally. Stopping at proof and documenting exactly what was accessed is what makes a legal letter survivable. And bringing in a coordinating body early changes an asymmetric argument between an individual and a company's legal department into a process with a third party in it.
This is a narrative simulation for general professional education. It is not legal or security advice, and the stat effects are storytelling devices rather than predictions. Testing systems you do not own may be unlawful regardless of intent, and disclosure norms and legal protections vary by country — follow your employer's policy and take qualified legal advice.