简单的旧时光……90 年代末作者从大学辍学进入科技行业第一台物理服务器两周内就因 phpMyAdmin 未打补丁被攻破。那时人们牢记要仔细审查依赖项及时更新软件。如今面对供应链安全事件一些包管理器建议特定天数后再更新依赖项。曾经的软件安全规范如今被认为有害不更新会面临活跃攻击更新又可能遭受供应链攻击。过去的运营模式在规模小、简单的科技世界可行那时依赖少数认证供应商可手动审查。但过去二三十年开源软件大规模发展生态系统规模指数级增长暴露出大量新问题如 bind、openssl、log4j 等核心依赖项漏洞冲击互联网。大约 2010 年代中期人们认识到开源软件维护者工作过度、资源不足、能力参差不齐且一些包管理器存在缺陷催生了只重更新表象的文化。行业对“供应链漏洞”反应大多束手无策一些“先锋企业”的繁琐程序也不能解决根本问题。从供应链漏洞到供应链被攻破信任的终结行业自身导致情况恶化与其找供应链漏洞不如攻破开发者账户发布恶意版本。2020 年代中期应用安全主要关注无法信任供应链本身过去 12 个月有 Shai Hulud、Nx s1ngularity 等事件。虽然技术上有能力加固供应链但推广最佳实践进展不佳。例如作者 2014 年领导的 Docker 分发团队的方案遇挫折很多人使用软标签还有人不固定 GitHub actions、盲目合并 Dependabot 拉取请求等。同时第三方依赖项维护者可能陷入网络钓鱼陷阱GitHub 仓库或 CI 管道可能暴露敏感令牌。审判日情况原本相对稳定但过去两年尤其是过去六个月大型企业大量使用编码代理代码生成和合并数量大幅增加传统代码审查防线被突破。一些公司考虑自动化软件开发生命周期机构级 CI 系统状况不佳GitHub 面临扩展性问题。有人试图回到过去但这种做法很难成功。我们应该大声说出来的话人类已无法掌控现代软件供应链安全人类在软件供应链安全方面已失败被大量无用警报淹没很少审查代码、修复上游问题。CVE/NVD 只是问题一部分。僵化的自动更新工具也无法胜任像 Dependabot 那样盲目更新依赖项已失败成为供应链被攻破的首要途径。“最新版本”“软标签”“未固定版本范围”都应被淘汰更新变得危险不更新也不行因为生态系统缺乏长期维护。Dependabot 等工具现在只会带来危害需要新工具取代。依赖项更新应被视为不可信的代码贡献项目收到拉取请求应审查验证但依赖项更新却直接合并这很荒谬。依赖项更新本质上是不可信的代码贡献过去在“依赖项”和“直接代码贡献”间建立的差异是错觉。保守的回归之路是死胡同回到过去不可行AI 带来的开发速度提升无法逆转开发速度会越来越快。开发者必须承担安全责任安全问题不能只交给安全专业人员。“保障” AI 工具安全并非应用安全的下一个前沿领域不良供应商转移目标到 AI 工具安全但根本问题未改变要验证一切且验证范围变大、难度增加。我们正在构建的解决方案Mendral 构建的系统位于 CI 内部将威胁信息、生产事件日志等连接起来配备安全沙箱环境和专用工具。当类似 Dependabot 的拉取请求到来代理会审查新的或更新的依赖项识别拼写仿冒、不良版本和恶意软件。无明显危险信号时会评估依赖项审查级别根据发布时间调整审查级别。审查级别达到阈值时会启动安全沙箱检查包和源代码。对于已知漏洞会评估可利用性和影响范围建议修复措施。每次分支扫描时会审计安全隐患。“但这是 AI你怎么能信任它呢”不能完全信任 AI但 AI 擅长处理机械、重复工作结合现有基础AI 审查员会比“如果 CI 通过就合并”的审查方式更彻底。那么你真的不应该更新吗标题并非吸引眼球在 2005 年的语境下不应再像现在这样更新依赖项不要手动更新、使用 Dependabot 或盲目信任依赖项。依赖项是不可信的代码贡献要全面审查。Mendral 将在下一个平台版本推出相关功能的第一个版本还可更积极主动地处理依赖项问题。聘请你的 AI DevOps 工程师山姆·阿尔巴和安德里亚·卢扎尔迪在 Docker 和 Dagger 工作十年现在为用户打造能自动运行 CI 的工程师有三个始终在线的代理处理故障、提交修复拉取请求和自定义自动化任务。用户可申请提前访问入职后几分钟内可获得首次修复。产品工作原理集成安全状态博客公司关于我们定价职业机会联系我们社交Twitter / X领英法律服务条款隐私政策