I’ve already blogged about OWASP Dependency Check or its alternative SourceClear in the past. But there is more you can do about security in a typical (Jenkins) build. Although I’m calling this post “Security in the build pipeline” I’m not actually using the Jenkins pipeline as code feature. Security scans are independent of that, so it doesn’t matter whether you are using pipeline as code, a freestyle or a Maven job (or any other type you can think of). I’m focused on Jenkins, since that’s the build server I’m used to. However most of the tools should be available for other build servers as well.
This post is the start of a little series talking about security in the build pipeline. One important part of that – verifying that there a no known vulnerabilities in your dependencies – has been published already. Upcoming parts will take care of a vulnerability scan in the web application to build and scan for vulnerabilities in your actual code.
The “problem” with all these scans is, that they will slow down your build. Every single one. That’s why I recommend to not scan in a build job that has been started because of a source code change (a push in your Git repo). You usually want fast feedback for those jobs, and even some extra minutes for a simple scan will be too long. I recommend a nightly build for those scans, one which provides feedback (reports) in the morning for the architect or security champion who cleans those reports and assigns the stuff to fix to the team. A weekly security build is too rare, a nightly build is a good compromise.
It’s always helpful to assign a single person to validate all reports and prepare them for your daily or create bug tickets. There will be false positives, there will be duplicates and not every finding is important (right away). This person should – whenever supported by the tool or plug-in – create and maintain ignore lists (blacklists) to get rid of false positives as soon as possible. These tasks require a little more security knowledge than usually available, a perfect job for a security champion!
Always keep in mind that all those scans aim for the low hanging fruits. They can’t replace secure development, they don’t find every security vulnerability. And they don’t make pen tests and code reviews superfluous. Use them as an additional defense mechanism. Removing the low hanging fruits before a pen test forces the pentester hunting the more complicated vulnerabilities.
This was the first post for more security in your build, watch out for the next one to come. In the meanwhile – if you haven’t done so already – have a look at my post on scanning for known vulnerabilities in third party dependencies within Jenkins.