DevOps和安全性–如何在软件流程中建立更多的阶段

在DevOps流程中或之后将安全性作为一个阶段来进行，会错过安全性可以在代码，云和基础结构之间提供的更大范围的方法。相反，值得花时间在开发过程中建立安全性。

没有人愿意制造不安全的软件。我们想要制作一款功能强大的软件，可以满足需要，实现目标并做到优雅。但是，随着时间的压力，急于提供更新的信息以及持续引起关注的喧嚣，实现这一目标可能会更加困难。对于开发人员来说，始终将工作代码放在首位。

这错过了开发人员面临的最大挑战之一-确保交付的代码是安全的。拥有安全软件的愿望与交付软件的责任之间存在明显的差异。例如，MongoDB在2020年初宣布了对安全性的研究，在该研究中，对开发人员的新应用方法进行了调查。92％的开发人员表示，他们在开发应用程序时会采取适当的预防措施，而47％的开发人员则认为，在购买新解决方案时，数据安全是重中之重。

但是，只有29％的开发人员同意，在自己软件的安全性方面，他们负有最大的责任。接受调查的人员则以IT安全团队，运营部门或其他专家为负责。但是，还有谁最适合从一开始就实现安全性，从而不必在生产中解决问题或在软件开发生命周期（SDLC）的后期进行处理？

安全性–固定式还是内置式？

在此背后，软件开发人员必须对方法进行根本性的考虑，以解决安全问题。一方面，您认为安全是在产品投入生产之前，SDLC必须经历的一个阶段。这涉及检查代码，应用程序和基础结构，然后再投入生产。如果出现任何问题，则可以将其传递回去修复。

另一方面，您认为应将安全性嵌入整个SDLC中。在整个开发，编码，测试和实施阶段，开发人员都可以使用安全工具，而不是要经历的阶段。这并不意味着向团队提供工具，而是如何将安全性真正地集成到那些开发人员的工作流和流程中。

对于所涉及的开发人员，两种方法都应该产生相同的结果–安全的代码和应用程序可以承受严苛的工作寿命。但是，他们到达该目的地的路线却大不相同。

在DevOps流程中或之后将安全性作为一个阶段来进行，会错过安全性可以在代码，云和基础结构之间提供的更大范围的方法。它也可能无法顺应开发人员想要利用的新平台，例如软件容器。相反，它的作用类似于阻止或阻止软件发布的传统安全功能方法。尽管可以理解，但它并不是最协作的方法，由于目标不一致，甚至可以颠覆它。

相反，值得花时间在开发过程中建立安全性。这涉及将安全工具直接集成到开发人员已经具备的持续集成和持续交付管道中。这可以通过使用Jenkins，Bamboo或Circle CI等工具中提供的API和插件架构，然后在创建任何软件资产时使用这些工具来实现。更重要的是，这些工具实际上对开发人员或测试人员本身是不可见的；他们在自己喜欢的环境中继续工作，并且仅使用结果数据。

采取协作方式来实现安全性

在开发过程中管理安全最佳实践和漏洞时，这一点尤其重要。OWASP和ISC2等组织提供了许多最佳实践框架，可用于提高软件质量，而软件漏洞工具可用于自动扫描软件组件或代码中的任何问题。通过使过程自动化并将其转换为API调用，开发人员可以在SDLC期间的任何时候自行执行该过程。

如果出现问题，则可以自动将其标记出来并重新添加到队列中，以供开发人员进行调查和修复。这使安全的代码和应用程序开发成为SDLC的标准部分，而不是每个人都在为完成交付而费力的阶段。

这种变化也更有利于团队之间的协作。由于安全团队为开发人员提供工具和支持，因此它们不会成功部署。相反，他们是值得信赖的同事，可以帮助加快项目进度并消除障碍。理想情况下，应将安全团队嵌入开发和部署中，以努力理解并实现相同的目标。

随着时间的流逝，安全性应该始终是整个SDLC的一部分，并在此过程中尽可能向左转移。这可以帮助所有人实现交付安全代码和应用程序的目标。它不是每个人的问题，而是每个人的责任。通过采取正确的方法并从一开始就建立安全性，参与交付软件的每个人都可以从一开始就发挥自己的作用。