Static application security testing

Static application security testing (SAST) is part of technologies used to secure software by reviewing the source code of the software to identify sources of vulnerabilities. Although the process of statically analyzing the source code exists since computers exist, the technic largely expanded to security in the late 90s when Web applications integrated new technologies like JavaScript and Flash and the first public discussion of SQL injection in 1998.

Unlike dynamic application security testing (DAST) tools performing Black-box testing based on functionalities of applications, SAST tools focus on the technical content of the application by doing White-box testing. A SAST tool is a program that scans the source code of applications and its components to identify potential security vulnerabilities in the software and within its architectural organization. It is estimated that static analysis tools can detect about 50% of existing security vulnerabilities.[1].

Within the SDLC, SAST is performed early in the development process and is done at code level during the development process but also and when all pieces of code and components are put together using a consistent testing environment. SAST is based on static analysis which is also used to ensure quality of software[2] even if the large rate of false-positive is slowing down the adoption by developers[3].

SAST tools are integrated into the development process to help development teams as they are primarily focusing on developing and delivering software respecting requested specifications[4]. SAST tools, like other security tools, focus on reducing the risk of downtime of applications or that private information stored in applications will not be compromised.

For the year of 2018, the Privacy Rights Clearinghouse database[5] shows that more than 612 millions of records have been compromised by hacking.

Overview

The specific domain of application security is based on numerous tests of applications before they are released. To do so, there are different technics used: static application security testing (SAST), dynamic application security testing (DAST), and interactive application security testing (IAST) which is a combination of two previous techniques[6].

Static analysis tools examine the text of a program syntactically. They look for a fixed set of patterns or rules in the source code. Theoretically, they can also examine a compiled form of the software. This technic relies on instrumentation of the code to do the mapping between compiled components and source code components to identify issues. Static analysis can be done manually in a form of code review or auditing of the code for different purposes, including security. Although, it is time-consuming [7].

The precision of SAST tool is determined by its scope of analysis and techniques used to identify vulnerabilities. Different Level of analysis are:

• function level - a sequence of instruction
• file or class-level - an extensible program-code-template for creating objects
• application level - a program or group of programs that might have interactions between them.

The scope of analysis determines its accuracy and capacity in detecting vulnerabilities by using a wider contextual information[8].

Depending on the scope of the analysis, different techniques are used by SAST tools. At a function level, a common technique used is the construction of an Abstract syntax tree to control the flaw of data within the function [9].

Since late 90s, the need for adaptability to business challenges transforms the software development into a componentization of software[10] enforced by processes and organization of development teams[11]. Following the flaw of data among all the components of an application or group of applications allows to validate that required calls to dedicated procedures for sanitization and that proper actions are taken to taint data in specific pieces of code[12][13].

The rise of web applications implied a focus on testing them: it is reported by Verizon Data Breach that 40% of all data breaches were achieved using web application [14]. At the opposite of external security validations, there is a rise in focusing on internal threats. It is reported by the Clearswift Insider Threat Index (CITI) that 92% of their respondents in a 2015 survey that they experienced IT or security incidents in the past 12 months and 74% of these breaches were originated by insiders[15]. Lee Hadlington categorized internal threats in 3 categories: Malicious, Accidental, and Unintentional. Mobile applications growing explosively implies securing application earlier in the development process to reduce malicious code development[16].

SAST strengths

The earlier a vulnerability is fixed in the SDLC, the cheaper it will cost. Common measures of costs for fixing during the development is 10 times less than during the testing stage and 100 times less than during the production stage[17]. SAST tools are run automatically, either at the code level or application-level and do not require manual activities. When integrated into a CI/CD context, SAST tools can be used to automatically stop the integration process if critical vulnerabilities are identified[18]

Because the tool is scanning the entire source-code, it can cover 100% of it when dynamic application security testing covers the execution resulting in the possibility to miss part of the application[6] or missing unsecured configuration located in configuration files.

SAST tools can offer extended functionalities such as quality and architectural testing. In that case, the extension of security to these subjects enforces the security as there is a direct correlation between the quality and the security. Bad quality software are also poorly secured software [19].

SAST weaknesses

Even though developers are positive about the usage of SAST tools, there are different challenges with the adoption of SAST tools by developers[4].

With the development of Agile Processes into software development, the integration of SAST early in the process results in many problems as developers focus first on features and delivering something[20].

Scanning a large amount of line of code with SAST tools may result in hundreds or thousands of vulnerability warnings for a single application. It generates a large number of false-positives increasing the investigation time and reducing the trust in such tools. This is particularly the case when the context of the vulnerability cannot be caught by the tool[21]

References

1. Okun, V.; Guthrie, W. F.; Gaucher, H.; Black, P. E. (October 2007). "Effect of static analysis tools on software security: preliminary investigation" (PDF). Proceedings of the 2007 ACM Workshop on Quality of Protection. ACM: 1–5. doi:10.1145/1314257.1314260.
2. Ayewah, N.; Hovemeyer, D.; Morgenthaler, J.D.; Penix, J.; Pugh, W. (September 2008). "Using static analysis to find bugs". IEEE Software. IEEE. 25 (5): 22–29. doi:10.1109/MS.2008.130.
3. Johnson, Brittany; Song, Yooki; Murphy-Hill, Emerson; Bowdidge, Robert (May 2013). "Why don't software developers use static analysis tools to find bug". ICSE '13 Proceedings of the 2013 International Conference on Software Engineering: 672–681. ISBN 978-1-4673-3076-3.
4. Oyetoyan, Tosin Daniel; Milosheska, Bisera; Grini, Mari (May 2018). "Myths and Facts About Static Application Security Testing Tools: An Action Research at Telenor Digital". International Conference on Agile Software Development. Springer: 86–103.
5. "Data Breaches | Privacy Rights Clearinghouse". privacyrights.org.
6. Parizi, R. M.; Qian, K.; Shahriar, H.; Wu, F.; Tao, L. (July 2018). "Benchmark Requirements for Assessing Software Security Vulnerability Testing Tools". IEEE 42nd Annual Computer Software and Applications Conference (COMPSAC). IEEE: 825–826. doi:10.1109/COMPSAC.2018.00139. ISBN 978-1-5386-2666-5.
7. Chess, B.; McGraw, G. (December 2004). "Static analysis for security". IEEE Security & Privacy. IEEE. 2 (6): 76–79. doi:10.1109/MSP.2004.111.
8. Chess, B.; McGraw, G. (October 2004). "Risk Analysis in Software Design". IEEE Security & Privacy. IEEE. 2 (4): 76–84. doi:10.1109/MSP.2004.55.
9. Yamaguchi, Fabian; Lottmann, Markus; Rieck, Konrad (December 2012). "Generalized vulnerability extrapolation using abstract syntax trees". Proceedings of the 28th Annual Computer Security Applications Conference. IEEE. 2 (4): 359–368. doi:10.1145/2420950.2421003.
10. Booch, Grady; Kozaczynski, Wojtek (September 1998). "Component-Based Software Engineering". 2006 IEEE Symposium on Security and Privacy (S&P'06). IEEE Software. 15 (5): 34–36. doi:10.1109/MS.1998.714621.
11. Mezo, Peter; Jain, Radhika (December 2006). "Agile Software Development: Adaptive Systems Principles and Best Practices". 2006 IEEE Symposium on Security and Privacy (S&P'06). Information Systems Management. 23 (3): 19–30. doi:10.1201/1078.10580530/46108.23.3.20060601/93704.3.
12. Livshits, V.B.; Lam, M.S. (May 2006). "Finding Security Vulnerabilities in Java Applications with Static Analysis". USENIX Security Symposium. 14: 18.
13. Jovanovic, N.; Kruegel, C.; Kirda, E. (May 2006). "Pixy: a static analysis tool for detecting Web application vulnerabilities". 2006 IEEE Symposium on Security and Privacy (S&P'06). IEEE: 359–368. doi:10.1109/SP.2006.29. ISBN 0-7695-2574-1.
14. "2016 Data Breach Investigations Report" (PDF). 2016.
15. "Clearswift Insider Threat Index (CITI)" (PDF). 2015.
16. Xianyong, Meng; Qian, Kai; Lo, Dan; Bhattacharya, Prabir; Wu, Fan (June 2018). "Secure Mobile Software Development with Vulnerability Detectors in Static Code Analysis". 2018 International Symposium on Networks, Computers and Communications (ISNCC): 1–4. doi:10.1109/ISNCC.2018.8531071. ISBN 978-1-5386-3779-1.
17. Hossain, Shahadat (October 2018). "Rework and Reuse Effects in Software Economy". Global Journal of Computer Science and Technology.
18. Okun, V.; Guthrie, W. F.; Gaucher, H.; Black, P. E. (October 2007). "Effect of static analysis tools on software security: preliminary investigation" (PDF). Proceedings of the 2007 ACM Workshop on Quality of Protection. ACM: 1–5. doi:10.1145/1314257.1314260.
19. Siavvas, M.; Tsoukalas, D.; Janković, M.; Kehagias, D.; Chatzigeorgiou, A.; Tzovaras, D.; Aničić, N.; Gelenbe, E. (August 2019). "An Empirical Evaluation of the Relationship between Technical Debt and Software Security". 9th International Conference on Information Society and Technology. doi:10.5281/zenodo.3374712. |chapter= ignored (help)
20. Arreaza, Gustavo Jose Nieves (June 2019). "Methodology for Developing Secure Apps in the Clouds. (MDSAC) for IEEECS Conferences". 2019 6th IEEE International Conference on Cyber Security and Cloud Computing (CSCloud)/ 2019 5th IEEE International Conference on Edge Computing and Scalable Cloud (EdgeCom). IEEE: 102–106. doi:10.1109/CSCloud/EdgeCom.2019.00-11. ISBN 978-1-7281-1661-7.
21. Johnson, Brittany; Song, Yooki; Murphy-Hill, Emerson; Bowdidge, Robert (May 2013). "Why don't software developers use static analysis tools to find bug". ICSE '13 Proceedings of the 2013 International Conference on Software Engineering: 672–681. ISBN 978-1-4673-3076-3.