A vulnerability shipped

At some point you will find a vulnerability in production that you reviewed, or should have. It might come from a researcher, a customer, a scanner or your own second look. The feeling is the same: a drop in the stomach and an urge to fix it quietly. Resist the second part.

The first hour

1. Work out the exposure. Is it reachable from the internet? Does it touch sensitive data?
2. Look for signs of use. Check logs for requests that match the flaw.
3. Tell your manager and the owning team now, not after you have a fix.
4. If there is any sign of exploitation or data exposure, start the incident process.
5. Agree the fastest safe fix: a patch, a config change, a feature flag or turning the feature off.

Telling people

Keep the first message short and factual. What you found, where, how exposed it is, whether you see signs of use and what happens next. Avoid guessing. If you do not know yet, say so and say when you will know more.

Rule of thumb:Write down times as you go: when you learned, who you told, what you checked. It feels like a distraction during the work. It saves hours when people ask questions later.

After the fix

• Confirm the fix in production, not just in the pull request.
• Search for the same pattern elsewhere. Flaws rarely live alone.
• If someone outside reported it, thank them and tell them when it is fixed.
• Ask why it got through. Missing test, unclear ownership, rushed review? That goes in the review, not on a person.

Whether customers or regulators must be told depends on the data, the law where you operate and your contracts. That decision belongs to legal and leadership, with your facts. Your job is to give them accurate facts fast.

Finally, look after yourself and the team. Fixing a live flaw under pressure is tiring. Once it is contained, say thank you to the people who helped, hand over anything that can wait and get some rest. Good judgement in the next incident depends on it.