Content deleted Content added
→Rationale: Added a citation |
GreenC bot (talk | contribs) Move 1 url. Wayback Medic 2.5 per WP:URLREQ#fda.gov |
||
(38 intermediate revisions by 27 users not shown) | |||
Line 1:
{{Short description|Analysis of computer programs without executing them}}
{{Software development process}}
In [[computer science]], '''
The term is usually applied to
== Rationale ==
The sophistication of the analysis performed by tools varies from those that only consider the behaviour of individual statements and declarations,<ref>{{Cite journal|
[[Software metric]]s and [[reverse engineering]] can be described as forms of static analysis. Deriving software metrics and static analysis are increasingly deployed together, especially in creation of embedded systems, by defining so-called ''software quality objectives''.<ref>[http://web1.see.asso.fr/erts2010/Site/0ANDGY78/Fichier/PAPIERS%20ERTS%202010/ERTS2010_0035_final.pdf "Software Quality Objectives for Source Code"] {{webarchive|url=https://web.archive.org/web/20150604203133/http://web1.see.asso.fr/erts2010/Site/0ANDGY78/Fichier/PAPIERS%20ERTS%202010/ERTS2010_0035_final.pdf |date=2015-06-04 }} (PDF). ''Proceedings: Embedded Real Time Software and Systems 2010 Conference'', ERTS2010.org, Toulouse, France: Patrick Briand, Martin Brochet, Thierry Cambois, Emmanuel Coutenceau, Olivier Guetta, Daniel Mainberte, Frederic Mondot, Patrick Munier, Loic Noury, Philippe Spozio, Frederic Retailleau.</ref>
Line 12 ⟶ 13:
locating potentially [[Vulnerability (computing)|vulnerable]] code.<ref>[http://research.microsoft.com/en-us/um/people/livshits/papers/pdf/thesis.pdf ''Improving Software Security with Precise Static and Runtime Analysis''] {{webarchive|url=https://web.archive.org/web/20110605125310/http://research.microsoft.com/en-us/um/people/livshits/papers/pdf/thesis.pdf |date=2011-06-05 }} (PDF), Benjamin Livshits, section 7.3 "Static Techniques for Security". Stanford doctoral thesis, 2006.</ref> For example, the following industries have identified the use of static code analysis as a means of improving the quality of increasingly sophisticated and complex software:
# [[Medical software]]: The US [[Food and Drug Administration]] (FDA) has identified the use of static analysis for medical devices.<ref>{{cite web |title = Infusion Pump Software Safety Research at FDA |author = FDA |publisher = Food and Drug Administration |date = 2010-09-08 |url = https://www.fda.gov/MedicalDevices/ProductsandMedicalProcedures/GeneralHospitalDevicesandSupplies/InfusionPumps/ucm202511.htm |access-date = 2010-09-09 |url-status =
# Nuclear software: In the UK the Office for Nuclear Regulation (ONR) recommends the use of static analysis on [[reactor protection system]]s.<ref>Computer based safety systems - technical guidance for assessing software aspects of digital computer based protection systems, {{cite web | title = Computer based safety systems | url=http://www.hse.gov.uk/nuclear/operational/tech_asst_guides/tast046.pdf | archive-url=http://webarchive.nationalarchives.gov.uk/20130104193206/http://www.hse.gov.uk/nuclear/operational/tech_asst_guides/tast046.pdf | url-status=dead | archive-date=January 4, 2013 |access-date=May 15, 2013 }}</ref>
# Aviation software (in combination with [[Dynamic program analysis|dynamic analysis]]).<ref>[http://www.faa.gov/aircraft/air_cert/design_approvals/air_software/cast/cast_papers/media/cast-9.pdf Position Paper CAST-9. Considerations for Evaluating Safety Engineering Approaches to Software Assurance] {{webarchive|url=https://web.archive.org/web/20131006134233/http://www.faa.gov/aircraft/air_cert/design_approvals/air_software/cast/cast_papers/media/cast-9.pdf |date=2013-10-06 }} // FAA, Certification Authorities Software Team (CAST), January, 2002: "Verification. A combination of both static and dynamic analyses should be specified by the applicant/developer and applied to the software."</ref>
# Automotive & Machines (
A study in 2012 by VDC Research reported that 28.7% of the embedded software engineers surveyed
{{cite web | title=Automated Defect Prevention for Embedded Software Quality | last=VDC Research | publisher=VDC Research | date=2012-02-01 | url=http://alm.parasoft.com/embedded-software-vdc-report/ | access-date=2012-04-10 | url-status=live | archive-url=https://web.archive.org/web/20120411211422/http://alm.parasoft.com/embedded-software-vdc-report/ | archive-date=2012-04-11 }}</ref>
A study from 2010 found that 60% of the interviewed developers in European research projects made at least use of their basic IDE built-in static analyzers. However, only about 10% employed an additional other (and perhaps more advanced) analysis tool.<ref>Prause, Christian R., René Reiners, and Silviya Dencheva. "Empirical study of tool support in highly distributed research projects." Global Software Engineering (ICGSE), 2010 5th IEEE International Conference on. IEEE, 2010
In the application security industry the name [[
== Tool types==
The OMG ([[Object Management Group]]) published a study regarding the types of software analysis required for [[software quality]] measurement and assessment. This document on "How to Deliver Resilient, Secure, Efficient, and Easily Changed IT Systems in Line with CISQ Recommendations" describes three levels of software analysis.<ref>{{cite web |url=http://www.omg.org/CISQ_compliant_IT_Systemsv.4-3.pdf |title=
; Unit Level: Analysis that takes place within a specific program or subroutine, without connecting to the context of that program.
; Technology Level: Analysis that takes into account interactions between unit programs to get a more holistic and semantic view of the overall program in order to find issues and avoid obvious false positives.
; System Level: Analysis that takes into account the interactions between unit programs, but without being limited to one specific technology or programming language.
A further level of software analysis can be defined.
Line 48 ⟶ 49:
* [[Model checking]], considers systems that have [[finite-state machine|finite state]] or may be reduced to finite state by [[abstraction (computer science)|abstraction]];
* [[Symbolic execution]], as used to derive mathematical expressions representing the value of mutated variables at particular points in the code.
* [[Nullable]] reference analysis
== Data-driven static analysis ==
Data-driven static analysis
==
Static analyzers produce warnings. For certain types of warnings, it is possible to design and implement [[Automatic bug fixing|automated remediation]] techniques. For example, Logozzo and Ball have proposed automated remediations for C# ''cccheck''.<ref>{{Cite journal |last1=Logozzo |first1=Francesco |last2=Ball |first2=Thomas |date=2012-11-15 |title=Modular and verified automatic program repair |url=http://dx.doi.org/10.1145/2398857.2384626 |journal=ACM SIGPLAN Notices |volume=47 |issue=10 |pages=133–146 |doi=10.1145/2398857.2384626 |issn=0362-1340|url-access=subscription }}</ref>
== See also ==
{{cmn|
* [[Code audit]]
* [[Documentation generator]]
* [[Formal semantics of programming languages]]
* [[Formal verification]]
* [[FX-87]]
* [[ISO 26262]]
* [[ISO/IEC 9126|ISO 9126]] (now ISO 25000 series)▼
* [[Lint (software)]]▼
* [[List of tools for static code analysis]]
* [[Shape analysis (
* [[Software quality]]
* [[Software quality assurance]]
* [[
}}
▲*[[ISO/IEC 9126|ISO 9126]] (now ISO 25000 series)
▲*[[Lint (software)]]
== References ==
Line 75 ⟶ 84:
* {{cite book |author1=Flemming Nielson |author2=Hanne R. Nielson |author3=Chris Hankin |edition = 1999 (corrected 2004) |title = Principles of Program Analysis |publisher= Springer |isbn = 978-3-540-65410-0|date=2004-12-10 }}
* [http://santos.cis.ksu.edu/schmidt/Escuela03/home.html "Abstract interpretation and static analysis,"] International Winter School on Semantics and Applications 2003, by [http://people.cis.ksu.edu/~schmidt/ David A. Schmidt]
{{Program analysis}}
[[Category:Static program analysis| ]]
[[Category:Program analysis]]
[[Category:Software
|