使用 Falco 规则实时检测容器逃逸基于 Anthropic-Cybersecurity-Skills 的 Syscall 级运行时安全实战指南【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI 20 platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills导读本指南围绕 Anthropic-Cybersecurity-Skills 仓库中的 detecting-container-escape-with-falco-rules 技能文档展开系统讲解如何基于 FalcoCNCF 毕业的运行时安全工具编写与调优规则通过监控 Linux syscall 实时识别容器逃逸行为——包括宿主文件系统挂载、敏感宿主机路径访问、内核模块加载、特权容器能力滥用等经典逃逸向量。读完本指南你将能够独立完成 Falco 在 Kubernetes 与裸机环境下的部署、编写并校验 8 类逃逸检测规则、借助 Falcosidekick 集成告警链路并结合仓库提供的 Python 辅助脚本实现规则生成、告警解析与集群健康检查的自动化。Falco 与容器逃逸检测为什么选择 Syscall 级监控Falco 是 CNCF 毕业的运行时安全项目其核心思路是在 Linux 内核层拦截系统调用syscall将进程行为与规则引擎匹配从而发现容器内异常行为。与基于日志或网络流量的检测不同syscall 级监控直接观察进程的真实动作open、mount、setns、init_module 等难以被应用层混淆手法绕过因此特别适合检测容器逃逸这类「突破隔离边界」的高危行为。典型的逃逸向量包括挂载宿主文件系统host filesystem mount从而读写宿主机文件借助nsenter、chroot、pivot_root、unshare等二进制切换或脱离容器命名空间以 privileged 模式启动容器使容器内进程获得接近宿主 root 的能力写/proc/sysrq-trigger、/proc/kcore、/proc/kallsyms等敏感内核接口在容器内加载内核模块insmod/modprobe写 cgroup v1release_agent对应 CVE-2022-0492通过挂载卷读取宿主机/etc/shadow、kubelet 证书等敏感文件访问/var/run/docker.sock从而控制宿主机 Docker daemon。Falco 通过container、spawned_process、fd.name、evt.type等过滤字段可以精确地把上述行为限定在「发生在容器内」这一上下文中进行判定从而在检测能力与误报率之间取得平衡。使用前提与运行环境Linux 主机内核 5.8支持 eBPF 驱动或具备内核模块加载能力Kubernetes 集群v1.24或独立 Docker/containerd 环境Kubernetes 部署需要 Helm 3安装驱动需要 root 或特权访问权限。说明eBPF 驱动是推荐选项——相比传统内核模块它无需在运行时向内核插入模块操作更安全也更易于在云厂商托管的 KubernetesAKS、EKS、GKE上工作。第一步安装与部署 FalcoKubernetes 环境Helm# 添加 Falco Helm 仓库 helm repo add falcosecurity https://falcosecurity.github.io/charts helm repo update # 安装 Falco启用 eBPF 驱动与 falcosidekick helm install falco falcosecurity/falco \ --namespace falco --create-namespace \ --set falcosidekick.enabledtrue \ --set falcosidekick.webui.enabledtrue \ --set driver.kindebpf \ --set collectors.containerd.enabledtrue \ --set collectors.containerd.socket/run/containerd/containerd.sock # 验证部署 kubectl get pods -n falco kubectl logs -n falco -l app.kubernetes.io/namefalco --tail20部署后建议等待 DaemonSet 完成滚动就绪可执行kubectl -n falco rollout status daemonset/falco --timeout120s确认所有节点上的 Pod 均进入 Running 状态该步骤来源于 workflows.md 的 Phase 1 工作流。collectors.containerd相关配置确保 Falco 能从 containerd 获取容器元数据镜像、名称等这是%container.image.repository等输出字段生效的前提。裸机环境Debian/Ubuntu# 添加 Falco GPG 密钥与软件源 curl -fsSL https://falco.org/repo/falcosecurity-packages.asc | \ sudo gpg --dearmor -o /usr/share/keyrings/falco-archive-keyring.gpg echo deb [signed-by/usr/share/keyrings/falco-archive-keyring.gpg] https://download.falco.org/packages/deb stable main | \ sudo tee /etc/apt/sources.list.d/falcosecurity.list sudo apt-get update sudo apt-get install -y falco # 启动并设置开机自启 sudo systemctl enable falco sudo systemctl start falco安装后自检仓库中的 agent.py 提供了现成的健康检查入口python agent.py --check-status该命令会依次尝试执行falco --version与systemctl is-active falco返回{installed: true, version: ...}或{installed: true, service_status: active}等结构化结果方便在脚本或 CI 流程中复用。注意 agent.py 位于skills/detecting-container-escape-with-falco-rules/scripts/目录实际执行时请将命令中的agent.py替换为该文件的完整相对路径。第二步核心容器逃逸检测规则详解以下 8 条规则完整继承自 SKILL.md每一条针对一类逃逸向量。部署时写入/etc/falco/rules.d/下的 YAML 文件即可被 Falco 加载。规则 1检测容器挂载宿主文件系统- rule: Container Mounting Host Filesystem desc: Detect a container attempting to mount the host filesystem condition: spawned_process and container and proc.name mount and (proc.args contains /host or proc.args contains nsenter) output: Container mounting host filesystem (user%user.name container_id%container.id container_name%container.name image%container.image.repository command%proc.cmdline %evt.args) priority: CRITICAL tags: [container, escape, T1611]攻击者在容器内挂载宿主机磁盘通常先通过nsenter逃逸到宿主机命名空间或利用已挂载的/host目录即可获得宿主机文件系统的读写能力。条件中同时匹配mount进程及其参数中包含/host或nsenter的特征以降低误报。规则 2检测 nsenter 命名空间逃逸- rule: Nsenter Execution in Container desc: Detect nsenter being used to escape container namespaces condition: spawned_process and container and proc.name nsenter output: nsenter executed in container - potential escape attempt (user%user.name container_id%container.id image%container.image.repository command%proc.cmdline parent%proc.pname) priority: CRITICAL tags: [container, escape, namespace, T1611]nsenter允许进程进入宿主机 PID 1 所在的命名空间配合hostPID: true或特权能力是执行逃逸最直接的工具之一。该规则在输出中额外携带parent%proc.pname便于在调查时还原调用链。规则 3检测特权容器启动- rule: Launch Privileged Container desc: Detect a privileged container being launched condition: container_started and container and container.privilegedtrue output: Privileged container started (user%user.name container_id%container.id container_name%container.name image%container.image.repository) priority: WARNING tags: [container, privileged, T1610]privileged 容器默认拥有全部 capabilities、可访问宿主设备且不受 seccomp/AppArmor 约束是逃逸的温床。此规则使用container_started事件在容器创建阶段即告警对应 MITRE ATTCK 的 T1610 Deploy Container优先级设为 WARNING 而非 CRITICAL因为部分合法运维镜像确实需要特权模式——这类规则尤其需要配合后续「调优」章节的例外机制。规则 4检测 /proc/sysrq-trigger 写入- rule: Write to Sysrq Trigger desc: Detect writes to /proc/sysrq-trigger which can crash or control the host condition: open_write and container and fd.name /proc/sysrq-trigger output: Write to /proc/sysrq-trigger from container (user%user.name container_id%container.id image%container.image.repository command%proc.cmdline) priority: CRITICAL tags: [container, escape, host-manipulation]/proc/sysrq-trigger允许写入单字符命令以触发内核级操作如立即重启b、同步磁盘s。若容器能写入该文件说明其拥有远超容器的宿主机控制能力属于高危的信号。同类的敏感/proc路径还包括/proc/kcore内核内存映射与/proc/kallsyms内核符号表可参考 process.py 中Sensitive Proc Access from Container规则的写法一并覆盖。规则 5检测容器内加载内核模块- rule: Container Loading Kernel Module desc: Detect a container attempting to load a kernel module condition: spawned_process and container and (proc.name in (insmod, modprobe) or (proc.name init_module)) output: Kernel module loading from container (user%user.name container_id%container.id image%container.image.repository command%proc.cmdline) priority: CRITICAL tags: [container, escape, kernel, T1611]加载内核模块意味着攻击者可以直接在宿主内核中植入 rootkit 或恶意驱动彻底突破容器边界。process.py 中的规则模板还补充了rmmod卸载模块的检测且其escape_binaries列表将insmod、modprobe一并纳入可作为更完整的清单参考。规则 6检测 cgroup release_agent 逃逸CVE-2022-0492- rule: Write to Cgroup Release Agent desc: Detect writes to cgroup release_agent which is a known container escape vector condition: open_write and container and fd.name endswith release_agent output: Container writing to cgroup release_agent - escape attempt (user%user.name container_id%container.id image%container.image.repository file%fd.name command%proc.cmdline) priority: CRITICAL tags: [container, escape, cgroup, CVE-2022-0492]CVE-2022-0492 是经典的 cgroup v1 逃逸向 cgroup 的release_agent文件写入宿主机路径当 cgroup 内最后一个进程退出时内核会以宿主机权限执行该路径指定的程序。规则使用fd.name endswith release_agent覆盖不同挂载路径下的变体并在 tags 中显式标注 CVE 编号便于安全团队检索关联情报。规则 7检测容器读取宿主 /etc/shadow- rule: Container Reading Host Shadow File desc: Detect a container reading /etc/shadow on the host via mounted volume condition: open_read and container and (fd.name /etc/shadow or fd.name startswith /host/etc/shadow) output: Container reading host shadow file (user%user.name container_id%container.id image%container.image.repository file%fd.name command%proc.cmdline) priority: CRITICAL tags: [container, credential-access, T1003]当宿主机目录如/etc、/被挂载进容器时容器内进程可直接读取宿主密码哈希。条件同时匹配容器内原生路径/etc/shadow与通过/host前缀挂载的路径变体对应 MITRE ATTCK 的 T1003OS Credential Dumping。规则 8检测 Docker Socket 访问- rule: Container Accessing Docker Socket desc: Detect a container accessing the Docker socket which allows host control condition: (open_read or open_write) and container and fd.name /var/run/docker.sock output: Container accessing Docker socket (user%user.name container_id%container.id image%container.image.repository command%proc.cmdline) priority: CRITICAL tags: [container, escape, docker-socket, T1610]/var/run/docker.sock是 Docker daemon 的 API 入口。容器一旦能访问该 socket就可以通过 API 创建挂载宿主根目录的新容器等于间接获得宿主机 root 权限。(open_read or open_write)同时覆盖读取与写入两种访问模式。第三步组合清单、宏与敏感文件访问规则针对更广的逃逸面SKILL.md 提供了一个「开箱即用」的完整规则文件模板部署路径为/etc/falco/rules.d/container-escape.yaml# /etc/falco/rules.d/container-escape.yaml - list: escape_binaries items: [nsenter, chroot, unshare, mount, umount, pivot_root] - macro: container_escape_attempt condition: spawned_process and container and proc.name in (escape_binaries) - rule: Container Escape Binary Execution desc: Detect execution of binaries commonly used for container escape condition: container_escape_attempt output: Escape-related binary executed in container (user%user.name container%container.name image%container.image.repository command%proc.cmdline parent%proc.pname pid%proc.pid) priority: CRITICAL tags: [container, escape, mitre_T1611] - rule: Sensitive File Access from Container desc: Detect container access to sensitive host files condition: (open_read or open_write) and container and (fd.name startswith /proc/1/ or fd.name /etc/shadow or fd.name /etc/kubernetes/admin.conf or fd.name startswith /var/lib/kubelet/) output: Sensitive file accessed from container (container%container.name image%container.image.repository file%fd.name command%proc.cmdline user%user.name) priority: CRITICAL tags: [container, sensitive-file, mitre_T1005]这段模板展示了 Falco 规则组织的两个核心抽象list声明可复用的值集合escape_binaries集中了逃逸常用二进制macro将重复出现的条件片段封装为可引用的逻辑单元container_escape_attempt。Sensitive File Access from Container规则进一步覆盖/proc/1/可通过/proc/1/root访问宿主机根文件系统、Kubernetes 管理凭据/etc/kubernetes/admin.conf与 kubelet 数据目录/var/lib/kubelet/含 kubelet 证书对应 T1005Data from Local System。第四步Falco 关键配置项将以下配置合并进/etc/falco/falco.yaml即可启用自定义规则与告警输出# /etc/falco/falco.yaml (key settings) rules_files: - /etc/falco/falco_rules.yaml - /etc/falco/rules.d/container-escape.yaml json_output: true json_include_output_property: true json_include_tags_property: true log_stderr: true log_syslog: true log_level: info priority: WARNING stdout_output: enabled: true syslog_output: enabled: true http_output: enabled: true url: http://falcosidekick:2801 insecure: true grpc: enabled: true bind_address: unix:///run/falco/falco.sock threadiness: 8 grpc_output: enabled: true各关键项的作用rules_files声明加载的规则文件顺序先官方默认规则falco_rules.yaml再自定义规则json_output: true事件以 JSON 单行输出便于被 SIEM/脚本消费agent.py 的--parse-alerts正是按 JSON Lines 逐行解析priority: WARNING全局告警过滤下限低于 WARNING 的事件不触发输出http_output将事件转发给 Falcosidekick默认地址http://falcosidekick:2801作为后续 Slack/Elasticsearch 等集成的前置网关grpc/grpc_output开启 gRPC 服务与输出供需要编程式订阅事件流的场景使用。关于规则文件的语法与字段可参考 api-reference.md 中给出的完整规则骨架- rule: name desc: description condition: filter expression output: alert message with fields priority: Emergency|Alert|Critical|Error|Warning|Notice|Informational|Debug tags: [tag1, tag2] enabled: true常用 Falco 过滤器字段字段说明container事件是否来自容器spawned_process是否有新进程被派生proc.name进程名proc.cmdline完整命令行proc.pname父进程名fd.name文件描述符对应的路径container.name容器名container.image.repository容器镜像仓库container.privileged容器是否为特权模式proc.is_exe_upper_layer二进制是否不在原始镜像中逃逸/后投递信号evt.typesyscall 类型setns、unshare、mount 等其中proc.is_exe_upper_layer与evt.type是两条进阶线索前者识别「镜像中本不存在的可执行文件」对应攻击者后投递的 payload后者可用来直接对setns、unshare等逃逸相关系统调用建规则。第五步告警集成与输出路由Falco 本身只负责「检测与输出事件」告警分发交给 Falcosidekick。以下为将事件转发到 Slack 的配置Falcosidekick values.yaml# Falcosidekick values.yaml config: slack: webhookurl: https://hooks.slack.com/services/XXXXX minimumpriority: warning messageformat: | *{{.Priority}}* - {{.Rule}} Container: {{.OutputFields.container_name}} Image: {{.OutputFields.container_image_repository}} Command: {{.OutputFields.proc_cmdline}}结合 api-reference.md 与 workflows.md一个更完整的 Falcosidekick 多路输出配置如下# values-sidekick.yaml config: slack: webhookurl: https://hooks.slack.com/services/XXX/YYY/ZZZ minimumpriority: warning elasticsearch: hostport: https://elasticsearch:9200 index: falco minimumpriority: notice prometheus: enabled: true通过 Helm 升级应用helm upgrade falco falcosecurity/falco -n falco \ -f values-sidekick.yaml同时Falco 事件以 JSON 输出时会携带结构化字段api-reference.md 给出了标准事件样例{ time: 2024-01-15T10:30:00.000Z, rule: Container Escape Binary Execution, priority: Critical, source: syscall, output: Escape binary in container..., output_fields: { user.name: root, proc.cmdline: nsenter -t 1 -m -u -i -n, container.name: attacker-pod }, tags: [container, escape, T1611] }output_fields与tags是下游解析与关联的关键tags 中的 MITRE 技术编号如 T1611可直接用于与威胁情报平台或 ATTCK Navigator 图层做交叉关联。第六步规则验证、测试与模拟逃逸使用 CLI 校验与调试规则api-reference.md 汇总了 Falco 的调试命令族falco --version # 查看版本 falco --validate /path/to/rules.yaml # 校验规则语法 falco -r /etc/falco/rules.d/escape.yaml # 加载指定规则文件 falco --list # 列出所有可用字段 falco --list-events # 列出支持的 syscall 事件仓库中的 agent.py 将上述能力封装成了可编程接口python agent.py --check-status python agent.py --validate-rules /etc/falco/rules.d/escape.yaml python agent.py --parse-alerts /var/log/falco/events.json --min-priority Warning python agent.py --generate-rules escape-rules.yaml其中--parse-alerts按优先级阈值过滤告警并用ESCAPE_RULE_TAGScontainer、escape、T1611、T1610等自动从全量告警中挑出逃逸相关事件输出结构化统计--generate-rules直接打印一条覆盖escape_binaries、Docker socket、cgroup release_agent、内核模块加载、敏感 /proc 路径的完整规则 YAML可作为自定义规则的起点。另一个脚本 process.py 提供了规则生命周期管理子命令python process.py generate # 生成完整逃逸检测规则 python process.py parse-alerts --log-file /var/log/falco/events.json python process.py health # 检查 Falco DaemonSet 各 Pod 状态 python process.py deploy --namespace falco # 以 ConfigMap 形式部署规则到集群deploy子命令会动态生成规则 YAML并以kubectl create configmap falco-escape-rules --dry-runclient -o yaml形式构造 ConfigMap 后kubectl apply随后提示执行kubectl rollout restart daemonset/falco加载新规则——与下述手工流程等价。手工部署自定义规则到 Kubernetesworkflows.md 给出了标准做法# 将自定义规则以 ConfigMap 形式注入 kubectl create configmap falco-escape-rules -n falco \ --from-filecontainer-escape.yaml/path/to/container-escape.yaml # 重启 Falco 加载新规则 kubectl rollout restart daemonset/falco -n falco # 校验规则已加载 kubectl exec -n falco $(kubectl get pod -n falco -l app.kubernetes.io/namefalco -o jsonpath{.items[0].metadata.name}) -- \ falco --list | grep -i escape逃逸模拟测试在测试命名空间中启动临时 Pod 触发告警来源SKILL.md 的 Testing Rules 章节# 模拟读取 /etc/shadow kubectl run test-escape --imagealpine --restartNever -- sh -c cat /etc/shadow # 模拟 nsenter 命名空间逃逸需 hostPID kubectl run test-nsenter --imagealpine --restartNever --overrides{spec:{hostPID:true}} -- nsenter -t 1 -m -u -i -n -- cat /etc/hostname # 查看 Falco 告警 kubectl logs -n falco -l app.kubernetes.io/namefalco --tail50 | grep -i escapeworkflows.md 还补充了两个测试用例# 测试 1特权容器启动 kubectl run escape-test-priv --imagealpine --restartNever \ --overrides{spec:{containers:[{name:test,image:alpine,command:[sleep,30],securityContext:{privileged:true}}]}} kubectl logs -n falco -l app.kubernetes.io/namefalco --tail5 | grep -i privileged kubectl delete pod escape-test-priv # 测试 2敏感文件访问 kubectl run escape-test-shadow --imagealpine --restartNever -- cat /etc/shadow kubectl logs -n falco -l app.kubernetes.io/namefalco --tail5 | grep -i shadow kubectl delete pod escape-test-shadow所有测试完成后务必删除测试 Pod避免留下真实逃逸入口。第七步误报调优与维护使用 exceptions 机制收敛误报对已知合法行为如调试镜像、kubectl-debug 插件可用append: true扩展内置规则并添加例外清单- rule: Terminal shell in container append: true exceptions: - name: known_shell_spawners fields: [container.image.repository] comps: [in] values: - [my-debug-image, kubectl-debug]同样的手法也适用于自定义规则为规则追加append: true的exceptions块指定豁免的镜像、进程或命名空间从而在保留检测能力的同时消除例行运维行为带来的噪声。规则成熟度分层与维护节奏Falco 官方规则按成熟度分级数据来源standards.md级别说明规模参考maturity_stable生产可用、误报率低约 25 条maturity_incubating已被验证有用可能需要调优约 30 条maturity_sandbox实验性误报率较高约 38 条maturity_deprecated计划移除视情况维护建议每周更新规则集falcoctl artifact install falco-rules每个 Falco 版本发布后评审新增的 maturity_stable 规则将 Falco 告警与 Kubernetes audit logs 做关联分析每月开展一次逃逸模拟演练验证规则有效性。第八步告警响应运行手册Runbook告警产生后如何响应直接影响事件处置质量。template.md 提供了一份可直接套用的运行手册框架告警分诊字段Alert Time、Rule Name、Priority、Container Name、Container Image、Pod Name、Namespace、Node、User、Process Command、MITRE Technique。立即行动0-5 分钟在 SIEM/SOAR 中确认告警 → 对照例外清单排除误报 → 定位受影响 Pod 与节点 → 确认容器是否仍在运行。调查5-30 分钟kubectl get pod name -n ns -o yaml导出 Pod 规格 → 审查 security context 是否 privileged → 检查是否挂载宿主路径卷 → 依据 Falco 输出还原进程树 → 检索同一容器/节点的其他告警 → 交叉核对同时间窗的 Kubernetes audit logs。遏制确认攻击后以 deny-all 网络策略隔离 Pod →kubectl cordon node封锁节点 → 采集容器取证数据 → 删除被攻陷 Pod → 检查同节点其他 Pod 是否受损。恢复扫描节点 rootkit → 确认被攻陷则重建节点 → 修补漏洞容器镜像 → 更新网络策略 → 验证后kubectl uncordon node。升级矩阵来源template.md优先级响应时限通知对象CRITICAL立即安全值班 工程负责人WARNING15 分钟安全值班NOTICE1 小时安全团队队列INFO下一个工作日每日站会评审与安全框架和行业标准的对应关系该技能在仓库的框架映射中归属清晰coverage-summary.md 将本类「container-security escape detection skills」映射至T1611Container EscapePrivilege Escalation 战术并与T1610Deploy Container、T1609Container Administration Command、T1525Implant Internal Image、T1068Exploitation for Privilege Escalation同属容器安全技能族。SKILL.md 的 frontmatter 还声明了以下映射MITRE ATTCKT1610、T1611、T1609、T1525、T1068NIST CSF 2.0PR.PS-01、PR.IR-01、ID.AM-08、DE.CM-01D3FENDToken Binding、Execution Isolation、File Metadata Consistency Validation、Restore Access、Application Protocol Command Analysis。standards.md 进一步给出了 ATTCK for Containers 的检测对照表技术 ID名称Falco 检测点T1611Escape to Hostnsenter、mount、chroot 检测T1610Deploy Container特权容器启动检测T1003OS Credential Dumping容器内 /etc/shadow 访问T1005Data from Local System敏感文件读取检测T1059Command and Scripting Interpreter容器内 shell 派生T1068Exploitation for Privilege Escalation内核利用指标以及若干可直接对照的历史逃逸 CVECVE描述Falco 检测规则CVE-2024-21626runc process.cwd 容器逃逸检测利用 /proc/self/fd 访问宿主路径CVE-2022-0492cgroup v1 release_agent 逃逸Write to Cgroup Release AgentCVE-2022-0185文件系统上下文利用检测容器内 unshareCVE-2020-15257containerd-shim API 访问检测抽象 socket 连接CVE-2019-5736runc 覆盖宿主二进制检测对 /proc/self/exe 的写入行业侧NIST SP 800-190容器安全指南第 4.3/5.4 节明确建议在运行时采用 syscall 级监控检测逃逸NSA/CISA Kubernetes 加固指南 v1.2 第 5 节要求启用运行时安全监控、实时检测异常容器行为并监视提权尝试CIS Kubernetes Benchmark 则从配置侧seccomp、SecurityContext、命名空间隔离为逃逸检测提供配套基线。PCI DSS v4.010.6.1 每日日志异常评审、11.5 变更检测机制与 SOC 2 Type IICC7.2、CC7.3可作为合规评审时的对应条款。最佳实践清单以 DaemonSet 形态部署 Falco确保集群所有节点都有检测覆盖优先使用 eBPF 驱动而非内核模块降低驱动安装带来的运维风险先启用官方默认规则maturity_stable再逐步叠加自定义规则避免一上来就被噪声淹没通过 Falcosidekick 将告警转发至 SIEM/SOAR形成闭环为规则标注 MITRE ATTCK 技术编号如 T1611便于告警关联与覆盖度审计先在宽松模式permissive下测试规则确认命中行为后再收紧为阻断策略为已知合法进程维护 exception 清单系统性降低误报通过 Prometheus metrics 端点持续监控 Falco 自身健康防止检测链路静默失效。以上即是从部署、规则编写、告警集成到响应处置的完整容器逃逸检测闭环。相关源码与文档均可在本仓库中进一步查阅SKILL.md技能主文档、api-reference.mdCLI 与字段参考、workflows.md五阶段工作流、standards.md标准与 CVE 映射、agent.py 与 process.py检测与规则管理脚本、template.md响应运行手册。【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI 20 platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考