使用 Claude Mythos Preview 的 30 天： Tenable 如何调整我们的安全计划，以及为何下一个就轮到您的计划

Tenable 用了 30 天时间在自身代码上运行前沿 AI 模型。它不仅能发现缺陷，还能通过可复现的利用程序证明缺陷真实存在。这从根本上改变了代码安全，使其从对潜在代码缺陷进行排序，转变为聚焦于关键发现结果的高价值信号。请继续阅读，了解这如何重塑我们安全团队的工作、所付出的成本，以及为何您的安全方案将是下一个受其影响的对象。

We’ve been running Claude Mythos Preview against our own code now for over 30 days, and one thing is crystal clear: Code security is fundamentally changing, and we believe there’s no turning back.

在 Tenable，我们的安全团队此前就已经拥有能够运行应用程序、测试 API 端点并执行预定义检查的安全测试代理。但直到最近，这些代理仍无法处理代码测试中更具挑战性的部分：发现此前未识别的缺陷并证明其可利用性。作为测试 Anthropic 的 Claude Mythos Preview 以用于 Project Glasswing 的工作的一部分，我们构建了一个智能体代码安全框架，并由这款 Anthropic 前沿 LLM 提供支持，针对锁定提交的代码和服务代码库运行，以确保结果可复现。

<bpt ctype="x-g" equiv-text="[" id="_0">&lt;g id="_0"&gt;</bpt><g id="_0"> 代码安全工作正在改变，但并非如各种炒作博客所言。更不可能是免费的。 我们发现，成本体现在两方面：资金和资深工程师的工时。 以下内容从 Tenable 内部安全团队安全从业者的角度出发，讲述我们如何利用前沿 AI：模型在何处证明了其价值、在何处有所欠缺，以及您在进一步投资前应考虑什么。</g><ept ctype="x-g" equiv-text="]" id="_0">&lt;/g&gt;</ept> 

From ranking guesses to ranking proof with frontier AI

十多年来，安全团队最为匮乏的资源一直是分析师的精力。我们围绕这一点构建了整套学科体系，包括可达性启发式分析、可利用性推测等，一切都是为了确定安全分析师首先应该查看代码中的哪些内容。

现在，运行在 harness 中的前沿 AI 模型改变了这一状况。优先级排序并未消失，而是从基于猜测转向了基于验证证据。当发现结果附带可行的漏洞利用时，您不再需要根据其产生影响的可能性来进行排序，而是根据已证实有效的结果来进行排序。

当 LLM 能够发现可疑缺陷并针对运行中的构建驱动可行的漏洞利用时，难题不再是“在数以千计的静态发现结果中，哪一个最需要人工优先处理？” 问题变为了“哪些代码缺陷是真实存在的，我们能否证实这一点？” 附带可复现概念验证的缺陷会自动完成排序。无法复现的缺陷则会进入验证队列。

这并不意味着缺陷数量会减少。事实上，这意味着会得出更多发现结果，尤其是在早期，因为该模型能够揭示源代码中传统工具绝不可能发现的威胁和风险暴露。相反，前沿 AI 带来的改变在于，提交给人工分析师的几乎所有缺陷都已经过基于证明（而非基于评分）的预先排序。这就形成了一份简短的已可复现事项清单，外加一份 Harness 仍在处理的候选项目暂存列表。

The model gets the headlines; the harness does the work

这并不是说模型并不重要。确实如此，而且非常重要。Claude Mythos Preview 在解读陌生代码和推导代码滥用行为方面的表现比我们之前见过的任何工具都要出色。该框架充当其编排器，引导模型完成从发现漏洞到验证漏洞的全过程。

我们将框架设计为循环运行模式。威胁模型为框架提供上下文信息。它将静态扫描的范围限定在特定代码路径中的特定滥用用例上。它针对运行中的构建版本实施有针对性的漏洞利用验证。它会反馈结果，以确认可利用性或排除误报。这种实时利用步骤是我们迄今为止推动动态测试“左移”最远的一步。这意味着模型不会去猜测注入攻击是否生效；它会针对真实目标发起攻击，并主动读取返回的内容。

Here’s the part that should decide where you spend your engineering time. The model underneath will change: a better one ships, pricing changes, a provider sunsets the endpoint you built against. If your program is a pile of clever prompts wired to one model, then every single one will require its own migration. But if your program is a harness that treats the model as an interchangeable component, then replacing it with any new or updated version of the model amounts to a simple config change and an afternoon of re-benchmarking. 

<bpt ctype="x-g" equiv-text="[" id="_0">&lt;g id="_0"&gt;</bpt><g id="_0"> 现在，测试框架成为了安全团队的资产。模型则变成了消耗品。</g><ept ctype="x-g" equiv-text="]" id="_0">&lt;/g&gt;</ept>

Blindly pointing coding agents at repos doesn’t work

<bpt ctype="x-g" equiv-text="[" id="_0">&lt;g id="_0"&gt;</bpt><g id="_0">每个刚开始探索的团队都会提出相同的问题： “我们已经有了代码 Agent。 “难道不能直接让它扫描我们的代码并查找漏洞吗？” 在开发任何工具之前，我们确实进行了这项尝试。 这是成本最低的实验，如果不做就太尴尬了。 但这种做法站不住脚，其原因是结构性的。 仅仅优化提示词于事无补。</g><ept ctype="x-g" equiv-text="]" id="_0">&lt;/g&gt;</ept>

<bpt ctype="x-g" equiv-text="[" id="_0">&lt;g id="_0"&gt;</bpt><g id="_0"> 标准的编码 Agent 旨在进行线性探查，自始至终遵循单一假设。有效的代码安全则需要采取截然相反的做法。 这是一项广泛且横向的工作，涉及管理多个并发假设，而其中大部分最终都不可避免地会被推翻。 如果将智能代理指向复杂的服务，它在解析架构时就会耗尽上下文窗口，几乎无法为实际的漏洞搜寻留出容量。</g><ept ctype="x-g" equiv-text="]" id="_0">&lt;/g&gt;</ept>

The harness earns its keep on three problems the model can’t solve alone: 

• State: so a run that dies at hour six resumes instead of restarting, with the system remembering which paths it already cleared
• Parallelism with focus: so fifty narrow hunters each chew one attack class against one component and nobody drowns in context. 
• 跨代码库推理： 存在漏洞的代码和触发该漏洞的入口点通常分别位于不同的服务中。缺陷位于服务 A，而可达且受攻击者控制的入口点只能在三个上游服务中找到。没有任何单个代码库会话能同时看到这两者，但正是这种关联，往往区分了普通的发现与真正可被利用的缺陷。

These are orchestration problems, and a prompt, however good, is not an orchestrator.

Where frontier AI excels: low-severity noise, chained into real attacks

<bpt ctype="x-g" equiv-text="[" id="_0">&lt;g id="_0"&gt;</bpt><g id="_0"> 该模型能够获取本身单独来看仅属于低严重性杂音的原语，并将它们拼接成一个具有实质影响的漏洞利用。这正是过去将资深研究人员与代码安全工具区分开的工作，而当每个问题被单独归类为“低”严重性时，这类工作恰恰会在积压任务中尘封。 亲眼看到前沿模型将这些问题串联成一个经证实的写入原语时，这一刻前沿模型不再给人一种仅仅是更好的 SAST 工具的感觉，而是让人感觉它像是一位不知疲倦、永不厌倦的安全研究员。</g><ept ctype="x-g" equiv-text="]" id="_0">&lt;/g&gt;</ept>

<bpt ctype="x-g" equiv-text="[" id="_0">&lt;g id="_0"&gt;</bpt><g id="_0"> 前沿模型也更倾向于运行代码，而非仅在理论上进行推导。只要向其提供可疑缺陷，它就会编写触发输入、在临时环境中编译、运行、读取崩溃信息，然后再次迭代。 这种闭环缩小了“这看起来可利用”与“这是进行利用的输入”之间的差距。</g><ept ctype="x-g" equiv-text="]" id="_0">  &lt;/g&gt;</ept>  

Where the human is non-negotiable

下游的一切均由威胁模型驱动。威胁模型必须来自全面深入了解系统的人员。如果给前沿 AI 模型提供空白的威胁模型，它就会以极快速度生成看似合理实则错误的输出。提供精准的威胁模型，它就能返回您的团队当天即可采取行动的发现结果。 输入的是垃圾，输出的是代价高昂的噪音，而这种噪音之所以高昂，恰恰是因为它的可读性极高。

同一位研究人员阅读模型发现的问题，决定哪些值得转化为可行的漏洞利用，对返回的结果进行分类，并将经验教训融入威胁模型中，使下一次检测更加高效。威胁模型并非一劳永逸撰写完成的静态文档。它是整个智能体 SDLC 循环持续运转的动态状态。

该研究人员必须是最资深的人员，而不是最空闲的人员。以往投入手动测试的技能，现在转向了威胁建模和审查工作。这改变了专家日常的工作方式，相当于为他们配备了一位速度极快、严格照章办事的助手，协助完成界定好的工作内容。

From proof to action: the gates before a human analyst

在移交人工处理之前，每个候选发现结果都必须通过同一道门槛： 是否存在可复现的概念验证？ 如果没有，则进入验证队列。如果有，我们就会对照一份与企业实际关注事项相匹配的简短问题清单进行核对：

• Reachable: 如果无法从不受信任且暴露的入口点触发该问题，那么它只是积压工作项，而不是实时风险。
• Automatable: 可靠、门槛低且可重复的漏洞利用可以优先处理；而需要定制调整的漏洞利用则需等待下一次计划发布。
• 影响： 部分影响或拒绝服务（DoS）攻击属于一个层级；完全控制、任意写入或远程代码执行（RCE）则属于另一个层级。
• Crown jewels: 如果涉及关键资产或跨越信任边界，重大工单就会转变为紧急带外补丁。

Figure 1: 智能体发现结果分选

Budget for two things: compute and senior expertise

工作方式正在发生变化，但并非毫无代价，其开销体现在两种不同的维度上。明面上的标价虽然是最引人瞩目的成本，但真正起约束作用的其实是资深工程专业技能；切勿因 Token 账单而忽视了使其正常运行所需的专家工时。

The compute bill, measured

计算成本是真实存在的，而且这一次可以精确衡量，无需靠猜测。以下是一名工程师整整一个月的用量： 2026 年 6 月，在 37 个不同的代码仓库中进行了 71 次 harness 运行，价格按 Mythos 定价费率 计算。传输了约 101 亿个 Token，总计约为 41,718 美元。

June 2026 — 71 runs, 37 services, Claude Mythos 5 list price

5-min cache writes 1.99B tok @ $12.50/MTok = $24,839 (60%)

cache reads 7.77B tok @ $1.00/MTok = $ 7,774 (19%)

output 0.15B tok @ $50.00/MTok = $ 7,266 (17%)

base input 0.18B tok @ $10.00/MTok = $ 1,839 (04%)

total ≈ $41,718

<bpt ctype="x-g" equiv-text="[" id="_0">&lt;g id="_0"&gt;</bpt><g id="_0"> 缓存写入费用占账单总额的 60%。在漫长代理会话的每轮对话中，都会向上下文添加更多内容：文件内容、工具输出，以及模型刚刚进行的任何推理。 并且，在读取这些新增内容之前，每一项都会以 1.25 倍的输入价格写入缓存。 读取费用便宜，写入则不然；如果测试框架允许其工作集不断扩大，最终几乎每轮对话都要支付这笔溢价。 单次运行的费用差距与总费用同样重要。 单次运行的费用中位数约为 47 美元。 平均费用为 588 美元。 最昂贵的一次单次运行成本刚刚超过 9,000 美元。 对大型服务进行的几次深层次、大范围全面扫描占了大部分 Token 支出。</g><ept ctype="x-g" equiv-text="]" id="_0">&lt;/g&gt;</ept>

Why one run isn’t enough

<bpt ctype="x-g" equiv-text="[" id="_0">&lt;g id="_0"&gt;</bpt><g id="_0">此外，还有一项更微妙的成本需要考量： AI 模型具有非确定性。 如果针对同一 commit 两次运行相同的 harness，将得到两组不同的发现结果。 一次扫描遗漏的内容可能会在下一次扫描中显现出来。 在我们的研究中，每次扫描发现的新问题数量均为上一次运行的一半。 如果首次运行发现了半数的缺陷，第二次运行将能找出四分之三，而第三次运行则能找出近八分之七。 在此之后，收益微乎其微，不足以证明继续消耗 Token 的合理性，这正是我们运行三次的原因。 对于任何注重覆盖率的服务，请规划三次运行的预算，而非仅一次。</g><ept ctype="x-g" equiv-text="]" id="_0">&lt;/g&gt;</ept> 

The formula, if you want to recompute against your own telemetry:

cost = 10·(input/1e6) + 12.5·(cache_write_5m/1e6) + 20·(cache_write_1h/1e6)

+ 1·(cache_read/1e6) + 50·(output/1e6)

<bpt ctype="x-g" equiv-text="[" id="_0">&lt;g id="_0"&gt;</bpt><g id="_0"> 这也明确了何时应该运行。对某些服务而言，这是定期全面扫描，而非每次提交时的卡口检查。 在整个集群中定期运行，并在服务的攻击面发生显著变化后再次运行。</g><ept ctype="x-g" equiv-text="]" id="_0">&lt;/g&gt;</ept> 

The expert you can’t skip

<bpt ctype="x-g" equiv-text="[" id="_0">&lt;g id="_0"&gt;</bpt><g id="_0"> 第二项真正起约束作用的成本是：资深专业知识。上述列出的所有计算成本都取决于是否拥有能够编写真实威胁模型并对真实发现进行评估分类的研究人员。 这类人才十分匮乏，而测试框架并不能让他们变得可有可无。 它能让一名研究人员完成五个人的工作，这是一个截然不同且更好的局面。 关于 ROI 令人不安的真相： 使用此工具需要付出成本，如果只购买 Token 而不为专家提供资金支持，您只是创建了一种能够极快生成无人可据以采取行动的发现结果的方法。 编制 Token 预算。 配备专家人员。

Only verify the facts that matter

运行 30 天后：在受控框架中运行的前沿模型极大改变了我们的工作形态，而不仅是提升速度。它并没有取代专家，而是改变了工作本身。它将分析人员从单纯的测试工作中解放出来，转向范围界定和判断评估。 这让安全方案不再停留在对推测进行排序，而是转向验证并处理已证实的问题。

补丁修复速度从来不是核心约束条件，单方面追求这一速度只会让情况恶化。跳过回归测试并在两小时内发布的修复程序，恰恰会让一个漏洞演变成两个漏洞。在将补丁速度纳入考量之前，harness 为您提供了更好的选择：在消除噪音的同时，确保已证实问题的确定性。了解一下我们的发现结果漏斗模型：

• Far more raw candidates than a human pass can produce
• A large fraction of them killed in validation
• The repeats removed via deduplication
• What survives lands with a proof, handed directly to an engineer

We don’t know whether these proven findings represent most of the real bugs in the code, but the efficient noise elimination with this funnel and knowing what’s left is real and verifiable are worth a lot. 

凭借这些效率提升，您可以重新分配有限的变更管理预算，从而彻底解决并缓解遗留的已证实问题带来的风险。在应用程序前部署控制措施，从根本上防止漏洞被触及。隔离各个组件，避免单点受损导致整个系统瘫痪。一次性将修复程序推送到整个集群，避免在修复第十台主机时其他九台仍处于暴露状态。

harness 能让您更快了解情况。如何运用这些知识，依然取决于您自己。

Where to start, if you’re starting

Take one service your best person knows cold, and build the first loop around it:

• Write the threat model by hand. 这一输入决定了后续的一切，因此它应当出自经验最丰富的人员之手，而非手头最空闲的人员。
• Run against a pinned commit so the results can be reproduced.
• Route the output through a triage tree that ends in real tickets, then watch your own funnel and tune sweep depth to your risk.

And three things not to do:

• Don’t start with the whole fleet.
• Don’t start with your crown-jewels service.
• Don’t start by letting the frontier model write fixes.

The guesswork you’ve been fighting mostly dissolves once you have proof, but only if you’ve built the harness that makes the proof worth trusting.

了解详情

• Claude Mythos Preview: 为应对董事会提出的网络安全问题做好准备
• Five steps to become Mythos-ready