SDL软件安全开发流程总结

2020-01-20 +15 125721人围观 ,发现 8 个不明物体 企业安全

前言

现在有很多公司SDL的流程刚刚起步,我想分享一下自己在SDL中的一些经验。由于经验尚浅,无法估量整个 SDL的建设情况,以下只是自己在工作中的理解和拍脑袋的想法,请各位大佬指点。

SDL全称Security Development Lifecycle,又称作安全开发生命周期,包括安全培训、安全需求设计、安全开发、安全检测和安全监控五个阶段。本文会以安全检测为重点展开。

一、安全培训

安全培训的重点是提高全体项目人员的安全意识,包括产品经理的安全意识和研发测试人员的代码安全意识。

项目的中期可开展针对性的培训,例如代码中经常出现的问题、测试过程中多次出现的漏洞等都可以作为培训的重点。

二、安全需求设计

针对系统业务要求实施风险评估工作,根据需求文档与项目经理确定安全需求,制定安全需求表,供后续开发检测时使用。

三、安全开发

安全开发阶段由项目经理把控。作为安全人员,在项目开始前对所有研发人员做好安全培训,中期做针对性的问题漏洞培训,能够减轻在安全检测时的工作量。

四、安全检测

在从前任职的公司,安全体系相对完善,所有的新项目上线前都需要经过三步检查——代码审计、Web应用扫描、人工渗透扫描。

代码审计

使用 Jekens 拉 Gitlab 代码放入Fortify 中扫描。开发过程中,开发人员每次更新代码都要进行扫描,并有权限查看Fortify相关项目漏洞情况,进行整改(不允许有中高危以上漏洞)。开发有权对漏洞进行忽略处理,但需要承担相应后果。若不知道如何处理,可请安全组提供解决方案。(代码扫描可以使用其他安全工具)

WEB应用扫描

WEB应用扫描不需要安全基础即可操作。因为安全人员比测试人员少,一般交予测试人员协助处理。扫描器可选择项很多,包括开源或者商用,选择适合自己的就好。

人工渗透扫描

这也是最后一步。针对不同的应用发布情况,若是应用为新应用则需要对总体项目进行渗透测试;若为增量项目(版本迭代更新)则只需要对增加项相关接口做测试。渗透人员由安全组人员负责。

以上报告中出现中高危以上问题必须整改,整改完成前不允许上线。 

五、安全监控

一般来说,公司都具有安全设备,安全的维护也可以借助SRC(Security Response Center安全应急响应中心)或者第三方漏洞平台。

六、SDL流程监督

最后分享一下关于SDL流程监督的经验。

SDL流程由项目经理负责,同样SDL的监督对象为项目经理,项目经理为整改流程的主导。流程监督是贯穿整个开发周期的,包括前期的安全培训、需求设计,中期的代码开发、安全检测,后期的安全监控。

再介绍一下在SDL流程中的《安全选项表》。《安全选项表》中的内容为等级保护和网站备案中必须存在的一些安全功能项,属于法律合规的内容。不是产品必须符合其中的内容,而是尽量符合。若不用相关功能,可以在表格中解释一下,日后在做等级保护等检查时也可直接提供与检查人员。

若项目为全新项目,则按照《安全选项表》(图1)中流程进行。产品经理需要参考表中的内容,对项目进行梳理,选择保留项。若选项不保留,则需要在备注中说明理由。

图1 

开发和测试根据产品填写好的《安全选项表》内容进行测试。部分安全专业的测试工作由安全人员进行测试。完成最后的安全测试并允许上线后,三份测试报告和此安全选项表格要进行归档。其中比较重要的环节是对四条线的人(项目经理、产品、开发、测试)培训安全选项表内容。

若项目为后期迭代,则需求评审的时候需要安全人员参与,负责安全性评估和后期渗透检查。代码和WEB应用扫描可以照常进行。

结束语

以上SDL整体的流程完全依据个人平时的工作理解而成,供大家参考。有错误的地方欢迎大佬们指正,有更好的完善方法也欢迎大家补充探讨。

相关资料

https://blog.csdn.net/shark1357/article/details/89368328

https://jenkins.io/doc/pipeline/steps/fortify/

https://wiki.jenkins.io/display/JENKINS/Fortify+Plugin

*本文原创作者:山城安全MTSec,本文属于FreeBuf原创奖励计划,未经许可禁止转载

相关推荐

这些评论亮了

  • Volts 回复
    1. SDL中交付不同阶段交付人员与安全人员的职责分工是什么?这个是涉及到组织规划的问题。 做SDL, 最简单的就是一堆东抄抄西抄抄的文档,开箱即用的工具,凑合一个的流程,就可以走一个了。 但没有定义好职责, 就会发现,一旦有问题出现,责任永远在信息安全。比如你会发现随着你的测试工具不断演进,会不断发现隐藏的漏洞,而发掘原因,虽然根源是开发能力或意识的问题, 但总可以甩锅给到所谓安全规则不明确或是测试有遗漏的原因。 所以组织要定义清楚安全规则结合业务及技术场景的落地, 整个过程两个团队的责任边界。 依照目前开发full load 以及高阶开发人员缺失的实际情况, 业内亟待一种标准化解决方案,可以将general 的安全需求翻译为给到具体coder或开发lead的安全系统设计。
    2. 测试角度,敏捷, 微服务,灰度发布,交付团队的交付迭代越来越快,交付颗粒度越来越细分,安全测试如何提效,什么样的测试策略,什么样的测试工具,可以满足高频的安全测试需求。 这个也是要不断在开发过程中摸索改进的方向。
    3. 度量, 花钱的活,需要想指标证明钱花的值。或者想指标显性化现状及改进的方向。 钱花的值这方面比较难,工作量的数据是开发统计的, 漏洞数量这东西呢深究下去又会有更多的问题,比如已发现漏洞与漏洞总数的占比,这个项目跟那个项目的漏洞数是否可比。所以还是得从安全团队自主可控的角度设计度量指标数据。现状及改进方向... 一个方向是找权威背书,CMM,BSIMM,NIST的CSF,就看怎么有策略的取舍及解释了。
    )8( 亮了
发表评论

已有 8 条评论

取消
Loading...
山城安全MTSec

这家伙太懒,还未填写个人描述!

1 文章数 4 评论数 1 关注者

特别推荐

填写个人信息

姓名
电话
邮箱
公司
行业
职位
css.php