本文由 dbaplus 社群授权转载。
前阵子有篇文章叫《史上最坑爹外包！花费2亿耗时2年，网站至今未交付》的热文在 IT 圈刷了屏，讲的是世界顶级咨询公司埃森哲为美国汽车租赁公司赫兹开发新网站和移动应用程序的外包项目烂尾了，后者无奈之下诉诸公堂，从而让这个惊天大瓜暴露在世人面前。我们注意到，该项目代码存在影响面极广的严重安全漏洞，也让其难以投入使用。
一说到外包开发项目中的安全问题，相信找过外包开发商开发项目的同学再熟悉不过了，外包开发项目的安全漏洞不仅多，而且还经常是越权访问、SQL 注入、文件上传、代码注入等高危漏洞。
针对这一问题，本文就来谈谈外包开发存在的意义、外包开发中的安全风险与应对解决方案。
一、外包开发存在的意义
外包开发是 IT 服务外包的一种子类，实质还是基于企业与 IT 外包服务提供者之间的委托代理关系，由前者提出开发需求与系统设计后，由后者提供应用程序或者系统开发的服务。
首先，随着企业对核心竞争力的重视，越来越多的企业将 IT 服务外包作为一种新的长期战略成本管理工具，用来消除不属于核心业务的干扰分支。企业需要重新定位，截断价值链中较短的部分，缩小经营范围。
在此基础上，需要对企业的各种资源进行重新配置，将资源集中于最能体现企业优势的领域，从而更好地构建竞争优势，获得可持续发展的能力，这对于企业核心资源的长远发展有着重要的意义，可实现“成本控制”和“管理效益”的有效兼顾。
其次，对于一些非核心系统或者应用，企业采用自行开发的方式成本过高；或者对于一些需要前沿技术的产品，企业自身并不具备成熟的开发能力。因此选择外包开发是其平衡成本与效益的最佳选择。
再者，在移动互联网蓬勃发展、全民互联网创业的风潮之下，对于那些自身没有开发能力的创业者，如果从 0 构建开发能力则需要太多投入，一方面是业务紧迫性不允许，另一方面，即便投入了也不见得比专业外包做的更好，所以他们选择了外包开发。
二、外包开发安全风险
来自国外的报告显示，56%的企业数据泄露都源自第三方供应商，42%的企业都因为第三方供应商遭遇攻击而出现数据泄露。前不久，Facebook 就因为第三方数据泄露而再次成为众矢之的。
因此，为了保护企业数据安全，企业不仅要抵御自身所面临的内外部安全威胁，还要进行第三方风险管理（TPCRM）。这里所说的 TPCRM，对应今天我们讨论的外包开发安全风险管理。
1、外包开发模式分类
简单而言，按照代码部署场景、协作模式，目前的外包开发模式可以分成三类，分别是驻场式、远程式和完全独立式，它们在开发过程中所面临的安全风险或者甲方安全能力覆盖上都存在很大不同。
1）驻场式
外包公司通过劳务派遣的方式或者临时办公的方式安排其员工到甲方办公地点进行服务，入驻到甲方产品或开发团队之中。
这种模式下甲方的风险控制程度最高，因为此时必须遵循甲方的办公、开发、测试、发布流程规范，整个 CI/CD 的流程与环境都为甲方所控制，同时也处于甲方安全能力覆盖范围，相对而言，这种情况下安全风险最小。
2）远程式
外包公司员工在其办公环境下完成代码开发、测试，然后通过公共代码仓库或者其他在线文件系统或存储系统进行代码共享，由甲方完成代码的部署和系统运维，或者合并到其主代码分支中，再由甲方完成代码部署与系统运维。
这种模式下，甲方的风险控制程度相对较高，整个 CI/CD 的流程与环境都为甲方所控制，同时也处于甲方安全能力覆盖范围。
但是无论合同中如何约定代码所有权，代码都会为外包公司所接触，而且代码共享路径经常需要对外网开放，这也为代码泄露留下口子。
相对而言，如果外包公司有成熟的安全管控流程、代码共享路径进行有效的身份验证和访问控制，这种情况下安全风险较小。
3）完全独立式
外包公司独立完成代码开发、测试、发布，整个 CI/CD 流程为其控制，虽然线上运行环境不一定为外包公司控制，甲方可能只是配合域名指向或者品牌资源使用申请，但可以看到甲方对此风险控制程度非常弱。
这种合作模式下的安全风险往往是极高的，因为甲方安全能力基本覆盖不到，其成熟的发布流程也不一定管控到。
2、风险列表
1）敏感信息泄露
最常见的是调试模式未关闭、源码压缩包放在 web 根目录、版本控制文件.git/.svn 等文件放在根目录，或者外包开发人员将源码上传第三方仓库外泄，或者外包人员的个人电脑中毒或被入侵，导致甲方源码、数据泄露。
2）高危漏洞高可能性
外包开发通常使用开源开发框架，这类框架往往漏洞频发，很容易被批量利用，而且也经常出现高危漏洞，常见的如服务端任意文件下载、SQL 注入、客户端组件暴漏和敏感信息泄露漏洞等，可以拉取数据库信息或者入侵服务器。
另外，开发商代码架构、质量一般，更容易产生漏洞，或者在对用户可控输入的限制上存在遗漏。
3）敏感信息窃取
之前出现过银行外包开发商违规收集用户信息或者甲方业务数据。
4）埋入后门
外包开发人员故意留逻辑后门等。
5）漏洞分布的广泛性
由于外包团队的代码复用，一旦在某个外包开发的系统出现漏洞，很大可能也能在其开发的其他系统找到相同或类似漏洞。另外，外包开发商一旦被黑，其客户源码、数据也会泄露。
3、原因剖析
外包公司自身的安全管理水平较低、安全运维能力不足，对于完全独立式的外包开发模式而言极易出现安全漏洞。
外包公司员工安全技能和安全意识不足，可能本身外包公司对员工自身能力建设重视程度不高，也让其员工失去提升安全意识与技能的机会。
模板式开发模式，换言之就是复制粘贴式的开发，自定义组件化程度往往不高，代码安全质量没有保障。
三、外包开发安全风险管理
下面从组织架构、流程管控和技术赋能三个方面浅谈外包开发安全风险管理，其中大部分已经在国内大中型 IT 企业或多或少落地了。
1、组织层面
确定外包管理的目标，明确外包的总体原则，建立企业层面的信息科技外包安全防控架构，完善外包管理组织体系和制度体系。这种比较适合大型金融、通信、制造、互联网等行业的企业。
由于外包项目多、外包开发商也多，所以需要在公司组织架构上予以重视。比如规划、建设独立的外包管理团队，让制订从上而下的外包项目管理流程获得组织基础。
2、流程层面
1）合同约束
在与外包开发商的合同中是否有安全要求？这些外包开发商是否需要标准来遵循安全开发生命周期？他们是否对系统开发生命周期和如何安全地编码接受过培训？外包开发商对代码中的漏洞和泄漏敏感信息是否承担责任？一旦发现漏洞被利用是否需要开展应急响应？
如果这些要求都没有在合同中规定，那么，在未来合同中应该增加这些条款，并且，现有合同应该进行修订来涵盖这些条款。
2）按照外包类型分类管理
针对不同类型的外包，建立包含安全资质、安全管理和安全运维能力的评估在内的全生命周期管理的机制，以及外包安全管理效果衡量机制。主要有以下考量：
信息安全管理资质评估[BSI 安全认证审核、ISO27001 认证]。
安全管理（制度流程完备性、信息安全管控情况、安全意识教育、风险控制能力）。
安全运维（安全编码规范、安全应急响应流程、权限控制）。
确认、审查合作方的网络安全策略、技术，以及相关的实践和案例。
3）日常活动规范的建立
服务变更控制；服务人员管理；安全事件处理；业务持续管理。
4）走统一招投标流程
通过更透明、统一的准入流程让更重视安全质量的开发商获得公平机会。
5）确认第三方可以访问的数据/系统；确认企业与第三方共享的信息、资产情况
项目为非重要信息系统的编码和测试外包，所有生产数据经过脱敏后方可用于开发测试环境，外包商无法接触敏感信息。避免 IT 服务人员接触组织的核心系统信息，降低了 IT 服务外包对 IT 系统敏感部分带来的安全风险。
3、技术层面
1）设置持续性的合作方网络安全监控基线
合作生命周期内持续监管、持续验证，比如加强对业务异常的监控和分析。
2）加强对外包开发人员的安全意识和技能培训
比如外包人员须参加安全培训与考试，达标后方可进行开发，将代码漏洞率等作为项目结项考评的要素， 安全编码规范可以参考 OWASP 安全编码指南。
3）完善和细化安全测试方法、测试用例
投产前进行严格的安全测试，上线后进行周期性测试，更具体的做法有：
①上线前安全自检：
自查 checklist。
②上线前漏洞扫描与安全审计：
这里需要区分环境。如果代码的测试、运营环境在甲方中，可以接入甲方的漏洞扫描系统进行自动扫描。
否则，如开发商有条件可以自行进行漏洞扫描，也可以通过授权让甲方的安全能力进行覆盖。
同时提供测试环境、源码，配套提供软件设计文档和使用指南，给甲方安全团队进行代码审计，审计是否存在安全漏洞或者后门、隐蔽通道等恶意代码 。
当然，安全审计需要考虑人工成本，如果甲方能够提供自动化审计手段，则可以覆盖到每次变更发布，否则以大版本更新为控制力度。
③对外包开发的代码进行安全审计，特别是登录、转账等重要业务场景需要重点审计。
4）代码发布和系统上线流程管控
按服务器环境是否为甲方可控分类。如可控，则业务变更须由甲方操作，包括：测试环境测试、发布上线，否则要有审批机制，外包或合作开发的 Web 应用建议部署在甲方安全能力覆盖范围内，如默认未能覆盖可通过授权的方式申请覆盖。
5）权限控制（系统管理、数据访问、环境变更）
不开放系统管理类权限；不开放变更权限，如果必须开放变更权限，实际变更时须参考甲方的发布变更验收标准做验收和记录。
6）审计机制
对应用系统或者主机访问日志、操作记录进行留存，通过自动化方式或者周期性 review 的方式进行审计。
作者介绍：
林伟壕，腾讯高级工程师，专注于企业 SDL、SecDevOps 建设。目前从事安全风险评估与代码审计，曾在国内大型电信运营商与顶尖游戏公司从事运维、安全体系建设工作。
原文链接：
数据连接未来
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论