How do you fit security into your Continuous Integration (CI)? The common response would be, “We do not because … “. Well, you can, without a large effort or a large impact. At a high level you can integrate source code analysis into your daily integration builds so that you know if the change from the previous day has created a security issue. At a lower level you can integrate it into your private builds and check-in integration builds by targeting high value security issues (SQL Injection, Cross-Site Scripting, etc). If you have automated your deployment of a web application, you can even bring in a light-weight tool like RatProxy or more heavy-weight tools like Fortify 360 Program Trace Analyzer (PTA) to evaluate the running web application.
The most common excuse for not integrating security into a CI build is the “need for speed”. While I can relate to this excuse I, also, know that you can scan at different levels. For example, I scanned the WebGoat application with Fortify SCA out of the box and it took about 7 minutes, but when I set up the quick scan parameters in my ANT build it took about 5 minutes, a savings of about 30%. You can focus on the top issues and set up a rule pack such that only those issues are scanned for in the application and save even more time. I would do this quicker scan for the private and check-in builds, and would look for fuller if not the fullest scans at night or over the weekends.
But let’s step back a bit and look at SCA integration into the ANT script.
Using Fortify 360v2 Source Code Auditor (SCA) I will show that you can build security into you CI processes without a large impact. What you gain is a more secure application. Utilizing ANT and the SCA integration for ANT, you can incorporate the code scanning into your CI builds. Note: I ran the analysis on the WebGoat application from OWASP version 5.2.
I incorporated SCA into my ANT script following the 360 SCA user guide with some modifications to allow it to take advantage of how the SCA quick scan option works. Creating a new “fortify” task allowed me to control when it is run during the CI processes.Here are some of the ANT lines:
(The tool directory contains several different directories for tools used during the CI build. The report directory is a sub-directory of the build directory where the tools store their output for review.)
<property location=”${tools.dir}/fortify360v2″ name=”fortify.dir”></property>
<property location=”${report.dir}/fortify” name=”fortify.report.dir”></property>
<property location=”${fortify.report.dir}/log” name=”fortify.log.dir”></property>
<property location=”${fortify.report.dir}/audit” name=”fortify.audit.dir”></property>
<!– Fortify properties –>
<property name=”sourceanalyzer.buildid” value=”mybuild”></property>
<property name=”fortify.debug” value=”false”></property>
<property name=”fortify.verbose” value=”false”></property>
<!– Fortify Path –>
<path id=”fortify.classpath”></path>
<path refid=”test.classpath”></path>
<fileset dir=”${fortify.dir}” includes=”sourceanalyzer.jar”></fileset>
<taskdef code=”” name=”sourceanalyzer”><br>
classname=”com.fortify.dev.ant.SourceanalyzerTask”
classpathref=”fortify.classpath”/>
These lines, along with other instruction in the user guide, set up the ANT build to be able to use SCA and store the output in a common build area. Now let’s look at the task itself:
<antcall target=”clean”></antcall>
<mkdir dir=”${fortify.log.dir}”></mkdir>
<mkdir dir=”${fortify.audit.dir}”></mkdir>
<mkdir dir=”${findbugs.report.dir}”></mkdir><!– set up the quick scan properties –>
<property name=”com.fortify.sca.FilterSet” value=”Critical Exposure”></property>
<property name=”com.fortify.sca.FPRDisableSrcHtml” value=”true”></property>
<property code=”” name=”com.fortify.sca.limiters.ConstraintPredicateSize”><br>
value=”10000″/>
<property code=””name=”com.fortify.sca.BufferConfidenceInconclusiveOnTimeout”><br>
value=”false”/>
<property name=”com.fortify.sca.limiters.MaxChainDepth” value=”4″></property>
<property name=”com.fortify.sca.limiters.MaxTaintDefForVar” value=”500″></property>
<property code=”” name=”com.fortify.sca.limiters.MaxTaintDefForVarAbort”><br>
value=”100″/>
<property name=”com.fortify.sca.NullPtrMaxFunctionTime” value=”30000″></property>
<property name=”com.fortify.sca.CtrlflowMaxFunctionTime” value=”30000″></property>
<property name=”com.fortify.sca.TrackPaths” value=”NoJSP”></property>
<echo>sourceanalyzer compile</echo>
<antcall target=”compile”></antcall>
<param name=”com.fortify.sca.Debug” value=”${fortify.debug}”>
<param name=”com.fortify.sca.Verbose” value=”${fortify.verbose}”>
<param code=”” name=”com.fortify.sca.Logfile”><br>
value=”${fortify.log.dir}/${sourceanalyzer.buildid}-${DSTAMP}-${TSTAMP}.log”/>
<param name=”build.compiler” value=”com.fortify.dev.ant.SCACompiler”>
<echo>sourceanalyzer ${web.dir}</echo>
<sourceanalyzer buildid=”${sourceanalyzer.buildid}”></sourceanalyzer>
<fileset dir=”${web.dir}”></fileset>
<include name=”**/*.properties”></include>
<include name=”**/*.xml”></include>
<echo>sourceanalyzer jsp</echo>
<sourceanalyzer buildid=”${sourceanalyzer.buildid}”></sourceanalyzer>
<fileset dir=”${build.dir}”></fileset>
<include name=”**/*.jsp”></include>
<echo>sourceanalyzer scan</echo>
<sourceanalyzer buildid=”${sourceanalyzer.buildid}”
scan=”true”
resultsfile=”${fortify.audit.dir}/issues.fpr”
htmlReport=”true”
findbugs=”true”
logfile=”${fortify.log.dir}/${sourceanalyzer.buildid}-scan.log”
/>
<echo>sourceanalyzer done</echo>
I have highlighted a couple of areas to look at. First, since the SCA ANT integration does not support the command line option of –quick, I have put the properties that need to be set here so that it is all contained within the task. (You could use the quick scan properties file.) By adding these properties the scan has about a 30 percent time savings, though I did not scientifically verify that. You will notice that when scanning I also tell it to run FindBugs so that I do not need to run that externally. One other parameter I set is the htmlReport allowing the scan to build the results as an HTML page that I can link to the results from Hudson or some other CI tool.
In the table below I changed Max Chain Depth to see how it affected the outcome. You will notice that the standard scan finds significantly more issues at low and medium but there is not as much degradation in the high issues. The number of files and the lines of code scanned do not change. You can play around with the parameters to see what performance improvements you get that are still within your thresholdfor finding issues.
I hope I have shown you that you can bring security into your CI builds without a large performance impact. The main question you need to answer is: What is your threshold for finding the issues earlier verse the runtime of your private and check-in builds? With the understanding that you can tune the security scans through parameters or rule sets to meet those thresholds. No matter how you proceed I cannot recommend too strongly the need for the security scans in today’s world of the Internet.
