编者按: 以下是Adobe赞助的博客文章:
不断变化的安全形势受到日益持续的威胁的驱动, 越来越复杂的攻击和更严格的遵从性要求让Adobe的安全和产品团队都很忙. 随着变革的步伐不断加快, 我们发现，传统的安全参与模式——试图在事后将安全问题和特性纳入产品——无法扩展. 由于使用了更新的云技术，应用程序开发过程变得更加快速和抽象，这一点尤其正确, 比如容器和微服务. 除了, 我们意识到，如果我们的安全团队继续使用我们一直使用的相同方法与产品团队合作, 我们可能会发现自己永远处于追赶的境地. 这可能会让我们被视为“检票员”，而不是在安全方面产生影响并取得有意义的进步——鉴于目前的发展速度，这绝对是不可扩展的.
在仔细检查了我们的流程以及与产品和服务团队的接触后，我们确定了在以云为中心的应用程序开发世界中，什么是最有效的, 我们专注于发展我们的用户参与模式，使其更加 前瞻性和协作性 第一，使之成为我们安全接触战略的一个基本概念. 在我们的应用程序安全工作中，这是在开发过程中尽可能多地“左移”安全工作的总体策略的一部分.
以下是我们推荐的安全约定流程的五个关键改进，以帮助确保“设计安全”原则在团队中得到更好的应用:
订婚
安全团队通常与产品组中的安全冠军进行接触. 虽然这些安全冠军帮助我们的集中式安全团队扩展安全工作, they are not the ones ultimately responsible for product roadmap decisions; that responsibility falls on Adobe application 发展 teams. 在软件开发生命周期中适应这一现实有助于我们创建一个参与模型，在正确的时间将正确的参与者带入安全对话, 不仅要确保适当的优先级和及时的补救, 但也要获得承诺，做出真正的决定.
为此目的, 我们现在采取分层的方法, 每两周与安全冠军进行一次交流，每月或每季度与产品架构师和产品管理人员进行一次会议，以了解有关整体产品路线图和设计策略的更多信息. 我们还将继续与工程团队会面, 主题专家和DevOps每次剥离新服务时，都需要更多的细节来更好地理解系统和服务的内部工作原理. 这有助于每个人在各个层面保持知情，并有助于确保产品安全.
谈话
在与工程团队的对话中做出有意识的转变是至关重要的. 虽然这种沟通是一种软技能，可能会被工程师们低估, 我们发现它帮助我们获得了工程和产品路线图的早期可见性，并将我们的对话从工程的单向信息下载转变为双向咨询和协作.
解决问题
而不是开会只是为了审查安全问题和收集增量进展的最新情况, 我们改变了与产品团队的基本接触方式. 通过成为更好的倾听者, 我们不仅成为他们设计过程中不可或缺的一部分, 但我们也成为了解决问题的人，可以帮助进行头脑风暴, 构思并解决复杂的架构挑战.
伙伴关系
这种方法上的改变使我们的安全和产品团队之间的合作关系更加紧密. 安全团队成员不再被认为是那些在不合理的时间表内推动额外工作的人. 而不是, 我们现在被视为关键的合作伙伴，可以被信任，可以指出错误并支持正确的方法. 我们的谈话集中在如何安全地 设计 应用程序和服务从头开始.
设计和构建安全
在软件开发生命周期中“左移”，并在设计和开发阶段早期与产品团队合作，有助于确保产品团队理解将安全需求与功能需求放在同等位置的需求. 确保在整个软件开发过程中真正集成了安全性——在概念中, 设计, 发展, 构建, 测试和部署阶段——这对Adobe和我们的客户来说都是双赢的.
随着越来越复杂的攻击和不断变化的业务需求, 对于安全团队来说，与他们的产品团队保持联系是非常重要的. 在Adobe, 这意味着我们的安全小组必须保持灵活性，并使我们的参与策略与产品团队保持一致，以帮助确保安全性和遵从性需求与业务需求一起得到满足. 我们坚信，从长远来看，培养这种共生模式将有利于安全和产品团队.
