到目前为止，几乎所有 IT 人员都熟悉 DevOps 的概念及其联合开发和运营团队以帮助组织更快、更高效地创建更好的软件的承诺。但在代码频繁更改的世界中，攻击面和风险状况可能会同样迅速地发生变化。所以现在，新兴领域“SecDevOps”寻求利用 DevOps 方法将安全性直接融入开发和生产工作流程。一个额外的好处是有机会包含安全团队所要求的一些功能，但在瀑布式开发过程结束时，这些功能经常被放弃。
将 SecDevOps（有时称为“Rugged DevOps”或“security at speed”）视为一组最佳实践，旨在帮助组织将安全编码深入植入其 DevOps 开发和部署流程的核心。目标是在工作流程中自动执行安全编码和安全测试和修复，使安全软件成为 DevOps 方法的固有结果。
除了合并运营和开发团队之外，DevOps 还旨在通过自动化开发来消除人为错误，从而最大限度地减少编码错误和遗漏。当确实发生错误时，DevOps 可帮助组织快速失败并更快地修复任何损坏。这降低了与软件创新相关的风险，并使持续部署更加可行。事实上，使用 DevOps，“高绩效组织部署代码的频率是低绩效组织的 30 倍，故障率比低绩效组织低 50%，” 来自 Puppet Labs 的 2014 年 DevOps 状态报告 说。但在许多情况下， 根据 CloudWedge 和其他人的说法，传统的 DevOps 并没有解决传统安全模型的缺点。
SecDevOps 与 DevOps
SecDevOps 寻求将安全性嵌入到开发过程中，就像 DevOps 对操作所做的那样。经典 DevOps 旨在自动化软件开发，加速和磨练工艺以满足运营需求，以获得可立即在生产中运行的代码。相比之下，SecDevOps 将开发的安全编码组件自动化，以满足安全团队建立和维护在生产中立即安全的软件的需求。
SecDevOps 现在很热门，有大量的新闻报道、它自己的 Twitter 标签 （#SecDevOps ），甚至还有一个 新的子 Reddit 。公司安全团队毫不掩饰地表示他们有兴趣将开发和开发人员工具和技能作为 DevOps 的一部分来保护编码。也许这就是为什么， 根据 CSO Online 的 说法 ，SecDevOps 已经成为信息安全人员的顶级安全策略驱动程序。
但 SecDevOps 并非一蹴而就。近 15 年来，安全和开发团队一直试图融合。在最近的推动中， DevOps 大师 Gene Kim 和其他人敦促 DevOps 包括 SecDevOps。与安全相关的开发测试工具和框架初创公司正在获得知名度，提供旨在将安全集成到 DevOps 中的产品。与此同时，大大小小的企业都在努力将 SecDevOps 添加到他们现有的开发流程中。
为什么要对 SecDevOps 大惊小怪？
据 CSO Online 称， 引起关注的原因之一是信息安全失误的代价正变得非常高昂，仅在美国每年就高达数千亿美元。然而，尽管企业花费大量资金来对抗信息攻击者， 但 TechTarget 报告 称，与其他主要安全措施相比，他们在软件供应链安全方面的花费要少得多。
DevOps 为这种安全情况提供了一种高度直观的解决方案。既然 DevOps 展示了修复软件几乎所有其他问题的承诺，为什么不利用它来解决本地自动化解决方案的安全问题呢？或者换个角度来看，为什么一开始就采用 DevOps 只是为了满足安全要求而在最后一刻进行更改？
将 SecDevOps 连接到 DevOps
要成功地将 SecDevOps 融入经典的 DevOps 开发流程，关键是在必要/可能的情况下尽早添加风险建模、威胁评估和渗透测试。 SecDevOps 从业者寻找最舒适和方便的地方将安全问题注入现有的开发工作流程。这有助于在最早的入口点捕获并消除安全漏洞，同时在漏洞首次出现时提供反馈。
要将 SecDevOps 挂接到您的 部署 过程中，请确保风险建模、威胁评估和渗透测试再次出现在二进制编译的第一个实例中。任何可执行代码最终都可以部署，因此应该从那时起直到部署之前进行测试。这包括进入预生产暂存环境之前和之后。 （ 安全情报 提供了关于将安全思想融入每个开发阶段的额外提示。）
DevOps 正在重塑软件开发实施的过程，但迄今为止，安全性在很大程度上仍然是一种附加的、事后的考虑。在 DevOps 流程中包含安全性并不总是那么容易，需要开发人员和运营人员从一开始就更加关注安全性，即使安全专家面临 DevOps 风格的精益/敏捷/自动化文化转变。但 SecDevOps 承诺的更快创建更安全的应用程序的回报似乎足以吸引越来越多的组织这样做。
延伸阅读：
- Cognitive Dissidents ，Josh Corman 的安全博客
- OWASP Top 10 项目
挂锁和 齿轮 图片由 Shutterstock.com 提供。
本文最初出现在 Stevan Arychuk 的 New Relic 博客上
