Static application security testing: Difference between revisions

Content deleted Content added
SAST weaknesses: Imp trans
Tags: Mobile edit Mobile web edit Advanced mobile edit
m Minor writing enhancements and linking
 
(43 intermediate revisions by 28 users not shown)
Line 1:
{{Short description|Software securing application}}
'''Static application security testing''' (SAST) is used to secure software by reviewing the source code of the software to identify sources of vulnerabilities. Although the process of [[Static program analysis|statically analyzing the source code]] has existed as long as computers have existed, the technique spread to security in the late 90s and the first public discussion of [[SQL injection]] in 1998.tv when Web applications integrated new technologies like [[JavaScript]] and [[Adobe Flash Player|Flash]].
'''Static application security testing''' ('''SAST''') is used to secure [[software]] by reviewing its [[source code]] to identify security vulnerabilities. Although the process of [[Informal methods of validation and verification#Desk checking|checking programs by reading their code]] (modernly known as [[Static program analysis|static program analysis]]) has existed as long as computers have existed, the technique spread to security in the late 90s and the first public discussion of [[SQL injection]] in 1998 when [[Web application|web applications]] integrated new technologies like [[JavaScript]] and [[Adobe Flash Player|Flash]].
 
Unlike [[dynamic application security testing]] (DAST) tools for [[black-box testing]] of application functionality, SAST tools focus on the code content of the application, [[white-box testing]]. A SAST tool scans the source code of applications and their components to identify potential security vulnerabilities in their software and architecture. Static analysis tools can detect an estimated 50% of existing security vulnerabilities in tested applications.<ref>
{{Cite book
An SAST tool scans the source code of applications and its components to identify potential security vulnerabilities in their software and architecture.
Static analysis tools can detect an estimated 50% of existing security vulnerabilities.<ref>
{{Cite journal
|last1=Okun|first1=V.
|last2=Guthrie|first2=W. F.
|last3=Gaucher|first3=H.
|last4=Black|first4=P. E.
|title=Proceedings of the 2007 ACM workshop on Quality of protection
|chapter=Effect of static analysis tools on software security: Preliminary investigation
|s2cid=6663970
|date=October 2007
|title= Effect of static analysis tools on software security: preliminary investigation.
|journal=Proceedings of the 2007 ACM Workshop on Quality of Protection
|pages=1–5
|publisher=ACM
|doi=10.1145/1314257.1314260
|isbn=978-1-59593-885-5
|url=https://samate.nist.gov/docs/SA_tool_effect_QoP.pdf
|chapter-url=https://samate.nist.gov/docs/SA_tool_effect_QoP.pdf
}}</ref>.
}}</ref>
 
In the [[Softwaresoftware development process|SDLClife cycle]] (SDLC), SAST is performed early in the development process and at code level, and also when all pieces of code and components are put together in a consistent testing environment. SAST is also used for software quality assurance.,<ref>
{{Cite journal
|last1=Ayewah|first1=N.
Line 35:
|publisher=IEEE
|doi=10.1109/MS.2008.130
}} </ref> even if the many resulting [[False_positives_and_false_negativesFalse positives and false negatives#False_positive_errorFalse positive error|false-positive positives]] impede its adoption by developers.<ref name="ReferenceA">{{Cite book
{{Cite journal
|last1=Johnson|first1=Brittany
|last2=Song|first2=Yooki
|last3=Murphy-Hill|first3=Emerson
|last4=Bowdidge|first4=Robert
|title=2013 35th International Conference on Software Engineering (ICSE)
|chapter=Why don't software developers use static analysis tools to find bugs?
|date=May 2013
|title= Why don't software developers use static analysis tools to find bug
|journal=ICSE '13 Proceedings of the 2013 International Conference on Software Engineering
|pages=672–681
|doi=10.1109/ICSE.2013.6606613
|isbn=978-1-4673-3076-3
}}</ref>
</ref>
 
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.<ref name="auto">
{{Cite journal
|last1=Oyetoyan|first1=Tosin Daniel
Line 59 ⟶ 58:
|pages=86–103
|publisher=Springer
}}</ref> SAST tools, like other security tools, focus on reducing the risk of downtime of applications or that private information stored in applications is not compromised.
}}</ref>.
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<ref>{{Cite web|url=https://privacyrights.org/data-breaches|title=Data Breaches &#124; Privacy Rights Clearinghouse|website=privacyrights.org}}</ref> shows that more than 612 millions ofmillion records in the [[United States]] have been compromised by hacking.
 
==Overview==
 
The specific ___domain of applicationApplication security is based on numerous tests of applicationsconducted before theytheir arerelease released:include static application security testing (SAST), [[dynamic application security testing]] (DAST), and [[interactive application security testing]] (IAST), which is a combination of the two.<ref name="auto1">
{{Cite journalbook
|last1=Parizi|first1=R. M.
|last2=Qian|first2=K.
Line 73 ⟶ 71:
|last4=Wu|first4=F.
|last5=Tao|first5=L.
|title=2018 IEEE 42nd Annual Computer Software and Applications Conference (COMPSAC)
|chapter=Benchmark Requirements for Assessing Software Security Vulnerability Testing Tools
|s2cid=52055661
|date=July 2018
|title= Benchmark Requirements for Assessing Software Security Vulnerability Testing Tools.
|journal=IEEE 42nd Annual Computer Software and Applications Conference (COMPSAC)
|pages=825–826
|publisher=IEEE
|doi=10.1109/COMPSAC.2018.00139
|isbn=978-1-5386-2666-5
}}</ref>.
 
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 technictechnique 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 as a [[code review]] or [[Software audit review|auditing]] of the code for different purposes, including security, but it is time-consuming.<ref>
Static analysis can be done manually in a form of [[Code review|code review]] or [[Software audit review|auditing]] of the code for different purposes, including security. Although, it is time-consuming <ref>
{{Cite journal
|last1=Chess|first1=B.
Line 96 ⟶ 93:
|publisher=IEEE
|doi=10.1109/MSP.2004.111
}}</ref>.
 
The precision of SAST tooltools is determined by itstheir scope of analysis and the specific techniques used to identify vulnerabilities. Different Levellevels of analysis areinclude the following:
* [[Subroutine|functionFunction level]]: - a sequenceSequences of instruction
* [[Class (computer programming)|fileFile or class- level]]: - anAn extensible program-code-template for creatingobject objectscreation
* [[Application software|applicationApplication level]]: - aA program or group of programs that might have interactions between them.interact
The scope of the analysis determines its accuracy and capacity into detectingdetect vulnerabilities by using a wider contextual information.<ref>
{{Cite journal
|last1=Chess|first1=B.
Line 114 ⟶ 111:
|publisher=IEEE
|doi=10.1109/MSP.2004.55
|doi-access=free
}}</ref>.
}}</ref> SAST tools, unlike [[Dynamic application security testing|DAST]] tools, give developers real-time feedback, and help them secure flaws before they move the code to the next level.
 
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 flawflow of data within the function .<ref>
{{Cite journalbook
|last1=Yamaguchi|first1=Fabian
|last2=Lottmann|first2=Markus
|last3=Rieck|first3=Konrad
|title=Proceedings of the 28th Annual Computer Security Applications Conference
|chapter=Generalized vulnerability extrapolation using abstract syntax trees
|s2cid=8970125
|date=December 2012
|title=Generalized vulnerability extrapolation using abstract syntax trees
|journal=Proceedings of the 28th Annual Computer Security Applications Conference
|volume=2
|issue=4
Line 130 ⟶ 128:
|publisher=IEEE
|doi=10.1145/2420950.2421003
|isbn=9781450313124
}}</ref>.
}}</ref>
 
Since the late 90s, the need forto adaptabilityadapt to business challenges transformshas thetransformed software development into awith componentization of software<ref>
{{Cite journal
|last1=Booch |first1=Grady
Line 139 ⟶ 138:
|date=September 1998
|title=Component-Based Software Engineering
|journal=2006 IEEE Symposium on Security and Privacy (S&P'06)
|pages=34–36
|volume=15
|issue=5
|publisherjournal=IEEE Software
|doi=10.1109/MS.1998.714621
}}</ref> enforced by processes and organization of development teams.<ref>
{{Cite journal
|last1=Mezo |first1=Peter
Line 152 ⟶ 150:
|date=December 2006
|title=Agile Software Development: Adaptive Systems Principles and Best Practices
|journal=2006 IEEE Symposium on Security and Privacy (S&P'06)
|pages=19–30
|volume=23
|issue=3
|publisherjournal=Information Systems Management
|doi=10.1201/1078.10580530/46108.23.3.20060601/93704.3
}}</ref> Following the flow of data between all the components of an application or group of applications allows validation of required calls to dedicated procedures for [[Code injection#Preventing problems|sanitization]] and that proper actions are taken to taint data in specific pieces of code.<ref>
}}</ref>.
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 [[Code_injection#Preventing_problems|sanitization]] and that proper actions are taken to taint data in specific pieces of code<ref>
{{Cite journal
|last1=Livshits|first1=V.B.
Line 169 ⟶ 165:
| volume=14
}}</ref><ref>
{{Cite journalbook
|last1=Jovanovic |first1=N.
|last2=Kruegel |first2=C.
|last3=Kirda|first3=E.
|title=2006 IEEE Symposium on Security and Privacy (S&P'06)
|chapter=Pixy: A static analysis tool for detecting Web application vulnerabilities
|s2cid=1042585
|date=May 2006
|title=Pixy: a static analysis tool for detecting Web application vulnerabilities
|journal=2006 IEEE Symposium on Security and Privacy (S&P'06)
|pages=359–368
|publisher=IEEE
|doi=10.1109/SP.2006.29
|isbn=0-7695-2574-1
}}</ref>.
 
The rise of web applications entailed testing them: Verizon Data Breach reported in 2016 that 40% of all data breaches use web application vulnerabilities.<ref name=DBI_1>{{cite web| title=2016 Data Breach Investigations Report| url=https://www.verizon.com/business/resources/Ta80/reports/DBIR_2016_Report.pdf| publisher=[[Verizon]]| date=2016| access-date=8 January 2016}}</ref> Both external security validations and a focus on internal threats have risen. The Clearswift Insider Threat Index (CITI) has reported that 92% of their respondents in a 2015 survey said they had experienced IT or security incidents in the previous 12 months and that 74% of these breaches were originated by insiders.<ref name=CITI_2>{{cite web| title=Clearswift report: 40 percent of firms expect a data breach in the Next Year| url=https://www.securityinfowatch.com/cybersecurity/information-security/press-release/12141612/clearview-clearswift-report-40-percent-of-firms-expect-a-data-breach-in-the-next-year| publisher=Endeavor Business Media| date=20 November 2015| access-date=8 January 2024}}</ref><ref name=CITI_1>{{cite web| title=The Ticking Time Bomb: 40% of Firms Expect an Insider Data Breach in the Next 12 Months| url=https://www.clearswift.com/resources/press-releases/ticking-time-bomb-40-firms-expect-insider-data-breach-next-12-months| publisher=Fortra| date=18 November 2015| access-date=8 January 2024}}</ref> Lee Hadlington categorized internal threats in 3 categories: malicious, accidental, and unintentional. Mobile applications' explosive growth implies securing applications earlier in the development process to reduce malicious code development.<ref>
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 <ref>{{cite web |url= https://enterprise.verizon.com/resources/reports/2016/DBIR_2016_Report.pdf |title= 2016 Data Breach Investigations Report |date = 2016}}</ref>.
{{Cite book
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<ref>{{cite web |url= http://pages.clearswift.com/rs/591-QHZ-135/images/Clearswift_Insider_Threat_Index_2015_US.pdf |title= Clearswift Insider Threat Index (CITI) |date=2015}}</ref>. 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<ref>
{{Cite journal
|last1=Xianyong|first1=Meng
|last2=Qian|first2= Kai
Line 191 ⟶ 186:
|last4=Bhattacharya|first4= Prabir
|last5=Wu|first5=Fan
|title=2018 International Symposium on Networks, Computers and Communications (ISNCC)
|chapter=Secure Mobile Software Development with Vulnerability Detectors in Static Code Analysis
|s2cid=53288239
|date=June 2018
|title= Secure Mobile Software Development with Vulnerability Detectors in Static Code Analysis
|journal=2018 International Symposium on Networks, Computers and Communications (ISNCC)
|pages=1–4
|doi=10.1109/ISNCC.2018.8531071
|isbn=978-1-5386-3779-1
}}</ref>.
 
==SAST strengths==
The earlier a vulnerability is fixed in the SDLC, the cheaper it willis to costfix. CommonCosts measuresto offix costs for fixing during thein development isare 10 times lesslower than during thein testing stage, and 100 times lesslower than during thein production stage.<ref>
{{Cite journal
|last=Hossain|first=Shahadat
Line 207 ⟶ 202:
|title= Rework and Reuse Effects in Software Economy
|journal=Global Journal of Computer Science and Technology
|volume=18
|issue=C4
|pages=35–50
|url=https://computerresearch.org/index.php/computer/article/view/1780
}}</ref> SAST tools run automatically, either at the code level or application-level and do not require interaction. When integrated into a [[CI/CD]] context, SAST tools can be used to automatically stop the integration process if critical vulnerabilities are identified.<ref>
}}</ref>.
{{Cite book
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<ref>
{{Cite journal
|last1=Okun|first1=V.
|last2=Guthrie|first2=W. F.
|last3=Gaucher|first3=H.
|last4=Black|first4=P. E.
|title=Proceedings of the 2007 ACM workshop on Quality of protection
|chapter=Effect of static analysis tools on software security: Preliminary investigation
|s2cid=6663970
|date=October 2007
|title= Effect of static analysis tools on software security: preliminary investigation
|journal=Proceedings of the 2007 ACM Workshop on Quality of Protection
|pages=1–5
|publisher=ACM
|doi=10.1145/1314257.1314260
|isbn=978-1-59593-885-5
|url=https://samate.nist.gov/docs/SA_tool_effect_QoP.pdf
|chapter-url=https://samate.nist.gov/docs/SA_tool_effect_QoP.pdf
}}</ref>
 
BecauseAnother theadvantage toolover other types of testing is scanningthat SAST tools scan the entire source- code, it can cover 100% of it whenwhile [[dynamic application security testing]] coverstools thecover its execution, resultingpossibly in the possibility to missmissing part of the application<ref name="auto1"/> 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 thereThere is a direct correlation between thesoftware quality and the security. Bad quality software areis also poorly secured software.<ref>
{{Cite conference
<ref>
{{Cite journal
|last1=Siavvas|first1=M.
|last2=Tsoukalas|first2=D.
Line 240 ⟶ 237:
|date=August 2019
|title= An Empirical Evaluation of the Relationship between Technical Debt and Software Security
|editor=Konjović, Z. |editor2=Zdravković, M. |editor3=Trajanović, M.
|chapter=Software security
|journalbook-title= 9th International Conference on Information Society and Technology 2019 Proceedings |volume=1 |pages=199–203
|doi=10.5281/zenodo.3374712 |doi-access=free |type=Data set
}}</ref>.
 
==SAST weaknesses==
Even though developers are positive about the usage of SAST tools, there are different challenges to their adoption.<ref name="auto"/> As an example, research shows that despite the long output generated by these tools, they may lack usability.<ref>{{cite book |last1=Tahaei |first1=Mohammad |last2=Vaniea |first2=Kami |last3=Beznosov |first3=Konstantin (Kosta) |last4=Wolters |first4=Maria K |title=Proceedings of the 2021 CHI Conference on Human Factors in Computing Systems |chapter=Security Notifications in Static Analysis Tools: Developers' Attitudes, Comprehension, and Ability to Act on Them |date=6 May 2021 |pages=1–17 |doi=10.1145/3411764.3445616|isbn=9781450380966 |s2cid=233987670 |url=https://www.research.ed.ac.uk/en/publications/e1bc04ef-ae83-4e82-8ade-ca572bc503d2 }}</ref>
Even though developers are positive about the usage of SAST tools, there are different challenges to the adoption of SAST tools by developers.<ref name="auto"/>
 
With [[Agile software development|Agile Processes]] in software development, early integration of SAST generates many bugs, as developers using this framework focus first on features and delivery.<ref>
{{Cite journalbook
|last=Arreaza|first=Gustavo Jose Nieves
|title=2019 6th IEEE International Conference on Cyber Security and Cloud Computing (CSCloud)/ 2019 5th IEEE International Conference on Edge Computing and Scalable Cloud (EdgeCom)
|chapter=Methodology for Developing Secure Apps in the Clouds. (MDSAC) for IEEECS Confererences
|date=June 2019
|title= Methodology for Developing Secure Apps in the Clouds. (MDSAC) for IEEECS Conferences
|journal=2019 6th IEEE International Conference on Cyber Security and Cloud Computing (CSCloud)/ 2019 5th IEEE International Conference on Edge Computing and Scalable Cloud (EdgeCom)
|pages=102–106
|publisher=IEEE
|doi=10.1109/CSCloud/EdgeCom.2019.00-11
|isbn=978-1-7281-1661-7
|s2cid=203655645
}}</ref>
 
Scanning a large amount ofmany linelines of code with SAST tools may result in hundreds or thousands of vulnerability warnings for a single application. It generatescan agenerate largemany numberfalse 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.<ref name="ReferenceA"/>
 
{{Cite journal
== See also ==
|last1=Johnson|first1=Brittany
 
|last2=Song|first2=Yooki
* [[Security testing]]
|last3=Murphy-Hill|first3=Emerson
* [[Lint (software)]]
|last4=Bowdidge|first4=Robert
* [[Dynamic application security testing]]
|date=May 2013
* [[Interactive application security testing]]
|title= Why don't software developers use static analysis tools to find bug
* [[Static program analysis]]
|journal=ICSE '13 Proceedings of the 2013 International Conference on Software Engineering
|pages=672–681
|isbn=978-1-4673-3076-3
}}</ref>
 
==References==
{{reflist}}
 
[[Category:SoftwareSecurity testing]]
[[Category:ComputerStatic securityprogram softwareanalysis]]
[[Category:Static program analysis| ]]
[[Category:Program analysis]]
{{Improve categories|date=July 2020}}
[[Category:Software development process]]
[[Category:Agile software development]]