ai-sdlc-security-testing

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

ai-sdlc-security-testing: Security Testing

ai-sdlc-security-testing：安全测试

Internal AI SDLC skill, not client-facing by default. Every rule below is important to follow. None of it can be skipped. Before producing the final artifact, confirm required inputs, target audience, missing facts, output format, and constraints when they are unclear. Do not invent missing information. Ask concise clarification questions when required inputs are absent.

内部AI SDLC技能，默认不面向客户。以下每条规则都必须遵守，无一例外。在生成最终产物前，若所需输入、目标受众、缺失信息、输出格式和约束条件不明确，请先确认这些内容。不得编造缺失信息。当所需输入缺失时，提出简洁的澄清问题。

0. Skill Card

0. 技能卡片

Skill name:
```
ai-sdlc-security-testing
```
Primary audience: Dev
Supporting audience: QA, Security, BA
Audience tags: Dev, QA, BA
SDLC stage: Security review / abuse-case validation
Purpose: Review AI SDLC diffs, endpoints, workflows, provider integrations, and configs for concrete security findings, abuse paths, trust-boundary failures, and missing security validation. When the output makes OWASP- or standards-based claims, verify them against current primary sources before presenting them as authoritative guidance.
Output: Security findings, trust-boundary analysis, standards-backed notes, validation gaps, and fixes

技能名称：
```
ai-sdlc-security-testing
```
主要受众：Dev
支持受众：QA、Security、BA
受众标签：Dev、QA、BA
SDLC阶段：安全审查 / 滥用场景验证
用途：审查AI SDLC的diff、端点、工作流、供应商集成和配置，找出具体的安全问题、滥用路径、信任边界失效以及缺失的安全验证。当输出内容涉及基于OWASP或标准的声明时，需先对照当前权威来源进行验证，再作为指导性内容呈现。
输出：安全问题、信任边界分析、基于标准的说明、验证缺口及修复方案

0.1 Required Inputs

0.1 必需输入

Security review target: diff, endpoint, workflow, commit, branch, or subsystem.
Identity, trust-boundary, data, provider, and state context.
Relevant specs and validation evidence when available.

安全审查目标：diff、端点、工作流、提交、分支或子系统。
身份、信任边界、数据、供应商和状态上下文。
相关规范和验证证据（如有）。

0.2 Clarification Rules

0.2 澄清规则

Ask concise questions before finalizing when role, artifact, requirements, scope, audience, or constraints are unclear.
If optional information is missing, mark it as
```
TBD
```
,
```
Not provided
```
, or
```
Assumption
```
instead of inventing it.
Separate confirmed facts from assumptions and open questions.
Do not proceed to downstream synthesis when a required upstream artifact or decision is missing.

当角色、产物、需求、范围、受众或约束条件不明确时，在最终确定前提出简洁的问题。
若可选信息缺失，标记为
```
TBD
```
、
```
未提供
```
或
```
假设
```
，不得编造。
将已确认事实与假设和未解决问题分开。
当所需的上游产物或决策缺失时，不得进行下游合成工作。

0.2.1 Flow Mode Flags

0.2.1 流程模式标志

Support two explicit execution flags:
```
--quick-flow
```
and
```
--full-flow
```
.
If both flags are supplied,
```
--full-flow
```
takes precedence because it is the stricter mode.
```
--quick-flow
```
: move fast, make high-quality progress with available context, avoid clarification questions unless continuing would create material product, security, compliance, data-loss, or irreversible implementation risk.
In
```
--quick-flow
```
, use documented assumptions, recommended defaults, existing repository patterns, and the nearest available artifact evidence; record important assumptions and decisions in
```
decision-log.md
```
.
In
```
--quick-flow
```
, run only focused checks that are directly relevant, cheap, and likely to catch regressions for the requested work; report any skipped broader checks as residual risk.
```
--full-flow
```
: ask concise clarification questions when inputs, scope, ownership, acceptance criteria, or decisions are unclear; do not silently assume material requirements.
In
```
--full-flow
```
, verify upstream and downstream artifacts, decision-log entries, traceability links, acceptance criteria, and validation evidence before finalizing.
In
```
--full-flow
```
, run or recommend the skill-appropriate gates, reviews, scripts, and validation commands needed for end-to-end confidence; document any blocked verification explicitly.
When neither flag is supplied, follow the skill default rules and choose the least risky behavior for the request size and domain.

支持两种明确的执行标志：
```
--quick-flow
```
和
```
--full-flow
```
。
若同时提供两个标志，
```
--full-flow
```
优先，因为它是更严格的模式。
```
--quick-flow
```
：快速推进，利用现有上下文开展高质量工作，除非继续执行会造成重大产品、安全、合规、数据丢失或不可逆的实施风险，否则避免提出澄清问题。
在
```
--quick-flow
```
模式下，使用已记录的假设、推荐默认值、现有仓库模式和最接近的可用产物证据；将重要假设和决策记录在
```
decision-log.md
```
中。
在
```
--quick-flow
```
模式下，仅运行与请求工作直接相关、成本低且可能发现回归问题的针对性检查；将所有跳过的更广泛检查报告为残留风险。
```
--full-flow
```
：当输入、范围、所有权、验收标准或决策不明确时，提出简洁的澄清问题；不得默认重要需求。
在
```
--full-flow
```
模式下，在最终确定前验证上游和下游产物、决策日志条目、可追溯性链接、验收标准和验证证据。
在
```
--full-flow
```
模式下，运行或推荐与技能匹配的关卡、审查、脚本和验证命令，以实现端到端的可信度；明确记录任何受阻的验证工作。
当未提供任何标志时，遵循技能默认规则，并根据请求规模和领域选择风险最低的行为。

0.3 Output Rules

0.3 输出规则

Keep output structured with headings and bullets.
Make findings, gaps, risks, and blockers explicit.
Tie recommendations to evidence from the provided artifact, repository,
```
specs-refiniment/<feature-name>/<file.md>
```
workspace, or user context.
Include role ownership when the output creates follow-up work for BA, QA, Dev, PM, or Delivery.
Return progress, completion, validation, and handoff summaries directly in the Codex response.

Before the final response, emit the

ai-sdlc-handoff/v1

contract with

result

blockers

next_required

, and

next_optional

; every action includes

reason

command

, and

expected_artifact

Do not create
```
summary.txt
```
,
```
*-summary.txt
```
, or another standalone summary file unless the user explicitly requests one.
Keep durable writes limited to the canonical lifecycle artifacts, decision log, human-readable index, and
```
_ai_sdlc
```
machine files.
Let shared helpers migrate legacy paths on the next write; never overwrite or manually merge divergent legacy and canonical files.

输出内容使用标题和项目符号保持结构化。
明确指出问题、缺口、风险和阻塞点。
将建议与提供的产物、仓库、
```
specs-refiniment/<feature-name>/<file.md>
```
工作区或用户上下文的证据关联起来。
当输出内容为BA、QA、Dev、PM或交付团队产生后续工作时，指定角色负责人。
在Codex响应中直接返回进度、完成情况、验证和交接摘要。

在最终响应前，发出包含

result

、

blockers

、

next_required

和

next_optional

的

ai-sdlc-handoff/v1

契约；每个操作都包含

reason

、

command

和

expected_artifact

。

除非用户明确要求，否则不得创建
```
summary.txt
```
、
```
*-summary.txt
```
或其他独立的摘要文件。
仅将持久化写入限制在规范生命周期产物、决策日志、人类可读索引和
```
_ai_sdlc
```
机器文件中。
让共享助手在下次写入时迁移旧路径；不得覆盖或手动合并不一致的旧文件和规范文件。

0.4 Artifact Routing

0.4 产物路由

Maintain a feature decision log whenever this skill records, resolves, changes, or depends on a product, delivery, QA, security, validation, branching, implementation, or rollout decision.
For PM, BA, QA, Delivery, discovery, planning, refinement, and readiness work, write decisions to
```
specs-refiniment/<feature-name>/decision-log.md
```
.
For developer implementation SDD work, write decisions to
```
specs/<feature-name>/decision-log.md
```
.
Each decision-log entry must include date, decision, context or evidence, options considered when relevant, owner, status, and links to affected artifacts, tasks, tests, or validation evidence.

Use this exact decision-log structure:

markdown

# Decision Log

| ID | Date | Status | Owner | Decision | Context/Evidence | Options Considered | Affected Artifacts | Validation/Trace Links |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| DEC-001 | YYYY-MM-DD | proposed / accepted / superseded / rejected | role or name | concise decision | source facts, artifact links, or evidence | option A; option B; recommended default | affected docs, tasks, code, tests, or rollout notes | requirement IDs, test IDs, validation commands, PRs, commits, or tickets |

Use
```
specs/
```
only for developer implementation SDD packages and repo-governance artifacts.
Do not place PM, BA, QA, Delivery, discovery, planning, refinement, or readiness outputs in
```
specs/
```
; those belong at
```
specs-refiniment/<feature-name>/<file.md>
```
.
When consuming
```
specs-refiniment/<feature-name>/<file.md>
```
, treat it as upstream refinement context and create or update
```
specs/
```
only when implementation work is explicitly in scope.

每当本技能记录、解决、更改或依赖产品、交付、QA、安全、验证、分支、实施或发布决策时，维护一个功能决策日志。
对于PM、BA、QA、交付、探索、规划、细化和准备工作，将决策写入
```
specs-refiniment/<feature-name>/decision-log.md
```
。
对于开发者实施SDD工作，将决策写入
```
specs/<feature-name>/decision-log.md
```
。
每个决策日志条目必须包含日期、决策、上下文或证据、相关备选方案（如有）、负责人、状态以及关联产物、任务、测试或验证证据的链接。

使用以下精确的决策日志结构：

markdown

# Decision Log

| ID | Date | Status | Owner | Decision | Context/Evidence | Options Considered | Affected Artifacts | Validation/Trace Links |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| DEC-001 | YYYY-MM-DD | proposed / accepted / superseded / rejected | role or name | concise decision | source facts, artifact links, or evidence | option A; option B; recommended default | affected docs, tasks, code, tests, or rollout notes | requirement IDs, test IDs, validation commands, PRs, commits, or tickets |

```
specs/
```
仅用于开发者实施SDD包和仓库治理产物。
不得将PM、BA、QA、交付、探索、规划、细化或准备工作的输出放在
```
specs/
```
中；这些内容应放在
```
specs-refiniment/<feature-name>/<file.md>
```
。
当使用
```
specs-refiniment/<feature-name>/<file.md>
```
时，将其视为上游细化上下文，仅当实施工作明确在范围内时才创建或更新
```
specs/
```
中的内容。

0.5 Feature State Machine

0.5 功能状态机

Maintain feature lifecycle state in TOON at

specs-refiniment/<feature-name>/_ai_sdlc/state.toon

for refinement work and

specs/<feature-name>/_ai_sdlc/state.toon

for implementation work.

Before executing this skill for a feature, check the state machine with

python3 skills/_shared/state_machine.py check --feature <feature-name> --skill <this-skill-name> --workspace <refinement|implementation> --quick-flow|--full-flow

When this skill starts durable work, mark it in progress with
```
begin
```
; when the skill's required artifact or review is complete, mark it done with
```
complete
```
and include
```
--artifacts <path>
```
plus
```
--decision-ref DEC-###
```
when a decision was involved.
In
```
--full-flow
```
, do not proceed when predecessor stages are incomplete, another lifecycle skill is active, or the state file reports a blocker.
In
```
--quick-flow
```
, a predecessor skip is allowed only when continuing is low risk and the command includes
```
--assumption "..."
```
or
```
--decision-ref DEC-###
```
; record the same assumption or decision in
```
decision-log.md
```
.

Use

python3 skills/_shared/state_machine.py status --feature <feature-name> --workspace <refinement|implementation> --format toon

to emit compact LLM-readable state before choosing the next skill.

The state machine is feature-scoped: do not reuse a
```
state.toon
```
across unrelated feature folders.

在TOON中维护功能生命周期状态：细化工作的状态存于
```
specs-refiniment/<feature-name>/_ai_sdlc/state.toon
```
，实施工作的状态存于
```
specs/<feature-name>/_ai_sdlc/state.toon
```
。

在为某个功能执行本技能前，使用

python3 skills/_shared/state_machine.py check --feature <feature-name> --skill <this-skill-name> --workspace <refinement|implementation> --quick-flow|--full-flow

检查状态机。

当本技能开始持久化工作时，用
```
begin
```
标记为进行中；当技能所需的产物或审查完成时，用
```
complete
```
标记为已完成，若涉及决策则添加
```
--artifacts <path>
```
和
```
--decision-ref DEC-###
```
。
在
```
--full-flow
```
模式下，当前置阶段未完成、另一个生命周期技能处于活跃状态或状态文件报告阻塞时，不得继续执行。
在
```
--quick-flow
```
模式下，仅当继续执行风险较低且命令包含
```
--assumption "..."
```
或
```
--decision-ref DEC-###
```
时，才允许跳过前置阶段；同时在
```
decision-log.md
```
中记录相同的假设或决策。

使用

python3 skills/_shared/state_machine.py status --feature <feature-name> --workspace <refinement|implementation> --format toon

在选择下一个技能前生成紧凑的LLM可读状态。

状态机以功能为范围：不得在不相关的功能文件夹间复用
```
state.toon
```
。

0.6 Artifact Metadata And Metatags

0.6 产物元数据和元标签

Every Markdown artifact generated or updated by this skill must start with an
```
artifact_metadata
```
YAML frontmatter block before the first visible heading.

Use schema

ai-sdlc-artifact-metadata/v1

and keep these fields current:

feature

artifact

path

workspace

skill

flow_mode

state_file

decision_log

status

owner

created_at

updated_at

trace_ids

related_artifacts

validation

, and

metatags

```
metatags
```
must include at minimum
```
ai-sdlc
```
, the workspace (
```
refinement
```
or
```
implementation
```
), this skill name, the artifact type or filename stem, and a lifecycle/status tag such as
```
draft
```
,
```
review
```
,
```
approved
```
, or
```
validated
```
.
When
```
--quick-flow
```
is active, set
```
flow_mode: quick
```
, keep assumptions visible in the body, and add tags for major defaults or unresolved risk only when they help retrieval.
When
```
--full-flow
```
is active, set
```
flow_mode: full
```
, keep blockers and validation evidence reflected in
```
status
```
,
```
validation
```
,
```
trace_ids
```
, and
```
related_artifacts
```
.
Update metadata whenever the artifact path, status, owner, trace links, validation evidence, related artifacts, or decision references change.
Metadata is an index for routing, retrieval, and traceability; it does not replace the artifact body,
```
decision-log.md
```
, or
```
state.toon
```
.

本技能生成或更新的每个Markdown产物，在第一个可见标题前必须包含
```
artifact_metadata
```
YAML前置块。

使用

ai-sdlc-artifact-metadata/v1

schema，并保持以下字段最新：

feature

、

artifact

、

path

、

workspace

、

skill

、

flow_mode

、

state_file

、

decision_log

、

status

、

owner

、

created_at

、

updated_at

、

trace_ids

、

related_artifacts

、

validation

和

metatags

。

```
metatags
```
至少必须包含
```
ai-sdlc
```
、工作区（
```
refinement
```
或
```
implementation
```
）、本技能名称、产物类型或文件名主干，以及生命周期/状态标签（如
```
draft
```
、
```
review
```
、
```
approved
```
或
```
validated
```
）。
当
```
--quick-flow
```
模式激活时，设置
```
flow_mode: quick
```
，在正文中显示假设，并仅在有助于检索时添加主要默认值或未解决风险的标签。
当
```
--full-flow
```
模式激活时，设置
```
flow_mode: full
```
，在
```
status
```
、
```
validation
```
、
```
trace_ids
```
和
```
related_artifacts
```
中反映阻塞点和验证证据。
每当产物路径、状态、负责人、可追溯链接、验证证据、关联产物或决策引用发生变化时，更新元数据。
元数据用于路由、检索和可追溯性；它不能替代产物正文、
```
decision-log.md
```
或
```
state.toon
```
。

0.7 Specs Index

0.7 规范索引

Before searching across feature folders, inspect the compact LLM index first:
```
specs-refiniment/_ai_sdlc/specs-index.toon
```
for refinement work or
```
specs/_ai_sdlc/specs-index.toon
```
for implementation work.
Use the human-readable index at
```
specs-refiniment/specs-index.md
```
or
```
specs/specs-index.md
```
when reporting feature coverage, artifact inventory, or handoff status to people.

After this skill creates or materially updates an artifact, refresh the matching workspace index with

python3 skills/_shared/ai_sdlc_specs_index.py --workspace <refinement|implementation> --quick-flow|--full-flow

In
```
--quick-flow
```
, rely on
```
specs-index.toon
```
to choose the smallest relevant artifact set before opening files.
In
```
--full-flow
```
, verify the updated artifact appears in both
```
specs-index.toon
```
and
```
specs-index.md
```
before final handoff.
The specs index summarizes artifact metadata and state; it does not replace reading the selected source artifacts when details, approvals, or validation evidence matter.

在跨功能文件夹搜索前，先查看紧凑的LLM索引：细化工作查看
```
specs-refiniment/_ai_sdlc/specs-index.toon
```
，实施工作查看
```
specs/_ai_sdlc/specs-index.toon
```
。
当向人员报告功能覆盖范围、产物清单或交接状态时，使用
```
specs-refiniment/specs-index.md
```
或
```
specs/specs-index.md
```
中的人类可读索引。

本技能创建或大幅更新产物后，使用

python3 skills/_shared/ai_sdlc_specs_index.py --workspace <refinement|implementation> --quick-flow|--full-flow

刷新匹配的工作区索引。

在
```
--quick-flow
```
模式下，依赖
```
specs-index.toon
```
选择最小的相关产物集，再打开文件。
在
```
--full-flow
```
模式下，在最终交接前验证更新后的产物是否同时出现在
```
specs-index.toon
```
和
```
specs-index.md
```
中。
规范索引汇总产物元数据和状态；当细节、审批或验证证据重要时，不能替代阅读所选源产物。

References

参考资料

Use
```
scripts/security_review_matrix.py
```
when deterministic scaffolding, planning, or formatting is useful for this workflow; pass the same
```
--quick-flow
```
or
```
--full-flow
```
flag that was supplied to the skill.
Read
```
references/owasp-backend-checklist.md
```
when the task needs the detailed structure, checklist, or examples for this skill.

当本工作流需要确定性脚手架、规划或格式化时，使用
```
scripts/security_review_matrix.py
```
；传入与技能相同的
```
--quick-flow
```
或
```
--full-flow
```
标志。
当任务需要本技能的详细结构、检查清单或示例时，阅读
```
references/owasp-backend-checklist.md
```
。

Script Usage

脚本使用

Run
```
scripts/security_review_matrix.py
```
before drafting or updating this skill's artifact when inputs are longer than a few bullets, when traceability matters, or when a flow flag is supplied. For agent analysis, pass
```
--format toon
```
, read
```
anchors
```
first, and open only
```
next_reads
```
; without that flag the script keeps its human-readable Markdown output.

Quick flow analysis:

python3 skills/ai-sdlc-security-testing/scripts/security_review_matrix.py --feature <feature-name> --quick-flow <input.md>...

Full flow analysis:

python3 skills/ai-sdlc-security-testing/scripts/security_review_matrix.py --feature <feature-name> --full-flow <input.md>...

To write content, pass one canonical heading with
```
--section "<section>"
```
; provide only that section body on stdin, without H1, H2, frontmatter, or a temporary content file.
Repeat
```
--section
```
for each required section, then run the same script with
```
--finalize
```
to validate the artifact and refresh metadata and specs indexes.
The AI must not write or directly edit the routed Markdown artifact; the script owns scaffold creation, section placement, and durable file writes.
Use
```
--decision-row
```
with one nine-cell Markdown table row on stdin when a decision-log entry is required.

Legacy

--emit-template

--emit-decision-log-entry

, and

--write

remain available for compatibility.

Use
```
--quick-flow
```
for first-pass synthesis with assumptions; use
```
--full-flow
```
before readiness, handoff, signoff, or any decision-sensitive output.

当输入内容超过几个项目符号、可追溯性重要或提供了流程标志时，在起草或更新本技能的产物前运行
```
scripts/security_review_matrix.py
```
。对于代理分析，传入
```
--format toon
```
，先读取
```
anchors
```
，再打开仅
```
next_reads
```
；若无此标志，脚本保持人类可读的Markdown输出。

快速流程分析：

python3 skills/ai-sdlc-security-testing/scripts/security_review_matrix.py --feature <feature-name> --quick-flow <input.md>...

完整流程分析：

python3 skills/ai-sdlc-security-testing/scripts/security_review_matrix.py --feature <feature-name> --full-flow <input.md>...

若要写入内容，传入一个规范标题
```
--section "<section>"
```
；仅在标准输入中提供该部分正文，无需H1、H2、前置块或临时内容文件。
为每个所需部分重复
```
--section
```
，然后使用
```
--finalize
```
运行相同的脚本来验证产物并刷新元数据和规范索引。
AI不得直接写入或编辑路由的Markdown产物；脚本负责脚手架创建、部分放置和持久化文件写入。
当需要决策日志条目时，使用
```
--decision-row
```
并在标准输入中提供一个九单元格的Markdown表格行。

旧版标志

--emit-template

、

--emit-decision-log-entry

和

--write

仍可兼容使用。

使用
```
--quick-flow
```
进行基于假设的首次合成；在准备、交接、签署或任何决策敏感的输出前使用
```
--full-flow
```
。

Purpose

用途

Review AI SDLC diffs, endpoints, workflows, provider integrations, and configs for concrete security findings, abuse paths, trust-boundary failures, and missing security validation. When the output makes OWASP- or standards-based claims, verify them against current primary sources before presenting them as authoritative guidance.

审查AI SDLC的diff、端点、工作流、供应商集成和配置，找出具体的安全问题、滥用路径、信任边界失效以及缺失的安全验证。当输出内容涉及基于OWASP或标准的声明时，需先对照当前权威来源进行验证，再作为指导性内容呈现。

Inputs

输入

Collect the exact review target: diff, commit, branch, endpoint, workflow, subsystem, or file set.
Run or read
```
git status --short
```
and
```
git diff --stat
```
for diff-based reviews.
Read relevant spec files for medium or large work.
Identify entry points, identity sources, roles, organizations, accounts, providers, assets, secrets, and state transitions.
Read
```
references/owasp-backend-checklist.md
```
when the surface is broad or the user asks for OWASP-style coverage.
When the request mentions OWASP, ASVS, API Top 10, or other standards-driven guidance, browse current primary sources before citing categories, versions, or remediation guidance.

收集确切的审查目标：diff、提交、分支、端点、工作流、子系统或文件集。
对于基于diff的审查，运行或读取
```
git status --short
```
和
```
git diff --stat
```
。
对于中型或大型工作，阅读相关规范文件。
识别入口点、身份来源、角色、组织、账户、供应商、资产、秘密和状态转换。
当审查范围较广或用户要求OWASP风格的覆盖时，阅读
```
references/owasp-backend-checklist.md
```
。
当请求提及OWASP、ASVS、API Top 10或其他基于标准的指导时，在引用类别、版本或修复指导前浏览当前权威来源。

Steps

步骤

Define the protected asset and trust boundary.
Map externally controlled inputs, identity sources, and privileged operations.
Check authentication before business side effects.
Check authorization across organization, account, role, provider, and workflow boundaries.
Check input validation, normalization, decimal handling, output encoding, query construction, and command construction.
Check secret handling, logs, errors, test fixtures, docs, config defaults, and webhook material for leakage.
Check replay, idempotency, race windows, retry behavior, broken state transitions, and failure isolation.
If the output will map issues to OWASP or another security standard, verify the current standard text from primary sources first. Prefer official OWASP pages, ASVS, API Security Top 10, or equivalent authoritative documentation.
Separate local exploitability evidence from standards-backed interpretation. Do not present remembered OWASP categories or stale version assumptions as verified guidance.
Check whether
```
test-cases.md
```
,
```
qa.md
```
, automated tests, or validation commands cover the risky paths.
Report concrete findings first, ordered by severity.
Report no findings explicitly when none are found, then list validation gaps, blocked verification, or residual risk.

定义受保护资产和信任边界。
映射外部控制的输入、身份来源和特权操作。
在业务副作用发生前检查认证情况。
跨组织、账户、角色、供应商和工作流边界检查授权情况。
检查输入验证、规范化、小数处理、输出编码、查询构造和命令构造。
检查秘密处理、日志、错误、测试 fixture、文档、配置默认值和Webhook内容是否存在泄露。
检查重放、幂等性、竞争窗口、重试行为、状态转换失效和故障隔离。
若输出将问题映射到OWASP或其他安全标准，先从权威来源验证当前标准文本。优先使用官方OWASP页面、ASVS、API安全Top 10或等效权威文档。
将本地可利用性证据与基于标准的解释分开。不得将记忆中的OWASP类别或过时版本假设作为已验证的指导内容呈现。
检查
```
test-cases.md
```
、
```
qa.md
```
、自动化测试或验证命令是否覆盖风险路径。
首先报告具体问题，按严重性排序。
当未发现问题时明确报告，然后列出验证缺口、受阻验证或残留风险。

Output Spec

输出规范

Use this findings-first format:

text

Findings:
- [CRITICAL|HIGH|MEDIUM|LOW] path:line - concise issue statement.
  Impact: exploitable outcome.
  Evidence: code path, input, state, or missing check.
  Fix: concrete remediation.

Verified sources:
- Required when the output uses OWASP or standards-based claims.
- Include the current primary source link and the specific claim it supports.

Open questions:
- Trust-boundary or exploitability question that blocks severity or fix selection.

Validation gaps:
- Missing security test, QA check, or command and why it matters.

Summary:
- Brief security posture summary after findings.

Quality gate:

Pass when every finding is tied to a concrete path, exploit condition, impact, and fix.
Fail when the output recites generic OWASP categories, cites standards from memory without verification, inflates speculative issues, omits severity, or hides missing validation.

使用以下“问题优先”格式：

text

问题：
- [CRITICAL|HIGH|MEDIUM|LOW] 路径:行号 - 简洁的问题说明。
  影响：可被利用的后果。
  证据：代码路径、输入、状态或缺失的检查。
  修复：具体的修复方案。

已验证来源：
- 当输出使用OWASP或基于标准的声明时必需。
- 包含当前权威来源链接及其支持的具体声明。

未解决问题：
- 影响严重性或修复方案选择的信任边界或可利用性问题。

验证缺口：
- 缺失的安全测试、QA检查或命令，以及其重要性原因。

摘要：
- 问题排查后的简要安全态势总结。

质量关卡：

通过：每个问题都关联具体路径、利用条件、影响和修复方案。
失败：输出内容复述通用OWASP类别、凭记忆引用标准而未验证、夸大推测性问题、遗漏严重性或隐藏缺失的验证。

Examples

示例

Finding example:

text

Findings:
- [HIGH] internal/transport/http/v1/handlers/transfers.go:142 - Transfer lookup does not verify organization ownership before returning wallet metadata.
  Impact: A user with access to one organization could enumerate another organization's provider wallet labels.
  Evidence: Handler uses transfer ID from the route and returns provider details before checking org ownership.
  Fix: Load the transfer through an organization-scoped query or compare `transfer.OrganizationID` before building the response.

No-finding example:

text

Findings:
- None found.

Validation gaps:
- No automated test covers replay of duplicate webhook IDs; add a service-level idempotency test before release.

Invalid counter-example:

text

Security looks fine.

Reject this because it omits reviewed boundaries, findings status, and validation gaps.

问题示例：

text

问题：
- [HIGH] internal/transport/http/v1/handlers/transfers.go:142 - 转账查询在返回钱包元数据前未验证组织所有权。
  影响：拥有某一组织访问权限的用户可枚举另一组织的供应商钱包标签。
  证据：处理器使用路由中的转账ID，在检查组织所有权前返回供应商详情。
  修复：通过组织范围的查询加载转账记录，或在构建响应前比较`transfer.OrganizationID`。

无问题示例：

text

问题：
- 未发现问题。

验证缺口：
- 无自动化测试覆盖重复Webhook ID的重放；发布前添加服务级幂等性测试。

无效反例：

text

安全性看起来没问题。

拒绝此输出，因为它遗漏了已审查的边界、问题状态和验证缺口。

Edge Cases

边缘情况

Stop and warn immediately if real secrets, bearer tokens, private keys, or production-only values appear in the diff; do not paste them back.
State
```
target unclear
```
when no diff, endpoint, workflow, or subsystem is provided and local context cannot infer one safely.
Use
```
$ai-sdlc-code-review
```
when the main ask is correctness, regression, or maintainability rather than exploitability.
If browsing or primary-source verification is unavailable, report
```
standards verification blocked
```
and limit the output to locally supported exploitability findings instead of presenting unverified OWASP guidance.
Mark validation as blocked when required credentials, fixtures, or environment are unavailable.
Do not lower severity because a path is "internal" unless the trust boundary proves only trusted callers can reach it.

如果diff中出现真实的秘密、Bearer令牌、私钥或仅生产环境的值，立即停止并发出警告；不得将其粘贴回去。
当未提供diff、端点、工作流或子系统且本地上下文无法安全推断时，标记为
```
目标不明确
```
。
当主要需求是正确性、回归或可维护性而非可利用性时，使用
```
$ai-sdlc-code-review
```
。
若无法浏览或验证权威来源，报告
```
标准验证受阻
```
，并将输出限制为本地支持的可利用性问题，不得呈现未验证的OWASP指导内容。
当所需凭据、fixture或环境不可用时，标记验证为受阻。
除非信任边界证明只有可信调用者能访问该路径，否则不得因路径为“内部”而降低严重性。

Scope Boundary

范围边界

Do not perform general code review unless security is the primary question.
Do not run production attacks, live exploitation, or credentialed provider actions.
Do not expose sensitive values in findings, tests, comments.
Do not decide business acceptance; use
```
$ai-sdlc-ba
```
and
```
$ai-sdlc-qa
```
.
Do not cite OWASP categories, ASVS controls, or standards versions from memory when current-source verification is required.

除非安全是主要问题，否则不得进行通用代码审查。
不得进行生产环境攻击、实时利用或需要凭据的供应商操作。
不得在问题、测试、注释中暴露敏感值。
不得决定业务验收；使用
```
$ai-sdlc-ba
```
和
```
$ai-sdlc-qa
```
。
当需要验证权威来源时，不得凭记忆引用OWASP类别、ASVS控制或标准版本。