Merge pull request #18 from TemujinCalidius/docs/security-and-disclosure

docs: add security policy + coordinated disclosure (SECURITY.md)

CONTRIBUTING.md

@@ -149,6 +149,10 @@ closes), so it's easy to see at a glance which problems are fixed and just waiti
 The label needs no cleanup: on merge the PR closes and any linked issue auto-closes via a
 `Closes #N` reference.
 
+**Closing multiple issues from one PR.** Give each issue its own keyword —
+`Closes #1, Closes #2` — not `Closes #1, #2`. GitHub only auto-links the number that directly
+follows a closing keyword, so the bare `#2` in the second form won't auto-close.
+
 ## Issue Templates
 
 File issues with the forms in `.github/ISSUE_TEMPLATE/`:
@@ -163,6 +167,13 @@ File issues with the forms in `.github/ISSUE_TEMPLATE/`:
 Open-ended questions and "how do I…?" go to
 [Discussions](https://github.com/TemujinCalidius/SurvivorCore/discussions), not Issues.
 
+## Reporting a security issue
+
+Found a vulnerability in the engine? **Don't open a public issue, PR, or discussion** — that
+discloses it to every game built on SurvivorCore before a fix exists. Report it privately via
+[**Security → Report a vulnerability**](https://github.com/TemujinCalidius/SurvivorCore/security/advisories/new).
+See [`SECURITY.md`](SECURITY.md) for the full coordinated-disclosure policy, supported versions, and scope.
+
 ## Architecture Overview
 
 SurvivorCore exposes two extension layers over a small foundation:

SECURITY.md

@@ -0,0 +1,67 @@
+# Security Policy
+
+Thanks for helping keep SurvivorCore — and the games built on it — safe.
+
+## Reporting a vulnerability
+
+**Please don't report security vulnerabilities through public GitHub issues, discussions, or
+pull requests** — a public report discloses the problem before a fix exists, and every game built
+on SurvivorCore inherits it.
+
+Instead, report it privately via GitHub's
+**[Report a vulnerability](https://github.com/TemujinCalidius/SurvivorCore/security/advisories/new)**
+form (the repo's **Security → Advisories → Report a vulnerability**). Only the maintainers can see it.
+
+Please include what you can:
+
+- the affected file(s) / module / version,
+- the impact and how it could be exploited (e.g. an exploit a malicious client could run against a
+  game that uses the engine),
+- steps to reproduce or a proof of concept,
+- any suggested fix.
+
+## What happens next
+
+SurvivorCore is small and mostly solo-maintained, so this is best-effort:
+
+1. We aim to **acknowledge** your report within a few days.
+2. We confirm the issue and develop a fix **privately**.
+3. We **release the fix first**, then publish a **GitHub Security Advisory** (requesting a CVE where
+   warranted) and **credit you** — unless you'd prefer to stay anonymous.
+
+We practice **coordinated disclosure**: please give us a reasonable window to ship a fix before
+disclosing publicly, so games already running the engine can update first.
+
+## Supported versions
+
+Security fixes ship against the **latest release** only. Keep your game current with the newest
+SurvivorCore release — bump the Wally dependency (`temujincalidius/survivorcore`) or re-import the
+latest `SurvivorCore.rbxm`.
+
+| Version | Supported |
+|---------|-----------|
+| Latest release | ✅ |
+| Anything older | ❌ — please update |
+
+## Scope
+
+SurvivorCore is an **engine consumed by independent games**, so each game is built and deployed
+separately.
+
+- **In scope:** vulnerabilities in the **SurvivorCore engine code in this repository** — anything
+  that puts a game built on the engine at risk (e.g. a server-side trust boundary the engine gets
+  wrong, or an exploitable default).
+- **Out of scope here:** a specific *game's* own code, content, or misconfiguration (including any
+  private game built on the engine), and bugs in third-party dependencies or Roblox itself (report
+  those upstream — though we're glad to hear about ones that materially affect SurvivorCore).
+
+A game built on SurvivorCore is also only as safe as its own server: **never trust the client** —
+validate every `RemoteEvent` / `RemoteFunction` argument server-side, keep secrets and keys out of
+client scripts, and run the latest engine release.
+
+## How we handle security internally
+
+Most hardening lands openly as normal issues and PRs, and we run **`selene` + `luau-lsp` static
+analysis** in CI plus a daily triage. (Luau isn't supported by GitHub CodeQL, so that static
+analysis is our code-scanning equivalent.) Genuinely sensitive, high-severity findings go through
+the private advisory process above instead, so a fix is available before any public disclosure.