浅谈企业 DevSecOps 实践: 安全在 DevOps 中的角色

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

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

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

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

系列文章（5）：浅谈企业 DevSecOps 实践：安全计划

正如前面提到的，DevOps 并不完全是工具和技术，但它的成功很大程度上取决于人们在这个模型中的工作方式。 我们已经对工具和流程进行了详细的介绍，并且从安全从业者与 DevOps 合作的角度探讨了大部分内容。 由于本文主要是为了帮助安全人员，所以我们在这里概述他们在 DevOps 环境中的作用。 我们希望这个总结能帮助你和其他团队一起工作，减少摩擦。

虽然我们有意将这篇文章命名为企业 DevSecOps，但请记住，你的开发，IT 同行们认为根本没有这回事。 对他们来说，安全性成为集成和交付代码的操作过程的一部分。 我们称安全性为一个独立的东西，是因为当它被编入 DevOps 框架时，安全人员实际上更难适应。 你需要了解如何改进安全代码的交付，而不会浪费时间，也不会在你可能并不熟悉的开发过程中引入瓶颈。 好消息是，安全性非常适合 DevOps 模型，但是你需要在组织使用的自动化和编排中进行调整以获得成功。

安全专家的责任

学习 DevOps 模型: 在本文中，我们甚至还没有触及 DevOps 的理论和实践。 在基本概念和实践方面有很多东西需要你学习。 要在 DevOps 环境中工作，你需要了解它是什么以及它是如何工作的。 你需要了解文化和哲学上的变化，以及它们如何影响过程、工具和优先级。 你需要了解公司的方法，以便最好地集成安全工具和指标。 一旦你了解了开发团队的机制，你就会对如何在他们的流程上下文中与他们一起工作有了更好的了解。

学习如何变得敏捷: 参与 DevOps 团队意味着你需要适应 DevOps，而不是相反。 DevOps 的目标是快、更快、最快: 提供快速反馈的小型迭代更改，最终减少在制品(Work In Progress，WIP)。 为提高安全性而进行的小型迭代变更符合这个模型。 你将优先考虑那些使得安全软件的交付优于新功能交付的事情，这通常是一项巨大的任务，以改变长期存在的“功能优先”的文化。 你需要调整需求和建议，使它们适合于流程，通常简化为小步骤，并提供足够的信息，使任务既可以自动化，又可以被监视。 你可以建议进行人工代码审计或模糊测试，只要你了解它们在流程中的适用位置，以及哪些可以发布哪些不能发布。 

培训: 我们的经验表明，使开发团队加快安全性的最佳方法之一是培训: 内部解释或演示、帮助应用程序安全的第三方专家、威胁建模、在线学习或各种商业课程。 历史的负面影响是成本，许多课程要花费数千美元。 你需要评估如何最好地利用你的资源——这个问题的答案通常包括为所有员工提供一些在线教学，选择参加课程的人，然后教同龄人。 邀请现场专家教学的费用可能很高，但是整个团队都可以参加培训。 

增加自己的支持: 如果没有帮助，安全团队根本无法扩展他们的知识。 这并不意味着会有数百名新的安全岗位的员工，而是意味着要委托开发人员帮助产品提高安全性。 安全团队通常很小，而且开发人员比例为100:1。 此外，安全人员在大多数开发会议上都不出席，因此他们在日常的敏捷活动中缺乏可见性。 为了帮助扩展安全团队的覆盖范围，看看是否可以让每个开发团队中的某个人——也就是所谓的“安全冠军”——充当安全倡导者。 这不仅有助于扩展安全团队的覆盖范围，还有助于扩展安全意识。 

帮助 DevOps 团队理解威胁: 大多数开发人员并不完全理解攻击者是如何攻击系统的，或者当代码或 SQL 注入攻击是可能出现的时候，这又意味着什么。 安全威胁的深度和广度超出了他们的经验，大多数公司不教授威胁建模。 OWASP Top 10是一个很好的指南，指出了困扰开发团队的代码缺陷类型，但是你应该将这些威胁映射回现实世界的示例，展示 SQL 注入攻击可能造成的损害，并解释 Heartbleed 类型的漏洞如何能够完全暴露客户凭证。 可以把这些现实世界中的用例看作是“震撼和敬畏” ，这对于帮助开发人员“理解它”大有帮助。 

对补救措施提出建议: 如果你的安全建议只是“加密数据”或“安装 WAF” ，那么这种建议是不够的。 通常情况下，开发人员和 IT 人员对于安全性的构成只有一个单一的想法，他们希望设置并忘记一个单一的工具。 帮助构建安全性程序的元素，包括代码内增强和支持工具。 教导他们如何帮助解决特定的威胁，并提供部署和策略设置方面的帮助。 过去，公司常常制作代码风格指南，教给年轻的开发人员正确编写的代码是什么样的。 通常情况下，这些资源都不是在线的。 考虑一个关于安全编码实践和其他参考资料的 wiki 页面，这些资料很容易被没有安全背景的人发现并且很容易阅读。 

帮助评估安全工具: 对于安全之外的人来说，充分理解安全工具的作用或工作方式是不寻常的。 因此，你可以通过两种方式提供帮助: 首先，帮助开发人员选择工具。 错误的概念到处都是，这不仅仅是因为供应商承诺的能力过高。 此外，对于开发人员来说，评估代码扫描器、活动监视器甚至补丁管理系统的有效性是不常见的。 作为顾问，你有责任帮助 DevOps 了解这些工具能够提供什么能力，以及在你的测试框架中适合什么。 当然，你可能无法评估 API 的质量，但是你可以判断一个产品在什么时候不能提供有意义的结果。 其次，你应该帮助定位开支，因为掌握资金的人并不总是清楚具体的工具如何解决安全性和遵从性要求。 你应该为满足业务需求的工具指定功能和报告要求。 

有优先级的提供帮助: 在我们的研究过程中，许多安全专家告诉我们，所有的漏洞看起来都像是高优先级的，区分一个对组织有影响的漏洞和一个没有影响的漏洞是非常困难的。 漏洞披露分析领域超出了开发人员的技能范围。 你需要帮助填补这个空白，因为并非每个漏洞都会带来真正的风险。 而且，安全人员长期以来都喜欢使用恐怖主义威胁等级，含糊地警告“严重风险”和“高威胁等级”。 如果不把威胁和可能的漏洞利用联系起来，不把漏洞利用对企业意味着什么说清楚，或者不知道如何解决和降低风险，这些警告都是没有价值的。 例如，你可以修复代码中一个关键的应用程序漏洞，对支持系统打补丁，如果不是关键的功能禁用则该功能，或者用 IDS 或防火墙进行阻止，甚至是用 WAF 或 RASP 技术进行过滤。 或者在漏洞利用实际上并不会损害业务的情况下，“什么都不做”反而是正确的答案。 而不是下意识的“天哪！ 现在就修复它! ” 我们在历史上看到过这样的反应—— 通常有几种选择来修复一个漏洞，所以向 DevOps 团队提出折衷方案可以让他们选择最适合的。

编写测试: DevOps 已经将一些操作和版本管理人员置于一个不舒服的位置，他们必须学习编写脚本，编写代码，并将他们的工作公开给大众评审。 它在短期内将人们推出他们的舒适区，但这是在中期内建立一个有凝聚力的团队的关键部分。 安全人员向团队贡献测试是完全可以接受的: 验证证书的扫描、检查已知的 SQL 注入攻击、定位漏洞的开源工具等等。 如果你对此感到担心，那么请帮助并集成单元测试和回归测试。 融合和迎合！ 要参加一个 DevOps 团队，其中自动化起着关键作用，你可能需要知道如何编写脚本或模板。 好消息是，你们的策略现在已经体现在环境的定义中。 不要害怕你不知道源代码控制或脚本的正确格式; 这是开发人员通常热衷于提供帮助的领域。 在将你的测试集成到构建和部署服务器之前，你可以在脚本编写方面学一些东西，但是你要做的不仅仅是宣扬安全性——你也可以做出贡献！ 

宣传: 你可以帮助开发团队的一个关键领域是了解公司和外部的策略需求。 正如 CVE 条目几乎不告诉你如何修复某个安全问题一样，内部安全和隐私策略执行对于开发团队来说常常是个谜。 开发者不能在谷歌上搜索这些答案，所以你可以提供自己作为顾问。 你至少应该像开发团队中的任何人一样理解遵从性、隐私、软件授权和安全策略，所以他们可能会感激你的帮助。