系列文章（1）：浅谈企业 DevSecOps 实践：基本原则

系列文章（2）：浅谈企业 DevSecOps 实践：安全如何与研发协同工作

系列文章（3）：浅谈企业 DevSecOps 实践: 安全测试集成

系列文章（4）：浅谈企业 DevSecOps 实践: 构建安全工具链

本文旨在帮助安全人员为应用程序安全程序创建一个大纲或结构。 我们将回答一些常见的问题，比如“我们如何开始构建应用程序安全策略? ” “我如何开始合并 DevSecOps? ” 及”我应该遵守什么样的应用程式安全标准? ”我将讨论软件开发生命周期(SDLC) ，介绍在实施计划时需要考虑的安全事项，并参考一些应用程式安全标准，作为应采取哪些安全措施的指引。 这篇文章将帮助你制定战略; 下一篇文章将介绍战术工具的选择。

安全计划和你的 SDLC

安全软件开发生命周期(S-SDLC)本质上描述了安全该如何适应软件开发生命周期的不同阶段。 我们将研究 SDLC 中的每个阶段，并讨论哪些安全工具和技术是适当的。 请注意，S-SDLC 通常是作为一个瀑布开发过程描绘的，具有线性进程中的不同阶段，但这实际上只是为了更清晰地描述——实际的 SDLC 可能是敏捷的、极限的，或者像瀑布一样的螺旋式的。 有充分的理由将 S-SDLC 基于更现代的 SDLC之上; 但是架构、设计、开发、测试和部署阶段都可以很好地映射到任何开发过程中的开发阶段。 它们提供了一个很好的起点，可以将当前的模型和流程适应到 DevOps 框架中。

在我们之前的文章中，我们希望你将 S-SDLC 看作是构建你的安全程序的框架，而不是一个完整的循序渐进的过程。 我们认识到这与课堂教学和维基教学有所不同，但是对于每个阶段的安全计划来说更好一些。

定义和架构

· 参考安全体系架构: 参考安全体系架构适用于不同类型的应用程序和服务，包括 web 应用程序、数据处理应用程序、应用程序的身份和访问管理服务、流或事件处理、消息传递等。 架构在公共云环境、 Kubernetes 集群和服务网格环境中甚至更有效——在这些环境中，我们可以通过策略严格控制每个应用程序的操作和通信方式。 对于云服务，我们建议你利用服务提供商关于部署安全的指导方针，尽管他们可能不会称之为“参考安全体系架构” ，但他们确实提供了这些指导方针。 了解应用程序平台，并询问软件设计师和架构师他们使用了哪些方法。 如果对于传统的应用程序，如果他们给你一个茫然的眼神，不要感到惊讶。 但是新的应用程序应该包括流程隔离、分离和数据安全计划，以及完整的 IAM 模型，以促进职责分离和数据访问控制。

· 操作标准: 与你的开发团队一起定义最小的安全测试需求，以及关键的和高优先级的问题。 你将需要协商哪些安全缺陷将导致构建失败，并提前定义流程。 你可能需要就修复问题的时间框架达成一致，并需要某种类型的虚拟补丁来解决难以修复的应用程序安全问题。 你需要预先定义这些事情，并确保你的开发人员和 IT 合作伙伴同意这些事情。

· 安全需求: 就像在代码验收之前必须运行的最小功能测试一样，你将在部署之前运行一组安全测试。 这些可能是针对你的团队所写的具体威胁而商定的一系列单元测试。 或者你可能要求所有 OWASP 十大漏洞在代码或支持产品中得到缓解，将每个威胁映射到所有 web 应用程序的特定安全控制。 不管你选择什么，你的基准需求应该既考虑到旧的功能，也考虑到新的功能。 越来越多的测试需要更多的资源进行验证，并且随着时间的推移可能会减慢测试和部署周期，因此你可以决定哪些测试可以阻止发布，哪些测试可以扫描以便进行后期生产。

· 监控和度量: 如果你将在每个版本中进行小的迭代改进，那么需要修复什么？ 哪些代码模块对安全有问题？ 什么是有效的，你如何证明它？ 度量标准是回答所有这些问题的关键。 你需要考虑需要收集哪些数据，并将其构建到 CI:CD 和生产环境中，以度量脚本和测试的执行情况。 这意味着你需要让开发人员和 IT 人员参与收集数据。 你将不断改进度量标准的收集和使用，但是从一开始就要对数据的基本收集和传播进行规划。

设计

· 安全设计原则: 一些应用程序的安全设计和操作原则提供了重大的安全改进。 例如用于帮助修补和减少攻击者持久性的临时实例、用于移除攻击表面的不可变服务、用于确保服务器和应用程序正确设置的配置管理、用于配置一致的云环境部署的模板、自动化修复、通过锁定开发人员和 QA 人员而将职责分离出生产资源等等。 同样重要的是，这些方法是 DevOps 的关键，因为它们使软件的交付和管理变得更快更容易。 这听起来似乎有很多需要解决的问题，但 IT 和开发人员也投入其中，因为这也使他们的生活变得更加容易。

· 确保部署管道的安全: 随着开发和生产环境更加固定，开发和测试服务器成为更具吸引力的目标。 传统上，这些运行环境的安全性很低或根本没有安全性可谈。 但是，对安全源代码管理、构建服务器和部署管道的需求正在增长。 由于 CI/CD 管道提供了进入生产的自动化路径，你至少需要对这些系统进行更严格的访问控制——特别是构建服务器和代码库。 而且，如果脚本在后台连续运行，并且人工监视很少，那么你将需要额外的监视来捕捉错误和不当使用。 许多工具提供了良好的安全性，具有数字指纹、2FA、日志、以角色为基础的访问控制和其他安全特性。 当部署在云环境中时，管理台允许控制整个环境，必须非常小心地进行访问控制和职责分离。

· 威胁建模: 威胁建模仍然是最有成效的安全实践之一。 虽然 DevOps 没有改变这一点，但它确实为安全团队成员提供了机会，可以指导开发团队成员处理常见的威胁类型，并帮助计划单元测试来应对攻击。 这个时候你需要决定是否在公司内部培养这个人才，还是聘请一个顾问，因为没有哪个产品可以为你做到这一点。 威胁建模通常在设计阶段执行，但也可以在开发较小的代码单元时执行，有时也可以通过自建单元测试执行。

开发

基础架构和自动化优先: 自动化和持续改进是关键的 DevOps 原则，对于安全也同样重要。 正如前面的文章所讨论的，自动化是必不可少的，因此你需要选择和部署安全工具。 我们强调这一点是因为计划很重要，有助于开发人员在交付新代码之前计划出他们需要部署的工具和测试工作。 请记住，许多安全工具需要集成一些开发技能，因此要么计划让你的员工提供帮助，要么参与专业服务。 坏消息是，在准备过程中需要预先支付费用和完成工作; 好消息是，未来的每一个构建都将从这些努力中受益。

· 自动化优先: 请记住，开发并不是编写代码和构建脚本的唯一团队——现在操作也是如此。 这就是 DevOps 如何将修复和加固带到一个新的水平。 运维的 DevOps 角色是提供构建脚本，用于构建开发、测试和生产服务器的基础设施。 好消息是，你现在正在测试的是生产环境的精确副本。 模板和配置管理解决了传统 IT 多年来一直努力解决的一个问题: 临时性的无文档的工作“调整”环境使得环境能够正常工作。 同样，要使环境完全自动化需要做大量的工作——在服务器、网络配置、应用程序等等上面——但是它使未来的工作更快、更一致。 我们采访的大多数团队每周都会构建新的机器镜像，并更新他们的脚本以应用补丁、更新配置和构建脚本以适应不同的环境。 但是这项工作确保了一致性和安全的基线。

· 安全代码存储库: 你希望为开发人员提供一种简便的方法来获得安全的和(内部)批准的开放源码库。 我们的许多客户都保留了经过批准的库的本地副本，使得访问这些资源变得很容易。 然后，在将代码部署到生产环境之前，他们使用成分分析工具和脚本的组合，以确保开发人员使用的是经过批准的版本。 这有助于减少易受攻击的开放源码的使用。

· Scrum 中的安全性: 如前一章节所述，DevOps 是与流程无关的。 你可以根据自己的喜好使用螺旋式，敏捷，或手术团队的方法。 但是敏捷 Scrums 和看板技术非常适合 DevOps。 他们专注于较小的、重点突出的、快速可证明的任务上，这很好地实现了协调一致。 我们建议在这个时候设置你的“安全冠军”程序，在每个团队中至少培训一个人学习安全基础知识，并确定哪个团队成员对安全主题感兴趣。 通过这种方式，安全任务可以很容易地分配给那些有兴趣并且有一定的技能处理这些任务的团队成员。

· 测试驱动开发: 持续集成的一个核心原则是永远不要将有错误或未经测试的代码提交到代码库中。 错误和未经测试的定义取决于你。 与编写巨大的瀑布式规范文档以提高代码质量或安全性不同，你正在用函数脚本和程序编写策略文档。 单元测试和功能测试不仅定义而且增强安全需求。 许多开发团队使用所谓的“测试驱动开发” ，其中的测试确保所需的功能——并避免不需要的结果——与代码一起构建。 这些测试用例被存入代码库，并成为应用程序测试套件的永久部分。 安全团队没有充分利用这种类型的测试，但是这是检测特定于代码的安全问题的一个极好方法，而商业工具却没有这样做。

测试

· 为失败而设计: DevOps 颠覆了 IT 和软件开发中许多长期坚持的原则。 例如，耐久性过去意味着“正常运行时间” ，但现在是更换的速度。 带有详细产品规格的大型文档已经被便利贴所取代。 对于安全性来说，曾经专注于让代码通过功能需求的团队现在正在寻找赶在其他人之前破坏应用程序的方法。 这种“混沌工程”的新方法有意破坏了应用程序的部署，迫使工程师在可靠性和安全性方面进行构建。 詹姆斯 · 维克特的《哥特列特》中有一句话: 对你的代码要刻薄——就像它雄辩地表达了你的思想一样。 我们的目标不仅仅是在自动交付过程中测试功能，而且是要真正测试代码的坚固性，并大幅度的提高可接受发行版的最低安全性。 我们通过在应用程序上线之前有意地对其进行各种功能测试、压力测试和安全测试，从而加强了应用程序的性能——减少了安全专家亲自测试代码所需的时间。 如果你能够找到某种方法来破坏你的应用程序，那么攻击者也有可能破坏你的应用程序，因此，你需要在应用程序启动之前构建测试以及补救措施。 你需要计划这些测试工作，以及构建它们所需的资源。

· 并行化安全测试: 所有敏捷开发方法都有一个共同的问题，那就是如何处理比开发周期更长的测试。 例如，我们知道对关键代码片段进行模糊测试所需的时间比敏捷 sprint 的平均时间要长。对大量代码进行 SAST 扫描通常要比构建过程长一个数量级。 DevOps 也是如此—— 使用 CI 和 CD 代码可能在创建后的几个小时内交付给用户，而且可能无法执行完整的白盒测试扫描或动态代码扫描。 为了解决这个问题，DevOps 团队同时运行多个安全测试以避免延迟。 他们将大型应用程序分解成服务，以加快扫描速度。 针对已知关键问题的验证由单元测试来处理，以便进行快速抽查，并将失败的代码返回给开发团队。 代码扫描器通常与单元测试或其他功能测试并行运行。 我们的观点是，作为一名安全专家，你应该寻找加快安全测试的方法。 组织效率与速度的测试以及完整性与完成时间的测试，对于我们交谈过的每个开发团队来说，都是一种持续的平衡过程。 将扫描集中在代码的特定区域有助于更快地发现问题。 一些公司还讨论了维护预填充和完全配置的测试服务器的计划——就像他们维护生产服务器一样——等待下一个测试周期以避免延迟。 为了提高效率和快速部署而重写和重新配置测试环境有助于 CI。

预发布

· 弹性 FTW: 有了公共云和虚拟化资源后，快速提供测试服务器变得更加容易。 我们现在可以通过一些 API 调用启动新环境，并在不使用时缩容。 利用随需应变的弹性云服务来加速安全测试。

· 测试数据管理: 开发人员和测试人员有一个非常坏的习惯，就是将生产数据复制到开发和测试环境中以改进他们的测试。 在过去的几十年里，这一直是许多数据泄露事件的源头。 锁定生产环境，这样 QA 和开发人员就不能泄露受管制的数据，这很好，但也确保他们不会绕过你的安全控制。 数据屏蔽、标记化和各种工具都可以生成高质量的测试数据，从而最大限度的降低它们使用生产数据的动机。 这些工具提供来自生产数据的测试数据，但去除了敏感信息。 这种方法已经证明对于许多公司是成功的，而且大多数厂商为 DevOps 管道提供了合适的 API 或自动化功能。

部署

· 手动与自动化部署: 通过自动化将新代码推入生产环境非常容易。 但对代码进行审查，或者在出现错误时进行回滚，要困难得多。 与我们交谈过的大多数团队还不能完全适应全自动化部署——这会吓坏许多安全人员。 持续的软件交付实际上只有少数公司使用。 大多数公司每隔几周才向客户发布新代码，通常是在一系列冲刺之后。 这些公司通过脚本执行许多部署操作，但是在操作和开发资源可用时手动启动脚本以完全监视推送操作。 有些组织确实对完全自动化的生产推送非常满意，每天会发布几次。 没有单一的正确答案，但无论哪种方式，自动化都能完成大部分工作，从而腾出人员进行测试和监视。

· 部署和回滚: 为了仔细检查在预部署前的测试中工作的代码能够在开发环境中仍然可以工作，我们交谈过的团队仍然会进行“冒烟”测试，但是他们已经将这些测试进化为自动化和更细粒度的控制。 我们看到了三个常用于增强部署的技巧。 第一个也是最强大的部署称为蓝-绿或红-黑部署。 新旧代码并排运行，各自在自己的一组服务器上。 在负载均衡器级别，如果发现错误，负载均衡器就会指向旧代码。 第二种是金丝雀测试，其中一小部分单独的会话是针对新代码的——优先的对内部员工的测试人员开放，然后开放给外部客户的子集。 如果金丝雀死亡(遇到错误) ，新代码将退出，直到发出的代码可以修复为止，此时将重复该过程。 最后，特性标记通过配置文件启用和禁用新的代码元素。 如果在新的代码段中发现了事件错误，则可以关闭该特性，直到该特性得到修复。 在不同的模型和组织之间，自动化和人工干预的程度有很大的不同，但总的来说，这些部署比传统的 web 服务环境更加自动化。

· 生产环境安全测试: 即使安全控制失败，应用程序通常也能继续运行。 例如，一个新的部署脚本可能会错过对 web或应用层防火墙策略的更新，或者应用程序可能在没有任何防火墙保护的情况下启动。 验证——至少是关键安全组件的健全性检查——对于生产环境是必不可少的。 我们采访的大多数大公司都雇佣了渗透测试人员，许多公司都有专职的“红队”来检查应用程序运行时的安全缺陷。

· 自动化运行时的安全防护: 许多公司将 Web 应用程序防火墙(WAF)作为其应用程序安全程序的一部分，通常是为了满足 PCI-DSS 需求。 与我们交谈过的大多数公司对这些工具都不满意，所以当他们继续利用 WAF 黑名单时，他们采用了运行时应用程序自我保护(RASP)来填补剩余的空白。 RASP 是一种应用安全技术，嵌入到应用程序或应用程序运行时环境中，检查应用层的请求，以实时检测攻击和误用。 除了“应用程序上下文中的 WAF” ，RASP 还可以在应用程序框架的许多地方进行监控和执行，既可以针对特定类型的攻击定制保护，也可以允许 web 应用程序请求“完成” ，直到在阻止请求之前发现某个请求确实是恶意的。 在过去三年里，我们接到的几乎所有讨论应用程序安全和 DevOps 的电话都讨论了 RASP，而且我们接触的大多数公司都部署了这项技术。

应用程序安全标准

目前已经有一些应用程序安全标准可用。 开放式 Web 应用程序安全项目(OWASP) TOP 10和 SANS 常见弱点枚举 TOP 25 是最流行的安全漏洞，但也有其他威胁和常见弱点列表，这些列表通常侧重于特定的子主题，如云部署或应用程序安全度量。每个标准都倾向于被一个或多个标准组织所接受，因此你使用的标准通常取决于你所处的行业。 或者你可以把它们都用上。

无论你的选择如何，我们的想法都是了解哪些攻击是常见的，并在构建管道中使用一个或多个安全控制和应用程序安全测试来解释这些攻击。 本质上，你构建的是一个威胁矩阵，并将它们映射到安全控制。 此步骤将帮助你计划采用哪些安全工具并将这些工具放入构建过程，以及在生产中使用哪些安全工具。