/security-audit

name: security-audit
description: "Audit the game for security vulnerabilities: save tampering, cheat vectors, network exploits, data exposure, and input validation gaps. Produces a prioritised security report with remediation guidance. Run before any public release or multiplayer launch."
argument-hint: "[full | network | save | input | quick]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Bash, Write, Task
model: sonnet
agent: security-engineer

Security Audit

Security is not optional for any shipped game. Even single-player games have save tampering vectors. Multiplayer games have cheat surfaces, data exposure risks, and denial-of-service potential. This skill systematically audits the codebase for the most common game security failures and produces a prioritised remediation plan.

**Run this skill:**

• Before any public release (required for the Polish → Release gate)
• Before enabling any online/multiplayer feature
• After implementing any system that reads from disk or network
• When a security-related bug is reported

**Output:** `production/security/security-audit-[date].md`

---

Phase 1: Parse Arguments and Scope

**Modes:**

• `full` — all categories (recommended before release)
• `network` — network/multiplayer only
• `save` — save file and serialization only
• `input` — input validation and injection only
• `quick` — high-severity checks only (fastest, for iterative use)
• No argument — run `full`

Read `.claude/docs/technical-preferences.md` to determine:

• Engine and language (affects which patterns to search for)
• Target platforms (affects which attack surfaces apply)
• Whether multiplayer/networking is in scope

---

Phase 2: Spawn Security Engineer

Spawn `security-engineer` via Task. Pass:

• The audit scope/mode
• Engine and language from technical preferences
• A manifest of all source directories: `src/`, `assets/data/`, any config files

The security-engineer runs the audit across 6 categories (see Phase 3). Collect their full findings before proceeding.

---

Phase 3: Audit Categories

The security-engineer evaluates each of the following. Skip categories not applicable to the project scope.

Category 1: Save File and Serialization Security

• Are save files validated before loading? (no blind deserialization)
• Are save file paths constructed from user input? (path traversal risk)
• Are save files checksummed or signed? (tamper detection)
• Does the game trust numeric values from save files without bounds checking?
• Are there any eval() or dynamic code execution calls near save loading?

Grep patterns: `File.open`, `load`, `deserialize`, `JSON.parse`, `from_json`, `read_file` — check each for validation.

Category 2: Network and Multiplayer Security (skip if single-player only)

• Is game state authoritative on the server, or does the client dictate outcomes?
• Are incoming network packets validated for size, type, and value range?
• Are player positions and state changes validated server-side?
• Is there rate limiting on any network calls?
• Are authentication tokens handled correctly (never sent in plaintext)?
• Does the game expose any debug endpoints in release builds?

Grep for: `recv`, `receive`, `PacketPeer`, `socket`, `NetworkedMultiplayerPeer`, `rpc`, `rpc_id` — check each call site for validation.

Category 3: Input Validation

• Are any player-supplied strings used in file paths? (path traversal)
• Are any player-supplied strings logged without sanitization? (log injection)
• Are numeric inputs (e.g., item quantities, character stats) bounds-checked before use?
• Are achievement/stat values checked before being written to any backend?

Grep for: `get_input`, `Input.get_`, `input_map`, user-facing text fields — check validation.

Category 4: Data Exposure

• Are any API keys, credentials, or secrets hardcoded in `src/` or `assets/`?
• Are debug symbols or verbose error messages included in release builds?
• Does the game log sensitive player data to disk or console?
• Are any internal file paths or system information exposed to players?

Grep for: `api_key`, `secret`, `password`, `token`, `private_key`, `DEBUG`, `print(` in release-facing code.

Category 5: Cheat and Anti-Tamper Vectors

• Are gameplay-critical values stored only in memory, not in easily-editable files?
• Are any critical game progression flags (e.g., "has paid for DLC") validated server-side?
• Is there any protection against memory editing tools (Cheat Engine, etc.) for multiplayer?
• Are leaderboard/score submissions validated before acceptance?

Note: Client-side anti-cheat is largely unenforceable. Focus on server-side validation for anything competitive or monetised.

Category 6: Dependency and Supply Chain

• Are any third-party plugins or libraries used? List them.
• Do any plugins have known CVEs in the version being used?
• Are plugin sources verified (official marketplace, reviewed repository)?

Glob for: `addons/`, `plugins/`, `third_party/`, `vendor/` — list all external dependencies.

---

Phase 4: Classify Findings

For each finding, assign:

**Severity:** | Level | Definition | |-------|-----------| | **CRITICAL** | Remote code execution, data breach, or trivially-exploitable cheat that breaks multiplayer integrity | | **HIGH** | Save tampering that bypasses progression, credential exposure, or server-side authority bypass | | **MEDIUM** | Client-side cheat enablement, information disclosure, or input validation gap with limited impact | | **LOW** | Defence-in-depth improvement — hardening that reduces attack surface but no direct exploit exists |

**Status:** Open / Accepted Risk / Out of Scope

---

Phase 5: Generate Report

# Security Audit Report

**Date**: [date]
**Scope**: [full | network | save | input | quick]
**Engine**: [engine + version]
**Audited by**: security-engineer via /security-audit
**Files scanned**: [N source files, N config files]

---

## Executive Summary

| Severity | Count | Must Fi