AI 技能应用安全【免费下载链接】security-audit-skillA coding-agent skill for multi-phase security audits with independently verified, machine-readable findings项目地址https://gitcode.com/GitHub_Trending/se/security-audit-skill点击查看免费下载本指南基于security-audit-skill仓库中的领域猎杀文档 PROTOCOLS-RPC-AND-MESSAGING.md系统讲解如何对 gRPC、GraphQL、Thrift、Protobuf、自定义二进制协议、流式 RPC、Webhook、Broker、队列、Pub/Sub 与事件总线类目标展开安全审计。你将掌握四类攻击面消息分帧与解释分歧、RPC 身份与授权、Broker 隔离、重放/排序/事务的猎杀方法、跨组件对比思路以及将候选证据收敛为confirmed或needs_validation的验证纪律。该技能以六阶段审计工作流为载体本文件作为被选定注入猎手提示词的领域 Companion与 SKILL.md、ATTACK-CLASSES.md、HUNTING.md 共同驱动一次可独立验证、机器可读的安全审计。何时启用本文件识别协议类目标与领域分工PROTOCOLS-RPC-AND-MESSAGING.md的When to use this file段定义了明确的启用条件当目标使用 gRPC、GraphQL 传输层、Capn Proto、Thrift、Protobuf、自定义二进制协议、流式 RPC、Webhook、Broker、队列、Pub/Sub 或事件总线时就应当选择本 Companion。它聚焦四类核心审查对象对等方身份peer identity、消息的逻辑解释logical message interpretation、路由、重放、排序与投递语义。该文件同时明确了与其它领域 Companion 的边界避免审计任务重叠或漏检解析器的内存安全问题交给 MEMORY-SAFETY-AND-BINARY.mdHTTP 层的分帧与身份协议问题交给 WEB-PROTOCOL-AND-AUTH.md消息消费导致的可用性影响如队列容量耗尽、Broker 投递逻辑引发的死锁交给 RESOURCE-EXHAUSTION-AND-AVAILABILITY.md。选择 Companion 不是依据语言或依赖名是否出现而是依据侦察阶段Phase 1发现的信任敏感边界。这一原则在 RECONNAISSANCE.md 中有明确要求Do not select a companion file merely because the language or dependency name appears. Select it because reconnaissance found the trust-sensitive boundary described by itsWhen to use this filesection即只有侦察确认存在由该文档所描述边界的信任敏感点才应选中该文件同时每个可见边界都不能仅仅因为另一个 agent 会审查相关类别就排除。系统拆分建议对于大型系统按以下维度划分审计单元——生产者/消费者配对producer/consumer pair、外部与内部对等角色external/internal peer role、同步 RPC、流式streaming、异步消息路径。这种拆分与 Phase 1 生成确定性覆盖台账coverage-ledger的单元粒度对齐每个入口面 × 信任边界 × 子系统 × 攻击类组合成为独立审计单元。核心纪律必须注入每个该领域猎手提示词的强制文本无论选择哪几条具体攻击类Core discipline段要求将其中的五条纪律逐字复制进每个该领域猎手的提示词在 HUNTING.md 的 Required hunter prompt 中选中的 Companion 的Core discipline、各攻击类小节、Universal moves与Validation rules均需完整注入且不得只发送块名或 Companion 名。原文如下- Internal is not authentication. Name the peer identity at every hop and show how it becomes the application principal used for authorization. - Schema validation proves message shape, not provenance, resource authority, ordering, or safe values. Follow decoded fields to policy and side effects. - Broker guarantees and application guarantees differ. Write down retry, ordering, acknowledgement, deduplication, and transaction behavior before evaluating state changes. - Parser disagreement requires two concrete consumers, schema versions, or wire representations and one security-relevant divergent value. - Use confirmed for source-complete paths plus bounded local producer/consumer tests. Use needs_validation for broker ACL, service-mesh identity, topic attachment, or compatibility behavior outside the repository.这五条纪律对应五类最常见的误判逐一展开内部不等于已认证。internal 只是网络拓扑或代码路径的描述必须逐跳hop指明对等方身份并说明它如何转化为授权使用的应用程序主体application principal。例如 gRPC 中一个请求经过 LB→网关→服务三个跳每一跳的 mTLS 身份与最终授权主体的绑定关系都必须可追踪。Schema 校验只证明消息形状。Protobuf/Thrift 等 schema 校验通过只能说明字段类型合法不能证明消息来源可信、资源权限合理、顺序正确或取值安全。审计必须沿着解码后的字段追踪到策略判断与副作用side effect。Broker 保证 ≠ 应用保证。Kafka 的 at-least-once、RabbitMQ 的 ack 语义、SQS 的 exactly-once 近似保证与业务代码自己实现的幂等、事务边界是两个层面。在评估任何状态变更前必须先写清楚重试、排序、确认ack、去重、事务行为再下结论。解析器分歧必须有双方证据。断言两个解析器对同一消息解释不一致需要给出两个具体的消费者、schema 版本或线上表示wire representation外加一个安全相关的分歧值例如 tenant 字段、权限字段。任何一方的安全拒绝safe rejection都会使该断言无法被确认。证据等级的硬性分界源码路径完整 有界的本地生产者/消费者测试 → 可标记confirmed涉及仓库外的 Broker ACL、服务网格身份、主题挂载或兼容性行为 → 必须标记needs_validation并写明缺失的确切事实。攻击类一消息分帧、Schema 与解释分歧Framing, schema, and interpretation本节由general子代理执行subagent_type: general包含三条攻击类消息边界与规范化分歧Message boundary and canonicalization disagreement不同组件对消息的长度、压缩、重复字段、未知字段、编码、数值宽度、规范化、信封/正文优先级envelope/body precedence的理解不一致。典型场景包括官方生成解析器与自研解析器对同一二进制流切分出不同的字段边界网关对消息做了一次规范化而消费者又做了一次版本转换器version converter在两代 schema 之间转换时丢字段或改默认值。审计动作对比生成解析器与自定义解析器、网关、各语言绑定language bindings与版本转换器解码后确认受影响的主体、资源或操作是否不同。如果没有一个可指认的 principal/resource/operation 在解码后发生分歧就不构成候选。这与 HUNTING.md 中 TEST SAD PATHS AND DISAGREEMENTS 的要求一致只在接口接受的前提下测试缺失、空、零、负、最大、超限、重复、混合编码、陈旧、已撤销、乱序、并发、部分迁移、失败依赖与回滚状态并在每次解析器/策略交接点比较规范化与单位canonicalization and units。联合、枚举与默认值混淆Union, enum, and default confusion未知变体、缺失判别符discriminator、零值、默认权限或兼容性映射最终流入假定已被校验为合法的代码。例如一个 union 字段在旧消费者看来是null而新消费者看来是admin一个 enum 出现 schema 中未定义的序号时某语言绑定抛出异常、另一绑定回落为默认值新增字段被旧消费者忽略但恰好携带安全敏感语义。审计动作审查穷尽分发exhaustive dispatch、默认分支default branch以及旧消费者如何解释新添加的字段——这正是跨版本兼容攻击的温床。信封与载荷身份不匹配Envelope and payload identity mismatch授权逻辑信任看起来可信的路由或信封元数据如 gRPC metadata 中的 tenant header、JWT 的某 claim而处理器实际依据正文body中冲突的 tenant、账户、主题、对象或发送者执行动作。此时必须判断哪个来源是权威的authoritative并确认客户端能否覆盖它override。payload 里的租户文本不是隔离机制——这句在 Broker 章节会再次出现是贯穿始终的原则。攻击类二RPC 身份与授权攻击类RPC identity and authorization包含四条攻击类全部聚焦认证了什么与授权了什么之间的错位拦截器与方法路径不一致Interceptor and method-path inconsistency认证/授权拦截器interceptor覆盖了 unary 方法却遗漏了流式方法streaming、反射服务reflection、健康检查health、网关转码路径gateway-transcoded paths、兼容性服务、或单条流内逐条消息individual stream messages。审计动作把每一处注册registration与路由route与同一个操作逐一比对找出看起来被保护、实际未被保护的方法族。对等身份与应用程序主体混淆Peer identity to application-principal confusionmTLS、工作负载身份workload identity、Bearer 元数据、转发身份forwarded identity或 Broker 凭证只能认证通道channel但如果随后有一个调用者可控的字段caller-controlled field来选择用户或租户就会发生混淆。通道身份与声明的 principal 必须由确定性策略绑定deterministic policy——例如 gRPC 中:authority元数据由客户端填充若服务端拿它决定租户而 mTLS 身份来自不同主体就是典型缺口。逐项与流式授权缺口Per-item and streaming authorization gaps一个流stream、订阅subscription、批量batch或群发bulk消息只被授权一次但后续的每条消息可能指向不同的资源或者订阅在角色、成员资格、令牌撤销之后继续存活。审计动作在作用域scope可能变化的每个点重新做授权检查并把订阅绑定到其原始主体bind subscriptions to their original principal。这也呼应 SKILL.md 的Require a boundary and result原则每个候选都要指明低信任主体、被接受的动作、被跨越的控制、受影响的主体/资源与可观察结果。回调与应答关联混淆Callback and reply-correlation confusion可预测、可复用或跨租户的关联 IDcorrelation ID会让一个响应、Webhook、取消或确认acknowledgement满足另一个调用方的待处理操作。例如回复队列reply queue没有与请求绑定任一消费者都能抢先取走应答。审计动作把每个未决请求outstanding request绑定到已认证的对等方、租户、操作与生命周期。攻击类三Broker 与队列隔离攻击类Broker and queue isolation包含三条攻击类聚焦消息中间件的隔离边界主题、路由键与订阅范围缺口Topic, routing-key, and subscription scope gaps发布者或订阅者可以选定另一租户的主题、通配符wildcard、消费组consumer group、分区、回复队列或死信路由。审计动作在可见处检查 Broker 强制的 ACL同时检查应用侧命名空间构造namespace construction。Payload 内的租户文本不是隔离机制——只有真正受控的命名空间与 ACL 才是。此处的难点在于 Broker ACL 通常不在仓库内因此这类缺口往往以needs_validation上报并写明需要验证的 Broker 名称与规则。死信、重试与诊断泄露Dead-letter, retry, and diagnostic disclosure被路由到死信队列DLQ、错误主题、追踪tracing或运维视图operator views的消息可能包含机密或跨租户载荷而消费这些失败路径的往往是一个低信任消费者。审计动作审查失败路径上的策略与脱敏redaction而不仅审查正常投递路径。不可信生产者被当作控制面Untrusted producer treated as control plane一条消息正文可以自称是管理事件admin event、提供方回调provider callback、复制记录replication record或迁移指令migration instruction却没有独立认证的生产者与事件类型。审计动作在执行特权处理前验证签名以及 source/account/audience 绑定。这类攻击与 ATTACK-CLASSES.md 中的Implicit trust assumptions一致不要把数据来自某个组件当作已验证。攻击类四重放、排序与事务攻击类Replay, ordering, and transaction包含四条攻击类聚焦消息系统的时序与一致性语义重复投递与幂等缺口Duplicate delivery and idempotency gaps重试或重投递redelivery重复执行副作用因为去重缺失、去重发生在变更之后deduplication after mutation、或去重键dedup key跨租户/跨操作冲突。审计动作确认 Broker 的投递模型at-most-once / at-least-once / exactly-once并确认哪个副作用天然不是幂等的如扣款、写文件、发通知。乱序与陈旧消息接受Out-of-order and stale message acceptance较旧的状态、已撤销的成员资格、已取消的工作或升级前pre-step-up的授权在较新状态之后到达并覆盖它。审计动作审查序号/版本检查sequence/version checks、墓碑tombstones、分区变更partition changes以及恢复/重放工作流restore/replay workflows。确认/提交顺序缺陷Acknowledgment/commit ordering defects确认ack发生在持久化提交之前导致安全相关工作丢失或提交发生在不可靠的确认之前导致变更重复。审计动作评估**事务性发件箱/收件箱transactional outbox/inbox**行为与故障恢复。部分多消费者转换Partial multi-consumer transitions多个消费者共同实现一个授权或业务转换但重试与部分失败导致只有子集被提交only a subset committed。审计动作识别哪些不变量必须原子地持久化durable atomically或用当前授权进行补偿compensate with current authorization。这与 ATTACK-CLASSES.md 中 Business logic 的State machine violations / partial failure攻击类呼应步骤 2/3 失败时步骤 1 是否回滚。通用动作消息族链路图与最小夹具Universal moves无论命中上述哪一类攻击三条通用动作都必须执行它们把零散攻击类收敛为可验证的审计路径逐消息族绘制链路图对每个消息族message family画出producer → broker/transport → gateway → consumer → storage在每一跳记录已认证的对等方authenticated peer、权威的租户/资源字段authoritative tenant/resource fields、校验内容与副作用side effect。这条动作与 VALIDATION-AND-REPORTING.md 要求的多步 trace 以entrypoint开头、以sink结尾、中间用propagation的记录结构一一对应。同一最小夹具喂给所有 schema 版本/语言绑定把同一个小的测试夹具small fixture输入仓库内每一个schema 版本或语言绑定测试重复duplicate、缺失missing、未知unknown、边界boundary、重放replayed与乱序reordered消息——且不产生负载without producing load这是 HUNTING.md bounded local evidence原则的落地方式优先使用现有单元测试、最小函数 harness、dummy 租户服务调用、小畸形夹具。横向对比全部路由形态比较正常normal、重试retry、死信dead-letter、重放replay、迁移migration、反射reflection、流式stream与网关转码gateway-transcoded路由——安全策略必须能在传输方式变化后依然成立Security policy must survive transport changes。这直接对应攻击类二拦截器与方法路径不一致。上报前的验证规则从候选到 confirmed / needs_validation在任何发现被上报之前必须执行本文件Validation rules段的五条规则。这是该领域特有的候选门槛candidate gate与 HUNTING.md 的通用门槛以及 report-schema.json 的三分支记录契约相互咬合命名完整参与者链指明现实的生产者或对等方realistic producer or peer、被接受的消息、已认证的通道身份、受影响的主体/资源以及未授权的变更或泄露unauthorized mutation or disclosure。缺少任何一环不构成候选。分歧声明需要双方案据对解析器分歧类声明必须引用两个解析器/消费者与分歧的解码值divergent decoded value。任何一方安全拒绝safe rejection即可阻止确认——即如果任一端会安全地拒绝该消息就没有可利用性。重放/排序声明需要投递保证与本地复现先确立实际的投递保证actual delivery guarantees再用有界的内存/本地传输bounded local/in-memory transport复现不变量失败而不是在生产 Broker 上验证。授权与隔离声明需核对所有可见层核验源码中可见的全部拦截器、Broker ACL、网关与消费者层。外部挂件external attachments使候选降级为needs_validation——这正是 SKILL.md Respect source visibility原则的体现部署控制、代理行为、Broker ACL 等真实控制若不在仓库内既不能假定存在也不能假定缺失。两种终态的判定标准仅在拥有完整消息生命周期 可观察的真实结果时返回confirmed若需要确切指明的 Broker、服务身份、路由或投递事实则返回needs_validation并给出所需的验证计划。这三分支契约在 report-schema.json 中被形式化confirmed记录必须携带root_cause、intended_behavior、trace、evidence、conditions、execution、remediation、severity、confidence且不得携带blockers或validation_planneeds_validation记录必须携带claimed_root_cause、blockers与至少一个非空的validation_plan.local或validation_plan.deployment且不得有严重度——needs_validation表示被源码边界的假设被阻断而非低置信度的 confirmed 漏洞。审计结束后由 validate-findings.cjs 校验这些约束。在六阶段审计工作流中的定位本文件不是独立运行的清单而是被 SKILL.md 六阶段流程按需加载的领域 Companion其生效路径如下Phase 1 侦察RECONNAISSANCE.mdresearch代理识别 RPC/消息/协议入口面Agent 1c 明确把 RPC/message/protocol 列为入口面清单之一父代理据此在覆盖台账的每个单元记录selected_companion_blocks含FILE.md#Core discipline、各攻击类小节、Universal moves、Validation rules并记录被排除的块及排除理由。Phase 2 猎杀HUNTING.mdgeneral猎手接收按顺序编排的提示词——角色序言、architecture.md原文、分配的覆盖 ID、逐字复制的选中块、排除块与理由、核心猎杀方法、核心验证规则、结构化结果契约。本文件的各攻击类小节即在此阶段注入。Phase 3 独立验证VALIDATION-AND-REPORTING.md每个候选交给未参与猎杀的新验证者验证者必须重新阅读每条引用的源码位置并独立复现决定性检查needs_validation只有在独立建立完整路径与有界观察结果后才能晋升为confirmed被源码驳斥的候选则标记rejected。Phase 4–6 结构化输出与报告所有终态记录写入findings.json由 validate-findings.cjs 与 validate-coverage-ledger.cjs 校验最终导出 REPORT.md 等目标中立报告。严重度校准同样适用于本领域SKILL.md 的锚点中high对应完全击败明确安全控制并产生真实后果例如跨租户读写如果无法说明具体损害严重度应低于直觉判断。消息系统审计中最常见的看起来严重实则未证实场景——例如理论上的乱序投递——恰恰是第 3 条验证规则要拦截的对象没有投递保证与本地复现就只能停留在needs_validation。实战要点速查启用判断目标含 gRPC/GraphQL 传输/Capn Proto/Thrift/Protobuf/自定义二进制协议/流式 RPC/Webhook/Broker/队列/Pub/Sub/事件总线 → 选择本 Companion并按 README.md 的安装方式npx skills add ... --skill security-audit随技能一并加载。强制注入Core discipline、选中的攻击类小节、Universal moves、Validation rules必须逐字进入猎手提示词不得只发块名。证据分界仓库内源码完整路径 有界本地生产者/消费者测试 →confirmedBroker ACL、服务网格身份、主题挂载、兼容性行为等仓库外事实 →needs_validation 确切缺失事实 安全验证计划。贯穿原则通道认证 ≠ 应用授权schema 校验 ≠ 来源/权限/排序/取值可信payload 内租户文本 ≠ 隔离安全策略必须在传输形态流式/转码/重试/死信变化后依然成立。赞分享AI 技能应用安全【免费下载链接】security-audit-skillA coding-agent skill for multi-phase security audits with independently verified, machine-readable findings项目地址https://gitcode.com/GitHub_Trending/se/security-audit-skill点击查看免费下载相关推荐供应链与发布安全审计security-audit-skill 的依赖、CI、发布与更新攻击面狩猎指南供应链与发布安全审计security audit skill 的依赖、CI、发布与更新攻击面狩猎指南 导读本文以 SUPPLY CHAIN AND RELEAI 技能应用安全DiemNet 消息协议Messaging Protocol v1深度解析网络消息类型、RPC/DirectSend 语义与 8 MiB 帧定界DiemNet 消息协议Messaging Protocol v1深度解析网络消息类型、RPC/DirectSend 语义与 8 MiB 帧定界 Diem区块链金融科技security-audit-skill HTTP 协议与身份认证安全审计指南从请求分帧到 mTLS 的系统化狩猎方法security audit skill HTTP 协议与身份认证安全审计指南从请求分帧到 mTLS 的系统化狩猎方法 本篇技术指南以 WEB PROTOCOAI 技能应用安全创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考