security-audit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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

对于任何已发布的游戏来说，安全都不是可选选项。即使是单机游戏也存在存档篡改的风险途径。多人游戏则面临作弊风险、数据泄露隐患以及拒绝服务攻击的可能性。本skill会系统性地审计代码库中最常见的游戏安全问题，并生成优先级修复计划。

运行本skill的时机：

任何公开发布之前（是Polish → Release关卡的必填项）
启用任何在线/多人功能之前
实现任何从磁盘或网络读取数据的系统之后
收到安全相关漏洞报告时

输出文件：

production/security/security-audit-[date].md

Phase 1: Parse Arguments and Scope

阶段1：解析参数与确定范围

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

模式：

```
full
```
—— 覆盖所有类别（发布前推荐使用）
```
network
```
—— 仅针对网络/多人模式
```
save
```
—— 仅针对存档文件与序列化
```
input
```
—— 仅针对输入验证与注入
```
quick
```
—— 仅检查高风险项（速度最快，适合迭代使用）
无参数 —— 默认运行
```
full
```
模式

读取

.claude/docs/technical-preferences.md

以确定：

引擎与编程语言（影响需搜索的模式）
目标平台（影响适用的攻击面）
是否将多人/网络功能纳入审计范围

Phase 2: Spawn Security Engineer

阶段2：调用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.

通过Task调用

security-engineer

，传递以下信息：

审计范围/模式
技术偏好文档中的引擎与编程语言
所有源目录清单：
```
src/
```
、
```
assets/data/
```
以及所有配置文件

Security Engineer会针对6个类别执行审计（见阶段3）。在进入下一阶段前，需收集其完整的审计结果。

Phase 3: Audit Categories

阶段3：审计类别

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

Security Engineer会评估以下每个类别。跳过与项目范围不相关的类别。

Category 1: Save File and Serialization Security

类别1：存档文件与序列化安全

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.

存档文件在加载前是否经过验证？（无盲反序列化）
存档文件路径是否由用户输入构造？（存在路径遍历风险）
存档文件是否经过校验和计算或签名？（用于篡改检测）
游戏是否在未进行边界检查的情况下信任存档文件中的数值？
存档加载附近是否存在任何eval()或动态代码执行调用？

需搜索的模式：

File.open

、

load

、

deserialize

、

JSON.parse

、

from_json

、

read_file

—— 检查每个调用点的验证情况。

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

类别2：网络与多人模式安全（单机游戏可跳过）

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.

游戏状态是由服务器权威管控，还是由客户端决定结果？
传入的网络数据包是否经过大小、类型与值范围验证？
玩家位置与状态变更是否在服务器端进行验证？
任何网络调用是否有速率限制？
认证令牌是否处理正确（从不以明文传输）？
发布版本中是否暴露任何调试端点？

需搜索的模式：

recv

、

receive

、

PacketPeer

、

socket

、

NetworkedMultiplayerPeer

、

rpc

、

rpc_id

—— 检查每个调用点的验证情况。

Category 3: Input Validation

类别3：输入验证

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.

是否有任何玩家提供的字符串用于文件路径？（路径遍历风险）
是否有任何玩家提供的字符串未经过滤就被记录？（日志注入风险）
数值输入（如物品数量、角色属性）在使用前是否经过边界检查？
成就/统计数值在写入任何后端之前是否经过检查？

需搜索的模式：

get_input

、

Input.get_

、

input_map

、面向用户的文本字段 —— 检查验证情况。

Category 4: Data Exposure

类别4：数据泄露

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.

```
src/
```
或
```
assets/
```
中是否硬编码了任何API密钥、凭证或机密信息？
发布版本中是否包含调试符号或详细错误信息？
游戏是否会将敏感玩家数据记录到磁盘或控制台？
是否有任何内部文件路径或系统信息暴露给玩家？

需搜索的模式：

api_key

、

secret

、

password

、

token

、

private_key

、

DEBUG

、

print(

（面向发布版本的代码中）。

Category 5: Cheat and Anti-Tamper Vectors

类别5：作弊与防篡改途径

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.

游戏关键数值是否仅存储在内存中，而非易于编辑的文件中？
任何关键游戏进度标记（如“已购买DLC”）是否在服务器端进行验证？
针对多人模式是否有任何防护措施抵御内存编辑工具（如Cheat Engine等）？
排行榜/分数提交在被接受前是否经过验证？

注意：客户端反作弊在很大程度上无法强制执行。对于任何竞技类或付费类内容，应重点关注服务器端验证。

Category 6: Dependency and Supply Chain

类别6：依赖项与供应链

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.

是否使用了任何第三方插件或库？列出它们。
当前使用的插件版本是否存在已知CVE漏洞？
插件来源是否经过验证（官方市场、已审核的代码仓库）？

需搜索的目录：

addons/

、

plugins/

、

third_party/

、

vendor/

—— 列出所有外部依赖项。

Phase 4: Classify Findings

阶段4：分类审计结果

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

针对每个审计结果，分配以下属性：

严重程度：

级别	定义
CRITICAL（关键）	远程代码执行、数据泄露，或可轻易利用的作弊行为，破坏多人模式完整性
HIGH（高）	可绕过进度限制的存档篡改、凭证泄露，或服务器端权限绕过
MEDIUM（中）	客户端作弊启用、信息泄露，或影响有限的输入验证漏洞
LOW（低）	纵深防御改进措施——减少攻击面的加固，但无直接可利用漏洞

状态： 未修复 / 已接受风险 / 超出范围

Phase 5: Generate Report

阶段5：生成报告

markdown

undefined

markdown

undefined

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]

日期：[date] 范围：[full | network | save | input | quick] 引擎：[engine + version] 审计者：security-engineer via /security-audit 扫描文件数：[N个源文件，N个配置文件]

Executive Summary

执行摘要

Severity	Count	Must Fix Before Release
CRITICAL	[N]	Yes — all
HIGH	[N]	Yes — all
MEDIUM	[N]	Recommended
LOW	[N]	Optional

Release recommendation: [CLEAR TO SHIP / FIX CRITICALS FIRST / DO NOT SHIP]

严重程度	数量	发布前必须修复
CRITICAL	[N]	是——全部修复
HIGH	[N]	是——全部修复
MEDIUM	[N]	推荐修复
LOW	[N]	可选修复

发布建议：[可发布 / 先修复关键项 / 禁止发布]

CRITICAL Findings

关键（CRITICAL）审计结果

SEC-001: [Title]

SEC-001: [标题]

Category: [Save / Network / Input / Data / Cheat / Dependency] File:

[path]

line [N] Description: [What the vulnerability is] Attack scenario: [How a malicious user would exploit it] Remediation: [Specific code change or pattern to apply] Effort: [Low / Medium / High]

[repeat per finding]

类别：[存档 / 网络 / 输入 / 数据 / 作弊 / 依赖项] 文件：

[path]

第[N]行描述：[漏洞内容] 攻击场景：[恶意用户如何利用该漏洞] 修复方案：[具体代码修改或需应用的模式] 修复工作量：[低 / 中 / 高]

[每个结果重复上述格式]

HIGH Findings

高风险（HIGH）审计结果

[same format]

[同上述格式]

MEDIUM Findings

中风险（MEDIUM）审计结果

[same format]

[同上述格式]

LOW Findings

低风险（LOW）审计结果

[same format]

[同上述格式]

Accepted Risk

已接受风险

[Any findings explicitly accepted by the team with rationale]

[团队明确接受的任何结果及理由]

Dependency Inventory

依赖项清单

Plugin / Library	Version	Source	Known CVEs
[name]	[version]	[source]	[none / CVE-XXXX-NNNN]

插件 / 库	版本	来源	已知CVE漏洞
[名称]	[版本]	[来源]	[无 / CVE-XXXX-NNNN]

Remediation Priority Order

修复优先级排序

[SEC-NNN] — [1-line description] — Est. effort: [Low/Medium/High]
...

[SEC-NNN] —— [一行描述] —— 预估工作量：[低/中/高]
...

Re-Audit Trigger

重新审计触发条件

Run

/security-audit

again after remediating any CRITICAL or HIGH findings. The Polish → Release gate requires this report with no open CRITICAL or HIGH items.

---

修复任何CRITICAL或HIGH风险项后，需重新运行

/security-audit

。Polish → Release关卡要求本报告中无未修复的CRITICAL或HIGH风险项。

---

Phase 6: Write Report

阶段6：编写报告

Present the report summary (executive summary + CRITICAL/HIGH findings only) in conversation.

Ask: "May I write the full security audit report to

production/security/security-audit-[date].md

Write only after approval.

在对话中呈现报告摘要（仅执行摘要 + CRITICAL/HIGH风险结果）。

询问：“是否允许我将完整的安全审计报告写入

production/security/security-audit-[date].md

？”

仅在获得批准后再写入文件。

Phase 7: Gate Integration

阶段7：关卡集成

This report is a required artifact for the Polish → Release gate.

After remediating findings, re-run:

/security-audit quick

to confirm CRITICAL/HIGH items are resolved before running

/gate-check release

If CRITICAL findings exist:

"⛔ CRITICAL security findings must be resolved before any public release. Do not proceed to
/launch-checklist
until these are addressed."

If no CRITICAL/HIGH findings:

"✅ No blocking security findings. Report written to
production/security/
. Include this path when running
/gate-check release
."

本报告是Polish → Release关卡的必填交付物。

修复审计结果后，重新运行：

/security-audit quick

以确认CRITICAL/HIGH风险项已解决，然后再运行

/gate-check release

。

若存在CRITICAL风险项：

"⛔ 关键安全问题必须在公开发布前解决。在解决这些问题前，不要运行
/launch-checklist
。"

若不存在CRITICAL/HIGH风险项：

"✅ 无阻塞性安全问题。报告已写入
production/security/
。运行
/gate-check release
时请包含此路径。"

Collaborative Protocol

协作规则

Never assume a pattern is safe — flag it and let the user decide
Accepted risk is a valid outcome — some LOW findings are acceptable trade-offs for a solo team; document the decision
Multiplayer games have a higher bar — any HIGH finding in a multiplayer context should be treated as CRITICAL
This is not a penetration test — this audit covers common patterns; a real pentest by a human security professional is recommended before any competitive or monetised multiplayer launch

切勿假设任何模式是安全的 —— 标记出来并让用户决定
接受风险是合理结果 —— 对于独立团队来说，一些LOW风险项是可接受的权衡；需记录决策过程
多人游戏有更高要求 —— 多人模式中的任何HIGH风险项都应视为CRITICAL
这并非渗透测试 —— 本审计仅覆盖常见模式；在任何竞技类或付费多人模式发布前，建议由专业安全人员进行真正的渗透测试