数字化转型是一股不可忽视的力量。在每一个垂直领域，企业都在努力成为科技公司，并越来越与众不同地实现这一目标。云和DevOps在这种转变中发挥着巨大作用，并彻底改变了我们开发和操作软件的方式。软件从未如此容易地创建、更频繁地更新或创新以如此迅速地适应客户需求。面对这样的变化，保安别无选择，只能适应。企业必须并将继续努力提高速度，而独立团队是实现这一目标的唯一途径。我们保护应用程序的方式必须改变，以便它成为这些独立开发团队日常工作的一部分。安全团队首先需要专注于帮助这些团队实现安全。安全需要成为发展的优先事项。安全行业不是DevOps旅程的一部分。安全流程倾向于控制正在进行的流程，而不是被纳入其中。值得注意的是，安全流程未能赋予独立开发团队安全能力由一个单独的团队拥有，开发团队无权做出安全决策，工具主要是为审计人员而非构建人员设计的。持续运营安全流程仍然严重依赖手动关卡，例如安全审计或结果审查，从而减慢了持续流程的速度。让安全与速度和独立性的业务动机相悖不太可能有好结果。开发团队必须在放慢速度（这会损害业务成果）和规避安全控制（这会带来重大风险）之间做出选择。这些都不是可行的长期选择，因此组织必须改变他们的安全实践以适应DevOps的现实。DevOps推动了对开发优先安全方法的需求，在数字化转型时代，我们也看到了云和云原生应用程序的演变。云原生应用程序的范围比它们的前身更广泛，并且越来越多地包含底层堆栈的更多元素。应用程序范围的这种变化也需要应用程序安全范围的变化。本文讨论了一种新的和扩展的应用程序安全范围，称为云原生应用程序安全性(CNAS)。采用CNAS需要对我们保护应用程序和基础设施的方式进行重大改变。转型的过程是一段旅程，每个组织的经历都是不同的，甚至同一组织的不同部分也是如此。虽然选择正确的道路取决于您，但为了走上正确的道路，模式和最佳实践已经开始出现。在这篇文章中，我提出了几个可以考虑打破现状的领域，以及如何。重新思考安全组织结构组织通常根据职责范围进行划分。当您将保护部分基础架构视为应用程序安全问题时，请重新考虑如何构建您的安全组织。更具体地说，考虑是否改变应用安全团队的职责范围。此外，随着您的安全实践变得更加以开发为先并专注于为开发人员提供支持，您对该应用程序安全团队的要求将会发生变化。你需要更多的同理心和项目管理以及更多的工程。你需要更多的建设者和更少的破坏者。为了帮助您评估您的安全组织应该如何构建，以下是我在应用程序安全领域看到的三个最常见的团队范围：核心应用程序安全、安全工程和新产品安全。这些应该作为如何构建组织的参考点，而不是采用完美的模型。核心应用程序安全团队让我们从现状开始，并保持应用程序安全团队的范围不变。由于这是默认状态，大多数组织至少将此团队范围用作起点。核心应用程序安全团队的任务是保护自定义应用程序代码和业务逻辑以及正在使用的开源库。他们通常有一个经典的应用程序安全测试(AST)套件，包括静态、动态和交互式应用程序安全测试（SAST、DAST和IAST）以查找自定义代码中的漏洞，以及软件组合分析(SCA)工具以查找易受攻击的开放源库。此外，这些团队经常开展安全教育和培训，并可能进行漏洞管理或漏洞赏金工作。在某些情况下，他们还可以使用RASP或WAF工具实现运行时应用程序保护功能。核心应用程序安全团队成员通常需要是安全编码方面的专家，并且具有应用程序操作审计和安全代码审计方面的一些经验。他们需要良好的开发人员同理心才能与开发人员一起工作，这反过来又需要一些理解能力或与代码相关的能力，而不是完整的软件开发证书。坚持核心应用安全团队的主要优势在于其在行业中的长期地位。这使得在整个团队中招聘具有现场经验的专业人员变得更加容易。对于工具，这是一个工具和实践都有详细记录的领域。从组织的角度来看，大多数行业会认为应用程序安全团队类似于核心应用程序安全团队。虽然核心应用程序安全团队的职责是维持现状，但其方法往往对开发人员更加友好。应用程序安全团队通常通过将团队中的个人职责分配给多个开发团队来帮助促进更好的协作。应用程序安全领域的许多同行都运行安全冠军计划，以帮助他们扩大规模并在他们的开发团队中嵌入更多的安全专业知识。虽然范围基本保持不变，但核心应用程序安全团队的内部实践不必是那些传统的。安全工程/安全平台团队安全治理流程中的自动化步骤是现代开发环境的关键。快速CI/CD管道没有手动审查的余地，而是需要自动化管道测试。此外，开发人员不是安全专家，在安全方面花费的时间较少，因此需要具有嵌入式安全专业知识并能够简化或促进安全决策的工具。构建和运行安全工具并不容易，尤其是在大型组织中，不同的开发团队有着截然不同的要求。为了帮助提高自动化程度，一些组织创建了专门的安全工程团队，专注于构建内部工具和集成外部工具，所有这些都是为了增强安全性。安全工程团队由稍微偏向安全的软件工程师组成，其运作方式与完整的DevOps工程团队类似。他们通常构建、部署和运营他们构建的服务，使用与其他工程团队相同的方法来运行他们的敏捷流程和管理产品积压。如果工作量不足以保证单独组建自己的团队，则通常也可以将相同的活动嵌入到核心应用程序安全团队中。然而，虽然标题为“安全工程”的小组在其章程中非常一致，但拥有（越来越普遍的）安全工程师头衔的个人在他们的职责上差异很大。有些是如上所述的软件工程师，而对于其他人，标题中的“工程师”部分指的是安全领域。安全工程团队是真正提高自动化水平的好方法，并且是面向Ops的平台或站点可靠性工程师(SRE)团队的一个很好的平行团队。事实上，在很多情况下，平台团队的范围已经扩大到包括构建和运营此类安全工具。这也是让软件工程师加入安全团队、帮助解决人才短缺问题并在安全团队中培养更多开发人员同理心的好方法。产品安全团队/云原生应用安全团队安全团队模型的最新成员是产品安全团队。这些团队的范围要大得多，不仅包括应用程序代码本身，还包括与产品相关的所有内容。最值得注意的是，两个关键的新增功能涵盖了CNAS的全部范围，并有助于在产品本身中构建安全功能。将完整的云原生应用程序安全范围扩展到包括CNAS范围是将某些基础架构风险重新考虑为应用程序安全的自然结果。如今，容器和IaC等技术由相同的开发人员使用相同的实践和工具编写自定义代码来驱动。为了支持这一变化，AppSec团队需要支持这些工程师才能成功地做到这一点。涵盖这一更广泛范围的团队通常将自己称为产品安全团队。扩大的CNAS范围意味着产品安全团队在软件开发生命周期的更大部分中工作。包括更多参与生产部署甚至运维工作，导致与更多以运维为主的云安全团队重叠。在实践中，云原生开发意味着云安全受到开发和运营团队的双重影响，产品安全涵盖前者。请注意，许多核心应用程序安全团队正在扩展以涵盖CNAS的全部范围，但并未正式更改其团队名称和任务。选择和实施扫描容器镜像漏洞和审计IaC文件的解决方案越来越成为应用程序安全团队的领域。虽然可以安全地假设产品安全团队涵盖了这个完整的范围，但这样的重命名并不是绝对必要的，而且许多应用程序安全团队在没有这样声明的情况下就已经成长起来了。产品安全功能与CNAS无关，但仍然值得注意的是，产品安全团队的参与有一个更面向用户的安全部分：安全功能。随着用户对安全重要性的认识不断增强，许多产品都希望内置专用的安全功能并通过这些功能实现差异化。确定哪些安全功能是有价值的需要一定程度的安全理解，开发团队可能没有，但安全团队有。产品安全团队通常在这里扮演明确的角色，与比以往任何时候都更拥有完整产品功能和价值主张的产品经理(PM)合作。此职责在应用程序和安全团队之间的关系中起着重要作用。安全控制是降低风险的一种手段，但能够将这种风险缓解作为一项安全功能提供意味着它可以帮助增加收入。增加收入是两个团队的另一个共同目标，而且比降低风险更明显，这更容易庆祝成功。产品安全的演变产品安全是一个新的名称和范围，并且仍在定义中。鉴于其更广泛的范围，它通常是父名称或大团队，其中包括提到的其他团队。在一些云原生组织中，产品安全是首席安全官(CSO)的主要职责，而另一些组织则开始任命领导者为首席产品安全官(CSO)。Atlassian首席信息安全官(CISO)AdrianLudwig说得最好：“产品安全的目标是改善产品的安全状况，并在内部向开发团队表达客户的安全期望”。其他公司，如Twilio、Deliveroo和Snyk也使用这个名称，我认为这是解决CNAS的正确方式。DevSecOps团队呢？您可能已经注意到我没有指定DevSecOps团队的名字，这并非偶然。与DevOps一样，DevSecOps不是一个团队；这是将安全嵌入到核心开发和运营工作中的运动。在我看来，它不应该是一个团队名称。然而，就像DevOps团队一样，DevSecOps团队也存在，并且他们的任务非常不同。有时，他们实际上是一个专注于运营和运行时安全的云安全团队。其他时候，它们更像是平台，职责类似于安全工程团队。由于头衔并不意味着一组特定的职责，因此DevSecOps团队的范围并不是真正可定义的。然而，所有这些团队的共同点是他们都具有前瞻性思维。DevSecOps旨在改变我们处理安全问题的方式，而DevSecOps团队，无论其范围如何，都将始终将自己视为变革推动者。他们拥抱自动化和云，更喜欢工程安全解决方案而不是审计，并致力于授权开发和运营团队保护他们自己的工作。
