How to write safe security bug reports

When you find a security issue, the instinct is to report it like any other bug: paste the steps, attach a screenshot, drop it in the shared tracker. That instinct is wrong, and acting on it can turn a finding into an incident. A security report has extra obligations a normal one doesn't — it has to convey impact without handing out an exploit, prove the issue without exposing real data, and reach the right people through the right channel. The goal is a fix, not a demonstration. This builds on the general craft of a bug report developers can fix, with security-specific guardrails.

The principles

Restrict the audience. Security findings shouldn't sit in a public repo issue, an open Slack channel, or a ticket the whole company can read. Use whatever private channel your org has — a security team, a restricted tracker, a direct line to the owner. If there's no process, that's the first thing to flag. The fewer people who see "here's an unpatched way in," the better.

Describe impact, not a weaponised exploit. Explain what an attacker could achieve — "an authenticated user can read other users' orders by changing the id" — clearly enough to convey severity and prove it's real, without writing a copy-paste attack script or automated exploit. Enough to reproduce and fix; not a turnkey tool.

Never use real user data. Reproduce with test accounts and test records. Don't pull a real customer's personal data to prove the point, and absolutely don't paste it into the report. If the bug inherently exposes real data, describe that fact — don't include the data itself. Capturing or sharing real PII to demonstrate a bug can itself be a breach.

Redact the sensitive bits in evidence. Screenshots and logs love to capture live tokens, session cookies, real emails, and internal hostnames. Redact them. A report that leaks a working token is the next vulnerability.

State severity and urgency plainly. Help the team triage: what's the impact, who's affected, is it being exploited, does it need an immediate fix or normal scheduling? A clear severity call is part of a real readiness/risk picture.

Safe security bug report checklist

• Reported through a private/restricted channel, not a public issue or open channel
• Impact described in terms of what an attacker could do — not a weaponised, copy-paste exploit
• Reproduced with test accounts and test data only — no real user data captured or pasted
• Screenshots/logs redacted: no live tokens, cookies, real PII, or internal hostnames
• Clear severity and urgency, so it can be triaged correctly
• Enough detail to reproduce and fix — and no more
• If no security process exists, that gap is flagged as part of the report

Why the discipline matters

Two things can go wrong, and both are avoidable. First, the report itself becomes the leak: it sits where the wrong person finds it, or it embeds a live token or real data that's now exposed in your tracker forever. Second, an over-detailed, weaponised write-up turns a subtle issue into something any reader can immediately abuse — you've documented the attack better than the attacker could. The fix for both is the same restraint: minimum audience, impact over exploit, test data only, redacted evidence.

None of this slows down the fix — a clear, responsibly-scoped report is easier to action than a panicked data dump, and it keeps the finding from becoming the breach. When you find something serious, the most professional move isn't the most detailed write-up; it's the safest one that still gets it fixed.