BDD-Security is a security testing framework that uses natural language in a Given, When, Then Gherkin syntax to describe security requirements as features. Those same requirements are also executable as standard unit/integration tests which means they can run as part of the build/test/deploy process.
Key Features
Free & Open Source automated testing framework for security
Ready to run on a Continuous Integration Server as part of the build/test/deploy process
Upgrade DevOps to DevSecOps
Generate reports easily viewed and understood by business and security users
Tests are run dynamically against a deployed application, no need to access your source code
How it works
Choose a basic architecture to start with
and test specific functional and non-functional security requirements:
Security features are defined up front and are exposed to the whole team, developers, operations and security; and can be tested at a moments notice. In fact they would ideally be run on a continuous integration server.
The framework is architectured so that security features and the application’s specific navigation logic are independent. This means that the same security requirements can be applied to multiple applications with minimal or no changes to the requirements themselves. Navigation logic goes into an application specific class file. This is similar in spirit to the page object pattern in that navigation is abstracted, but we don’t use separate objects for each page.
Simple
BDD-Security does not need access to your source code to run its tests! Although the BDD tests are backed by Java, they are all executed over the network against a running instance of your app. The app under test can be written in any language and framework. If it talks HTTP/S, BDD-Security can test it.
BDD-Security is written in Java and based on Cucumber, Selenium 2 (WebDriver), OWASP ZAP and a number of other security tools. This means that any automated testing can be performed, while describing the actions in a easily understandable format.
Testable Security requirements for DevOps
One of the guiding principles of DevOps is taking a systems approach to building services by breaking down the division between development and operations. This approach works equally well with security, and if we want to include security in the development and operations processes, then the security requirements and acceptance criteria should be exposed to, and understandable by those teams.
Security requirements are defined in one place, and can be tested on demand at any time, or even continuously.
BDD-Security reports are presented in Cucumber’s native JSON, XML and HTML formats in the: build/reports/cucumber directory
Prettier HTML reports are also generated by the cucumber-reporting project in the build/reports/cucumber/pretty directory
Standard JUnit reports are also generated if the “test” task is executed: build/test-results
The feature overview presents a summary of the test run.
Functional features such as the authorisation and access control feature provides a clear and detailed description of the tests.
While the automated scanning feature lists the results of the ZAP scans.
BDD-Security jobs can be run as a shell script or Gradle test and run from CI servers like Jenkins. The Jenkins Cucumber reporting plugin can be used to display the HTML reports.
OWASP Zap Java client
Java client library for OWASP ZAP. In addition to scanning and spidering, it also provides programmatic access to the proxy.
Visit Github repositoryNessus Java Client
A Java client to the Nessus scanner’s REST interface, supports both v5 and v6 The API is divided into a ScanClient and a ReportClient.
Visit Github repository