多样化研发体系下,安全开发落地的实践探讨

在各行业数字化进程的快速推进和网络安全攻防效果至上、合规趋严的态势下,软件开发面临的不仅仅是功能效能的提升,而是如何在不同开发模式下融合安全要求和能力,构建高效、安全的软件开发体系。

 

一、为什么要做开发安全体系?

 

参照 CNVD 统计数据,大量漏洞层发生在应用层。在近年来的大量攻防演练实战中,应用程序也被认为是最容易被攻破的地方之一。应用程序内生安全缺陷凸显的现状也引起了国家法律和行业监管层面的重视。开发安全体系是应用安全的解法,也是满足合规要求的必经之路。

 

二、开发安全体系在设计阶段的“要和不要”  

 

不照搬:应结合自身情况选择最合适的安全能力展开建设与运营,否则可能面临难落地的局面。

 

不违背:不违背现有开发流程,新体系落地自带阻力,想推翻原有流程更会难上加难;另外,对现有开发流程的清晰认识也有利于后续整体体系的流畅运营。

 

可操作:要明确各个环节要收敛的风险,形成详细的操作手册、审核内容及研判标准,确定责任边界,同时保证人工需求评审、代码审计、渗透测试等环节的有序推动和目标安全效果。

 

精细化:设计时将收敛环节尽可能左移,例如在本地库做卡点,将供应链安全风险收敛到编码引入阶段;同时通过精细化运营,在需求设计阶段明确人工参与环节,降低鉴权、认证等工作的人力成本,做到资源集约。

 

三、如何实现开发安全体系的成功转变  

 

开发安全体系真正落地的关键问题是能否高效运营。高效运营需要依赖于 4 个核心因素:

  • 流程自动化:与 CI/CD 集成或采用自动化流程平台。
  • 卡点推覆盖:卡点即质量门禁,是流程管理的必要因素,也是保证安全覆盖度的关键。
  • 能力高可靠:安全方法应保证高可靠、低误报,否则直接影响体系的落地效果。
  • 制度与宣发:制度管理规范是流程推进的重要依据和支撑;宣发是指保证整个流程流转状态的透明化,并赋予研发等团队推动环节流转所需的知识技能等。

 

从具体实现来看,以上 4 个核心因素都有相应的、比较有效的方法。

 

 1. 流程自动化:建设应用安全运营平台

 

一个基础的应用安全运营平台应包含 3 个关键功能,分别是

  • 流程自定义(尤其在大型应用环境中,流程复杂多变,支持自定义能够保持灵活度和有效性)
  • 支持安全工具集成(适用于非 DevOps 类开发项目,即无法与 CI/CD 直接集成时,能够自动调用安全工具)
  • 漏洞管理(运营平台的核心最终还是落到安全效果,漏洞全生命周期的管理是考验开发安全体系运营效率的重要指标)

 

 2. 卡点推覆盖:如何设置质量门禁

 

(1)安全评审(威胁建模)与 SAST安全评审需要结合项目管理平台等,确保所有项目过审,在代码合入时做卡点,只有已备案的分支允许合入;安全评审校验完成后自动进行白盒代码扫描,Gitlab 根据扫描结果判断是否允许代码合入。

 

(2)安全编码培训与 IAST安全编码培训针对新人入职,自动创建培训与考试,通过后开通工作权限;还可以当某位程序员产出的同一种类漏洞超过一定阈值则自动收回权限,强制完成安全考试,考试通过后恢复权限。这里讨论的 IAST 指的是被动 IAST,可以设立以下质量门禁:

  • 若 IAST 扫描存在漏洞则通过漏洞管理平台通知研发,研发完成修复后继续测试。
  • 若研发分析存在误报,则发起误报研判;若安全团队研判为误报,则自动修改扫描结果。
  • 研发发起上线申请,并关联 IAST 扫描结果,若无漏洞则上线成功,若有漏洞则上线失败。

 

(3)容器安全检查在容器安全检查的卡点主要体现在以下 3 个方面:

  • 基础镜像的准入:确保镜像仓库的基础镜像是经过安全扫描的,经构建编辑后的镜像需再次进行安全检查后才能发布到镜像仓库。
  • 强制要求对镜像仓库的所有镜像定期扫描,防止污染。
  • 上线后,要求持续监控镜像运行状态。

 

 3. 能力高可靠:威胁建模 /SAST/IAST/ 容器安全

 

(1)威胁建模更多发挥的是指导和培训的作用,往往在基础开发安全体系相对完善的单位中更为流行。威胁建模一般采用基于场景的问卷形式,研发的使用和学习成本相对较低,但也存在基于历史经验、针对新场景“无计可施”的缺点,建议针对新的业务场景,可在问卷完成后增加人工安全审核,提高威胁模型的可靠性。

 

(2)SAST 的作用因其误报等问题在近年来的市场应用中有所削弱,但 SAST 其中一个显著作用是作为 IAST 的缓冲,尤其是在业务并发量非常多的环境中,如果把所有安全检查全部放在测试阶段,整个流程运转必然会面临一定的“拥塞”局面。另外,想要提高 SAST 的扫描质量,无论是提高检出率还是降低误报,需要结合自身企业的开发框架和技术栈自定义大量扫描规则,有一定的规则运营成本。

 

(3)IAST 主要讨论的还是被动插桩,其优势也是业内公认的,如支持检测敏感数据、加密脱敏的场景,误报率低等;由于 IAST 技术实现原理不同,相对于 SAST,它的规则定制量会少很多;但存在一定的流程运营成本,需要在发布到测试环境的中完成插桩操作。

 

(4)在容器安全中,目前如能在构建、部署、运行三个阶段中做到安全控制已经相对比较理想,包括镜像安全检查,安全基线、Kubernetes 安全配置等检查,运行时的微隔离、网络通信监控、pod 运行进程监控等。

 

 4.制度与宣发:安全规范与安全文化建设

 

组织内部依据安全流程编写详细的安全制度和相应的奖惩制度,再根据制度发布关键的“安全红线”,重点解决“故意绕过安全措施”、“故意编写后门逻辑”等技术手段较难解决的问题。当然安全制度也要根据开发安全体系实际运营情况不断调整。

 

安全文化也可通过日常宣贯、定制化安全培训、考试激励以及纳入 KPI 等手段逐渐建立起来。

 

四、开发安全体系从 0 到 1 的步骤与建设收益

 

下图详细罗列了从 0 到 1 建设开发安全体系的建议步骤。除了前期整体的建设步骤,关键效果的显现离不开最后的精细化运营,即查缺补漏,重点解决一些痛点,例如越权漏洞的检测。

 

开发安全体系完整建设的关键收益主要体现在:

  • 提升系统安全,防止应用带病上线
  • 降低漏洞修复成本和修复效率,加快项目安全上线
  • 降低人工成本,赋能开发团队安全能力
  • 实现业务与安全的融合
  • 满足合规要求