Integrating static analysis tools with build servers for continuous assurance
Learn how to set up continuous assurance with Code Dx to improve code quality and security at the speed of DevOps.
Continuous integration (CI) has made a tremendous impact on how we develop software. The concept is simple: fail fast and fail often. This allows the team to fix problems before they become a big deal, saving time and money. The term itself was first coined by Grady Booch in his 1993 book “Object-Oriented Analysis and Design with Applications”:
“At regular intervals, the process of ‘continuous integration’ yields executable releases that grow in functionality at every release…. It is through these milestones that management can measure progress and quality, and hence anticipate, identify, and then actively attach risks on an ongoing basis.”
It gained in popularity when Kent Beck and Martin Fowler extended and evangelized the concept in 1999 in their book, “eXtreme Programming (XP)”:
“A fully automated and reproducible build, including testing, […] runs many times a day. This allows each developer to integrate daily, thus reducing integration problems.”
Can you imagine developing software without continuous integration? I certainly cannot. The benefits of CI are numerous but for starters, it ensures that you always have a working build and consistent results, since the build is performed on the same machine. No more “works on my machine” issues. There’s also always a place to get the latest working build, which makes the current state of things visible to the entire team.
The beauty of CI is that it’s automated. Once you have a build set up and configured, you can just let the CI server do its thing. No more spending time doing manual, error-prone builds. Any time someone commits new code, the CI server is triggered to run a build or builds. If something goes wrong, the build will be marked broken, the developer who broke the build will get an email notification, and they’ll work to resolve the issue as soon as possible; otherwise their teammates will get on their case.
Automated builds are one thing, but where it gets interesting is the unit and integration tests that run as part of every build. Test-driven development is part of the build process, and automated regression tests run continuously.
Integrating frequently and automating the checks help ensure that issues are discovered early, which will make them easier to fix since the changes that caused the failure will be fresh in the developers’ minds. This also helps ensure that the amount of change will be minimal and it will be easier to track down the cause.
Continuous delivery and DevOps
Today, organizations are moving at an even faster pace with continuous delivery and DevOps. This is the process of pushing out releases to production very frequently, or even continuously (continuous deployment). Forget about releases twice a year, according to the “ASOC Handbook,” organizations like Etsy push out 60 updates per day, Amazon releases updates every second, and Netflix deploys 100 times per day. This pace makes it even more challenging to thoroughly test. Automation is the only way to do it. And when done correctly, many find that DevOps is easier, as fixing things that go wrong can happen so fast.
The CI process also be used to improve code quality and security, providing continuous assurance even in the fast-paced DevOps world.
Developers should be performing these important quality and security checks, as well as unit tests, during development in their IDE. However, having a central location is still necessary to make certain this testing is actually done. Build automation provides this workflow.
Setting up continuous assurance with Code Dx
Setting up continuous assurance with Code Dx is a breeze thanks to a REST API that integrates Code Dx with your existing CI build server. For those using the very popular Jenkins CI, Code Dx offers a native plugin. The rest of this section focuses on Jenkins integration and provides some tips for setting things up.
The first step is to install the Code Dx Jenkins plugin. This can be done simply by going to the Manage Plugins section of your Jenkins installation, searching for the Code Dx plugin, and following the instructions to install.
Once installed, you will see a new Publish to Code Dx post-build action for each Jenkins job. This allows you to add a continuous assurance step to your existing build process, which will likely be one of the last steps in your job after the binaries have been built and unit tests have been run.
The basic process is to tell the Code Dx Jenkins plugin where the source and binary files are located. The plugin will automatically zip up those files and send them to the Code Dx server specified for analysis. You also have the option to include commercial tool results as well.
You have the option to just fire off the Code Dx analysis and let the Jenkins build complete, or select Wait for Analysis Results to wait for Code Dx to finish its analysis. Waiting allows you to view summary results or break the build if Code Dx finds something.
Breaking the build
One of the great features of CI is that it allows you to set up conditions to break the build or mark a build as unstable. If a developer commits new code that causes something to fail, an email is sent to the author, the project lead, and/or the whole team.
For continuous assurance, you can also configure the system to break the build if a new high-severity finding appears. This provides automated assurance that any new high-severity issue will be automatically flagged and addressed.
The Code Dx Jenkins plugin provides a high-level summary including a table breakdown of the number of findings and a breakdown of the current status of each finding. Possible status includes New (not seen in last build), Unresolved (appeared in last build and is still there), False Positive, Escalated, or Assigned to a developer. Each entry also shows the change since the last build.
You can access the details of the findings via the Code Dx web interface. A link to the latest results is available directly from the Jenkins page (View latest in Code Dx). Also, Code Dx has IDE plugins that can be used to view and remediate the findings.
The Code Dx Jenkins plugin also allows you to monitor trends. Are the number of high-severity findings going up or down? How fast are you resolving findings after they are discovered? Are you keeping up with new findings?
When analysis tools take a long time to run
The analysis tools bundled with Code Dx are designed to be fast, usually completing in a matter of minutes for most projects. This fits well with CI principles; otherwise, you introduce a gap between when the problem was introduced and when the developers are made aware of it, which can make it harder for the developer to fix since they’ve most likely moved on to another task.
Commercial tools such as HP Fortify or IBM AppScan can take considerably longer to run, often for good reason since they are doing in-depth analysis, but integrating these with an automated build can be a challenge. Even Code Dx’s bundled tools can take longer than acceptable for really large projects.
Creating a build pipeline with downstream Jenkins chained jobs can be helpful since you will get your build results right away and the longer-running analysis will come later. However, if it’s going to take several hours to run your static analysis tools, you probably do not want to run on every code commit happening throughout the day. Your static analysis job will never be able to catch up, especially if you have multiple projects contending for the same system resources.
One solution is to run static analysis tools as part of a separate Jenkins job, or run them nightly or twice a day instead of with every commit.
Jenkins makes this simple. Just create a new Jenkins job for continuous assurance.
Then set the build trigger to run at midnight and noon.
Next, set up the build for the new job. One way to do this is to copy your main project and run through the whole build again. But I wouldn’t recommend that unless the source code analysis tool you’re using requires it. Also, the job configuration can get complicated, and then you’d be stuck keeping both jobs up-to-date as changes are made.
Instead, a nice solution is to use the Jenkins Clone Workspace SCM plugin. This allows you to copy selected workspaces files from another job.
After installing that plugin, you can then do something like what is shown below in your main job to clone the source and bytecode. Or you can leave it blank to clone the whole workspace.
And you can do something like this in your continuous assurance long-running job.
You can then build steps in to run your commercial tools, and send your source/bytecode to Code Dx along with your commercial tool results using the Code Dx post-build action.
I hope this helps you take CI to the next level by making continuous assurance part of your SDLC.
Want to learn more?
*** This is a Security Bloggers Network syndicated blog from Software Integrity Blog authored by Synopsys Editorial Team. Read the original post at: https://www.synopsys.com/blogs/software-security/integrating-static-analysis-tools-with-build-servers-for-continuous-assurance/