Coordinated security disclosure

Part of the Verify pillar. If you have found a security issue in deny.sh, please tell us. 48-hour acknowledgement, a real GPG fingerprint, safe harbour for good-faith research. Here is what to send, where to send it, and what you can expect in return.

Draft. Under review. This policy is being finalised for the 1 June launch. It already governs how we handle reports today; if you want to test it, please do.

Draft version: 11 May 2026

The short version

Email security findings to security@deny.sh. We acknowledge within 48 hours, agree a coordinated public disclosure date with you, fix in priority order, and credit you in the changelog and on this page (unless you prefer to remain anonymous). For high-impact findings, please use the GPG key linked at the bottom of this page.

The deny.sh source code is open. The cryptographic construction is published in the whitepaper and the prose companion at /security. Findings are welcome on any layer: the primitive, the SDKs, the hosted API, the browser tools, the CLI, the bot, the MCP server, the website.

This policy is intended to give security researchers the comfort to test deny.sh in good faith. We do not pay a monetary bounty today. We expect to launch a funded program once we close our first round of funding (post-launch, second half of 2026). Recognition, coordinated public credit, and a hall of fame at the bottom of this page are what we offer in the meantime.

Scope

The following surfaces are in scope. A finding on any of these is welcome under this policy.

The following are out of scope:

How to report

Email

The primary channel is email to security@deny.sh. We monitor this address actively during UK business hours and check it twice daily outside business hours. Include in your report:

For high-impact findings, especially anything that affects the cryptographic primitive, please encrypt your report to our GPG key (fingerprint below). Reports that do not affect confidentiality of the finding itself (for example, a website XSS that is already exploitable in production) do not need encryption.

GitHub security advisories

For findings against the open-source SDKs at github.com/deny-sh-crypto, you can also file a private security advisory through GitHub's UI on the relevant repository. This is the preferred channel for SDK-specific findings because it gives us version control over the disclosure timeline and a clean audit trail. The maintainers receive private advisories with the same response-time commitments as email.

What we commit to

When you report a finding, we will:

  1. Acknowledge within 48 hours, even if the acknowledgement is only "we have received this and are investigating." If you do not hear back in 48 hours, please re-send to hello@deny.sh in case the security mailbox failed. Our response time during weekends and UK bank holidays may extend to 72 hours; we will improve this once we have funded security staffing.
  2. Triage and assess within five working days, and share our assessment with you. If we believe the finding is out of scope, we will explain why. If we agree it is in scope, we will agree a target fix date and a coordinated disclosure date.
  3. Fix in priority order. Critical findings affecting the cryptographic primitive or live customer data: within 7 days. High-impact findings: within 30 days. Medium-impact: within 90 days. Low-impact: best effort, typically within the next release cycle. These are targets, not guarantees; we will keep you informed.
  4. Coordinate public disclosure with you. Default disclosure window is 90 days from acknowledgement, with the option to extend by mutual agreement if a fix is in progress. We will publish a security advisory at the agreed date, naming you (or your pseudonym) unless you have asked to remain anonymous.
  5. Credit you publicly in the changelog, in the relevant SDK's SECURITY.md file, and in the hall of fame at the bottom of this page. We do not require an NDA, gag clause, or any restriction on you discussing the finding after the coordinated disclosure date has passed.

Safe harbor

If you make a good-faith effort to comply with this policy during your research, we will:

Good-faith research means: you do not access, modify, or destroy data that is not your own; you do not degrade or disrupt the Service for other users; you stop testing and notify us as soon as you have demonstrated the impact of a finding; and you do not disclose the finding publicly until we have agreed a coordinated date or 90 days have passed since acknowledgement (whichever is earlier).

If you are unsure whether a specific test is in scope or safe, write to us first at security@deny.sh and we will tell you. We would rather field a pre-test question than mediate a misunderstanding after the fact.

On a paid bounty program

We do not run a paid bug bounty today. We are a small company that has not yet raised institutional capital. Paying a credible bounty (one that values cryptographic findings at a level that reflects the work involved) is something we want to do, but only when we can fund it properly rather than offer token rewards. The plan is to launch a funded program after our first round of funding closes, which we expect to be in the second half of 2026.

In the meantime, we offer recognition, prompt response, and a public credit that documents your contribution. If you are an experienced security researcher and a monetary bounty is a hard requirement, please get in touch anyway: we can discuss a paid informal review on a finding-specific basis, and we are interested in building relationships with researchers we may want to commission post-funding.

Hall of fame

Researchers who have reported findings under this policy will be listed here, ordered by date of acknowledgement. Pseudonyms are honoured. The list begins from launch (Sat 4 July 2026) and will be backfilled to include any findings reported during the pre-launch window.

No reports acknowledged at the date of this draft. The list will populate from launch onwards.

Contact

Primary security mailbox: security@deny.sh.

General contact: hello@deny.sh.

GPG key for security@deny.sh:

UID:         deny.sh Security (Treehouse in Valhalla Ltd) <security@deny.sh>
Fingerprint: D318 1C84 73FD B3E7 1271  8D9F D6DA 921A CB41 4764
Algorithm:   ed25519 (signing) + cv25519 (encryption)
Valid:       2026-05-11 to 2028-05-10
Download:    https://deny.sh/security-key.asc

Verify the fingerprint independently before encrypting: gpg --show-keys security-key.asc should print the fingerprint above. The same key signs /.well-known/security.txt; verify with gpg --verify security.txt.

The GPG public key will be linked here, on the deny.sh security.txt at /.well-known/security.txt, and published on the launch-day changelog entry.

Related pages