Skip to content

Security disclosure handling

961tech ships /.well-known/security.txt per ADR-0012 Q5. This runbook is the operational side: what to do when a real report lands.

Intake channels

In priority order: 1. GitHub Security Advisory (preferred) — private repo against Amine32/961tech. Threaded discussion + CVE assignment built in. 2. security@961tech.dev (mail-only) — for researchers who don't want a GitHub account. 3. Twitter/Mastodon DM, GitHub issue, IRC — best-effort. Politely redirect to the above.

Do not engage on public forums unless the disclosure is already public.

Triage SLA

Severity Initial ack First response Public disclosure
Critical (RCE, data loss, full account takeover) 24h 72h with fix plan 7d
High (auth bypass, IDOR, persistent XSS) 48h 7d with fix plan 30d
Medium (reflected XSS, info disclosure) 7d 30d 60d
Low (best-practice scanner output, theoretical) 14d 60d or "won't fix" n/a

These are aspirational at hobby scale. Document any miss in docs/postmortems/.

Severity scoring

Use CVSS 3.1 baseline. Adjust with: - +1 severity step if the bug touches affiliate attribution or click-token forgery (#99 territory) — those map to direct retailer-side money. - +1 severity step if the bug exposes hashed-IP click logs (the only PII we keep, per ADR-0014 D4).

Fix-or-disclose timeline

  • 0–7d: confirm reproducibility, file private GitHub Security Advisory, draft fix in private branch
  • 7–30d: ship fix, deploy, verify
  • 30–60d: public disclosure with researcher credit

Coordinate disclosure date with the reporter — never publish before they're ready unless they go silent.

Researcher credit

Maintain a public credits page at /transparency#code-of-conduct. Each entry: researcher name, advisory ID, severity, fix commit. Entries are append-only.

Out of scope (per security.txt)

  • DoS / volumetric attacks
  • Best-practice-scanner output without a working PoC
  • Self-XSS requiring console paste
  • Third-party retailer sites (we proxy public catalog data; their security is theirs)

When the bug is real and live in prod

  1. Roll back the deploy if the bug is exploitable AND a rollback is faster than a forward-fix
  2. File an incident postmortem under docs/postmortems/YYYY-MM-DD-<slug>.md
  3. Audit audit_log for evidence of exploitation in the affected window
  4. Notify users only if their data was demonstrably accessed (per future #40 obligations)

Bug bounty platform

ADR-0012 Q5 explicitly defers Bugcrowd / HackerOne until affiliate revenue justifies the spend. When MRR > $5k/mo, revisit; until then security.txt is the sole intake channel.

See also