为什么安全和工程不相处

Palo Alto Networks正在认真对待云安全，购买BridgeCrew，它侧重于作为代码安全性的基础设施。这是一个扩展的市场，随着更多公司使用Terraform和云形成来管理他们的云配置。随着组织变得更复杂的云用户，将继续出现新的安全需求。

至少，我的所有深度潜入云安全都没有徒劳！

此外，Solarwinds正在责备实习生的安全问题。严重地？！这是这本书中最古老的伎俩......来吧，原创性在哪里！同样，另一个原因传统安全球员在这一天和年龄不能跟上。

我不知道每周有多少次听到“Devsecops”空间中的公司。我的第一个问题几乎总是“你需要安全和开发人员是否协作部署？”如果答案是肯定的，那将是一个销售周期长的GTM战斗。但为什么？

让我们说出每个人都不想说的：安全和工程并不意味着一起工作，他们不想一起工作。

所以，不要迫使他们一起工作！停止开发需要Devops和Security以共同使用的产品。致董事会成员和C-Suite，停止强迫您的Devops和安全领导者弄清楚如何共同努力。这是浪费时间！

为什么不能安全和工程相处？在某些方面，它是组织和C-Suite的错，并且在某些方面，它只是市场的方式。在高水平，他们的矛盾的目标不会激励他们合作。我有点暗示了一些与我的文章有关为什么开发人员不关心安全性以及安全性需要强迫开发人员做安全性的篇章。这种关系只是合作。事实上，我认为云提供商不关心安全性。

这种紧张的来源是什么？这很简单。开发人员是核心业务的一部分，安全性是一个成本中心。他们基本上不同的目标。

开发人员希望在产品上工作，而不是安全性。产品推动收入增长，同时安全防止收入损失。风险奖励力学不排队。

安全性希望可见于Devops工作流程，但Devops不希望您访问权限，因为他们担心安全性会弄乱产品。这是一个有效的问题，因为担保不了解产品优先事项，因为它不是他们的工作要理解。

Devops是关于速度和效率，而安全性是关于风险缓解的，这是固有的效率低下。

这是张力！ Devops和Security有没有对齐的议程，所以在一起工作的激励是什么？

为什么现在发生这种紧张？在云之前，它部署了基础架构而不是开发人员。它和安全性有很好的关系。你可能已经猜到了它。他们都彼此了解，因为它们都是成本中心。

在某种程度上，这就是为什么我相信传统的安全公司所拥有，并将继续陷入云安全性。他们假设安全性与它所做的Devops具有与Devops相同的关系，但没有什么可以进一步来自真相。传统的安全公司必须获得云安全策略而不是有机开发它并不奇怪。产品和GTM假设安全和基础设施之间的强烈连接，云安全性不存在。

我可以永远谈论云如何改变技术，一般而言。如果您对学习这些变化有兴趣，我会鼓励您阅读我的合作伙伴Tyler Jewell的开发者LED景观。

基础架构驱动器的变化在安全需求中变化。但是，云创造了一个有趣的变化。它与产品进行了深入捆绑的基础设施，从成本中心转向一系列业务。例如，公司正在花费大量的时间和金钱现代化数据基础架构，因为它们对其产品至关重要。就在安全性，我们看到Sentinelone购买Scalyr和Crowdstrike购买Humio以使其后端现代化。雪花在超过70b中没有惊喜，并且具有如此高的净保留率。数据基础架构只是对产品的基础设施的一个示例。这种对基础设施的重点是由移动到SaaS的运动驱动。公司目前正在控制其产品运行的基础设施，并且该基础设施的性能是一个重要的分化点。

在一个基础架构被视为产品的核心组件的世界中，安全产品的后果是什么？

我认为近期近期的最成功的云安全项目将提供安全性，以便在Devops工作流程中的可见性，如CI / CD和云，而无需从Devops任何协作。例如，像ORCA和WIZ这样的公司可以在没有代理的情况下做漏洞管理，云姿势管理和云工作负载保护，因此不需要合作。

当然，我不认为这种动态将永远持续下去。市场最终将转移，以便基础设施和安全性都是产品的重要组成部分，因此不再成本为成本中心，而是商业线条。事实上，我们看到某些产品已经在某些产品中等班次，如视频会议，其中加密是一个关键功能。因此，新的安全产品和GTM将出现。

但是，目前，我们无法改变市场，但符合他们的地方。所以，真的，停止迫使安全和工程一起工作！