SDL
帮助开发人员构建更安全的软件和解决安全合规要求的同时降低开发成本的软件开发过程
SDL的核心理念就是将安全考虑集成在软件开发的每一个阶段：需求分析、设计、编码、测试和维护。从需求、设计到发布产品的每个阶段每都增加了相应的安全活动，以减少软件开发过程中产生的漏洞数量，在上线前将安全风险降到最低。
培训
开发团队的所有成员都必须接受适当的安全培训，了解相关的安全知识，培训对象包括开发人员、测试人员、项目经理、产品经理等。
需求
在项目确立之前，需要提前与项目经理或者产品进行沟通，确定安全的要求和需要做的事情。确认项目计划和里程碑，尽量避免因为安全问题而导致项目延期发布。
质量门/bug栏
质量门和bug栏用于确定安全和隐私质量的最低可接受级别。
Bug栏是应用于整个开发项目的质量门，用于定义安全漏洞的严重性阈值。
理解下，如果项目发布上线，当发现安全风险时，要判断是否超过阈值，比如我们规定他严重以及高危风险不允许上线，那如果是低
安全和隐私风险评估
安全风险评估（SRA）和隐私风险评估(PRA)是一个必需的过程，必须包括以下信息：
1、（安全）项目的哪些部分在发布前需要威胁模型？
威胁模型，对项目可能潜在存在的安全威胁和风险进行建模，识别潜在的安全问题并实施相应缓解措施
2、（安全）项目的哪些部分在发布前需要进行安全设计评析？
在威胁建模之后进行漏洞分析和风险评估提出解决方案最后进行实施和监控
3、（安全）项目的哪些部分需要并不适用于项目团队且双方认可的小组进行渗透测试？
假设已经设定项目上线，邀请其他公司来对项目进行渗透测试
4、（安全）是否存在安全顾问认为有必要增加的测试或分析要求已缓解安全风险？
是否存在遗漏的测试项，潜在的安全问题这些缓解措施是否生效？
5、（安全）模糊测试要求的具体范围是什么？
模糊测试：向系统中引入不良格式以及随机数据来检测系统是否故障
6、（安全）隐私影响评级如何？
对个人敏感信息被泄漏滥用或者未经授权访问的风险进行评级
设计要求
在设计阶段应仔细考虑安全和隐私问题，在项目初期确定好安全需求，尽可能避免安全引起的需求变更。
减小攻击面
减小攻击面与威胁建模紧密相关，不过解决安全问题的角度不同。减小攻击面通过减小攻击者利用潜在弱点或漏洞的机会来降低风险，减小攻击面包括：关闭或限制对系统服务的访问、应用“最小权限原则”、分层防御
关闭或限制对系统服务的访问：比如公网内网划分，公网涉及面更广，内网就只允许我们公司内部访问
应用“最小权限原则”：需要啥权限给啥权限，严格规定权限分配
分层防御：比如打进内网，内网里面还是有防御的；再比如网站已经打下来了，但是数据爬取还有一层防御
既然威胁建模和减少攻击面两个紧密相关，啥区别？
威胁建模是用来识别潜在安全问题，那减少攻击面是减少安全问题的一种方法
威胁建模
为项目或产品面临的威胁建立模型，明确可能来自的攻击有哪些方面，同上了
使用指定的工具
开发团队使用的编辑器等相关工具，可能会涉及一些安全相关的环节，因此在使用工具的版本上，需要提前与安全团队进行沟通。
开发工具也可能存在漏洞
弃用不安全函数
许多常用函数可能存在安全隐患，应当禁用不安全的函数和API，使用安全团队推荐的函数。
静态分析
代码静态分析可以由相关工具辅助完成，其结果与人工分析相结合-------白盒代码审计
动态程序分析
动态分析是静态分析的补充，用于测试环节验证程序的安全性---黑盒咯
模糊测试（Fuzzing Test）
模糊测试是一种专门形式的动态分析，通过故意向应用程序引入不良格式或随机数据诱发程序故障。模糊测试策略的制定，以应用程序的预期用途，以及应用程序的功能和设计规范为基础。安全顾问可能要求进行额外的模糊测试，或者扩大模糊测试的范围和增加持续时间。
威胁模型和攻击面评析
项目经常会因为需求等因素导致最终的产出偏离原本设定的目标，因此在项目后期对威胁模型和攻击面进行评析是有必要的，能够及时发现问题并修正。
重新修正威胁建模和攻击面范围，在需求变更完了之后也要保证能及时返现问题
事件响应计划
受SDL要求约束的每个软件在发布时都必须包含事件响应计划。即使在发布时不包含任何已知漏洞的产品，也可能在日后面临新出现的威胁。需要注意的是，如果产品中包含第三方的代码，也需要留下第三方的联系方式并加入事件响应计划，以便在发生问题时能够找到对应的人。
最终安全评析
最终安全评析（FSR）是在发布之前仔细检查对软件执行的所有安全活动。通过FSR将得出以下三种不同不同结果。
1、 通过FSR。在FSR过程中确定所有安全和隐私问题都已得到修复或缓解。
2、 通过FSR但有异常。确定所有安全和隐私问题都得到解决方法。无法解决的问题将记录下来，在下次发布时更正。
3、 需上报问题的FSR。如果团队未满足所有SDL要求，并且安全和产品团队无法达成可接受的折中，则安全不能批准项目，项目不能发布。团队必须在发布之前解决所有可解决的问题，或者上报高级管理层进行抉择。
发布/存档
在通过FSR或者虽有问题但达成一致后，可以完成产品的发布。但发布的同时仍需对各种问题和文档进行存档，为紧急响应和产品升级提供帮助。
SDL实际上代表的是以瀑布模式的S-SDLC（安全软件开发生命周期），适用于系统级软件或者工具软件，开发周期相对较长、需求范围相对明确，而且变化相对可控并不会太频繁。
那这样的话对于敏捷开发，高迭代的场景下，如果严格按照sdl模型实施的话，可能会因为太过繁琐而不能及时落地，如果强行要求各个阶段都实施安全管控，可能会对项目周期产生影响。正式实施sdl的时候最大的问题就是将安全技术和软件生命周期各阶段有效的结合起来，就会出现业务部门认为安全是安全部门的事情，安全目标的推动就会很难进行等等
那就出现了devsevops！
- SDL: Security Development Lifecycle，安全开发生命周期
- S-SDLC: Secure Software Development Life Cycle , 安全软件开发生命周期
- SDLC: Software Development Life Cycle, 软件开发生命周期
- DevOps: Development 和 Operations 的组合，是一组过程、方法与系统的统称
- DevSecOps: 在DevOps模式下提出的安全模式
关系如下：
为什么要做SDL
可以看到在软件发布运行一段时间后，才发现的漏洞，需要运维，发布的介入，修复成本大量上升，给企业带来相当大的风险和成本压力，若漏洞已被黑客发现或利用，造成的损失和影响将更大。
而在研发阶段，发现的漏洞可以由开发直接修复，成本低，效率高。
所以越早发现漏洞问题，修复成本越低。
这是一张在各个时期修复漏洞所产生的成本
DevSecOps
相对于SDL，DevSecOps不再是一个单纯的安全开发模型，它所强调的是人人为安全负责，人人参与安全，安全嵌入到开发到运维的每个阶段。
从角色角度，安全团队不再置身于业务之外，也不再是安全团队兜底安全，安全是一个开发、安全、运维一起协作的过程。
DevSecOps强调的是：
- 人人为安全负责，人人参与安全构建
- 自动化工具，将安全嵌入到开发到运维的每个阶段
- 进一步的流程融入，加强不同团队间的协作
在不同阶段需要开展不同的安全工作，都需要不同的工具支撑。
主机安全检测：端口扫描漏洞检测，开放在端口上的服务是否存在风险
安全配置基线扫描：是否对公网开放、默认密码（产品出厂自带默认密码是否修改）等等配置项
代码签名：对软件进行数字签名，实现安全分发并符合操作系统安全策略，会认为是个安全软件可安装
ngfm：堡垒机，运维管控设备，服务器统一安全管控，所有人登陆服务器都需要通过堡垒机登陆
堡垒机会记录运维在服务器上的操作以防止操作不规范产生的风险，比如开了个后门啥的等等
但是鸡肋啊，这玩意打你一台全部服务器不会被打吗？
ddos：一次性发起大量请求攻击网站
ddos攻击清洗与防护：识别ddos攻击，如果是一个ip发起大量请求就认为是恶意操作，或者爬虫恶意流量识别
主机入侵行为检测：服务器有没有被打
资产扫描：资产收集
威胁情报：收集安全情报，比如黑客团队在做什么，或者hw期间有什么漏洞会被打
白盒：源代码扫描，不影响业务，覆盖率高，误报率高，通过代码跟踪数据流，不知道具体输入，也没有真正运行代码，所以误报率高（数据流越长，越容易出现误报，比如已经有安全处理的函数，但白盒是不知道已经处理过了）分析了所有数据流量非常大，可能十几万上百万，从数据角度说覆盖率和误报率升高是必然的
黑盒：动态安全检测，覆盖率低，准确率高，最传统的检测方法，知道输入输出不知道数据流的流转过程，只能通过模糊测试，比如说接口中插入脏数据，可能会导致脏数据
灰盒：结合了黑盒和白盒的优点，知道输入输出也知道数据流的流转过程，缺点是对性能影响比较大，会跟踪数据流，在跟踪数据流的时候性能跟着数据流的层数飙升，数据流层数低了可能会漏报漏洞，可能会影响正常业务
以上简单理解，针对开发安全产品线产品后续展开
从SDL到DevSecOps
是不是原来SDL的东西就没法用到DevSecOps？需要推翻呢？
不是的，需要做的是进一步的流程融入，更加自动化，更多前置，以及安全意识的培养吧。
DevSecOps的落地中很重要的一个部分就是如何在CI/CD嵌入相关安全动作，找到了下面这个图
