review-security

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Security Fitness Review

安全健康度审查

Analyze the codebase (or specified files/modules) for security fitness.

Reference: Fundamentals of Software Security — see also Fundamentals of Privacy and Compliance and Fundamentals

分析代码库（或指定文件/模块）的安全健康度。

参考：Fundamentals of Software Security——另见 Fundamentals of Privacy and Compliance 和 Fundamentals。

Domain Knowledge

领域知识

```
references/rubric.md
```
is the scoring source: severity definitions, 1-10 anchors per dimension, the N/A rule, and the overall-score formula. It is short; read it first so scores are repeatable across runs.
```
references/checklist.md
```
is what to check during each workflow step, including section 9 (CI/CD and containers) with ready-made grep patterns.
```
references/wisdom.md
```
is optional background, auto-synced from the two articles above. It has no rubric. Grep it by heading for a specific question (
```
grep -n '^##' references/wisdom.md
```
); never read it whole, it is about 15k tokens.

```
references/rubric.md
```
是评分依据：包含严重性定义、各维度 1-10 分的锚点、N/A 规则和总分计算公式。它篇幅很短；应先阅读，以确保多次运行所得评分具有一致性。
```
references/checklist.md
```
包含每个工作流步骤需要检查的内容，其中第 9 节涉及 CI/CD 和容器，并提供了可直接使用的 grep 模式。
```
references/wisdom.md
```
是可选的背景资料，会从上述两篇文章自动同步而来。它不包含评分标准。按标题使用 Grep 查找特定问题（
```
grep -n '^##' references/wisdom.md
```
）；不要全文读取，因为它约有 15k tokens。

Configuration

配置

Invoke the resolver CLI to obtain the effective

security.confidenceThreshold

. Never load

fitness-config.json

directly.

bash

python3 "${CLAUDE_SKILL_DIR}/../../scripts/fitness-config.py" show --path <target>

${CLAUDE_SKILL_DIR}

is this skill's directory; the resolver ships two levels up in the plugin's

scripts/

. If your agent does not expand the variable, substitute the directory containing this

SKILL.md

Read

effective.security.confidenceThreshold

from the JSON block delimited by

<!-- BEGIN_EFFECTIVE_CONFIG_JSON -->

<!-- END_EFFECTIVE_CONFIG_JSON -->

. The default is 7. Include the

Config:

and

Effective weights:

lines from the resolver within the first 10 lines of the report as the provenance trail (AC-03.1, AC-08.2).

调用 resolver CLI 获取生效的

security.confidenceThreshold

。绝不直接加载

fitness-config.json

。

bash

python3 "${CLAUDE_SKILL_DIR}/../../scripts/fitness-config.py" show --path <target>

${CLAUDE_SKILL_DIR}

是此 skill 所在目录；resolver 位于插件

scripts/

中上两级位置。如果你的 agent 无法展开该变量，请替换为包含此

SKILL.md

的目录。

从由

<!-- BEGIN_EFFECTIVE_CONFIG_JSON -->

<!-- END_EFFECTIVE_CONFIG_JSON -->

界定的 JSON 块中读取

effective.security.confidenceThreshold

。默认值为 7。将 resolver 输出中的

Config:

和

Effective weights:

行包含在报告前 10 行内，作为来源追踪记录（AC-03.1、AC-08.2）。

Workflow

工作流

Load the rubric — Read
```
references/rubric.md
```
, and skim the section headings of
```
references/checklist.md
```
so you know where each step's checks live.
Identify scope and threat surface — Use Grep/Glob to find request handlers, API endpoints, authentication flows, data access layers, form handlers, configuration files, dependency manifests,
```
.github/workflows/
```
,
```
Dockerfile*
```
, and
```
docker-compose*.yml
```
. Map the attack surface: external inputs (including issue/PR text that workflows consume), trust boundaries, data stores, third-party integrations. For very large generated files (e.g. compiled workflow lock files), grep for expressions,
```
permissions:
```
, and
```
uses:
```
rather than reading them end to end.
Decide applicability — For each of the six dimensions, decide whether anything in scope can be evaluated. Mark the rest
```
N/A — <reason>
```
per rubric.md. A workflows-only target usually scores Input Validation, Auth/Authz (token scope), Dependency Security (action pinning), and Cryptography only if secrets are handled.
Run scanners that are installed — Check with
```
command -v
```
and run what exists; scanner output is evidence, not a verdict, so confirm each hit in the code:
- Secrets:
```
gitleaks detect --no-banner --redact -s <target>
```
  (always
```
--redact
```
  ).
- Dependencies:
```
pip-audit -r requirements.txt
```
  ,
```
npm audit --omit=dev
```
  (needs a lock file), or
```
osv-scanner -r <target>
```
  .
- Workflows:
```
zizmor <target>/.github/workflows
```
  ;
```
actionlint
```
  if zizmor is absent.
If none is installed, review manually and label CVE claims "unverified (no scanner available)". Name the scanners you ran, or that none were available, in the report.
Analyze input handling — Trace user-supplied data from each entry point to SQL, shell, HTML, file paths, deserializers, and outbound URLs (checklist section 1). Before flagging, confirm the input is attacker-controlled and reaches the sink without validation; do not flag code that already validates (length/type checks, allowlists) as a vulnerability.
Audit CI/CD and containers — Apply checklist section 9. Run its greps for
```
${{ github.event.* }}
```
/
```
github.head_ref
```
inside
```
run:
```
or
```
github-script
```
,
```
pull_request_target
```
with a head checkout, workflow-level or missing
```
permissions:
```
, third-party
```
uses:
```
not pinned to a SHA, missing
```
persist-credentials: false
```
, and Dockerfile
```
USER
```
,
```
ENV
```
secrets, debug
```
CMD
```
, and
```
:latest
```
bases. Choice/boolean
```
inputs.*
```
and
```
github.sha
```
-style contexts are not injection.
Audit authentication and authorization — Checklist sections 2 and 3: password hashing, session management, tokens, authorization on every route, IDOR.
Evaluate data protection and privacy — Checklist sections 4 and 8: where PII and credentials are collected, stored, transmitted, logged; retention and deletion.
Scan dependency security — Checklist section 5: lock files, pinning, scanner results from step 4, supply chain.
Review error handling and logging — Checklist section 6: error responses leak nothing internal, security events are logged, failures deny.
Assess cryptography and secrets — Checklist section 7: algorithms, RNG, TLS, and hardcoded secrets (grep for
```
api_key|secret|token|password|BEGIN .*PRIVATE KEY
```
assigned to literals). Follow the secrets rule below.
Score each dimension with the anchors in
```
references/rubric.md
```
and file:line evidence. Compute the overall per rubric.md, including the CRITICAL cap.
Self-check, then write the report — Before writing, confirm: every cited file:line exists and says what the finding claims; every finding has confidence at or above the threshold; the overall equals the stated computation (and the cap is applied if any CRITICAL exists); no secret value appears anywhere in the report.

加载评分标准——读取
```
references/rubric.md
```
，并快速浏览
```
references/checklist.md
```
的章节标题，以了解每个步骤的检查项所在位置。
确定范围和威胁面——使用 Grep/Glob 查找请求处理器、API 端点、身份验证流程、数据访问层、表单处理器、配置文件、依赖清单、
```
.github/workflows/
```
、
```
Dockerfile*
```
和
```
docker-compose*.yml
```
。梳理攻击面：外部输入（包括工作流使用的 issue/PR 文本）、信任边界、数据存储和第三方集成。对于非常庞大的生成文件（例如已编译的工作流 lock 文件），应 grep 表达式、
```
permissions:
```
和
```
uses:
```
，而不是从头到尾读取。
判定适用性——针对六个维度中的每一个，判断范围内是否有可评估的内容。按照 rubric.md，将其余维度标记为
```
N/A — <reason>
```
。仅包含工作流的目标通常需要评估输入验证、Auth/Authz（Token 范围）和依赖安全（Action 固定），并且只有在处理 Secrets 时才评估密码学。
运行已安装的扫描器——使用
```
command -v
```
检查并运行现有扫描器；扫描器输出只是证据，不是最终结论，因此必须在代码中逐项确认每个命中项：
- Secrets：
```
gitleaks detect --no-banner --redact -s <target>
```
  （始终使用
```
--redact
```
  ）。
- Dependencies：
```
pip-audit -r requirements.txt
```
  、
```
npm audit --omit=dev
```
  （需要 lock file），或
```
osv-scanner -r <target>
```
  。
- Workflows：
```
zizmor <target>/.github/workflows
```
  ；如果没有 zizmor，则使用
```
actionlint
```
  。
如果没有安装任何扫描器，则进行人工审查，并将 CVE 声明标记为
```
unverified (no scanner available)
```
。报告中应列出已运行的扫描器，或注明没有可用的扫描器。
分析输入处理——从每个入口点追踪用户提供的数据，直至 SQL、shell、HTML、文件路径、反序列化器和出站 URL（checklist 第 1 节）。在标记问题前，确认输入受攻击者控制且未经验证即可到达 sink；不要把已经实施验证的代码（长度/类型检查、allowlist）标记为漏洞。
审查 CI/CD 和容器——应用 checklist 第 9 节。执行其中的 grep，检查
```
run:
```
或
```
github-script
```
内的
```
${{ github.event.* }}
```
/
```
github.head_ref
```
、带 head checkout 的
```
pull_request_target
```
、工作流级或缺失的
```
permissions:
```
、未固定到 SHA 的第三方
```
uses:
```
、缺失的
```
persist-credentials: false
```
，以及 Dockerfile
```
USER
```
、
```
ENV
```
Secrets、调试用
```
CMD
```
和
```
:latest
```
基础镜像。Choice/boolean 类型的
```
inputs.*
```
和
```
github.sha
```
风格的上下文不是注入问题。
审计身份验证和授权——checklist 第 2 和第 3 节：密码哈希、会话管理、Token、每条路由上的授权检查和 IDOR。
评估数据保护和隐私——checklist 第 4 和第 8 节：PII 和凭据在哪里被收集、存储、传输和记录；保留期限和删除机制。
扫描依赖安全——checklist 第 5 节：lock file、已知漏洞、版本固定、第 4 步的扫描器结果和供应链安全。
审查错误处理和日志——checklist 第 6 节：错误响应不得泄露内部信息、安全事件应被记录、失败时必须默认拒绝（fail-secure），以及部署配置中是否存在调试服务器。
评估密码学和 Secrets——checklist 第 7 节：算法、RNG、TLS 和硬编码 Secrets（grep 查找被赋为字面量的
```
api_key|secret|token|password|BEGIN .*PRIVATE KEY
```
）。遵循下述 Secrets 规则。
对每个维度评分——依据
```
references/rubric.md
```
中的锚点进行评分，并提供 file:line 证据。按照 rubric.md 计算总分，包括应用 CRITICAL 上限。
自查，然后撰写报告——撰写前确认：每个引用的 file:line 均存在且内容与发现一致；每项发现的置信度均达到或超过阈值；总分等于所述计算结果（若存在任何 CRITICAL，则已应用上限）；报告任何位置均未出现 Secret 值。

Secrets rule

Secrets 规则

Reports land in the repository and get shared, so a reproduced secret is a second leak.

Never reproduce a secret value, in full or in part beyond a provider prefix (e.g.
```
sk-...
```
,
```
AKIA...
```
). Cite it by file:line and variable name only. In Evidence, show the line with the value replaced by
```
<redacted>
```
.
Always recommend rotating the credential, not only removing it: once committed, it lives in git history and any clones. Mention history rewriting (
```
git filter-repo
```
) as optional follow-up, never as a substitute for rotation.
Recommend loading the value from the environment or a secrets manager, and adding a secret scanner (gitleaks) to pre-commit or CI.

报告会保存在仓库中并被共享，因此复现 Secret 本身就会造成二次泄露。

绝不复现 Secret 值；无论是完整值还是超出 provider 前缀的部分，都不得展示（例如仅可展示
```
sk-...
```
、
```
AKIA...
```
这样的 provider 前缀）。仅通过 file:line 和变量名进行引用。在 Evidence 中，显示将该值替换为
```
<redacted>
```
后的行。
始终建议轮换凭据，而不只是将其删除：一旦提交，它就会留在 git history 和所有 clone 中。可以提及历史重写（
```
git filter-repo
```
）作为可选后续操作，但绝不能以此替代凭据轮换。
建议从环境或 secrets manager 加载该值，并将 Secret 扫描器（gitleaks）添加到 pre-commit 或 CI 中。

Confidence and Severity

置信度和严重性

Only report findings with confidence >= 7/10 (or the resolver's threshold). For each finding, assess:

Is this a real pattern in the code, not a guess about runtime behavior?
Can you point to a specific file and line?
Is the vulnerable pattern actually reachable from an external input?

If any answer is no, do not report it. It is better to miss a theoretical issue than to flood the report with noise.

Severity levels (CRITICAL, HIGH, MEDIUM, LOW) and their domain examples are defined in

references/rubric.md

. Any CRITICAL finding caps the overall score at 4.0, so a repository-takeover bug cannot hide behind good scores elsewhere.

仅报告置信度 >= 7/10（或 resolver 输出的阈值）的发现。对于每项发现，评估：

这是代码中真实存在的模式，而不是对运行时行为的猜测吗？
能否指向具体的文件和行？
存在漏洞的模式是否确实可从外部输入到达？

如果任一答案为否，则不要报告。漏报理论问题优于用噪声淹没报告。

严重性级别（CRITICAL、HIGH、MEDIUM、LOW）及其领域示例在

references/rubric.md

中定义。任何 CRITICAL 发现都会将总分限制在 4.0，因此导致仓库接管的漏洞不能被其他方面的高分掩盖。

Scoring Dimensions (1-10 each)

评分维度（每项 1-10 分）

Anchors for each score band are in

references/rubric.md

; the checks behind them are in

references/checklist.md

Input Validation — SQL injection, command injection, XSS, path traversal, XXE, deserialization, SSRF, and GitHub Actions expression injection
Authentication and Authorization — Password hashing, session management, token handling, authorization enforcement, IDOR, privilege escalation, CI token permissions and
```
pull_request_target
```
Data Protection — PII handling, encryption at rest and in transit, log redaction, data minimization, retention, and deletion
Dependency Security — Lock files, known vulnerabilities, version pinning, supply chain, action and base-image pinning
Error Handling and Logging — Error response sanitization, security event logging, fail-secure behavior, debug servers in deploy config
Cryptography — Algorithm choices, key and secrets management (including hardcoded secrets), random number generation, TLS configuration

各分数区间的锚点位于

references/rubric.md

，对应的检查项位于

references/checklist.md

。

输入验证——SQL 注入、命令注入、XSS、路径遍历、XXE、反序列化、SSRF 和 GitHub Actions 表达式注入
身份验证和授权——密码哈希、会话管理、Token 处理、授权执行、IDOR、权限提升、CI Token 权限和
```
pull_request_target
```
数据保护——PII 处理、静态和传输中加密、日志脱敏、数据最小化、保留和删除
依赖安全——lock file、已知漏洞、版本固定、供应链、Action 和基础镜像固定
错误处理和日志——错误响应净化、安全事件日志记录、fail-secure 行为、部署配置中的调试服务器
密码学——算法选择、密钥和 Secrets 管理（包括硬编码 Secrets）、随机数生成和 TLS 配置

Output Format

输出格式

Write the report to

docs/security-review.md

at the root of the repository that contains the target, unless the user gives a path. For a review scoped to a subdirectory or file set, write

docs/security-review-<scope-slug>.md

(e.g.

docs/security-review-github.md

for

.github/

) so a scoped run does not replace the whole-repo report.

markdown

undefined

除非用户提供路径，否则将报告写入目标仓库根目录的

docs/security-review.md

。对于范围限定到子目录或文件集的审查，将报告写入

docs/security-review-<scope-slug>.md

（例如，针对

.github/

使用

docs/security-review-github.md

），以确保限定范围的运行不会覆盖整个仓库的报告。

markdown

undefined

Security Fitness Review

Target: <path(s) or scope reviewed> Config: <copied from resolver output> Effective weights: <copied from resolver output> Scanners: <tools run, or "none installed; manual review">

Direct Answer

(Only if the user asked a specific question, e.g. "is this workflow safe to merge?": answer it in 1-3 sentences, citing the finding numbers.)

Summary

Overall fitness score: X.X / 10 (mean of <list of scored dimensions>; capped at 4.0 due to CRITICAL finding N, if applicable) Status: Healthy / Needs Attention / Critical

Dimension	Score	Key Finding
Input Validation	X/10	...
Authentication/Authorization	X/10	...
Data Protection	X/10 or N/A — reason	...
Dependency Security	X/10	...
Error Handling/Logging	X/10	...
Cryptography	X/10 or N/A — reason	...

Overall fitness score: X.X / 10 (mean of <list of scored dimensions>; capped at 4.0 due to CRITICAL finding N, if applicable) Status: Healthy / Needs Attention / Critical

Dimension	Score	Key Finding
Input Validation	X/10	...
Authentication/Authorization	X/10	...
Data Protection	X/10 or N/A — reason	...
Dependency Security	X/10	...
Error Handling/Logging	X/10	...
Cryptography	X/10 or N/A — reason	...

Detailed Findings

Finding 1: [Title]

Severity: CRITICAL / HIGH / MEDIUM / LOW
Confidence: X/10
Dimension: [which scoring dimension]
Location: file:line
Description: What the vulnerability is and why it matters.
Evidence: The code pattern found, with any secret value replaced by
```
<redacted>
```
.
Exploit scenario: How an attacker could exploit this in practice.
Remediation: Concrete fix with code example or specific steps (for secrets: rotate first).

(repeat for each finding, ordered by severity)

Severity: CRITICAL / HIGH / MEDIUM / LOW
Confidence: X/10
Dimension: [which scoring dimension]
Location: file:line
Description: What the vulnerability is and why it matters.
Evidence: The code pattern found, with any secret value replaced by
```
<redacted>
```
.
Exploit scenario: How an attacker could exploit this in practice.
Remediation: Concrete fix with code example or specific steps (for secrets: rotate first).

(repeat for each finding, ordered by severity)

Input Validation (X/10)

Evidence: file:line references (for an absence, cite where it should be, e.g.
```
.github/workflows/ (none)
```
)
Issues found
Recommendations

(repeat for each scored dimension; one line for each N/A dimension)

Evidence: file:line references (for an absence, cite where it should be, e.g.
```
.github/workflows/ (none)
```
)
Issues found
Recommendations

(repeat for each scored dimension; one line for each N/A dimension)

Action Items (up to 5, by impact)

[CRITICAL/HIGH/MEDIUM] Description -- file:line
...

[CRITICAL/HIGH/MEDIUM] Description -- file:line
...

Reference

Based on Fundamentals of Software Security, Fundamentals of Privacy and Compliance, and guidance from https://jeffbailey.us/categories/fundamentals/

undefined

Based on Fundamentals of Software Security, Fundamentals of Privacy and Compliance, and guidance from https://jeffbailey.us/categories/fundamentals/

undefined