加载失败
这场讨论围绕一篇把网络安全比作 proof of work 的文章展开，核心论点是：如果 LLM 能持续用更大的 token budget 做漏洞扫描、推理和 exploit 链构造，防守方也许必须用类似的算力和 token 先发现并修补问题。评论里提到的 AISI（AI Security Institute，英国政府下属的 AI 安全研究机构）和 Mythos（文中用于展示能力的前沿模型）说明争议来自一份带有 benchmark 性质的分析，而不是单纯的产品发布。很多人把问题放到更大的安全工程背景里看：LLM 既可能增强漏洞发现、decompilation（反编译）和代码审计，也可能放大供应链攻击、软件克隆和合规成本。于是讨论很快从“模型有多强”扩展到“如何设计更简单、可验证、可隔离的系统”。
不少人认为防守方真正的优势在于“全量上下文”：完整源码、git history、文档、PR 和原作者配合，都能让 LLM 做更定向的审计。攻击者往往只有网络入口、未公开 API 或二进制，必须自己重新摸清系统；而防守方可以只盯变更文件和关键安全路径，集中把 token 花在最危险的地方。有人还提到，把代码整理成 source-to-sink trace、可操作 artifact 之后，LLM 更像是在帮团队把零散代码结构化，效率提升可能反而压过攻击者的盲扫。
另一派对文章和 AISI（英国政府下属的 AI Security Institute，AI 安全研究机构）持保留态度，觉得它很像 AI 行业在放大“多买 GPU 就更安全”的叙事。评论里反复质疑 benchmark 的代表性：32-step network intrusion 这种复杂链条任务，不一定能外推到单个代码库或更常见的安全审计场景。也有人指出，所谓“最佳 LLM cyber scanning 只是 bash script”听起来过于粗糙，现实中从入口点追踪执行、构建工具链和 scaffolding 才更像成熟做法。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10]
很多评论把真正的出路指向 formal verification（形式化验证）和更简单的架构，而不是无限制地烧 token 找漏洞。观点是：如果能把关键属性证明出来，或者把系统设计得足够简单、可审计，漏洞空间就会显著缩小，攻击者再多的算力也没法凭空制造缺陷。反对者也承认这很难，因为先定义清楚“系统应该做什么”本身就不容易；但有人认为 LLM 至少可以帮忙补 proof 的琐碎步骤，让工程师把精力放在规范和架构上。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11]
很多人觉得标题并不新鲜：安全一直都是攻防资源竞赛，攻击者只需找到一个弱点，防守者却要补很多洞。PoW 的类比被认为只是把原本就存在的成本差异换成了 token 和 GPU 的语言，本质仍是“谁愿意为结果付更多成本”。不过也有人提醒，真正困难的是修补而不是发现；如果团队没有能力安全打补丁，或者还要面对 social engineering、DDoS 这类更偏攻击方优势的手段，单纯加大探测预算并不能解决问题。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13] [来源14] [来源15] [来源16]
另一条很强的线索是，LLM 在 decompilation、反编译和跨域翻译上已经相当有用。有人分享把 Ghidra 或 IDA 的输出转成可读源码、对混淆 JavaScript 做格式化和追踪、分析 Electron/React Native bytecode 的经验，认为闭源二进制不再是天然防线。由此还引申出更激进的判断：未来复制桌面软件、重写 FOSS 变体、甚至 clone 游戏和功能模块都会更便宜，厂商可能转向 thin client、法律保护或更强的访问限制来应对。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13]
讨论还延伸到现实运维和组织流程：一旦开发者机器被拿下，supply chain attack 可能把整个源码库 exfiltrate 出来，再用自动化扫描快速找权限提升点。于是有人主张把 dev/test 和 prod 彻底隔离、禁用 SSH、给 SRE 准备更受限的第二台设备，甚至靠 air gap 和物理隔离降低风险。也有人担心 trusted software 会变得更贵，外部面向产品和依赖 OSS 的公司都要承担更高安全成本，startup 可能被预算和合规压力挤压。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13]
LLM harness: 围绕 LLM 构建的执行、工具调用和评测脚手架，用来把模型能力接到真实任务里。
formal verification: 用数学规范证明程序满足某些性质的方法，目标是减少或排除特定类型的漏洞。
defense in depth: 纵深防御；用多层、互相独立的防护来避免单点失守。
red teaming: 红队测试；模拟攻击者去主动找系统弱点，用于安全评估和加固。
supply chain attack: 供应链攻击；通过依赖、构建流程或开发者环境间接入侵目标系统。
decompilation / reverse engineering: 反编译/逆向工程；把二进制或混淆代码还原成更可读、可分析的形式。