任何在软件生产中工作过的人都可能意识到在考虑安全因素时可能出现的紧张关系，主要是在开发人员和审查其代码的安全专家之间。

在过去，开发团队尽可能晚地发布代码，故意缩短安全大师检查漏洞的时间，这并不罕见--毕竟，如果发生什么问题，这就会延迟发布，而且人们已经渴望继续前进，开始建立下一个令人敬畏的功能。然而，这最终产生了负面影响，因为当代码最终被检查时--有时是在外部漏洞已经发生之后--代码仍然会反弹到开发人员那里，他们的软件宝贝仍然被安全团队称为丑陋的，他们不得不放下一切去热修复他们几个月前最后接触的代码。

这种功能障碍今天仍在继续，但有一个巨大的问题：正在开发的代码要多得多，一旦发生数据泄露，社会就会面临更大的风险。我们不再有时间继续打这场古老的战役，在2020年，是时候我们都加入到反对坏人的同一阵营了。

我们必须达到这样一个阶段：安全被视为整个组织和整个SDLC的共同责任。当你致力于建立一个全面的、高度支持的DevSecOps环境时，这当然是可能的。更重要的是，当你用正确的培训和工具点燃开发团队的安全之火时，他们就会成为一股强大的力量，不仅可以压制bug，还可以为那些长期以来被分散的安全专家减轻负担。

我希望你能观看我最新的网络研讨会之一，如何将 "Sec "放入DevOps。

这是AllTheTalks24小时峰会活动的一部分，它深入探讨了。

• 为什么旧的开发方法学使安全最佳实践变得如此困难
• 为什么DevSecOps是阻止常见安全漏洞的最新游戏规则？
• 安全作为一种共同的责任在一个组织中是什么样子的
• 你如何能够让开发人员有信心地发送安全代码，而不牺牲他们所喜爱的东西（提示：是建立令人敬畏的功能）。

在那里见到你!