Add a security policy with a private reporting channel

The repository documented no way to report a vulnerability privately, so
anyone who found one had to guess at an address or open a public issue.
SECURITY.md now states the reporting address, what a useful report
contains, what a reporter can expect back and on what timing, the
disclosure default, what is in scope and what is already known and
accepted, and which branches receive fixes.

CHANGELOG.md

@@ -9,6 +9,12 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Added
 
+- `SECURITY.md`, stating a private channel for vulnerability reports, what a
+  useful report contains, what a reporter can expect back and on what timing,
+  and which branches receive fixes. The repository previously documented no
+  reporting channel at all, so someone with a finding had to guess at an
+  address or open a public issue.
+
 - `node.rate_limit.established_handshake_burst` and
   `node.rate_limit.established_handshake_rate`, the parameters of the new
   established-link msg1 token bucket. Both are optional; omitting them (the

SECURITY.md

@@ -0,0 +1,104 @@
+# Security Policy
+
+FIPS is a permissionless mesh: any node can peer with any other, and
+every node processes traffic from parties it has never met. Defects in
+that path are the ones we most want to hear about, and we would rather
+hear about them privately first.
+
+## Reporting a vulnerability
+
+**Email <johnathan@corganlabs.com>.** Please do not open a public issue
+for a suspected vulnerability, and please do not post one to a Nostr
+relay or a chat channel before we have had a chance to respond.
+
+Useful things to include, none of them required:
+
+- The commit hash or release tag the finding is against. FIPS moves
+  quickly across three branches, so a finding without a ref can be
+  expensive to place.
+- The file and line you read, and what you read there. A claim we can
+  open and check ourselves is worth several we have to reconstruct.
+- Whether you walked the path from an attacker-reachable entry point to
+  the defect, or inferred it. Both are welcome; knowing which saves time.
+- What an attacker needs: on-path position, an admitted peering
+  relationship, a signature from a key the node accepts, or nothing but
+  the ability to send a packet.
+- Any harness or tooling output, if the finding came from a scanner. Say
+  so either way; it changes how we read the citations, not whether we
+  take them seriously.
+
+Findings produced with automated or AI-assisted tooling are in scope and
+welcome. We ask only that you tell us what was machine-generated and what
+you checked yourself.
+
+## What to expect
+
+We will acknowledge a report within a few days and tell you whether we
+think the finding holds, in our own words, per item. Where we disagree
+with a severity we will say why rather than silently reclassifying it.
+Where a report is right and we had missed it, we will say that too.
+
+We do not run a bug bounty and cannot offer payment. We are glad to
+credit you in the changelog and the release notes for the fix, under
+whatever name or handle you prefer, and equally glad not to if you would
+rather stay anonymous.
+
+## Disclosure
+
+We would like to agree on timing with you rather than impose it. Our
+default is that a finding stays private until a fix is released on the
+affected branches, and that we do not sit on it indefinitely: if a fix is
+going to take a long time, we would rather say so and agree a date than
+let the clock run quietly.
+
+Please tell us in your report if you have a disclosure deadline in mind.
+If we have not responded at all within two weeks, treat that as a failure
+on our side and escalate however you see fit.
+
+## Scope
+
+In scope is anything in this repository: the `fips` daemon and its
+libraries, the control socket and CLI, the packaging under
+[packaging/](packaging/), and the CI workflows.
+
+Some things are known and accepted rather than undiscovered, and a report
+about them will get a pointer to the reasoning rather than a fix:
+
+- The protocol is not stable and has not had an independent cryptographic
+  audit. Wire format and session behavior still change between minor
+  versions.
+- The control socket authenticates by filesystem permission and, on
+  platforms without a Unix domain socket, by loopback binding. Where that
+  assumption is weaker than a local user boundary, it is documented at the
+  implementation.
+- A node that you have admitted as a peer is trusted to the extent the
+  protocol says it is. Findings about what an *admitted* peer can do are
+  still interesting; they are just a different class from what a stranger
+  can do, and it helps if you say which one you mean.
+
+Denial of service against a node by simply sending it a lot of traffic is
+not a finding. Amplification, where a small input costs the node or a
+third party a large amount, is.
+
+## Supported versions
+
+Fixes land on the oldest branch they apply to and are merged upward, so a
+fix for the maintenance line reaches all three.
+
+| Branch   | Version line | What it receives                        |
+| -------- | ------------ | --------------------------------------- |
+| `maint`  | 0.4.x        | Security and bug fixes                  |
+| `master` | 0.5.x        | Security and bug fixes, plus new work   |
+| `next`   | 0.6.x        | Development, including wire-format work |
+
+Released versions before the current maintenance line do not receive
+fixes. If you are running one, the fix will be to upgrade.
+
+## Security documentation
+
+[docs/reference/security.md](docs/reference/security.md) describes the
+security posture as built, and
+[docs/design/fips-security.md](docs/design/fips-security.md) covers the
+design reasoning behind it. Both are worth reading before reporting, but
+neither is a prerequisite: we would rather have a duplicate report than a
+missing one.