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