问题——遗留系统的“隐性风险”正被重新放大。 软件产业长期演进过程中，大量历史代码、冷门架构固件和早期二进制程序仍在现实世界运行：从工业控制、消费电子到各类微控制器设备，不少系统因成本、兼容性或供应链限制，长期处于“能用但很少审”的状态。它们的共同点是语言与架构陈旧、文档缺失、可读性差，导致安全审计门槛高、覆盖率低。此次公开的实验显示，即便是40年前的 Apple II 平台程序，也可能被快速梳理出关键控制流与潜在异常行为，使长期潜伏的缺陷更容易被发现，甚至被利用。 原因——技术门槛下降叠加存量庞大，带来新的安全矛盾。 遗留代码之所以难审，往往是因为需要熟悉特定指令集、调用约定和运行环境。以 6502 汇编为例，对应的人才已不多，人工复盘成本高、周期长。此外，存量系统规模巨大，并大量分布在嵌入式领域：许多设备生命周期长、更新机制薄弱，甚至没有远程升级能力。另一上，自动化分析能力提升，反汇编、结构推断、逻辑检查等环节更容易被工具化；过去依赖“冷门架构”“代码混淆”来提高破解难度的做法，效果正减弱。供需两侧的变化叠加，使“老系统风险”从边缘话题变成必须正视的现实问题。 影响——“发现能力”和“滥用能力”同时增强，攻防节奏可能被改写。 在鲁西诺维奇披露的案例中，模型在理解程序意图后指出一类“静默错误”：当程序未找到目标行号时，可能不会给出明确提示，而是将指针推进到下一行，甚至越过程序末端继续执行。在早期软件环境中，这类问题可能被当作一般缺陷处理；但在安全语境下，它意味着不可预期的执行路径，可能扩大攻击面。更值得关注的是，模型不仅能发现问题，还能给出修复思路，例如在关键分支检查进位标志并进入错误处理逻辑。对行业而言，这带来两点提示：其一，漏洞发现门槛下降，防守方可以更早、更广地定位风险；其二，攻击方同样可能借助自动化手段更快识别弱点，尤其面对无法升级的存量设备，潜在危害更难缓解。 对策——用“全生命周期治理”替代“事后打补丁”，把审计前移、把处置落到实处。 业内人士认为，面对遗留系统与嵌入式固件的安全挑战，仅靠发布后修补远远不够，需要建立更系统的治理框架。 一是建立资产与固件清单，先把底数摸清。对关键行业设备，推动形成可追溯的软件/硬件物料清单与版本管理，明确哪些系统可升级，哪些需要通过外部防护降低风险。 二是把二进制与固件审计纳入常态流程。对缺少源代码或难以复现编译环境的项目，可采用多手段交叉验证：静态分析、模糊测试、仿真与运行时监测结合，提高覆盖率与准确性。 三是对“不可更新设备”实施分层防护。通过网络隔离、最小权限、访问控制、异常检测与补偿性控制等措施，把风险限制在可控范围。 四是推动供应链责任闭环。设备制造商与软件提供方应完善漏洞响应机制，明确支持周期、披露流程与缓解方案，并为高风险场景提供可操作的替代措施。 五是加强自动化安全能力的合规使用与边界管理。分析能力越强，越要明确授权范围、日志留痕与风险评估，避免在无授权环境中扩散为新的安全隐患。 前景——自动化代码审计或将成为行业“基础能力”，安全建设从“可选项”变成“必答题”。 趋势来看，面向多架构、跨年代的软件与固件分析能力会持续提升，安全工作方式可能发生结构性变化：一上，安全审计将更接近工程化流水线，覆盖更多长期被忽视的角落；另一方面，漏洞披露到被利用的时间窗口可能更缩短，对关键基础设施、物联网和工业互联网提出更高要求。未来竞争焦点或不再只是“能不能发现漏洞”，而是“发现后能否快速评估影响、形成可落地的缓解与处置方案”，并将其纳入组织的日常治理。
一段尘封数十年的程序被重新“读懂”——不只是一次有趣的技术实验——也提醒人们：软件安全从来不只属于新系统，历史遗留同样构成现实风险面；面对自动化逆向与漏洞发现能力的加速演进，只有把遗留资产纳入持续治理，把可更新性与安全规范写进交付要求，才能在技术迭代与风险扩散之间建立更稳固的防线。