精华内容
下载资源
问答
  • 安全开发流程SDL).pdf
  • 安全开发流程SDL

    千次阅读 2019-06-05 16:07:15
    安全开发生命周期(SDL)即Security Development Lifecycle,是一个帮助开发人员构建更安全的软件和解决安全合规要求的同时降低开发成本的软件开发过程。 0x02SDL流程框架 自2004年起,SDL就成为M...

    目录

    0x01 SDL介绍

    0x02 SDL流程框架

    0x03 SDL实战经验

    0x04 总结


    0x01 SDL介绍

            安全开发生命周期(SDL)即Security Development Lifecycle,是一个帮助开发人员构建更安全的软件和解决安全合规要求的同时降低开发成本的软件开发过程。

    0x02 SDL流程框架

            自2004年起,SDL就成为Microsoft全公司的计划和强制施行政策,其核心理念就是将安全考虑集成在软件开发的每一个阶段:需求分析、设计、编码、测试和维护。从需求、设计到发布产品的每一个阶段每都增加了相应的安全活动与规范,以减少软件中漏洞的数量并将安全缺陷降低到最小程度。安全开发生命周期 (SDL)是侧重于软件开发的安全保证过程,旨在开发出安全的软件应用。

    Microsoft 安全开发生命周期 – 简化(英文版)

    Microsoft 安全开发生命周期 – 简化(中文版)

     

    SDL的安全活动包括:

    阶段1:培训

    开发团队的所有成员都必须接受适当的安全培训,了解相关的安全知识,培训对象包括开发人员、测试人员、项目经理、产品经理等。

    阶段2:安全要求

    在项目确立之前,需要提前与项目经理或者产品owner进行沟通,确定安全的要求和需要做的事情。确认项目计划和里程碑,尽量避免因为安全问题而导致项目延期发布。

    阶段3:质量门/bug栏

    质量门和bug栏用于确定安全和隐私质量的最低可接受级别。

    Bug栏是应用于整个开发项目的质量门,用于定义安全漏洞的严重性阈值。例如,应用程序在发布时不得包含具有“关键”或“重要”评级的已知漏洞。Bug栏一经设定,便绝不能放松。

    阶段4:安全和隐私风险评估

    安全风险评估(SRA)和隐私风险评估(PRA)是一个必需的过程,必须包括以下信息:

    1、(安全)项目的哪些部分在发布前需要威胁模型?

    2、(安全)项目的哪些部分在发布前需要进行安全设计评析?

    3、(安全)项目的哪些部分需要并不食欲项目团队且双方认可的小组进行渗透测试?

    4、(安全)是否存在安全顾问认为有必要增加的测试或分析要求已缓解安全风险?

    5、(安全)模糊测试要求的具体范围是什么?

    6、(安全)隐私影响评级如何?

    阶段5:设计要求

    在设计阶段应仔细考虑安全和隐私问题,在项目初期确定好安全需求,尽可能避免安全引起的需求变更。

    阶段6:减小攻击面

    减小攻击面与威胁建模紧密相关,不过它解决安全问题的角度稍有不同。减小攻击面通过减小攻击者利用潜在弱点或漏洞的机会来降低风险,减小攻击面包括:关闭或限制对系统服务的访问,应用“最小权限原则”,以及尽可能进行分层防御。

    阶段7:威胁建模

    为项目或产品面临的威胁建立模型,明确可能来自的攻击有哪些方面。

    阶段8:使用指定的工具

    开发团队使用的编辑器、链接器等相关工具,可能会涉及一些安全相关的环节,因此在使用工具的版本上,需要提前与安全团队进行沟通。

    阶段9:弃用不安全函数

    许多常用函数可能存在安全隐患,应当禁用不安全的函数和API,使用安全团队推荐的函数。

    阶段10:静态分析

    代码静态分析可以由相关工具辅助完成,其结果与人工分析相结合。

    阶段11:动态程序分析

    动态分析是静态分析的补充,用于测试环节验证程序的安全性。

    阶段12:模糊测试(Fuzzing Test)

    模糊测试是一种专门形式的动态分析,它通过故意向应用程序引入不良格式或随机数据诱发程序故障。模糊测试策略的制定,以应用程序的预期用途,以及应用程序的功能和设计规范为基础。安全顾问可能要求进行额外的模糊测试,或者扩大模糊测试的范围和增加持续时间。

    阶段13:威胁模型和攻击面评析

    项目经常会因为需求等因素导致最终的产出偏离原本设定的目标,因此在项目后期对威胁模型和攻击面进行评析是有必要的,能够及时发现问题并修正。

    阶段14:事件响应计划

    受SDL要求约束的每个软件在发布时都必须包含事件响应计划。即使在发布时不包含任何已知漏洞的产品,也可能在日后面临新出现的威胁。需要注意的是,如果产品中包含第三方的代码,也需要留下第三方的联系方式并加入事件响应计划,以便在发生问题时能够找到对应的人。

    阶段15:最终安全评析

    最终安全评析(FSR)是在发布之前仔细检查对软件执行的所有安全活动。通过FSR将得出以下三种不同不同结果。

    1、 通过FSR。在FSR过程中确定所有安全和隐私问题都已得到修复或缓解。

    2、 通过FSR但有异常。在FSR过程中确定所有安全和隐私问题都已得到修复或缓解,并且/或者所有异常都已得到圆满解决。无法解决的问题将记录下来,在下次发布时更正。

    3、 需上报问题的FSR。如果团队未满足所有SDL要求,并且安全顾问和产品团队无法达成可接受的折中,则安全顾问不能批准项目,项目不能发布。团队必须在发布之前解决所有可解决的问题,或者上报高级管理层进行抉择。

    阶段16:发布/存档

    在通过FSR或者虽有问题但达成一致后,可以完成产品的发布。但发布的同时仍需对各种问题和文档进行存档,为紧急响应和产品升级提供帮助。从以上的过程可以看出,微软的SDL的过程实施非常细致。微软这些年来也一直帮助公司的所有产品团队,以及合作伙伴实施SDL,效果相当显著。

    SDL 过程图示:

     

    0x03 SDL实战经验

    准则:

    • 与项目经理进行充分沟通,排除足够的时间

    • 规范公司的立项流程,确保所有项目都能通知到安全团队,避免遗漏

    • 树立安全部门的权威,项目必须由安全部门审核完成后才能发布

    • 将技术方案写入开发、测试的工作手册中

    • 给工程师培训安全方案

    • 记录所有的安全bug,激励程序员编写安全的代码

     

    0x04 总结

            SDL中的方法,试图从安全漏洞产生的根源上解决问题,通过对软件工程的控制,保证产品的安全性。本文简单介绍了一下微软SDL,但流程复杂,落地难,借鉴微软SDL流程框架,思考如何构建符合自己公司的SDL流程框架。接下来会写几篇关于SDL的学习与思考,待续。

    参考文献:

    [1]【软件安全设计】安全开发生命周期(SDL) http://blog.nsfocus.net/sdl/
    [2] 微软SDL官方地址
    http://www.microsoft.com/security/sdl/default.aspx
    [3] Microsoft SDL 的简化实施 
    https://www.microsoft.com/zh-cn/download/confirmation.aspx?id=12379
    [4] 应用安全与微软SDL-IT流程
    https://blogs.technet.microsoft.com/gcrsec/2008/09/22/sdl-it/ 
    [5] SDL 威胁建模工具入门
    https://msdn.microsoft.com/zh-cn/magazine/dd347831.aspx
     

     

    展开全文
  • 【安全】安全开发SDL

    2021-07-19 14:31:52
    安全开发SDL SDL流程: 1、需求分析期 确定安全需求,创建质量门,错误标尺,安全隐私的保护及风险评估。 设计初期需要对需求进行安全评估,主要容易出现的问题如下: 需求需要公开的数据是否影响用户隐私 ...

    安全开发SDL

    SDL流程:

     

    1、需求分析期

    确定安全需求,创建质量门,错误标尺,安全隐私的保护及风险评估。

    设计初期需要对需求进行安全评估,主要容易出现的问题如下:

    • 需求需要公开的数据是否影响用户隐私
    • 确认项目计划里程碑中的安全问题点

    2、设计期安全问题

    确定设计需求,针对各种风险做安全风险建模

    • 设计逻辑是否存在逻辑缺陷bug
    • 安全隐私点的评估

    3、编码期

    • 安全函数的使用情况
    • 对于模块点的安全测试
    • 对于复杂业务逻辑的安全测试

    4、安全测试

    安全测试主要是在项目每一步的安全测试

    • 功能模块的安全测试
    • 阶段点、里程碑的安全测试
    • 环境部署前的安全测试

    5、发布

    • 定制针对系统的安全响应策略
    • 定制定期扫描策略
    • 定制漏洞修复流程
    展开全文
  • 第 17 章 安全开发流程SDL安全开发流程,能够帮助企业以最小的成本提高产品的安全性。它符合“ Secure at the Source ”的战略思想。实施好安全开发流程,对企业安全的发展来说,可以起到事半功倍的效果。 ...

    第 17 章 安全开发流程( SDL )

    安全开发流程,能够帮助企业以最小的成本提高产品的安全性。它符合“ Secure at the Source ”的战略思想。实施好安全开发流程,对企业安全的发展来说,可以起到事半功倍的效果。

    17.1 SDL 简介

    SDL 的全称是 Secureity Development Lifecycle ,即:安全开发生命周期。它是由微软最早提出的,在软件工程中实施,是帮助解决软件安全问题的办法。SDL 是一个安全保证的过程,其重点是 软件开发,它在开发的所有阶段都引入了安全和隐私的原则。自 2004 年起,SDL 一直都是微软在全公司实施的强制性策略。SDL 的大致步骤如下:

    image

    SDL 中的方法,试图从安全漏洞产生的根源上解决问题。通过对软件工程的控制,保证产品的安全性。

    美国国家标准与技术研究所( NIST )估计,如果是在项目发布后再执行漏洞修复计划,其修复成本相当于在设计阶段执行修复的 30 倍。

    步骤阶段:

    1. 培训
    开发团队的所有成员都必须接收适当的安全培训,了解相关的安全知识。培训的环节在 SDL 中看似简单,但其实不可或缺。通过培训能贯彻安全策略和安全知识,并在之后的执行过程中提高执行效率,降低沟通成本。培训对象包括开发人员、测试人员、项目经理、产品经理等。
    微软推荐的培训,会覆盖安全设计、威胁建模、安全编码、隐私等方面知识。

    2. 安全要求
    在项目确立之前,需要提前与项目经理或者产品 owner 进行沟通,确定安全的要求和需要做的事情。确认项目计划和里程碑,尽量避免因为安全问题而导致项目延期发布----这是任何项目经理都讨厌发生的事情。

    3. 质量门/bug 栏
    质量门和 bug 栏用于确定安全和隐私质量的最低可接受级别。在项目开始时定义这些标准可加强对安全问题相关风险的理解,并有助于团队在开发过程中发现和修复安全 bug 。项目团队必须协商确定每个开发阶段的质量门(例如,必须在 check in 代码之前进行 review 并修复所有的编译器警告),随后将质量门交由安全顾问审批,安全顾问可以根据需要添加特定于项目的说明,以及更加严格的安全要求。另外,项目团队需阐明其对安全门的遵从性,以便完成最终安全评析(FSR)。
    bug 栏是应用于整个软件开发项目的质量门,用于定义安全漏洞的严重性阀值。例如,应用程序在发布时不得包含具有“关键”或“重要”评级的已知漏洞。bug 栏一经设定,便决不能放松。

    4. 安全和隐私风险评估
    安全风险评估(SRA)和隐私风险评估(PRA)是一个必需的过程,用于确定软件中需要深入评析的功能环节。这些评估必须包括以下信息:

    1. (安全)项目的哪些部分在发布前需要威胁模型?
    2. (安全)项目的哪些部分在发布前需要进行安全设计评析?
    3. (安全)项目的哪些部分(如果有)需要由不属于项目团队且双方认可的小组进行渗透测试?
    4. (安全)是否存在安全顾问认为有必要增加的测试或分析要求以缓解安全风险?
    5. (安全)模糊测试要求的具体范围是什么?
    6. (隐私)隐私影响评级如何?

    5. 设计要求
    在设计阶段应仔细考虑安全和隐私问题,在项目初期确定好安全需求,尽可能避免安全引起的需求变更。

    6. 减少攻击面
    减少攻击面与威胁建模紧密相关,不过它解决安全问题的角度稍有不同。减少攻击面通过减少攻击者利用潜在弱点或漏洞的机会来降低风险。减小攻击面包括关闭或限制对系统服务的访问,应用“最小权限原则”,以及尽可能地进行分层防御。

    7. 威胁建模
    为项目或产品面临的威胁建立模型,明确可能来自的攻击有哪些方面。微软提出了 STRIDE 模型以帮助建立威胁模型,这是非常好的做法。

    8. 使用指定的工具
    开发团队使用的编译器、链接器相关工具,可能会涉及一些安全相关的环节,因此在使用工具的版本上,需要提前与安全团队进行沟通。

    9. 弃用不安全的函数
    许多常用函数可能存在安全隐患,应该禁用不安全的函数或 API ,使用安全团队推荐的函数。

    10. 静态分析
    代码静态分析可以由相关工具辅助完成,其结果与人工分析相结合。

    11. 动态程序分析
    动态分析是静态分析的补充,用于程序环节验证程序的安全性。

    12. 模糊测试( Fuzzing Test )
    模糊测试是一种专门形式的动态分析,它通过故意向应用程序引入不良格式或随机数据诱发程序故障。模糊测试策略的制定,以应用程序的预期用途,以及应用程序的功能和设计规范为基础。安全顾问可能要求进行额外的模糊测试,或者扩大模糊测试的范围和增加持续时间。

    13. 威胁模型和攻击面评析
    项目经常会因为需求变更等因素导致最终的产出偏离原本设定的目标,因此在项目后期重新对威胁模型和攻击面进行评析是有必要的,能够及时发现问题并修正。

    14. 事件响应计划
    受 SDL 要求约束的每个软件在发布时都必须包含事件响应计划。即使在发布时不包含任何已知漏洞的产品,也可能在日后面临新出现的威胁。需要注意的是,如果产品中包含第三方的代码,也需要留下第三方的联系方式并加入事件响应计划,以便在发生问题时能够找到对应的人。

    15. 最终安全评析
    最终安全评析( FSR )是在发布之前仔细检查对软件执行的所有安全活动。通过 FSR 将得出以下三种不同结果。

    • 通过 FSR 。在 FSR 过程中确定的所有安全和隐私问题都已得到修复或缓解。
    • 通过 FSR 但有异常。在 FSR 过程中确定的所有安全和隐私问题都已得到修复或缓解,并且/或者所有异常都已得到圆满解决。无法解决的问题将记录下来,在下次发布时更正。
    • 需上报问题的 FSR 。如果团队未满足所有 SDL 要求,并且安全顾问和产品团队无法达成可接受的折中,则安全顾问不能批准项目,项目不能发布。团队必须在发布之前解决所有可以解决的问题,或者上报高级管理层进行抉择。

    16. 发布/存档
    在通过 FSR 或者虽有问题但达成一致后,可以完成产品的发布。但发布的同时任需要对各类问题和文档进行存档,为紧急响应和产品升级提供帮助。


    相对于微软的 SDL ,OWASP 推出了 SAMM( Software Assurance Maturity Model ),帮助开发者在软件工程的过程中实施安全。
    image

    SAMM 和微软 SDL 的主要区别在于,SDL 适用于软件开发商,他们以贩售软件为主要业务;而 SAMM 更适用于自主开发软件的使用者,如银行或在线服务提供商。软件开发商的软件工程往往较为成熟,有着严格的质量控制;而自主开发软件的企业组织,则更强调高效,因此在软件工程的做法也存在差异。

    17.2 敏捷 SDL

    就微软的 SDL 过程来看,仍然显得较为厚重。它适用于采用瀑布法进行开发的软件开发团队,而对于使用敏捷开发的团队,则难以适应。

    敏捷开发往往是采用“小步快跑”的方式,但是对于安全来说,往往是一场灾难。需求无法再一开始非常明确,一些安全设计可能也会随之变化。

    微软为敏捷开发专门设计了敏捷 SDL。

    敏捷 SDL 的思想其实就是以变化的观点实施安全的工作。需求和功能可能一直在变化,代码可能也在发生变化,这要求在实施 SDL 时需要在每个阶段更新威胁模型和隐私策略,在必要的环节迭代模糊测试、代码安全分析等工作。

    17.3 SDL 实战经验

    1. 与项目经理进行充分沟通,排出足够的时间。
    2. 规范公司的立项流程,确保所有项目都能通知到安全团队,避免遗漏。
    3. 树立安全部门的权威,项目必须由安全部门审核完成后才能发布。
    4. 将技术方案写入开发、测试的工作手册中。
    5. 给工程师培训安全方案。
    6. 记录所有的安全 bug ,激励程序员编写安全的代码。

    17.4 需求分析与设计阶段

    在需求阶段,安全工程师需要关心产品主要功能上的安全强度和安全体验是否足够,主要需要思考安全功能。

    在安全领域中,“安全功能”与“安全的功能”是两个不同的概念。

    • 安全功能:产品本身提供给用户的安全功能。
    • 安全的功能:产品具体功能的实现上要做到安全,不要出现漏洞而被黑客利用。

    17.5 开发阶段

    开发阶段是安全工作的一个重点。依据“安全是为业务服务”这一指导思想,在需求层面,安全改变业务的地方较少,因此应当力求代码实现上的安全,也就是做到“安全的功能”。

    17.5.1 提供安全的函数

    在开发阶段,还可以使用的一个最佳实践就是制定出开发者的 开发规范 ,并将安全技术方案写进开发规范中,让开发者牢记开发规范。

    将安全方案写入开发规范中,就真正的让安全方案落了地。 这样不仅仅是为了方便开发者写出安全的代码,同时也为代码安全审计带来了方便。

    代码安全审计工具

    代码的自动化审计比较困难,而半自动的代码审计仍然需要耗费大量的人力,那有没有取巧的办法呢?

    实际上,对于甲方公司来说,完全可以根据开发规范来定制代码审计工具。其核心思想是, 并非直接检查代码是否安全,而是检查开发者是否遵守了开发规范。

    这样就把复杂的“代码自动化审计” 这一难题,转化为“代码是否符合开发规范”的问题。而开发规范在编写时就可以写成易于审计的一种规范。最终,如果开发规范中的安全方案没有问题的话,当开发者严格遵守开发规范时,产出的代码就应该是安全的。

    17.6 测试阶段

    测试阶段是产品发布前的最后一个阶段,在此阶段需要对产品进行充分的安全测试,验证需求分析、设计阶段的安全功能是否符合预期目标,并验证在开发阶段发现的所有安全问题是否得到解决。

    安全测试应该独立于代码审计而存在。“安全测试”相对于“代码审计”而言,至少有两个好处:

    1. 有一些代码逻辑较为复杂,通过代码审计难以发现所有问题,而通过安全测试可以将问题看得更清楚;
    2. 有些逻辑漏洞通过安全测试,可以更快的得到结果。

    安全测试,一般分为自动化测试和手动测试两种方式。
    自动化测试以覆盖性的测试为目的,可以通过“Web 安全扫描器”对项目或产品进行漏洞扫描。

    目前 Web 安全扫描器针对 “ XSS ”、“ SQL Injection ”、“ Open Redirect ”、“ PHP File Include ” 等漏洞的检测技术已经比较成熟。这是因为这些漏洞的检测方法主要是检测返回结果的字符串特征。

    而对于 “ CSRF ”、“越权访问”、“文件上传”等漏洞,却难以达到自动化检测的效果。这是因为这些漏洞涉及系统逻辑或业务逻辑,有时候还需要人机交互参与页面流程。因此这类漏洞的检测更多的需要依靠手动测试完成。

    Web 应用的安全测试工具一般是使用 Web 安全扫描器。

    安全测试完成以后,需要生成一份安全测试报告。这份报告并不是扫描器的扫描报告。扫描报告可能会存在误报与漏报,因此扫描报告需要经过安全工程师的最终确认。确认后的扫描报告,结合手动测试的结果,最终形成一份安全测试报告。

    安全测试报告中提到的问题,需要交给开发工程师进行修复。漏洞修补完成后,再迭代进行安全测试,以验证漏洞的修补情况。

    展开全文
  • SDL security development lifecycle(安全开发生命周期),是微软提出的从安全角度指导软件开发过程的管理模式。SDL是一个安全保证的过程,起重点是软件开发,它在开发的所有阶段都引入了安全和隐私的原则。自2004...

    一、SDL简介

    SDL security development lifecycle(安全开发生命周期),是微软提出的从安全角度指导软件开发过程的管理模式。SDL是一个安全保证的过程,起重点是软件开发,它在开发的所有阶段都引入了安全和隐私的原则。自2004年起,SDL一直都是微软在全公司实施的强制性策略。

    二、SDL步骤图

    SDL中的方法,试图从安全漏洞产生的根源上解决问题,通过对软件工程的控制,保证产品的安全性。

    美国国家标准与技术研究所(NIST)估计,如果是在项目发布后在执行漏洞修复计划,其修复成本相当于在设计阶段执行修复的30倍

    三、SDL的步骤包括:

    阶段1:培训

    开发团队的所有成员都必须接受适当的安全培训,了解相关的安全知识,培训对象包括开发人员、测试人员、项目经理、产品经理等。

    阶段2:安全要求

    在项目确立之前,需要提前与项目经理或者产品owner进行沟通,确定安全的要求和需要做的事情。确认项目计划和里程碑,尽量避免因为安全问题而导致项目延期发布。

    阶段3:质量门/bug栏

    质量门和bug栏用于确定安全和隐私质量的最低可接受级别。

    Bug栏是应用于整个开发项目的质量门,用于定义安全漏洞的严重性阈值。例如,应用程序在发布时不得包含具有“关键”或“重要”评级的已知漏洞。Bug栏一经设定,便绝不能放松。

    阶段4:安全和隐私风险评估

    安全风险评估(SRA)和隐私风险评估(PRA)是一个必需的过程,必须包括以下信息:

    1、(安全)项目的哪些部分在发布前需要威胁模型?

    2、(安全)项目的哪些部分在发布前需要进行安全设计评析?

    3、(安全)项目的哪些部分需要并不食欲项目团队且双方认可的小组进行渗透测试?

    4、(安全)是否存在安全顾问认为有必要增加的测试或分析要求已缓解安全风险?

    5、(安全)模糊测试要求的具体范围是什么?

    6、(安全)隐私影响评级如何?

    阶段5:设计要求

    在设计阶段应仔细考虑安全和隐私问题,在项目初期确定好安全需求,尽可能避免安全引起的需求变更。

    阶段6:减小攻击面

    减小攻击面与威胁建模紧密相关,不过它解决安全问题的角度稍有不同。减小攻击面通过减小攻击者利用潜在弱点或漏洞的机会来降低风险,减小攻击面包括:关闭或限制对系统服务的访问,应用“最小权限原则”,以及尽可能进行分层防御。

    阶段7:威胁建模

    为项目或产品面临的威胁建立模型,明确可能来自的攻击有哪些方面。

    阶段8:使用指定的工具

    开发团队使用的编辑器、链接器等相关工具,可能会涉及一些安全相关的环节,因此在使用工具的版本上,需要提前与安全团队进行沟通。

    阶段9:弃用不安全函数

    许多常用函数可能存在安全隐患,应当禁用不安全的函数和API,使用安全团队推荐的函数。

    阶段10:静态分析

    代码静态分析可以由相关工具辅助完成,其结果与人工分析相结合。

    阶段11:动态程序分析

    动态分析是静态分析的补充,用于测试环节验证程序的安全性。

    阶段12:模糊测试(Fuzzing Test)

    模糊测试是一种专门形式的动态分析,它通过故意向应用程序引入不良格式或随机数据诱发程序故障。模糊测试策略的制定,以应用程序的预期用途,以及应用程序的功能和设计规范为基础。安全顾问可能要求进行额外的模糊测试,或者扩大模糊测试的范围和增加持续时间。

    阶段13:威胁模型和攻击面评析

    项目经常会因为需求等因素导致最终的产出偏离原本设定的目标,因此在项目后期对威胁模型和攻击面进行评析是有必要的,能够及时发现问题并修正。

    阶段14:事件响应计划

    受SDL要求约束的每个软件在发布时都必须包含事件响应计划。即使在发布时不包含任何已知漏洞的产品,也可能在日后面临新出现的威胁。需要注意的是,如果产品中包含第三方的代码,也需要留下第三方的联系方式并加入事件响应计划,以便在发生问题时能够找到对应的人。

    阶段15:最终安全评析

    最终安全评析(FSR)是在发布之前仔细检查对软件执行的所有安全活动。通过FSR将得出以下三种不同不同结果。

    1、  通过FSR。在FSR过程中确定所有安全和隐私问题都已得到修复或缓解。

    2、  通过FSR但有异常。在FSR过程中确定所有安全和隐私问题都已得到修复或缓解,并且/或者所有异常都已得到圆满解决。无法解决的问题将记录下来,在下次发布时更正。

    3、  需上报问题的FSR。如果团队未满足所有SDL要求,并且安全顾问和产品团队无法达成可接受的折中,则安全顾问不能批准项目,项目不能发布。团队必须在发布之前解决所有可解决的问题,或者上报高级管理层进行抉择。

    阶段16:发布/存档

    在通过FSR或者虽有问题但达成一致后,可以完成产品的发布。但发布的同时仍需对各种问题和文档进行存档,为紧急响应和产品升级提供帮助。

    从以上的过程可以看出,微软的SDL的过程实施非常细致。微软这些年来也一直帮助公司的所有产品团队,以及合作伙伴实施SDL,效果相当显著。

    相对于微软的SDL,OWASP推出了SAMM(Software Assurance Maturity Model),帮助开发者在软件工程的过程中实施安全。

    SAMM与SDL的主要区别在于,SDL适用于软件开发商,他们以贩售软件为主要业务;而SAMM更适用于自主开发软件的使用者,如银行或在线服务提供商。软件开发商的软件工程往往较为成熟,有着严格的质量控制;而自主开发软件的企业组织,则更强调高效,因此在软件工程的做法上也存在差异。

    四、SDL实战经验准则:

    准则一:与项目经理进行充分沟通,排除足够的时间

    准则二:规范公司的立项流程,确保所有项目都能通知到安全团队,避免遗漏

    准则三:树立安全部门的权威,项目必须由安全部门审核完成后才能发布

    准则四:将技术方案写入开发、测试的工作手册中

    准则五:给工程师培训安全方案

    准则六:记录所有的安全bug,激励程序员编写安全的代码

    展开全文
  • 安全开发生命周期(SDL)是一个帮助开发人员构建更安全的软件和解决安全合规要求的同时降低开发成本的软件开发过程。安全应用从安全设计开始,软件的安全问题很大一部分是由于不安全的设计而引入的,微软用多年的...
  • SDL的全称是Security Development Lifecycle,即:安全开发生命周期。由微软最早提出,是一种专注于软件开发的安全保障流程。为实现保护最终用户为目标,它在软件开发流程的各个阶段引入安全和隐私问题。 2.流程 ...
  • 安全开发SDL

    2020-02-29 10:20:48
    确定安全需求,创建质量门,错误标尺,安全隐私的保护及风险评估。 设计初期需要对需求进行安全评估,主要容易出现的问题如下: 需求需要公开的数据是否影响用户隐私 确认项目计划里程碑中的安全问题点 2...
  • 1、详见下图:
  • 第17章 安全开发流程SDL) 17.1 SDL简介 安全开发是从根源有效地解决安全漏洞问题,而已在软件的生命周期内,这样的开发模式成本更低。 SDL过程: q培训 所有的开发人员必须接收适当的安全培训,了解相关的安全...
  • 【渗透测试-web安全】SDL -软件安全开发周期SDL基本内容块未来发展 SDL SDL即Security Development Lifecycle (SDL),是微软提出的从安全角度指导软件开发过程的管理模式。SDL不是一个空想的理论模型。它是微软为了...
  • 讲述令狐冲引进SDL安全开发周期)的过程. 话说令狐冲所在的华山剑派的信息技术部,最近又出事了! 原来,他所在的开发团队发布的一款名为“华山剑谱”的手机App被人发现含有木马,经过了解,原因是开发工具不是...
  • 话说令狐冲所在的华山剑派的信息技术部,...原来,他所在的开发团队发布的一款名为“华山剑谱”的手机App被人发现含有木马,经过了解,原因是开发工具不是官方正版的,而是从网上下载了一个被植入木马的Xcode修改版。
  • 安全开发流程与安全开发生命周期SDL管理介绍,以及在线项目管理、SDL SaaS服务介绍。
  • 安全开发生命周期(SDL)即Security Development Lifecycle,是一个帮助开发人员构建更安全的软件和解决安全合规要求的同时降低开发成本的软件开发过程。 0x02SDL流程框架 自2004年起,SDL就成为Microsoft全公司的...
  •  概述安全开发周期,即Security Development Lifecycle (SDL),是微软提出的从安全角度指导软件开发过程的管理模式。SDL不是一个空想的理论模型。它是微软为了面对现实世界中安全挑战,在实践中的一步步发展起来的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 3,925
精华内容 1,570
关键字:

sdl安全开发流程