当前，DevOps尚未成为DevSecOps，因此DevOps不安全，很多人都在讨论它，但很少有企业真正掌握它。那么，是什么导致的DevSecOps采用率如此之低?

关于DevSecOps，总结来看，人们认知中的这5个误区，对采用DevSecOps并实施存在一定阻碍。

误区一：DevSecOps是由文化促成的。

人们通常认为DevSecOps是由文化促成的，但事实上，DevSecOps 是基于技术并由技术支持的，文化随之而来。那些将文化放在首位的企业往往会失败，因为在施行过程中需要有一定的AppSec基础。一些企业组织了DevSecOps团队，用DevOps采用的方法培训他们，高呼持续、快速的安全发布的口号，但最终一无所获。

如果缺少安全技术支持，就不可能有DevSecOps文化。如果企业还在做手动安全代码审查，肯定无法建立DevSecOps的速度文化。如果只有手动渗透测试则无法大规模构建安全文化。如果你没有诸如静态应用程序安全测试、动态应用程序安全测试、软件组成分析和web应用程序防火墙等技术，你就不会构建一个包含多个日常安全测试的文化。

技术是文化的基础。DevSecOps 是一种技术现象。所以，确保用正确的技术来领导公司，公司文化也会随之改变。

误区2：任何AppSec技术都可以与DevOps一起使用，使其成为DevSecOps。

这个误区导致DevOps专业人员选择了错误的AppSec技术，建立在前DevSecOps时代的“传统”AppSec技术，来将DevOps转变为DevSecOps。正是这种错误的操作，往往会导致结果令人失望。

事实上，只有专门设计的AppSec技术才能实现DevSecOps。传统的AppSec 技术并未涵盖成功执行DevSecOps所需的整个软件生命周期 (SLC)。大多数AppSec检查只在应用程序部署之前运行，偶尔也会在部署之后运行，这并不适合DevSecOps。这些传统技术需要专门的AppSec人工操作，包括安装、配置和操作。

另一个问题是，传统AppSec技术的运行速度比DevOps慢得多，需要数小时甚至数天的时间进行测试，而DevOps发布代码单位只需几秒或几分钟此外，传统的AppSec技术尚未构建为原生测试 API、单页应用程序和微服务。

所有这些考虑使得选择正确的、特别设计的AppSec技术来支持DevSecOps变得非常重要。

误区3：DevSecOps等于自动化。

人们认为沿着SLC的AppSec调用和执行必须是自动化的，因此AppSec技术将自动沿着持续集成/持续交付(CI/CD)过程运行，而没有AppSec自动化，DevSecOps是不可能的。事实上，自动化是必要的，但并非对所有AppSec技术都是必要的。

在CI/CD过程中自动化传统AppSec的集成应该是一个低(更)优先级，因为如前所述，它们很少被使用。自动化的主要主题应该是那些能够真正实现DevSecOps并在开发人员和操作专家手中有用的专门设计的技术。有了这些技术，应用程序的安全性测试一天可以进行十几次，在整个SLC中可以进行数百次。

误解4：DevSecOps等于向左转移。

向左转移已经成为大众认知，但这并不绝对。AppSec技术确实应该向左转移，开发人员应更多关注编码规范和安全，如静态代码分析。但它们也应该向右和中间移动，构建工程师需要CI/CD管道中间的安全性，而操作专业人员需要右侧的安全性。

误解 5：DevOps专业人员欢迎应用程序安全。

DevOps的首要任务是在预算内按时交付应用程序功能。下一个优先事项：确保质量和性能。安全是DevOps遥不可及的目标。由于AppSec技术很复杂，DevOps专业人员没有时间、技能或意愿来采用和操作AppSec技术，而这些努力使他们偏离了他们最初的目标。

DevOps的新AppSec应该是与应用程序架构无关的:它应该自动测试任何应用程序架构，无论是单页应用程序还是多页应用程序，微服务还是API。它应该被有意地构建为原生云和原生社区。AppSec不应该需要进行大量的入门和配置工作，也不应该需要定制登录/凭据处理程序或任何其他繁重的人工操作。它应该覆盖整个SLC。它应该能够测试任何业务增量，而不仅仅是特定的URL或IP地址。

随着对DevSecOps各部分测试工具的逐渐完善和更新，新的技术正在进入市场，留意这些新的技术和工具，可以帮助企业将DevOps转变为DevSecOps。

 

参读链接：

https://www.whitehatsec.com/blog/dont-let-these-five-myths-hinder-your-devsecops-adoption/