What is VAddy?

VAddy is a web service that we are developing around the concept of a custom vulnerability scanner that works together with continuous integration (CI) tools to run security tests.

Once you’ve grown accustomed to the sense of security that comes with running unit tests (such as JUnit and PHPUnit) on a CI server (such as Jenkins) and automating browser tests via Selenium, it’s hard to go back to writing code any other way. However, it seems that security tests (vulnerability scans) and performance tests are still generally not run with CI tools.

It’s natural to think about implementing vulnerability scans (security tests) with CI tools—particularly in the English-speaking world, where blog articles, conference presentation materials, and other information is readily available. Much has been written about how to use OWASP ZAP with Jenkins, but this seems to take more effort than it should because ZAP was originally developed as a GUI tool.

Unlike ZAP and other existing tools, VAddy was designed from the ground up to work with CI tools. It’s easy to set up with your CI tools and—because it’s a cloud-based service (SaaS)—it doesn’t require any maintenance. Once you’ve configured it properly, VAddy will check for SQL injection, cross-site scripting, and other vulnerabilities on your web application every time you push up code.

Testing on a real-world project

When we first set out to develop VAddy, it was important for us to build a service that we would want to use ourselves. One of the first real-world projects that we started testing with VAddy is Scutum, another service we at Bitforest Co., Ltd. develop and run to protect the security of web applications.

We originally developed Scutum’s web application with the following tools:

Git and Bitbucket for source code management

Jenkins for continuous integration

Ant for build tasks

JRuby and shell scripts for (unit) tests

Selenium for browser tests

Tomcat for running the application

Whenever we pushed source code from our local Git repositories to Bitbucket, web hooks would cause jobs to run on our Jenkins server. Jenkins pulled the (new) source code from Bitbucket, built it with Ant, and then ran (unit) tests on the code. Finally, the web application was deployed to Apache Tomcat on our test server and Jenkins started the Selenium driver, which ran browser tests against the Tomcat server.

After we added VAddy to our development setup, the VAddy plugin installed on our Jenkins server would kick off a vulnerability scan following the Selenium browser tests. The VAddy plugin calls VAddy’s web API, causing VAddy’s servers to check for SQL injection and cross-site scripting vulnerabilities on our Tomcat server. If a vulnerability were to be found, the job would exit with an error and send us an email notification. This allows us to continuously deploy our application with confidence—we can trust VAddy to alert us if we ever neglect to escape an input parameter or inadvertently introduce some other vulnerability into our code.

If you’re already using Selenium, don’t miss out!

Before you can incorporate VAddy into your development workflow, you need to crawl your site and tell VAddy what to scan for vulnerabilities. Put another way, you need to give VAddy a sequence of URLs that represent a user session on your web application.

Selenium tests provide exactly such a sequence of URLs, so you don’t need to do much more than run Selenium to crawl your site with VAddy. Because Selenium and VAddy are so compatible with each other, you really would be missing out if you didn’t use the two together.

Sign up for an account and try it for yourself!

http://vaddy.net