docs(security): rewrite SECURITY.md with scope, SLA, severity table, and advisory template

[V1ctor-o]

Summary

Complete rewrite of docs/reference/SECURITY.md, which previously only described a generic vulnerability disclosure policy with a placeholder contact ([INSERT SECURITY EMAIL OR TG HANDLE]) and no scope, SLA, or severity definitions. Adds a new .github/SECURITY_ADVISORY_TEMPLATE.md for use with GitHub's private vulnerability reporting feature.

What changed

Scope (new)

Explicit in-scope / out-of-scope lists, VaultDAO-specific rather than generic:

• In scope: contract auth/role bypasses, timelock/spending-limit bypasses, integer overflow affecting balances, double-execution, cross-contract call risks, governance bypasses, backend/frontend issues with on-chain consequences, exploitable dependency vulnerabilities.
• Out of scope: gas optimization, UX issues, physical-access attacks, social engineering/phishing itself (as opposed to a flow that enables it), issues already tracked in AUDIT_SCOPE.md, and devnet-only issues that don't reflect real network behavior.

Reporting process (new)

• Primary channel: GitHub private vulnerability reporting (Security tab → Advisories → Report a vulnerability) — verified against GitHub's actual documentation for how this feature works and how it relates to SECURITY.md (they're independent; one doesn't imply the other is configured).
• Backup channel: email — left as an explicit [MAINTAINER ACTION REQUIRED] placeholder rather than a fabricated address, since no real security contact exists anywhere in this repo today (same gap as the existing placeholder in CODE_OF_CONDUCT.md).
• What a good report should include: description, affected component, reproduction steps, impact assessment, suggested fix (optional), reporter's own severity assessment.

Response SLA (new)

Calibrated against this repo's actual activity (checked: 169 unique contributors, 1,475 commits, 84 in the last 7 days) rather than picked arbitrarily:

• Acknowledgement: 48 hours
• Triage: 7 days
• Fix timelines by severity: Critical (best-effort 7–14 days post-triage), High (~30 days), Medium (next release cycle), Low (best-effort, no fixed deadline)

Deliberately does not promise sub-48-hour acknowledgement or guaranteed same-day fixes — the issue explicitly asked for realistic SLAs, and given how many structural bugs were found by hand across the last few PRs in this codebase, overpromising here seemed like the wrong call.

Severity classification table (new)

Critical / High / Medium / Low, each with a real, already-documented VaultDAO finding as the worked example (not generic web-security examples):

• Critical — the upgrade mechanism discarding the proposed WASM hash (AUDIT_SCOPE.md §1.6)
• High — unilateral signer-tier execution bypassing the timelock entirely (AUDIT_SCOPE.md §1.3)
• Medium — the spending-limit refund bucket-mismatch bug (AUDIT_SCOPE.md §1.4)
• Low — raw i128 arithmetic with no overflow-checks in the release profile (AUDIT_SCOPE.md §1.5)

Every AUDIT_SCOPE.md section reference was checked against the actual file before inclusion.

Responsible disclosure timeline (new)

Report → acknowledge → triage → fix → coordinated disclosure (default 30 days after fix ships) → public disclosure/CVE request, plus how an actively-exploited report changes the timeline.

Bug bounty section (new, explicitly TBD per issue instructions)

States plainly that no funded bounty program exists yet, what we can commit to today (public credit), and the four concrete things maintainers need to decide (qualifying severities, reward amounts, payment method, whether already-known AUDIT_SCOPE.md findings are bounty-eligible) before announcing one — rather than implying a program exists with vague placeholder numbers.

GitHub Security Advisory template (new file: .github/SECURITY_ADVISORY_TEMPLATE.md)

A copy-paste template for the description field of GitHub's native private vulnerability report form. Not placed under .github/ISSUE_TEMPLATE/ deliberately — vulnerability reports shouldn't be public issue templates, since that would defeat private disclosure.

Known gap — needs a maintainer action, not a code/doc fix

The email backup channel is left as an explicit placeholder ([MAINTAINER ACTION REQUIRED]) rather than a fabricated address. Whoever has repo admin access should either:

1. Enable Settings → Security → Private vulnerability reporting (making the GitHub-native flow fully functional — this is the bigger win, since it needs no email infrastructure at all), and/or
2. Provide a real, monitored security contact address to replace the placeholder.

I can't verify from outside the repo whether private vulnerability reporting is currently enabled — the doc includes a note telling readers how to tell, and instructs whoever enables it to remove that note once it's done.

Verification

• All AUDIT_SCOPE.md section cross-references checked against the actual file content
• SLA figures checked against real repo commit/contributor activity, not arbitrary
• Confirm whether GitHub private vulnerability reporting is actually enabled for this repo (Security tab → Advisories) — flagging for whoever has admin access, not blocking merge

Notes for reviewers

This is a documentation-only PR; no code changes. The one outstanding item (private vulnerability reporting toggle) is a repository setting only an org/repo admin can change — it's called out explicitly in the doc itself so it doesn't get silently missed.

Closes #1179

[drips-wave]

@V1ctor-o Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits