安全的生命周期不是开发人员的生命周期

应用安全公司Enso Security的首席架构师以及联合创始人，Chen Gour-Arie发现了创业的一个重要组成部分，即反思个人发展以及行业的演变。2008年，PCI-DSS成为了以色列企业不可或缺的业务元素。那时，他参与了许多最早的认证流程，也见证了许多公司在合规性方面作出的努力。

Chen的主要职务涉及与应用相关的PCI部分，比如渗透测试。一天下午，Chen坐在以色列一家最大的医疗保健供应商的办公室里，回忆起曾经审查过一份冗长且似乎永无止境的问题清单，最后非但没有解决问题，反而其团队变得更加困惑。最后离开办公室的时候，剩下的问题比答案还要多，也并没有获得任何的见解或者有用的信息。

通过这次经历，Chen更加清楚地明白了一件事：安全标准所规定的内容对于企业来说是不可行的。不仅是在2008年，即使在今天它们也仍是不现实的。例如，PCI-DSS标准需要全面地收集数据，并对范围内的资产进行多学科的评估。业界花费了多年的时间才找到了满足PCI-DSS标准的合适策略，即隔离PCI环境。

一个流行词诞生了

同一时间，软件开发安全生命周期(SSDLC)成为了业界的流行词，而这并非巧合。要将安全整合到开发的每个阶段中，其前提是：从一开始就确保安全团队的参与，以便最大限度地避免发生错误并保护开发过程。由于云迁移的增加以及移动应用的广泛应用，SSDLC成为了越来越多企业的首选。它甚至在DevOps大展拳脚后，仍然存活了下来。如今SSDLC已经转变为我们今天所用的持续交付-操作循环。当隐私保护计划如火如荼地进行时，我们再次见证了企业掌握控制标准(如GDPR)是多么的困难。然而这一次，缩小范围并不是一个选择。突然间，许多企业在努力满足新条例要求的时候，都直接受到了由于糟糕的设计和安全负债而造成的影响。

对于那些二十年来一直在“挠痒痒”和“戳应用”的人来说，这并不奇怪。尽管初衷是好的，但是在所有项目的每个阶段都实现安全性几乎是不可能的，并且开发出对高级黑客(和渗透测试人员)有弹性的应用也变得越来越困难。说实话，开发出没有bug并且不会宕机的应用是极具挑战性的，所以监管者以及整个行业的期望都必须得到调整。

简单来讲，企业缺乏足够的人力资源来处理安全问题，而开发人员又过于忙碌而无暇顾及安全问题。无论是否令人感到惊讶，这个缺陷都体现出安全人员和开发人员之间关系的失调。

进入大脑

精英黑客，比如Solarwinds攻击的幕后黑手，进入了开发者的思维，利用软件开发中的弱点，进行了一个复杂的操作。入侵应用其实就是寻找开发人员必然会犯的错误。

理想情况下，通过适当的培训，有效的内部沟通，注重安全性的设计以及严格的测试流程，这些错误都能被很好地控制，从而降低其所带来的不良影响。但是，众所周知，现实情况并非如此，现实中企业并非都能实施严格的防御。

许多开发者不考虑安全。他们考虑的是特性、截止日期、延展性和速度。开发者考虑生产事故以及宕机时间方面的事。但最重要的是，开发者是创造者，他们需要经验，获取客户真实的意图，并且主动做决定来使安全融入到他们的创新领域。

安全专家经常低估开发人员为保护应用而作出的努力。开发人员一边不断实现应对错误和失败的不同层次的弹性，一边不断受到来自各个方面的困扰。而这些困扰多来自于产品，客户成功，市场营销和组织中所有利益相关者的无数需求。

狼来了

Chen曾经有过一个项目，需要为一个拥有一千名开发人员的公司开发一个可扩展性的程序。经过一个繁琐的过程以及数小时的讨论后，其团队终于达成了一个安全服务级别协议。一个首席工程师笑着对Chen说：“你看，安全就喜欢中心舞台。”他立刻明白过来：不论是无意还是有意，安全总是扮演着狼来了的角色。

另一方面，当你向开发人员展示零日漏洞时，所有人都会大叫：“救火!”一定要扑灭它。所以，无论开发人员是否相信，有些脆弱性都已经对业务连续性构成了真实的潜在威胁。也就是说，无论他们承不承认，他们都需要安全感。

所以，底线结论就是：安全生命周期不是开发人员生命周期。像威胁建模和渗透测试等活动对安全级别至关重要，但是它们也需要许多难以扩展的资源。

尤其是在SSDLC模型上运行时，管理开销会降低你的速度。另一方面，尽管利用单纯的应用安全测试自动化来收集关于软件定量化的反馈是一个高效的策略。但是，没有严格的管理以及全面的安全文化，它也不太可能会被企业采用。

安全性与软件开发的生命周期保持一致，但是也超越了它。

尽管应用安全不断挑战包括传统应用在内的所有应用，而这一点仍然成立。应用安全跨越代码本身来评估软件成分，CI管道以及执行时间。无论开发是否在内部进行，应用安全都会评估开发人员作出的修改，也会持续关注新的攻击和漏洞。

应用安全有自己的生命周期，且与开发人员的不同。

点评

尽管安全对于软件的开发的不可或缺的，但几乎所有的软件开发过程都会受到安全性的“阻碍”。安全标准对于开发团队往往是不可行的。这大多是由于安全团队不够了解应用安全和企业面临的风险波动之间的关联。加强开发团队与安全团队的沟通与协作，使其步调一致，才能更好地实现技术的进步以及安全风险的管控。