基于 Anthropic-Cybersecurity-Skills 检测影子 API 端点流量比对、云配置扫描与治理实战【免费下载链接】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导读影子 APIShadow API是指运行在组织环境中、却未被登记、未纳入文档、也未受到安全管控的 API 端点。它们源于快速迭代的开发周期、被遗忘的测试环境、遗留的旧版本接口、第三方集成或未经治理部署的开发者实验项目常常绕过认证与监控为攻击者留下隐藏的入口。本文以本仓库中的 detecting-shadow-api-endpoints 技能 为骨架完整讲解如何通过流量分析与 OpenAPI 规范比对、云配置扫描、源码仓库挖掘三种方法发现未登记端点并结合仓库内附的 Python 检测器实现与治理策略帮助读者构建一套可落地的影子 API 发现与治理方案。1. 影子 API 是什么为什么危险影子 API 的核心特征是不在文档中。它可能是一个仍在运行的/api/v0/legacy旧接口、一个暴露在公网上的internal/debug调试路由也可能是一个没有加任何鉴权头的测试版本端点。正因为未被纳入资产管理它们往往绕过认证与监控安全团队不知道它的存在WAF、网关策略、SIEM 告警规则自然也不会覆盖它成为隐藏的突破口攻击者通过枚举、历史版本嗅探或供应链情报发现这些端点后可以绕开正式防线直接访问内部功能造成合规缺口未登记的端点可能违反 API 资产管理要求在 NIST CSF 2.0 下对应资产识别ID.RA、数据保护PR.DS与持续监控DE.CM等控制项的缺失。本技能在元数据中声明了其覆盖的威胁面MITRE ATTCK 的 T1190利用面向公网的应用、T1133外部远程服务、T1526云服务发现、T1213应用层信息收集以及 NIST CSF 2.0 的 PR.PS-01、ID.RA-01、PR.DS-10、DE.CM-01 控制项——也就是说影子 API 既是初始访问的入口也是发现/侦察阶段攻击者会主动搜寻的目标。适用场景来自技能文档的 When to Use调查安全事件怀疑存在未登记的 API 端点被利用构建针对该领域的检测规则或威胁狩猎查询SOC 分析师需要结构化的分析流程验证相关攻击技术T1190/T1133/T1526/T1213的监控覆盖是否完整。2. 环境准备与前提条件在开始检测前需要具备以下基础设施对应技能文档的 Prerequisites 部分类别要求网关/反代日志Kong、AWS API Gateway、Envoy 等具备流量日志能力的网关或反向代理流量捕获网络包代理packet broker或端口镜像能力源码与 CI/CD源码仓库及 CI/CD 流水线配置的访问权限云平台访问用于配置扫描的云服务商权限AWS、GCP、AzureAPI 文档清单OpenAPI 规范、Swagger 文档等已登记的 API 文档运行环境Python 3.8用于运行自定义检测工具其中API 文档清单是整个方案的事实基准只有明确知道什么是已登记的才能可靠地判定什么是影子。3. 检测方法一流量分析与规范比对这是最核心、也最直接的检测路径把线上真实流量中出现的端点与 OpenAPI/Swagger 中登记的端点做差集差集即为候选影子端点。仓库在 SKILL.md 中给出了完整的 Python 实现ShadowAPIDetector同时在 scripts/agent.py 中提供了可命令行调用的轻量级版本。两者思路一致本文以完整版为主线讲解并指出命令行版的差异用法。3.1 核心数据结构完整版用DiscoveredEndpoint数据类记录每个被观察端点的特征这些字段正是后续风险评估的输入dataclass class DiscoveredEndpoint: method: str path_pattern: str first_seen: str last_seen: str request_count: int source_ips: Set[str] field(default_factoryset) status_codes: Set[int] field(default_factoryset) has_auth_header: bool False documented: bool False3.2 加载 OpenAPI 规范建立白名单load_openapi_spec()读取 JSON 或 YAML 格式的 OpenAPI 规范遍历paths下每个路径的每个方法仅收录 HTTP 标准方法GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS并把{id}之类的路径参数归一化为{id}以便与流量中的真实路径对齐normalized_path re.sub(r\{[^}]\}, {id}, path)从仓库附带的 api-reference.md 可以看到OpenAPI 3.0 规范的关键字段结构为{ openapi: 3.0.0, paths: { /api/users: { get: { summary: List users }, post: { summary: Create user } }, /api/users/{id}: { get: { summary: Get user by ID } } } }其中paths是 URL 路径到操作operation的映射、servers[].url是 API 基础地址、components.securitySchemes声明认证方式——后两者可以作为后续判定端点是否有认证的规范侧参照。3.3 路径归一化把动态参数变成占位符真实流量中的路径带有动态值必须归一化后才能与规范比对。完整版使用PARAM_PATTERNS表按顺序替换PARAM_PATTERNS [ (re.compile(r/\d), /{id}), (re.compile(r/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}), /{uuid}), (re.compile(r/[a-zA-Z0-9]{20,40}), /{token}), ]对应关系举例/users/123→/users/{id}UUID 形式 →/users/{uuid}长 token 串 →/users/{token}。api-reference.md中补充了更完整的归一化模式包括 MongoDB ObjectId[0-9a-f]{24,}→{id}与 UUID v4[0-9a-f-]{36}→{uuid}命令行版 agent.py 同样实现了这些替换可作为扩展参考。3.4 解析访问日志观察流量侧process_access_log()支持两种日志格式common 格式Apache/Nginx 默认正则r(?Pip[\d.])\s\S\s\S\s\[(?Ptime[^\]])\]\s r(?Pmethod\w)\s(?Ppath\S)\s\S\s(?Pstatus\d)JSON 格式网关/云日志通过字段名兜底取值method/http_method、path/uri、status/status_code、remote_addr/client_ip、timestamp/timestamp并检查authorization/auth_header字段判断是否携带认证头。每条日志行经过过滤只处理/api或/v开头、代表 API 路径的请求、归一化、聚合三步后累计出每个端点的request_count、source_ips、status_codes、has_auth_header。api-reference.md还给出了 Apache/Nginx Combined Log 的字段对应关系可作为手工解析时的参考分组内容1客户端 IP2时间戳3HTTP 方法4请求路径5状态码6响应大小3.5 识别影子端点并评估风险identify_shadow_apis()过滤出documentedFalse的端点并按请求量降序排序活跃的影子优先。随后classify_risk()采用加权评分模型六类证据累加得到 013 的分数证据加分未观察到认证头3请求量 10002请求量 10010001来源 IP 数 10暴露面广2出现 200/201 成功响应端点可用1写操作POST/PUT/DELETE/PATCH2路径命中敏感关键字admin/internal/debug/test/backup/config/health/metrics/graphql/console3总分分级≥8 CRITICAL≥5 HIGH≥3 MEDIUM其余 LOW。注意评分背后是清晰的攻防逻辑has_auth_header只在日志行出现Authorization时置真但这只能证明请求方带了头不能证明服务端做了鉴权校验——因此它适合作为疑似无认证的一级信号真正的确认仍需后续人工验证。3.6 输出报告generate_report()输出结构化 JSON 报告包含扫描时间、登记端点数、观察到的端点总数、影子端点数与影子占比shadow_ratio并为每个影子端点附上方法、路径、风险等级、请求数、唯一来源数、是否带认证头、状态码集合、首次/最后出现时间。main()的调用方式是# 传入 OpenAPI 规范文件支持 .yaml/.yml/.json解析 /var/log/api/access.log python3 shadow_api_detector.py openapi.yaml终端输出摘要并保存完整报告到shadow_api_report.json。风险标记格式[!!!]CRITICAL、[!!]HIGH、[!]MEDIUM、[.]LOW。3.7 命令行版直接可用的 agent.py仓库还提供了开箱即用的命令行工具 scripts/agent.py适合快速验证参数如下python3 agent.py --access-log /var/log/api/access.log \ --openapi-spec openapi.json \ --api-prefix /api \ --min-calls 3 \ --output shadow_report.json--access-log必填Web 访问日志路径--openapi-specOpenAPI/Swagger JSON 规范路径--api-prefixAPI 路径前缀过滤默认/api--min-calls最小调用次数阈值用于过滤偶发噪音默认 1--outputJSON 报告输出路径缺省时直接打印到 stdout。与完整版不同的是agent.py 将影子端点进一步按语义归类debug/admin/internal/deprecated/unknown例如命中debug/test/dev/health归为 debug 类、v1/v0/old/legacy归为 deprecated 类并依据影子端点中成功响应2xx数量给出整体风险等级HIGH ≥ 2、CRITICAL ≥ 5。这种归类对后续治理排期非常有用deprecated类可以直接推动下线debug/admin类则需要立即收敛权限。4. 检测方法二云配置扫描流量分析只能发现有人调用过的端点而云上可能还有大量从未被访问、或者仅被内部 VPC 调用的隐藏资源。云配置扫描负责从配置侧补齐盲区。技能文档给出了针对 AWS 的命令族# AWS: 发现未在文档中的 API Gateway 端点 aws apigateway get-rest-apis --query items[*].[name,id] --output table # 列出每个 API 的所有路由 aws apigatewayv2 get-apis --query Items[*].[Name,ApiId,ProtocolType] --output table # AWS Lambda 函数 URL潜在影子 API aws lambda list-function-url-configs --function-name * 2/dev/null # 查找路由到未登记后端的 ALB 监听规则 aws elbv2 describe-rules --listener-arn $LISTENER_ARN \ --query Rules[*].[Priority,Conditions[0].Values[0],Actions[0].TargetGroupArn]要点解读API Gatewayv1/v2枚举直接列出所有rest-apis与apigatewayv2的 API 与协议类型与公司内部 API 台账比对任何不在台账中的 API 都是影子候选Lambda Function URL这是最容易产生影子 API 的资源——开发者为了快速演示随手开启 Function URL往往没有任何 WAF 或认证前置ALB 规则检查监听器规则背后的 Target Group发现指向未登记后端的转发路径。api-reference.md还给出了从 AWS API Gateway 导出当前部署的 OpenAPI 3.0 规范的命令可以反查规范内有什么aws apigateway get-export \ --rest-api-id abc123 \ --stage-name prod \ --export-type oas30 \ exported-api.json5. 检测方法三源码仓库挖掘第三种途径是代码审计式发现直接从源码中搜索路由定义找出从未出现在文档中的路由。技能文档给出了主流框架的 grep 模式# Express.js 路由 grep -rn app\.\(get\|post\|put\|delete\|patch\) --include*.js --include*.ts src/ # Flask/Django 路由 grep -rn app\.route\|api\.route\|path( --include*.py src/ # Spring Boot 端点 grep -rn \(Get\|Post\|Put\|Delete\|Patch\)Mapping\|RequestMapping --include*.java src/ # 将找到的路由与 OpenAPI 规范做差集 diff (grep -roh /api/[^]* src/ | sort -u) \ (yq .paths | keys[] openapi.yaml | sort -u)最后一条命令把源码中出现的/api/...路径与OpenAPI 规范中的路径做集合差直接输出候选影子端点清单。这套方法的价值在于可以发现尚未上线但已存在的端点提前治理可以发现文档更新滞后于代码的端点deprecated类与流量分析形成互补流量侧看正在被使用代码侧看存在但可能从未暴露。6. 预防与治理API 注册网关策略检测到影子 API 只是第一步关键在于建立治理机制防止增量产生。技能文档给出的方案是在 Kong 网关上强制实施白名单注册制任何未登记的端点直接返回 404并通过日志记录访问尝试。# Kong 插件配置——拒绝未注册路由 plugins: - name: request-validator config: allowed_content_types: - application/json body_schema: null - name: pre-function config: access: - | -- 阻止对未注册端点的请求 local registered kong.cache:get(registered_endpoints) local path kong.request.get_path() local method kong.request.get_method() local key method .. : .. path if not registered[key] then kong.log.warn(Shadow API access attempt: , key) return kong.response.exit(404, {error Endpoint not registered}) end机制解读网关注入一个全局缓存registered_endpoints内容是经过治理流程登记的端点白名单pre-function插件在 access 阶段计算METHOD:PATH键并查表未命中的请求记录告警日志并返回 404对攻击者表现为端点不存在同时为安全团队留下审计线索。在建立注册制的同时建议配套以下治理动作结合文档与仓库映射可推导的实践下线而非隐藏对deprecated/test类端点优先推动真实下线而非仅仅在网关上屏蔽纳入 CMDB/API 台账将影子端点补录进资产管理体系对应 NIST CSF 2.0 的 ID.RA风险识别与 PR.PS平台安全持续监控将网关的Shadow API access attempt日志接入 SIEM形成 DE.CM持续监控闭环上线门禁在 CI/CD 中增加路由与 OpenAPI 规范一致性校验从源头杜绝文档滞后。7. 检测流程闭环从发现到处置综合上述方法可编排出一条完整的处置闭环采集汇总网关访问日志Kong/Envoy/AWS API Gateway、云平台 API 资源清单、源码仓库路由定义比对以 OpenAPI/Swagger 台账为基准运行 SKILL.md 中的ShadowAPIDetector或 scripts/agent.py 生成差集分级按风险评分模型认证缺失、高流量、多来源 IP、写操作、敏感路径输出 CRITICAL/HIGH/MEDIUM/LOW验证对高优端点手工复核——确认是否真实无鉴权、是否指向敏感数据对应 api-reference.md 中 OWASP API Security Top 10 的 API1 Broken Object Level Auth、API2 Broken Authentication、API5 Broken Function Level Auth、API9 Improper Inventory Management处置下线、收敛权限或补录台账按第 6 节的网关白名单策略落地反馈将新发现回填 API 文档更新 MITRE ATTCK 覆盖视图与 NIST CSF 控制项状态形成持续改进。仓库的 mappings/README.md 与 NIST CSF 对齐表 显示api-security子域在 CSF 2.0 下主要对应 ProtectPR.DS、PR.PS职能而影子 API 检测同时覆盖 IdentifyID.RA识别风险与 DetectDE.CM持续监控——这解释了为什么本技能在元数据中同时声明了四个控制项影子 API 治理不是一个孤立的扫描任务而是资产识别、平台加固与持续监控三项安全能力的交汇点。8. 局限性说明为保持技术准确性需要指出以下适用前提与限制均以仓库内容为依据流量分析只能发现实际发生过的请求从未被调用过的影子端点需要靠云配置扫描与源码挖掘补齐has_auth_header判定的是请求方是否携带认证头不能证明服务端执行了鉴权高置信结论需结合手工验证路径归一化依赖预置模式表遇到自定义编码规则如 base64 路径段可能无法正确聚合可参考 api-reference.md 中的模式自行扩展源码挖掘的 grep 模式以 Express/Flask/Spring 为代表其他框架需要适配对应注解/装饰器语法。参考资料仓库内技能主文档Detecting Shadow API EndpointsAPI 参考OpenAPI 结构、日志格式与工具接口命令行实现shadow API 检测 AgentMITRE ATTCK 技能映射OWASP Top 10 2025 技能映射含 API Security 相关条目NIST CSF 2.0 子域对齐表MITRE ATTCK Navigator 覆盖层【免费下载链接】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），仅供参考