生命周期管理图例

转自https://hksanduo.github.io/2021/06/16/2020-12-16-dependency-check/

修复方法

部分外部依赖包可能存在多个漏洞，需综合各个漏洞，为外部依赖包制定整体的修复方案：

• 依赖包对应的多个 CVE 漏洞均有修复建议，需根据每个外部依赖包涉及的 CVE 漏洞修复方法制定修复方案
• 不同依赖包之间可能存在关联依赖关系，建议采用就高不就低原则，综合考虑，形成每个外部依赖包的整体修复建议
• 根据漏洞影响、可利用程度、是否存在简化利用工具进行修复排期，对外提供服务，易遭受攻击的依赖包优先修复
• 从整体技术架构层面考虑，考虑修复的难易程度，为整体技术架构升级做准备

开发团队需根据每个外部依赖包的整体修复建议，采用升级或调整配置等方式，修复外部依赖包的漏洞。在修复时，可参考以下方式：

• 确定各依赖包的作用，确定各依赖包在项目中的使用情况，排查项目之间是否存在交叉引用
• 升级至修复方案提供的建议版本，在测试环境进行功能测试验证
• 查看各依赖包与其他依赖包是否存在依赖关系：如功能独立，则直接升为建议版本；如存在依赖关系，则需要同时升级相关依赖包，并在应用中验证兼容性

客观困难

外部依赖库在升级过程中可能存在以下客观困难：

• 某一依赖包升级（如 spring 相关依赖包），与此依赖包存在依赖关系的其他 jar 包均需同步升级，工作量及影响均特别大
• 依赖包升级后可能存在不兼容、功能不可用问题，除测试其编译是否成功以及基本功能验证之外，对于升级之后对系统带来的影响，还需进行充分的单元测试或系统测试
• 可能有些外部依赖包来源于采购的产品，若需升级依赖包，则需联系产品提供商进行升级。

基于上述困难和问题，开发团队经过验证和评估，对于无法升级到建议版本、升级难度较大或联系产品厂商进行升级存在困难的依赖包，提请安全架构决策，依据漏洞影响面、易受攻击程度等进行综合判断

总结

• 持续构建物料清单为每个应用程序持续构建详细的软件材料清单，从而全面洞察每个应用软件的组件情况。如果存在无法验证来源的开源组件，则不允许使用。
• 强化软件供应链通过强化软件供应链来降低安全风险。这包括检查内部和外部源代码、支持脚本、配置文件和其他工件，并创建可信开源组件的内部存储库。而对外部存储库的使用要合理管理。
• 风险管理通过制定策略确定可接受的开源组件、对在代码中发现漏洞或受限软件许可的合理响应，来管理风险。

建议

• 企业要有清单列表记录哪些产品使用了哪些开源组件。一旦某个开源组件出现漏洞，可以通过清单列表迅速排查。该清单列表也正是 Gartner 提到的材料清单，将在开源组件管控过程中发挥重要的作用。
• 企业要有清单列表记录禁用的开源组件，即，开源组件黑名单。对于那些安全问题比较多、风险较大的第三软件，应加入到这个禁用清单列表中禁止使用。
• 企业对于使用较多的开源组件，建议执行静态代码扫描或其他必要的安全测试，提早识别安全漏洞。对于发现的漏洞，提交开源社区，并促使开源社区修复。
• 对于开源组件的使用要有安全性指导（主要是规避一些因配置不当引入的安全问题）。
• 慎用对安全问题处理态度消极的厂商所开发的开源组件。
• 建立统一的组件库，各项目使用统一的技术架构和组件版本，减少后续版本升级的工作量和对项目的影响，在组件入库时即进行入库评审