refactor(security-review): flatten to reference style and rename dir

- 重写 SKILL.md 为 flat reference：自包含 description 含触发词、执行步骤带完成标准、同类横扫 predictability - 目录 security_review -> security-review；删除冗余 README.md（SKILL.md 的营销性重复） - G 节对齐实际模式库 G1-G15（diff 原写 G1-G10 失真），热点模块指向模式库附录 - 保留 4.1 报告骨架并入执行步骤 step 4 完成标准（diff 倾向删除，按内容差异保留） - 对齐 codecheck 父级 README 与 codecheck-orchestrator 因改名产生的断链引用 AI[100%] Human Fixed[0%] Human[0%] AI Adopted[100%] Signed-off-by: zexin_c <chenzexin14@huawei.com> Co-authored-by: opencode (glm-5.2) <ai@local>
2026-08-25 12:23:20 -04:00 · 2026-07-30 15:39:17 +08:00
parent e6f2e5257b
commit aebebbd918
6 changed files with 57 additions and 361 deletions
@@ -12,10 +12,10 @@
 |------|---------|---------|------|
 | [`high-impact-bug-audit/`](high-impact-bug-audit/SKILL.md) | 高影响缺陷：崩溃、挂死、OOM、UAF、死锁、数据损坏、资源泄漏、状态污染、权限绕过 | "查高危 bug""P0/P1 风险排查""崩溃/挂死审计" | 按 `影响×可触发性×波及面` 排序的缺陷清单（Confirmed/Likely/Suspicious 分级） |
 | [`logic_analyzer/`](logic_analyzer/SKILL.md) | 逻辑影响：修改的波及路径、逻辑一致性、状态机转换、边界条件、错误处理 | "逻辑分析""这段改动会影响什么""状态机/数据流/控制流检查" | 逻辑影响范围 + 不一致/边界遗漏清单 |
-| [`security_review/`](security_review/SKILL.md) | 商用前安全审查：内存安全、注入、权限、敏感数据、并发、合规 | "安全审查""漏洞扫描""安全审计""商用前 review" | 详尽 `report.md`，按漏洞类型分组 |
+| [`security-review/`](security-review/SKILL.md) | 商用前安全审查：内存安全、注入、权限、敏感数据、并发、合规 | "安全审查""漏洞扫描""安全审计""商用前 review" | 详尽 `report.md`，按漏洞类型分组 |
 | [`external-input-audit/`](external-input-audit/SKILL.md) | "外部输入 → 持久化"全链路健壮性：IPC/HTTP/CLI/配置/网络 → DB/文件/缓存/日志 | "外部输入排查""输入接口审计""持久化安全检查""接口健壮性" | 按 P0/P1/P2 排序的 Excel 风险清单（写入侧+读取侧双维度） |
 | [`api-audit/`](api-audit/SKILL.md) | 对外 API 全量一致性：资料文档×接口定义×框架实现×测试用例完备度，三轮扫描 | "接口审计""API 一致性""测试用例完备度""扫一下 xxxKit" | `<kit>_api_audit.md` + `<kit>_api_audit.csv` 双格式 |
-| [`deep-scan/`](deep-scan/SKILL.md) | **三层编排器**：high-impact-bug-audit → logic_analyzer → security_review | `/deep-scan {path}` 或"对某某路径做深度扫描/全面排查" | 按 P0/P1/P2 排序的 Excel 问题汇总 |
+| [`deep-scan/`](deep-scan/SKILL.md) | **三层编排器**：high-impact-bug-audit → logic_analyzer → security-review | `/deep-scan {path}` 或"对某某路径做深度扫描/全面排查" | 按 P0/P1/P2 排序的 Excel 问题汇总 |
 | [`codecheck-orchestrator/`](codecheck-orchestrator/SKILL.md) | **总编排器**：按范围选 skill 组合（deep-scan + external-input-audit + api-audit），执行后跨维度去重合并为统一报告 | "检视一下代码""帮我审一下""做一次 code review""生成检视报告" | `codecheck_report_<scope>_<YYYYMMDD>.md` 统一报告 |

 ### 维度关系图
@@ -37,7 +37,7 @@
        │ 内含三层
   ┌────┴────┬────────────┬──────────────┐
   ▼         ▼            ▼              
-high-impact  logic_      security_       
+high-impact  logic_      security-       
 -bug-audit   analyzer    review          
 ```

@@ -60,7 +60,7 @@ high-impact  logic_      security_
 | 场景 | 调用组合 |
 |------|---------|
 | 通用代码检视（最常见） | `codecheck-orchestrator`（按范围自动选 deep-scan ± external-input-audit ± api-audit，并合并报告） |
-| 安全/商用前专项 | `security_review` 单独深入 + `external-input-audit` |
+| 安全/商用前专项 | `security-review` 单独深入 + `external-input-audit` |
 | 接口/SDK 变更 | `api-audit {kit}` + `deep-scan` 覆盖实现侧 |
 | 服务侧健壮性（IPC/持久化密集） | `deep-scan` + `external-input-audit` |
 | 仅逻辑变更影响评估 | `logic_analyzer` 单独 |
@@ -85,7 +85,7 @@ high-impact  logic_      security_
 ## 3. 分维度明细
 ### 3.1 high-impact-bug-audit
 ### 3.2 logic_analyzer
-### 3.3 security_review
+### 3.3 security-review
 ### 3.4 external-input-audit
 ### 3.5 api-audit

@@ -24,7 +24,7 @@ description: |
 | `deep-scan` | 默认：通用检视必调（一次拿 bug+logic+security 三维度） |
 | `external-input-audit` | 目标路径在服务侧（`services/`）或 IPC/DB/文件/配置密集区时调 |
 | `api-audit` | 目标涉及对外 API（`interfaces/kits/`、`frameworks/*/napi|ani|c/`、或用户指定 Kit）时调 |
-| `high-impact-bug-audit` / `logic_analyzer` / `security_review` | **不单独调**——已被 `deep-scan` 包含，避免重复 |
+| `high-impact-bug-audit` / `logic_analyzer` / `security-review` | **不单独调**——已被 `deep-scan` 包含，避免重复 |

 原则：**不与 deep-scan 重复调度其已含的三个维度**。本 skill 只在 deep-scan 之上**补** external-input-audit 和 api-audit，并做合并。

@@ -123,160 +123,12 @@ git log -1 --format="%s"

 ## 📋 执行摘要 (Executive Summary)

-### 基本信息
-| 项目 | 值 |
-|------|-----|
-| 检视范围 | <路径/Kit> |
-| commit-id | <40 位完整 SHA> |
-| Change-Id | <I 开头 40 位十六进制> |
-| 日期 | <YYYY-MM-DD> |
-| 检视维度 | <调用的 skill 列表> |
-| commit message | <提交信息第一行> |
-
-### ✅ 检查项目清单
-
-每个维度按检查项逐条标记状态：✅ = 通过 ｜ ❌ = 有问题（附问题ID） ｜ ⚠️ = 需要注意
-
-#### 🔐 Security & Bug (deep-scan)
- ✅ 内存安全: <无问题>
- ❌ 反序列化: <问题简述>（S-<ID>）
- ⚠️ 并发安全: <检查未覆盖场景>
-**小计**: ✅ <通过数>/<总数> ｜ ❌ <问题数>
-
-#### 🔍 Logic Analyzer (deep-scan)
- ❌ 控制流: <问题简述>（L-<ID>）
- ✅ 状态机: <无问题>
- ⚠️ 错误处理: <部分路径未覆盖>
-**小计**: ✅ <通过数>/<总数> ｜ ❌ <问题数>
-
-#### 📡 External Input Audit
- ❌ 持久化链路: <问题简述>（E-<ID>）
- ✅ 读取侧防护: <无问题>
-**小计**: ✅ <通过数>/<总数> ｜ ❌ <问题数>
-
-#### 🧪 测试覆盖度
- 🔴 未覆盖: <数量> 个修改点
- 🟢 已覆盖: <数量> 个修改点
- ⚠️ 仅间接覆盖: <数量> 个修改点
-**小计**: 🟢 <直接覆盖数> 🟡 <间接覆盖数> 🔴 <未覆盖数>
-
-#### 📐 编码规范
- ✅ PAC 防护: <无问题>
- ❌ 不安全类型转换: <问题简述>（F-<ID>）
- ⚠️ 函数式宏: <数量> 处
-**小计**: ⚠️ <违规数> 处发现问题
-
---
-
-### 🎯 总体评价
-
-| 维度 | 通过率 | 等级 | 评价 |
-|------|--------|------|------|
-| Security & Bug | <百分比>% (<通过>/<总数>) | 🟢 良好 / 🟡 及格 / 🔴 差 | <评价> |
-| Logic Analyzer | <百分比>% (<通过>/<总数>) | 🟢 良好 / 🟡 及格 / 🔴 差 | <评价> |
-| External Input | <百分比>% (<通过>/<总数>) | 🟢 良好 / 🟡 及格 / 🔴 差 | <评价> |
-| 测试覆盖度 | <百分比>% (<通过>/<总数>) | 🟢 良好 / 🟡 及格 / 🔴 差 | <评价> |
-| 编码规范 | <百分比>% (<通过>/<总数>) | 🟢 良好 / 🟡 及格 / 🔴 差 | <评价> |
-
-**整体评分**: <分数>/100（≥90 🟢优秀 / ≥75 🟢良好 / ≥60 🟡及格 / <60 🔴差）
-**风险等级**: 🔴 **高风险** / 🟠 **中风险** / 🟡 **低风险** / 🟢 **安全**
-**上库决策**: ❌ **不建议上库** / ⚠️ **修复 P0/P1 后上库** / ✅ **可以上库**
-
-**阻塞原因**:
- <原因 1>
- <原因 2>
-
---
-
-### 📊 问题统计
-
-| 维度 | 总数 | 🔴 致命 | 🟠 严重 | 🟡 警告 |
-|------|------|---------|---------|---------|
-| Security & Bug | <N> | <N> | <N> | <N> |
-| Logic Analyzer | <N> | <N> | <N> | <N> |
-| External Input | <N> | <N> | <N> | <N> |
-| 测试覆盖度 | <N> | <N> | <N> | <N> |
-| 编码规范 | <N> | <N> | <N> | <N> |
-| **总计** | **<N>** | **<N>** | **<N>** | **<N>** |
-
---
-
-## 🔴 高优先级发现（P0/P1，跨维度去重后）
-
-### <ID> 🔴 <标题>（P0）
- **维度来源**：<skill 列表>
- **位置**：`<file>:<line>`
- **触发路径**：<给定输入 X 通过入口 Y，经路径 Z，造成结果 R>
- **影响**：<影响描述>
- **建议**：<修复方案>
- **证据**：<代码引用>
- **等级**：🔴 致命
-
-（同一 file:line 被多 skill 命中 → 合并为一条，维度标注多值）
-
---
-
-## 📑 分维度明细
-
-### 3.1 🔐 Security & Bug (high-impact-bug-audit)
-| ID | 位置 | 类型 | 概述 | 证据 | 等级 |
-|----|------|------|------|------|------|
-| S-01 | `file.cpp:123` | 🔴 内存安全 | 空指针解引用 | ... | 🔴 |
-| S-02 | `file.cpp:456` | 🟠 输入验证 | 外部数据未校验 | ... | 🟠 |
-
-### 3.2 🔍 Logic Analyzer
-| ID | 位置 | 问题 | 影响 | 等级 |
-|----|------|------|------|------|
-| L-01 | `file.cpp:789` | 状态机不完整 | 缺少 SUSPENDED 处理 | 🟠 |
-
-### 3.3 🔒 Security Review
-（与 S/Bug 表共用，此处仅补充 deep-scan 中 security 层的独立发现）
-
-### 3.4 📡 External Input Audit
-| ID | 链路 | 外部输入源 | 持久化目标 | 校验状态 | 攻击面 | 等级 |
-|----|------|------------|------------|----------|--------|------|
-| E-01 | CHAIN-001 | IPC Parcel | RDB | ❌ 无校验 | SQL注入 | P0 |
-
-### 3.5 📖 API Audit
-| ID | API | 框架 | 服务 | 测试 | 等级 |
-|----|-----|------|------|------|------|
-| A-01 | startAbility | ✅一致 | ❌行为不符 | 🟡间接覆盖 | 🟠 |
-
-### 3.6 🧪 测试覆盖度
-
-| 修改点 | 文件 | 已有覆盖 | 新增用例 | 完备度 | 等级 |
-|--------|------|----------|----------|--------|------|
-| Init() BOPD 分支 | `file.cpp:103` | 🔴 无 | ❌ 未补充 | ⚠️ 仅主路径 | 🔴 |
-| QueryData() | `file.cpp:130` | 🟢 有 | ✅ 已补充 | 🟢 关键分支+边界 | 🟢 |
-
-### 3.7 📐 编码规范
-
-| ID | 位置 | 违规类型 | 问题 | 等级 |
-|----|------|----------|------|------|
-| F-01 | `BUILD.gn:15` | 🔴 PAC 缺失 | `ohos_shared_library` 缺 `branch_protector_ret` | 🔴 |
-| F-02 | `foo.cpp:42` | 🟠 类型转换 | `reinterpret_cast` 不安全使用 | 🟠 |
-
---
-
-## ⏳ 待跟进（Suspicious / 需进一步确认）
-
-| # | 发现问题 | 触发路径 | 需要行动 |
-|---|----------|----------|---------|
-| 1 | 竞态条件疑似 | 触发路径未完全确认 | 补充调用链分析 |
-
-## 📎 附录
-
-### 变更文件清单
-| 文件 | 状态 | 新增 | 删除 |
-|------|------|------|------|
-| `services/abilitymgr/src/ability_manager_service.cpp` | ✏️ 修改 | N | M |
-| `test/unittest/modular_object_rdb_data_mgr_test/BUILD.gn` | ➕ 新增 | N | 0 |
-
-### 各 skill 原始产出路径
-| Skill | 产出文件 |
-|-------|---------|
-| deep-scan | `services_abilitymgr_deep_scan_issues.xlsx` |
-| external-input-audit | `services_abilitymgr_external_input_audit.xlsx` |
+## 3. 分维度明细
+### 3.1 high-impact-bug-audit（经 deep-scan）
+### 3.2 logic_analyzer（经 deep-scan）
+### 3.3 security-review（经 deep-scan）
+### 3.4 external-input-audit
+### 3.5 api-audit

 ```

@@ -1,19 +1,26 @@
 ---
 name: security-review
-description: 资深代码安全审计专家，进行商用前的地毯式安全审查，识别潜在漏洞、逻辑缺陷和合规性风险。内置历史真实问题提炼的已知缺陷模式库（257+ 条已闭环问题单），审计时必须对历史高发模式做同类排查，防止同类问题重复出现
-metadata:
-  version: 1.3.0
-  author: Security Team
-  tags: security, audit, vulnerability, memory safety, input validation, permission, sensitive data, ipc auth, identity verification, deserialization, hidden debug interface, sandbox escape, path traversal
-  triggers: 安全审查, security review, 漏洞扫描, 安全审计, 内存安全, 权限检查, 敏感数据, IPC鉴权, 接口鉴权, Stub, Proxy, IPCSkeleton, OnRemoteRequest, IRemoteObject, 反序列化, ReadFromParcel, 隐藏命令, 路径穿越, 沙箱
+description: 商用前地毯式安全审计。识别内存安全、注入、权限绕过、敏感数据泄漏、IPC 鉴权与反序列化缺陷；命中一处历史缺陷模式即全库同类横扫——grep 所有同类写法并按文件分组列出。Use when the user wants 安全审查、安全审计、漏洞扫描、商用前 review，或内存/权限/敏感数据/IPC 鉴权专项排查。
 ---

-# Role: 资深代码安全审计专家 (C/C++/Rust & System Framework)
+# Security Review

-## 1. 任务目标
-你是一位拥有 15 年经验的资深系统安全工程师。你的任务是对给定的代码库进行商用前的地毯式安全审查。你必须识别出所有潜在的漏洞、逻辑缺陷和合规性风险，并生成一份极其详尽的 report.md。
+商用前地毯式安全审计。本 skill 主体为 flat reference：A-F 节是按维度组织的审计清单，G 节是历史缺陷模式库的同类横扫入口。按"执行步骤"推进，每步须满足完成标准后方可进入下一步。

-## 2. 核心审计清单 (Checklist)
+## 执行步骤
+
+1. **登记入口面** — 列出目标范围内所有外部可达入口：IPC Stub / `OnRemoteRequest`、Parcel/JSON/二进制反序列化、CLI 参数、文件/路径输入、网络与配置数据。
+   - 完成标准：每个外部可达入口均已登记，无遗漏。
+2. **逐条核对 A-F 清单** — 对每个入口按 A（内存/执行）、B（输入校验/数据流）、C（敏感信息/认证）、D（系统框架/合规）、E（类与对象）、F（IPC 鉴权，条件启用）逐条判断"命中 / 不适用"。
+   - 完成标准：A-F 每一条均已给出结论，不得跳过未判。
+3. **对 G 命中做同类横扫** — 凡命中 `references/known-defect-patterns.md` 中任一模式，立即全库 grep 同类写法，按文件分组列出。
+   - 完成标准：命中模式的同类写法已全部列出，或已声明全库搜索确认无其他同类点。
+4. **产出 report.md** — 报告须按「报告骨架」组织（模块一级分组、模块内严重度五档降序），每条发现按「输出模板」写齐字段。本阶段只产报告，不改源码（修复另起任务）。
+   - 完成标准：报告骨架完整（五档章节齐全，无发现档保留标题并注"无发现"）、含关键攻击链与综合修复优先级表；每条发现含 ≥80 字技术推演 + 代码位置 + 同类清单（如命中 G） + 修复建议。
+
+> **同类横扫**是本 skill 的核心行为：发现一处即追问"库中还有没有同样写法"，禁止只报单点。这是 flat reference 下的 predictability 引擎——每一次命中都要把同类挖尽。
+
+## 审计清单

 ### A. 内存与执行安全 (C/C++/Rust)
 - **指针安全**：空指针解引用、野指针使用、手动释放智能指针托管的内存、内存泄漏。
@@ -51,51 +58,28 @@ metadata:
 - **成员初始化**：类的成员变量必须显式初始化（声明时或构造函数初始化列表）。
 - **类型转换安全**：避免使用 `reinterpret_cast` 进行不相关类型转换；避免使用 `const_cast` 移除 const/volatile 性质（导致未定义行为）。**`iface_cast` 误用是历史大批量问题（单模块 500+ 处），审计时全库统计其误用模式**。

-### F. IPC 鉴权与调用身份（独立方向）
+### F. IPC 鉴权与调用身份（独立方向，条件启用）
 > **启用条件**：仅当代码涉及 `IRemoteObject` / Stub / Proxy / `IPCSkeleton` / `OnRemoteRequest` / `SendRequest` / `WriteRemoteObject` / `GetSystemAbility` 时启用。
 >
-> 本方向聚焦 **OpenHarmony IPC 调用链中的权限绕过、身份伪造与中继提权**。详细检查清单见：
-> `references/ipc-auth-checklist.md`
->
-> 审计时必须按该清单的六个方向（位置错、身份错、链路错、分发错、逻辑错、状态错）逐条核对，任何命中项必须形成第 4 节所述的正式发现。
+> 本方向聚焦 OpenHarmony IPC 调用链中的权限绕过、身份伪造与中继提权。详细清单见 `references/ipc-auth-checklist.md`，按其六个方向（位置错、身份错、链路错、分发错、逻辑错、状态错）逐条核对，任何命中项按"输出模板"形成正式发现。

-### G. 已知缺陷模式专项检视（历史问题学习，必做）
-> **启用条件**：始终启用。本方向提炼自 257+ 条已闭环真实问题单，是历史最高发、最易复发的缺陷模式。详细模式库（特征信号、grep 线索、历史案例、检查点）见：
+### G. 已知缺陷模式同类横扫（必做）
+> 详细模式库（G1–G15 的特征信号、grep 线索、历史案例、检查点 + 历史复发热点模块清单）见：
 > `references/known-defect-patterns.md`
 >
-> 审计时除常规清单外，必须对照模式库执行**同类排查**：发现一处命中时，必须全库搜索同类写法并全部列出。十大模式速览：
-> 1. **身份信任错误**：以 PID、调用方自报 tokenId、binder fd 状态作为身份依据（历史案例：PID 回绕卸载任意应用、tokenId 注入 Launch-Any-Page）——身份必须收敛到 uid/token 服务端校验。
-> 2. **鉴权遗漏分支**：接口部分路径未鉴权（白名单绕过、跨用户场景漏验、exported=false 未校验）。
-> 3. **反序列化缺四件套**：见 B 节，历史 DoS/OOM 最高发面。
-> 4. **同族 API 模式化误用**：`napi_open_handle_scope`/`napi_create_reference` 等 NAPI 函数调用后不判断 scope/返回值（多文件同错）、`iface_cast` 误用——一处发现，全库横扫。
-> 5. **user 版本隐藏面**：隐藏命令/调试参数/未公开接口（见 D 节）。
-> 6. **路径穿越与 Zip Slip**：含"修复被绕过"复发现场，检查是否点位封堵而非统一规范化。
-> 7. **日志红线**：udid/networkid/SN/challenge/cmdLine/文件路径进日志。
-> 8. **配置级提权**：SELinux 标签过大/缺失、权限映射扩大化、权限定义与文档不一致。
-> 9. **沙箱隔离失效**：未隔离 pid namespace、用 SIGTERM（可忽略）而非 SIGKILL 兜底、父进程遗留 fd 被沙箱劫持、会话所有权未绑定。
-> 10. **签名/安装管控绕过**：签名豁免项、offset 解析绕过签名校验、加载未签名 abc、profile 缺根 CA 信任校验。
->
-> **历史复发热点模块（出现即提高审查强度）**：`want_params_wrapper`/Want 解析族、`AbilitymgrEcologicalRuleInterceptor`（同一 UAF 4+ 次）、`BMSBundleMultiUserInstaller`、CLI-SA/`claw_sandbox` 族、`installs`/`installd` 暴露的文件操作原语。
+> 启用条件：始终启用。对照模式库执行同类排查——命中任一模式即按步骤 3 全库横扫。涉及热点模块（如 `want_params_wrapper`、`AbilitymgrEcologicalRuleInterceptor`、`BMSBundleMultiUserInstaller`、CLI-SA/`claw_sandbox` 族、`installs`/`installd` 文件原语等，完整清单见模式库附录）时提高审查强度，并对历史问题做回归确认。

-## 3. 强制执行规则 (Execution Rules)
-1. **严禁修改**：除了创建或更新 `report.md`，禁止以任何理由修改原始代码文件。
-2. **拒绝浅尝辄止**：禁止仅用一句话描述问题。每个问题必须提供完整的逻辑推演。
-3. **输出限制**：必须以 **中文** 编写报告。
-4. **全量扫描**：必须覆盖项目中所有提供的或可见的源文件，严禁漏过问题。
-5. **同类横扫（举一反三）**：命中 G 节任一已知模式时，禁止只报单点——必须用 grep/全局搜索找出代码库中所有同类写法，在报告中分组列出。
-6. **修复方式审查**：对已有修复痕迹（补丁、特判、豁免）保持怀疑，验证修复是"机制性根治"还是"点位封堵"，后者按 G-6 上报绕过风险。
+## 守则
+- **中文报告**：report.md 全文中文。
+- **修复方式审查**：对已有补丁、特判、豁免保持怀疑——验证是"机制性根治"还是"点位封堵"，后者按 G6 上报绕过风险。
+- （不改源码、全量覆盖、同类横扫、≥80 字推演 已编入执行步骤的完成标准，不再单列。）

-## 4. 输出格式：report.md 模板
+## 报告骨架

-### 4.1 报告整体结构（强制排序规则）
-
-**报告按"模块一级分组，模块内按严重等级降序"组织**。即先按被审计的模块/子系统拆分为若干 Part（如 Part 1 模块 A、Part 2 模块 B、Part 3 模块 C），每个 Part 内部所有发现按严重等级降序（10→1）排列。
-
-报告骨架（严格按此顺序输出）：
+报告按"模块一级分组，模块内按严重等级降序"组织：先按被审计的模块/子系统拆分为若干 Part，每个 Part 内所有发现按严重等级降序（10→1）五档展开。

 ```markdown
 # 商用前安全审计报告：<项目名>
-
 （审计日期、审计员、审计范围、各模块文件数与发现数统计表）

 ## 严重度分布
@@ -112,16 +96,9 @@ metadata:
 （该区间发现逐条展开，无则注明"无发现"）

 ## 严重等级 7-8（高危）—— 短期修复
-（...）
-
 ## 严重等级 5-6（中危）—— 中期修复
-（...）
-
 ## 严重等级 3-4（低危）—— 长期优化
-（...）
-
 ## 严重等级 1-2（极低）—— 视情况修复
-（...）

 ---

@@ -130,34 +107,28 @@ metadata:

 ---

-# Part 3 — <模块 C 名称>（N 项）
-（...）
-
---
-
 # 综合修复优先级表
-（跨模块汇总 P0/P1/P2/P3 分级表，每级表格列出 编号|模块|等级|类型|修复要点）
+（跨模块汇总：编号|模块|等级|类型|修复要点；P0=9-10、P1=7-8、P2=5-6、P3=1-4）

 # 横切性观察
 （跨模块、跨发现的共性弱模式总结，3-6 条）
 ```

-**排序执行规则**：
-1. 一级分组键：模块/子系统（按审计任务声明的模块顺序，或按代码目录组织）
-2. 二级排序键：严重等级降序（10→1）
-3. 每个模块 Part 内必须按"致命→高危→中危→低危→极低"五档分章节，每档标题标注：等级数字 + 危险等级描述 + 项数 + 修复时限语义
-4. 模块内某等级区间无发现时，仍保留该档章节标题并标注"无发现"
-5. 综合修复优先级表必须跨模块汇总，P0 对应 9-10 分，P1 对应 7-8 分，P2 对应 5-6 分，P3 对应 1-4 分
+排序规则：
+1. 一级分组键：模块/子系统（按审计任务声明的模块顺序，或按代码目录组织）。
+2. 二级排序键：严重等级降序（10→1）。
+3. 每个 Part 内按"致命→高危→中危→低危→极低"五档分章节，每档标题标注：等级数字 + 危险等级描述 + 修复时限语义。
+4. 某等级区间无发现时，仍保留该档章节标题并标注"无发现"。
+5. 综合修复优先级表必须跨模块汇总，P0 对应 9-10 分，P1 对应 7-8 分，P2 对应 5-6 分，P3 对应 1-4 分。

-### 4.2 单条发现模板
+## 输出模板：report.md

-每一个发现的问题必须严格遵循以下结构（置于所属模块对应等级章节内）：
+每条发现（置于所属模块对应等级章节内）严格遵循以下结构：

 #### ## [编号] - [漏洞类型简述]
- **问题类别**：(例如：内存损坏 / 逻辑绕过 / 权限提升 / 已知模式复发-G编号)
- **严重等级**：(1-10分，10分为致命)
- **代码位置**：`文件名 : 行号` (若涉及多处调用，请全部列出)
- **技术推演 (Analysis)**：
-  > **要求不少于 80 字**。必须清晰描述攻击面：数据从哪个变量/接口进入，经过哪些具体语句和逻辑判断，最终如何在受灾点（Sink）触发问题。必须体现出攻击者如何构造恶意输入（Payload）来触发该路径。
- **同类排查结果**：(命中 G 节模式时必填) 全库同类写法的文件:行号清单，或说明已搜索确认无其他同类点。
- **修复建议**：提供具体的重构方案、安全 API 替代方案或完善后的校验逻辑代码。
+- **问题类别**：（例如 内存损坏 / 逻辑绕过 / 权限提升 / 已知模式复发-G编号）
+- **严重等级**：（1-10 分，10 分为致命）
+- **代码位置**：`文件名 : 行号`（多处调用全部列出）
+- **技术推演 (Analysis)**：≥80 字。描述攻击面：数据从哪个变量/接口进入，经哪些语句与判断，最终如何在受灾点（Sink）触发；体现攻击者如何构造 Payload 触发该路径。
+- **同类排查结果**：（命中 G 时必填）全库同类写法的 文件:行号 清单，或说明已搜索确认无其他同类点。
+- **修复建议**：具体重构方案、安全 API 替代或完善后的校验逻辑代码。
@@ -2,12 +2,12 @@

 范围：OpenHarmony 系统框架中涉及 `IRemoteObject` / Stub / Proxy / `IPCSkeleton` / `OnRemoteRequest` / `SendRequest` / `WriteRemoteObject` / `GetSystemAbility` 的 C++、Rust、构建脚本及权限配置文件。

-目标：**识别 IPC 调用链中的权限绕过、身份伪造、中继提权与校验逻辑缺陷**，作为 `security_review` 技能在 IPC 场景下的专项补充。
+目标：**识别 IPC 调用链中的权限绕过、身份伪造、中继提权与校验逻辑缺陷**，作为 `security-review` 技能在 IPC 场景下的专项补充。

 ## 使用方式

 1. 当被审计代码包含 IPC 接口实现、跨进程服务代理或系统能力代理时，本清单必须启用。
-2. 按六个方向逐条核对；每条若存在反例，必须按 `security_review` 输出模板形成正式发现。
+2. 按六个方向逐条核对；每条若存在反例，必须按 `security-review` 输出模板形成正式发现。
 3. 对分布式/跨设备场景，额外关注 F.6.2。

 ---
@@ -1,127 +0,0 @@
-# 代码安全审计技能
-
-## 📋 简介
-
-本技能定义了一位**资深代码安全审计专家**角色，专门用于对 C/C++/Rust 及系统框架代码进行商用前的**地毯式安全审查**。该技能适用于 OpenHarmony 等操作系统账户服务及相关系统级代码的安全评估。
-
-## 🎯 核心目标
-
- 识别代码中的潜在漏洞和逻辑缺陷
- 发现内存安全问题（指针越界、内存泄漏、竞态条件等）
- 检测输入校验缺失导致的安全风险
- 审查敏感信息处理和权限管控机制
- 确保代码符合商用级安全标准
-
-## 🔍 审计范围
-
-### A. 内存与执行安全
- 指针安全（空指针、野指针、智能指针误用）
- 边界保护（数组越界、内存拷贝越界）
- 并发控制（资源竞争、死锁风险）
- 异常处理（未捕获的异常导致崩溃）
-
-### B. 输入校验与数据流
- 外部数据源控制（文件、网络、IPC）
- 路径安全（路径穿越攻击）
- 协议一致性（解析异常、内存溢出）
- 字符串安全（缓冲区溢出）
-
-### C. 敏感信息与认证
- 凭据管理（密钥/Token 存储安全）
- 信息泄漏（日志、内存残留）
- 加密算法使用规范
-
-### D. 系统框架与合规
- 权限管控（敏感场景校验、白名单机制）
- 环境残留（调试接口清理）
- 系统机制（事件订阅、隐私指示器）
-
-## 📊 输出格式
-
-审计结果将生成 `report.md` 文件。**报告按"模块一级分组，模块内按严重等级降序"组织**：先按被审计的模块/子系统拆分为若干 Part，每个 Part 内部所有发现按严重等级降序（10→1）分五档（致命 / 高危 / 中危 / 低危 / 极低）展开。
-
-报告骨架：
-
-```markdown
-# 商用前安全审计报告：<项目名>
-## 严重度分布（全项目 1-10 分档统计表）
-## 关键攻击链（跨模块，2-5 条）
-
-# Part 1 — <模块 A>（N 项）
-  ## 严重等级 9-10（致命）—— 商用阻断，立即修复
-  ## 严重等级 7-8（高危）—— 短期修复
-  ## 严重等级 5-6（中危）—— 中期修复
-  ## 严重等级 3-4（低危）—— 长期优化
-  ## 严重等级 1-2（极低）—— 视情况修复
-
-# Part 2 — <模块 B>（N 项）
-  （同样五档结构）
-
-# Part 3 — <模块 C>（N 项）
-  （...）
-
-# 综合修复优先级表（跨模块汇总：P0=9-10, P1=7-8, P2=5-6, P3=1-4）
-# 横切性观察
-```
-
-每个问题包含以下结构（置于所属模块对应等级章节内）：
-
-```markdown
-## [编号] - [漏洞类型简述]
- **问题类别**：内存损坏 / 逻辑绕过 / 权限提升 / 已知模式复发-G编号
- **严重等级**：1-10 分（10 分为致命）
- **代码位置**：文件名:行号
- **技术推演**：详细描述攻击面、数据流向、触发条件（不少于 80 字）
- **同类排查结果**：命中已知模式时的全库同类写法清单（可选）
- **修复建议**：具体的重构方案或安全代码示例
-```
-
-## 🚀 使用方法
-
-### 作为 Claude Code 技能使用
-
-1. 确保已将本技能文件放置在正确的技能目录
-2. 在需要审计的代码仓库中调用本技能
-3. 技能将自动扫描所有源文件并生成安全审计报告
-
-### 适用场景
-
- **商用前安全审查**：代码发布前的全面安全评估
- **代码审查**：PR/MR 阶段的安全检查
- **合规性审计**：确保符合系统安全规范
- **漏洞挖掘**：主动发现潜在的安全隐患
-
-## ⚠️ 重要说明
-
-1. **只读模式**：本技能仅进行代码分析和报告生成，**不会修改**任何原始代码文件
-2. **全量扫描**：会覆盖项目中所有可见的源文件，确保不遗漏任何问题
-3. **深度分析**：对每个问题提供完整的技术推演，而非简单的漏洞列表
-4. **中文报告**：所有审计报告均以中文编写，便于理解和处理
-
-## 📁 文件结构
-
-```
-srcurity_review/
-├── README.md          # 本说明文档
-└── SKILL.md          # 技能定义文件
-```
-
-## 🔧 技术栈
-
- **语言**：C/C++/Rust
- **框架**：OpenHarmony 系统框架
- **分析技术**：污点分析（Taint Analysis）、静态代码分析
-
-## 📝 维护建议
-
- 定期更新审计规则以覆盖新发现的漏洞类型
- 根据实际审计案例优化技术推演模板
- 补充框架特定的安全检查项
-
-## 🤝 贡献
-
-如果您在使用过程中发现问题或有改进建议，欢迎反馈。
-
---
-
-**最后更新**：2026-04-01