从 Codex Security 到 DMARC，安全正在离开「一次性检查」
从 Codex Security、Claude 密码分析、MCP 无状态协议、DMARC 执行缺口与 eBPF 性能剖析出发，理解安全能力如何从发现问题转向可复核、可续接、可测量的运行链。
先看结论
截至 2026 年 7 月 29 日 08:00（北京时间），Hacker News 当前 front page 上有五条帖子，把安全工作的不同环节放到了同一张图里：Codex Security 负责找、验证和跟踪代码漏洞；Claude Mythos Preview 进入密码算法的搜索空间；MCP 把会话状态从传输层拿掉；DMARC 展示了安全策略为什么常年停在「只报告」；eBPF 则要求每一个内核钩子的性能代价都能被测出来。
它们共同指向的变化很具体：安全产品的价值不再只在于「发现了什么」，还在于结果能否复核，状态能否续接，权限能否说清，修复和迁移是否有路径。AI 把发现问题的速度推高以后，系统没有因此变简单，反而更需要把失败、成本和责任写进运行过程。
热度是抓取时的快照，不代表永久排名。下面的五条是按讨论量、主题关联和可核实材料选出的当前热榜样本，并非 front page 的简单前五名。
| 帖子 | HN 发帖时间（北京时间） | 抓取时热度 |
|---|---|---|
| Codex Security | 7 月 29 日 04:52 | 288 分，62 条评论 1 |
| Discovering Cryptographic Weaknesses with Claude | 7 月 29 日 01:22 | 167 分，100 条评论 2 |
| MCP 2026-07-28 Specification: transport going stateless | 7 月 29 日 02:35 | 95 分，31 条评论 3 |
| DMARC has been public since 2012 but most company domains still don't enforce it | 7 月 28 日 18:20 | 173 分，106 条评论 4 |
| How Do I Profile eBPF Code? | 7 月 28 日 23:55 | 105 分，6 条评论 5 |
五条帖子的 HN 提交者背景在本轮公开材料中都没有得到独立核实。原文作者和项目身份则以各自页面为准。
Codex Security：扫描器的产品边界在运行记录里
HN 提交者 bakigul 的背景未公开。OpenAI 的公开仓库把 Codex Security 定义为 CLI 和 TypeScript SDK，用来发现、验证和修复代码漏洞，也支持扫描仓库、审阅变更、长期跟踪发现结果，以及接入 CI。仓库同时要求 Node.js 22 或更高版本、Python 3.10 或更高版本，并提供 ChatGPT 登录和 API key 两种认证方式。6
这个项目在热榜上最值得看的地方，不是「模型会不会找到一个 bug」，而是它已经把扫描做成了一个持续运行的系统。仓库说明里有历史状态目录；HN 讨论里，参与项目的 Michael 说，独立 CLI/SDK 面向多仓库和长期运行，产品会处理历史结果、去重、误报跟踪、预算控制和 CI 集成。1
评论区很快把这些接口的缺口翻了出来。有人遇到认证错误，追问工具如何确认用户确实拥有目标项目，也有人担心代码是否必须上传到云端。另一位用户实际运行扫描后遇到账号速率限制，花掉约 13 美元，程序提示保留了部分输出，却没有提供明显的续跑方式；项目参与者承认，重试和恢复还需要补上。这里的分歧不是「AI 扫描有没有用」，而是扫描中断以后，谁承担已经发生的成本，结果能不能继续使用。1
这也是安全工具和普通代码助手的分界线。一次性给出漏洞提示，模型能力就足够抢眼；把结果去重、标记误报、限制预算、保存证据、支持重试，才是团队敢把它放进 CI 的理由。安全扫描真正需要被产品化的部分，往往藏在扫描器周围。
Claude Mythos：发现能力变强，验证责任没有消失
HN 提交者 gslin 的背景未公开。Anthropic 在 7 月 28 日的 Frontier Red Team 文章中称，研究人员使用 Claude Mythos Preview 改进了对后量子签名候选 HAWK 的攻击：此前经过两轮、两年人工研究的最佳已知攻击，被模型在约 60 小时内推进，HAWK 的有效密钥强度因此减半。文章还说，模型改进了对七轮 AES-128 的攻击，速度比此前方法快 200 到 800 倍。7
这组数字很容易被标题带偏。Anthropic 明确写出，HAWK 仍只是候选方案，尚未部署；AES 结果针对的是七轮变体，完整 AES-128 有十轮。两项结果都没有要求现有生产系统立刻更换密码算法。每个主要结果的 API 成本约为 10 万美元，研究人员还通过论文、演示代码、同行和政府及行业伙伴的预先沟通来验证和披露发现。7
评论区的反方主要集中在三件事上。有人提醒，七轮 AES 和选择明文模型不等于 AES 已被攻破；也有人指出，HAWK 并未部署，影响应限于标准候选评估。更尖锐的质疑来自研究方法：Anthropic 展示的是成功案例，失败的搜索、重复实验的成功率和人工筛选掉的路径没有同等透明度。另一些评论则认为，模型的价值更像是扩大文献检索和搜索空间，真正的密码学验证仍依赖专家。2
这条帖子给产品团队的提醒很现实：当发现速度快到足以改变算法评估时，验证、复现和披露流程会变成瓶颈。模型可以提出一个攻击，系统必须留下完整的实验条件、成本、代码和适用边界，专家才有机会判断它是突破、误报，还是只对一个简化问题成立。
MCP 无状态：状态没有消失，只是换了地方
HN 提交者 Eldodi 的背景未公开。MCP 官方博客宣布
2026-07-28 版本把协议核心改成无状态的请求/响应模式：请求自带协议版本、客户端身份和能力信息，不再强制使用 initialize / initialized 交换与 Mcp-Session-Id，因此同一个请求可以落到普通轮询负载均衡后的任意实例。新版本还加入多轮请求、基于 HTTP header 的路由、列表结果缓存提示、授权加固和至少十二个月的弃用窗口。8官方文本同时留了一道很重要的口子：协议层无状态，不等于应用层不能有状态。需要延续上下文的工具，可以显式生成句柄，让模型在后续参数中传回。需要用户中途确认或补充参数的场景，则通过
input_required 和多轮请求完成，而不是让服务器一直占住一条双向连接。8评论区一边欢迎服务器不再维护会话，认为这会降低持久连接和共享存储的负担；另一边提醒新协议存在双向线缆不兼容，旧客户端和服务器仍要改造，长期工作流还要重新处理断线、超时和显式句柄。文件传输支持仍被认为是缺口，部分评论则直接质疑 MCP 是否只是给已有 HTTP 能力重新包装了一层。官方维护者的回应也很克制，承认文件输入支持被延期，并说明生态支持会逐步推出。3
无状态改造的工程含义，不是「以后不用管状态」，而是让状态从服务器内存和传输连接里露出来。这样更容易扩容、缓存和路由，也迫使开发者明确哪些状态需要保存、谁拥有它、断线后怎样恢复。对于 agent 工具来说，这种显式化比一条永远在线的连接更容易审计，但迁移期会把账单交给客户端和网关。
DMARC：规则发布了，执行为什么还停在「观察」
HN 提交者 adulion 的背景未公开。原文作者 Chris McCabe 说明，CipherCue 在 2026 年 4 月 14 日至 7 月 28 日之间检查了其跟踪实体集合中的 67,336 个域名。这不是全球企业域名的统计样本，文章也明确提醒了这一点。样本里有 30,362 个域名没有 DMARC 记录，占 45.1%；有记录的域名中，15,709 个仍使用
p=none，只收集报告、不要求隔离或拒收。按该样本的口径，68.4% 的域名没有执行隔离或拒收策略。9p=none 不是无效配置，它是 DMARC 用来观察发信来源的模式。问题在于，观察阶段需要有人读懂每天的聚合报告，逐个确认哪些 IP、供应商和发信系统属于自己，再决定能否升级到 p=quarantine 或 p=reject。文章统计了 36,974 条包含 rua= 的记录，发现报告地址分布在大量难以识别的单次目的地上。把 DNS 记录写进去很容易，辨认系统边界才是持续的工作。9HN 评论把这个问题落到了组织的日常里。有人说明 SPF 和 DKIM 解决的是不同层面的认证，DMARC 负责把发件人对齐和处理策略交给接收方；也有人说小团队没有专人处理报告，只能把配置停在示例值。一位评论者分享了用 LLM 帮忙解析 DMARC 报告、检查 DNS 并复核修改的做法，但另一个评论指出，平台供应商不愿打开 DKIM 选项，也会让域名无法进入严格执行。4
DMARC 和 Codex Security 看似隔得很远，卡住它们的却是同一种东西：安全规则已经存在，组织却没有把状态、责任人和失败后的下一步接起来。没有报告归属、变更验证和持续维护，
p=none 就会从过渡状态变成永久状态。eBPF：安全钩子也要交一份性能账
HN 提交者 snaveen 的背景未公开。原文作者 Naveen Srinivasan 的文章发表于 2026 年 7 月 22 日，7 月 28 日重新进入当前 front page，因此它不是当天新发的文章。文章用一个尽量简单的 C 测试程序测量文件打开操作，在预热缓存、固定 CPU 和丢弃前 10% 样本后，对比没有 eBPF hook 和启用 hook 时的 p50/p99，再用
perf 和火焰图定位内核路径上的开销。作者没有给出一个普遍适用的性能数字，而是把重点放在测量方法上。10这条帖子评论不多，但意见很具体。有人补充应测量 TLB miss，因为 eBPF map 可能污染地址转换缓存；另一位评论者分享了可以沿着 eBPF 源代码和内核调用路径查看耗时的工具。换句话说，单看 hook 自己的指令数并不够，必须把它对内核和宿主应用造成的连带影响一起量出来。5
安全控制一旦挂在文件打开、网络包或授权检查这样的热路径上，它就不再只是策略问题。p99 延迟、页表遍历、缓存污染和 CPU 周期都会变成用户实际承担的成本。能阻止一次攻击，却让正常请求的尾延迟失控的 hook，仍然没有完成生产交付。
五条热帖放在一起，安全产品的竞争面变了
第一，安全能力正在从「发现」延伸到「处理发现」。Codex Security 的扫描器、Claude 的密码分析都可以把问题带到桌面上，但团队还要知道结果由谁确认、怎样复现、花了多少钱、失败后能否接着跑。模型越能做探索，运行记录越不能省。
第二，隐式状态正在变成显式接口。MCP 把会话从传输层移走，要求应用自行表达句柄和恢复方式；DMARC 的
p=none 则反过来说明，状态即使被报告出来，如果没有人认领和处理，透明度也不会自动带来安全性。第三，安全控制必须能被测量。密码分析需要知道攻击模型和适用范围，扫描器需要知道 token 预算和误报率，eBPF hook 需要知道尾延迟和内核副作用。只展示成功结果，无法让使用者估算失败代价。
对开发者工具和基础设施产品，可以把今天这组帖子压缩成四个验收问题：
- 运行中断后，结果、成本和上下文能否恢复，而不是从头再来？
- 一个发现能否关联到原始输入、复现步骤、修复提交和后续状态？
- 协议、认证和权限是否把状态写在调用者看得见的地方？
- 控制措施挂到热路径后，谁测量它的性能代价，谁负责处理异常？
这五条帖子没有证明 AI 已经可以替代安全团队。它们证明的是另一件更麻烦的事：当机器开始更快地搜索漏洞、调用工具和运行检查，安全工作就会从一个结果字段，变成一条必须可观察、可解释、可续接的系统流程。
References
- 1Hacker News：Codex Security
news.ycombinator.com
- 2Hacker News：Discovering Cryptographic Weaknesses with Claude
news.ycombinator.com
- 3Hacker News：MCP 2026-07-28 Specification
news.ycombinator.com
- 4Hacker News：DMARC enforcement gap
news.ycombinator.com
- 5Hacker News：How Do I Profile eBPF Code?
news.ycombinator.com
- 6OpenAI：Codex Security 仓库
github.com
- 7
- 8Model Context Protocol：2026-07-28 规范
blog.modelcontextprotocol.io
- 9CipherCue：DMARC enforcement gap
ciphercue.com
- 10Naveen Srinivasan：How Do I Profile eBPF Code?
naveensrinivasan.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.