开源当道，供应链安全何去何从？

 

人们对于开源安全问题总是抱有一种侥幸心理，只有开源代码出现问题之后，人们才会注意到它自带的安全隐患。在这之中，我们总是复盘已经出现过的某个或某些特定的安全威胁模式，然而当未知的威胁出现时，现有的安全威胁模型并不能很好地解决问题。

 

背景

美国去年发布了一项关于网络安全的行政命令，其中提到要保护软件供应链；此后，白宫召开会议讨论了通过保护开发基础设施和工具以及确定关键开源项目来保护开源软件供应链的方法。消息一出，很多人的第一反应是小题大做。但这次的主要目的是在回应一系列的包括solarwinds攻击在内的网络攻击。

Solarwinds黑客攻击是典型的供应链攻击，在这类攻击面前，程序员们总是会处于被动的状态。Log4j2事件中，在漏洞被披露后，管理员们却只能忙不迭地修补系统。一波刚平一波又起，维护人员刚刚从混乱中找回节奏，又发现Faker.js和Colors.js也出现了问题。

至此，我们无法把这类事件简单归因为个别现象，重视供应链安全刻不容缓。

 

正文

Sonatype的软件供应链状况报告指出：29%的热门开源项目至少包含一个已知漏洞，2020-2021年间针对开源软件供应链的网络攻击增加了650%。最常见的攻击是依赖项混淆和命名空间混淆攻击，其次是误植域名攻击。在这几种情况下，攻击者通常依托于恶意软件包，一旦维护人员不小心下载就会被攻击。 

相对少见的攻击是恶意源注入，但这也是最可怕的攻击。恶意软件会通过黑进开发人员的帐户、篡改工具直接注入开源项目，随之进入下游应用程序中进而影响整个进程。

软件供应链安全问题并不是一个全新的问题，甚至我们还能想到那句如雷贯耳的获奖感言，”你不能相信不是完全自研的代码“。但实际上呢？成千上万的开发人员会不停纠结于自研部分的代码是否出现bug，转过头却毫无负担选择信任其他人的代码。真可谓是“严于律己，宽以待人”。正是这份“无条件的信任”让开源漏洞有机可乘，在我们看不到的角落埋下了一个又一个潜在的风险。

待大家发现漏洞的时候，人们只会对着最终的项目争论不休，试图在自研的代码部分找到问题所在，但真正的罪魁祸首站在大家忽视的开源内容中洋洋得意。使用开源已经成为大家项目进程中必不可少的部分，然而内含漏洞的开源项目对于研发人员而言，就如同沙漠里行舟，怎么走都是错。

 

那要怎样才能解决漏洞呢？

对于项目而言，最大的风险可能来自审核流程最少的小项目，Faker.js和Colors.js就是很好的例子。人们对它们的存在太不重视，却忘记古人早就告诉过我们，“千里之堤，溃于蚁穴”。在供应链攻击中最常见的是误植域名，但反制相对简单，仔细检查拼写即可，甚至还可以检查一个项目被下载的次数。

在与开源漏洞斗智斗勇的过程中，研发人员体现出“魔高一尺，道高一丈”的智慧。最初对于开源项目的检测是人工完成的，但指数增长的项目产出不得不让人们另寻他路。面对超量级的项目群，对开源安全检测的自动化也被提上日程。事实证明，自动化确实是个不错的点子。人工反复监测的结果最后很可能不如在下载软件包之前花十秒钟检查效率高。

目前在生命周期初期阶段检测开源漏洞的技术主要为SCA技术，能够在软件开发过程中对应用程序进行分析，以检测开源组件是否携带已知的漏洞。例如，检测到可用安全补丁的过期库和有法律危险的第三方库或商业软件。

 

SCA做到了保证软件供应链的安全，从而支撑整个软件生命周期的平稳进行。

应用安全检测软件并不能从源头上解决问题，真正需要引起我们注意的是在软件生产过程中对于安全的重要性的充分认识，以及对开源项目的维护和共享。

开发人员和安全人员还需要能够有策略地在问题出现时及时实现修复。简单来说，我们缺少安全的意识和系统的安全维护学习，开发人员普遍缺少关于安全编码的培训。安全人员又很少得到相关内容的系统学习，此外，可能还有超过一半的开发人员并不是学院派出身。

对于应用安全检测技术的发展固然重要，但仅有技术是远远不够的。只有所有人都有意识去做一件事，才能够真正把它做好。我们需要让项目过程中涉及的人员意识到安全在整个进程中的重要性，并且参与到安全维护的过程中。

 

总结

对于目前的研发人员而言，完全不使用开源软件可以说是不切实际。主流市场要求产品快速地更新迭代，开源生态系统的形成完美契合了市场的需求。效率至上的时代中，谁第一个产出谁就能抢占市场先机。在享受快速产出的同时，便捷的第三方组件也带来了较大风险。

目前众多开源项目的维护仍然建立在自愿的基础上，开源生态系统可以参照的正式规则也很有限。如果监管和治理的压力过于沉重，就可能会扼杀开源项目的活力。我们需要适度调整开源项目与自研项目的关系，保持二者的平衡。随着越来越多组织机构朝着更加数字化的敏捷开发迈进，开源项目对软件供应链安全的影响会愈发突出。去其糟粕，取其精华，才能攥紧开源安全的缰绳。

 

相关阅读

欢迎大家入群交流讨论OpenSCA技术

(遇到问题可以添加小镜微信：anpro_xmirror)

 

OpenSCA是悬镜安全旗下源鉴OSS开源威胁管控产品的开源版本，继承了源鉴OSS的多源SCA开源应用安全缺陷检测等核心能力。

OpenSCA用开源的方式做开源风险治理，致力于做软件供应链安全的护航者，守护中国软件供应链安全。

OpenSCA的代码会在GitHub和Gitee持续迭代，欢迎Star和PR，成为我们的开源贡献者，也可提交问题或建议至Issues。我们会参考大家的建议不断完善OpenSCA开源项目，敬请期待更多功能的支持。

 

GitHub：

https://github.com/XmirrorSecurity/OpenSCA-cli/

Gitee：

https://gitee.com/XmirrorSecurity/OpenSCA-cli/

OpenSCA官网：

https://opensca.xmirror.cn/

 

关于悬镜安全

 

悬镜安全，DevSecOps敏捷安全领导者。由北京大学网络安全技术研究团队“XMIRROR”发起创立，致力以AI技术赋能敏捷安全，专注于DevSecOps软件供应链持续威胁一体化检测防御。核心的DevSecOps智适应威胁管理解决方案包括以深度学习技术为核心的威胁建模、开源治理、风险发现、威胁模拟、检测响应等多个维度的自主创新产品及实战攻防对抗为特色的政企安全服务，为金融、能源、泛互联网、IoT、云服务及汽车制造等行业用户提供创新灵活的智适应安全管家解决方案。更多信息请访问悬镜安全官网：www.xmirror.cn