“I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”
When it comes to commercial and open source tools (i.e., paid and free software) the debate as to which category of software is better continues, leaving egos, careers, and forums in ruins. I personally think that it’s impossible to definitively prove that one class of software is the best for every situation. The best source code scanning tool in the world may not do a thing for you if it doesn’t run against your code.
Compared to the “openness” of open source software, closed source software’s proprietary nature is scary. Its source code is closed and unknowable. It is also controlled by entities that have the potential for evil. Or, if not particularly evil, they might disappear and leave their users in a permanently unsupported state. Proprietary software may have price tags that put it out of reach of your firm’s security budget. Finally, if something goes wrong, relying on proprietary support can make or break security operations.
Believe it or not, despite how free it is to procure open source software or join community forums, there are costs associated with using open source software. When bringing unvetted software into your environment, it should be checked over and scanned. If you aren’t paying for a support contract with the open source software’s development team, developers are left to rely on community support and internal know-how to keep a piece of open source software working.
These technical debts aren’t as large as the proponents of commercial, closed source software would have you believe. However, they aren’t as non-existent as the open source advocates promote either. Factor these concerns into the decision to pick a piece of software, but don’t let the support or vetting piece sway you away from a tool that is a better overall fit.
Let’s take a step back from software for a moment and reflect on the fact that I have eight different hammers in my toolbox. Now, I’m sure that some folks use a wrench to hang pictures… For me, each hammer serves a different purpose and not all of them include driving nails. My demolition hammer knocks holes into existing structures. Meanwhile, my mallet knocks things into place. Then again, my ball peen hammer helps me out when I’m working with metal. Just like my physical toolbox, my security toolbox has a variety of tools that may all look alike at first glance but actually serve very different purposes.
Identifying, remediating, and even preventing vulnerabilities should be the goal of any security team. If your security toolbox only contains open source or only closed source software, you may be ill equipped for the job at hand. Let’s look at some different tools so that you don’t have to treat everything like a nail:
Hewlett Packard’s Fortify Source Code Analyzer (SCA) was one of the first automated code scanners that did more than search for instances of strcpy() in code. It can scan 30+ languages and works well for organizations with a diverse development environment and a large number of applications in development. This monster of an application scanner works best when scanning as part of a regular scripted build.
While it can be run from developer workstations, the amount of time and hardware required to scan code can make it more of a hindrance to individuals. The reports that come out of periodic scans can be uploaded to a team collaboration server for further analysis and resolution. The built-in GUI is based off of Eclipse and offers many of the features developers are used to when tracing data and calls.
This is a high powered tool that can analyze a variety of programming languages and frameworks, but it also comes with a high-powered price tag.
IBM’s answer to Fortify’s SCA is another enterprise-level tool that is part of a suite of security testing tools. This tool is also best run as part of a build process where results combine with previous scans. This allows for the assignment of new vulnerabilities to developers. The results of the scans are the same, but AppScan Source’s GUI doesn’t offer the same amount of developer-friendly tools. Additionally, determining whether a vulnerability is a false positive or not may involve opening the project in another IDE such as Eclipse as the AppScan source GUI is lacking access to many features that developers are used to using when they have to make sense of code.
This open source tool can provide value to any Java development team. It focuses from top to bottom to scan for bugs in Java code. If you are running development shops that aren’t coding in Java, this tool will not work for them. These can also include security or quality issues.
Developers can work directly with FindBugs. It has plugins that work with many developer-level IDEs and automated build servers.
While not precisely a security analysis tool, SonarQube can incorporate security vulnerabilities identified by other applications into its quality checks. Quality software is secure. SonarQube can provide additional functionality that helps teams ensure that their software is up to snuff. This open source software can be configured to work with a variety of build servers to aid teams that want to get a handle on their quality and security concerns. It can accept findings from both closed source and open source tools and can turn the open source vs. closed source debate into a productive conversation.
Klocwork originally spun off from Nortel in the early 2000’s to commercialize an in-house development tool. The software runs like a spell-checker that points out vulnerabilities and errors as developers type them. This also closes the feedback loop and trains developers to not commit vulnerabilities back to the repository. Rather than waiting for a weekly scan and then parceling out the security fixes to random team members, Klocwork Insight puts the onus on the developer to fix and learn at that point.
Whether you need to knock out an entire application with a Fortify or AppScan sledge hammer, tack security details into place with a SonarQube finish hammer, or mold software into a secure solution with a ball peen Klocwork hammer, everybody benefits from the added security that automated source code analysis tools offer.
Your choice of a static analysis solution is based on many factors: security budget, development workflow, languages, frameworks, size of the codebase, existing tools, and other features of your development environment. Our white paper Enterprise or Open Source: Which SAST Tool Is Right for You? discusses these factors and offers a few recommendations.
Jamie Boote is a security consultant at Synopsys. He works with organizations to ensure their developers understand how to write secure code. Jamie believes that software security doesn't happen in isolation and needs effective communication between all levels of a company. When he's not advocating for the dinosaurs in any Perl vs. Python argument, Jamie can be found chasing his sons around Southern Florida.