掌控开源 企业开展软件成分分析工作的思路与实践
作者:星期三, 七月 22, 20200

为了加速业务创新,应用开源技术提升开发效率成为企业的主流选择,但这也导致了日益依赖复杂的软件供应链。虽然有诸多优点,但广泛应用开源组件也带来了新的安全挑战,软件成分分析(SCA)应运而生。

软件成分风险日益加剧

近日,Synopsys 公司发布了《2020 年开源安全和风险分析(OSSRA)报告》。报告显示:2019 年审计的代码库中,有 70% 进行了开源,同比增长10%。但其中 75% 的代码库中包含已知的安全漏洞,49% 的代码库包含高风险漏洞。无独有偶,今年3月安全公司 WhiteSource 发布的《开源年度报告》也指出,2019 年公开披露的开源漏洞为 6100 个,同比增长 50%。

除了安全漏洞外,应用开源组件导致的法律风险也日渐增多。很多企业对于开源协议以及引用规范并不是十分清晰,进而引起各种不必要的争议甚至法律纠纷。如博云在使用开源项目 Apache SkyWalking 时违反了该项目声明的 Apache License Version 2.0 开源协议规定被要求整改。

软件成分分析应运而生

组件问题由来已久,但直到不久前,软件供应链还是国内企业忽略的主题,SCA相关工具市场份额也一直被国外企业长期垄断。

早在2013年版和2017年版的《OWASP Top 10》文档中,就对“使用含有已知漏洞的组件”进行了收录和分析,以提醒安全团队和开发团队注意由组件自带安全漏洞而对应用引入的安全风险。

2019年,Gartner在《应用安全测试(AST)魔力象限》报告中把SCA纳入AST技术领域范围,从而形成了包含SAST、DAST、IAST和SCA的应用软件安全测试技术体系;并正式发布了有关软件成分分析(SCA)的技术洞察报告,对软件成分分析技术进行了准确定义:软件组件分析产品对应用程序进行分析,以检测开源软件组件是否带有已知的安全漏洞或功能漏洞,及需要恰当授权许可的商业软件或第三方产品。它有助于确保企业软件供应链仅包含安全的组件,从而支持安全的应用程序开发和组装。

至此,SCA正式走进国人视野。

软件成分分析应用场景

  • 应用软件安全开发场景

随着行业对软件安全开发越发重视,无论是体系化的SDL或S-SDLC开发流程方法落地,还是DevSecOps思想的实践,都对第三方组件的安全使用提出了更高要求。因此,在软件安全开发过程中,SCA将对开源组件进行资产管理与检测分析,这同时适用于传统Web应用开发和新基建范畴应用系统开发场景。

  • 软件授权许可分析场景

在知识产权保护的影响下,基于不同软件授权许可的软件代码合理使用,正成为新的技术关注点。近年,国内外已先后发生了多起因未对软件授权许可正确理解而使用开源组件引起的法律纠纷案件。SCA可以对不同软件组件的授权许可进行分析,避免潜在的法律风险。

Gartner对SCA未来应用发展提出如下预测:

到 2024 年,软件供应商提供详细、定期更新的软件材料清单(BOM),将是至少一半的企业软件购买者的强制要求;约60% 的企业将自动为它们创建的所有应用程序和服务构建软件材料清单。在 2019 年,这两项数据均不到 5%。

企业如何落地软件成分分析

根据笔者团队近年与企业交流访谈,企业落地SCA通常有以下典型痛点:

  1. 对开源组件管控缺乏统一规划和管理体系;
  2. 搞不清自主研发或外包研发的软件系统使用了哪些开源组件;
  3. 搞不清这些开源组件当前的安全状况;
  4. 没有专人专岗,且理不清与软件开发团队、安全保障团队之间的工作关系。

我们设置了以下实践思路,供大家参考:

  1. 企业要有清单列表记录哪些产品使用了哪些开源组件。一旦某个开源组件出现漏洞,可以通过清单列表迅速排查。该清单列表也正是Gartner提到的材料清单,将在开源组件管控过程中发挥重要的作用。
  2. 企业要有清单列表记录禁用的开源组件,即,开源组件黑名单。对于那些安全问题比较多、风险较大的第三软件,应加入到这个禁用清单列表中禁止使用。
  3. 企业对于使用较多的开源组件,建议执行静态代码扫描或其他必要的安全测试,提早识别安全漏洞。对于发现的漏洞,提交开源社区,并促使开源社区修复。
  4. 对于开源组件的使用要有安全性指导(主要是规避一些因配置不当引入的安全问题)。
  5. 慎用对安全问题处理态度消极的厂商所开发的开源组件。

基于上述思路,我们建议企业在软件安全开发过程中使用自动化的SCA工具,既能有效发挥SCA的作用,又能解决企业的典型痛点。自动化SCA工具的使用有利于:

  1. 从资产管理的角度管理软件开发过程中使用的各类开源组件;
  2. 从风险管理的角度检测和跟踪开源组件的安全态势;
  3. 从团队管理的角度设置专职管理人员角色和其他相关角色;
  4. 从开发流程的角度与开发阶段、测试阶段融合;
  5. 为未来的软件开发知识产权管理提供当前应用软件的全盘情况。

而若能把SCA和SAST、IAST、DAST四种技术在软件安全开发不同阶段有机结合起来,必然有助于企业从多维度保障软件产品安全。

对安全管理者的建议

最后,让我们看看Gartner报告中向负责应用程序安全和数据安全的管理者提出的建议:

  1. 为每个应用程序持续构建详细的软件材料清单,从而全面洞察每个应用软件的组件情况。如果存在无法验证来源的开源组件,则不允许使用。
  2. 通过强化软件供应链来降低安全风险。这包括检查内部和外部源代码、支持脚本、配置文件和其他工件,并创建可信开源组件的内部存储库。而对外部存储库的使用要合理管理。
  3. 通过制定策略确定可接受的开源组件、对在代码中发现漏洞或受限软件许可的合理响应,来管理风险。
  4. 当用评估工具给出特定软件包的整体状况报告以判断软件产品的安全能力时,再多考虑一下安全漏洞和授权许可以外的问题。

结语

在超市中购买的食品,包装上都会表示使用了哪些原料配料,遵循哪些标准,在我们看来习以为常的事情确保了超市食品供应链和每一位顾客的安全。

未来企业在购买软件时,软件供应商也应该向企业提供一个类似的软件组件清单,或者企业软件研发团队将自行输出一份软件组件配料清单。

这样,才能真正利用好开源,掌控开源。

 

申明:本文系厂商投稿收录,所涉观点不代表安全牛立场!


相关文章