揭开政府供应链管道中网络漏洞的真相

本文部分内容曾发表于TechCrunch。本文经更新后在此转载。

‍

仿佛那一年（我们不愿提及的那一年）的动荡还不够多，2021年伊始，美国政府就遭遇了史上最严重的网络攻击之一，引发了巨大震动。SolarWinds事件是一场极具破坏性且手段高明的国家级攻击，导致多个政府部门和大型机构陷入恐慌，纷纷忙于加固终端。几乎所有SolarWinds软件的终端用户都受到了波及，这一事件充分表明，软件供应链中的网络安全与防御至关重要。

网络安全的重要性显而易见，但在供应链背景下，它究竟意味着什么？

普通开发团队的网络安全现状

每天都有海量的软件被开发出来，每年产生的代码行数高达数十亿，且随着我们日益数字化的生活方式所带来的需求，这一数字还在不断增长。全球开发者人数预计到2024年将接近2900万，但目前尚无正式的认证体系来评估和证明他们的安全编码能力。这并不是说每位开发者都会编写或复用不安全的代码，但不可否认的是，基础安全漏洞被引入我们所信任的软件中，从而威胁数据安全的风险始终存在。

开发者的考核标准通常是功能实现速度和代码交付效率。在大多数组织中，安全性并未被纳入绩效评估，但随着越来越多的公司意识到开发者在软件开发初期预防常见安全漏洞的潜力，这种观念正在发生转变。然而，意识到问题与付诸实践是两码事。由于大多数高等教育的开发课程缺乏安全编码的相关背景知识，填补这一空白的重任往往落在了开发者的工作单位身上。如果技能培训和知识共享流于形式或脱离实际，那么效果往往不尽如人意。于是，因技能缺失而导致漏洞频发的恶性循环便难以打破。

当然，解决全球网络安全难题并非普通软件开发者的责任；毕竟，组织高薪聘请专业安全人员是有原因的。然而，安全专家供不应求，开发者完全可以在减轻安全压力方面发挥作用。

那么，对于我们以及那些为关键基础设施和敏感机构开发软件的供应商而言，在预防毁灭性网络攻击方面，我们处于什么位置？至少，这需要改变软件采购的现状。

阻碍安全软件供应链的陷阱

“链条的强度取决于最薄弱的一环”这句老话，在软件供应链中同样适用。即便贵公司拥有强大的安全最佳实践、投入了开发者技能提升，并转向了功能完善的DevSecOps环境（即人人分担软件安全责任），也无济于事；如果你使用了存在安全问题的供应商软件，这些问题就会被引入你的生态系统，并由你承担后果。

诚然，安全团队应协助评估第三方技术栈的安全性，但业务需求往往迫使企业在选择有限的情况下做出决策。此时，这更像是一场信任博弈。供应商是否像贵公司一样重视安全？他们能否像你一样理解资产的风险并进行评估？

透明度是评估供应商软件安全性的关键因素。他们是否公开了自己的安全实践？他们应该以保护数据安全的方法为荣，并将其视为重中之重。如果找不到任何关于安全实践的公开信息，那么很可能安全并未被置于首位。供应商应能回答技术问题，且拥有如ISO27001和SOC2等独立认证会更好。此外，如果你无法“深入底层”进行漏洞扫描，作为内部尽职调查和安全实践的一部分，那么还是算了吧。

在需求驱动下，软件实施节奏极快，尤其是当供应商代码被整合进现有系统以在新的环境下运行时，供应商和买方都需要保持高度警惕，并且双方都应让开发者作为一线力量，在代码发布前识别出常见的安全漏洞和缺陷。如果现有的技术解决方案网络中加入了一个新的组件，可能会导致成百上千个依赖项受到威胁，一个小小的失误就可能引发灾难性的后果。

那么，解决方案是什么？一切从零开始自主开发？如果是1998年，这或许说得通。然而，正如我们不再通过“Ask Jeeves”搜索最近的洗车店一样，我们需要在当今的背景下实施切实可行的保障措施。

虽然没有万能药，但确实有解决之道

对于买方而言，对供应商软件及开发实践进行安全评估，应成为整体安全计划和风险缓解方案的重中之重。务必询问有关其认证、实践以及开发者安全声誉的问题。

供应商（以及任何开发软件的公司）必须准备好证明其将安全置于首位，并应专注于技能提升。具备安全技能的开发者需求量巨大，只要有合适的工具和支持，就可以从现有团队中培养他们，并赋予其抵御常见漏洞攻击的能力。但不要随意进行培训。给他们时间，利用与现有工作流程互补的安全工具来提升能力。尽可能简化流程，你会发现代码中的那些顽固漏洞会逐渐减少。

归根结底，任何软件风险一旦进入供应链，都会被迅速放大，影响所有用户及使用这些脆弱组件的系统。如果供应商不像实施其软件的公司那样重视安全，或者双方在安全计划上都有所欠缺，那么像SolarWinds这样破坏力巨大、影响深远的供应链攻击将不可避免地成为常态——这对每个人来说都是一个严峻的问题。