当前，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变得非常重要。
人们认为沿着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/
