docs: add a security policy and fix the reporting instructions

[bloxster]

Why

The repo has no SECURITY.md, so GitHub has no policy to surface, and the only security contact anywhere in the project is a README line near the bottom pointing at security [at] torquem.ch — the pre-rename domain.

That leaves two paths that disagree with each other:

• Private vulnerability reporting is enabled and working on this repo, but nothing tells anyone it exists.
• The one written instruction points at a legacy-domain address a researcher has no way to verify is still monitored.

A researcher who finds something serious spends about a minute looking for how to report it. If what they find looks abandoned, the realistic outcomes are emailing the old address and waiting, posting publicly instead, or dropping it. Two of those three are bad for node operators.

For the record: a test message to security [at] torquem.ch went unanswered, so this PR drops the address rather than carrying it over. GitHub's private reporting is the sole documented route — the one channel confirmed to work. Advertising an address that did not answer a test would send reports into a void, which is the failure this PR exists to fix.

❓ Two things to confirm before merging

1) "We aim to acknowledge a report within three business days." This is the only promise in the file and nobody has agreed to it yet — picked as a defensible default. Please confirm, change the number, or drop the sentence.

For context on where that sits among the other clients:

	Response commitment
Nethermind	"we will work to acknowledge your report within 24 hours"
Besu	"patch within a reasonable amount of time"
Geth	none
Reth	none

Nethermind is the only one that commits to a number, and theirs is tighter. The phrasing here follows their softer "we aim to" form rather than stating a guarantee.

2) Do we want an email fallback, and at which address? @yperbasis @AskAlexSharov — leaving this one to you. Options:

• Ship as-is, GitHub-only. All four peers document an email address, so this would make Erigon the only one without one — in exchange, every route we document actually works. Reporters need a GitHub account.
• Create security@erigon.tech. The conventional choice, and what the original public-docs proposal asked for. Worth pointing at two or three people rather than one, so a report doesn't stall on a single inbox.
• Revive security@torquem.ch if someone still owns the domain and can confirm delivery.

This doesn't block merging: the policy is correct and safe without an email, and adding one later is a one-line change.

What this does

• SECURITY.md (new) — leads with Report a vulnerability, says what to include, sets expectations, and states which versions get fixes.
• README.md — the reporting section now points at the private route and the policy, instead of the bare stale address.

Shaped acc. to industry best practice

Rather than writing this from scratch, other EVM clients have been compared.

Consequences for this file:

• GitHub private reporting first matches Nethermind, the closest structural peer, which leads with the same button.
• No PGP key — only Geth has one, and it predates GitHub's private reporting. The advisory channel is already an encrypted private channel, so a key would add key-rotation maintenance for no gain.
• No audit-report section — Geth's is the one thing in this group nobody else has copied and it is a genuine trust signal, but Erigon has no external audits to publish. Worth adding the day that changes.
• Supported versions stated as a rule, not a version number, so it can't go stale: fixes land on main and the most recent release series. Geth's equivalent is "use the latest"; the other three say nothing.
• Kept short. At 29 lines this sits between Besu and Geth. An earlier draft ran 42 lines, which would have made it the second-longest policy in the peer group for no added substance.

Scope

Only main is touched, since it is the default branch and therefore backs both the repo landing page and the Security tab — the two places this needs to be right.

release/3.5 and release/3.6 carry the same stale README line, so anyone browsing tag v3.5.4 still sees it. That needs no separate effort: #22919 is already rewriting release/3.5's README and can carry the fix, and 3.6 picks it up on the next backlog port.

Testing

Docs-only; no code paths touched. Verified the GitHub links resolve and that no reference to the dropped address remains in either file.

🤖 Generated with Claude Code