# Security Policy

_Last updated: 2026-06-24_

DunceLab is a learning app that also handles **accounts and payments** (via Stripe). We take
security reports seriously and appreciate responsible disclosure.

## Reporting a vulnerability

Please do **not** open a public issue for security problems.

- Preferred: GitHub's private **"Report a vulnerability"** (repo **Security** tab → Advisories).
- Or email **Contact@SwrlSite.com** with details and steps to reproduce.

We aim to acknowledge within **3 business days** and to keep you updated until it's resolved.
Please give us a reasonable window to fix before any public disclosure.

## Especially sensitive areas

- The **backend** (`backend/`, Django + DRF): auth (email magic-link / Google OAuth), the Stripe
  billing + webhook flow, and the AI-review → auto-merge PR pipeline.
- **Secrets never live in the repo.** They exist only as environment variables on the host
  (Railway). `backend/.env.example` is a template of *empty* values. If you ever find a real key
  committed anywhere — including git history — treat it as an incident: report it, then rotate it.
- The support payment links in the app (`buy.stripe.com`) are **public Stripe
  Payment Links** by design. They are **not** secrets.

## Out of scope

- Issues requiring physical access to a user's unlocked device.
- Missing best-practice headers without a demonstrated exploit.
- Findings only reproducible against an unauthorized copy or unrelated deployment.

## Safe harbor

We want good-faith security research to feel safe, not risky. If you test in line with this policy,
we **will not pursue or support legal action against you**, and we **will not treat your research as
a violation of our Terms of Service** (see TERMS.md, Acceptable use). We consider research and
disclosure that follows this policy to be **authorized** for purposes of the Computer Fraud and
Abuse Act (CFAA), the DMCA's anti-circumvention rules, and applicable state computer-crime law
(including Tennessee's). This is a commitment we make on our own behalf; it cannot waive the rights
of anyone else, and it does not override criminal law.

To qualify, please keep your research good-faith and within these limits:

- **Stay in scope.** Work within the areas above and respect the "Out of scope" list.
- **Use only your own test accounts and data.** Don't access, change, or keep other users'
  information beyond the minimum needed to demonstrate the issue, and delete any such data once
  you've confirmed the bug.
- **Do no harm.** Avoid privacy violations, data destruction, service degradation or denial of
  service, and spamming.
- **No social engineering or physical attacks.** Don't phish or target our staff, users, or
  contractors, and don't attempt physical access to any systems or offices.
- **Report promptly and privately**, and give us a reasonable time to remediate before any public
  disclosure (see "Reporting a vulnerability" above).

This safe harbor covers DunceLab and Swrl LLC only. It does **not** authorize testing against our
third-party providers — **Stripe, Railway, Google, and Anthropic** — whose own programs and rules
govern any research on their systems.

If you're unsure whether something is in scope or allowed, email us at **Contact@SwrlSite.com**
**before** you test. We're happy to clarify and to work with you.

## Maintainer guardrails

- **Branch protection on `main`:** require a PR review (including **Code Owners** — see
  `.github/CODEOWNERS`), require the **Verify** gate to pass, and disallow force-push.
- **Actions:** restrict workflow execution and secret access to authorized collaborators.
- **Auto-merge boundary:** the autonomous AI pipeline may only touch `sims/**` spec files — **never**
  `backend/**`, `.github/**`, `config.js`, or payment code. Those paths require a human reviewer.
- Workflows that hold secrets must trigger on `schedule` / `workflow_dispatch` only — never on
  `pull_request_target` with a checkout of untrusted code.