摘要
在本模块中，你了解了新式软件开发如何依赖于开源组件和学习的策略来实现开源软件，同时管理相关的安全、法律和作风险。 通过了解这些概念，你可以利用开源权益，同时保护组织免受潜在责任的伤害。
如何构建新式软件
你了解到 ，当代应用程序是从组件组装的 ，而不是完全从头开始构建的：
- 组件组合： 新式应用程序由大约 80 个% 在项目外部维护的现有组件组成，只有 20 个% 是原始业务逻辑代码。
- 开源与闭源： 开源组件提供公开可用的源代码，任何人都可以检查、修改和分发，而闭源组件仅分发没有源访问权限的二进制文件。
- 包生态系统： 组件通过包管理器（如 npm、PyPI、NuGet 和 Maven Central）分发，后者可自动执行依赖项管理。
- 基于组件的开发的优点： 重用经过验证的组件可以加速开发，通过社区审查提高质量，通过避免许可费来降低成本，并提供对尖端创新的访问权限。
- 开发速度： 通过允许团队专注于独特的业务价值，而不是重建通用基础结构，使用开源组件可显著缩短上市时间。
企业对开源软件的担忧
你检查了组织在采用开源组件时 面临的重大风险 ：
安全问题：
- 已知漏洞： 每年在开源组件中发现数千个安全漏洞，需要持续监视和快速修补。
- 供应链攻击： 攻击者入侵包维护者帐户、使用拼写错误或利用依赖项混淆来注入恶意代码。
- 未维护的项目： 许多开源项目缺乏维护，当维护者放弃项目时，漏洞未得到修补。
质量和可靠性问题：
- 可变质量： 开源组件的范围从专业维护的项目到测试不充分的业余代码不等。
- 中断性变更：组件并不总是优先考虑向后兼容性，需要在更新时更改代码。
- 文档差距： 文档不足会增加集成错误和滥用。
法律和许可问题：
- 许可证合规性义务： 每个开放源代码许可证都规定了从简单归因到强制性衍生作品开源等要求。
- Copyleft 传播：如果不仔细管理，GPL 等强 copyleft 许可证可能需要开源整个应用程序。
- 许可证激增： 应用程序可能依赖于具有数十个不同许可证的数百个包，从而造成复杂的合规性负担。
操作问题：
- 外部基础结构依赖项： 应用程序依赖于可能会发生中断或包删除的公共包注册表。
- 更新管理负担： 使依赖项保持最新状态需要持续的努力、测试和部署。
什么是开源软件
你了解了 开源软件的基本特征：
- 定义： 源代码公开可用的软件，可接受开放源代码许可证的检查、修改和分发。
- 协作开发： 开源项目涉及全球自愿参与的分布式参与者，开发在公共存储库中以透明方式进行。
- 广泛采用： 超过 90% 企业在生产环境中使用开源软件，开源技术为 Internet 基础结构、云平台和移动设备提供支持。
- Microsoft的转型： Microsoft从将开源视为威胁转变为全面拥抱开源技术，不仅开放了 .NET，还为 Linux 和 Kubernetes做出贡献，并创建了像 Visual Studio Code和TypeScript这样的流行开源工具。
- 战略理由： 组织通过代码检查选择开源，以节省成本、灵活性和控制、透明度和安全性，避免供应商锁定、社区支持以及提前获得创新。
开源许可证基础知识
你了解了 开源许可证如何控制软件的使用：
许可证用途：
- 定义权限： 许可证授予使用、修改和分发版权法禁止的软件的权利。
- 施加义务：许可证要求署名、公开源代码、保存许可证，有时还需要遵守 copyleft 规定。
- 不承担责任： 作者不负责损害赔偿，软件“按原样”提供，没有保证。
开放源代码定义条件：
- 自由分发： 不限制销售或赠送软件。
- 源代码可用性： 必须以首选形式包含源以供修改。
- 允许派生工作： 必须允许修改和衍生作品。
- 没有歧视： 不能歧视个人、团体或努力领域。
- 技术中立： 不需要特定技术或接口。
许可证类别：
- 宽松许可证： 允许将代码合并到专有软件中（MIT、Apache 2.0、BSD）。
- Copyleft 许可证： 要求衍生作品使用相同的许可证，确保软件保持开放源代码（GPL，AGPL）。
- 弱版权许可：要求对组件进行开源修改，但允许专有使用（如 LGPL、MPL）。
常见的开源许可证
你检查了 常用许可证及其关键特征：
宽松许可证：
- MIT 许可证： 最简单宽松的许可证只需要署名，最大化普及率和商业用途。
- Apache 许可证 2.0： 具有明确的专利授权和防御性终止的宽松许可，以确保专利清晰性。
- BSD 许可证： 类似于 MIT 许可证，3-Clause BSD 版本通过增加名称使用限制来实现对商标的保护。
强 copyleft 许可证：
- GPL v2 和 v3： 需要派生工程是 GPL 许可的，并使用二进制文件分发源代码;GPL v3 增加了专利保护和国际兼容性改进。
- AGPL： 扩展了具有网络使用条款的 GPL v3，要求 SaaS 产品的源代码公开。
弱著作权许可证：
- LGPL： 允许从专有应用程序链接到库，同时需要对库本身进行修改以开放源代码。
- MPL 2.0： 提供文件级别的 copyleft，仅要求公开 MPL 许可文件的源代码，而不是同一应用程序中的专有代码。
许可证兼容性：
- 兼容的组合： MIT + Apache 2.0、MIT + GPL v3、Apache 2.0 + GPL v3、LGPL + GPL。
- 不兼容的组合： GPL v2 + Apache 2.0、GPL + 专有、将不同类型的 Copyleft 许可证组合在一起。
许可证影响和风险评级
你了解了如何 评估许可证风险并实施合规性：
许可证风险框架：
- 低风险（绿色）： MIT、BSD、Apache 2.0 等宽松许可证对于任何商业用途都是安全的。
- 中等风险（黄色）： 像 LGPL、MPL 这样的弱 copyleft 许可证允许专有使用，但对修改进行限制。
- 高风险（红色）： 像 GPL 和 AGPL 这样的强 copyleft 许可证与专有软件分发不兼容。
- 未知风险（橙色）： 自定义或不清楚的许可证需要在使用前进行法律审查。
商业软件含义：
- 宽松许可证： 允许在仅有署名要求的情况下进行专有分发。
- 弱版权共享：允许在专有软件中使用库，但要求公开库的修改内容。
- 强共享软件许可证： 需要开放源代码衍生作品，使其与私有软件不兼容。
知识产权注意事项：
- 专有 IP 保护：宽松许可证保留专有代码；copyleft 许可证需要披露。
- 专利条款： Apache 2.0 和 GPL v3 包括显式专利授予;MIT/BSD 缺乏专利清晰度。
- 商业机密损失： 源代码披露消除了商业机密保护。
合规性实现：
- 依赖项清单： 维护全面的材料清单，跟踪所有开源组件和版本。
- 许可证兼容性验证： 使用自动化工具识别许可证不兼容。
- 属性符合性： 生成许可证聚合文件，包括在“关于”对话框中，并在文档中维护。
- 源代码预配：对于 copyleft 许可证，请提供附带生成说明的完整源代码。
软件供应链安全性：
- 漏洞扫描： 使用 Snyk、Dependabot 或 WhiteSource 等工具持续扫描依赖项来查找已知漏洞。
- 供应链攻击缓解措施： 验证包签名，首选信誉良好的来源，使用私有注册表，并锁定依赖项版本。
- 质量评估： 评估维护状态、社区大小、文档质量和安全做法。
组织策略：
- 审批工作流： 在采用新依赖项之前，对安全性、许可和质量实施预使用评估。
- 已批准的包列表： 维护开发人员可以立即使用的预审查组件的特选列表。
- 开发人员教育： 根据许可证影响、安全做法和合规性流程培训开发人员。
- 持续监视： 跟踪依赖项更新、许可证更改和漏洞泄露。
关键结论
在组织中实现开源软件时，请记住以下基本原则：
从战略上接受开源： 开源提供了巨大的优势，包括开发速度、质量、成本节约和创新访问。 不要因风险而避免使用开源技术，而是应实施治理流程以实现安全采用。
了解依赖项： 维护所有开源组件（包括可传递依赖项）的综合清单。 你无法管理你不知道的风险，使依赖项可见性的基础是有效的开源管理。
了解许可证含义： 不同的许可证对商业软件的影响大相径庭。 MIT 之类的宽松的许可证对于专有软件是安全的，Copyleft 许可证（如 GPL）要求对衍生作品进行开源。 将许可证选择与业务模型匹配。
评估许可证兼容性： 验证是否可以合法地合并不同组件的许可证。 不兼容的许可证可能会造成需要成本高昂的修正的法律问题，包括组件替换或代码重写。
实现自动化符合性： 手动许可证跟踪不会扩展到具有数百个依赖项的新式应用程序。 使用自动化工具进行依赖项扫描、许可证检测和漏洞监视。
确定安全性的优先级： 依赖项中的安全漏洞会影响应用程序，而不管它们源自何处。 实现持续漏洞扫描，并为关键安全修补程序建立快速更新过程。
管理供应链风险： 除了已知漏洞外，还通过包验证、源信誉评估、专用注册表和依赖项固定来防范供应链攻击。
使用自由平衡控制： 开发人员需要自由使用新式工具和框架。 与其阻止开源软件的采用，不如实施审批工作流和已批准的程序包列表来确保安全使用。
培训团队： 开发人员对许可和安全问题的认识至关重要。 培训计划可帮助开发人员做出有关组件选择和了解组织策略的良好决策。
持续监视： 开源管理不是一次性活动。 不断披露新的漏洞，许可证有时会更改，项目可以放弃。 持续监视可确保持续合规性和安全性。
通过应用这些原则并实施系统性的开源管理做法，使组织能够利用开源软件的巨大优势，同时有效管理安全、法律和运营风险。