DevSecOps：一种不可抗拒的方式

我们能将DevOps进程中的安全完全自动化吗？或许办不到，但我们肯定能改进现有的标准。
安全是DevOps敏捷性的拦路石吗？
要回答这个问题，我们需要快速了解一下DevOps、QA和安全在自动化问题方面的区别。
对于像我们一样已经参与过传统AppSec活动前线如渗透测试和动态或静态代码分析的人而言，我们很容易发现所使用的传统工具和技术更多的是为瀑布式原生环境而非DevOps原生环境构建的。但对于从基础设施、网络或开发领域转向安全领域、并且从未运行过安全扫描的主管们而言，他们可能无法一眼看出将传统工具集和实践带入DevSecOps这个新的速度预期中所面临的挑战。
当今，很多安全主管都来自非安全领域，造成这种现象的很大一部分原因是安全专业人员的匮乏。要了解安全和非安全领域之间的区别，我们首先应该看下相较于其它工作而言，传统安全的结果和措施。了解之后我们就能培养出更多的同理心，并致力于改善这两个领域之间的协作。
DevOps、QA和安全之间的一个关键区别是，前两者的确定性更高，而安全并非如此。对于安全专业人员而言，判断风险或建议缓解风险方向的传统方法通常需要的是人类做出决策而非基于机器的动作。
下表很好地阐释了这一点：

 
在通常会被合规标准如SOC 2、HIPAA或PCI所要求的另外两个重要的AppSec活动即基础架构审查和威胁建模的案例中，安全的确定性更低，原因在于分析的结果可能是完全无法预测的且很大程度上取决于评估人员的背景。
用简单语言描述威胁
无需多言，自动化与以上类型的活动相差很远。我们所能做的就是不使用不必要的复杂的伪科学方法来评估风险（如DREAD方法），而是在一个简单的风险表中通过人人都懂的严重程序即“低”、“中”、“高”说明威胁的情况。
如果不理解这个简单的事实就会导致自我感觉良好并且预期设立错误。例如，来自网络领域的首席信息安全官可能会认为完全将安全自动化所需要的只是一款好的网络设备，而具有开发背景的首席信息安全官可能会认为写很多的代码就会让安全跟DevOps原生速度同步。虽然这两种方法都可能有助于加快形式更加确定的安全检查，但仅靠这些方法会导致做出正确决策时产生盲点。对于那些只依靠确定安全方法的首席信息执行官而言，当顶头上司首席执行官或首席信息官了解到他们将安全完全自动化的诺言永远无法兑现时，他们头顶的乌纱帽或将不保。
利用自动化为安全加速
难道我们就无法自动化安全并为安全加速吗？当然不是。作为安全工程师，我们能够而且应当寻找新方法来利用自动化和更加确定的安全方法。这些都不是新概念，在近几年来一直都很流行。就我个人而言，近三年来我一直都在谈论这些实践：第一次是在LASCON 2015会议上，主题是《传统AppSec需要如何改变？》；第二次是在AppSecCali 2016会议上，主题是《让安全敏捷化》；最近一次是在RSA 2017 DevOps会议上，主题是《为安全加速》。
如果采用正确的方法，那么信息安全就不会对DevOps实践产生太大的阻碍作用。为此，在跟主管讨论时，我们都应该考虑到某些必要安全实践的非确定性本质并且设立正确的预期。
就算安全被视作DevOps敏捷性的拦路石，那也是因为它在很多时候确实起到了阻碍作用。虽然不能将所有的人类投入自动化，但通过研究新方法确实能找到改进的机会。在这一方面，我希望人工智能和机器学习会更深入地渗透到安全领域。虽然这并不容易，但它们在入侵检测系统/入侵防御系统 (IDS/IPS) 中所取得的进步让我感到它们终将帮助传统AppSec活动实现自动化。