incident-disclosure: add Incident Disclosure and Notification policy

New policy to document our commitments to disclosing security incidents
and the exact process for notifying users.

README.md

@@ -27,6 +27,7 @@ This repository includes:
 * [Testing policy](/testing/index.md)
 * [Patch management policy](/patch-management/index.md)
 * [Data retention and deletion policy](/data-retention-deletion/index.md)
+* [Incident disclosure and notification policy](/incident-disclosure/index.md)
 
 ### When does Tailscale review or update these policies?
 

incident-disclosure/index.md

@@ -0,0 +1,38 @@
+---
+title: Incident disclosure and notification policy
+slug: incident-disclosure
+policy: true
+faq: false
+weight: 13
+---
+
+This policy specifies when and how we notify users about security incidents.
+
+Both the client software and our managed backend infrastructure (i.e. coordination server) are in scope for this policy.
+
+For incidents that fall under any legal disclosure requirements (such as [California’s Data Security Breach Reporting](https://oag.ca.gov/privacy/databreach/reporting)), those requirements will take precedence over this policy.
+
+By “notify” here we mean explicitly contacting users in addition to regular release notes in the [changelog](https://tailscale.com/changelog/) and GitHub commit history. For example, you may read about minor vulnerability patches in release notes, but we may not notify users via a dedicated security bulletin.
+
+### When we notify users
+
+Generally, we aim to reduce noise and only notify users for actionable incidents. Tailscale does not notify users for routine security patching of dependencies. We also don’t notify users for vulnerabilities in our software, if we confirm the vulnerability was not exploited and no users were affected.
+
+We will **disclose** a security vulnerability **when a fix is available** and any of the following is true:
+* User action is needed to fix the vulnerability, e.g. updating the client software, or applying another mitigation;
+* We can confirm that tailnet metadata or data was visible to an unauthorized party; or
+* We cannot confirm that no users were affected by the vulnerability.
+
+We will **notify users directly** about a security vulnerability when we can confirm that the tailnet was affected, and any of the following is true:
+* User action is needed to fix the vulnerability, and it is a critical or high impact vulnerability; or
+* We can confirm that tailnet metadata or data was visible to an unauthorized party.
+
+We respond to reported incidents, and resolve and determine impact as soon as possible. We do not provide guarantees on time to remediate.
+
+### How we notify users
+
+To disclose security vulnerabilities, Tailscale publishes security bulletins publicly for a broad audience at https://tailscale.com/security-bulletins/. These can be consumed directly, via RSS readers or via social media bot accounts.
+
+To notify users about security vulnerabilities, Tailscale will **email** affected tailnets’ administrators, with information specific to the tailnet, including specific users or nodes which are affected. These emails will be sent to the [security contact](https://tailscale.com/kb/1224/contact-preferences/#setting-the-security-issues-email) for the tailnet, which by default is the Owner of the tailnet.
+
+Occasionally, Tailscale may decide to notify users in additional ways about a security issue, such as by publishing a blog post at https://tailscale.com/blog/, or with in-product notifications by putting a warning banner in the admin console.

incident-response/index.md

@@ -26,7 +26,7 @@ All employees should watch for potentially suspicious activities, including:
 * Modification or defacement of websites
 * New open network ports on a system
 
-Tailscale regularly reviews logs for detecting and tracking attempted intrusions and other suspicious activity. These include git, cloud, networking, SaaS tool, and other infrastructure logs. 
+Tailscale regularly reviews logs for detecting and tracking attempted intrusions and other suspicious activity. These include git, cloud, networking, SaaS tool, and other infrastructure logs.
 
 The Security Review Team:
 
@@ -41,3 +41,7 @@ Tailscale’s Security Review Team reviews and responds to potential third-party
 ### Incident response and remediation
 
 If a suspected incident is detected, it should be responded to following the [Incident response process](http://go/incident-response-process).
+
+We respond to reported incidents, and resolve and determine impact as soon as possible. We do not provide guarantees on time to remediate.
+
+Confirmed incidents may be disclosed publicly per our [disclosure policy](/security-policies/incident-disclosure/).