security-audit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Security Audit

安全审计

Purpose

目的

This skill reads and reports. It never writes. No file edit, no

gh api

write, no GitHub issue, no invocation of another skill on the user's behalf. It detects security gaps across whichever areas a repository exposes, aggregates them into one severity-ordered report, and hands off. Every

gh api

command it produces is report text for a human or a downstream skill to run — the audit never executes one.

maintain:repo-hardening

is the write half of the pair. It applies the baseline via

gh api

: rulesets, Actions token defaults, security features, immutable releases, branch-restricted environments for deploy secrets. Findings from this skill are its input; run it after an audit, or standalone on a new repo. If the user wants changes made rather than gaps listed, that is the skill to use.

Read-only is what makes this skill safe to run anywhere, including on a repo the user does not own. Keep it that way: a new audit area adds a checklist under

references/

and a prompt in

references/subagent-prompts.md

, never a mutation.

Audit areas currently implemented:

Area	Checklist
GitHub Actions workflows under `.github/workflows/`	`references/actions-checklist.md`
Release configuration ( `release.yml` , `package.json` , `dependabot.yml` , npm publishing)	`references/release-checklist.md`
Repository settings via the GitHub REST API (Actions defaults, rulesets, security features, immutable releases, deploy environments)	`references/repo-settings-checklist.md`
Package manager and install-time controls, pnpm and bun only (lifecycle-script allowlists, release-age gates, scope→registry mapping)	`references/package-manager-checklist.md`
Application source code (injection and unsafe-execution vectors)	`references/code-security-checklist.md`

Not yet implemented: non-GitHub CI providers (CircleCI, GitLab CI), container security (Dockerfiles, base-image pinning), committed-secret scanning beyond GitHub's native feature, runtime config (CSP, CORS, security headers), dependency policy (license allowlist, banned packages).

For dependency CVE scanning specifically, use

gh dependabot alerts

npm audit

, or

pnpm audit

directly — this skill does not duplicate that.

Boundary with
audit:ci-audit
. Both read

.github/workflows/

, split by consequence. This skill owns the security surface: action pinning,

permissions:

persist-credentials

pull_request_target

, OIDC, third-party action sources, and cache poisoning or cross-branch scope.

ci-audit

owns performance, spend, and gating correctness — the job graph, cache hit rate, matrix design,

timeout-minutes

, artifact retention, and

concurrency

. Action pinning is graded here and only here, so the same line of YAML never gets two severities. When

ci-audit

finds a required check name that no workflow produces, it hands the observation over, because reconciling rulesets against triggers needs the

gh api

calls only this skill makes.

本技能仅读取和报告，绝不执行写入操作。 不会编辑文件、不会通过

gh api

执行写入操作、不会创建GitHub Issue、不会代表用户调用其他技能。它会检测仓库各领域存在的安全漏洞，将结果汇总为按严重程度排序的报告后交付。生成的所有

gh api

命令均为报告文本，供人工或下游技能执行——审计过程中绝不会自行执行这些命令。

maintain:repo-hardening

是配套的写入类技能。它通过

gh api

应用安全基线：规则集、Actions令牌默认值、安全功能、不可变发布、部署密钥的分支受限环境。本技能的审计结果是它的输入；可在审计后运行，也可在新仓库上独立运行。如果用户希望修复漏洞而非仅查看漏洞列表，请使用该技能。

只读特性让本技能可在任何环境安全运行，包括用户不拥有的仓库。请保持这一特性：新增审计领域时，只需在

references/

下添加检查清单，并在

references/subagent-prompts.md

中添加提示，绝不执行任何修改操作。

当前已实现的审计领域：

领域	检查清单
`.github/workflows/` 下的GitHub Actions工作流	`references/actions-checklist.md`
发布配置（ `release.yml` 、 `package.json` 、 `dependabot.yml` 、npm发布）	`references/release-checklist.md`
通过GitHub REST API获取的仓库设置（Actions默认值、规则集、安全功能、不可变发布、部署环境）	`references/repo-settings-checklist.md`
包管理器及安装时控制，仅支持pnpm和bun（生命周期脚本白名单、发布时长限制、作用域→注册表映射）	`references/package-manager-checklist.md`
应用源代码（注入和不安全执行风险点）	`references/code-security-checklist.md`

**尚未实现的功能：**非GitHub CI提供商（CircleCI、GitLab CI）、容器安全（Dockerfile、基础镜像固定）、超出GitHub原生功能的已提交密钥扫描、运行时配置（CSP、CORS、安全头）、依赖策略（许可证白名单、禁用包）。

针对依赖项CVE扫描，请直接使用

gh dependabot alerts

、

npm audit

或

pnpm audit

——本技能不会重复该功能。

与
audit:ci-audit
的边界划分两者都会读取

.github/workflows/

，但关注的影响不同。本技能负责安全层面：操作固定、

permissions:

、

persist-credentials

、

pull_request_target

、OIDC、第三方操作源，以及缓存投毒或跨分支范围问题。

ci-audit

负责性能、成本和正确性校验——作业图、缓存命中率、矩阵设计、

timeout-minutes

、工件保留和

concurrency

。操作固定仅在本技能中评估，因此同一段YAML不会被标记两个严重程度。当

ci-audit

发现某个规则集要求的检查名称没有任何工作流生成时，会将该观察结果移交本技能，因为需要通过本技能的

gh api

调用来协调规则集与触发器的匹配。

When to Use

使用场景

Use when the user asks to:

"Audit security" / "security audit"
"Check supply chain" / "review for supply-chain attacks"
"Harden CI" or "harden actions" — audit first, then hand off to
```
repo-hardening
```
"Audit release workflow" / "audit npm publishing"
"Harden settings" / "audit rulesets" / "audit repo settings"
"Audit install scripts" / "audit lifecycle scripts" / "audit package manager"

Trigger phrases:

security audit

supply chain

ci hardening

harden actions

audit release

harden settings

audit rulesets

audit install scripts

audit package manager

minimum release age

allowBuilds

staged publishing

pwn request

sha pinning

Not for:

Applying the fixes →
```
maintain:repo-hardening
```
Bug hunting on a diff →
```
review:changes-review
```
; style and comment noise →
```
review:code-cleanup
```
CI speed/parallelization →
```
audit:ci-audit
```
Dependency CVE scanning → run
```
gh dependabot alerts
```
/
```
pnpm audit
```
directly

当用户提出以下需求时使用：

"审计安全" / "安全审计"
"检查供应链" / "审查供应链攻击风险"
"加固CI"或"加固Actions"——先审计，再移交
```
repo-hardening
```
处理
"审计发布工作流" / "审计npm发布"
"加固设置" / "审计规则集" / "审计仓库设置"
"审计安装脚本" / "审计生命周期脚本" / "审计包管理器"

触发关键词：

security audit

、

supply chain

、

ci hardening

、

harden actions

、

audit release

、

harden settings

、

audit rulesets

、

audit install scripts

、

audit package manager

、

minimum release age

、

allowBuilds

、

staged publishing

、

pwn request

、

sha pinning

。

不适用场景：

修复漏洞 → 使用
```
maintain:repo-hardening
```
代码差异漏洞排查 → 使用
```
review:changes-review
```
；代码风格和注释优化 → 使用
```
review:code-cleanup
```
CI速度/并行化优化 → 使用
```
audit:ci-audit
```
依赖项CVE扫描 → 直接运行
```
gh dependabot alerts
```
/
```
pnpm audit
```

Asking the User

与用户交互

Every question in this skill is written as

AskUserQuestion

options. Use that tool where the host offers it, or the host's nearest structured-choice equivalent. Where the host has neither, ask the same question in normal chat as a numbered list of 2–5 options — recommended first, one short line of description each — and wait for the user to reply with a number.

本技能中的所有问题均以

AskUserQuestion

选项形式编写。如果宿主环境提供该工具，请使用它；否则使用宿主环境最接近的结构化选择功能。如果两者都没有，请以普通聊天形式提出问题，列出2-5个带编号的选项——推荐选项放在首位，每个选项配简短描述——等待用户回复编号。

Workflow

工作流程

Step 1: Detect Repo Layout

步骤1：检测仓库布局

Run in parallel. Every command here is a read:

bash

ls .github/workflows/ 2>/dev/null
cat .github/dependabot.yml 2>/dev/null
jq '{name, packageManager, trustedDependencies, scripts: (.scripts | keys), publishConfig, private}' package.json 2>/dev/null
ls package-lock.json pnpm-lock.yaml yarn.lock bun.lock bun.lockb 2>/dev/null
cat pnpm-workspace.yaml 2>/dev/null
cat bunfig.toml 2>/dev/null
cat .npmrc 2>/dev/null
gh api repos/<owner>/<repo>/actions/permissions 2>/dev/null
gh api repos/<owner>/<repo>/actions/permissions/workflow 2>/dev/null
gh api repos/<owner>/<repo>/rulesets 2>/dev/null
gh api repos/<owner>/<repo>/immutable-releases 2>/dev/null
gh api repos/<owner>/<repo> --jq '{private, default_branch, security_and_analysis}' 2>/dev/null

Resolve

<owner>/<repo>

from

gh repo view --json nameWithOwner --jq .nameWithOwner

. If the API calls fail with

or auth errors, note it — repo-settings findings will be skipped for that area.

Extract org-scope context for Subagent D (compute in the orchestrator, then substitute):

```
org_prefix
```
— derived from
```
package.json
```
```
name:
```
. If the name is
```
@<prefix>/<pkg>
```
, the prefix is
```
<prefix>
```
. If the name is unscoped, leave
```
org_prefix
```
empty (no org scopes will be flagged).

org_scope_patterns

— given a non-empty

org_prefix

, owned scopes are

@<prefix>/*

AND any scope matching

@<prefix>-*/*

(e.g., for

enonic

@enonic/*

@enonic-types/*

@enonic-cli/*

already_covered_scopes

— union of:

minimumReleaseAgeExclude

from

pnpm-workspace.yaml

(use

yq

minimumReleaseAgeExcludes

from

bunfig.toml

registries:

keys from

pnpm-workspace.yaml

[install.scopes]

keys from

bunfig.toml

, and

@<scope>:registry=

lines from

.npmrc

These pre-approve scopes the team has already decided to trust. Subagent D treats them as covered and emits no finding for missing config.

Default posture: deny everything. Subagent D flags missing exclude/registry config only for owned scopes (matching

org_scope_patterns

) that appear in the lockfile and are not in

already_covered_scopes

. All other scopes stay under the release-age and dependency-confusion gates — that is the intended hardening. If

org_prefix

is empty, no scope-specific findings are emitted.

Extract release-target context for Subagent B (compute in the orchestrator, then substitute):

```
release_publishes_to_npm
```
—
```
true
```
if any of these exist (the audit does not care WHICH non-npm publisher is used, only whether npm is involved): a
```
release.yml
```
/
```
release.yaml
```
in
```
.github/workflows/
```
containing a literal
```
npm publish
```
,
```
npm stage publish
```
,
```
pnpm publish
```
,
```
yarn publish
```
, or
```
bun publish
```
; a
```
publishConfig.registry
```
field in
```
package.json
```
; or a
```
scripts.publish
```
value containing any of those commands.
```
detected_build_systems
```
— assembled from root file presence:
```
npm
```
if
```
package.json
```
+ any lockfile,
```
gradle
```
if
```
build.gradle
```
/
```
build.gradle.kts
```
,
```
maven
```
if
```
pom.xml
```
,
```
cargo
```
if
```
Cargo.toml
```
,
```
pip
```
if
```
requirements.txt
```
/
```
pyproject.toml
```
,
```
docker
```
if
```
Dockerfile
```
.
```
github-actions
```
is always added when
```
.github/workflows/
```
exists. This drives item 7 (dependabot ecosystem coverage) so the audit recommends the right ecosystems regardless of stack.

Routing. Skip the Actions subagent if

.github/workflows/

is absent. Skip the Release subagent unless one of these holds: a

release.yml

release.yaml

exists,

package.json

has

publishConfig

, or

package.json

scripts

has any of

publish

release

prepublishOnly

. If

package.json

is absent or

private: true

, note it — release findings about provenance change severity. Dispatch the Package Manager subagent if any lockfile exists — including

package-lock.json

yarn.lock

, where its whole job is the one out-of-scope finding (the audit supports pnpm and bun only) rather than a tuning pass. Dispatch the Repo Settings subagent if

gh api .../actions/permissions

returns HTTP 200; skip only on

or auth error. An empty

[]

from

/rulesets

is success — Subagent C treats the absence of rulesets as a finding, not a reason to skip. Skip the code subagent on a configuration-only or docs-only repo.

并行执行以下命令，所有命令均为读取操作：

bash

ls .github/workflows/ 2>/dev/null
cat .github/dependabot.yml 2>/dev/null
jq '{name, packageManager, trustedDependencies, scripts: (.scripts | keys), publishConfig, private}' package.json 2>/dev/null
ls package-lock.json pnpm-lock.yaml yarn.lock bun.lock bun.lockb 2>/dev/null
cat pnpm-workspace.yaml 2>/dev/null
cat bunfig.toml 2>/dev/null
cat .npmrc 2>/dev/null
gh api repos/<owner>/<repo>/actions/permissions 2>/dev/null
gh api repos/<owner>/<repo>/actions/permissions/workflow 2>/dev/null
gh api repos/<owner>/<repo>/rulesets 2>/dev/null
gh api repos/<owner>/<repo>/immutable-releases 2>/dev/null
gh api repos/<owner>/<repo> --jq '{private, default_branch, security_and_analysis}' 2>/dev/null

通过

gh repo view --json nameWithOwner --jq .nameWithOwner

解析

<owner>/<repo>

。如果API调用返回

或认证错误，请记录该情况——对应领域的仓库设置审计结果将被跳过。

为Subagent D提取组织作用域上下文（在编排器中计算后替换）：

```
org_prefix
```
— 从
```
package.json
```
的
```
name:
```
字段派生。如果名称为
```
@<prefix>/<pkg>
```
，则前缀为
```
<prefix>
```
。如果名称无作用域，则
```
org_prefix
```
留空（不会标记任何组织作用域问题）。
```
org_scope_patterns
```
— 当
```
org_prefix
```
非空时，可信作用域为
```
@<prefix>/*
```
以及所有匹配
```
@<prefix>-*/*
```
的作用域（例如，对于
```
enonic
```
：
```
@enonic/*
```
、
```
@enonic-types/*
```
、
```
@enonic-cli/*
```
）。

already_covered_scopes

— 以下内容的并集：

pnpm-workspace.yaml

中的

minimumReleaseAgeExclude

（使用

yq

提取）、

bunfig.toml

中的

minimumReleaseAgeExcludes

、

pnpm-workspace.yaml

中的

registries:

键、

bunfig.toml

中的

[install.scopes]

键，以及

.npmrc

中的

@<scope>:registry=

行。

这些是团队已决定信任的预批准作用域。Subagent D会将它们视为已覆盖，不会针对缺失配置发出警报。

默认策略：拒绝所有Subagent D仅针对锁定文件中存在且未包含在

already_covered_scopes

内的、匹配

org_scope_patterns

的自有作用域，标记缺失的排除/注册表配置。所有其他作用域均受发布时长限制和依赖混淆防护——这是预期的加固效果。如果

org_prefix

为空，则不会发出任何作用域相关的审计结果。

为Subagent B提取发布目标上下文（在编排器中计算后替换）：

```
release_publishes_to_npm
```
— 如果存在以下任一情况则为
```
true
```
（审计不关心使用的是非npm的哪个发布工具，仅关心是否涉及npm）：
```
.github/workflows/
```
中的
```
release.yml
```
/
```
release.yaml
```
包含字面量
```
npm publish
```
、
```
npm stage publish
```
、
```
pnpm publish
```
、
```
yarn publish
```
或
```
bun publish
```
；
```
package.json
```
中有
```
publishConfig.registry
```
字段；或
```
package.json
```
的
```
scripts.publish
```
值包含上述任一命令。
```
detected_build_systems
```
— 根据根目录文件存在情况汇总：如果有
```
package.json
```
+任意锁定文件则为
```
npm
```
；如果有
```
build.gradle
```
/
```
build.gradle.kts
```
则为
```
gradle
```
；如果有
```
pom.xml
```
则为
```
maven
```
；如果有
```
Cargo.toml
```
则为
```
cargo
```
；如果有
```
requirements.txt
```
/
```
pyproject.toml
```
则为
```
pip
```
；如果有
```
Dockerfile
```
则为
```
docker
```
。当
```
.github/workflows/
```
存在时，始终添加
```
github-actions
```
。这用于驱动第7项（dependabot生态系统覆盖），以便审计无论技术栈如何都能推荐正确的生态系统。

路由规则如果

.github/workflows/

不存在，则跳过Actions子代理。仅当以下任一条件满足时才运行Release子代理：存在

release.yml

release.yaml

、

package.json

有

publishConfig

、或

package.json

的

scripts

包含

publish

、

release

、

prepublishOnly

中的任意一个。如果

package.json

不存在或

private: true

，请记录该情况——关于发布来源的审计结果严重程度会调整。如果存在任意锁定文件（包括

package-lock.json

或

yarn.lock

，此时其唯一任务是标记一个超出范围的结果：审计仅支持pnpm和bun），则调度Package Manager子代理。如果

gh api .../actions/permissions

返回HTTP 200，则调度Repo Settings子代理；仅在返回

或认证错误时跳过。

/rulesets

返回空数组

[]

视为成功——Subagent C会将规则集缺失视为审计结果，而非跳过的理由。如果是仅配置或仅文档的仓库，则跳过代码子代理。

Step 2: Dispatch Audit Subagents in Parallel

步骤2：并行调度审计子代理

Read

references/subagent-prompts.md

. It holds one prompt per audit area, the placeholder substitution table, and the rule that no subagent mutates anything.

Dispatch one subagent per applicable audit area, concurrently if the host allows it. If the host has no subagent facility, run each area sequentially inline using the same prompts. Substitute every placeholder before dispatch —

{{SKILL_DIR}}

in particular, since subagents are spawned with the user's CWD and relative checklist paths will not otherwise resolve.

As new audit areas are added under

references/

, add the matching prompt to that file. No change to Step 3 or Step 4 is needed.

阅读

references/subagent-prompts.md

。该文件包含每个审计领域的调度提示、占位符替换表，以及子代理不得执行任何修改操作的规则。

如果宿主环境允许，为每个适用的审计领域同时调度一个子代理。如果宿主环境无子代理功能，则按顺序依次运行每个领域的审计，使用相同的提示。调度前替换所有占位符——尤其是

{{SKILL_DIR}}

，因为子代理在用户的当前工作目录启动，相对路径的检查清单无法自行解析。

当

references/

下新增审计领域时，在该文件中添加对应的提示即可，无需修改步骤3或步骤4。

Step 3: Aggregate Findings

步骤3：汇总审计结果

Wait for all dispatched subagents. Apply the four aggregation rules, then assemble the report. Severities come from

references/severity-table.md

— use it to reconcile any disagreement between subagents on the same finding shape.

Aggregation rule 1 — Pin-status cross-check (A ↔ C). Reconcile Subagent A's pin findings with Subagent C's

sha_pinning_required

report:

A reports zero pin findings (every
```
uses:
```
is SHA-pinned) AND C reports
```
sha_pinning_required: false
```
→ emit high: "All actions are SHA-pinned but
```
sha_pinning_required
```
is off. Enable to prevent regression:
```
gh api -X PUT /repos/<owner>/<repo>/actions/permissions -F sha_pinning_required=true
```
."
A has pin findings AND C reports
```
sha_pinning_required: false
```
→ do NOT additionally flag the setting. The issue is the unpinned actions (already in A's report). In "Already hardened" add: "
```
sha_pinning_required
```
cannot be enabled until A's pin findings are fixed — re-run the audit afterward."

C reports

sha_pinning_required: true

→ "Already hardened:

sha_pinning_required

enforced."

Aggregation rule 2 — Required-status-check coverage (A ↔ C). For each

{ruleset_id, protected_branches, required_checks}

entry in C's

RULESET_REQUIRED_CHECKS

map, for each

required_check

, for each

protected_branch

Find workflow(s) in A's
```
WORKFLOW_TRIGGER_MAP
```
whose
```
name:
```
matches
```
required_check
```
.
If no workflow matches the name, OR none of the matching workflows trigger on
```
protected_branch
```
(check both
```
push_branches
```
and
```
pr_branches
```
; treat
```
*
```
as matching any branch), emit high: "Required check
```
<check>
```
on branch
```
<branch>
```
(ruleset
```
<id>
```
) is not produced by any workflow triggering on that branch. PRs to
```
<branch>
```
will be permanently BLOCKED. Either add the branch to the workflow's
```
on.push.branches
```
/
```
on.pull_request.branches
```
, or remove the check from the ruleset's
```
required_status_checks
```
."

Aggregation rule 3 — Pass collation. Each subagent's report ends with a "passes" / "already hardened" section. Concatenate these into

### Already hardened

, prefixed with the source subagent:

[Actions] persist-credentials: false on all checkouts

[Repo Settings] secret_scanning enabled

[Package Manager] minimumReleaseAge: 4320 with Strict: true

. For each subagent skipped per Step 1 routing, add instead:

[<area>] Skipped — <reason>

Aggregation rule 4 — Sequencing hints. If any finding pair has a "fix A before C is actionable" relationship (rule 1's second case is canonical; the rule-2 BLOCKED-PR finding depends on the ruleset existing at all; D's

allowBuilds

fix may break installs until paired with

strictDepBuilds

), surface the ordering in a final

### Sequencing

section:

1. Apply [Actions] findings → 2. Re-run audit → 3. Apply [Repo Settings] sha_pinning_required recommendation.

Render the section only if at least one relationship exists.

Weighting.

release.yml

is the privileged target — weight findings there above equivalent findings in ordinary CI.

Report skeleton:

markdown

undefined

等待所有子代理完成。应用以下四条汇总规则，然后生成报告。严重程度来自

references/severity-table.md

——用于协调子代理对同一类型结果的严重程度分歧。

**汇总规则1——固定状态交叉校验（A ↔ C）**协调Subagent A的操作固定结果与Subagent C的

sha_pinning_required

报告：

A报告无固定问题（所有
```
uses:
```
均已通过SHA固定）且C报告
```
sha_pinning_required: false
```
→ 标记为高风险："所有Actions均已通过SHA固定，但
```
sha_pinning_required
```
未启用。请启用以防止回归：
```
gh api -X PUT /repos/<owner>/<repo>/actions/permissions -F sha_pinning_required=true
```
。"
A报告有固定问题且C报告
```
sha_pinning_required: false
```
→ 不要额外标记该设置。问题在于未固定的Actions（已在A的报告中）。在"已加固项"中添加："
```
sha_pinning_required
```
需在修复A的固定问题后才能启用——修复后重新运行审计。"

C报告

sha_pinning_required: true

→ "已加固项：

sha_pinning_required

已强制启用。"

**汇总规则2——必填状态检查覆盖校验（A ↔ C）**对于C的

RULESET_REQUIRED_CHECKS

映射中的每个

{ruleset_id, protected_branches, required_checks}

条目，针对每个

required_check

和每个

protected_branch

：

在A的
```
WORKFLOW_TRIGGER_MAP
```
中查找名称与
```
required_check
```
匹配的工作流。
如果没有匹配名称的工作流，或匹配的工作流均未在
```
protected_branch
```
上触发（检查
```
push_branches
```
和
```
pr_branches
```
；
```
*
```
视为匹配任意分支），标记为高风险："分支
```
<branch>
```
上的必填检查
```
<check>
```
（规则集
```
<id>
```
）没有任何工作流在该分支上触发。向
```
<branch>
```
提交PR将被永久阻止。请将该分支添加到工作流的
```
on.push.branches
```
/
```
on.pull_request.branches
```
中，或从规则集的
```
required_status_checks
```
中移除该检查。"

汇总规则3——通过项合并每个子代理的报告末尾都有"通过" / "已加固"部分。将这些内容合并到

### 已加固项

中，并添加来源子代理前缀：

[Actions] 所有checkout均设置persist-credentials: false

、

[Repo Settings] secret_scanning已启用

、

[Package Manager] minimumReleaseAge: 4320且Strict: true

。对于步骤1路由中跳过的子代理，添加：

[<领域>] 已跳过——<原因>

。

汇总规则4——修复顺序提示如果任意结果对存在"先修复A才能处理C"的关系（规则1的第二种情况为典型案例；规则2中的PR被阻止结果依赖于规则集本身存在；D的

allowBuilds

修复可能会在配合

strictDepBuilds

之前导致安装失败），则在最终的

### 修复顺序

部分说明：

1. 应用[Actions]的修复建议 → 2. 重新运行审计 → 3. 应用[Repo Settings]的sha_pinning_required建议。

仅当存在至少一个此类关系时才显示该部分。

权重优先级

release.yml

是重点审计目标——该文件中的结果权重高于普通CI中的同类结果。

报告框架：

markdown

undefined

Security Audit Report

安全审计报告

<one-line summary: areas audited, areas skipped>

<一行摘要：已审计领域、已跳过领域>

Critical

严重

High

高风险

Medium

中风险

Low / Informational

低风险 / 信息提示

Already hardened

已加固项

[Actions] ...
[Release] Skipped — <reason>

[Actions] ...
[Release] 已跳过——<原因>

Sequencing

修复顺序


Sort findings within each severity bin worst-first (most exploitable first; policy findings after CVE-rated findings of the same severity). Keep file:line / API-path references intact from each subagent's report.


每个严重程度分类内的结果按风险从高到低排序（最易被利用的排在前面；同一严重程度下，策略类结果排在CVE评级结果之后）。保留子代理报告中的文件:行号 / API路径引用。

Step 4: Hand Off Findings

步骤4：交付审计结果

The audit stops here. Step 4 produces two artifacts side by side — a task queue for downstream work, and a Planned Changes report for the user to read. Do not edit files, run

gh api

writes, create issues, or invoke

/maintain:repo-hardening

/build:fix-and-reverify

/plan:issue-flow

, or any other skill on the user's behalf.

Hosts differ in whether they have a task tracker; where none exists, the Planned Changes report is the handoff and the options below collapse to option 4.

Ask, per Asking the User:

```
Emit tasks + planned-changes report
```
(Recommended) — one task per finding, plus the report below

Emit tasks flagged for issue filing

— same as 1, with

intended_action: file_issue

metadata

```
Emit a single summary task
```
— one task summarising all findings, suitable for a single tracking issue
```
Skip — just the report
```

All four options render the Planned Changes report (so the user always sees the change plan and revert commands). Options 1–3 additionally emit tasks.

审计到此结束。步骤4会生成两个并行交付物——下游工作的任务队列，以及供用户阅读的计划变更报告。不得编辑文件、执行

gh api

写入操作、创建Issue，或代表用户调用

/maintain:repo-hardening

、

/build:fix-and-reverify

、

/plan:issue-flow

或任何其他技能。

不同宿主环境的任务跟踪能力不同；如果没有任务跟踪功能，计划变更报告即为交付物，以下选项将简化为选项4。

根据与用户交互规则询问：

```
生成任务 + 计划变更报告
```
（推荐）——每个结果对应一个任务，加上下方的报告

生成标记为需创建Issue的任务

——与选项1相同，但添加

intended_action: file_issue

元数据

```
生成单个汇总任务
```
——一个汇总所有结果的任务，适合作为单个跟踪Issue
```
跳过任务——仅生成报告
```

所有四个选项都会生成计划变更报告（因此用户始终能看到变更计划和回滚命令）。选项1–3还会额外生成任务。

Task emission rules (options 1, 2, 3)

任务生成规则（选项1、2、3）

Skip this subsection entirely when the host has no task tracker.

One task per finding from the Step 3 report (options 1, 2). For option 3, emit a single task whose description is a numbered list of all findings.
```
subject
```
: short finding title (e.g., "Pin
```
actions/checkout@v6
```
to SHA").
```
description
```
: severity (including any
```
(policy)
```
qualifier), source subagent (
```
[Actions]
```
,
```
[Release]
```
,
```
[Repo Settings]
```
,
```
[Package Manager]
```
,
```
[Code]
```
), file:line or API path, the exact remediation snippet from the report.
```
metadata
```
: minimum set —
```
severity
```
,
```
source_area
```
,
```
change_kind
```
(
```
code
```
for file edits /
```
server_state
```
for
```
gh api
```
writes),
```
intended_action
```
(
```
fix
```
/
```
file_issue
```
/
```
summary
```
). Keep metadata light — the task queue is a handoff, not the audit's persistence layer.
Sequencing: for any pair from Step 3's
```
### Sequencing
```
section, record the downstream task as blocked by the upstream one, using whatever dependency field the host's tracker exposes. If it has none, state the ordering in the task description.
Emit tasks worst-first within each severity, matching the report's order.

如果宿主环境没有任务跟踪功能，请完全跳过本小节。

步骤3报告中的每个结果对应一个任务（选项1、2）。对于选项3，生成一个单个任务，其描述为所有结果的编号列表。
```
subject
```
：简短的结果标题（例如，"将
```
actions/checkout@v6
```
固定到SHA"）。
```
description
```
：严重程度（包括任何
```
(policy)
```
限定符）、来源子代理（
```
[Actions]
```
、
```
[Release]
```
、
```
[Repo Settings]
```
、
```
[Package Manager]
```
、
```
[Code]
```
）、文件:行号或API路径、报告中的具体修复代码片段。
```
metadata
```
：最小集合——
```
severity
```
、
```
source_area
```
、
```
change_kind
```
（
```
code
```
表示文件编辑 /
```
server_state
```
表示
```
gh api
```
写入）、
```
intended_action
```
（
```
fix
```
/
```
file_issue
```
/
```
summary
```
）。保持元数据简洁——任务队列是交付物，而非审计的持久层。
修复顺序：对于步骤3
```
### 修复顺序
```
部分中的任意结果对，将下游任务标记为依赖上游任务，使用宿主跟踪工具支持的依赖字段。如果没有该字段，则在任务描述中说明顺序。
任务按严重程度从高到低排序，与报告顺序一致。

Planned Changes report

计划变更报告

Render directly in the chat output, grouped by source area. It is the audit's plan-of-record, not an execution transcript — phrasing matters. Use

Recommended command:

and

Revert command:

(never

Applied:

), because the audit does not observe what actually runs. Code edits get one line; server-state changes get three.

markdown

undefined

直接在聊天输出中渲染，按来源领域分组。这是审计的正式计划，而非执行记录——措辞很重要。使用

推荐命令:

和

回滚命令:

（绝不要使用

已应用:

），因为审计不会监控实际执行的操作。代码编辑用一行描述；服务器状态变更用三行描述。

markdown

undefined

Security Audit — Planned Changes

安全审计——计划变更

Plan-of-record (not an execution transcript). Render of the Step 3 findings as code edits and

gh api

calls a downstream skill or human will apply.

正式计划（非执行记录）。将步骤3的结果渲染为代码编辑和

gh api

调用，供下游技能或人工执行。

[Actions] (N planned changes)

[Actions]（计划N项变更）

```
.github/workflows/ci.yml
```
— pin 6
```
uses:
```
lines via
```
pinact run
```

.github/workflows/release.yml

— add workflow-level

permissions: contents: read

```
.github/workflows/ci.yml
```
— 通过
```
pinact run
```
固定6个
```
uses:
```
行

.github/workflows/release.yml

— 添加工作流级别的

permissions: contents: read

[Release] (N planned changes)

[Release]（计划N项变更）

(or: "No changes planned — audit area skipped per Step 1 routing")

-（或："无计划变更——根据步骤1路由规则跳过该审计领域"）

[Repo Settings] (N planned changes)

[Repo Settings]（计划N项变更）

Set

default_workflow_permissions: read

on <owner>/<repo>

Recommended command:

gh api -X PUT /repos/<owner>/<repo>/actions/permissions/workflow -f default_workflow_permissions=read -F can_approve_pull_request_reviews=false

Revert command:

gh api -X PUT /repos/<owner>/<repo>/actions/permissions/workflow -f default_workflow_permissions=write -F can_approve_pull_request_reviews=true

Enable immutable releases on <owner>/<repo>

Recommended command:

gh api -X PUT /repos/<owner>/<repo>/immutable-releases

Revert command:

gh api -X DELETE /repos/<owner>/<repo>/immutable-releases

在<owner>/<repo>上设置

default_workflow_permissions: read

推荐命令：

gh api -X PUT /repos/<owner>/<repo>/actions/permissions/workflow -f default_workflow_permissions=read -F can_approve_pull_request_reviews=false

回滚命令：

gh api -X PUT /repos/<owner>/<repo>/actions/permissions/workflow -f default_workflow_permissions=write -F can_approve_pull_request_reviews=true

在<owner>/<repo>上启用不可变发布

推荐命令：

gh api -X PUT /repos/<owner>/<repo>/immutable-releases

回滚命令：

gh api -X DELETE /repos/<owner>/<repo>/immutable-releases

[Package Manager] (N planned changes)

[Package Manager]（计划N项变更）

pnpm-workspace.yaml

— add

minimumReleaseAge: 4320

minimumReleaseAgeStrict: true

pnpm-workspace.yaml

— 添加

minimumReleaseAge: 4320

、

minimumReleaseAgeStrict: true

Deferred or skipped (informational)

延迟处理或已跳过（信息提示）

[Actions]
```
pull_request_target
```
finding in
```
ci-fork.yml
```
— flagged as
```
informational
```
, no fix planned
[Repo Settings]
```
sha_pinning_required
```
— depends on
```
[Actions]
```
pin changes per Step 3 sequencing


**Format rules:**
- Every area gets a section, even if empty, so the user can see which areas had nothing to apply or were skipped.
- Code edits are one line: file path + short description. No `Recommended command:` block — the edit content lives in the task description.
- Server-state changes are three lines: title, `Recommended command:`, `Revert command:`. Both are the literal `gh api` invocations from the Step 3 finding.
- A `### Deferred or skipped` section captures anything not fixed (informational items, sequencing-blocked items). Nothing is silently dropped.

[Actions]
```
ci-fork.yml
```
中的
```
pull_request_target
```
结果——标记为
```
信息提示
```
，无计划修复
[Repo Settings]
```
sha_pinning_required
```
——需等待[Actions]的固定变更完成（根据步骤3的修复顺序）


**格式规则：**
- 每个领域都要有一个章节，即使为空，以便用户了解哪些领域无需变更或已被跳过。
- 代码编辑用一行描述：文件路径 + 简短说明。无需`推荐命令:`块——编辑内容在任务描述中。
- 服务器状态变更用三行描述：标题、`推荐命令:`、`回滚命令:`。两者均为步骤3结果中的字面量`gh api`调用。
- `### 延迟处理或已跳过`章节包含所有未修复的内容（信息提示项、受顺序限制的项）。不得遗漏任何内容。

Handoff line

交付提示语

After rendering the report and emitting tasks, print one of:

Option 1: "N tasks emitted. Run
```
/maintain:repo-hardening
```
for the
```
gh api
```
changes, or
```
/build:fix-and-reverify
```
to walk through the file edits."
Option 2: "N tasks emitted with
```
file_issue
```
flag. Run
```
/plan:issue-flow
```
per task when you're ready."
Option 3: "Single summary task emitted. Run
```
/plan:issue-flow
```
to file it as a tracking issue."
Option 4: "No tasks emitted; the report above is the full audit output."

Then stop. Do not invoke any of those skills yourself.

渲染报告并生成任务后，打印以下其中一条：

选项1："已生成N个任务。如需执行
```
gh api
```
变更，请运行
```
/maintain:repo-hardening
```
；如需逐步完成文件编辑，请运行
```
/build:fix-and-reverify
```
。"
选项2："已生成N个标记为
```
file_issue
```
的任务。准备就绪后，针对每个任务运行
```
/plan:issue-flow
```
。"
选项3："已生成单个汇总任务。运行
```
/plan:issue-flow
```
将其创建为跟踪Issue。"
选项4："未生成任务；上述报告为完整审计输出。"

然后停止操作。不得自行调用上述任何技能。

References

参考文件

File	Contents
`references/subagent-prompts.md`	Dispatch prompt per audit area, plus the placeholder substitution table
`references/severity-table.md`	Severity per finding shape; the release-age gate's four units
`references/actions-checklist.md`	Detection, severity, and fix for each workflow check
`references/release-checklist.md`	Release trigger, provenance, staged publishing, artifact identity
`references/repo-settings-checklist.md`	Exact `gh api` detection and remediation commands, bypass-actor patterns
`references/package-manager-checklist.md`	Per-manager field names, units, defaults, and fix examples
`references/install-flags.md`	Frozen-lockfile and `--prod` flags per manager, multi-stage Docker
`references/code-security-checklist.md`	Injection and unsafe-execution vectors by stack

文件	内容
`references/subagent-prompts.md`	每个审计领域的调度提示，以及占位符替换表
`references/severity-table.md`	每种结果类型的严重程度；发布时长限制的四种单位
`references/actions-checklist.md`	每个工作流检查项的检测方法、严重程度和修复方案
`references/release-checklist.md`	发布触发器、来源验证、分阶段发布、工件标识
`references/repo-settings-checklist.md`	精确的 `gh api` 检测和修复命令、绕过参与者模式
`references/package-manager-checklist.md`	各包管理器的字段名称、单位、默认值和修复示例
`references/install-flags.md`	各包管理器的冻结锁定文件和 `--prod` 标志、多阶段Docker
`references/code-security-checklist.md`	各技术栈的注入和不安全执行风险点