我们有一年时间来修复各处的安全问题
大型语言模型的进步正在加剧人们的担忧：自动化工具很快就能大规模发现并利用软件漏洞，把当下已经脆弱的安全态势变成更危险的环境。评论者讨论了传统应对方式——打补丁、内存安全语言和形式化验证——是否还能跟上，还是需要更深层的改变，例如基于微内核的系统、更激进的依赖裁剪、空气隔离的关键基础设施以及更严格的监管。许多人也看到了 AI 强大的防御用途，但认为激励机制、治理以及现实世界的复杂性，使防御不太可能像新的自动化攻击那样快速进步，或被同样广泛地部署。
LLM 作为进攻性安全加速器
- 多位评论者表示，当 LLM 被指向生产代码库时，能在几分钟内发现真实漏洞。
- 担心廉价、未审查的本地模型会让“for 循环攻击”变得可行：扫描 CT 日志、山寨币仓库、电商栈等。
- 担心企业软件和设备中那些鲜有人知的“长尾”漏洞会被大规模利用。
- 有人认为这一年的时间线太宽松；也有人指出，几十年来我们一直处在类似“修复安全的最后机会”的状态。
防御用途及其局限
- LLM 可以帮助进行模糊测试、性质测试、代码审查和形式化证明，但防守方会面临组织阻力：审批、测试、厂商补丁。
- 不对称性：攻击者只需要一次成功的利用；防御者则必须持续管理所有风险。
- 有人建议，一旦 LLM 筛掉了容易捡的“低垂果实”，未来的“基线安全”可能会有所改善。
系统、操作系统模型与攻击面
- 有人强烈主张微内核、能力系统、空气隔离、数据二极管，以及尽量减少受信任代码；Linux/Windows 被视为从根本上过于庞大且基于环境权限。
- 也有人强调对现有系统进行务实加固：纵深防御、沙箱、零信任、应用白名单、严格的网络暴露控制。
Web、CMS 与依赖膨胀
- WordPress、电商平台以及插件/模块常被举为脆弱安全性的例子；许多人推荐静态站点或“headless CMS”方案。
- 反对意见是：非技术用户依赖功能丰富的平台；静态/JAMstack 工具和以 Git 为中心的工作流目前还不能满足他们的需求。
语言、硬件缓解措施与 C/C++
- 许多人支持内存安全语言和诸如内存标记之类的硬件特性；另一些人则认为其采用速度实在太慢。
- 反复出现“不要再写新的 C/C++”与“只要小心，C/C++ 也没问题”的争论；C++ 中的 RAII 受到称赞，但语言复杂性和历史遗留陷阱也受到批评。
监管、激励与风险文化
- 经常有人指出：安全漏洞很少带来严重后果，因此企业优化的是审计和打勾式合规，而不是真正的韧性。
- 有人呼吁强制漏洞报告和责任追究，类似金融审计；也有人指出，要检测并报告所有漏洞在实践上很困难。
更广泛的 AI 与社会风险
- 讨论分支延伸到对 AI 赋能的社会工程、生物风险、恐怖主义，以及“大过滤器”/ASI 场景的担忧，但对这些风险的现实性或紧迫性存在强烈分歧。