AppScan’s new Application Discovery Assistant (ADA) saves the Day!!

The next release of AppScan was announced June 5^th and while it will not be ready for customers until June 12^th, I was able to obtain a pre-release copy and started to exercise some of the new capabilities.  I was specifically interested in checking out some of the new tools for on-boarding applications quickly.

Have you ever had to perform a static analysis security assessment of an application, but didn’t know where or what all the parts and pieces are?  Most reviews start when the developer gives you a massive zip file of the “application” or you check-out the source code directly from the source code repository.  As a security guy, with a development background and who has built and reviewed hundreds of applications, it’s always a daunting task to find all the buildable source code and the dependent libraries from distributions like these.  

As a security analyst that has never built source code for static analysis scanning, it’s a near impossible task without significant developer help.  Configuring a complicated application for source code scanning is often the most important, but tedious, part of tool-assisted manual source code review.  Over the years, I’ve performed many source code security assessments and the new AppScan 8.6 - Application Discovery Assistant (ADA) is a significant step in simplifying the configuration process.

In order to show the features of ADA, I will walk through the AppScan Source configuration of the open source tools Sonar and JSPWiki.  Sonar because it uses a maven build and has a lot of individual projects as part of the application.  JSPWiki because it is an ant build and has many JSPs.  Both of these are good candidates to see what ADA is capable of.  Key requirements for a good candidate are:

• Limited to no familiarity with the code base
• Multiple projects within the application
• Relatively complex manual build (I will not be using the ant or maven AppScan integrations)
• Reasonably sized   (At least 150 KLoC)

Once I was synched to the code bases, I was ready to try a couple of different approaches:

1. Point and shoot
2. Tune to exclude obvious test code and create reusable configuration files for continuous integration scanning

Point and Shoot Configuration

I was pleased at how simple the out-of-the-box configuration was.  Using the Quick Start guidance I chose “Discover Applications…” and pointed ADA to the root directory for each project.

Step 1 – Discover Applications, starts the discovery process.

Sonar	JSPWiki

Step 2 - Search Location, specify where discovery searches for source code and dependencies.

For the Sonar application, I added the location of the maven repository as a dependency search location. These were the only steps required to correctly configure each application for scanning.

Sonar	JSPWiki
	No configuration required

Step 3 - Dependency Search Location (Optional), only needed if dependencies are outside of search path.

After starting the discovery, it spinned and whirred for about 3 minutes and provided detailed feedback. Upon completion it produced a nice summary screen of any errors and warnings and gave me the option to go back and change any configurations.  The Discovery Report showed me that I had 3 missing Sonar dependencies and a clean discovery for JSPWiki.

Sonar	JSPWiki
	No warnings

Step 4 – Review Creation Summary, clearly denotes if anything went wrong with the discovery process.

The discovery process completed in about 4 minutes from start to finish for each application. I was ready to scan.  I used the new Quick Scan scan configuration to generate my assessment results (I’ll blog about those settings at a later date).

	Sonar	JSPWiki
Projects	72	2
Files	2696	871
Configuration Time	4 Minutes	3 Minutes
Scan Time	1 hour	48 minutes
Scan Results	Good	Good
Notes	Had expected compilation errors in test-resources from missing dependencies.  Scanned many test directories.	Had several processing restricted messages due to time limitations imposed by Quick Scan configuration. Scanned many test directories

Results for Point and Shoot Configuration – using Quick Scan

Tuned Configuration

Now that my initial out-of-the-box test configurations were complete, I wanted to remove all the test projects, metrics, and test resources that were included in the above configurations.  I used the ADA exclusions to remove these projects as part of my configuration.  Taking a quick look at the projects inside AppScan’s project explorer for the above configurations, I decided to exclude:

Sonar	JSPWiki
\target  – a maven generated build directory	\tests  – directory for unit tests
\test-resources  – stuff used for unit tests
\.git  – the github repository directory
\sonar-testing-harness  – test harness directory

I could have right-clicked and deleted these projects inside the project explorer, but I wanted to see how well the ADA exclusions worked and if I could easily create a more targeted solution.  I deleted all previous configurations and restarted the AppScan client to clear any caching and to avoid skewing the results.  I followed the exact same steps as above except I added the above exclusions in the Exclusion Rules step of ADA. 

Sonar	JSPWiki

Step 3a – Exclusion Rules (Optional), allows the exclusion of portions of a project

The next step in the ADA flow was a project creation tab.  I wanted to reuse my project configurations for continuous scanning so I added a working directory for ADA configuration files.  This working directory is also the location of where AppScan will output any additional configuration, caching, and staging files.  Specifying the working directory allows me to easily reuse my configuration in another scanning environment.

Sonar	JSPWiki

Step 3b - Project Creation (Optional), allows “advanced” configurations.  I wanted to use the discovery configurations for my continuous integration scanning environment.

The discovery process was a little faster with the exclusions as it didn’t process the test directories. When it completed, I had an application configured and ready to scan. I right clicked on the application in the AppScan project explorer and used the new “Quick Scan” option to perform the vulnerability assessment.  The scans for these projects were significantly faster because these configurations were not scanning the test code.

	Sonar	JSPWiki
Projects	33	1
Files	1541	452
Configuration Time	6 Minutes	4 Minutes
Scan Time	10 Minutes	27 Minutes
Scan Results	Good	Good
Notes	Clean build and scan.  Excluding the test directories using patterns significantly decreased the amount of triage work that will be required.	Had several processing restricted messages due to time limitations imposed by Quick Scan configuration (Using Normal Scan would eliminate these).  Excluding the test directories using patterns significantly decreased the amount of triage work that will be required.

Results for Tuned Configuration – using Quick Scan

Summary

Having spent the last several years manually configuring buildable projects, the new Application Discovery Assistant (ADA) is an impressive step forward.   ADA worked well and the 1-4 configuration screens are clear and easy to use.   Spending a few additional minutes to exclude the obvious test files made the ADA configuration something I could use for both tool assisted manual review and automated scanning.  What would normally have taken me most of a day to understand and configure, took minutes when using the ADA.  So really, the new ADA saves the day!

Comments

[Jason Suplizio]

Excellent blog! I'm in the process of integrating AppScan with Jenkins. For continuous delivery (CI), using the steps you outlined, were you able to have your CI environment publish to the directory you specified in ADA and did AppScan just listen for any changes to that directory and rescan continuously? Also, were you able to have AppScan report build pass/failure back to the CI?