fix: attest-drill 回溯步补 RUN_ID step env（run 33261139414 实测红）

[randypanding]

Card: #420
ADR: ADR-0103（同 #456，缺陷修复）

缺陷

run 33261139414：演练前四步全绿（pack/verify/绑定/archive PR #46 已成），回溯步死于 RUN_ID: unbound variable——RUN_ID 只在前一 step env 定义，本 step set -u 未定义即红。

修复

回溯步 env 补 RUN_ID: ${{ github.run_id }}（step env 独立作用域）。合并后重触发演练验证全链。

Summary by CodeRabbit

• 改进
  • 回溯实测流程现可自动获取当前运行标识，提升后续流程追踪的一致性。

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[qodo-code-review]

PR Summary by Qodo

Add end-to-end attestation tracing and fix drill RUN_ID scope

✨ Enhancement 🧪 Tests 🐞 Bug fix 🕐 20-40 Minutes

AI Description

• Adds a signed attestation drill from artifact packaging through archived evidence binding.
• Introduces ledger-driven artifact reconstruction and mechanical content verification.
• Covers trace failures and scopes RUN_ID to prevent strict-shell workflow failure.

Diagram

graph TD
  A["Drill workflow"] --> B["CIW pack verify"] --> C["Archive evidence"] --> D["Trace engine"] --> E["Git rebuild"] --> F["Content verify"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Move tracing into CIW

• ➕ Co-locates attestation creation and trace contract logic
• ➕ Avoids a shell-injected verifier command
• ➖ Requires coordinated CIW and governance releases
• ➖ Couples archive-ledger semantics to the packaging repository

2. Use a reusable workflow

• ➕ Makes the drill reusable across repositories
• ➕ Centralizes credentials and orchestration
• ➖ Adds workflow-call integration complexity
• ➖ Does not replace the standalone offline trace engine

Recommendation: Keep the standalone governance trace engine and explicit drill workflow for this rollout: they preserve archive-ledger ownership and support self-contained gate tests. Consider moving the verifier command behind a typed CIW subcommand once the event contract stabilizes.

Files changed (3) +339 / -0

Enhancement (1) +67 / -0

attest-trace.shAdd ledger-driven attestation trace engine +67/-0

Add ledger-driven attestation trace engine

• Resolves the latest attestation-pack ledger event, cross-checks bundle digest and commit anchors, rebuilds the artifact with 'git archive', and delegates content verification. It distinguishes evidence rejection from infrastructure or invocation failures through exit codes.

governance/attest-trace.sh

Tests (1) +163 / -0

test-attest-bind.shTest attestation tracing with offline cryptographic fixtures +163/-0

Test attestation tracing with offline cryptographic fixtures

• Builds a temporary Git repository, RSA-signed evidence bundle, ledger event, and content verifier without CIW or archive dependencies. Tests the successful trace plus digest drift, forged commit, missing bundle, and event-contract failures.

governance/tests/test-attest-bind.sh

Other (1) +109 / -0

attest-drill.ymlAdd signed-evidence drill and scope RUN_ID for tracing +109/-0

Add signed-evidence drill and scope RUN_ID for tracing

• Adds a manually triggered workflow that packages the repository, creates and verifies a signed attestation, and opens an archive evidence PR. The trace step now receives 'github.run_id' in its own environment, preventing 'set -u' from failing on the step-scoped variable.

.github/workflows/attest-drill.yml

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 94d2c45f-d96c-4c6f-b008-d8cb716cb19e

📥 Commits

Reviewing files that changed from the base of the PR and between 4283c93 and 1210683.

📒 Files selected for processing (1)

• .github/workflows/attest-drill.yml

---

📝 Walkthrough

Walkthrough

新增 RUN_ID 环境变量，并将其绑定到当前 GitHub Actions 运行 ID，供回溯步骤构造分支名。

Changes

回溯运行标识绑定

Layer / File(s)	Summary
回溯步骤绑定运行 ID .github/workflows/attest-drill.yml	回溯步骤新增 RUN_ID 环境变量，并使用 ${{ github.run_id }} 赋值。后续分支引用可在 set -u 环境下使用该变量。

Suggested labels: security, bug

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch w4r3-drill-fix

---

_{Comment @coderabbitai help to get the list of available commands.}

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (1) 📜 Skill insights (0)

1. 账本路径可注入命令 🐞 Bug ⛨ Security

Description

attest-trace.sh 将账本控制的 bundle_ref 未转义替换进 VCMD，随后通过 bash -c 执行；只要证据目录名包含 shell
元字符，回溯验证就能执行任意命令。该脚本用于消费待验证的证据账本，因此不能在完成可信性验证前把账本值当作 shell 语法执行。

Code

governance/attest-trace.sh[R64-66]

+CMD=${VCMD//\{BUNDLE\}/$BUNDLE}
+CMD=${CMD//\{ARTIFACT\}/$TMP/artifact.tar.gz}
+bash -c "$CMD" || die1 "内容级验证红（产物与 SBOM 漂移或验签失败）"

Relevance

●●● Strong

Accepted governance security precedents favor fail-closed validation against attacker-controlled
inputs; no close rejection precedent appeared.

PR-#19
PR-#50
PR-#195

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

脚本直接从账本 payload 读取 bundle_ref，拼成 BUNDLE 后仅以引用形式检查文件存在；之后却把该值做原始文本替换并交给 shell 重新解析。工作流传入的模板也未引用
{BUNDLE}，所以带 ;、命令替换或空白的合法目录名会改变命令结构。

governance/attest-trace.sh[39-50]
governance/attest-trace.sh[64-66]
.github/workflows/attest-drill.yml[104-108]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`bundle_ref` 来自待验证账本，当前被直接替换进命令字符串并交给 `bash -c`，可通过包含 shell 元字符的目录名触发命令注入。

## Issue Context
同时应限制 `bundle_ref` 必须位于指定的 bundle root 内；不要依赖调用方恰好给占位符加引号。

## Fix Focus Areas
- governance/attest-trace.sh[41-50]
- governance/attest-trace.sh[64-66]
- governance/tests/test-attest-bind.sh[90-120]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. GOVERNANCE_TOKEN performs repository writes 📘 Rule violation ⛨ Security

Description

The workflow injects the org-admin GOVERNANCE_TOKEN into GH_TOKEN and uses it to clone, push,
and create a pull request in repositories. This exceeds the token's permitted CI use for org-level
Project writes or membership checks and bypasses the required GitHub App identity.

Code

.github/workflows/attest-drill.yml[56]

+          GH_TOKEN: ${{ secrets.GOVERNANCE_TOKEN }}

Relevance

●●● Strong

Recent token-policy findings were rejected, but this workflow performs cross-repository writes, a
materially closer security context.

PR-#176
PR-#173
PR-#184

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Rule 2825796 permits GOVERNANCE_TOKEN in workflows only for org-level Project writes or membership
checks, while rule 2778539 requires GitHub App identity via the standard helpers for authenticated
automation. The changed workflow maps that secret to GH_TOKEN, then embeds it in authenticated
clone and push URLs and uses the same credential for gh pr create; the repository's credential
policy likewise reserves GOVERNANCE_TOKEN for Project/membership operations.

Rule 2825796: Agents must never access or store the GOVERNANCE_TOKEN outside CI workflow secrets
Rule 2778539: Use GitHub App identity and ghcb script for agent GitHub operations
.github/workflows/attest-drill.yml[54-56]
.github/workflows/attest-drill.yml[64-64]
.github/workflows/attest-drill.yml[87-89]
AGENTS.md[44-46]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The workflow uses `GOVERNANCE_TOKEN` for authenticated repository cloning, pushing, and PR creation, although that credential is restricted to org-level Project writes and membership checks.

## Issue Context
Mint short-lived, repository-scoped GitHub App tokens through `scripts/gh-app-token.sh` or invoke the repository-standard `scripts/ghcb` path. Use separate least-privilege tokens where CI-Workflows and archive require different repository scopes.

## Fix Focus Areas
- .github/workflows/attest-drill.yml[29-36]
- .github/workflows/attest-drill.yml[54-89]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. SBOM 绑定未校验 🐞 Bug ≡ Correctness

Description

脚本读取了 attestation 的 materials.sbom_sha256，却从未读取或比较 payload 中声明的
sbom_sha256，因此这两个记录发生漂移时回溯仍会成功。这样违反了脚本注释声明的 payload 契约，也使“payload↔attestation 互证”结论不成立。

Code

governance/attest-trace.sh[R53-56]

+SUBJ_DIGEST=$(jq -r '.subject.digest.sha256' "$BUNDLE/attestation.json")
+SBOM_SHA=$(jq -r '.materials.sbom_sha256' "$BUNDLE/attestation.json")
+ATTEST_COMMIT=$(jq -r '.materials.git_commit' "$BUNDLE/attestation.json")
+[[ "$SUBJ_DIGEST" == "$ART_DIGEST" ]] || die1 "payload.artifact_digest ≠ attestation.subject.digest（两套记录漂移）"

Relevance

●●● Strong

Accepted governance precedents consistently enforce complete cross-record consistency and fail
closed on omitted validation.

PR-#19
PR-#50
PR-#195

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

payload 契约明确包含 sbom_sha256，工作流也将其写入事件；但 trace 只提取 artifact_digest，读取的 SBOM_SHA
没有参与任何条件，现有一致性检查仅覆盖 artifact digest 和 commit。

governance/attest-trace.sh[9-11]
.github/workflows/attest-drill.yml[61-76]
governance/attest-trace.sh[39-58]
governance/tests/test-attest-bind.sh[72-75]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
回溯流程没有校验 payload 的 `sbom_sha256` 与 attestation 的 `materials.sbom_sha256` 是否一致，导致账本中的 SBOM 绑定字段漂移仍被放行。

## Issue Context
工作流会写入该 payload 字段，脚本也已读取 attestation 侧摘要，但当前变量未使用。应补充缺失字段和不一致的拒绝路径，并添加负向测试。

## Fix Focus Areas
- governance/attest-trace.sh[39-58]
- governance/tests/test-attest-bind.sh[122-155]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

✅ Compliance rules (platform): 22 rules

Review mode: ⚖️ Balanced

Tip of the day

💡 Did you know, you can group findings by type and pick your Finding display, from Minimal to Full

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗