Notifications
Clear all
Topic starter
19/08/2026 3:51 pm
TL;DR: Reporting friction still drives disclosure risk and weakens remediation discipline, as 70% of INTIGRITI’s bug bounty community have found vulnerabilities without a vulnerability disclosure policy to report them, while 32% were unsure whether a submission succeeded. Clear intake paths matter because governance gaps can turn ethical reporting into public exposure.
NHIMG editorial — based on content published by INTIGRITI: Common Types of Vulnerability Disclosure When Working With Ethical Hackers
By the numbers:
- 70% of our bug bounty community have identified vulnerabilities before but found no vulnerability disclosure policy (VDP) to report them.
- 32% said they weren’t sure whether it was successful.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
Questions worth separating out
Q: How should security teams run a vulnerability disclosure program without losing control of reports?
A: Use one intake path, define clear ownership for triage and remediation, and publish response expectations before opening the program.
Q: Why do unclear disclosure processes increase security risk?
A: When researchers cannot find a policy or confirm receipt, they are more likely to publish the issue or move to another channel.
Q: What do organisations get wrong about bug bounty programmes?
A: They often treat them as a one-time discovery mechanism instead of a continuous assurance process.
Practitioner guidance
- Publish a clear vulnerability disclosure policy State where researchers should report issues, what confirmation they will receive, and who owns triage.
- Create one accountable intake path Route all reports into a single queue with ticketing, acknowledgement, and decision tracking so that email, spreadsheet, and ad hoc submissions do not fragment the workflow.
- Separate disclosure handling by issue type Treat identity and NHI reports as urgent containment cases when they involve API keys, service accounts, certificates, or delegated access.
What's in the full article
INTIGRITI's full article covers the practical disclosure details this post intentionally leaves for the source:
- Examples of when private disclosure, full disclosure, and responsible disclosure are most appropriate
- Guidance on how bug bounty platforms support researcher intake and reporting
- The rationale behind a formal vulnerability disclosure policy from a researcher perspective
👉 Read INTIGRITI's guide to vulnerability disclosure types and policy design →
Vulnerability disclosure policies: where do teams still fail?
Explore further
19/08/2026 4:26 pm
Disclosure governance is now part of security control, not just communications. The article shows that the risk is not only the vulnerability itself, but the organisation's ability to receive, route, and act on the report before exposure widens. In identity-rich environments, a missed report can leave secrets, service accounts, or delegated access paths unaddressed. The practical conclusion is that disclosure intake should be treated as a governed control surface.
A question worth separating out:
Q: Who is accountable when a vulnerability report misses an exploitable issue?
A: Accountability sits with the programme owner who accepted the testing model and closure criteria, not only with the tester. If the organisation chose snapshots over continuous validation, the control gap is governance-led. Security leaders, application owners, and risk owners all need clear closure standards and evidence requirements.
👉 Read our full editorial: Vulnerability disclosure policies are lagging researcher reporting
