众所周知，事物的发展总是随着客观现实的变化而变化的。
随着网络安全的发展，作为一个开发，总是能听到一些安全开发的理念，从 SDL、DevOps、DevSecOps、S-SDLC、瀑布模型、敏捷开发等等。
这些都是什么呢？什么是适合我的呢？该怎么做呢？
接下来我们先不介绍这些具体的名称的含义，先来举几个小例子。
小型公司：我只有开发
假如你成立了一个软件公司 A，然后现在接到了客户的需求，要你开发一套 OA 系统，但是由于你的公司才刚刚成立，手里的资金也不多，所以目前也就只能招聘 5 名开发来帮你写这个 OA 系统了。
经过分析讨论客户的具体要求和功能，你们选择了合适的语言、框架、数据库等等这些技术来设计和编写这个 OA 软件，然后经过 1 年的时间，这个 OA 系统终于写好了，可以交给客户使用了，但是客户很关心一件事，这个系统的安全性怎么样呢？
为了向客户证明系统的安全性，你只好找到当地的一家知名的安全公司 B，给你们的 OA 系统做了渗透测试和安全评估，确实也发现了一些问题，经过修复你们解决了这些问题，然后就可以把 OA 交付给了客户使用了，你们把 OA 系统部署在了客户机房里面了。
但是客户公司没人懂软件，而且你们合同里也写了需要保证软件的正常运行和一些简单的修改，时不时软件和服务器确实会出一些小毛病，你也挺忙的，不能总是往客户那里跑吧，所以你又招了一名运维直接派到客户那里去了，帮客户维护你们的系统。
中型公司：开发、安全、运维团队
经过几年的发展，你们公司已经发展成了一个中型的公司，有好几个客户找你们开发系统了，你扩招了 20 个开发。
在回顾这几年的发展时，你注意到在和安全公司 B 的合作中，一次渗透测试和安全评估的费用也是比较高的，所以你都是开发完了系统才进行的测试，这就导致了很多问题，比如有一次发现了重大的安全漏洞，需要重构一个重要的模块，导致足足比约定的系统交付时间推迟了一个月。还有派去各个公司的运维人员在管理上、沟通上、技术上、成本上也都有各种问题。
所以你决定招 2 个人组建安全团队。
这样一来开发、安全、运维之间的合作就比较方便了，开发人员每写完一个模块或者一个功能点都可以直接交给安全团队去测试，安全团队也可以负责整个系统的备案、等保、数保、通保等等。
而且你也决定招 2 个人组建运维团队。
你将所有你们开发的系统都部署到自己的机房里，然后交给运维团队去维护，这样可以大大节省人员的开支，还可以加强对各个服务器的管控、缩减安全事件的响应时间等等。
大型公司：项目组 + 自动化
随着你们开发的系统得到大多数客户的好评，还有某些通用功能的重复，你决定将自己的好几个软件合并，变成一个云服务平台，客户直接租用你们的服务，而不是购买你们的系统了。但这也导致了软件的复杂性和工作量都呈几何级别的扩增，原本的组织人员架构也不适应这种变化了。
你把开发、安全、运维拆分一部分人员出来，专门成立了一个服务平台组，负责这个服务平台的建设。因为是在线的平台，所以系统的一些小改动用户基本是无感的，为了和同行的竞争，所以你们加快了新功能的开发速度、旧功能的使用体验改造等等。这也导致你们的发版频率有的非常大的提升，以前可能是半年或者一年才发布一个版本，现在甚至已经达到了一周一个版本的程度。
这就多出来了很多的工作量，而且这些工作还都是重复性的，所以你们迫切需要自动化的去完成这些工作，你们为此引入了 CI 工具 jenkins、项目管理 Jira、代码质量检测 SonarQube、部署平台 kubernetes 等等诸如此类的工具。
安全挑战：角色融合
随着安全需求的提高、工具的复杂性变高、人员数量增多，各种新的问题又冒了出来：人员都太各司其职了，虽然各司其职是好事，但是也会阻碍沟通的效率和处理问题的速度。
虽然你把项目里所有的人员包括研发、安全、运维都放在一个办公室里了，但是他们都还是有着自己的身份标签，开发就是开发、安全就是安全、运维就是运维，开发不懂安全和运维，也不想管安全和运维的事情，其他人也都是这么觉得的。
你很纳闷，明明现在自动化程度已经很高了，为什么有的事情解决起来还是那么慢呢？比如某天构建发版的时候构建不通过，因为系统发现了一个 XSS 注入漏洞，然后安全人员跟开发说需要修复，位置在这某句代码、然后需要过滤用户的输入，比如 <img onerror=alert(1)> 这种的都要过滤，经过几次反复拉扯又过滤了好几种形式的语句，又编码了输出、设置了 CSP 等等。导致发布延期了一周。但是作为一个全局视角的你发现，其实开发用的框架本来就带 XSS 过滤的能力，只需要在配置里打开就行了。经过这个事件你发现，安全人员完全不懂开发，甚至开发用的什么语言、什么框架都不知道。开发也是一点安全都不知道，明明开发框架里都写了，可以打开设置过滤 XSS ，因为自己没接触过这些名词，学习框架的时候没注意到直接忽略了。
这就又引申出了新的概念，一个人员不能只做自己知道的事情，比如作为开发，80% 的知识储备是开发知识，那还要至少再学习 10% 的安全知识，了解下 AWVS、SonarQube 、XSS、SQLi 这些都是什么意思，至少开会的时候能听懂是什么。也要了解 10% 的运维知识等等。作为一个安全，了解点开发用的语言、框架等的文档、代码都有哪些模块、中间件都有什么，不要求你动手，现阶段至少要明白这些东西都代表什么，开会的时候能参与进去等等。
总结
为什么软件安全会向着这个方向发展呢，因为在软件应用生命周期中，修复漏洞的成本随着发现漏洞阶段的进程呈几何级数增长。传统的漏洞检测方法通常只能在业务系统开发完成后才能介入，这导致漏洞的修复成本高昂。甚至很多漏洞在安全事件发生后，才会被发现及修正。
下面是一些大公司的 DevSecOps 实践的分享：
大概明白这些内容之后，再去查询前面那些所不知道的名词，就容易理解的多了
PS：人数这些数字是我随便写的，没有经过准确的思考，不太懂运维，所以运维的内容比较少。
