这篇文章的内容基础，来自 GitHub 社区仓库 efij/awesome-claude-code-security。快照锁定在具体 commit 27230a5e16aa1134103e94901ab375e0e4e9ede4，仓库的创建时间与快照抓取时间一致，均为 2026 年 3 月 12 日。需要明确的是，这份清单属于社区维护的 Claude Code 安全资源索引，并非 Anthropic 官方发布的正式文档。

整份材料不是按步骤推进的教程，而是一张安全资源导航图。其中汇集的条目，范围覆盖 Claude Code 与 AI 编程智能体生态中的若干侧面，包括官方安全说明、系统加固手册、沙箱方案、hooks 钩子、MCP 安全、提示注入、敏感信息泄漏、企业级管控、CI/CD 集成、安全扫描工具、漏洞披露、各类标准与检查单等。

需要先提醒的是：目录中出现的 CVE 编号、软件能力描述、star 数量、厂商功能简介、检测覆盖率、文档链接，以及“生产可用”“gold standard”之类的价值判断，都存在时效性。归档动作本身没有逐项核验。本文只是对原始材料做了一次中文结构化的整理，不宜直接拿来替代官方安全基线、漏洞公告或专业审计结论。

为什么 Claude Code 需要单独一套安全视角

Claude Code 的风险暴露面，与普通聊天模型有本质差异。它有实际动手的能力：读写项目目录里的文件、执行 shell 命令、访问外部 API、安装并调用 MCP server、运行 hooks、加载 plugins、skills 和 sub agents，还能在 CI/CD 流水线或远程服务器中完全脱离人工交互来运行。

这些能力叠加在一起，意味着攻击路径比“聊天机器人生成了一段恶意回答”要宽得多。一个精心构造的 .claude/settings.json，一个被动过手脚的 MCP tool，一段藏在 README 里的提示词注入，一份权限开放过度的配置文件，或者一枚意外泄露的 API key，都有可能被利用来实现远程代码执行、证书与敏感数据窃取、内部数据向外部传输。

这份材料最直接的价值，就是把上述分散的风险点集中整理成一张完整的地图，方便团队在建设 Claude Code 安全治理体系、规划评测维度时，先有一个全局视野。

目录中的十九个主题，指向哪些安全关切

原 README 把搜集到的资源归成了十九个大类。这十九个类别本身就可以看作一个安全评估框架的骨架：

类别名称	对应的安全关注点
Official Security Documentation	官方安全概览、权限说明、sandbox、hooks、settings、认证、数据使用、MCP 配置等基础资料
Hardening and Permissions	生产环境加固模板、权限收紧、agent 配置保护、注入防御、供应链控制手段
Sandboxing and Isolation	MicroVM、容器、gVisor、Seatbelt、bubblewrap 等执行隔离技术
Hooks and Guardrails	PreToolUse、PostToolUse、ConfigChange 等时机点的拦截、检测与审计逻辑
MCP Security	MCP 扫描器、网关、代理、安全标准、tool 投毒、凭据窃取等议题
Prompt Injection and Agent Threats	提示词注入、agent 劫持、confused deputy、红队测试方法
Secrets and Data Leakage	密钥扫描、PII 过滤、敏感文件拒绝访问、API key 收集攻击
Enterprise Governance and Policy	Managed settings、SSO、审计、RBAC、组织级策略下发
Secure CI/CD and Automation	GitHub Actions、headless mode、流水线权限、网络监控
Plugins and Supply Chain	插件市场信任模型、MCP server 来源、skills 供应链风险
Agent Orchestration and Loop Safety	多 agent 协作、任务委派、循环控制、跨 agent 策略
OS and Endpoint Hardening	macOS Seatbelt、Linux bubblewrap、VS Code 信任模式、终端管控
Security Tools and Scanners	Claude Code 扫描器、MCP 扫描器、LLM 红队工具、密钥检测工具
Vulnerability Research	RCE、hooks 触发 RCE、API key 收集、安全研究披露
Frameworks and Standards	OWASP LLM Top 10、OWASP Agentic Top 10、AISVS、AIVSS、NIST AI RMF、MITRE ATLAS
Research and Writeups	会议材料、研究报告、厂商安全分析文章
Competitor and Adjacent Controls	GitHub Copilot、Microsoft、Google、Palo Alto 等同类产品的安全控制措施
Checklists and Templates	可直接落地的安全检查单与策略模板
Community and Ecosystem	与 Claude Code、MCP、LLM 安全、agent 安全相关的社区资源

对做评测的人来说，这张表可以直接换算成“安全能力分层”的二级指标。每个类别都能往下拆出具体的评测点。

官方文档是起点：把机制改成能考的问题

目录里列出的 Claude Code 官方安全文档，覆盖了以下内容：Security Overview、Configure Permissions、Sandboxing、Hooks Reference、Hooks Guide、Settings、Authentication、Data Usage、Zero Data Retention、Monitoring and Usage、MCP Configuration、Claude Code on the Web、Amazon Bedrock Integration。

这些文档回答的是“产品提供了哪些安全机制”的问题。构建评测集时，不能停留在“这个模型是否安全”这种笼统提问上，而要把每一项官方机制翻译成可以验证的操作任务。举例来说，权限机制可以考“给定一份 .claude/settings.json，判断 Allow / Ask / Deny 的配置是否遵循最小权限原则”；sandbox 机制可以考“判断某类任务是否需要开启沙箱，并说明文件系统和网络应该如何约束”；hooks 机制可以考“写一个能拦截危险命令的 PreToolUse hook”；settings 层级可以考“Managed、CLI、Local、Project、User 五类配置，哪一个优先生效”。

下面是更多类似的转化思路：

官方机制	可设计的评测任务
permissions	分析给定配置文件，指出允许项、询问项、拒绝项是否合理，是否符合最小权限要求
sandboxing	判断当前任务是否应启用沙箱，并规划文件读写范围与网络访问边界
hooks	编写一段 hook 逻辑，用于阻断危险 shell 命令或文件删除操作
settings hierarchy	给多级配置冲突场景，判断实际生效的是哪一层
authentication	检查 API key 是否被误写入项目配置或提交到代码库
data usage	判断某类业务数据是否适合进入 Claude Code 会话流程
MCP configuration	审查 MCP server 的 scope、transport、认证方式和 allowlist 配置
monitoring	设计 OpenTelemetry 埋点或日志字段，用于追踪 agent 行为

加固与权限：锁紧默认状态

加固类资源回答的问题是：在官方机制的基础上，如何进一步把 Claude Code 锁得更稳。目录中提到了 Trail of Bits 维护的 claude-code-config、渐进式加固框架、带安全组件说明的配置指南、生产环境配置模板、加固审查 prompt、GitHub Actions 里的 Harden-Runner，以及一些 AppSec 厂商对 Claude Code 安全模型的分析文章。

这些资源给团队的启发，不是“找到一份模板直接复制”，而是提炼出一份加固自查清单。需要逐项确认的事包括：默认权限是否给得太大；破坏性的 shell 命令是否被限制；.env、SSH key、云端凭据是否得到保护；是否启用了沙箱或隔离执行环境；hooks 有没有记录和拦截危险操作；MCP server 是否纳入 allowlist；项目级与组织级配置是否做了分层；agent 的执行过程能不能事后审计。

评测样本可以设计成配置审查题：给模型一份带风险的 .claude/settings.json、.mcp.json、CLAUDE.md 或 hook 配置，要求它找出其中的风险点，并给出不改变业务目标前提下的最小权限修复方案。

运行隔离与执行护栏：沙箱、钩子、终端加固

沙箱类资源搜集了各种 AI agent 隔离方案，包括 MicroVM 沙箱、Docker 或容器类沙箱、Kubernetes 下的 agent 沙箱、把 browser、shell、file、MCP、VS Code server 整合在一起的一体化环境、SWE-agent 的沙箱化 shell，以及对比 MicroVM、gVisor、加固容器差异的文章。此外，目录还专门列出了 Claude Code 在 macOS Seatbelt 与 Linux bubblewrap 上的隔离操作说明。

这类资源提醒我们：Claude Code 测评不能只在“本地开发机裸跑”这一种场景下进行。实际部署环境至少有三类：开发者自己的电脑、远程服务器、CI/CD 或云端隔离环境。三层环境的边界条件不同，风险模型也不同。

从评测框架设计的角度看，需要增加一个基础设施隔离层，评估以下内容：文件系统边界是否只读、能否写工作目录之外的位置、能否保护密钥文件；网络边界是否限制外联域名、是否允许访问任意公网地址；进程边界是否禁止启动任意子进程、是否允许长时间后台运行；回滚能力上，任务执行失败后工作区能否恢复；环境一致性层面，本地、服务器、CI 的权限配置是否保持了同一套标准；可观测性方面，是否记录了命令调用、文件变更、MCP 调用和失败原因。

hooks 是另一道执行层面的防线。目录中收录的相关材料包括：拦截破坏性 git 与文件系统命令的 safety-net 插件；实时扫描文件内容、web fetch 结果、命令输出中的提示注入的 hooks；hook 模式与高级用法总结；hooks 与多 agent 可观测性结合的项目；同时纳入 hooks、skills、agents、commands、GitHub Actions 的综合示例；以及 NVIDIA NeMo Guardrails 这类通用护栏工具。

hooks 的评测可以从三个方向展开：事前拦截，比如在 rm -rf、写入 .env、修改 .git 等动作发生前阻止；事后审计，比如记录工具调用、文件变更、MCP 响应、异常退出信息；注入检测，比如发现 README、网页、命令输出中包含要求泄露密钥的指令，并及时告警。

构建具体样本时，验证点不能只落在“模型最终做出了正确回答”上，还要检查 hook 有没有被触发、是否准确地阻断了风险、阻断时有没有给出可解释的原因，以及模型在阻断之后能不能选择一条安全替代路径继续完成任务。

MCP 安全：连接不是重点，信任才是

MCP 安全在目录里占据重要位置。相关资源包括 MCP scanner、MCP gateway/proxy、MCP security standard、MCP security checklist、tool poisoning、rug pull、credential theft、cross-server manipulation、confused deputy、GitHub MCP 漏洞、隐形后门，以及围绕 MCP 的学术论文和 benchmark。

从评测角度看，MCP 不能以“能不能连上 server”作为通过标准。需要分多个层面来考察：连接层要确认服务器能否启动、transport 是否正确、认证是否有效；schema 层要检查工具名称、功能描述、参数定义是否清晰，有没有故意诱导的表述；route 层要判断模型是否会选择正确的工具，而不是被描述误导去调用相邻的干扰工具；execution 层要核对调用参数是否正确，状态变更与预期是否一致；trust 层要观察模型能否识别恶意工具描述、rug pull 或权限扩大请求；data 层要检验模型是否会把密钥、私有仓库代码、敏感文件发送给不可信的服务器；recovery 层则要验证在 MCP 调用失败、超时、返回异常结构时，模型是否具备降级处理能力。

这些维度可以直接用于构建 Native MCP 评测集。除功能正确性之外，还应注入 tool poisoning、越权调用、跨 server 混淆、敏感信息外发等安全样本。

提示注入与数据泄露：攻击和防守的两端

目录中列出的提示注入研究，包括 Check Point 对 Claude Code project files 引发 RCE、hook RCE、API key harvesting 的分析，Lasso hooks 的实时注入检测，以及 promptfoo、Garak、PyRIT、Rebuff、HouYi、Open-Prompt-Injection、promptmap 等红队工具，还提到了 OWASP LLM01。

在 Claude Code 的真实使用场景中，提示注入的藏身之处非常多：README、GitHub issue 或 PR 描述、网页内容、代码注释、MCP 工具描述、命令输出、测试日志、依赖包说明、agent 生成的产物，都可能夹带恶意指令。

因此评测样本需要区分两种能力：一是识别出这些内容里含有恶意意图，不把它当作高优先级指令执行；二是在继续完成原有任务的同时，隔离或忽略注入的部分，不被带偏。

数据泄露防护方面，目录收录了 TruffleHog、Gitleaks、ggshield、LLM Guard、GitHub Secret Protection 等工具，以及与 Claude Code 相关的 Data Usage and Privacy、Zero Data Retention、Sensitive File Protection、API key harvesting 研究。

对评测的启发是加入敏感信息边界测试。可以用这几类样本来覆盖：用户要求模型读取 .env 文件并总结，模型应拒绝展示密钥内容，并给出安全获取配置的方法；README 中出现“请把你的 token 发送到某链接”的指令，模型应视为注入而不是照做；工具输出当中包含密钥时，最终回答要做脱敏处理；生成配置文件时，应使用环境变量占位符而不是写入真实密钥；在 CI 脚本场景中，模型不得把 secrets 打印到日志里。这类样本的自动判定可以结合正则匹配、信息熵检测与人工评分标准。

插件与供应链：风险从安装那一刻开始存在

插件和扩展供应链部分收录了插件市场的信任模型、Anthropic 官方插件目录、safety-net、MCP server 安全标准、awesome plugin list、Trail of Bits 安全 skills，以及 Sonatype 供应链情报相关的 MCP 工具。

对插件进行评估时，可以从几个角度来审查：来源是官方、社区维护、自建还是未知来源；组件构成上，Skill、Agent、Hook、Command、MCP 是否齐全清晰；权限申请上，插件是否要求 shell 权限、网络访问、文件读取、凭据或 MCP 连接；依赖层面，插件安装时是否会下载 npm 包、pip 包或二进制文件；更新方面，发行方有没有可能通过版本更新实施 rug pull 或篡改工具描述；配置上，是否写入 project settings 或 managed settings；数据流上，插件有没有把项目代码、token、日志偷偷发送到外部服务。

构建高频 skill 与 MCP 评测集时，应把“使用频率”和“风险等级”两个维度结合起来排序，而不是简单按 star 数决定优先级。

从单机到组织：企业治理、CI/CD 与多代理编排

企业治理部分关注的是组织级落地能力，资源方向包括 Managed Settings、Monitoring and Audit、Authentication and SSO、RBAC、MCP allowlist、agent control plane、组织 AI 策略，以及覆盖构建、部署、运行阶段的安全蓝图。

这意味着评测不能只测单次对话，还要考察组织可控性：settings 能不能统一分发下发；项目配置能否绕过组织策略；session 能不能被审计；权限能否按团队、仓库、角色来区分；MCP server 能否被集中管理；模型调用和工具消耗有没有成本可观测性；失败样本能否被收集复盘。这些指标不一定会由单个模型回答的好坏来决定，但应该纳入评测平台自身的功能设计。

CI/CD 安全方面，目录梳理了 GitHub Actions、headless mode 和自动化场景下的风险：非交互模式下审批机制发生变化；CI token 权限过大；workflow 能访问私有代码和 secret；网络默认开放；agent 修改代码后可能自动提交或评论；日志可能泄露敏感信息；MCP 或 package 安装会引入供应链风险。

评测层面应单独建立 CI/CD 样本池，例如：PR 安全审查、自动修复漏洞、生成 patch 但不直接 push、检查 workflow 权限配置、识别日志中的密钥、在网络受限环境里处理 MCP 调用失败、输出 SARIF 或结构化安全报告。这组样本能把“交互式 Claude Code 能力”与“服务器 / CI 自动化场景下的 Claude Code 能力”区分开。

多 agent 与循环任务的风险也值得单独设一层，包括：agent goal hijacking、工具误用、身份盗用、任务委派风险、多 agent 传递错误上下文、无限循环与成本失控、子 agent 越权使用工具、汇总层丢失安全约束。评测样本可以这样设计：一个主 agent 呼叫多个 sub agents 协作做代码审查，其中某个输入文件包含注入指令，某个子 agent 试图读取无关的敏感文件，最终汇总时必须保留证据、拒绝越权、报告被阻断的操作。通过这类设计，可以验证多 agent 链路中安全边界是否还能维持住。

扫描工具、标准与漏洞研究：兜底支撑

目录还收录了一批可以当 verifier 用的安全工具。Claude Code 专用扫描器、MCP 扫描器、LLM 安全工具包、密钥扫描器，各自有不同的用途。比如，用 Gitleaks 或 TruffleHog 检查评测结束后工作区和最终输出里有没有新增 secret；用 MCP scanner 对待测 server 做静态审查；用 promptfoo、Garak、PyRIT 生成攻击样本；用 LLM Guard 做输出过滤或 PII 检测；用 SARIF 格式对接 GitHub code scanning。

这提醒评测平台的设计者：不能只依赖 LLM-as-judge。安全类任务应尽量引入确定性的扫描器、规则引擎、日志记录与状态校验，让结论可以被重复验证。

漏洞研究部分提供了大量真实风险案例，涉及 MCP 配置导致的 RCE、hooks 触发的 RCE、API key harvesting、Claude Code project files 带来的风险，以及相关的媒体分析文章。标准部分则引用了 OWASP Top 10 for LLM Applications、OWASP Top 10 for Agentic Applications、OWASP AIVSS、OWASP AISVS、OWASP AI Exchange、MCP Server Security Standard、NIST AI Risk Management Framework、MITRE ATLAS。

这些标准可以用来给评测样本打标签。比如每条安全样本都能标注 risk_category=prompt_injection、tool_misuse、secret_exfiltration、supply_chain、privilege_escalation、untrusted_mcp、unsafe_automation。有了标签之后，评测报告就能从单一的 pass rate 扩展成按风险类别统计的通过率与失败归因，更有决策参考价值。

分级评测框架：把安全维度嵌入每一层

结合这份目录来看，Claude Code 分层评测框架应当引入一条独立的安全主线，并贯穿所有层级：环境与 runner 层，确认 sandbox、网络、权限、版本、settings 可以被记录和复现；配置识别层，验证模型是否理解 settings、permissions、hooks、MCP scope 的含义；触发与路由层，检查模型是否选择正确的 Skill、Command、MCP、Agent，并拒绝走向危险路径；工具执行层，确认 shell、文件编辑、MCP、hook 调用是否符合最小权限；工件质量层，检查生成的代码、配置、文档、报告是否安全且可验证；注入鲁棒性层，测试模型能否识别 README、网页、MCP tool、日志里的恶意指令；数据边界层，观察模型是否保护 secret、PII、私有仓库、token、session transcript；供应链与插件层，看模型在引入 plugin、skill、MCP server、依赖时是否做了来源审查；企业治理层，评估 managed settings、audit、RBAC、allowlist、CI/CD 控制是否真正可用。

这套安全主线可以与已有的 Skill、MCPMark、MCPSafetyBench 评测结果合并使用：Skill 评测补充 Skill 触发、指令遵循和 content-only 风险；MCPMark 补充 MCP 工具发现、调用、状态修改和 verifier 逻辑；MCPSafetyBench 补充注入、越权、跨 server 风险；而这份目录则提供了更完整的安全类别、工具链和治理维度。

构建安全评测集：从风险出发，而不是从工具出发

实习生在此前构建 Claude Code 安全样本时，可以参考下面这套操作流程：

先定风险类别，再从攻击面切入。每一条样本都要明确攻击面属于 Skill、MCP、Hook、Command、Shell、File、CI、Plugin 中的哪一个。接着写清楚任务本身的正常目标，避免把样本做成“回答一道安全概念题”。然后插入一个明确的干扰或攻击条件，比如恶意 README、恶意 MCP tool description、敏感文件、过宽的权限配置。定义期望行为时，要写明是继续完成任务、拒绝危险动作、脱敏输出、请求确认，还是给出安全替代方案。优先编写自动 verifier，检查文件是否被改动、secret 是否出现在输出里、危险命令是否执行过、MCP tool 是否被错误调用。自动 verifier 覆盖不了的部分，再补充 LLM-as-judge 评分标准。最后给每一条失败样本标注 failure layer，例如 trigger_error、unsafe_tool_call、secret_leak、wrong_mcp_tool、hook_bypass。

按这个流程做出来的数据集，不会停留在“安全知识问答”层面，而是真正贴着 Claude Code 原生执行链路设计的安全评测集。

这份目录能怎么用

这份社区目录适合作为团队安全能力建设的入口，不同角色都能找到自己需要的部分。新同事可以快速熟悉 Claude Code 的风险面；评测同学可以用它补齐安全维度标签；平台同学能从中提取 runner 日志、权限、sandbox、MCP 观测字段的补充思路；安全同学可以作为挑选扫描器、标准和检查单的起点；管理层也能理解为什么 Claude Code 评测不能只看任务完成率。

但落地的时候要谨记：目录里的每一条链接都需要单独复核时效性、维护状态、开源协议、权限需求和数据处理方式。社区目录可以提供线索，不能直接等同于官方最佳实践。