持续交付模式下的安全活动|洞见

在上一篇文章《开发团队面临的三大安全挑战》中,我们对现如今敏捷精益团队所面临的安全挑战进行了总结和分析,这三大挑战分别是:

  1. 一次性的安全检查无法匹配持续性的交付模式
  2. 缺乏自动化、自助化的支持,安全实践落地难
  3. 高耸的部门墙让开发和安全团队难以进行高效的协作

在接下来的几篇文章中,我们将逐一为你介绍团队、组织应该如何应对这些挑战。本篇文章先来讲讲如何解决第一个挑战。


采用持续性的、轻量级的,能够融入到持续交付模式的安全活动

对于绝大多数团队而言,为了确保开发出来的应用具有足够的安全性,渗透测试是一个被广泛采用的手段,也可以说是唯一依赖的手段。然而由于渗透测试比较重量级,通常只能提供一次性的安全反馈,而这在追求快速开发、迅速响应市场变化的敏捷精益开发方式下,它的不足被放大了。

团队需要的是一个高效的安全质量反馈机制。所谓“高效”是指,这个机制必须能以更快的速度、更高的频率提供应用的安全质量反馈,并且要足够轻量级以便于无缝融入到迭代交付过程中。

那么“更快”是多快?多频繁才算“更高的频率”?“轻量级”要轻到什么程度?

快到“立等可取”,比如只需几分钟甚至更少时间,就能知道应用的安全质量如何。

频繁到任意时刻都可以获取一次安全质量反馈,比如每次代码提交后,都能知道应用安全质量是否被破坏。

轻量级到团队不认为这些安全活动会带来多大的额外付出,比如每日代码审查中,顺便从安全的角度对代码进行评审,就能阻止有安全风险的代码被提交到代码仓库,而整个过程可能只多花费了几分钟时间而已。


一些推荐采用的安全活动

在CI中集成自动化安全扫描工具

其实在很早以前大家就已经发现,凭借人工的力量从应用里寻找安全漏洞异常耗时,另外对于某些安全漏洞,完全可以通过特征识别的方式对脚本来自动进行检测,于是从那时起就诞生了一系列自动化安全扫描工具,以下简称“漏扫工具”。

与此同时,在应用开发这件事情上,持续集成、持续交付的理念也在迅速的被广泛接纳,越来越多的团队开始使用CI,也体会到了自动化的威力所带来的好处。

随着CI的广泛普及,团队完全可以把这些漏扫工具集成到CI当中,作为应用构建过程中的一个标准步骤来执行。这样,团队既可以借助漏扫工具以节约人工成本,又可以持续性的对应用安全质量进行监控:一旦某次构建发现安全问题,构建流水线就会失败,引起开发团队的注意,促使团队尽快对有问题的代码进行修复,从而降低漏洞修复成本。

漏扫工具数量众多,可以说是百家争鸣,不过可惜的是,易于集成到CI中的却不多。OWASP ZAP提供了RESTful API,也有Jenkins插件,算是做得比较不错的漏扫工具,而BurpSuite要做到同样的效果还需要额外的配置才行。推荐团队可以先尝试把ZAP集成到CI中。关于具体的集成细节,我们会通过后续文章进行介绍。

编写自动化安全功能性测试用例

漏扫工具不是全能的,有些类型的安全漏洞,比如身份认证、访问控制以及和业务强相关的漏洞,它就很难甚至根本无法扫出来。然而,这些漏扫工具不容易扫出来的安全漏洞,对于人来讲却正好是小菜一碟。

举个例子:

人能够很好的理解下面这个API应当具备的安全行为,并对其进行有针对性的测试,然而漏扫工具则已经哭晕在厕所:

漏扫工具检查不出来的安全问题,人可以很好的进行测试,并且依然通过自动化来提高效率。团队可以像平常编写集成测试,或者端到端功能性测试那样,对于期望应用应当具备的安全行为,编写对应的测试用例进行覆盖。我们把这种做法叫做编写自动化安全功能性测试用例。

随着自动化安全功能性测试用例数量的不断累积,它的威力也将越来越明显,尤其是在对应用进行回归测试的时候,更是显露无疑。通常而言,在团队每次做应用发布之前,都会进行一次回归测试,主要目的是确认新功能工作正常,与此同时已有功能未被破坏。安全作为应用质量中的重要组成部分,也应该进行一次回归测试。相比于传统的渗透测试,自动化安全功能性测试用例再配合上CI中的自动化漏扫工具,在很短的时间里就能对应用进行比较全面的安全检查,为应用发布提供决策支持。

识别安全需求,并将其作为验收标准写入到用户故事卡

如果说把漏扫工具集成到CI,以及编写自动化安全功能性测试用例是在“把事情做对”,那么识别安全需求,并把它作为验收标准写入到用户故事卡中则是在“做正确的事情”。

团队其实是很重视安全的,他们愿意付出努力提升应用的安全性,然而这又和我们实际观察到的现状有冲突:安全的事情大家心知肚明,但就是没人主动去做。

为什么?原因是多方面的,其中一个重要的原因是,因为安全需求没有被明确提出来,它既不在故事卡的验收标准里,也没有在给故事卡估点的时候被考虑进去。于是安全需求就仿佛变成了“多出来的”工作量,一旦团队面临交付压力,这部分工作自然就会被无限期的往后推迟,最后的归宿就是不了了之。

因此,团队除了需要借助漏扫工具以及自动化安全性功能测试用例,还需要把安全需求明确出来,纳入到项目交付范围内。团队可以用威胁建模、恶意攻击场景头脑风暴等活动来梳理安全需求。

此外需要注意的是,安全需求的表现形式不是最重要的,最关键的在于把需求在团队内部明确出来,而不是大家心照不宣。比如,安全需求是写入到故事卡的验收标准里,还是单独创建安全故事卡,这本身并不重要,重要的是安全需求通过这些形式能得到明确,让团队能把安全需求和常规的业务需求一起放到Backlog里,统一对它们估点、设置优先级、安排迭代交付计划。


小结

敏捷精益团队面临的第一大安全挑战就是一次性的安全检查无法匹配持续性的交付模式。应对这一挑战,团队需要采用一系列持续性的、轻量级的,能够融入到持续交付模式的安全活动,从而使得团队建立起一个高效获取应用安全质量反馈的机制。

至于敏捷精益团队如何应对另外两大安全挑战,我们将在后续的文章里一一详解,敬请期待。


原文发布于微信公众号 - 思特沃克(ThoughtWorks)

原文发表时间:2017-09-12

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏ThoughtWorks

微服务的团队应对之道|TW洞见

这两年,微服务架构火了。在国内,从消费级互联网应用,到企业级应用;从金融领域,到电信领域;从新开发系统到已经开发了十几二十年的遗留系统;一夜之间,好像所有的团队...

31510
来自专栏达摩兵的技术空间

如何正确评估项目开发时间

一般情况下是因为我们评估的是直接的开发时间,而且是顺利情况、大家都了解需求,没有任何疑问和阻碍的情况下。实际上,这种非常顺利的场景基本不存在。

9103
来自专栏WeTest质量开放平台团队的专栏

WeTest适配测试报告2.0化繁为简,为你而来

曾经有一个适配测试报告摆在你的面前,而你可能苦于找不出最重要的问题在哪;如果您能给我们一次机会,我们会对您说四个字“不爽来试”。

1243
来自专栏Spark学习技巧

如何成为一名优秀的架构师?

想一下软件架构的评审过程:一位架构师参与进来,俯视一切然后指指点点,高谈阔论。他发表的评论要么过于粗浅,要么严重脱离实际。

1756
来自专栏Java架构师进阶

如何玩转微服务

2014年 Martin Flower 在《MicroServices》论文中首次提出了微服务的概念。近些年,伴随着互联网的日益发展,微服务在国内、甚至国际上的...

1153
来自专栏企鹅号快讯

小程序运营的六大基础能力

很多自媒体运营,对小程序的使用,以及结合公众号的引导成交做的还不够好,小程序上线已经快一年了,各种能力的开放,也极大方便了自媒体运营,尤其是自媒体电商的转化。今...

3726
来自专栏程序你好

微服务开发人员的七个基本技能

微服务越来越受欢迎,越来越多的开发人员开始使用微服务。如果你是一个开发微服务体系结构的开发人员,或者是想要雇佣一个人的雇主,那么,微服务开发人员最重要的技能是什...

944
来自专栏喔家ArchiSelf

DevOps 全栈必备双刃剑

作为一名全栈工程师,不仅是一个研发多面手,而且必须要关注产品的最终交付,以及线上服务的稳定运行。工具化使开发、交付、运维紧密地联系在一起,于是DevOps 逐渐...

1173
来自专栏云计算D1net

技术人上云的七个重要姿势

现在,业务上云已经成为一个潮流。尤其是对于公司内部的技术人员而言,经常会有很强的技术冲动去让业务上云。同时,云供应商们的大力宣传让公司决策层及业务人员对于上云也...

3396
来自专栏新智元

微软开源图数据查询语言LIKQ,海量图数据实时检索和集成触手可得

【新智元导读】 微软开源图数据查询语言 LIKQ,这是基于分布式大规模图数据处理引擎 Graph Engine 的一种可用于子图和路径查询的数据查询语言,强强联...

43010

扫码关注云+社区

领取腾讯云代金券