Report vulnerabilities to us, not to the upstream we forked

This repo is a fork, and its SECURITY.md still carried the upstream's contact —
so a researcher who found a hole in what WE ship was told to mail a vendor who
cannot fix it, and who would then know about a live vulnerability in our
production before we did.

Fourteen repos were in that state: datastore -> [email protected], git and
its two worktrees -> [email protected], auto -> [email protected],
calendar -> [email protected], dns -> [email protected], python-sdk ->
[email protected], plus bot, gui-gates, gui-geist, playground and
playground-oauthcb pointing at brand domains with no mailbox behind them.

All of them now carry one policy and one address, [email protected], matching
what cloud and gateway already used. The policy says out loud to report here
rather than upstream, because the next fork will inherit the same file and the
same instinct.

SECURITY.md

@@ -1,87 +1,15 @@
-<!--
+# Security Policy
-the file is autogenerated by utils/security-generator/generate_security.py
--->
 
-# ClickHouse Security Vulnerability Response Policy
+## Reporting a vulnerability
 
-## Security Change Log and Support
+Email security@hanzo.ai with details. We respond within 48 hours; critical
+issues receive same-day acknowledgment.
 
-Details regarding security fixes are publicly reported in our [security changelog](https://clickhouse.com/docs/whats-new/security-changelog/). A summary of known security vulnerabilities is shown at the bottom of this page.
+Report to us, not to the upstream this fork came from. They cannot fix what we
+ship, and routing a live vulnerability in our deployment to a third party tells
+someone else about it before it reaches the people who can close it.
 
-Vulnerability notifications pre-release or during embargo periods are available to open source users and support customers registered for vulnerability alerts. Refer to our [Embargo Policy](#embargo-policy) below.
+## Scope
-
-The following versions of ClickHouse server are currently supported with security updates:
-
-| Version | Supported |
-|:-|:-|
-| 26.6 | ✔️ |
-| 26.5 | ✔️ |
-| 26.4 | ✔️ |
-| 26.3 | ✔️ |
-| 26.2 | ❌ |
-| 26.1 | ❌ |
-| 25.12 | ❌ |
-| 25.11 | ❌ |
-| 25.10 | ❌ |
-| 25.9 | ❌ |
-| 25.8 | ✔️ |
-| 25.7 | ❌ |
-| 25.6 | ❌ |
-| 25.5 | ❌ |
-| 25.4 | ❌ |
-| 25.3 | ❌ |
-| 25.2 | ❌ |
-| 25.1 | ❌ |
-| 24.* | ❌ |
-| 23.* | ❌ |
-| 22.* | ❌ |
-| 21.* | ❌ |
-| 20.* | ❌ |
-| 19.* | ❌ |
-| 18.* | ❌ |
-| 1.* | ❌ |
-
-## Reporting a Vulnerability
-
-We're extremely grateful for security researchers and users that report vulnerabilities to the ClickHouse Open Source Community. All reports are thoroughly investigated by developers.
-
-To report a potential vulnerability in ClickHouse please send the details about it through our public bug bounty program hosted by [Bugcrowd](https://bugcrowd.com/clickhouse) and be rewarded for it as per the program scope and rules of engagement.
-
-### When Should I Report a Vulnerability?
-
-- You think you discovered a potential security vulnerability in ClickHouse
-- You are unsure how a vulnerability affects ClickHouse
-
-### When Should I NOT Report a Vulnerability?
-
-- You need help tuning ClickHouse components for security
-- You need help applying security related updates
-- Your issue is not security related
-
-## Security Vulnerability Response
-
-Each report is acknowledged and analyzed by ClickHouse maintainers within 5 working days.
-As the security issue moves from triage, to identified fix, to release planning we will keep the reporter updated.
-
-## Public Disclosure Timing
-
-A public disclosure date is negotiated by the ClickHouse maintainers and the bug submitter. We prefer to fully disclose the bug as soon as possible once a user mitigation is available. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested, or for vendor coordination. The timeframe for disclosure is from immediate (especially if it's already publicly known) to 90 days. For a vulnerability with a straightforward mitigation, we expect the report date to disclosure date to be on the order of 7 days.
-
-## Embargo Policy
-
-Open source users and support customers may subscribe to receive alerts during the embargo period by visiting [https://trust.clickhouse.com/?product=clickhouseoss](https://trust.clickhouse.com/?product=clickhouseoss), requesting access and subscribing for alerts. Subscribers agree not to make these notifications public, issue communications, share this information with others, or issue public patches before the disclosure date. Accidental disclosures must be reported immediately to trust@clickhouse.com. Failure to follow this policy or repeated leaks may result in removal from the subscriber list.
-
-Participation criteria:
-1. Be a current open source user or support customer with a valid corporate email domain (no @gmail.com, @azure.com, etc.).
-1. Sign up to the ClickHouse OSS Trust Center at [https://trust.clickhouse.com](https://trust.clickhouse.com).
-1. Accept the ClickHouse Security Vulnerability Response Policy as outlined above.
-1. Subscribe to ClickHouse OSS Trust Center alerts.
-
-Removal criteria:
-1. Members may be removed for failure to follow this policy or repeated leaks.
-1. Members may be removed for bounced messages (mail delivery failure).
-1. Members may unsubscribe at any time.
-
-Notification process:
-ClickHouse will post notifications within our OSS Trust Center and notify subscribers. Subscribers must log in to the Trust Center to download the notification. The notification will include the timeframe for public disclosure.
 
+This policy covers the code in this repository. For the broader Hanzo platform
+threat model, see [hanzoai/hips](https://github.com/hanzoai/hips).