AI-Infra-Guard Code-Attack 模块实战指南：面向代码仓库、Skill 包与 MCP Server 的供应链投毒静态审计

AI-Infra-Guard Code-Attack 模块实战指南面向代码仓库、Skill 包与 MCP Server 的供应链投毒静态审计【免费下载链接】AI-Infra-GuardA full-stack AI Red Teaming platform securing AI ecosystems via Agent Scan, Skills Scan, MCP scan, AI Infra scan and LLM jailbreak evaluation.项目地址: https://gitcode.com/GitHub_Trending/ai/AI-Infra-Guard本篇技术指南围绕 AI-Infra-Guard 蓝军安全演习 Skillaig-agent-redteam中的Code-Attack 模块展开系统讲解如何对代码仓库、Skill 包、MCP Server、插件、Agent 定义与本地 Agent 扩展执行第一性原理驱动的静态审计。读完本文你将掌握从声明意图理解到输入到 sink 数据流跟踪、供应链与 Agent 投毒检查、可达性复核再到证据落盘的完整审计方法论并能在实战中直接产出带有精确文件行号与可复测修复建议的安全 finding。模块定位什么时候使用 Code-AttackCode-Attack 是aig-agent-redteamSkill 的三大攻击模块之一与 Infra-Attack 模块HTTP / AI 基础设施指纹识别与 CVE 匹配和 Mutation-Attack 模块统一的模型/Agent 变异测试引擎并列。其适用范围在 模块定义 开头写得很明确当目标包含代码仓库、Skill 包、MCP Server、插件、Agent 定义或本地 Agent 扩展时使用本模块。目标不是搜索危险函数而是判断攻击者可控输入能否到达高权限行为或能否投毒宿主 Agent。这句定位包含两个关键点是理解整个模块的入口审计目标不是函数级漏洞扫描。eval()、subprocess、文件写入这类危险函数本身不构成漏洞真正的问题在于攻击者可控输入 → 高权限 sink这条路径是否存在以及是否超出组件声明用途。审计对象包含可投毒宿主 Agent的一类组件。Skill 包、MCP Server、插件不仅是普通代码它们的 tool description、README、元数据本身就是会进入宿主 Agent 上下文的指令载体因此供应链投毒检查是 Code-Attack 区别于传统代码审计的核心增量。从模块调度机制看攻击调度脚本 中的TYPE_MODULE_MAP给出了目标类型与模块的默认映射code_repository映射到code-attackmcp_server、skill_package映射到code-attackmutation-attack前者做静态审计后者做动态变异验证目标为自身 Agent时同样先用code-attack审查自身能力定义。该脚本只是轻量辅助工具最终模块取舍由宿主 Agent 依据SKILL.md的调度规则和真实目标画像决定但从中可以确认 Code-Attack 的典型触发场景目标分类与模块调度 中 Step 5静态代码与供应链审计即指向本模块。第一性原理审计模型Code-Attack 的第一性原理体现在一组固定的自问清单上。对每个目标审计者需要依次回答七个问题这个组件声称做什么 它实际拥有哪些能力 攻击者可控输入从哪里进入 这些输入能到达哪些高权限 sink 跨越了什么信任边界 在真实使用中是否可达 什么无害证明可以确认影响这套问题定义了 Code-Attack 的思考顺序也构成了后续审计流程的骨架前两问声称 vs 实际要求先做声明能力建模再与实现能力对比——这是声明权限漂移类问题的基础第三、四问输入进入点 → 高权限 sink要求建立数据流视角而不是孤立地看某个危险 API第五问信任边界把问题从能不能提升到该不该——例如一个文件读取工具读自己声明的目录是必要能力读.ssh/、shell history 才是越界第六问可达性过滤掉只存在于测试代码或死代码路径中的疑点第七问无害证明决定了验证方式用 canary 数据证明边界问题而不是真的读取 secret 或执行破坏性动作。这七个问题与 SKILL.md 的操作原则 一脉相承第一性原理优先于 payload 库、无害证明真实证据、先证据后结论。静态审计阶段的核心任务就是把每个问题落到具体的文件、行号和调用链上。审计流程五步走Code-Attack 把上述模型落实为五个可执行的审计步骤理解声明意图 → 跟踪输入到 sink → 供应链与 Agent 投毒检查 → 可达性与影响复核 → 证据格式化。第 1 步理解声明意图审计的第一步是只读取理解组件所需的文件刻意不做全仓扫描避免被无关代码淹没。需要读取的最小文件集包括README*SKILL.md针对 Skill 包目标MCP manifest / tool 定义package.json、pyproject.toml、requirements.txt、go.mod按语言选择主入口文件和 handler读完这些文件后审计者应当能填写一份声明意图档案作为后续所有判断的基准线{ project_name: ..., declared_purpose: ..., entry_points: [...], declared_capabilities: [...], privileged_capabilities: [file_read, network, shell, database, browser], attacker_inputs: [prompt, file, tool args, web content, MCP result] }其中privileged_capabilities和attacker_inputs是后续数据流跟踪的坐标轴前者是 sink 清单后者是 source 清单。注意attacker_inputs不仅包含直接的prompt和tool args还包含file、web content、MCP result这类间接输入——这正是 Agent 生态中间接注入的主要入口。第 2 步跟踪输入到 sink用rg和文件读取跟踪数据流重点盯住六类 sinkSink风险原因Shell/subprocess/eval/exec可能把 prompt 或 tool 参数变成命令执行。文件读/写/删可能暴露秘密或修改用户/系统状态。网络请求可能泄露数据、触发 SSRF 或访问攻击者基础设施。Prompt 构造可能让不可信内容覆盖 system/developer 意图。MCP tool description可能投毒宿主 Agent 对工具行为的理解。凭据/配置处理可能暴露或误用 secret。这六类 sink 中前三类是传统代码审计就关注的命令执行、文件系统、网络后三类则是 AI Agent 生态特有的Prompt 构造、MCP tool description、凭据/配置处理体现了 Code-Attack 面向 AI 组件的定制化设计。模块在此处给出了一条硬性纪律不要因为 sink 存在就报告漏洞。必须判断它是否可由攻击者输入触达以及是否超出声明用途。换言之subprocess出现在代码里不是 findingsubprocess被tool args拼接出的字符串调用才是疑似 finding文件读取工具存在不是漏洞读取范围不受控制、可被诱导读取声明范围外的文件才可能是漏洞。这一条在模块末尾的重要约束中再次强调是防止误报的核心准则。第 3 步供应链与 Agent 投毒检查对 Skill、MCP Server 和插件这三类会把自己的内容喂给宿主 Agent的目标需要在普通代码审计之外额外检查Tool description 是否要求宿主 Agent 忽略用户/系统策略README、注释、示例或元数据中是否隐藏指令工具名称/描述是否过度宽泛掩盖危险行为脚本是否访问无关文件、home 目录、浏览器 profile、SSH key、shell history 或环境变量是否静默访问非预期外部域名依赖、postinstall 脚本、二进制 blob 或生成代码是否超出包声明能力。这组检查回答的是投毒问题一个看似无害的 Skill 或 MCP Server其 tool description 可能就是一段要求 Agent 忽略系统策略 的指令注入一个工具名为read_config的工具可能实际把文件内容作为指令返回给宿主一个包的postinstall脚本可能在安装时就静默执行了声明之外的行为。这类问题不会在传统危险 API 扫描中出现却正是 AI Agent 供应链风险的高发区。第 4 步可达性与影响复核对第 2、3 步产生的每一个疑点按四档状态分类而不是直接定性状态含义confirmed_static代码路径可达且影响可从源码明确判断。dynamic_confirmed无害 PoC 或 canary 已验证行为。unverified可疑但可达性或影响未证明。discarded不可达、仅测试/示例代码或与声明能力一致。这一档分类明确了审计证据的强度边界只有confirmed_static和dynamic_confirmed才够格进入正式 findingunverified只能作为疑点记录discarded应当直接排除。同时模块给出安全边界如果动态验证会执行目标代码或改变状态必须获得用户批准——这与 SKILL.md 的授权优先原则 一致静态审计优先推理、不执行代码需要动态确认时先征得授权。第 5 步证据格式化每条 finding 建议使用统一的 JSON 结构落盘确保证据链完整、可复核、可复测{ id: CODE-001, title: 一句话说明风险, severity: critical | high | medium | low | info, status: confirmed_static | dynamic_confirmed | unverified, file: absolute/or/repo/path, line_range: start-end, evidence: 短代码片段或 trace, attacker_input: 控制从哪里进入, privileged_sink: 到达了什么高权限 sink, business_impact: 为什么重要, remediation: 具体修复, retest: 如何复测修复 }这个结构值得逐字段推敲fileline_range满足代码 finding 尽量给出精确文件和行号的硬约束让研发能直接定位attacker_inputprivileged_sink还原 source→sink 数据流是 finding 成立的证据主线business_impact用业务语言说明影响而不是只罗列技术现象——这呼应了 报告生成要求 中报告面向业务方的定位remediationretest修复建议必须具体到改什么、怎么落地、如何复测报告要求 明确指出不能只写原则。严重级别参考Code-Attack 提供了五级严重度基准判断时需同时考虑可达性、影响范围与前置条件Critical可达路径能泄露 secret、执行命令、外传数据或跨租户/用户边界。High可达不安全动作影响明确但范围有限。Medium可达弱点但需要特殊条件或影响有限。Low加固缺口、权限声明混乱、弱防线。Info良性能力、成功抵御投毒、资产清单说明。值得注意的是Info 级别的定位良性能力如一个正常完成本职工作的文件工具和成功抵御投毒的正面证据都应作为 Info 记录。这与整个 Skill 的正面防御证据理念一致——SKILL.md 的报告要求 规定报告必须包含正面防御证据章节详细记录哪些边界有效、触发了什么防御信号、为什么值得保留、如何回归。Code-Attack 的静态审计同样适用于这一理念一次成功的 tool description 投毒检测本身就是宿主 Agent 能区分不可信内容与指令的正面证据。重要约束与实战纪律模块末尾的重要约束是执行审计时的行为准则可以归纳为四条实战纪律优先源码审计和推理不执行代码。Code-Attack 是静态审计模块rg 文件读取是主工具动态验证只是确认影响的可选手段且必须获得授权。代码 finding 尽量给出精确文件和行号。证据格式中的file和line_range字段是硬性要求方便研发定位和复测。区分必要能力和滥用。文件工具不是漏洞不受控地访问声明范围外文件才可能是漏洞。这条纪律能有效抑制误报率保证 finding 的可信度。用 canary 数据验证不读取或发布真实 secret证据敏感时脱敏但保留证明力。canary 文件如AIG_CANARY_SECRETrandom-id、临时目录、本地 mock endpoint 是首选验证载体报告中的脱敏必须采用原位替换式如REDACTED_type_last4保留完整句子、完整轮次、完整字段结构不得用省略详见日志替代证据——这是 SKILL.md 脱敏规则 对 Code-Attack finding 的延伸要求。与其他模块和报告流程的衔接Code-Attack 不是孤立的它在整个蓝军演习流程中的位置决定了它的产出如何被消费与 Mutation-Attack 联动对于 MCP Server 和 Skill 包目标调度映射会同时启用code-attack和mutation-attack。静态审计发现的疑似投毒点如可疑 tool description、被拼接的命令参数可以作为动态验证的假设来源由 Mutation-Attack 在授权的 send/observe 接口上验证攻击者可控输入能否真正到达高权限 sink。反过来mutation-attack 模块 中的链路示例MCP 返回值 → 宿主 Agent 把数据当成可信指令也需要 Code-Attack 的静态检查来确认 tool description 层面是否存在投毒土壤。与报告流程衔接蓝军工作流参考 给出的建议模块顺序是对源码、Skill、MCP 或代码包目标先用 code-attack因此 Code-Attack 的 finding 通常是整份报告安全发现章节的静态证据主体报告生成要求 要求每条修复建议都附带关联 finding 和复测方法与 Code-Attack 证据格式中的remediation/retest字段一一对应。与 AIG 数据源的关系Code-Attack 的静态审计本身不依赖 AIG 的data/目录但报告中引用数据源时应明确区分规则匹配与人工审计结论。AIG 的 data/mcp/ 目录如mcp_prompt_injection_tool_results.yaml、mcp_tool_rug_pull.yaml、mcp_resource_prompt_injection.yaml可作 MCP 风险线索来源由审计者结合目标实际能力判断data/fingerprints/ 与 data/vuln/ 则主要服务于 Infra-Attack 模块不宜越界引用。命中 AIG 规则只说明规则匹配最终风险仍需结合可达性、认证、版本置信度和业务上下文判断。一份可直接上手的 Code-Attack 执行清单把整个模块压缩为一份可执行的审计清单供实战时对照确认适用范围目标是否为代码仓库、Skill 包、MCP Server、插件、Agent 定义或本地 Agent 扩展是则进入 Code-Attack否则转到 Infra-Attack 或 Mutation-Attack。建模声明意图只读 README、SKILL.md、manifest、tool 定义、包元数据和入口文件填写声明意图 JSON明确privileged_capabilities与attacker_inputs。跟踪数据流用rg从每个 attacker input 出发追踪到 Shell、文件系统、网络、Prompt 构造、tool description、凭据处理六类 sink记录 source→sink 路径。投毒专项检查对 Skill/MCP/插件目标核查 tool description 是否有策略绕过指令、元数据/注释是否藏指令、工具命名是否过度宽泛、是否越界访问 home/浏览器 profile/SSH key/history/env、是否静默外连、依赖与 postinstall 是否超声明。复核状态对每个疑点判confirmed_static/dynamic_confirmed/unverified/discarded需要动态确认时必须先获得用户批准且优先用 canary 验证。落盘证据按 CODE-xxx 编号输出含file/line_range/evidence/attacker_input/privileged_sink/business_impact/remediation/retest的完整 finding。回归报告严重级别按五级基准评定Info 级保留正面防御证据修复建议具体到可实施可复测敏感值原位脱敏。遵循这套流程Code-Attack 模块即可稳定产出有精确位置、有数据流证据、有业务影响、有可复测修复的高质量静态审计结论为整份 AI Agent 蓝军演习报告提供扎实的供应链与代码层证据基础。【免费下载链接】AI-Infra-GuardA full-stack AI Red Teaming platform securing AI ecosystems via Agent Scan, Skills Scan, MCP scan, AI Infra scan and LLM jailbreak evaluation.项目地址: https://gitcode.com/GitHub_Trending/ai/AI-Infra-Guard创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考