主题
安全自动化
在主题维度下，安全自动化主题情报把围绕同一具体议题、信号焦点或监测主题的 BTW.MEDIA 文章串联起来。页面为读者提供更完整的阅读路径，涵盖相关报道、证据来源、市场参与者和基础设施影响，并给出足够背景，帮助理解该主题为何在公司动态、治理决策、区域影响和运营风险中值得关注。读者可以比较反复出现的信号、受影响组织、公开证据、市场背景、服务连续性、采购、竞争、合规和战略规划等问题，而不是只看一份单薄的相关文章列表。页面还会说明该主题涵盖什么、涉及哪些基础设施参与方或政策、有哪些证据支撑报道，以及该主题对运营商、客户、投资者和关注政策的读者为何重要。
案例档案
收据把声明写入账本，却没有替任何人作出信任决定：RFC 9943 与 SCITT
软件供应链里最危险的压缩，往往发生在一张“已验证”的绿色卡片上：有签名，有透明服务，有可核验收据，于是某个制品似乎已经“可信”。RFC 9943 提供的其实是一种更严谨、也更有用的能力：让签名声明及其登记过程可审计。它不裁定声明为真，不保证发行方已披露全部重要信息，不评价透明服务政策是否足够，也不代替依赖方决定是否部署、采购、放行或继续使用制品。
案例档案
令牌说明了芯片，并没有决定门禁：RFC 9783 与 PSA 证明权限
一份签名完好的证明令牌很容易显得像最终结论：nonce 对得上，client ID 看起来正确，里面还有实例、实现、生命周期和软件组件的声明。于是接收系统想把“验证通过”直接翻译成“准入通过”。RFC 9783 提供的恰恰是一条反方向的纪律：它规范 PSA Initial Attestation 产生的受保护证据以及各项声明的含义，却不替依赖该结果的一方作出设备登记、服务访问、工作负载接纳、记录保留或后续操作的决定。
案例档案
联系卡片没有 UID，并不等于没有边界：RFC 9982 与记录身份的权限
一张联系人卡片缺少方便引用的标识符时，系统最容易做的事是补一个。数据库需要主键，同步任务需要锚点，关系图需要可以指向的字符串。RFC 9982 选择了更克制的路径：JSContact 2.0 允许 Card 没有 `uid`；如果源 vCard 没有 `UID`，转换时不得为版本 2.0 虚构 `uid`。这不是放弃数据，而是拒绝把格式便利误写成身份、关系和更新权限。
案例档案
多播请求抵达了群组，却没有授权行动：RFC 10020 与 CoAP 证据边界
一次受保护的多播发送、几条返回消息，常让控制台过早写下“完成”。RFC 10020 的价值恰在于让这种群组通信更可说明、更可保护；它并没有把一个发送地址、一组密钥或若干响应变成对每个设备行动的授权，更没有把它们变成行动已经产生结果的证明。
案例档案
群组密钥到达了设备，却没有决定行动：RFC 10020 与 CoAP 群组权限
一个受保护的消息可以从一个发送方发出，并被一组设备理解；它不能把五个接收方变成一个决策者。RFC 10020 的价值在于，它让受限系统能对群组说话，同时不抹去成员资格、接纳、处理和实际效果各自需要的证据。
IETF
Sean Turner 与那份没有授权证书签发的私钥证明
申请人能用私钥签名，只能说明这把钥匙确实在某个控制面内。申请人是谁、能否使用所填名称、注册机构改了什么、认证机构是否同意签发，仍是四道不能省略的判断。
案例档案
配置模型写下端点，却未启动服务：RFC 10009 与 HTTP 配置权限
HTTP 端点常在真正存在之前就显得已经确定：管理树中有 URI，版本已被允许，TLS 和代理参数已被填入，服务器也有名字。这些都是可审计、可复核的选择。RFC 10009 让它们拥有共同的表达方式；它没有把这份表达变成正在监听的服务、已被验证的对端、成功的请求或获准的业务结果。
案例档案
电话接通了，身份仍须另行成立：RFC 9970 与本地决策边界
电话接通，只说明网络完成了一次连接；它并没有自动回答“接听者是否正是预期对象”“改路是否适合这项业务”或“现在能否披露一段敏感信息”。RFC 9970 把 STIR 的身份材料带到 SIP 的返回路径上，使主叫方能够得到关于已连接一方的可验证证据。它提供证据，却没有把最终判断从本地组织手中拿走。
案例档案
聚合报告究竟知道什么：RFC 9990 与执行前的证据边界
一份 DMARC 聚合报告可以覆盖一段很长的时间，也可以显示很大的计数；它仍然不是完整的邮件历史。RFC 9990 规定的是接收系统如何把自己的聚合观察交给域名所有者，而不是让任何一方凭一行 XML 对发信方作出跨网络的裁决。
案例档案
偏好被发布，不等于 AI 控制：RFC 9969
RFC 9969 记录了 AI 内容偏好如何失去可验证性的讨论。发布者可以表达一个偏好；这不等于某个爬虫已经被识别、某次收集已经遵守、某个模型已排除数据，或任何一方已能证明并补救后续使用。
案例档案
请求 `eap.arpa` 不是一次网络准入：RFC 9965
RFC 9965 让尚无凭据的 EAP 对等端能够以可审计的方式请求一条配置路径。`eap.arpa` 域及其配置标识符只使这个请求可辨识；它不认证对等端、不证明路由、不签发凭据，也不授予通用网络访问。
案例档案
`SSH_MSG_KEX_HYBRID_REPLY` 不是一次用户准入：RFC 10042
RFC 10042 为 SSH 定义 ML-KEM 与经典 ECDH 的混合密钥交换。它规定如何形成和保护一次会话密钥建立的证据；它不替代主机密钥信任、用户认证、访问授权或命令结果。
案例档案
`must` 约束保证配置一致，却不保证一次准入：RFC 9950
RFC 9950 要求：如果系统把 TACACS+ 选为认证方法，就必须配置提供认证服务的服务器。这条 `must` 约束修复的是配置树中的矛盾，不是对可达性、对端可信度、用户准入或权限结果的保证。
案例档案
状态反馈中断会停止测试，却不会给路径下结论：RFC 9946
UDPSTP 会在负载或状态反馈消失时终止一次测量。这是对实验边界的保护，而不是把一次中断解释成路径容量、服务质量或责任归属的结论。
互联网历史
这个比特保住了回程路径，却没有认证请求：RFC 1044 的 HYPERchannel SRC
把 `TO` 与 `FROM` 对调，一条消息便应回到原来的进程。RFC 1044 把这种物理网络的对称性做成可沿途撤销的 SRC 标记。它让接收端知道“回答可以送回哪里”，却没有替接收端回答“是谁在请求”与“是否应当照办”。
案例档案
CMC 已送达，并不代表跨域决定已经成立：RFC 10003
文件、邮件、HTTP 与 TCP 都能承载同一个 CMC 对象。RFC 10003 规范的是这段可验证的传输旅程，而不是任何机构作出证书决定的权力。
案例档案
密钥变得可移植，保管权并没有：RFC 9964、ML-DSA 与 AKP 的边界
RFC 9964 解决的是 ML-DSA 在 JOSE 和 COSE 之间如何表达的问题。它以 Algorithm Key Pair（AKP）给出带算法和公开材料的密钥表示，禁止把私有材料放进公钥表示，又为仅由公开输入计算的密钥指纹规定共同方法。它还作了一个很具体的取舍：私有字段使用 32 字节种子，而不是 FIPS 204 所定义的展开私钥。
案例档案
一项完成的 SCIM 请求并未替跨域作出决定：RFC 9967
当异步 SCIM 请求收到 202，随后又出现带有同一事务值的 Security Event Token，人们很容易把这条轨迹读成一次完整的身份决定。RFC 9967 提供的是更清晰的关联，不是把远端目录的结论直接变成本地域的权限。它让接收方知道应当核对哪一项工作；接收方仍要决定该工作是否对应本地对象、是否符合本地规则、是否应当产生实际效果。
案例档案
遗留代码点抵达了客户端，却没有重新授权服务器：RFC 9963
迁移评审中看到 IANA 新增一个代码点，很容易把它读成“旧算法又被允许了”。RFC 9963 的设计恰恰更窄。它为三种遗留 RSASSA-PKCS1-v1_5 签名分配 TLS 1.3 数值，但这些数值只能在服务器通过 `CertificateRequest` 明确提出后，由客户端用于自己的 `CertificateVerify`。它们不能用于服务器签名，默认应关闭，在注册表中也标为不推荐。这是一座只通向客户端的窄桥，不是对遗留 RSA 的全面放行。
案例档案
反向连接已抵达，设备身份仍待验证：RFC 10011
控制器等到了一个反向连接，往往会让人产生一种过早的确定感：设备应当回连，监听器也正为它打开，于是抵达者似乎自然就是那台设备。RFC 10011 和 RFC 8071 的组合恰好说明了为什么不能这样推论。前者让 RESTCONF 客户端、服务器和 Call Home 的配置关系可以用 YANG 表达；后者规定设备可以先发起 TCP。二者都没有说，一次成功抵达的套接字已经证明设备身份、RESTCONF 会话或变更权限。