基于瀑布型模型而言的SDL落地流程建设的一些胡言乱语

首先要讨论SDL，你脱离了公司当前的软件开发模型就是脱离了实际能够落地的基本原则，在往空中楼阁上面走，因此了解自己公司当前的软件开发模型及软件开发流程是必须得准备工作。不要相信非技术部门的领导或者某一单一技术部门领导跟你说的软件开发模型？为啥？因为不仅安全圈子里面混子多，整个互联网圈子里面的混子也很多，明明是瀑布型的软件开发模型，他能吹成是DevSecOps，不为啥，他不吹，他怎么证明自己的价值？
那么什么是瀑布式模型呢？什么是敏捷呢？
瀑布型

敏捷型

但是，我们常见在企业里面碰到的是什么类型呢？一般是这种：

你说这种是敏捷？还是瀑布？都不对，这瀑布1.1版，而不是敏捷-1版。所以想做SDL的宝子们，最好实际去调研。我总结下来大致有五个不同：
方式不同：瀑布采用的线性开发方式，敏捷是灵活开发方式。
人员不同：瀑布角色明确专人专责，敏捷角色灵活一人多岗。
成本不同：瀑布基于范围、计划人力定预算跟周期，敏捷基于配置管理定成本。
文档不同：瀑布的各阶段文档输出很明确，但敏捷由于采用快速迭代只会对重要节点进行文档规范。
时间不同：瀑布项目时间预期可见，敏捷时间灵活跟需求来定。
需要注意一点不管是瀑布还是敏捷，他们应用的场景是不同，因此其实没有好坏之分，只有能不能适应企业的需求。那么，调研这些有啥用呢？还是上面说的，混子误事，一开始你调研都不调研，摸排都不摸排，你直接就掉坑里爬不出来了还想往后推？
聊完区别，我们聊下瀑布型SDL，当前瀑布型的SDL一般遵循的是微软那套方法，见图：

但是很多师傅是不是看到这张图觉得会了，但是实际去做会摸不着头脑，为啥？因为这是个框架类的东西，你落地其实不行，东西太多。那么实际自己去落地怎么做呢？画了个简图，看下大致流程：

一、        培训：
培训的目的不是走个形式，培训的目的其实是告知大家我有这套东西能够去管控相关风险。但是我们同时也得考虑受众面的不同，挑选我们的培训题材，大致我总结下来就是意识、制度、合规。为啥不放代码安全培训，安全测试培训？因为你在做SDL之前不必给自己挖坑，除非你D大背景硬。
二、        评估：
评估我看很多人就局限于GB/T20984的方法，然后很多公众号们23年了还在只是做安全状态的风险评估，拜托啦各位，23年了，安全评估有很多方法，数据安全风险评估，个人隐私安全风险评估这些都是可以加到我们评估环节的，而且也是符合我们当前实际业务开展的需求，这些都是可以格局打开的东西，为啥要局限在另起一个架构，然后在弄一个方法，有必要？
三、        需求：
需求大多数公司其实都是销售或者产品经理进行市场反馈和市场调研，有些是合理诉求，有些其实是违规需求，最终输出整理的需求报告提交给后端，一定是复杂且庞大的，而这种情况下，怎么做？两部分，融入。一部分是合规，这应该大多数安全部门是可以做的，这方面其实就是规范市场跟产品提的需求基础，你需求再大能大过法律？另一部分就是质量，质量是规范技术侧的，你技术在牛能牛过监管？不必要把自己安全部门单独拎出来给人集火，毕竟还得接着混呢，咱们是辅助部门搞清楚自己的定位。
四、        设计：
设计其实分成两部分，你不可避免其实是要接触到产品及研发的架构师。那么你必须要做的就是区分你面向的对象，举个简单例子，你拿安全架构设计的东西去跟产品讲，你看产品理不理你，或者你上来不管三七二十一，就直接丢个安全产品设计要求，你看产品理不理你？最后成什么状态？你写的东西都是一堆吃灰的文档。怎么做？调查自己公司已经发生的安全事件，进行总结；调查自己所在的行业，所颁布的相关标准。调查自己所在公司的市场定位及面向客户，去跟产品，去跟架构一起去制定相应的基线，然后去建模，深度参与进去，你才能落地。
五、        开发：
可以看到，我没提什么代码安全培训，也没提去搞什么开发的安全架构这些东西。为啥？因为你安全的，你能比开发专业？很少有人能做到吧？那这个阶段主要做哪些？我发布我实施我协同管理。简而言之，我发布了指南，我加入了代码安全检测，但是我在前期已经融入到了质量标准里面，那么你不符合质量管理？那么谁以主体会找你呢？反正不是我安全部门。
六、        测试：
我看到很多所谓的SDL专业文档里面说什么，给测试部门赋能，让测试具备安全测试的能力。我很想反手给他一巴掌打醒他，测试部门为啥听你的？人家领导是死了吗？你还能指挥人家测试部门的领导还是怎么滴？乖乖的融入测试流程里面，通过更改测试质量去提升安全测试的质量，去建设相关安全测试的知识库，帮助测试部门能够提升基础的简单的安全测试能力不行吗？
七、        运维（运营）：
运维（运营）阶段其实更多是对线上业务系统的检测与跟踪还有加固。其实技术手段就那些，大多数甲方安全人员其实都并在这个部门里面。这里不做重点介绍。
八、        审计：
大多数人其实印象中的SDL并没有安全审计，而我们很多服务支撑方在SDL里面也不会去提。说到审计，大多数人印象里面是法务审计，财务审计，但是法务里面没有安全合规要求？还是财务里面没有资金数据追溯支撑？如果是独立安全部门，其实我们安全本身就跟法务还有财务的性质是一样的，是一把手部门，而不是单纯意义上的技术部门。那合规跟风控推进之后，其实是能够将SDL包在内的，而这也是当最后其他部门都让我们吃灰的时候，我们最终的手段。


说一说为啥会写？然后整篇文档里面其实很少有一些具体实施方法，更多偏向于去落地。因为偏向实施的文章其实比较多了，但是很多时候大家觉得SDL这玩意儿落不了地，太重了，很多人作为安全负责人其实只知道概念，并不知道怎么推。然后厂商大多数能提供解决方案，但是提供的方案，能给一堆文档，一开始还好，然后顶多一个月两个月，那堆文档就要去吃灰了，因为不接地气儿。很多时候我们的安全负责人或者项目负责人去推这套东西，会发现做着做着，一堆部门叼你，很多情况下，其实大家都是为了完成工作，为什么会叼你？因为你喜欢出风头哇，安全部门或者说安全这件事儿，本身就没必要说非得大张旗鼓，画底线划红线，跟别的部门多协作其实没那么难推。说白了，甲方的安全职能是保障为主，但是区别于运维的保障而言，安全又是一把手部门，所以想着，写点干的落地经验大家一起探讨，安全路上大家一起携手同行吧~如果文章内有错误的，或者别的思路的，也可以发出来大家一起探讨，感谢。