Vulnerability disclosure policy

Last updated: 3 November 2026

Applies to: every product and network that Whisper Security operates.

Operated by: Whisper Security, the trading name of viaGraph B.V. (KVK 95822429), Keizersgracht 520H, 1017 EK Amsterdam, the Netherlands.

Version: 2.0

We build security products, so we expect our own work to be tested. If you have found a weakness in something we run, we want to hear about it, and we will treat you as a partner in fixing it. This policy explains what you can test, how to tell us, what we commit to in return, and the legal protection we give to good-faith research.

This policy follows ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling), and its safe harbour is based on the disclose.io core terms.

How to report

Email security@whisper.security. If your report is sensitive, please encrypt it with our OpenPGP key:

Fingerprint: EFF1 663D 9925 3968 2106 A5EA D0F7 0908 CF3B 7929

Key: https://www.whisper.security/.well-known/openpgp-key.txt

A good report tells us:

  1. what is affected (the host name, URL, API call, package and version, or address);
  2. how to reproduce it, step by step, or a proof of concept;
  3. what an attacker could achieve, as you see it;
  4. when you found it, with the time zone;
  5. how you would like to be credited, or that you would prefer not to be.

One issue per report makes it easier to track. You do not need to write a polished report; a clear one is enough. Please write in English.

What is in scope

  1. whisper.security and every subdomain we operate, including the graph API (graph.whisper.security), the MCP server (mcp.whisper.security) and the Console (console.whisper.security).
  2. whisper.online and its subdomains: the identity platform, Graph XDR (endpoint.whisper.online), the registry (nic.whisper.online), RDAP (rdap.whisper.online) and our authoritative name servers (ns1 and ns2.whisper.online).
  3. Our network: AS219419, the prefixes 2a04:2a00::/32 and 2a04:2a01::/32 as routed objects (not the hosts in them, see "What is out of scope", item 1), our routing and origin security (RPKI, IRR), and as219419.net.
  4. Software we publish: the whisper CLI and on-host sensor, our SDKs, connectors and plugins in the whisper-sec GitHub organisation, and the release, signing and installer path that delivers them (for example get.whisper.online). A supply chain finding against an artefact we sign is firmly in scope.
  5. The identity machinery itself: how agent /128 addresses are allocated, registered, resolved and published, and the certificate, DNSSEC and transparency ledger infrastructure behind them.

What is out of scope

  1. Individual agent hosts in 2a04:2a01::/32, and any data or traffic on them. They belong to our customers. Do not probe or access them; the infrastructure that issues their identities is in scope, the agents are not.
  2. Other customers' accounts, tenants and data. Test only against an account you created yourself.
  3. Systems we do not operate: our cloud, CDN, email and payment providers, our transit providers, and any destination reached through our egress. Please report those to the provider.
  4. Findings in our threat intelligence content, such as a claim in a published report you believe is wrong. Those are welcome too, but please send them through the corrections route on our threat intelligence disclosure page rather than as a vulnerability.

What we ask you not to do

  1. No denial of service, load or stress testing, and nothing that degrades the service for others.
  2. No social engineering of our staff, customers or providers, and no physical testing.
  3. Access only the data you need to demonstrate the issue. If you reach personal data, credentials or another customer's information, stop, do not keep a copy, and tell us straight away.
  4. Do not change or delete data that is not yours, and do not install persistence.
  5. Do not use automated scanners at a volume that generates noise for our operators; a few targeted requests are fine.
  6. Give us a reasonable time to fix the issue before you share it with anyone else.

We do not usually treat these as vulnerabilities on their own: missing security headers on pages without authentication or sensitive content, version banners, reports from automated tools without a demonstrated impact, clickjacking on pages without state-changing actions, missing email authentication records on domains that send no mail, and rate limiting on public endpoints that are intentionally open. If you believe one of these does have real impact in our setting, tell us why and we will look.

Safe harbour

If you research and report in good faith and in line with this policy:

  1. We will not take legal action against you, file a criminal complaint against you, or ask a law enforcement agency to act against you, for that research.
  2. We give you permission to access the systems listed under "What is in scope", solely for that research. For the Netherlands, this is our permission for the purposes of Article 138ab and related provisions of the Dutch Criminal Code (Wetboek van Strafrecht).
  3. We will not enforce our terms of service, or any claim we hold under anti-circumvention or other intellectual property laws, against research that follows this policy.
  4. If a third party takes legal action against you for that research, we will, at your request, confirm in writing that you acted with our permission and in line with this policy.

Our permission covers only systems we operate. We cannot give permission for our customers' agent hosts or for systems of our providers or other third parties, and we cannot bind prosecutors or courts. Where the law requires us to share information about a reported issue, for example in a data breach notification, we will do so.

Safe harbour does not apply to research outside this policy, or to activity that causes harm to our customers, their data or any other third party. We will treat a minor, unintentional deviation that you report to us promptly as falling within this policy. If you are unsure whether something is allowed, ask us first at security@whisper.security and we will answer.

What we commit to

These are working days in the Netherlands.

  • Acknowledgement: A human reply within 3 working days, with a reference number.
  • Triage: Our assessment of validity and severity within 10 working days, and who is handling it.
  • Updates: An update at least every 14 days until the issue is closed.
  • Fix target: Critical within 30 days, high within 60 days, medium and low within 90 days, counted from triage. Where a fix needs longer we will explain why and agree a new date with you.
  • Disclosure: We publish an advisory once the fix is available, or 90 days after your report, whichever is earlier, unless we agree a different date with you. If no fix is available after 90 days and publication would put customers at risk, we will explain why and agree a new date with you.

We rate severity with CVSS 4.0 and our own judgement of the real-world impact in our setting. Where a vulnerability affects software that customers run (for example the whisper CLI or sensor), we will request a CVE identifier and publish an advisory on GitHub and on our advisory page. If a vulnerability in our product is being actively exploited, we may publish sooner to protect customers, and we will tell you before we do.

If the issue lies in third-party software we use, we will coordinate with that vendor, or help you do so, and we will tell you which route we have taken.

Credit

We are glad to credit you by name or handle, with a link of your choice, in the advisory and on our acknowledgements page at https://www.whisper.security/security/acknowledgments. We credit only with your consent and in the form you ask for. We do not run a paid bug bounty at present; we do not ask for, and you should not expect, payment for a report. We will not ask you to sign a non-disclosure agreement in order to report to us.

Advisories

Published advisories are listed at https://www.whisper.security/security/advisories and, for software in our GitHub organisation, in the Security tab of the affected repository. Each advisory states the affected versions, the fixed version, the severity, the CVE where one exists, and the credit.

Other contacts

  1. Abuse coming from our networks or agent identities (spam, scanning, attacks): abuse@whisper.security. See https://www.whisper.security/security/abuse
  2. Network operations, routing incidents, hijacks or route leaks involving AS219419: noc@whisper.security
  3. Questions about our threat intelligence publications, or a notification you received from us: see https://www.whisper.security/security/threat-intelligence-disclosure
  4. Your personal data: privacy@whisper.security
  5. Legal matters and law enforcement requests: legal@whisper.security

Changes to this policy

We will date every change on this page and keep previous versions available on request. A change will never withdraw safe harbour from research that was already under way under an earlier version.