诸子笔会 | 孙琦：企业视角下的软件供应链安全

Original 孙琦安在 2022-07-04

自2021年6月起，安在征文全新“改版”——“诸子笔会，打卡征文”。简单来说，我们在诸子云社群招募“志愿者”，组成“笔友群”，自拟每月主题，互相督促彼此激励，完成每月一篇原创，在诸子云知识星球做主题相关每日打卡，同时邀请专业作者群内分享，互通交流。我们的目标，不仅是在持续8个月时间里，赢取累计8.8万的高额奖金，更是要探索一种脑力激荡、知识分享的新思路和新玩法。本期发文，即诸子笔会月度主题来稿之一。

企业视角下的软件供应链安全

文 | 孙琦

孙琦

某上市公司信息安全负责人

负责集团及各业态分子公司的信息安全管理工作。在传统行业、互联网行业深耕多年，先后为多家上市公司成功建立信息安全管理体系及满足法律法规监管要求的信息安全运营能力。

随着企业数字化转型的加速，各种新技术源源不断的在企业内部落地应用，开源软件也已成为软件行业事实上的主流形态。各种容器、微服务、框架、中间件的组合使用，给我们带来了快速交付、快速响应的能力，其组成的软件供应链能力帮助研发人员降低了大量的重复工作量，同时也埋下了潜在的软件供应链安全问题。

数据来源：软件供应链安全白皮书（2021）

从软件工程的角度来说，研发人员关心的是了解需求和产品交付。为了完成快速的交付和迭代，他们会将大量具备类似功能的软件进行抽象聚合工作，形成“原始组件”；然后再将这些“原始组件”按照功能进行组合，形成所谓的“集成组件“；这个时候，产品经理出现了，他们会把这些”集成组件“按照需求方的实际需求进行再次组合，比如某地产公司希望有一套软件能够解决他的购物商场信息化管理需求，产品经理就会去和研发人员沟通，像搭积木似的快速满足需求，最后形成一个软件产品，比如xxx商业管理系统。这个实现过程在以前，我们需要从零开始写代码，可能需要花费6个月才能完成；而如今，充分发挥软件供应链的威力后，可能只需要花费6周就能完成整个项目从提出需求到项目交付的过程。

数据来源：软件供应链安全白皮书（2021）

在软件供应链中，开源代码的数量正快速的增长这，从2015年的36%快速提升至2019年的70%，随着这些开源代码不断集成到我们的各类软件产品中去，我们发现对其进行的日常管理和维护已经成为了一件非常有挑战性的问题。

Kubernetes和Docker的出现改变了传统软件系统的整体交付方式。原本相对较重的基于host的软件部署方式被认为成本太高，缺乏弹性，但他的优点也很明显，部署和后续的维护对象相对单一，成本和复杂程度较低；反观目前大量互联网企业使用的容器编排技术，由于其从镜像构建到平台、运行时的运营都有大量的开源组件可供选择，而这些选择之间的依赖关系以及维护成本往往是被我们低估的。

数据来源：软件供应链安全白皮书（2021）

每一个系统从诞生的那一刻起就带着一个属性，我们叫他“漏洞“。根据Veracode发布的软件安全状况报告中我们可以发现，修复漏洞是一个长期的工作，假设我们的研发人员知道有一个漏洞需要修复的话，他们需要花费1周左右才能修复差不多一半的的漏洞，如果研发人员不知道这个漏洞，这一事件很可能要增长到7个月。这也就意味着我们的软件漏洞在其未被发现前将面长达7个月的风险期，想想这个数据是多么的可怕。

不光是漏洞，软件供应链还附带了另一个重要的问题，那就是知识产权风险。开源软件涉及到的各种开源许可证也可能让一款任何一款软件产品陷入到知识产权官司中去，特别是目前全球化大背景下，我们急需有经验的处理技术风险、法律风险和软件供应链风险的专业人士，帮助企业消除整个软件供应链中的风险。

我们剖析软件供应链风险的现状，“缺乏安全意识”和“拿来就用”是两个非常突出的问题。“棱镜门”事件的曝光让全世界知道了真实的“黑客帝国”存在，无处不在的数字化监控行为让人们惊醒，原来我们生活在一个并不安全的世界。大量研发人员为了快速的交付直接采取“拿来就用”的方法，以效率换取安全的方式向外输出大量的软件系统，一旦这些“拿来就用”的组件中发生任何一个漏洞，都有可能导致使用了该组件的软件系统大规模的发生安全问题，轻则系统运行异常，重则危害国家安全。如果这些研发人员能有一些安全意识，例如主动确认其需要使用的组件是否有安全检测报告、主动进行系统、代码的安全检测等，都能将这些潜在威胁消灭在萌芽阶段。我们必须要接受“是软件就有bug、漏洞”的事实，用积极、务实的态度将其尽快消除，而不是一味追求“快速交付”。

在软件系统处于设计阶段的时候，我们就应该引入安全设计。通过安全意识教育达成安全共识、通过安全设计规避一些“先天性”的功能、设计缺陷，比如将一些credential用hard code的方式写死在代码里、将一些测试验证内容直接带入生产环境。我们通过在这个阶段的“做规矩”来提升安全性，效果远比上线后修修补补要好得多。

软件工程师在进行代码编写的时候，我们需要从其使用的开发工具、编译器等着手，确保这些“硬环境”的安全，他们才可能写出安全的软件系统，试想一下，如果其使用的编译器被中了后门、rootkit等，你的系统很可能就会成为下一个“棱镜门”事件的主角。

系统上线后将交付给业务部门进入日常的运营阶段，在这个过程中我们需要高度注意对于软件版本迭代的工作，因为这个阶段的系统直接暴露在终端用户面，等于是赤裸裸的直面各种攻击，如果前期并未重视安全工作，在这个阶段将非常被动。我们需要主动的收集软件系统在运营阶段的各类数据，通过这些数据去发现潜在的安全问题，同时还要避免在更新迭代过程中被别有用心的人通过中间人等方式进行的诱骗攻击，这个运营的过程将耗费我们大量的精力，但这些都是值得的。

数据来源：软件供应链安全白皮书（2021）

说了这么多，我们来看一下供应链攻击的类型。其整个过程相对简单，但每一个步骤都有精心策划的剧本辅助，从而实现攻击效果最大化的预期。组件自身的恶意预留后门、散播被种马的开发工具、软件更新劫持、源代码污染等等攻击手段，都是我们常见的供应链攻击中的一环。

数据来源：软件供应链安全白皮书（2021）

要解决软件供应链的安全问题，有没有什么产品可以买了就能解决这个问题呢？我的回答是，没有，谁告诉你买了什么产品就能解决这个问题，他就是在忽悠你。面对这个挑战，我们需要做的就是尽量将安全左移，即在软件开发的早期就将安全引入，从本质上让每一个组件安全，这样才可能确保软件供应链的安全。其次，对于软件自身的更新维护也需要做到足够的即时性，对于一个无人维护的组件即使其功能再完美、性能再强大，我也不会去使用它，毕竟没人想背着一颗“定时炸弹”行走。DevSecOps的理念和模式是可以参考借鉴的，但这取决于你的组织，团队的意识和能力达到了，我们就可以借鉴，我个人更建议采用取其精华的方式，在你的团队中进行分拆落地，逐步实现。

写在最后，软件供应链安全问题是一个所有人都会面对的问题，在我看来是一个需要我们所有人一起共建的安全项目，没有人可以置身事外。法律层面，《关键基础设施保护条例》的颁布也为我们提供了有力的支撑，只有把控好每一个组件的安全，我们才可能放心的去享受软件供应链给我们带来的便捷和优实。

推荐阅读

诸子笔会 |11月征文合集《供应链安全》

蔚晨：金融机构供应链安全的分析方法和应对之道张永宏：从供应链安全看企业信息化系统风控刘志诚：从供应链到生态——情景化安全的创新与挑战杨文斌：从第三方引入开始思考供应链安全

诸子笔会 |10月征文合集《安全周》