DevOps 中安全性的转变意味着思维方式的转变

很久以前，当我还是一个愚蠢的年轻 UNIX 系统管理员时（我现在只是其中一个），我在运行我们的备份系统的一台服务器上犯了一个非常严重的安全失误。 我不会详细说明，但它与 sudo 命令、文本编辑器和无知有关。

幸运的是，一位更有经验（坦率地说，更聪明）的系统管理员支持了我。 他们注意到了我的新程序，对其进行了调查......然后礼貌地把我拉到一边，解释我的错误。 然后他们花时间帮助我找到一个解决方案，既能为人们提供他们需要的自助服务功能，又能减少发生灾难的可能性。 在我自己编辑的、不可靠的记忆中，我很感激这些改进——无论是对我和我的配置而言。

这种分享、协作和无责故障排除的行为多年来一直伴随着我，我希望偶尔能够帮助某人解决他们的安全失误。  

沿着这些思路，在阅读Puppet 的 DevOps 状态报告时，你毫不惊讶地发现，当你将安全性尽早集成到软件交付生命周期中时，其结果就是——等待它的是——更好的安全性。

从报告来看，将安全性转移到软件生命周期中的优势显然在于将 DevOps 行为原则转移到安全团队中，就像将安全工具转移到管道中一样（如果不是更多的话）。

虽然更传统的安全操作实践侧重于测试和控制（大多数应用程序团队都会遇到收到工具生成的安全报告，其中显示需要解决的多个问题的情况），但基于 DevOps 原则构建的方法鼓励早期协作、共享和共同责任。

查看报告中的“改善安全态势”部分（从第 31 页开始），重要的是要认识到，与仅仅实施正确的控制和技术相比，在多大程度上依赖于将安全思维无摩擦地注入软件和基础设施的设计和构建中。

如果这些好处依赖于将安全专业人员的技能和思维方式共享并融入软件交付流程的核心，那么一些最显著的变化将是行为上的变化。

将安全团队早期纳入软件开发生命周期肯定需要他们进行适应，但这些变化必须是双向的。 虽然安全专业人员必须采用新的工作方式，并且可能要学会比现在更多地使用“开发”一词，但开发团队可能必须接受安灯线之道。

如果您还没有研究过安灯线及其在丰田首创的质量控制制造流程中的作用，那么这非常值得您花时间去了解。 有文章、学术论文、整本书，甚至高等教育课程涉及该主题。 但是在您放弃技术职业去攻读您一直承诺给自己的 MBA 学位之前，请先读完这篇文章，因为我认为有关安灯线的最重要事实既是最简单的，也是最难实现的。

当生产线上的工人拉动安灯绳以由于缺陷而停止生产时，他们的同事和管理团队做的第一件事就是冲过去感谢他们。 他们必须是真心这么做的。 拉动安灯绳被视为一件好事，因为这是朝着质量改进迈出的一步。 管理人员和同事们都很高兴生产线因问题而停止，因为这是一个改进的机会。

您的开发团队是否会感激安全团队发现缺陷并拉动（虚拟）绳索？ DevOps 团队能否学会像重视通过安全测试的构建或部署一样重视未通过安全测试的构建或部署？

有意向的企业主是否可以了解到，为了开发出优秀的软件，我们应该在构建越来越好的测试以在部署过程中发现问题之前发现问题的过程中寻找更频繁的测试失败？

这可能需要一段艰难的心理适应。

虽然我很感激当您读到这篇文章时，它已经进行了不可避免的编辑修正，但看到别人剖析您所创建的东西并不总是那么容易。 你的理性大脑知道它可以提供更好的产品，但你内心的黑猩猩只想挥动它的手臂。

因此，尽管这可能是一种难以接受的思维方式，但将安全性成功融入软件生命周期早期至关重要，而且比现有的事后审查和匆忙补救要好得多。

改变态度是另一个研究领域，但 IT 领域的领导者和从业者需要熟练掌握这一领域，尤其是在这个工作方式发生革命的时代。 这往往比仅仅采用新技术要困难得多。 如果您要成功地在安全性方面“左移”——本报告的数据表明您应该这样做——那么请在人为因素上花费与技术因素一样多的时间。