如果你在谷歌上搜索 "DevSecOps"，特别是如果你阅读典型的安全供应商的博客，你会被原谅，认为这个术语都是关于自动化和工具的。然而，就像云原生（Cloud Native）与文化的关系远远超过与容器的关系一样，DevSecOps实际上是关于实现有效的沟通。
在本文中，我们将考虑CAMS模型（代表文化、自动化、测量和共享），但不考虑自动化，主要是因为网上已经有很多关于安全自动化的建议，同时也因为它不是我们在大多数商业环境中发现的典型限制。
文化
为了讨论这个问题，我们将关注Schein博士关于文化的工作，这也是Nicole Forsgren博士等人在他们的开创性书籍 "加速"中采取的方法。加速》也是WTF的推荐阅读书目，它证明了我们的软件开发团队的表现与组织的表现是相关的。
在Schein博士的模型中，组织文化发生在三个不同的层面：基本假设、价值观和人工制品。
基本假设
基本假设往往是随着时间的推移而形成的，因为员工和其他直接参与的第三方对他们的关系以及如何通过他们的过程和活动完成工作有了认识。这些是 "员工知道 "的事情，往往不是特别明显，因此很难改变。在安全方面，基本假设通常集中在理解环境和工作如何被优先考虑的背景，如何倾向于做出决定，以及相应地，这些决定是基于什么。
开始探索基本假设的第一个好问题是 "谁的工作是做安全的"？我们的行业已经开始鹦鹉学舌 "安全是每个人的工作"，尽管在实践中这很少有帮助。如果我们努力去真正了解其他人的工作，他们如何执行这些工作以及他们所受到的限制，我们可能会发现一些地方的安全问题确实是一个集体问题，而其他地方甚至没有考虑到这一点。我们还可以找到特别感兴趣的人，他们能够并且愿意在自己的团队中倡导安全。我们可以通过向潜在的安全倡导者传授基本知识来开始改变潜在的基本假设，从而为他们团队中的其他人提供一种更安全的方式来做他们已经在做的事情。
为了进一步扩展，我们应该注意到，在这些基本假设中，有两个关键因素--代理和信任，这将使你了解安全治理和你的开发或平台团队之间的合作动态。代理--对你所做的工作的控制--必须先于所有权，因为没有人愿意对他们不能共同创造的东西负责。对我们来说，作为安全专家，这意味着我们不是告诉软件开发人员该做什么，而是要给他们必要的工具，然后让他们控制如何将安全嵌入到他们的正常工作中，并积极确定对已发现的漏洞的缓解措施。然而，这也要求那些负责管理的人能够建立起高度的信任，相信现有的流程和实践能够充分证明该组织在保证其产品和服务的适当安全水平方面履行了应有的职责。
探讨组织内的机构和信任，特别是安全治理和工程之间的关系，将使你深入了解基本的假设是什么。
价值观
价值观对于团体成员来说往往更加明显，因为当你意识到集体的价值观和规范时，就可以对它们进行讨论。这些价值观通过建立社会规范来影响团体的互动和活动，这些规范塑造了团体成员的行动，并提供了背景规则（即：在这里我们可以做这样的事情，但不能做那样的事情）。
对于如何识别和使用价值观的一些实用技巧。
- 专注于学习公司和团队层面的价值观，例如通过询问他们感到自豪的是什么。更多的时候，安全团队对这些价值一无所知，这可能导致他们试图 "把婴儿和洗澡水一起扔掉"，从而导致安全倡议受到抵制。安全倡导者或实践社区是听取和探索组织中安全感觉的叙述的好方法。
- 下一步，在实现或追求这些价值的过程中确定安全活动。例如，如果我们的组织有一个目标和价值观，并与具有竞争力或实现上市时间相一致，我们就可以为我们的安全自动化计划设定需求。谷歌云CISO菲尔-维纳布尔斯提出了一个精彩的比喻，他称其为"滑流"业务举措以推动安全改进。
- 在引入实践和工具时，应将这些举措纳入公司价值的实现中。语言是很重要的。
- 如果你管理一个团队，确保你所做的事情和公司的价值观之间的映射在你自己和你的团队成员的沟通中经常得到加强。
当开始讨论价值观时，区分实际的公司价值观和典型的企业文化牌上听起来不错的价值观是很有用的。正如Patty McCord（前Netflix首席人才官）所说。
"实际的公司价值观，而不是听起来很好的价值观，是通过谁得到奖励、晋升或被解雇来体现的。"
通常情况下，当公司受到威胁时，一个组织的真正价值观就会显现出来。这对我们如何处理安全违规、安全事件和安全报告有影响。如果作为一个领导者，你已经养成了制裁和过早拿出纪律手册的习惯，那么你可以预料到对你的文化的寒蝉效应，因为没有人会愿意主动说出他们可能发现的任何安全漏洞，因为害怕这样做的后果。这意味着，我们需要通过促进组织的心理安全来使报告和讨论安全问题变得安全，这一点需要慎重和不懈。你需要使报告问题，即使有人觉得自己犯了错误，也总是最好的选择，而绝不是限制职业的活动。然而，我知道 "重大过失 "的界限总是存在的，所以你需要非常慎重地意识到它的位置以及它可能对整个组织的动态产生的影响。
艺术品
这句特别的话说明了我们应该如何对待文化变革的问题，肖克认为，文化变革往往试图从假设和价值观出发，而这是不太有效的。
"我的经验告诉我，改变文化的方法不是首先改变人们的思维方式，而是从改变人们的行为方式--他们的行为开始。
这表明我们首先应该关注实践和人工制品，因为它们会随着时间的推移对价值观和假设产生连锁反应。文化变革需要时间，所以要有相应的计划，并带着现实的期望开始行动。
人工制品是人们 "接触 "的任何东西。这可能是一个代码库，一个政策文件，一个电子表格上的调查问卷，一个需要安装的软件代理等等。
人工制品通常作为 "边界的跨越者"--团队之间的输入和/或输出接口。例如，一些开发团队可能被要求在电子表格上填写一个系统安全计划，强调所有的控制措施，这些控制措施将被用于正在建立的新系统。然后由安全专业人员对其进行审查，以签署设计并授权建立。
在如何使用人工制品方面，我们看到了一些关键的挑战，这些挑战会影响你对安全的预期效果。其中一些关键的挑战是。
- 人造物被创建，但没有作为能力进行维护
- 创建存在于工程师正常工作环境之外的人工制品
- 人工制品不能为管理系统的关注提供可追溯性
创造了人工制品，但没有作为能力来维护
Sriram Narayan在Martin Fowler的博客上的文章这样描述了 "产品高于项目"的观点。
"软件项目是资助和组织软件开发的一种流行方式。它们将工作组织到临时的、只负责建设的团队中，并以商业案例中预测的具体利益作为资金来源。而产品模式则使用持久的、以思想为基础的团队来处理持续的商业问题。产品模式允许团队快速调整方向，减少他们的端到端周期时间，并允许通过使用短周期迭代来验证实际效益，同时保持其软件的架构完整性，以保持其长期有效性。
大体上说，信息安全世界仍然停留在管理和交付项目的模式上，而不是管理产品。其中一个关键的区别是，当我们给一个团队一个代理来安装，或者一个新的政策文件来遵守时，工作并没有结束。组织是有生命的东西，在其目标和环境的限制下不断适应和发展，如果我们只是 "建立并忘记 "或 "建立并追究不符合要求的责任"，那么我们就是在卖弄自己，并不利于我们组织不断发展的能力。在这种更糟糕的情况下，我们最终会创造条件，使隐蔽的工作系统出现，因为工程师发现满足安全期望需要不可接受的权衡，并对实现他们的目标施加了不现实的限制。
创建存在于工程师的正常工作环境之外的人工制品
在为我们的团队和其他工程或业务团队创建这些人工制品时，我们倾向于以这样一种方式来制造它们，使它们处于正常工作环境之外。例如，我们提供的工具在CI/CD管道中不提供反馈，迫使工程师登录到不同的门户来查看安全报告的输出，而不是选择将所有质量问题（如其单元、集成或端到端测试）直接规范到CI/CD系统本身的技术。或者我们创建的政策文件只作为Word文档存在，或者存在于工程师们从来不使用的协作工具中，然后我们想知道为什么其他人没有注意到。为了影响正常工作的完成，我们需要考虑上下文，并确保我们建立的能力能够与之无缝整合。任何与此不同的东西都会增加摩擦，因此不是我们的安全计划中对其他团队有利的元素。
人工制品无法实现对管理系统关注的可追溯性
我的意思是，我们可能知道我们正在对不安全的软件依赖的使用进行验证，或者对正在使用的角色的权限进行一些验证，但是没有任何东西可以用来将它与我们试图管理的组织风险或我们可能有的合规义务联系起来。
利用元数据的使用来保持我们所关心的事情的可追溯性，是扩大使用所提供的能力的关键，并将其纳入工件的创建中，因为它成为另一种使团队之间有意义的沟通的机制。例如，如果我们有一个测试，输出针对软件依赖的已知漏洞运行验证的结果，并且该测试被标记为它帮助我们实现的合规性要求，那么现在我们有一个人工制品，它具有工程背景的必要信息。此外，它还提供了所需的证据，合规经理可以直接从流程的运行中使用，以确认每次有人部署代码或新系统时，哪些合规要求得到了满足。这消除了人工审计和人工追踪的需要，使各方都更有效。
测量
测量是创建和维持我们安全计划的另一个具有挑战性的方面。在讨论衡量标准之前，我们应该想一想这些标准的受众是谁，以及我们打算衡量的内容如何与那些将受其影响的人的关注点保持一致。
Jabe Bloom讨论了（参考了Elliot Jacques之前的工作，Elliot Jacques是一位心理分析学家和社会科学家，他提出了 "自由裁量权的时间范围 "的概念），它将一个组织中的利益相关者所做决定的复杂性和他们的责任范围联系起来。这个概念也与行动的可观察性联系在一起，也就是说，"在检查结果之前，你的经理会允许你在多长时间内产生产出？"对于高管来说，这往往是多年的周期，而对于知识工作者（如工程师）来说，这可能被限制在两周的冲刺阶段或类似的阶段。
原文来自 ：https://www.youtube.com/watch?v=WtfncGAeXWU 作者： Joshua Bloom（完整参考资料见本章）。
测量应该让我们有一个场所，根据在每个时间尺度上有意义的内容来连接这些不同的时间线。
其中一个方法是通过执行层面的风险管理来连接测量，在副总裁/董事层面关注安全能力和关键风险指标，并在知识工作者层面将其与威胁建模的实践联系起来。
风险可以使用领结图和类似的技术来呈现，以提供威胁和控制的可视化，以及后果和针对它们的缓解措施，根据你的风险管理成熟度，使用定量或定性的方法。
副总裁/董事级别是风险容忍度的表达应该转化为衡量标准和目标的谈判，通过在你的背景下有意义的属性，牢记组织的所有其他限制和目标。
然后，这些可以帮助告知有针对性的威胁建模会议，以帮助探索这些积极的安全属性，并确保缓解措施到位，以保护免受相应的威胁。
在工程层面上，同样的指标也是相关的，但是了解安全实践如何影响关键的DevOps指标将是我建议你开始的地方。
来自DORA的研究（以及他们的DevOps状态报告）将软件交付绩效的4个关键指标与我们需要熟悉的组织绩效联系起来。这些指标是：。
- 交付时间--从客户提出要求到得到满足所需的时间
- 发布频率--将软件部署到生产中（这代表了代码部署的批量大小）。
- 恢复服务的时间--当事件发生时，恢复服务所需的时间
- 变更失败率--对生产系统的变更中失败的百分比
我们如何处理安全问题会对这些指标产生不同的影响--要么是不利的，要么是支持的。
| DORA指标 | 有害的信息 | 支持性指标 |
| 准备时间 | 人工审查和开发前的风险分析可能对其产生负面影响（风险专家的节奏与开发冲刺计划不一致）。 | 尽量减少人工审查、启发式方法和轻量级的风险分析过程，如服务级（而不是功能级）风险评估和有针对性的风险知情威胁建模。 |
| 发布频率 | 人工漏洞检查或渗透测试可能会对此产生负面影响，而不进行这些检查则风险太大。 | 开发平台级验证，并立即反馈给开发人员，输出结果易于消费和解释，并对假阳性进行本地管理 |
| 恢复服务的时间 | 复杂的、未经测试的灾难恢复流程和无计划的取证会对这一指标产生负面影响。 | 定期测试事件管理和灾难恢复流程，以及定期审查 "险情 "或战争游戏/游戏日，有助于通过定期测试响应来改善这一指标。 |
| 改变失败率 | 失败是建立在安全发现上的，没有让开发人员管理假阳性，也没有与开发节奏一致的清晰快速的异常管理流程。 | 建立务实的安全边界，仅在对组织构成实际风险的安全发现上失败构建，例如具有已知利用代码的关键漏洞或正在被攻击者积极利用的漏洞。 |
关于衡量标准的主要收获如下。
- 使它们与 关注它们的利益相关（因此在其机构内）。它们必须能够支持个人责任范围内的知情决策，而不仅仅是与其他人的关注有关。理想情况下，它们应该有助于突出目标冲突和权衡。
- 将你的衡量标准情境化：在整个组织中采用 "一刀切 "的方法，可能会疏远那些落后的人，而对那些领先的人来说，则不会成为行动的动力。团队背景是关键，因此，与产品所有者的关系也是一个关键因素。衡量标准的目标必须经过协商才能有效。
- 在不了解 "当前 "是什么样子或涉及到的权衡的情况下，不要建立目标指标。这是一个承诺目标的秘诀，这些目标与现实无关，或者考虑到绩效和能力目标是别人的日常工作，是无法实现的。
分享
分享是使知识和能力在组织内传播的关键。这必须至少体现在三个方面：关注点的分享、能力的分享和信息的分享。
为了确保关注点的分享，你必须把建立一种条件作为目标，让人们在心理上可以安全地报告弱点、漏洞或风险。做到这一点是很难的，需要持续不断的深思熟虑的行动，而破坏这一点是很容易的，一个判断失误的管理层或执行层的反应就能为人们建立起不主动报告的条件。最近的一个例子是，大众汽车公司最近在一名高级雇员提出网络安全问题后将其解雇。虽然这里可能有一些细微的差别没有被《金融时报》的文章所传达，但仅仅是一篇文章或通信存在的事实，就足以使员工更有可能试图隐藏或假装他们没有看到安全问题，因为害怕受到谴责或职业限制。当然，我们希望的是员工能够坦率地说出他们所发现的情况；如果他们觉得不能这样做，我们就会一无所知，并更多地暴露在风险之中。报告机制和领导者如何处理坏消息是优化的关键因素，以支持这一点。
为了确保能力的共享，你的目标应该是创造出最好能同时支持多个团队的人工制品，这样少数人就能成为专家，然后能够支持其他人提高自己的安全能力整合。这是适当扩大安全计划的一个关键因素，对组织设计有明显的影响。Manuel Pais和Matthew Skelton在《团队拓扑》一书中所描述的 "授权团队 "的概念，是一种提供能力的方式，通常由创建安全实践社区或安全倡导者计划来支持。这些可以反过来作为一个 "传感器网络"，了解安全在你的组织中的感觉，并提供一个接触点，安全团队可以在多个不同的团队中极大地利用他们的影响。
最后，为了确保信息的共享，主要的见解是，信息需要尽可能接近接收者的背景。在软件开发的背景下，如果你的开发者在一个协作工具上的Word文档上，而他们没有其他用途，也从未作为日常工作的一部分访问过，那么就不要指望他们知道你的安全策略。如果你的开发人员在GitHub或Confluence中寻找指导和他们自己的文档，那么你的政策就应该在那里，这样他们就可以在他们的工作环境中存在。这就消除了与认知负荷增加和性能下降有关的上下文切换。启用异步信息消费总是一个好主意，所以录制关于如何解决一个特定问题或集成一个工具的短视频，对于更新知识和帮助新团队成员入职都很有用。
结束语
DevOps和DevSecOps所涉及的不仅仅是工具和自动化，我们的安全计划也应该反映这一点。专注于文化的改变，确定有助于为项目提供方向感的相关衡量标准，而不使其本身成为目标，这是关键，而采取有意的行动，使共享成为安全项目的一个组成部分和重点。关注这些将对你的安全成果产生更大的影响，而不是花时间和精力在Gartner的魔力象限中选择一个领导者或一个有远见的DevSecOps工具供应商。
我们的重点应该是获得正确的文化、正确的共享机制、可以帮助指导和纠正行动的体面的可用测量以及任何合理的技术。DevOps和DevSecOps是关于持续改进和减少反馈循环的。从迪斯尼的冰雪奇缘电影中吸取教训，我们应该专注于 "做下一件正确的事情"。
