微软SDL实践

微软官方学习链接：https://www.microsoft.com/en-us/securityengineering/sdl/practices

标准SDL

安全培训

安全培训是指企业的安全团队组织“安全角”进行定期的安全培训，对象为研发、产品经理、运维等同事。培训内容可以是基础安全知识、业务安全风险、代码编写规范、基本渗透测试使用工具等。

0x01 基础安全知识

培训内容可根据主题来拆分，分时段进行。

1. SQL专题（根据企业内常见的漏洞出现场景进行定制）
   1. 根据漏洞出现的场景进行讲解（日期选择处，ID处等等）
   2. 根据漏洞防御方式进行讲解（预编译，利用MyBatis框架等）
   3. 根据漏洞检测方式进行讲解（如何自检测，顺便向研发推一波IDEA插件[安全SDK]，自己检测的集中方式，或者是SQLmap的使用）具体课程时间可自行分配
   4. 代码编写规范（避免拼接、避免MyBatis配置文件中的拼接、多注意些无法使用预编译的场景：like等函数）
2. 代码泄露专题（可根据SRC的漏洞数据和企业内部的漏洞库进行分析，找出企业内经常出现的漏洞类型）
   1. 不要把敏感信息硬编码在代码中，比如AES密钥等
   2. 不要把源代码放在公共资源上，比如：GitHub等
   3. 以上这些应当是在新人培训当中体现。
   4. webpack导致的源码泄露
3. 业务安全专题
4. API专题
5. XSS专题
6. 检测工具专题
7. 等等

0x02 业务安全风险

逻辑漏洞往往是企业中出现的漏洞占比最高的，针对逻辑漏洞的防御也不是扫描器和工具可以来进行的，大部分是需要研发在项目设计阶段对功能的逻辑进行梳理，还有企业内部安全人员在SDL阶段进行安全测试发现，以及外部白帽子挖掘SRC发现。所以针对经常出现逻辑漏洞的场景进行收集，对研发进行培训逻辑漏洞场景预防。

0x03 代码编写规范

这个需要企业针对自家产品以及一些安全检测工具来进行限制和培训。具体事情具体分析。

0x04 测试工具

最主要的是安全编码SDK也就是IDEA插件的使用，在企业内部各大研发中心进行推广使用。其他的工具也可以收集一些简单的工具，针对研发和运维做一些安全培训。

定义安全需求

考虑安全和隐私的需要是开发高度安全的应用程序和系统的一个基本方面，无论使用何种开发方法，安全要求都必须不断更新以反映所需功能的变化和威胁形势的变化。显然，定义安全要求的最佳时间是在初始设计和规划阶段，因为这允许开发团队以最大限度减少中断的方式集成安全性。影响安全要求的因素包括（但不限于）法律和行业要求、内部标准和编码实践、对先前事件的审查以及已知威胁。应通过工作跟踪系统或从工程管道派生的遥测来跟踪这些要求。

定义指标和合规报告

必须定义最低可接受的安全质量水平，并让工程团队负责满足该标准。尽早定义这些有助于团队了解与安全问题相关的风险，在开发过程中识别和修复安全缺陷，并在整个项目中应用这些标准。 设置一个有意义的 bug bar 包括明确定义安全漏洞的严重性阈值（例如，发现的所有具有“严重”或“重要”严重性等级的已知漏洞必须在指定的时间范围内修复）并且一旦设置就永远不会放松. 为了跟踪关键绩效指标 (KPI) 并确保完成安全任务，组织使用的错误跟踪和/或工作跟踪机制（例如 Azure DevOps）应允许将安全缺陷和安全工作项明确标记为安全并标有相应的安全严重性。这允许准确跟踪和报告安全工作。

执行威胁建模

威胁建模应该用于存在重大安全风险的环境中。威胁建模可以应用于组件、应用程序或系统级别。这种做法允许开发团队在其计划的操作环境的上下文中以结构化的方式考虑、记录和（重要的）讨论设计的安全影响。 将结构化方法应用于威胁场景有助于团队更有效且成本更低地识别安全漏洞，确定这些威胁带来的风险，然后选择安全功能并建立适当的缓解措施。