القائمة
依赖安全审计（SCA）——按依赖清单 / 锁文件提取 SBOM，匹配已知 CVE 库（NVD / GitHub Advisory）， 对每个命中判定 vulnerable code 是否在项目实际消费路径上（关键路径判据）。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
白盒建模——一次深度建模产出五张共享模型：项目架构（技术栈/分层/框架自有封装/闭源依赖位置）、 入口点（路由/中间件信任边界）、认证与权限（会话/角色/多租户/归属字段）、业务（实体/流程状态机/ 业务不变量/高价值资产）、全局威胁（攻击面×漏洞类别的适用性映射，供下游逐一全测）。本能力不做漏洞判定，为后续 漏洞维度分析建立共享底图。
OS 命令注入综合检测——覆盖直接命令拼接 / shell 元字符 / 参数注入 / 间接 RCE，按回显 / 时间 / 带外通道分诊。 流量中参数值含主机名 / URL / 文件名 / 命令片段、响应里出现 shell 错误关键字（`/bin/sh` / `cmd.exe` / `command not found`）、注入 `sleep N` 耗时增加、上传后异步处理链路时使用。
文件上传多策略综合检测——覆盖扩展名 / MIME / 魔术数 / 解析漏洞 / 上传链组合（LFI / Zip Slip / SVG XSS / SVG XXE）。 流量含 multipart/form-data 上传、响应回显落盘路径、上传后文件可被 GET 解析、上传字段含 filename / path 可控时使用。
IDOR 水平越权检测 — 通过替换资源标识符（ID/UUID/路径）访问他人资源的风险；适用于用户资料、订单、文档、租户隔离场景。
检测路径穿越和本地文件包含（LFI）风险；当目标存在文件读取/下载/预览功能且含路径参数时触发；适用于文件下载、日志查看、模板加载等场景。
黑盒建模 — 迭代式攻击面建模，按站点级 / 页面级 / 功能级三粒度推进；进入新页面即触发一次页面级建模、切换新身份各刷新一次，产出端点账本与页面语义模型，为后续漏洞维度的适用性判断提供依据。
| name | dependency-audit |
| description | 依赖安全审计（SCA）——按依赖清单 / 锁文件提取 SBOM，匹配已知 CVE 库（NVD / GitHub Advisory）， 对每个命中判定 vulnerable code 是否在项目实际消费路径上（关键路径判据）。 |
| when-to-use | 当需要检查项目依赖是否存在已知安全漏洞时 |
| allowed-tools | bash,read_file,list_files,rg,list_skills |
| user-invocable | true |
| argument-hint | [target_path] |
| arguments | ["target_path"] |
按 "依赖清单 / 锁文件 / 已构建产物 / 容器镜像" 四维识别本能力命中场景。
依赖清单 / 锁文件维度（项目根存在以下任一）：
pom.xml（Maven）/ build.gradle / build.gradle.kts（Gradle）/ *.lockfilepackage.json + package-lock.json / yarn.lock / pnpm-lock.yamlrequirements*.txt / Pipfile + Pipfile.lock / poetry.lock / pyproject.tomlgo.mod + go.sumcomposer.json + composer.lockGemfile + Gemfile.lockCargo.toml + Cargo.lock容器 / 基础镜像维度：
Dockerfile 含 FROM <image>:<tag> 拉取基础镜像docker-compose.yml 引用第三方镜像apt-get install / apk add / yum install 落地系统包已构建产物维度（无源码、只看到产物时仍可粗筛）：
*.jar / *.war / *.ear（含 META-INF/MANIFEST.MF）node_modules/ 已落地的传递依赖树vendor/ 目录里直接 vendored 的三方代码（Go / PHP 常见）反向信号（不命中本能力）：
项目使用了含已知 CVE 的依赖库 → 攻击者利用已公开的 PoC 在该库的脆弱代码路径上触发漏洞 → 漏洞实际触达取决于 vulnerable code 是否在项目消费路径上。
成因核心可分为四档：
require / import 含 CVE 的版本，且 vulnerable function 在调用链上。关键判据：CVE 命中本身只代表"理论上有风险"。真实风险 = CVE 命中 + vulnerable code 在项目消费路径。SCA 工具的核心痛点正是 N 个 CVE 但只有 M 个真正在消费路径上——本能力把"是否在关键路径"作为静态可达性的核心判据。
本能力 n/a（原因：SCA 本质是"依赖坐标 + 版本"与"已知 CVE 库"的版本比对 + 库匹配，不走代码层 source → sink 的数据流模型。CVE 命中是 (package, version, cve_id) 三元组级别的事实，不是用户输入流到危险 sink 的污点追踪。需要追依赖内部数据流时移交 dependency-decompile 反编译后接 dataflow-analysis）。
按 SCA 维度的主流命中类型（按已知主流覆盖，不追求穷举）：
| 类型 | 静态识别特征 | 主要判定难点 |
|---|---|---|
| 已知 CVE 直接依赖 | manifest 里直接 declared 的 (groupId, artifactId, version) 命中 NVD / GitHub Advisory | 是否实际消费 vulnerable function |
| 传递依赖 CVE | lock 文件里的传递坐标命中 CVE，但 manifest 看不到 | 调用链跨多层依赖，判可达成本高 |
| 过期 / 不再维护依赖 | 上次发版超过 N 年；upstream 已 archive；无 CVE 不代表安全 | 0day 风险，需做替换评估 |
| 恶意 / typosquatting 包 | 包名与流行库相近（lodahs vs lodash）/ 安装时执行可疑脚本 | 需对比 npm/pypi 主流命名 + 检查 install hook |
| lock 与 manifest 不一致 | package.json 写 ^1.0.0，但 package-lock.json 锁了 1.5.3-known-cve | 构建漂移——开发/CI/生产实际拉到的版本可能不同 |
| 多版本共存 | 同一库（如 log4j-core）出现 1.x / 2.x 多份；其中一份命中 CVE | shaded jar / fat jar 隐藏多版本 |
| 基础镜像系统包 CVE | FROM ubuntu:18.04 拉到 openssl / glibc 的旧版 CVE | OS 层 CVE 通常被业务侧忽视 |
按依赖管理生态找清单与锁文件——粗筛能否命中真实候选取决于扫描面是否覆盖到正确的 manifest / lock 文件。
下列生态 / 工具仅作类似项目示例 不限于此；以目标实际栈为准。
§6 跨框架代码变体在本能力 n/a（见 §6），此处合并展开"按依赖管理工具差异"。SCA 不是代码 pattern 对比，而是依赖生态差异——每个生态的清单文件、锁文件格式、传递依赖展开方式都不同。
pom.xml 直接依赖 + mvn dependency:tree -DoutputType=text 展开传递树build.gradle / build.gradle.kts + gradle dependencies --configuration runtimeClasspathmvn dependency:tree 不展开 shaded 内容，需反编译 jar 看 META-INF/MANIFEST.MF + 类路径package.json 的 dependencies / devDependencies / optionalDependenciespackage-lock.json / yarn.lock / pnpm-lock.yaml（npm v7+ 全展开为扁平树）npm ls --all / yarn list --pattern '*' / pnpm list --depth Infinityrequirements.txt / setup.py / pyproject.toml（PEP 621）Pipfile.lock / poetry.lockpip freeze / pip-audit / poetry show --treego.modgo.sum（含校验和）go list -m all（全模块列表）/ go mod graph（依赖图）/ govulncheck ./...composer.jsoncomposer.lockcomposer show -t / composer auditGemfileGemfile.lockbundle list / bundle auditCargo.tomlCargo.lockcargo tree / cargo auditDockerfile 的 FROM <image>:<tag> 是 OS 包 CVE 的入口apt / apk / yum 安装的系统包同样需扫trivy image <image> / grype <image>本能力 n/a（原因：SCA 关心的是依赖坐标与 CVE 库匹配，不是代码层 pattern 对比。同一漏洞（如 Log4Shell）在 Spring / Dropwizard / Vert.x 项目里"危险形态"都是同一句 log.info(userInput)——差异不在代码 pattern，而在 §5 已展开的"按依赖管理工具差异"。代码层 pattern 对照请参 sast-scan §6 或对应单漏洞 skill）。
加载本 skill 时按这些问题思考：
import 但未被调用，算不算？openssl / glibc / apt 包）有没有覆盖？业务侧通常忽视。本能力只到候选 + 静态可达性——动态利用证据走对应漏洞的黑盒 / graybox skill；关键路径上的闭源依赖追内部数据流走 dependency-decompile + dataflow-analysis。本节方法论描述粗筛与判定，不规定 plan / step 编排。
Dockerfile 存在时）每语言用对应工具生成完整传递依赖列表：
# Java / Maven
mvn dependency:tree -DoutputType=text > sbom-mvn.txt
# Java / Gradle
gradle dependencies --configuration runtimeClasspath > sbom-gradle.txt
# Node.js
npm ls --all --json > sbom-npm.json
# Python
pip freeze > sbom-pip.txt # 或 pip-audit --format=json
# Go
go list -m all > sbom-go.txt
# PHP
composer show -t > sbom-php.txt
# Rust
cargo tree > sbom-cargo.txt
# 容器镜像
trivy image --format json <image> > sbom-image.json
按生态选对应扫描器（优先用支持离线 CVE 库的工具，便于审计环境复现）：
npm audit / yarn audit / pnpm auditpip-audit / safety checkgovulncheck ./...（注意：govulncheck 已内置可达性判断，会标 vulnerable call vs vulnerable but not called）cargo auditmvn org.owasp:dependency-check-maven:check / Trivybundle auditFROM 基础镜像 + 安装层CVE 命中 ≠ 真实风险——需判 vulnerable code 是否在项目消费路径。按下列优先级：
reachable=truego list -deps / npm ls <dep> / mvn dependency:tree -Dincludes=<gav> 看反向依赖ClassLoader 暴露）
reachable=triggered-by-import，等同 confirmed-staticreachable=static-unknownreachable=false，留必要的判定证据（grep 输出 + 配置位置）关键路径上但闭源 / 无源码可读的依赖——sast-scan / dataflow-analysis 无法继续追踪：
移交时随候选附坐标与仓库线索：groupId:artifactId:version + manifest 声明 + 私服 <repositories> / settings.xml mirror 配置，便于下游按坐标取件（sources 优先）。
以下是已知的检查角度，作为基线起点而非必检硬清单。结合目标项目实际依赖栈动态调整，按三态标注（
[x]/[-]/[+]）处置。
闭环判定 / 取证完整性以 common/closure-verification.md 为准，下面只列本能力特有的判定上限与产物契约。
为什么这里是「必须」：本节属交付契约——产物结构关系到下游 dependency-decompile /
result-with-file机器消费；产物聚合或省略会让"该依赖该 CVE 是否落地"无法溯源，因此是刚性要求。
本能力作为 SCA 粗筛 + 关键路径判定的原子能力，判定上限为 static-confirmed（CVE 命中 + 关键路径可达性已证），不等于动态 confirmed。升级路径：
| 状态 | 判据 | 上限 |
|---|---|---|
static-confirmed | CVE 命中 + vulnerable function 在调用链上 / 归属即触发 | 白盒上限，落 status=needs_review + confidence=static-confirmed |
static-unknown | CVE 命中但反射 / 配置驱动消费 / 闭源依赖深处 | 不能默认 not_vulnerable，落 status=needs_review + 标 unknown 原因 |
not_vulnerable | CVE 命中但 vulnerable function 仅在 test scope / 未启用功能 / 版本号实际是 vendor patch | 必须留判定证据 |
partial-coverage | SBOM 提取不全 / lock 缺失 / 闭源依赖未反编译就下"已审"结论 | 结论降级 |
特殊规则：归属即触发类（Log4Shell 风格——库引入即装载危险逻辑）即便业务未直接调用也按 static-confirmed 处理（why：库装载逻辑本身已触发，业务调用与否不改变风险落地）。
升级路径（白盒不能独立给 confirmed）：
static-confirmed 升为 confirmed禁止仅凭 CVE 命中直接判 confirmed——无可观测效果证据，仅依赖坐标匹配不构成动态利用。
为什么这里是「必须」：产物结构是下游机器消费的接口——(package, version, cve_id, reachable) 四元组任一不同即独立成行，聚合或省略会让 result-with-file 计数闸门失效，并让 dependency-decompile 无法回溯到具体依赖坐标。
每确认一条 CVE 命中立即 append 一行到 shared/coverage-ledger/findings/dependency-audit.jsonl，不等汇总阶段回头整理（why："事后总结"是聚合 / 区间 / "等 N 个 CVE" 省略的根源）：
{
"id": "dep-001",
"title": "log4j-core 2.14.1 含 Log4Shell (CVE-2021-44228)",
"severity": "critical",
"cwe": "CWE-502",
"source": "org.apache.logging.log4j:log4j-core:2.14.1",
"sink": "JndiManager.lookup",
"entry_point": "systemic",
"status": "needs_review",
"confidence": "static-confirmed",
"file_location": "pom.xml:42",
"source_report": "dependency-audit",
"description": "..."
}
字段约束：
id 带 dep- 前缀全局唯一status ∈ confirmed | needs_review | not_vulnerable | false_positive | superseded（粗筛默认 needs_review）confidence ∈ static-confirmed | static-unknown | needs-dynamic-confirmation(package, version, cve_id, reachable) 四元组任一不同即各自独立成行——禁止合并折叠source 填依赖坐标（groupId:artifactId:version / pkg@version）sink 填该 CVE 影响的 vulnerable function / classentry_point 填 systemic（SCA 没有 HTTP 入口点）；若 CVE 仅在特定 HTTP 端点触发可填具体入口file_location 填发现该坐标声明的 manifest / lock 文件 file:line禁止：
why：SCA"已完整覆盖"结论是覆盖完整性产物声明，缺失反向验证会让下游误信"该项目依赖侧无风险"。
写"未发现 CVE"或"依赖已全部审计"前，产物必须包含：
static-unknown 单元格的具体原因（反射 / 配置驱动 / 闭源深处）清单不完整 → 结论降级 partial-coverage。
反例 1：CVE 命中但 vulnerable function 仅在 test scope
junit 含 CVE 但 <scope>test</scope>；devDependencies 里的 webpack-dev-server 含 CVE 但生产构建不打入scope=test / devDependencies / build-time onlyreachable=false 并附 scope 证据；不在 prod runtime classpath 上的判 not_vulnerable反例 2：版本号命中但实际 vendor 了官方 patch
pom.xml 写 log4j-core:2.14.1 但实际 jar 是公司内部 fork 已合入 JNDI 修复META-INF/MANIFEST.MF 标了 vendor / fork 信息JndiManager.lookup 实际代码；标 reachable=false 并附反编译证据反例 3：CVE 仅影响特定平台 / 配置
tar 的某 CVE 仅在 Windows 解压时触发；项目跑 Linux container 不命中reachable=false 并附环境证据反例 4：传递依赖深度截断
npm ls 默认深度 / mvn dependency:tree 不展开 shaded jar--all / --depth Infinity 强制全展开；shaded jar 反编译看真实坐标反例 5：npm optionalDependencies 被消费
optionalDependencies 工具默认按"可选"处理跳过审计，但项目实际安装并消费fsevents 作为 optional 但 darwin 环境实际加载；其中含 CVEoptionalDependencies 块里出现，但 runtime 实际 requireoptionalDependencies 纳入扫描面；grep 项目源码是否实际 require反例 6：shaded jar / fat jar 含已知漏洞类但 manifest 看不到
uber-jar 内部嵌入了 log4j-core 旧版本但 pom.xml 没有 log4j 声明mvn dependency:tree 看不到的依赖，但反编译 jar 能找到对应类反例 7：vendored 代码（直接 copy 进项目目录）失去依赖追踪
vendor/ / internal/），不再走依赖管理vendor/、PHP 项目直接 copy 一个老版本库到 lib/vendor/ / lib/ 目录里有看起来不像自家代码的文件vendor/ 目录单独跑 Trivy / Grype 文件系统扫描反例 8：CVE 命中但 vulnerable function 通过反射调用
Class.forName / 反射调用 vulnerable function，静态 grep 找不到Class.forName(config.get("jndi.factory")) 间接走到 vulnerable lookupreachable=static-unknown + 反射点行号；不能默认 not_vulnerable白盒底线：不假装看到看不到的代码。本能力的可观测能力到"依赖坐标 + 版本 + CVE 库匹配 + 项目源码 grep 可达性"为止。
下面这些情形 SCA 无法继续追踪，必须标 static-unknown，不允许默认为 not_vulnerable：
CVE 库覆盖盲区：
闭源依赖内部不可见：
传递依赖图谱不可见的部分：
Class.forName / 插件机制）static-unknown反射 / 配置驱动消费：
reachable=static-unknown + 反射点行号构建漂移：
^1.0.0）与 lock 实际锁定的版本不一致基础镜像层不可见：
scratch 基础镜像直接 copy 二进制——CVE 在源码侧但镜像层看不到底线：本能力写"该项目无 CVE 风险"前，所有 static-unknown 单元格必须显式列出原因。否则结论降级 partial-coverage。
package-lock.json / Pipfile.lock / poetry.lock / Cargo.lock / go.sum），CI 强制校验 lock 与 manifest 一致npm audit / pip-audit / govulncheck / cargo audit 等，新 CVE 出现时自动告警npm-check-updates 等工具自动开 PR 升级依赖go.sum / package-lock.json integrity）+ 包签名验证needs_review），不能因为"廉价扫描没扫到"就放行