T3MP3ST 2026 评测：它能取代渗透测试吗？
目前不能。T3MP3ST 是一个值得关注的开源 AI 辅助安全测试框架，适合在授权范围内做侦察、可重复的实验室测试和证据采集。但它不能取代独立渗透测试、人工业务逻辑审查或合规级 assurance。仓库自己也明确说明：headline benchmark 来自 single-agent loop，而端到端多 Agent 协同利用仍未经验证。
我们在 2026 年 7 月 15 日审阅了公开仓库，并把公开证据映射到 OWASP Autonomous Penetration Testing Standard（APTS）的八个治理领域。这是文档审阅，不是正式一致性审计，也不是 hands-on pentest。
希望在独立渗透测试前先加固应用？
规划生产级审查T3MP3ST 是什么？
T3MP3ST 是 TypeScript 编写的编排层。它把 Claude Code、Codex、Hermes 或本地/API 模型连接到安全工具、浏览器 War Room、scope 控制和 evidence ledger。它是 harness，不是自有安全模型。
| 截至 2026-07-15 的公开事实 | 对采购方意味着什么 |
|---|---|
| AGPL-3.0-or-later，package 1.0.0 | 开源，但修改后通过网络提供服务时需要做许可证审查。 |
| 默认 35 个工具，opt-in 后 83 个 | 覆盖面更广，也带来更高治理成本。 |
| War Room、CLI、HTTP API 和一个可用 MCP 工具 | 容易接入，但每个控制面都需要加固。 |
| GitHub 尚无正式 release | 固定并审查 commit；不要把持续变化的 main 当稳定发行版。 |
| 仓库报告 XBEN 黑盒 pass@1 均值 90.1% | 值得研究，但不能证明八 Agent swarm 或你的应用会有同样表现。 |
哪些能力已有证据，哪些仍是实验？
功能文档把侦察和扫描标为已实现，把 Exploiter、Infiltrator、Exfiltrator、Ghost 和 Coordinator 标为实验性。文档还写明，full-chain run 中执行的 exploit 为 0，主要 benchmark 来自单 Agent，而不是八 Operator 协同单元。
| 能力 | 公开证据 | 我们的判断 |
|---|---|---|
| 侦察与扫描 | 真实 tool-backed loop | 适合成为 pilot scope |
| Finding provenance | 工具输出、evidence 引用与 retest | 最强的设计选择之一 |
| Single-agent benchmark | 可重算结果；仓库报告 90.1% XBEN、23/40 Cybench、8/10 CVE-Zero 精确命中 | 应在固定 commit 和自有 test set 上复现 |
| 端到端多 Agent 利用 | 明确标为未 benchmark 且不可靠 | 暂时不要为 swarm 承诺买单 |
Verified Provenance 的原则是对的：模型写出的文字是分析，不是证据。只有工具输出、可复现 artifact 或 retest 支持后，finding 才应从假设升级。
按照 OWASP APTS，T3MP3ST 表现如何？
OWASP APTS 在八个领域定义了 173 项 tier-required 要求。下表中的“未证实”只表示公开材料不足，并不等于控制一定不存在。
| APTS 领域 | 公开信号 | 决策 |
|---|---|---|
| Scope enforcement | Scope receipt、目标绑定 egress 和越界拒绝 | 有潜力；需测试 DNS rebinding、时间窗和云资源 scope |
| Safety controls | 危险工具需要人工批准 | 部分；需证明 kill switch、watchdog、rollback 和 sandbox 完整性 |
| Human oversight | Receipt、approval 和 Operator review | 部分；需测试安全 timeout 与不可逆动作门禁 |
| Graduated autonomy | 概念上有人工与自治模式 | 未映射到 APTS level；首个 pilot 只用 supervised |
| Auditability | Evidence Vault、Finding Ledger、retest、可重算 claim | 最强领域；tamper-evident log 和隔离 audit storage 尚需证明 |
| Manipulation resistance | Scope enforcement 位于模型之外 | 对 prompt injection、恶意目标输出和 runtime 隔离未证实 |
| Supply-chain trust | Lockfile、override 和公开源码 | 部分；没有 release，SBOM、签名和模型变更治理未证实 |
| Reporting | Evidence-backed finding 与 Markdown 报告 | 部分；需验证误报、覆盖披露和独立复现 |
它能取代人工渗透测试吗？
不能。合理定位是补充：在人工 assessment 之间提高授权侦察和证据采集频率。NIST SP 800-115把渗透测试放在有 Rules of Engagement、分析与修复的完整 assessment 流程中。自运行工具无法自行产生“独立性”。
| 需求 | 当前适配度 | 仍需人工负责 |
|---|---|---|
| 隔离 lab/staging 中重复侦察 | 适合试点 | Scope owner 与 evidence reviewer |
| release 之间持续安全信号 | 可能是有用补充 | Triage、修复和回归责任 |
| 业务逻辑与 abuse case | 不能证明可替代 | 产品上下文与对抗判断 |
| 客户、投资人或监管 assurance | 只能提供辅助证据 | 需要时仍要独立 scope 和正式报告 |
安全试点应该怎样做？
- 写清 mission contract：owner、精确 target、允许动作、时间窗、禁止资产、停止条件和数据规则。
- 先用故意脆弱的 lab，再进入隔离 staging：不要把生产环境作为第一次实验。
- 固定 commit 和完整环境：记录模型、Agent、工具、prompt、配置和 target image。
- 全程 supervised，只按证据评分：每个接受的 finding 都要有工具输出、复现路径、严重性依据与 retest。
- 保留独立 pentest：让 T3MP3ST 在外部测试前减少可避免问题，不要让它为自己的工作认证。
“开源且 keyless”的真实成本是什么？
仓库免费不代表结果免费。预算要包括编码 Agent 订阅或 API、隔离环境、外部工具、人工 review、evidence triage、修复和 retest。修改后通过网络给用户使用时，还应审查 AGPL。商业问题不是“是否免费”，而是“每个工程周能否比当前 scanner + review 流程减少更多可验证且可修复的风险”。
常见问题
T3MP3ST 是渗透测试工具吗？
它能替代渗透测试吗？
可以安全地在生产环境运行吗？
Benchmark 是独立验证的吗？
CTO 应该衡量什么？
最终思考
T3MP3ST 值得关注，因为它比多数 AI security 项目更认真地处理 provenance、scope 和可重算 claim。但诚实结论比宣传标题窄：它目前是可信的研究与 supervised-testing harness，不是渗透测试团队的替代品。
把自动化用于可重复的授权侦察和证据采集；把人工保留在上下文、独立性和责任真正重要的环节：业务逻辑、scope、修复判断和最终 assurance。
想在独立渗透测试前减少可避免的 finding？
审查并加固产品