一、工行软件开发中心应用安全支撑体系概述
随着安全成为数字时代最重要的问题之一，越来越多的企业已经整合了 DevSecOps (DevSecOps 是“开发、安全和运营”的缩写，它可在软件开发生命周期的各个阶段自动集成安全性-从最初的设计到集成、测试、部署，一直到软件交付)生命周期，从而进一步强化安全，同时 DevSecOps 也被用于简化治理和提高可见性。
DevSecOps 的主要思想是安全应该遵循的“左移”方法，而不是事后修复和弥补。根据最新的 DevSecOps 趋势，大约 40% 的企业有在使用 DAST (Dynamic Application Security Testing：动态应用程序安全测试，模拟黑客行为对应用程序进行动态攻击，分析应用程序的反应，从而确定该Web应用是否易受攻击)测试，50% 在使用 SAST（Static Application Security Testing：静态应用程序安全测试，通常在编码阶段分析应用程序的源代码或二进制文件的语法、结构、过程、接口等来发现程序代码存在的安全漏洞），其余的企业通过扫描依赖项和容器来确保软件安全。
工行软件开发中心应用安全支撑体系建设围绕安全左移、过程管控和安全右移三个方面开展。在安全左移方面，通过自研ide插件提前发现安全风险；在过程管控方面，通过持续集成流水线识别并阻断安全风险，并通过 DAST 和 IAST 持续检测安全问题；在安全右移方面，通过安全监控，完善可疑流量报警和攻击行为阻断，通过安全右移来反哺过程管控。安全团队通过这些措施，将安全流程和工具更早的纳入软件开发生命周期（SDLC）中，在研发测试阶段将安全问题检出率提高到 99.22%。
图片
二、当前主要问题及挑战
从企业内部信息安全团队的视角看来，企业内部在整个研发流程中遇到的风险点较多，通过对各种攻击面的梳理和分析之后，我们发现在研发流程中经常提及的风险主要包含代码安全风险、供应链相关的风险以及服务器安全三大类，下文将逐一展开。
安全问题的引入-构建-发布过程，往往和企业内部的持续集成流水线是高度一致的，简单来说可以抽象成下图形式：
图片
开发人员在编写完代码后提交到源代码管理平台，然后触发 CI/CD 的构建编译打包流程，在这个过程中，构建平台的服务器会从依赖仓库（大型企业往往会自己建立 nexus 的私服）拉取所需的依赖包，完成构建编译之后，做成镜像推送到镜像仓库，通过项目分发平台分发到生产环境上，完成系统的上线。开发视角看习以为常，但安全视角看危机四伏。
1.供应链安全
在依赖引入的过程中，如果引入了有问题的组件，则相当于引入了风险，这也是目前最典型的供应链攻击手段，通过我们对各个源的安全调查和分析后发现，“投毒”的重灾区在 Python 和 NodeJS 技术栈,投毒的主要目的是控制设备进行“挖矿。（一个原因是因为前端的“挖矿”已经很成熟，容易被黑产滥用，另外一个原因是 Python 的机器学习库相当丰富，加上机器学习配套的计算环境性能强悍，导致“挖矿”的收益会比入侵普通 IDC 主机更高）。由于例子较多，这里就不一一列举了。
2.服务器安全
研发前期，在完成了代码完整性检测的前提下，如果流程没有被篡改或者构建平台都运行正常，一般情况下，出现问题的几率很低。但如果 CI/CD 平台和前面的 Git 一样被恶意篡改或是破坏，也会出现安全隐患，SolarWind 事件就是由于这一原因导致的，攻击者在 CI/CD 过程中嵌入了“后门”，通过了签名校验，再通过 OTA 分发补丁之后，出现了让人震惊的攻击事件。
3.代码安全
在软件开发环节，开发人员因为水平、安全意识的诸多原因，往往会在开发过程中引入漏洞，这本身是一件十分正常的事情。但对于开源软件而言，因为几乎所有人都可以向开源项目提交代码，并且通过审核后就可以 Merge 进项目，所以可能有不怀好意的人故意引入有问题的代码，这种风险实际上有可能因为审核的疏忽导致风险直接被引入。
三、应用安全支撑体系建设
工行软件开发中心应用安全支撑体系建设主要围绕应用编写、应用构建、应用发布和持续运营这几个环节来开展，通过在各个阶段提供完善的工具链支持，实现对各阶段的安全赋能。
1.应用编写环节
工行通过自研 IDE 插件，在开发人员的编码阶段对代码及引入的依赖进行准实时检测，根据风险特征匹配，提示开发人员在编码早期就完成对安全问题的修复，减少后期修复成本。这其实也是“安全左移”的最佳实践之一， 即将安全程序（代码审查、分析、测试等等）移动到软件开发生命周期（SDLC）早期阶段，从而防止缺陷产生和尽早找出漏洞。通过在早期阶段修复问题，防止其演变为需花费巨资加以修复的灾难性漏洞，进而达到节省时间和金钱的目的。
2.应用构建和发布环节
工行软件开发中心通过在应用构建和发布阶段建立软件物料清单（SBOM）来实现对软件资产的透视，实现安全威胁的快速发现和清除。应用软件通常由大量的开源代码、自研代码和第三方库组成。由于除了直接引用的开源代码、第三方库之外，在构建阶段开源代码常常会引入额外的依赖项，因此在软件开发阶段生成 SBOM，对于提高软件的透明度、提升安全事件处理效率有着重要意义。工行软件开发中心在DevSecOps 流程上集成软件物料清单，通过在 CI/CD 的标准实践，尽量覆盖绝大多数的场景（业务应用系统、Hadoop 作业等数据服务、Puppet 等运维服务等）。SBOM 包含的信息会随流水线的推进不断更新，SBOM 将作为软件产品的一部分，在统一的存储库中存储和管理。SBOM 作为软件信息数据源为安全运营体系中各应用提供软件信息数据支撑，包括但不限于安全资产管理、安全信息与事件管理（SIEM）、威胁情报管理等。SBOM 与安全运营平台上各项业务功能集成后，在提高对组件漏洞的可见性的同时，也大幅提升对风险的主动响应和风险预防能力。
3.持续运营环节
工行软件开发中心通过建设安全运营平台，实现对安全风险的可视化及全生命周期管理。企业组织不能以牺牲运行时安全为代价整体左移。开发人员永远无法编写出完美的代码，也无法在发布窗口期内足够广泛地扫描代码，扫描器的设计目的是为了找出遵循明确模式的已知漏洞或弱点。因此，安全团队通过对生产运行流量的监控，识别出威胁与攻击流量并告警，通过建设风险告警与资产关联的基础设施，实现对被攻击资产的快速定位与及时修复，通过安全右移来反哺过程管控。
四、结语
罗马不是一日建成的，即使确定了整体应用安全支撑平台建设需求和建设的方向，但落地仍然需要分阶段完成。正如建设其他的安全子系统一样，后续工行将持续从智能化、合规性和多层次防御等方面加强应用安全支撑体系建设，并在高度变化的威胁环境中保持战略优势。
