0x00背景
Microsoft SDL在开发过程的所有阶段都引入了安全性和隐私注意事项，从而帮助开发人员构建高度安全的软件，解决安全合规性要求并降低开发成本。Microsoft SDL中的指南，最佳实践，工具和过程是我们在内部使用以构建更安全的产品和服务的实践。自2008年首次共享以来，由于我们在新场景（例如云，物联网（IoT）和人工智能（AI））方面的不断积累的经验，我们对实践进行了更新。
0x01概述
安全开发生命周期（SDL）包含一组支持安全保证和合规性要求的实践。通过减少软件的漏洞数量和严重性和降低开发成本，SDL帮助开发人员构建更安全的软件。
0x02 12大实践
实践1-提供培训
安全是每个人的工作。开发人员，服务工程师以及程序和产品经理必须了解安全基础知识，并知道如何在软件和服务中构建安全性，以使产品更加安全，同时仍能满足业务需求并提供用户价值。
有效的培训将补充和加强安全策略，SDL实践，标准和软件安全要求。同时它以通过数据获取到的见解或新获得的技术能力为指导。
尽管安全是每个人的工作，但重要的是要记住，并非每个人都需要成为安全专家，也不是力求要成为熟练的渗透测试人员。但是，确保每个人都了解攻击者的视角，他们的目标和可能的技巧将有助于吸引所有人的注意力并提高团队知识水平。
实践2-定义安全要求
考虑安全性和隐私性是开发高度安全的应用程序和系统的基本方面，并且无论使用何种开发方法，都必须不断更新安全性要求，以反映所需功能的变化和威胁态势的变化。
显然，定义安全需求的最佳时间是在初始设计和规划阶段，因为这允许开发团队通过最小化中断的方式集成安全性。影响安全要求的因素包括（但不限于）法律和行业要求，内部标准和编码惯例，对先前事件的回顾以及已知威胁。这些要求应通过工作跟踪系统或通过工程线路得出的测量技术来跟踪。
有用的链接：
实践3-定义指标和合规性报告
必须定义安全质量的最低可接受级别，并使工程团队有责任去达到该标准。尽早定义这些有助于团队了解与安全问题相关的风险，在开发过程中识别和修复安全缺陷，并在整个项目中应用标准。 设置有意义的缺陷门栏涉及明确定义安全漏洞的严重性阈值（例如，必须在指定的时间范围来修复发现具有“严重”或“重要”严重性等级的所有已知漏洞），并且在设置好之后就不能放松。
为了跟踪关键绩效指标（KPI）并确保完成安全任务，组织使用的缺陷跟踪或者工作跟踪机制（例如Azure DevOps）应当允许将安全缺陷或者安全工作事项明确标记为安全并标有其相应的安全严重性。这样可以准确跟踪和报告安全工作。
有用的链接：
将安全性错误栏添加到Microsoft Team Foundation Server 2010（旧版资源）
实践4-执行威胁建模
威胁建模应在存在重大安全风险的环境中使用。威胁建模可以应用于组件，应用程序或系统级别。通过这种做法，开发团队可以在计划的操作环境中并以结构化方式考虑，记录和（重要）讨论设计的安全隐患。
将结构化方法应用于威胁情景可帮助团队更有效，更低成本地识别安全漏洞，确认来自哪些威胁的风险，然后选择安全功能并建立适当的缓解措施。
有用的链接：
实践5-建立设计要求
SDL通常被认为是保证活动，可帮助工程师实施“安全功能”，因为功能在安全性方面经过精心设计。为了实现这一点，工程师们通常将依赖于安全功能，例如加密，身份验证，日志记录等。在许多情况下，安全功能的选择或实施已被证明是如此复杂，以至于设计或实施的选择很可能也会导致漏洞。因此，至关重要的是要始终如一地应用这些应用程序，并对它们提供的保护保持一致的理解。
实践6-定义和使用密码学标准
随着移动和云计算的兴起，至关重要的是确保在传输或存储数据时，防止所有数据（包括对安全敏感的信息以及管理和控制数据）受到意外泄露或更改。通常使用加密来实现此目的。在密码学任何方面的使用时，做出一个错误的选择都将是灾难性的，最好的做法是开发清晰的加密标准，以提供有关加密实现每个元素的详细信息。这标准应该留给专家制定。一个好的通用规则是仅使用经过行业审查的加密库，并确保以某种方式实施它们，以便在需要时可以轻松替换它们。
有用的链接：
实践7-管理使用第三方组件的安全风险
如今，绝大多数软件项目都是使用第三方组件（包括商业组件和开源组件）构建的。选择要使用的第三方组件时，重要的是要了解它们中的安全漏洞可能会对集成它们的较大系统的安全性产生影响。拥有准确的第三方组件清单并制定发现新漏洞时的响应计划将大大减轻这种风险。应根据组织的风险承受能力、使用的组件类型以及安全漏洞的潜在影响，应该考虑到（对于上述清单和响应计划）进行更多的验证核实。了解有关管理使用开源软件等第三方组件的安全风险的更多信息。
有用的链接：
实践8-使用认可的工具
定义并发布已批准工具以及这些工具相关的安全检查列表，例如编译器/链接器选项和警告。工程师应努力使用批准工具的最新版本，例如编译器版本，并利用新的安全分析功能和保护。
有用的链接：
x86，x64和ARM的推荐工具，编译器和选项（旧版工具）
实践9-执行静态分析安全性测试（SAST）
在编译之前，分析源代码提供了一种高度可扩展的安全代码检查方法，并有助于确保遵循安全的编码策略。SAST通常集成到提交流程中，以便在每次构建或打包软件时识别漏洞。但是，某些产品集成到开发人员环境中，以发现某些缺陷，例如存在不安全或其他被禁止的功能，却在开发人员积极编码时，替换了那些原本更安全的方法。没有一刀切的解决方案，开发团队应确定执行SAST的最佳频率，并可能部署多种策略，以便在开发产品与足够的安全保障之间取得平衡。
有用的链接：
FxCop（旧版工具）
静态代码分析工具列表（维基百科）
实践10-执行动态分析安全性测试（DAST）
对完全编译或打包的软件执行运行时验证将检查功能，这些功能仅在所有组件都已集成并运行时才显而易见。通常使用工具或一组预先构建的攻击或专门监视应用程序行为的内存损坏，用户特权问题和其他关键安全性问题的工具来实现此目的。与SAST相似，没有一刀切的解决方案，尽管某些工具（例如Web应用程序扫描工具）可以更轻松地集成到持续集成/持续交付流程中，而其他DAST测试（例如模糊测试）则需要不同的解决方案方法。
有用的链接：
实践11-执行渗透测试
渗透测试是由熟练的安全专家模拟黑客行为，执行软件系统的安全性分析。渗透测试的目的是发现由编码错误，系统配置错误或其他操作部署弱点导致的潜在漏洞，因此，该测试通常可以发现种类最多的漏洞。渗透测试通常与自动和手动代码检查结合使用，以提供比通常可能更高的分析水平。
有用的链接：
实践12-建立标准的事件响应流程
制定事件响应计划对于帮助应对随着时间推移可能出现的新威胁至关重要。应与组织的专用产品安全事件响应团队（PSIRT）协调创建该事件响应计划。该计划应包括在安全紧急情况下应与谁联系，并建立安全服务协议，这些协议包括考虑到从公司组织的其他团队继承的代码和第三方的代码等。事件响应预案应在需要事件发生之前进行演练！
有用的链接：
0x03官方帮助文档
参考链接：
主页：https://www.microsoft.com/en-us/securityengineering/sdl/
介绍：https://www.microsoft.com/en-us/securityengineering/sdl/about
实践：https://www.microsoft.com/en-us/securityengineering/sdl/practices
资源：https://www.microsoft.com/en-us/securityengineering/sdl/resources
威胁建模工具：https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling
