Vulnerability Disclosure Policy & Management

Why this matters

If you build or sell software, hardware or a service, somebody will eventually find a vulnerability in it and try to tell you. How that goes is your decision to make now, not theirs.

Organisations without a disclosure process reliably do one of three things: ignore the email because it looks like spam, route it to a sales inbox where it dies, or respond with a legal threat. All three end the same way — the researcher publishes, and you find out from your customers.

Beyond that, disclosure policies are increasingly a procurement requirement. NCSC guidance recommends them, the Product Security and Telecommunications Infrastructure regime requires them for connectable products, and enterprise security questionnaires now routinely ask.

What we build

The policy

A clear public statement of what is in scope, what testing is acceptable, how to report, what a researcher can expect from you and when. Aligned to ISO/IEC 29147, with a security.txt file published under RFC 9116 so reports reach the right place instead of your sales inbox.

The safe harbour language matters most. Researchers need to know you will not pursue legal action against good-faith testing. Without it, competent people simply will not report to you.

Triage

Reports arrive at varying quality. Some are genuine critical findings; many are scanner output, duplicates, or issues that are not vulnerabilities at all. We assess, validate and rate them, so your engineers only see what is real and you are not spending developer time on false positives.

Coordination

Managing the relationship with the researcher — acknowledging quickly, communicating honestly about timelines, and agreeing disclosure. Most researchers are entirely reasonable when treated as such; the disputes that end badly are almost always about silence rather than substance.

CVE coordination

Where a finding warrants a CVE identifier, we handle the process with the relevant numbering authority and help you produce an accurate advisory.

Why us

We have been on the other side of this. Solusec's director has multiple publicly disclosed CVEs and has run coordinated disclosure with vendors ranging from responsive to actively hostile. That experience shapes how we advise: we know what makes a researcher escalate, and what keeps a disclosure cooperative.

We also publish our own security.txt. It seems reasonable to practise the thing we advise on.

Common questions

Is a disclosure policy the same as a bug bounty?

No. A disclosure policy is a process for handling reports that arrive; it costs nothing per report. A bug bounty pays for findings and drives volume, most of it low quality unless carefully managed. Almost every organisation should have a disclosure policy. Comparatively few should run a bounty, and never before the disclosure process works.

Will publishing a policy attract attacks?

People are already testing your public-facing systems. A policy changes where the findings go — to you, rather than to a public post or a broker. Organisations consistently report the volume of genuinely malicious activity is unaffected.

What if a researcher demands payment?

That is the distinction between a researcher and someone attempting extortion, and a clear policy stating you do not pay for reports makes handling it straightforward. We help you draw that line in advance and advise if you find yourself on the wrong side of it.

How quickly must we respond?

ISO 29147 does not fix timescales, but expectation in practice is acknowledgement within a few working days and a substantive assessment within a couple of weeks. Ninety days to fix before public disclosure is the widely accepted industry norm.

Vulnerability Disclosure Management