第三方代码
概述
第三方代码(Third-Party Code)是指开发组织并非自行编写,而是从外部供应商或开源社区引入并使用的软件组件的统称。库、框架、SDK、插件、API 客户端、开源包等均包含在内。在现代软件开发中,为提升生产力与扩展功能,依赖第三方代码已不可或缺,但同时也必须一并管理安全、许可证与维护方面的风险。
主要内容
定义与范围
第三方代码大体分为三类。第一,开源组件,即在 npm、PyPI、Maven Central 等仓库中分发的包。第二,商业软件开发工具包(SDK),即云服务或硬件厂商的官方库。第三,外包开发成果或供应商以模块形式提供的代码。
使用原因
- 提升开发速度:无需重新实现认证、加密、网络等重复性功能。
- 经过验证的稳定性:被广泛使用的库已在众多项目中得到测试。
- 降低成本:可节省自行开发与维护的人力。
- 符合标准:可轻松支持行业标准协议与格式。
主要风险
安全漏洞
第三方代码是供应链攻击(Supply Chain Attack)的主要通道。2021 年的 Log4Shell 事件就是被广泛使用的日志库漏洞影响全球数百万服务的代表性案例。滥用包名的域名仿冒(typosquatting)、恶意代码注入、依赖混淆(Dependency Confusion)攻击也屡见不鲜。
许可证问题
若包含 GPL、AGPL 等 copyleft(著佐权)许可证,可能产生公开自有源代码的义务。相反,MIT、Apache 2.0 则相对自由。遗漏许可证声明义务可能引发法律纠纷。
缺乏维护
若开源项目停止或维护者消失,便无法获得安全补丁。这常被称为“僵尸依赖”问题。
版本冲突
当要求同一库不同版本的依赖相互纠缠时,就会产生“依赖地狱(Dependency Hell)”。
管理方案
- 编写 SBOM(Software Bill of Materials,软件物料清单):将使用中的所有第三方组件列表化。
- 引入 SCA(Software Composition Analysis,软件组成分析)工具:用 Dependabot、Snyk、OWASP Dependency-Check 等自动扫描漏洞。
- 建立许可证政策:明文规定允许与禁止的许可证清单。
- 定期更新:确定安全补丁的应用周期并实现自动化。
- 最小依赖原则:仅引入确有必要的包,并管理传递依赖的数量。
最新动态
截至 2024~2025 年,第三方代码管理的范式正朝三大方向转变。
第一,监管趋严。美国行政令与欧盟《网络弹性法案》(CRA)要求提交 SBOM,供应链透明度正趋于义务化。韩国国内也在推广软件供应链安全指南。
第二,基于 AI 的代码生成日益普及。有人提出 Copilot、Cursor 等工具生成的代码可能包含既有开源代码的片段,验证 AI 生成代码的许可证来源成为新的议题。
第三,引入 SLSA、Sigstore 等供应链完整性标准。包签名与来源证明(Provenance)已在实践中立足,npm、PyPI 等主要仓库也支持签名验证。
相关主题
- [[开源]]
- [[软件供应链攻击]]
- [[SBOM]]
- [[依赖管理]]
- [[许可证]]