数字化转型浪潮下，为提高软件开发效率，公司和开发工程师都倾向于使用开源代码。从研究咨询公司 Gartner 统计数据来看，应用程序建设中 80%-90% 的软件工程师会使用开源组件。

随着市场上开源项目逐渐增多，业内人士开始意识到开源代码无疑是一把双刃剑。站在资金投入角度，应用程序开发中调用开源代码，能够大幅降低软件成本，但站在业务安全风险和合规角度，一旦调用的开源代码带有病毒、漏洞，兼容性低，或者不满足合规要求，便有可能引入安全隐患。

开源治理工作越来越受到重视，早在 2018年，信通院就推出《开源治理白皮书》。因此，当下企业在保证最大限度发挥开源代码优势同时，还应思考如何规避其带来的业务风险及安全治理问题。

1 月 11 日，某 IoT 解决方案供应商技术专家 Rical.Liu 在FB甲方安全 Talk 会第 10 期直播活动担任演讲嘉宾，带来《开源代码治理》主题分享，详细讲述企业应如何进行开源代码治理、开源代码合规治理以及安源代码安全治理。

直播开始，Rical.Liu 老师引入了南京未来和江苏云蜻蜓知识产权侵权案。南京未来发现江苏云蜻蜓使用了一款和南京未来非常相似的软件，不久后又发现自己一个前员工跳槽至江苏云蜻蜓（太巧了），立刻就把相似软件的代码反编译了一下，发现里面有一些非常奇怪的硬编码，类似公司名称或其它一些字段和自己的代码神之吻合，随即起诉了江苏云蜻蜓。法院判决江苏云蜻蜓侵犯南京未来的著作权和知识产权，需要予以资金赔偿。
本以为这件事情到此为止了，但南京未来不久后发现江苏云蜻蜓没有停止侵权的行为，依然在继续的使用商用侵权的软件，便再次起诉江苏云蜻蜓知法犯法，明知故犯，要求法院给其一个高额的罚金予以惩戒。江苏云蜻蜓也意识到了事情的严重性，即刻召集安全团队，研发团队和律师团队，想办法来规避这个风险。
江苏云蜻蜓的律师团队发现“侵权源代码”里面用了一个 SharpZIPLib 开源组件，这个开源代码是基于 GPL 的一个衍生证书写的。（GPL 的规则是，如果没有按照规定的方式使用，那么就需要将相关代码开源）但南京未来的代码并没有开源。
江苏云蜻蜓表示南京未来拿一个侵权的代码来起诉我侵权，这本身就是一件荒谬的事情，于是就把它们的观点告诉了法官，法官也认可，原来需要索赔 2000 万的一个案子，最后判赔 300 万。
通过这个案例，可以看出做好开源治理对于企业来说多么重要。

如何做开源治理？

开源治理本质上就是对开源代码进行管理控制，以达到在安全和合规两个方面的治理目标。从安全角度来看，业内人士一般说是资产，威胁，脆弱性三个角度。

资产角度来讲要构建开源代码的软件物料清单SBOM（Software Bill of Materials），从脆弱性的治理角度来讲就是收敛开源代码当中的安全漏洞，可通过修复、规避，甚至是减轻。在直播中，Rical.Liu 表示威胁可能因为是各场景不太一样，很难给出统一标准。

开源治理中另外一个方面就是合规治理，相对于安全治理，合规治理其实很简单，是要求使用者遵照开源代码 License 的要求使用开源代码，从而去规避商业代码开源以及著作权侵权等一些相关风险。

开源 license

开源代码就是源代码可以随便获取的计算机程序代码，代码的权利持有人，一般也就是作者通过一定的License（相当于协议许）将自己代码修改的权限，使用的权限，再分发的这些权限授予任意的使用者。

开源 License 实际上就是证明代码权利的持有人，一般就是作者授予所有的使用者，包括贡献者、使用者，只要你遵守我的 License 的相关条款，履行你应该尽的义务，在这种前提下，就可以将代码修改使用再分发。

在对开源 License 学习的时候，一般都是通过根据编写 License 人的初衷来对 License 进行分类建档，以大而化之的形式按类归档，建立一个触类旁通的知识体系。以下是 License 分类以及关于开源代码使用限制的参考：

合规治理

在分享过程中，Rical.Liu 强调，相较于安全问题存在规避、修复的可能，合规却是的的确确会影响到企业的商业利益，因此合规治理显然非常重要。

合规治理工作不能够盲目开展，需要有一个前期准备工作。首先要明确治理对象是哪一个项目并获取项目里面的开源代码清单，清晰开源代码名称、版本、来源、Lisense、使用过程中是否存在修改以及使用方式。一旦连开源代码清单都未能获取，便是一纸空文、何谈合规治理工作。

在讲到获取开源清单获取，Rical.Liu 指出目前部分软件项目复杂程度较高，可能某个项目就依赖于多个开源包，甚至于开源代码中也积累众多开源包，这时就需要通过商业化的 SCA 工具，对所有的代码进行一个扫描，选一个比较好的工具对源码、固件或者是镜像进行扫描，获取里面的一个开源代码清单。

如何判断代码是否开源？

1. 判断项目是否涉及代码分发或提供 Web Service

2. 判断涉及开源代码 License

3. 部分开源代码基于其他开源代码编写或者引入了新的开源 License，这种情况下，如能明确 License和具体代码文本的覆盖关系，则根据对应代码 License进行开源治理，若不能的,则建议按照最高级别License 予以治理,，亦有部分开源代码同时包含多种 License,，且明确声明可以选择 License 遵守，可按照最低级别予以治理

4. 修改源代码/静态链接/动态链接/独立进程

代码专利

关于当开源代码专利问题，Rical.Liu 指出开源代码原作者或者贡献者是可以将所持有与代码相关的专利授予任何可能潜在的使用人。例如在使用的 Apache2.0，GPL3.0，LGPL3.0，Mozilla1.1/2.0这些 License 的时候，不需要考虑是否侵犯专利。值得一提的是，不能用专利授权去进行专利的诉讼，一旦起诉那一刻开始，授权就被撤销了。

直播答疑和好礼大放送

议题分享结束后，主持人和 Rical.Liu进行了交流互动并代表直播间同行进行了提问。

大神:开源软件版本参差不齐，内部软件的开发与使用会有不同的版本差异，如何做到最优的兼容和监控，避免因为开源软件版本漏洞带来的管理问题？

答：兼容的问题一般不是安全/合规侧能够去决定，因为兼容本质上是研发测的事情。尤其是现代软件工业上下游协作分工明确，在这种情况下，开源代码的选用往往是依赖于上游厂商，安全/合规侧很难去插手。对于监控，以web开发为例，使用一个统一的开发环境，配置相同的开源组件是一个不错的选择。但是因为版本的一致性，可能会出现一个漏洞全部沦陷的风险。所以，最优兼容和监控本身就是一个适应于业务场景的问题，没有标准答案。

安平不太平：固件漏洞升级修复如何保持兼容性以及不再更新的开源组件存在漏洞如何解决？

答：升级尽可能升级小版本，不升级大版本。开源代码的功能实现和代码架构一般不在小版本变动，都是大版本变动，这种情况从1.1.1a升级到1.1.1b往往并无兼容性差异；针对不更新的开源代码，可以考虑选择同类代码替换，但是这个可能会存在风险或者过高的工作投入，因此，根据代码证书将代码闭源或者开源维护也是一个可以考虑的选项，这种情况下除了修复安全问题外，还可以扩大组织的影响力，是一种双赢。

我本小唐：开源代码引入，安全应该在哪些方面卡点管控？在合规法务方面呢？可以从哪些方面着手？

据我所知很多公司会将SCA和敏捷开发整合在一起，这种工作模式下，会在需求阶段就进行规划，然后在CI卡点扫一次，release卡点扫一次；同时研发还可以视需要自查。整体的管控原则就是商业代码开源风险考量结果、自己/客户的安全准入，这个就各不相同了。

siberia ：目前SCA工具是否能真正的缓解开源代码带来的风险，如果能，该类型的工具如何嵌入开发过程中实现自动化处理，友商有没有成熟的案例可以提供参考。

SBOM和开源代码漏洞清单的需求越来越多，对于没有相关能力的公司，唯一Solution就是SCA，这个不是发现风险，缓解风险的问题，是大部分情况下能力建设的唯一解，更何况很多客户在供应商准入都会拿SCA卡一道。开发过程自动化的话，可以问一下华为和oppo，据我所知这两家的开源治理水平非常高，应该是国内T0级别。

菲尼克斯 ：如何和知识产权及出口管制合规结合？实操上如何和利益相关方合作并约定责任？

鉴于开源代码的license具有非歧视性，也就是任何人都可以使用开源代码，所以一旦你的专利或者涉及出口管制的能力依赖于开源代码实现，实质上就是进行了专利授权或者违反了出口管制，因此，结合的要点是相关专利和能力尽可能依赖于闭源代码，并在代码开源前增加相关评估流程。约定责任一般是法务的工作，和供应商和下游客户，签署相关文件，约定各自承担由各自开源不合规导致的损失。

抽奖环节

直播的最后，Rical.Liu和主持人一起抽取了数位互动观众送出精美礼品。

欢迎大家加入FreeBuf甲方社群

本期直播精彩回顾到此结束啦~此外，FreeBuf会定期开展不同的甲方社群直播，想了解更多话题和观点，快来扫码免费申请加入FreeBuf甲方群吧！加入即可获得FreeBuf月刊专辑，还有更多精彩内容尽在FreeBuf甲方会员专属社群，小助手周周送福利，社群周周有惊喜，还不赶快行动？

申请流程：扫码申请-后台审核（2-5个工作日）-邮件通知-加入会员俱乐部

如有疑问，也可扫码添加小助手微信哦！

申请流程：扫码申请-后台审核（2-5个工作日）-邮件通知-加入会员俱乐部

如有疑问，也可扫码添加小助手微信哦！