Add a security model and trust boundary page #402

Summary

Web3Signer has no page describing its security model. Add a concept page that states the trust boundary, explains what Web3Signer protects against and what it does not, and describes the mitigations available to operators.

Suggested location: docs/concepts/security-model.md.

Why this is needed

Web3Signer holds validator keys, so the first question a security engineer, auditor, or prospective operator asks is what the threat model is. The documentation currently has no answer.

Two consequences follow. Readers evaluating Web3Signer cannot assess it from the official source, so they rely on analyses published by external parties, including vendors of competing products. And readers who need to harden a deployment have no single page telling them which risks are theirs to manage.

The underlying design involves a legitimate and well understood trade-off. Documenting it clearly, with the mitigations, is more useful and more credible than leaving it undocumented.

What the page should cover

The trust boundary. State plainly what Web3Signer defends against and what falls outside its control. Make clear which surrounding components are assumed to be trusted, including the host, the PostgreSQL slashing protection database, and any external vault or key management service.

Key material lifecycle. Explain where key material exists at each stage: encrypted at rest in a keystore or an external vault, and decrypted into process memory when loaded for signing. Explain what that means in practice for an attacker who gains host access, can read process memory, or can obtain a core dump or swap contents.

At rest versus in use. A vault or key management service protects keys at rest. It does not protect keys while they are being used to sign. This distinction is the core of the page and should be stated directly rather than implied.

Available mitigations. Cover the controls an operator can apply, and link to the page that explains how to configure each one rather than repeating the procedure. These include running Web3Signer inside a secure enclave, restricting the network interfaces the signing API binds to, host allowlisting, mutual TLS, disabling the key manager API when it is not needed, and running the distroless container image.

Slashing protection in context. Explain that slashing protection is a correctness control that prevents conflicting signatures. It is not an access control and does not protect key material.

Cross-link the finished page from the introduction, the architecture concept page, and the private key management best practices page.

Where to add the page

Verifying technical claims

This page carries more risk than most, because inaccurate security claims are worse than no security claims.

Do not state any behavior, default, option, or guarantee that you have not verified against the published reference or the Web3Signer source. Where a claim cannot be confirmed, flag it in the pull request for maintainer review rather than guessing. Statements about what Web3Signer does not protect against should be confirmed with a maintainer before publishing.