一种新型的计算系统

第三方依赖管理

对项目中出现的任何第三方依赖有效的管理有非常重要的意义，通过扫描工具，识别出项目中是否有源码、jar包、二进制文件是否来源于某个开源项目。任何的第三方软件需要申请入库管理(内部其他团队申请通过可以直接使用)，质量团队对申请的软件进行评估：

• 是否有开源义务需要履行
• 引入的第三方依赖是否有 CVEs等漏洞
• 第三方开源软件是否仍然在维护

质量团队根据上面的一些条件，决定出申请的软件能否在项目中使用，允许被采用的软件会定义出优选级别，优先推荐团队使用较为优选的软件，并对项目整体的优选率有一定要求。如果项目中出现了无法识别的二进制文件、非约定目录下的代码片段，需要报备。通过良好的依赖管理和规范化，能减少不良第三方依赖的引入，让软件项目透明、可信。一些商业公司提供这些完整的服务，例如 fossid、blackduck、code-climate 等。

运维安全

大的软件公司，往往有一堆流程和要求。虽然一线开发对堡垒机、防火墙、各种安全规范显得不耐烦，但这些安全措施也在保护开发者。

1. 防火墙用于环境隔离

往往开发者理解的防火墙用于防止网络入侵、审计、入侵检测等功能，除此之外，防火墙还可以用于各个环境的隔离。一般来说，企业对于生产环境的数据控制比较严格，不会将生产环境的权限交给团队所有开发者，但网络连接有可能疏漏。曾经出现过一次线上事故，由于配置文件错误，将原本应该连接到测试的数据库连接到了生产环境，造成大量脏数据写入。如果通过防火墙规则对各个环境进行隔离，这类问题将不会出现。另外也可以设计 DMZ 区，将面向用户侧的网关部署到 DMZ 区，仅仅开放必要的端口给网关，实现内外网的物理隔离。同时，对整个系统的防火墙策略应该清晰地记录，否则在做大的基础设施更新时，梳理出所有的防火墙策略，是一件比较困难的事情。
 

第三方依赖规范化

软件开发过程中，不可避免的需要引入第三方或者开源软件包作为库或者框架引入。“第三方” 其实不是一个软件工程术语，现今在软件行业里面的理解是：第一方为自研的软件，第二方为内部发布的软件，第三方为从社区或者外部商业途径引入的软件包。对于个人开发者而言，面向“搜索引擎”编程往往将来源不明的代码片段和程序包引入到项目中。对于企业来说，考虑到的不仅仅是功能是否能实现，还要考虑引入时带来的成本和问题，例如是否需要授权、开源协议是否合理、是否会带来安全威胁。企业对于第三方依赖的引入分为几种情况：

• 作为开发工具引入，例如 gcc、Jenkins，基本没有开源协议问题，但是需要注意开发机、CI 会有安全风险。Jenkins 曾出现过漏洞，CI 服务器被当做远程矿机使用。
• 作为服务部署使用(SaaS)，部分开源协议会限制这种使用方式，第三方依赖的安全问题会威胁服务器。
• 通过软件包再发布，大部分开源软件对这种使用方式有较多要求，例如 GPL 开源协议具有传染性，要求使用了 GPL 的项目也要开源。
• 拷贝源代码引入项目，非常不推荐这种方式，尽量通过包管理的方式引入。

引入第三方依赖需要充分考虑，尽可能最小成本的引入。在一个 React 的前端项目中，有不熟悉的工程师，为了使用一个简单的手风琴效果，引入了整套 bootstrap。不仅破坏了使用 React 的最佳实践，而且让输出的 bundle 文件大小激增数倍，造成首屏加载的性能问题。

常见商业友好的开源协议

商业用户常用的开源协议实际上只有6种左右，即 LGPL、Mozilla、GPL、BSD、MIT、Apache，另外还有极其宽松的 The Unlic

 

（编辑：周口站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!