背景:
目前及未来一段时间内, 可见的安全需求评审来源有三
1、施行SDL的业务线:需求评审是sdl一个环节
2、业务方对安全有要求,希望进行安全评审,给到安全建议
3、重要项目,虽未实行SDL,但安全团队依然对其有安全要求, 要对其进行安全评审;
(三种来源并存的情况,也是因为目前没有足够人力资源,及安全能力成熟度不足(如自动化、运营等), SDL不能覆盖全部业务线,所以会有以上来源;)
目的及展望
其中,第二种“业务线对安全有要去, 让我们做安全评审,给安全建议的 ”沟通成本还是有点小高 我们资源也不多
如果有个类似工单的线上的口子,会方便高效一些,降低成本,也能一定成度吸引增加愿意、乐意进行安全评审的人、项目;
在工具、流程、制度、文化成熟后,可将三种来源都汇总走线上化;
实现方案:
现有常见可以实现的地方有:
1、Jira : 在安全需求项目下,由各业务方将需要评审的需求、场景等描述上去, 安全人员来进行排期、评审操作 :
优点: 进度直观、总的评审需求总体情况直观
缺点:需要生成内容模版,模版内对字段无法方便地进行“必填”约束;
但可考虑新建属性;
2、工单: 采用现有的工单,
优点:字段约束可选、通知与钉钉关联,及时
缺点:整体及进度统计不直观;
工单设计
1、在ticket中提供入口
2、工单字段 按照需求评审所需设计,
需求名、链接、描述、备注
(需要不断完善添加)
3、工作流: 审批(需求方员工申请填写--对应leader复核确认提交)--接受(安全需求评审接口人接受)--处理(安全需求评审资源分配,确认评审者--评审者接受--评审者处理)-完成–通知(以上涉及人员均通知到)
初期可以简单点,需求人填写--》安全人员审核--》安全人员接受处理--》反馈
4、脚本同步:
- 在审批环节,leader复核确认后,工单脚本同时同步到wiki设定的目录下(安全需求评审--需求池,新建文件名为 “需求名(待评审)”)
- 接受后在jira上新建任务 跟踪
后续
评审自动化:
对接威胁建模工具,自动生成威胁列表
根据威胁列表,对应安全知识库、修复方案等,自动生成 初步的 安全评审及建议
安全建议/方案 可复用--》自动给出+人工审核
---------------------
实现后效果:
以工单形式进行实现后,节省不必要的询问时间,有需求直接提来,有模糊的在沟通;