2012年，Gartner通过一份研究报告“DevOpsSec:Creating the Agile Triangle.”提出了DevSecOps的概念。
在这份研究报告中，确定了信息安全专业人员需要积极参与DevOps计划并忠实于DevOps的精神，拥抱其团队合作、协调、敏捷和共同责任的理念。也即是，完全遵循DevOps的思想，将安全无缝集成到其中，使之升级成为DevSecOps。
一个对DevSecOps最简单直观的图示如下图：
这一安全研发体系的概念和实践特别是最近几年越发被业界所重视，谷歌趋势可以看到关注度的增加。
接下来的问题就变成了：“如何实现DevSecOps？”
快速迭代开发和安全能力是两个相互博弈的因素，拿编码环节来说，持续的快速构建也意味着需要快速的产生代码，而如何快速的产生安全的代码变的越发重要。在开发人员能力短期无法质变（或不停的有人力交接或新人加入等）时，鱼和熊掌看起来是不可能兼得的。
用一个更通俗的话说就是，当前云环境下的基础安全攻防问题，95%以上都是因为不恰当的配置方式以及错误使用了不安全的代码导致的，例如：
- 在云服务器上安装了sqlserver数据库服务器，使用了sa默认密码、或者是弱口令，并且将端口开放到公网可访问。
- 配置了sshd密码登录，同时允许root直接登录，并且将ssh端口开放到公网可访问。
- 在云服务器上安装了tomcat服务器，并且部署了存在漏洞的struts2应用。
- 在云服务器上安装了lamp服务器，并且部署了存在漏洞的dedecms应用。
这些不恰当的配置方式以及不安全的代码，是导致批量化低门槛入侵的根本原因之一。
为了“缓解”这些问题，业内厂商给出了一些“补丁式”的缓解方案，典型的比如：
- 通过实时对进程日志进行审计以及关联分析，发现当前系统存在的入侵行为
- 通过实时对网络行为进行聚合分析，发现当前系统存在的暴力破解和异常登录，并且对攻击者行为进行阻断实现防御能力
- 通过oval扫描、cms、jar包文件扫描，检测网站代码中存在漏洞，并提供一站式修复方案
这种“补丁式方案”从总体上可以取得较好的效果，但是也存在一个比较明显的问题，即“检测和防御总是滞后于漏洞和攻击”，防御者被迫处于攻防博弈的滞后者位置，新的漏洞总是不断被提出，新的攻击方式总是不断出现。
而我们谈到的0day/nday监控，更多时候就像是“地震预警”，作为防御方，能做到的极限就是，在事件发生的第一时间进行响应，然后进行紧急救火。
为了解决这个矛盾问题，业界提出了【默认安全（Secure by Default）】的理念，通俗地说就是【IT组件框架化、云产品化，将原本涉及基础系统层面上的逻辑封装到一个高层的黑盒中】。
通过提供默认安全的开发框架或者默认安全的组件可能很好的防止犯低级错误，比如搞Web开发的同学肯定知道，一些新的开发框架中都内置了一些安全机制或者安全操作库，比如得益于框架内置的anti-csrftoken安全机制，你在一个基于CodeIgniter框架并且打开了该项配置的应用中可能很难找到CSRF漏洞。再比如当你使用Go或Rust语言构建系统时，基本上也杜绝掉了C/C++中常见的缓冲区漏洞及攻击，这是语言特性中默认安全原则的体现。
当然，默认安全的原则并不仅仅限于代码，比如：
- Web接入层上默认覆盖的WAF
- 默认安全配置的云/容器/数据库/缓存等基础系统和服务
- 统一的登录鉴权认证服务
- KMS（密钥管理系统）
- 保护关键数据的票据系统
- 零信任（Zero Trust）架构
- Pam登录统一管控
- 堡垒机
- 运行时应用自我保护（RASP，Runtime Application Self-Protection）技术
都是默认安全的很好实践。这也要求安全团队要参与到整个系统架构、基础设施等的建设中。反过来也会要求更多的组织架构保障以及安全与研发团队之间的沟通协作能力。
可以印证这个小趋势的一个现象是，国外的IT技术设施普遍更加框架化，很多安全功能都默认集成在里面，因此导致国外的IT系统面临的WEB基础安全问题（例如webshell）会相对较少。
可以预见到的是，随着国内云厂商的逐渐成熟，推出越来越多的安全的云产品、docker化、serverless、fass的推广，传统基础安全问题会逐渐收敛，甚至可能在将来5年后完全消失。
当时，这并不意味着安全问题会消失，安全攻防是人和人之间的对抗，安全对抗是永远存在的，只是对抗的战场和形式会发生变化，例如针对docker的溢出和提权攻击、针对api接口的业务层面的攻击等、针对基础设施本身的漏洞攻击（例如SaltStack）、甚至面向客户本身的toC的攻击也可能会出现。
Relevant Link:
https://mp.weixin.qq.com/s/_jBmFdtyXY5D_YrrTUP1iQ