问题——遗留代码沉疴难查，新工具“看得更深” 软件与设备长期迭代过程中，大量关键系统仍运行着早期代码和固件。近日，微软Azure首席技术官马克·鲁西诺维奇在社交平台披露，其使用Anthropic推出的新模型Claude Opus 4.6分析自己1986年面向Apple II 6502处理器编写的汇编代码。模型不仅能解释低级控制流与处理器标志位含义，还指出其中存在未检查算术运算进位标志等逻辑错误。业内普遍认为，这类能力意味着一些“以往靠经验、靠运气”的隐患，正在被更系统地暴露出来。 原因——代码生命周期长、维护断档与工具边界叠加 一是“历史包袱”客观存在。许多遗留代码形成于现代语言特性、框架与安全清单尚未普及的年代，开发目标更偏向功能实现与性能压榨，安全性约束相对薄弱。二是维护链条易断。大量程序在商业更迭、人员流动后进入“能跑就不动”的状态，缺少持续审计与补丁投入。三是传统检测手段存在边界。静态分析工具擅长在源代码层面匹配已知模式，但面对汇编、固件、二进制制品以及跨模块逻辑缺陷时，覆盖面与解释能力有限。新一代模型通过“按系统预期功能反推故障模式与攻击路径”的方式，补上了部分空白。 影响——安全增益与攻击扩面并存，行业压力加大 新技术带来的正面效应首先体现在提速增效。Mozilla上表示，对应的团队在短时间内发现的高严重性问题数量，超过以往较长周期的常规报告量，显示大规模自动化分析正成为安全工程的重要增量工具。 但风险同样不容低估。业内人士担忧，当模型能够高效“读懂”数十年前的架构并辅助逆向分析时，攻击者的门槛随之降低，攻击面可能从现有应用扩展至大量仍在运行却缺乏维护的旧程序、旧固件乃至各类微控制器设备。尤其在工业控制、消费电子与物联网场景中，存量设备规模巨大，一旦固件存在脆弱环节，可能带来连锁性安全事件与供应链风险。 同时，模型生成与自动化报告也可能增加维护负担。开源项目维护者反映，缺乏验证的自动化“安全告警”会淹没有效线索，造成精力被分散，甚至影响漏洞响应的优先级判断。 对策——把“新助手”纳入流程，而非替代责任链条 业内共识是：应以工程化方式使用新工具，避免“只靠模型做安全”。一要坚持多工具协同，将模型分析与SpotBugs、CodeQL、Snyk Code等成熟静态分析、模糊测试、动态监测以及人工代码评审结合，形成“发现—验证—修复—回归”的闭环。二要建立报告分级与证据标准，对自动生成的漏洞线索设置可复现条件、影响范围说明与利用链证明，减少噪声输入。三要对遗留系统开展分层治理：对关键基础设施和高价值资产优先清点固件版本与依赖关系，推动可替换设备更新；对难以替换的存量设备，强化隔离、最小权限、补丁窗口管理与监测告警。四要完善责任边界，在企业内部明确研发、运维与安全团队的分工，防止“工具在场、责任缺位”。 前景——旧系统安全将被重新定价，更新替换或加速 可以预见，随着模型能力持续提升，针对遗留代码与二进制制品的分析将更加普遍，企业与机构对“历史遗产”的安全评估会更精细，成本核算也将更真实：继续维持旧系统，可能意味着更高的审计、加固与应急代价；适时替换与升级，反而可能成为性价比更高的选择。与此同时，监管、行业标准与供应链安全要求或将更强化，对固件可更新性、漏洞响应时效、软件物料清单等提出更明确的约束。