Source code analysis (or static analysis) software helps identify buggy code. Wouldn’t it be cheaper to write secure code in the first place? For a lot of enterprises, their legacy software has accrued years of technical debt, so the enterprise was unable to write secure and pristine code along the way.
One of the fastest growing areas in the software security industry is source code analysis tools, also known as static analysis tools. These tools review source code line by line to detect security vulnerabilities and provide advice on how to remediate problems they find – ideally before the code goes into production.
The entire software security market was worth about $300 million in 2007. It’s estimated that the tools portion of that market doubled from 2006 to 2007 to about $180 million. About half of that is attributable to static analysis tools, which amounted to about $91.9 million.
One of the fastest growing areas in the software security industry is source code analysis tools, also known as static analysis tools. These tools review source code line by line to detect security vulnerabilities and provide advice on how to remediate problems they find – ideally before the code goes into production.
The entire software security market was worth about $300 million in 2007. It’s estimated that the tools portion of that market doubled from 2006 to 2007 to about $180 million. About half of that is attributable to static analysis tools, which amounted to about $91.9 million.
And no wonder; according to Gartner, Inc., close to 90% of software attacks are aimed at the application layer. If security were integrated earlier in the software development lifecycle, flaws would be uncovered earlier, reducing costs and increasing efficiency compared with removing defects later through patches or never finding them at all. Although there is no replacement for security-aware design and a methodical approach to creating more secure applications, code-scanning tools are a very useful addition to the process.
Despite the high degree of awareness, many companies are behind the curve in their use of static analysis tools, possibly due to the big process changes that these tools entail.
Despite the high degree of awareness, many companies are behind the curve in their use of static analysis tools, possibly due to the big process changes that these tools entail.
Key Decisions in Source Code Analysis
1 Should you start with static tools or dynamic tools or use both?
In addition to static analysis, which reviews code before it goes live, there are also dynamic analysis tools, which conduct automated scans of production Web applications to unearth vulnerabilities. In other words, dynamic tools test from the outside in, while static tools test from the inside out. Many organizations start with dynamic testing, just to get a quick assessment of where their applications stand. In some cases, the groups that start this initiative are in security or audit compliance departments and don’t have access to source code. The natural second step is to follow up with static analyzers, enabling developers to fix the problems found by dynamic analysis tools. Some companies continue using both, because each type yields different findings.2 Do you have the source code?
Most static analyzers scan source code, but what happens if you want to analyze third-party software or code written so long ago that you only have the executable? In that case you could try a tool that offers binary code scanning through a software as a service platform. A vendor may not be willing to give you source code, but they will give you executables or binary in many cases.Source Code Analysis Tools: Evaluation Criteria
- Support for the programming languages you use. Some companies support mobile devices, while others concentrate on enterprise languages like Java, .Net, C, C++ and even Cobol.
- Good bug-finding performance, using a proof of concept assessment. Hint: Use an older build of code you had issues with and see how well the product catches bugs you had to find manually. Look for both thoroughness and accuracy. Fewer false positives means less manual work.
- Internal knowledge bases that provide descriptions of vulnerabilities and remediation information. Test for easy access and cross-referencing to discovered findings.
- Tight integration with your development platforms. Long-term, you’ll likely want developers to incorporate security analysis into their daily routines.
- A robust finding-suppression mechanism to prevent false positives from reoccurring once you’ve verified them as a non-issue.
- Ability to easily define additional rules so the tool can enforce internal coding policies.
- A centralized reporting component if you have a large team of developers and managers who want access to findings, trending and overview reporting.
Do’s and Don’ts of Source Code Analysis
- Don’t underestimate adoption time required. Most static analysis projects are initiated by security or compliance, not developers, who may not immediately embrace these tools.
- Do analyze pricing as different vendors have different pricing structures and your enterprise has different needs.
- Do plan to amend your processes. Tools are no replacement for strong processes that ensure application security from the beginning, starting with defining requirements, which should focus on security as much as functionality.
- Do retain the human element. While the tools will provide long lists of vulnerabilities, it takes a skilled professional to interpret and prioritize the results.
- Don’t forget the business case. You’ve got to unite the business and technical sides to ensure everyone is on the same page and that you know what to do with the results.
- Do consider using more than one tool or a tool that performs a variety of functions that will be critical to analyzing your legacy application.
Your Contact
Uta Daniels Assistant
of Sales Management
udaniels@pitss.com
+49 711/914-012-12