SDL 42/100问:如何说服业务部门老板做SDL?
SDL是一个体系化的大工程,需要业务方增加人员投入进行配合,很可能影响业务系统发布节奏,所以会遇到不少阻力。
不过从为“业务保驾护航,安全服务业务”的切入点出发,保持“结合实际定制,轻柔融入”的原则,会增大成功的概率。在推进时可以:
1、找案例:纵观行业,介绍在SDL方面做得好的公司以及取得的成效;
2、讲好处:可以获得及早发现安全风险、满足法规要求、全面提高产品安全性、增强客户信任等收益;
3、先试点:找重视安全有意愿的、安全问题比较多的业务开始小范围推进,最开始可以是1个业务跑通流程、持续优化;
4、再全面:有了小范围的试点之后,以此为先进代表、在公司公开晒取得的成果,产生一定影响力,与此同时可以直接将SDL写成安全规范,然后在全公司推广。
更多软件安全内容,可以访问:
1、SDL100问:我与SDL的故事
SAST误报太高,如何解决?
SDL需要哪些人参与?
设计阶段应开展哪些安全活动?
有哪些不错的安全设计参考资料?
安全设计要求怎么做才能落地?
有哪些威胁建模方法论?
如何选择开源组件安全扫描(SCA)工具?
SCA工具扫描出很多漏洞,如何处理?
SCA工具识别出高风险协议,如何处理?
应该如何选型代码安全扫描工具?
白盒检测工具存在局限性,如何进行补偿?
SCA用什么系统做,自研还是外购?
有没有好用的SDL平台?
Sonar是否好用以及误报率咋样?
如何推进有问题的jar包更新?
SCA工具的误报率怎样?
在研发安全流程落地方面,有何经验?
如何说服业务完成checklist自检?
sdl会对项目变更代码做review吗?
如何展示SDL的成果或效果?
怎么解决源代码两张皮导致安全失效?
2、SDL创新实践系列
首发!“ 研发安全运营 ” 架构研究与实践
DevSecOps实施关键:研发安全团队
DevSecOps实施关键:研发安全流程
DevSecOps实施关键:研发安全规范
从安全视角,看研发安全
数字化转型下的研发安全痛点