Git Blame 审计器

以审计视角执行 git blame。 关注的不是“这段代码为何存在？”，而是“这段代码是否安全？”

你正在开展一次安全审查。某一行代码引起你的注意 —— exec("rm -rf " + userInput)。git blame 显示，该行由一名初级开发人员在周六凌晨 2 点提交，且属于一个包含 47 个文件的巨型提交（mega-commit），未经过任何 PR 审查。这是一次疏忽？后门植入？还是仅仅又一个糟糕的工作周？

Git Blame 审计器 读取与所有 blame 工具相同的原始 Git 数据，但通过审计与风险视角对其进行解读。它标记各类风险信号（⏰ 加班提交、📦 散布式变更、🚫 无审查、🔍 间接调用），映射影响域（哪些测试、服务或端点会触达此代码），并输出结构化的风险判定结果。

本能力明确不用于历史考古。如需重构某行代码背后的叙事时间线及原始决策依据，请使用 phy-git-blame-archaeologist。而当你需要为审计、安全审查或 on-call 事件排障等场景评估代码安全性、风险态势及作者行为模式时，请使用本能力。

本能力的定位（“是” vs “不是”）

触发短语

• “audit this line” / “risk check this change”
• “who last touched this and is it safe”
• “is this code risky”
• “blame audit on” / “git blame audit”
• “find suspicious commits in”
• “show risky changes by this author”
• “/git-blame-audit”

如何提供输入

# 方式 1：审计指定行（聚焦风险的 blame）
/git-blame-audit src/payment/gateway.ts:142

# 方式 2：审计代码范围
/git-blame-audit src/payment/gateway.ts:140-155

# 方式 3：审计符号（函数 / 类 / 常量）
/git-blame-audit --symbol processRefund src/

# 方式 4：全文件审计 — 获取每行的风险摘要
/git-blame-audit src/payment/gateway.ts

# 方式 5：作者风险画像 — 某位作者的所有高风险提交
/git-blame-audit --author "alice@company.com" --since 2026-01-01

# 方式 6：时间窗口扫描 — 过去 7 天内带风险标记的所有提交
/git-blame-audit --since "7 days ago"

步骤 1：运行 git blame 并收集原始信号

# 获取指定行的 blame（完整 porcelain 格式）
git blame -L 142,142 src/payment/gateway.ts --porcelain

# 获取范围的 blame
git blame -L 140,155 src/payment/gateway.ts --porcelain

# 获取整个文件的 blame（精简格式）
git blame --date=short src/payment/gateway.ts

从 porcelain 输出中读取并提取以下字段：

abc1234def5678... 142 142
author Alice Chen
author-mail 
author-time 1825027200     ← Unix 时间戳
author-tz +0800
committer Alice Chen
committer-time 1825027200
summary fix: validate amount
previous e1234567 src/payment/gateway.ts
filename src/payment/gateway.ts
        const MAX_AMOUNT = 100000

用于风险评估的关键字段：

• author-time → 转换为本地时间 → 若不在周一至周五 09:00–18:00 区间则标记为加班
• summary → 检查提交信息中是否含 PR/工单引用
• previous → 获取该行上一次变更的确切提交哈希
• 提交哈希 → 用于步骤 2（审查状态检查）

步骤 2：评估审查状态与提交规模

# 获取完整提交详情
COMMIT="abc1234def5678"
git show $COMMIT --stat               # 共修改了多少文件？
git log --format="%H%n%an%n%ae%n%ai%n%s%n%b" $COMMIT -1

# 检查是否为合并提交（可能表示缺乏个体审查）
git cat-file -p $COMMIT | head -5
# 若显示两个父提交（Merge: xxx yyy），即为合并提交

# 统计总修改文件数（散布指标）
git diff-tree --no-commit-id -r --name-only $COMMIT | wc -l

# 统计总增删行数（扰动指标）
git diff --stat $COMMIT | tail -1 | grep -oP '\d+ insertions?'
git diff --stat $COMMIT | tail -1 | grep -oP '\d+ deletions?'

风险阈值（可配置）：

• 🔴 高散布：单次提交修改文件数 > 15
• 🟡 中散布：单次提交修改文件数 8–15
• ⏰ 加班：提交时间超出标准工作时段（可配置，默认为周一至周五 09:00–18:00）
• 🚫 无 PR 引用：提交信息中缺失 PR/工单模式（如 #\d+、PR-\d+、JIRA-\d+）
• 📏 高扰动：单次提交增删行数 > 500

步骤 3：影响域分析 — 哪些模块依赖此代码？

# 查找引用该符号的函数 / 类
# 若被 blame 行定义了符号：
git grep -n "processRefund|MAX_AMOUNT" -- src/ -- ':!*.test.*'

# 在代码库中查找全部调用者
# （使用 grep 查找函数调用）
git grep -n "processRefund(" -- src/ -- ':!*.test.*'

# 查找本次提交所触及的所有文件（不仅限于被 blame 的行）
git diff-tree --no-commit-id -r --name-only $COMMIT | sort

影响域分类：

• 数据库 / 迁移脚本
• 支付 / 计费
• 认证 / 授权
• 公开 API 端点
• 内部工具函数
• 配置 / 常量
• 构建 / CI 流程
• 测试文件（单行风险较低，但可能反映测试覆盖缺口）

步骤 4：作者行为模式分析

# 作者近期提交次数
git shortlog -sn --since="2026-01-01" --until="now" | grep "Alice Chen"

# 作者文件亲和度 — 该作者通常修改哪些模块？
git log --author="alice@company.com" --oneline --name-only --since="2026-01-01" 
  | grep -E "\.(ts|js|py|go|java|rb)$" | sort | uniq -c | sort -rn | head -10

# 作者提交时间分布
git log --author="alice@company.com" --format="%ai" --since="2026-01-01" 
  | cut -d' ' -f2 | cut -d: -f1 | sort | uniq -c | sort -rn

# 作者是否通常在此模块工作？
# 若其最常修改的 Top 10 文件中从未包含本模块 → ⚠️ 跨领域变更

作者风险信号：

• 🔄 跨领域：作者通常负责前端，但本次变更为数据库迁移脚本
• 🌙 夜间模式：超 40% 提交发生在 09:00–18:00 之外
• 🆕 新贡献者：作者在本仓库提交数 < 10
• 📈 扰动激增：本月提交数超过其月均提交数的 3 倍
• 🗂️ 广泛散布：作者最近一次提交涉及 5+ 个互不相关的模块

步骤 5：综合风险评分

将各项风险信号加权汇总为 0–100 分的综合风险分：

风险等级划分：

• 🟢 低风险（0–20）：常规变更，已审查，属作者常规领域，工作时段内提交
• 🟡 中风险（21–50）：存在若干风险信号 —— 建议在审查中重点关注
• 🟠 高风险（51–75）：多个风险信号叠加 —— 部署前必须完成审计
• 🔴 致命风险（76–100）：强风险模式 —— 需立即展开调查

步骤 6：输出结构化风险报告

## Git Blame 审计报告
**目标**: `src/payment/gateway.ts:142` — `const MAX_AMOUNT = 100000`

---

### 🔴 风险分值：72 / 100（高风险）

| 风险因素 | 权重 | 详情 |
|---|---|---|
| ⏰ 加班 | +15 | 2026-06-13 周六 02:15 CST |
| 📦 散布 | +20 | 共修改 47 个文件 |
| 🚫 无审查 | +15 | 合并提交，无 PR/工单引用 |
| 🔍 跨领域 | +10 | 作者主领域：frontend/src |
| 🆕 新贡献者 | +10 | 总提交数仅 4 次 |
| ⚠️ 敏感领域 | +15 | 支付模块 — 影响计费流程 |

---

### 🧑‍💻 作者画像

**Alice Chen** ``（自 2026-05-20 开始活跃）

- **仓库总提交数**：4（均在过去 3 周内）
- **文件亲和度**：`frontend/src/components/`, `frontend/src/api/`
- **本次提交所属模块**：`src/payment/`（首次涉及 → 跨领域）
- **提交时间模式**：4 次提交中 3 次在 22:00 之后
- **典型审查人**：未发现任一提交存在审查记录

---

### 🌐 影响域

`MAX_AMOUNT = 100000` 被以下位置使用：

src/payment/processor.ts:47 ← 金额校验逻辑
src/payment/validation.ts:88 ← 输入验证
src/api/checkout.ts:23 ← POST /checkout 端点

**上游调用者**（调用上述 3 个文件的文件）：

src/controllers/OrderController.ts:15
src/workers/paymentWorker.ts:33

**本次变更影响范围**：支付处理、结账流程、订单控制器。

---

### 📋 风险详情

**提交 `a1b2c3d4` 修改了横跨 6 个模块的 47 个文件：**

| 模块 | 修改文件数 |
|---|---|
| frontend/src/components | 14 |
| frontend/src/api | 8 |
| src/payment | 7 ← 作者首次涉足的新领域 |
| src/db/migrations | 5 ← 极高敏感度模块 |
| src/config | 4 ← 生产环境配置 |
| tests | 9 |

**其中 3 个文件含高危操作：**
- `src/payment/executeRefund.ts:22` — 使用动态输入调用 eval()
- `src/db/migrations/20260613_add_columns.sql` — 原始 SQL（迁移脚本）
- `src/payment/gateway.ts:142` — MAX_AMOUNT 上限由 50000 更改为 100000

---

### ✅ 建议措施

1. 🔴 **暂停部署** — 本提交需人工审查确认
2. 👥 指派具备支付领域经验的审查人
3. 🔄 要求作者拆分为聚焦型提交（每个提交仅解决单一关注点）
4. 📝 补充工单引用，说明业务需求背景（为何将额度提升 2 倍）
5. 🧪 验证新 MAX_AMOUNT 边界值的测试覆盖率

---

### 📊 快速结论

Git Blame 审计：src/payment/gateway.ts:142
──────────────────────────────────────────────────
风险： 🔴 高风险（72/100）
作者： Alice Chen（新贡献者、跨领域、夜间模式）
时间： 周六 02:15 — 47 个文件、6 个模块、无审查
内容： MAX_AMOUNT 翻倍（50000 → 100000）
影响： 支付处理、结账流程、订单控制器
操作： 🛑 暂停。需领域专家审查。

---

## 快速模式输出

/git-blame-audit src/config.prod.ts:23

🟠 风险：62/100
⏰ 加班（周日 23:47） +10
📦 23 个文件 +15
🚫 无 PR 引用 +15
🔍 环境配置 +10
🆕 新贡献者 +12
作者：Bob（共 2 次提交，无审查记录）
变更：API_ENDPOINT 更改为 https://staging.example.com
操作：🛑 调查 — 生产环境配置中误用 staging URL

---

## 首次成功路径

首次使用者最快获得有效结果的操作路径如下：

1. **导航至** 本地任意 Git 仓库目录
2. **运行命令**：/git-blame-audit any-file.ts:10（任选一个至少含 10 行的文件）
3. **验证输出是否包含**：
   - 风险分值（0–100）
   - 至少一项风险标记（如加班、散布等）
   - 作者与提交上下文信息
4. **可选深入分析**：/git-blame-audit --author "$(git log --format='%ae' -1)" --since 2026-01-01

预期耗时：从触发命令到首份报告生成 < 30 秒。

---

## 示例提示词

- “Audit `src/api/users.ts:88` — is this change safe?”  
- “Show me all risky commits from Alice in the last 30 days”  
- “Flag every line in `src/payment/` that was committed outside business hours”  
- “Risk check the last 10 commits on the `main` branch”  
- “Who changed `MAX_RETRIES` and is it a concern?”  
- “Find all lines in `src/db/` that lack a PR reference in blame”  
- “This PR touches 4 unrelated modules — audit the risk score”  
- “Compare risk patterns between Alice and Bob's commits this sprint”

---

## 注意事项

- **完全离线运行** — 仅依赖本地 git 二进制程序与代码仓库  
- **无外部 API 调用** — 所有分析均在本地完成  
- **模型建议**：推荐使用 DeepSeek 进行自然语言风险解读  
- **阈值可配置**：各风险阈值可根据团队策略调整  
- **非代码审查替代方案** — 它是辅助审查者聚焦关键风险的分流工具  
- **PR 引用模式** 当前适配 GitHub（#\d+）与 Jira（[A-Z]+-\d+）；支持通过配置扩展