让安全实践在敏捷团队落地(2)

发表于:2017-03-16来源:infoq作者:刘建华点击数: 标签:安全
那么为什么攻击者可以获得Web系统权限呢?这种几率到底有多大呢?如果可能性非常小,我们是不是不必花费太多精力在安全上面呢? 我们来看一下Web系

那么为什么攻击者可以获得Web系统权限呢?这种几率到底有多大呢?如果可能性非常小,我们是不是不必花费太多精力在安全上面呢?

我们来看一下Web系统的组成,一个最简单的系统都至少有这么几个部分:

如上图,浏览器发送请求到服务器服务器给浏览器响应,服务器会查询数据库数据库返回结果。在这个过程中,我们开发的Web程序不可避免的存在安全漏洞,甚至我们开发系统所使用的编程语言也会有安全问题。在开发时,我们常常会引用一些第三方的工具、组件,而第三方的安全性也没有办法保障,甚至数据传输过程中使用的协议、操作系统本身也会有安全问题。所以可以想象一下,如果我们不做任何的安全防范,那么每一个软件都是一个非常脆弱的系统,很容易出现安全问题。

常见的Web安全问题

既然这么多环节都有潜在的安全风险,那么该如何着手呢?可以参考OWASP TOP 10,以便对最严重的Web应用程序安全问题有个大致的了解。

敏捷开发模式现状

我们是一个已经实施敏捷开发七年的团队,一共有五十多人,划分成不同的Feature小组进行日常的工作,其敏捷开发模式已经非常成熟,我所在的Feature小组有6个开发人员,1个业务分析师,1个QA,我们每个小组的交付模式都是这样的:

如上图,以用户故事为单元,所有的用户故事都会经历一个从分析到最后给客户演示的生命周期,多个用户故事组成一个Feature,然后我们会进行Feature的功能测试,给客户展示整个功能,最后在发布之前,客户会邀请第三方的专业安全公司做渗透测试,然后找我们的开发团队修复安全缺陷。

那么这种方式有什么问题呢?

1.守门员模式,安全测试非常滞后

2.安全问题的修复时间非常有限

3.只有少数人关注和了解安全

4.依赖独立的渗透测试

所谓守门员模式,指的就是把所有的问题和风险都留在最后,靠少数人来保障,在当时的开发模式下,第三方的安全公司就是我们系统的安全守门员,可想而知,如果我们的团队对安全没有任何了解,在用户故事的开发阶段引入的安全问题要等到发布之前才能够被发现,安全测试是非常滞后的,反馈周期特别长。

另外当第三方的安全公司发现问题,留给我们团队修复问题的时间特别有限,因为渗透测试是发布前的最后一个阶段,长时间的修复又会导致发布延期,所以经常会导致安全修复以补丁的方式发布。

而且除了少数修复过安全缺陷的开发人员对安全有一点点了解之外,团队内是没有人关心安全的。

最大的问题是,所有的安全防范都依赖于最后的独立渗透测试。虽然因为执行渗透测试的是专业的第三方安全公司,他们有专业的安全知识,可以发现很多公共的安全问题,也可以提供专业的极具权威性的安全报告,但这种方式的渗透测试有个致命的弱点,他们对业务知识了解不够,很难发现跟业务相关的安全问题,而这一类的安全问题又占了相当大的比重。

原文转自:http://www.infoq.com/cn/articles/let-safe-practices-land-in-the-agile-team