10 Reasons why we need Application Security Testing Tools

Despite the fact that there are quite a few reservations concerning the use of application security scanning technologies (e.g. false positives, false negatives, usability and of course the price), there are also a couple of good reasons for using such tools:

1. Applications are becoming bigger and bigger

Enterprise applications can be quite big: 100,000 lines of code (100 KLOC) are some sort of lower boundary. Larger applications can easily have millions of lines of code. The same goes for the number of unique sites and business functions such a application can have. On the same hand, even a code reviewer will only be manage to analyses 1,000 lines of code (1 KLOC) a day.

2. Applications do often change

Especially agile developed (Web) applications are periodically changed every sprint (e.g. every two weeks). But changes can also occur in the environment or integration of a productive application. For instance, many Web applications are dynamically linked with other sites. Where some changes are trivial with no security impact, others will make a security review of the whole application necessary (e.g. due to architectural changes). Manual pentesting or code review cannot solve that problem. According to WhiteHat, the average amount of serious vulnerabilities introduced per website was 56 in 2012 (in the years before even much higher).

3. Tools can be executed by non-experts

Despite the well-known phrase “a fool with a tool is still a fool”, the required for performing a security assessment with a tool is much lower than without. Especially where more and more application-based threats are emerging, a pentester or code reviewer has to know a lot more than a few years ago. It still need some training to perform a decent tool-based assessment though.

4. Tools can be executed continuously

A tool-based assessment is not comparable with a manual one (e.g. a pentest or code review) in respect of the level of assurance it can reach. This is very well stated by the OWASP ASVS Standard and other publications. Although the reached assurance is lower it can be ensured due to periodic (even daily) scans.

5. Tools can make manual analysis much more efficient

Manual assessments (code reviews or pentests) based on tool-based scans can be much more efficient. Especially large code bases can be analyzed pretty well using such an approach. Many Low Hanging Fruits, that are often the point of attack for criminals, can be identified very efficiently with tool scan, before a manual assessments has even started. Also, tools will often give us indicators for possible vulnerabilities or weaknesses that can then be analyzed manually.

6. Tools can check specific policies and other requirements

Many tools allow the definition of very specific policies and can therefore be used to ensure that an application is compliant to a secure coding guideline.

7. Tools allow us standardized, objective and repeatable analysis

As long as the rule set does not change, a tool scan will always execute the same comprehensible tests cases on all applications. No test is left out my mistake or other reason.

8. Tools provide us metrics

Tools can provide us metrics – such as the security to quality defect ratio or the cyclomatic complexity that we can use to measure security and observe trending. In addition, results of scanning tools such as HP Fortify can be displayed in quality dashboard such as sonar, leading to a much more visible (in)security:
Fortify Plugin for Sonar

9. Tools are the foundation of sustainable and continuous improved security

Tool scans are based on policies and rules. Both can be customized and tuned. The more we work with such a tool we can improve its results.

10. Tools can be integrated in existing tools suites (e.g. in quality assurance)

We can integrate a security scanning tool in tool suites that are already in place and periodically executed by the quality assurance. This integration capability is yet only at its beginning but will surely be improved in the future.

All in all, we should be aware of tool limitations in general (and tool-specific ones too), but shouldn’t deny their capabilities (and benefit by using them) too.


About Matthias Rohr

Matthias Rohr, CISSP, CCSLP, is the founder and lead security architect at Secodis. Matthias began working in this field in 2004 and is since a frequent speaker on international AppSec conferences, book author, author of TSS-Web and an active AppSec community contributor. He lives and works in Hamburg / Germany.
This entry was posted in SAST and tagged , , . Bookmark the permalink.

2 Responses to 10 Reasons why we need Application Security Testing Tools

Leave a Reply

Your email address will not be published. Required fields are marked *