开源依赖包有风险吗？

本文目录导读：

1. 开源依赖包的主要风险类型
2. 如何管理和降低这些风险？

是的,开源依赖包存在风险，而且这是现代软件开发中一个非常现实且重要的问题。

开源本身不是风险，但引入未经审查的开源依赖会引入风险。 就像建造房子，使用免费、公开的砖头（开源代码）是高效的，但如果这些砖头有裂缝、内部藏有白蚁或者来源不明，整个房子的安全性和稳定性就会受到威胁。

下面来拆解一下这些风险具体有哪些,以及如何应对。

开源依赖包的主要风险类型

可以将风险大致分为以下四类：

安全漏洞风险（最常见、最直接的威胁）

• 已知漏洞： 依赖包本身可能存在已知的、尚未修复或未及时修复的安全漏洞，攻击者会利用这些漏洞攻击使用了该包的系统，著名的 Log4j 漏洞（CVE-2021-44228）就是一个典型案例，影响了全球无数Java应用。
• 供应链攻击： 这是近年来增长最快、危害最大的风险，攻击者通过以下方式入侵：
  • 投毒： 上传看似有用但包含恶意代码的包到公共仓库（如npm, PyPI, Maven Central）。
  • 劫持： 攻陷已存在的、流行的开源包的维护者账户，然后发布包含恶意代码的更新版本。
  • 依赖混淆： 利用公司内部使用的私有包名，在公共仓库上传同名但恶意的包，当构建系统优先从公共库拉取时，就会引入恶意代码。
• 传递性依赖（Transitive Dependencies）风险： 你的项目直接依赖一个包A，而A又依赖包B、C、D，即使你仔细审查了A，但B或C中的一个微小漏洞，同样会通过A威胁到你的整个系统，这就是所谓的 依赖地狱。

许可证合规风险（法律和商业风险）

• 开源项目有多种许可证（如MIT, Apache 2.0, GPL, AGPL），一些许可证（如GPL, AGPL）是 “具有传染性”的，即如果你的软件使用了此类许可证的包，你的整个软件可能也需要以相同许可证开源并免费分发。
• 在商业闭源软件中,无意中引入了一个强传染性许可证的依赖，可能导致法律纠纷或被迫公开核心代码，造成巨大的商业损失。

质量与维护风险（稳定性和长期风险）

• 维护不活跃： 依赖包可能因为作者失去兴趣、时间不足或其他原因而停止更新，不修复Bug、不响应安全漏洞、不兼容新环境。
• 质量低下： 代码本身可能充满Bug、性能低下、缺乏测试、设计糟糕，这会将不稳定性引入你的项目。
• 版本冲突： 同一个传递依赖需要多个不兼容版本，导致构建失败或运行时异常。

恶意行为与后门风险（故意破坏）

• 除了供应链攻击外,一些包可能看起来是合法的库，但其功能中包含了隐藏的后门、信息窃取器（如窃取环境变量、SSH密钥、数据库密码）、或挖矿脚本。
• 破坏性恶意包： 专门设计用来删除文件、破坏系统或加密数据以进行勒索。

如何管理和降低这些风险？

不能因噎废食,完全不用开源包，有效的管理策略是关键。

1. 选择可信赖的依赖：

   • 检查流行度和活跃度： 在GitHub / PyPI / npm 等平台检查包的下载量、Star数、最近更新时间、Issue和PR的响应情况。
   • 检查维护团队： 了解项目背后是谁，多人维护、有组织支持（如Apache、CNCF基金会）的包通常更可靠。
   • 审查代码（如果可以）： 对于关键依赖，花时间快速浏览其核心代码，了解其依赖关系。

2. 使用软件组成分析（SCA）工具（强烈推荐）：

   • 这是最核心的防御手段,SCA工具可以自动化地：
     • 识别所有依赖（包括传递性依赖）和它们的许可证。
     • 将已知漏洞（CVE）与你的依赖进行匹配，并给出风险等级和修复建议。
   • 常见工具：
     • 商业工具： Snyk, Sonatype Nexus Lifecycle, WhiteSource (Mend), Black Duck。
     • 免费/开源工具：
       • GitHub Dependabot： 集成在GitHub中，自动创建PR来更新有漏洞的依赖包。
       • GitLab依赖扫描： GitLab自带功能。
       • OWASP Dependency-Check： 开源的SCA工具，可以与CI/CD集成。
       • Snyk的免费层： 提供了基础功能。

3. 维护准确的依赖清单（SBOM）：

   • 软件物料清单（SBOM, Software Bill of Materials） 是你的项目使用的所有开源组件及其关系的清单，有了它，当新漏洞（如Log4j）爆发时，可以迅速知道你的项目是否受影响以及影响范围。
   • 很多SCA工具可以自动生成SBOM。

4. 及时更新依赖：

   • 不要忽视Dependabot或其他工具的自动更新PR,定期检查和合并这些安全更新。
   • 但注意：不要盲目更新，对于重大版本更新（如2.x到3.x），需要测试兼容性。

5. 最小化依赖原则：

   • “不要为了一个简单的功能引入一个巨大的库。” 如果只需要使用JavaScript中的 isEmpty() 函数，可以自己写一行，而不是引入整个Lodash库。
   • 定期清理项目中不再使用的、废弃的依赖。

6. 内部私有仓库（如果可以）：

   对于大型企业或关键项目,可以搭建自己的私有包仓库（如JFrog Artifactory, Sonatype Nexus），所有对外部包的拉取都经过此代理，这样可以在发布前对所有包进行安全扫描，只允许通过审查的包进入仓库。

开源依赖包当然有风险，但风险是可以被有效管理和降低的。 关键不是躲避它们，而是要建立一套 “选择-引入-监控-更新” 的体系化安全流程，并持续贯彻，对于任何生产环境使用的开源依赖，使用SCA工具进行自动化的安全扫描，是必不可少的最佳实践。