合规就代表安全了吗？那可以不一定

前言

2018年，5G标准、中芯案件，使得技术博弈、话语权博弈持续发酵，深刻改变着数字经济的利益格局和安全格局。GDPR落地已经半年有余，我国《网络安全法》也正式实施一年了，全球范围内围绕网络安全、数据保护等重要制度立法、执法和司法活动都在积极推动。但是一部分企业在合规过程中往往被一叶障目，以为合规了数据就安全了，真的是这样吗？

概述

企业中的开发部门和网络安全部门的责任划分、目标和动机有着很大的不同，不可避免地会产生诸多冲突。在新应用、新功能的开发过程中，企业一般通过引入代码扫描 工具 来确保安全，以便在上线之前发现漏洞并进行修复。但是随着企业合规需求的不断上升，对于一些企业而言，网络安全建设的重心转向了如何满足法律法规的监管，这就有可能出现本末倒置引发的问题。

这里举一个来自于电子支付领域的典型例子。对于存储了用户财产信息的支付系统来说，应当以确保所在目标系统和数据的机密性、完整性和可用性为前提。但是合规性需求一来，对于质量安全评估员（QSA）而言获得支付卡行业数据安全标准（PCI-DSS）认证就变成最高优先级事件了。

比如2008年Heartland支付系统数据泄露的例子，虽然有点老，但是说明的问题很典型。就是到了现在，它还是有史以来最大的数据泄漏事件之一，当年超过1亿人的个人信息和支付卡数据被盗，超过600家公司受到影响，损失总额达数亿美元。Heartland符合PCI-DSS，在发现违规行为的两周前刚刚通过合规审计。造成该事件的原因是攻击者通过 SQL 注入漏洞成功渗透到系统内部，并非是零日攻击或APT。漏洞所在模块是用于处理支付卡数据，因此不在PCI QSA的审核范围内。

合规与安全建设

合规计划与安全建设应当作为两条轨道同时进行，合规计划不应管理安全计划的运作。任何行业标准下的要求应当作为组织的安全底线，而不是终极目标。合规团队的目标是满足最低安全标准，这些标准由第三方定义，不会考虑每个企业的独特业务背景，只是推进某种业务功能而不是强制保证全面安全。

那么，企业开发流程中的安全建设该如何适应？每个开发生命周期都必须根据业务需求、开发节奏和使用的技术进行自定义设计，以下五点可以作为参考：

一、光扫描是不够的，还需要持续跟踪和修正

要提升开发流程安全性，光扫描和报告漏洞是不够的，必须要有能够在整个开发周期中进行全面安全管理的一套工具/系统，支持提供以下信息：

有关开放漏洞的最新统计数据；

统计数据的时间窗口；

漏洞的历史趋势；

安全缺陷密度统计和趋势。

该工具应当支持集成基础架构漏洞管理报告，让高级管理人员明确了解整体风险，并了解具体针对哪些领域。

二、推进SDLC中的安全流程标准化

标准化保证每个开发阶段安全性的必要条件。针对软件开发生命周期（SDLC）而言，团队是否遵循每年一次的大规模部署的瀑布流程，或者包含持续集成/持续部署通道，这些因素并不是最重要的。每个人都知道会进行安全测试，比如静态分析/检测并修复任何已识别的漏洞。

所以要注意的一点是，SDLC还必须包括安全维护这一环节。一旦推向生产环节，项目往往会冻结，有时候开发人员不会参与下一个版本的工作。在源代码中发现新漏洞时该怎么办？必须有一个持续的版本维护流程来确保安全。

三、使用经过验证的技术

基于知名和成熟的技术来构建标准化的安全流程可以让安全团队更加专注和专业。分析师熟悉语言语法能够协助开发人员，针对特定语言和版本定制自动化工具。建立第三方库和框架的索引可以更方便地进行管理，在发生问题时快速急行补救，并可降低使用流氓库的可能性。

四、上下一心

如果高层管理人员三心二意，那么就算是世界上最好的安全计划也无计可施，安全团队要向管理人员和利益相关方传达安全开发流程的好处，能够带来哪些绩效上的提升。

五、开发人员教育

在开发时引入漏洞是源代码出现问题的根源，相当一部分比例的计算机科学专业毕业生从未接触过最基本的安全实践准则或原则。要解决这个问题需要在安全发展计划中纳入继续教育这一块的内容而且应当是从全面的安全基础教育开始，而不是那种蜻蜓点水式的培训。形式上可以是午餐会、学习小组、现场活动等，当他们深入了解代码阶段引入的各种问题让安全团队多么头大时，代码质量就会相应提升。

*参考来源： darkreading ，Freddy编译整理，转载请注明来自 FreeBuf.COM。