报告核心观点 - 提出向Linux基金会构建并运营名为信任与安全倡议（TSI）的项目的提案，及其他需投资和帮助的安全问题的建议 [4] - TSI包含八项最佳实践及认证计划，旨在提升开源项目的安全性，且该提案基于此前行业大规模实施软件安全的工作，借鉴微软的可信计算（TWC）和安全开发生命周期（SDL），并针对开源社区和现代软件开发团队进行调整 [5][6] - 实施TSI最佳实践虽不能完全避免安全问题，但能提升软件安全性和用户信心，且该方案会根据反馈和采用情况不断更新和完善 [8] 各部分总结 概述 - 软件安全面临挑战，但有解决的希望，此前已有实现软件安全的经验，且可根据团队文化匹配技术和工具，减少对开发的影响 [11][12] - 文档分为八项最佳实践、认证计划和其他需投资和帮助的安全问题三个主要部分，各部分采用先说明意图和目标，再以表格形式描述具体实践的结构，且该方案可灵活实施 [13][14] 八项最佳实践 角色与职责 - 明确团队安全计划中各角色的职责，缺乏明确角色和职责是导致安全问题的重要原因 [22] - 包括指定首席安全官、首席安全工程师、首席安全架构师等角色，确保每个人了解自己的安全职责，并参加相关培训，大型项目可设立专职安全团队 [23][25] 安全策略 - 定义团队安全计划的内容，组织应发布安全策略，包括组织级和项目级的策略，并确保相关人员阅读和确认 [27][28] 了解贡献者 - 目的是让组织信任贡献者，消费者信任软件，可通过验证贡献者身份、使用强认证、基于角色的访问控制、实施贡献者许可协议和公布贡献者列表等措施实现 [30][31][33] 软件供应链 - 软件供应链攻击常见，需锁定工具链并验证其中的内容，如仅接受拉取请求、使用受保护分支、数字签名提交、立即处理安全问题等 [35][36] 技术安全指南 - 技术安全指南可缩小安全解决方案范围，Linux基金会可维护核心技术指南并允许组织扩展和定制，包括应用安全、操作系统安全配置、云安全配置等指南 [42][43] 安全剧本 - 定义特定安全流程的执行方式，如事件响应和漏洞管理流程，Linux基金会可开发和维护集中的剧本并允许组织定制 [47][48] 安全测试 - 描述多种安全测试技术，优先推荐自动化测试，也包括一些手动测试，如安全检查、威胁建模、静态分析安全测试等 [50][51] 安全发布和更新 - 对最终用户很重要，组织应定义安全发布标准，对发布进行数字签名，发布安全构建证书，公布不安全版本信息并实施自动安全更新系统 [58][59] 认证计划 - 可基于云安全联盟（CSA）的STAR计划模式构建和运营认证计划，该计划对软件生产者、消费者和安全咨询行业都有好处，Linux基金会可提供相关资源和优惠 [63][64][66] 其他需投资和帮助的安全问题 安全构建证书 - 行业面临难以了解产品安全性的问题，建议Linux基金会构建规范和工具，生成可附加到软件发布的安全构建证书，以提高开源软件和互联网的安全质量 [69][70] 缺乏优秀的开源安全测试工具 - 缺乏可信的免费开源安全测试工具阻碍了安全测试的广泛应用，建议Linux基金会投资开发，可参考一些有前景的项目，并推荐Jacob West领导该工作 [73][74][77] 开源软件包分发对互联网构成风险 - 开源软件包分发存在问题，建议Linux基金会开发和运营中央库分发系统，并内置适当的安全功能 [79] 漏洞披露存在问题 - 通用漏洞披露（CVE）系统存在格式、披露流程、规模和商业冲突等问题，需要重新思考适用于DevOps和开源时代的漏洞披露方式 [82][83][85]

报告核心观点 - 软件成分分析（SCA）工具可帮助软件开发团队从许可合规性和安全漏洞角度跟踪和分析引入项目的开源代码 但缺乏标准方法比较和评估此类工具 本文旨在推荐评估多个SCA工具的一系列比较指标 [3] 评估指标 知识库 - 衡量知识库大小 包括开源项目数量和跟踪文件数量 列出主要跟踪的存储库、生态系统、源语言 区分包级别检测和特定语言支持 明确知识库更新频率、客户请求添加到知识库的时间和流程 [7] 检测能力 - 具备校正/配置分析器的能力 说明检测方法 处理部分代码片段 提供校正和验证结果的选项 支持对结果进行排名 能够自动识别代码的来源和许可 减少误报 支持多种类型的分析 明确支持的语言及分析类型 [10] 易用性 - 具有直观的设计和用户界面 提供本地客户端、浏览器插件或移动客户端 运行所需培训极少或无需培训 但提供结果检查和评估的培训 [11] 操作能力 - 提高源代码扫描速度 确保工具可用于并购活动且无使用模式的许可限制 支持不同的审计模型 具备编程语言无关性 能够在组织内复用扫描说明 与构建系统无关 提供API和命令行界面（CLI） [13] 集成能力 - 支持用户界面集成 能够将组织的合规政策集成到工具中 并根据声明的政策和规则标记代码 [14] 安全漏洞数据库 - 关注漏洞数据库的大小、更新频率和漏洞信息来源 了解工具提供商为验证漏洞警报所做的额外研究 评估漏洞检测的精度、召回率和上下文漏洞优先级排序能力 [14] 高级漏洞发现 - 支持高级漏洞发现 能够识别复制到新组件中的漏洞代码 [15] 相关成本 - 考虑基础设施成本、运营成本、年度许可成本、与现有工程/IT工具和基础设施集成的初始成本、导出项目和其他信息的能力、锁定成本以及工程定制成本 [15] 支持的部署模型 - 支持现场部署、云部署或混合部署 明确代码和项目信息离开网络的情况 [16] 报告能力 - 能够生成所需的合规通知 明确通知的依据和包含的内容 支持多种报告格式和开放标准格式 [16] 相关项目 - 开放合规计划 为开发者和律师提供开源合规工具和最佳实践的学习起点 [21] - ACT（自动化合规工具） 旨在改进检测和遵守开源许可证的软件工具 提高开源合规工具的互操作性 [21] - OpenChain 定义组织开源合规计划的关键要求 建立一致性计划 使公司能够自我认证 [21] - SPDX（软件包数据交换） 以标准化、人机可读的格式传达软件物料清单信息 促进组织间信息沟通和合规工具的互操作性 [22] - 面向软件开发人员的开源许可基础培训 为开发者提供免费的在线开源许可和合规培训 [22] - 白皮书和博客文章 定期发布关于解决日常实践中出现的开源法律问题的内容 [22]

报告核心观点 - 开源并购评估清单可评估组织开源实践 需坦诚评估开源项目优缺点 组织应根据自身情况调整合规方法 [7][9][10] 评估类别 开源软件发现 - 产品开发周期早期进行开源软件发现 系统识别需合规分析的软件和材料 [13][17] - 第三方供应商披露交付物中的开源软件 组织审查披露内容准确性和完整性 [19] - 组织定期审计开源软件使用情况 准备开源物料清单 [19] 开源软件使用的审查和批准 - 组织审查所有产品和服务中使用的开源软件 定义触发重新批准的情况 [21] - 采用系统方法识别代码基线变化 有效进行增量合规 [21] - 开源审查委员会审查和批准开源软件使用 定义相关程序并记录审议情况 [23] 义务履行 - 组织验证第三方供应商提供满足开源许可义务的信息 定义触发许可义务的软件传输模式 [27] - 组织以一致和规范的方式履行义务 提供许可证文本和义务要求的存储库 [27] - 开发团队按要求提供完整源代码 进行验证活动确保源代码可构建和符合要求 [29] 社区贡献 - 社区贡献按定义流程审查和批准 确定员工贡献是否与工作相关 [34] - 明确计划贡献的版权归属 跟踪公司对开源社区的贡献 [34] 政策 - 制定政策使公司能够在产品和服务中使用开源软件 由高级管理人员倡导并传达给整个公司 [35] - 政策涵盖合规行动的角色和职责、开源软件使用的审查和批准流程等内容 [38] 合规人员配置 - 提供有技能和知识的人员参与合规工作 明确合规职能的工作描述 [38] - 从跨职能部门抽调人员参与合规 提供培训和学习机会 [38] 业务流程调整 - 估算合规工作的总工作量和持续时间 制定人员配置计划以满足产品发布周期 [41] - 修改现有业务流程以纳入开源合规活动 进行流程失效模式与影响分析 [42] 培训 - 为接触开源软件的人员提供基本培训 定义培训对象并记录培训情况 [46] - 提供开源相关主题的额外培训 鼓励内部开源用户和贡献者社区的发展 [46] 合规流程管理 - 明确实现组织级开源合规的责任 合规支持团队可获取相关专业资源 [48] - 应用项目管理原则管理合规项目和团队活动 设定合规目标和优先级 [48] 开源软件清单 - 跟踪产品合规活动的进度 系统跟踪开源问题的解决情况 [52] - 维护产品和服务中开源内容的准确记录 开源审查委员会维护审查记录 [52] 自动化和工具支持 - 评估合规流程以确定自动化和工具支持的机会 定期调查相关工具 [56] - 采用系统方法评估工具 计划和执行工具获取或开发项目 [56] 验证 - 使用批准的方法确定产品中开源软件的内容和需合规分析的文件 跟踪开源问题至解决 [59] - 合规团队按定义程序进行验证活动 确保产品发布时满足开源许可义务 [60] 流程遵守审计 - 进行流程遵守审计以确定组织是否遵循定义的合规流程 评估合规结果 [64] - 审计确定组织是否维护准确的开源软件内容和合规活动记录 [64] 收购目标公司的审计准备 了解代码内容 - 维护完整的软件清单 包括软件组件的来源和许可信息 具备识别和跟踪开源组件的流程 [66] - 制定开源合规政策和详细流程 输出开源物料清单 [67][70] - 大型企业的开源合规团队是跨学科团队 小型公司或初创企业可由工程经理和法律顾问组成 [71][73] - 提供开源和合规培训 提高员工对开源政策和策略的认识 [74] - 使用工具自动化源代码审计、发现开源代码和识别许可证 [75] 保持合规 - 跟踪所有开源软件的使用 编制最终的开源物料清单 履行开源许可义务 [76] - 每次发布软件更新时重复合规流程 及时认真响应合规查询 [79] 使用最新版本以确保安全 - 利用合规计划查找并替换不安全的开源组件版本 升级时确保组件许可证不变 [77][78] - 企业开发者应订阅并监控相关邮件列表 关注安全漏洞和修复信息 [78] 评估合规工作 - 参与OpenChain项目并获得“OpenChain Conformant”状态 确认组织有开源软件合规流程或政策 [79] 收购公司的审计准备 选择合适的审计方法 - 传统审计模型由第三方审计公司的合规审计员远程或现场扫描源代码 按流程执行并交付报告 [82][87] - 盲审计模型由FOSSID AB利用专有技术在不查看源代码的情况下进行审计 提供高度保密性 [89] - 自行审计方法使收购方或目标公司可使用开源合规云工具自行扫描 适合有内部经验的公司 [92] 明确关注重点 - 确定关键的许可证和用例 关注相关信息 [97] 提出正确问题 - 利用清单中的问题与目标公司沟通 澄清或确认合规相关问题 [98] 确定交易前需解决的事项 - 识别开源审计中发现的不可接受的许可证或合规实践 要求目标公司解决 [99][100] 制定收购后合规改进计划 - 收购大公司收购小初创企业时 帮助目标公司建立正式合规政策和流程 提供培训和支持 [101] 推荐的合规相关开发实践 推荐实践 - 使用开源软件前请求批准 链接代码时遵循相关规定 [104] - 更新修改日志 记录代码与开源软件的接口信息 [104] - 保存开源软件包的许可证信息 升级时验证许可证是否变化 [104] 避免常见错误 - 不删除或干扰现有许可或版权信息 不重命名开源组件 [107] - 未经批准不复制粘贴代码 不将开源或第三方代码提交到内部产品源代码树 [107] - 未经批准不合并不同许可证的源代码 不与公司外部人员讨论合规实践 [107] 结论 - 开源尽职调查是并购交易中重要的一部分 若双方做好准备并与高效的合规服务提供商合作 可快速完成 [108] - 目标公司应保持良好的开源合规实践 收购公司应明确关注重点并具备解决问题的能力 [109] - 开源合规是持续过程 公司应投资建设和改进开源合规计划 [110]