\documentclass[11pt,twoside]{article}\makeatletter

\IfFileExists{xcolor.sty}%
  {\RequirePackage{xcolor}}%
  {\RequirePackage{color}}
\usepackage{colortbl}
\usepackage{wrapfig}
\usepackage{ifxetex}
\ifxetex
  \usepackage{fontspec}
  \usepackage{xunicode}
  \catcode`⃥=\active \def⃥{\textbackslash}
  \catcode`❴=\active \def❴{\{}
  \catcode`❵=\active \def❵{\}}
  \def\textJapanese{\fontspec{Noto Sans CJK JP}}
  \def\textChinese{\fontspec{Noto Sans CJK SC}}
  \def\textKorean{\fontspec{Noto Sans CJK KR}}
  \setmonofont{DejaVu Sans Mono}
  
\else
  \IfFileExists{utf8x.def}%
   {\usepackage[utf8x]{inputenc}
      \PrerenderUnicode{–}
    }%
   {\usepackage[utf8]{inputenc}}
  \usepackage[english]{babel}
  \usepackage[T1]{fontenc}
  \usepackage{float}
  \usepackage[]{ucs}
  \uc@dclc{8421}{default}{\textbackslash }
  \uc@dclc{10100}{default}{\{}
  \uc@dclc{10101}{default}{\}}
  \uc@dclc{8491}{default}{\AA{}}
  \uc@dclc{8239}{default}{\,}
  \uc@dclc{20154}{default}{ }
  \uc@dclc{10148}{default}{>}
  \def\textschwa{\rotatebox{-90}{e}}
  \def\textJapanese{}
  \def\textChinese{}
  \IfFileExists{tipa.sty}{\usepackage{tipa}}{}
\fi
\def\exampleFont{\ttfamily\small}
\DeclareTextSymbol{\textpi}{OML}{25}
\usepackage{relsize}
\RequirePackage{array}
\def\@testpach{\@chclass
 \ifnum \@lastchclass=6 \@ne \@chnum \@ne \else
  \ifnum \@lastchclass=7 5 \else
   \ifnum \@lastchclass=8 \tw@ \else
    \ifnum \@lastchclass=9 \thr@@
   \else \z@
   \ifnum \@lastchclass = 10 \else
   \edef\@nextchar{\expandafter\string\@nextchar}%
   \@chnum
   \if \@nextchar c\z@ \else
    \if \@nextchar l\@ne \else
     \if \@nextchar r\tw@ \else
   \z@ \@chclass
   \if\@nextchar |\@ne \else
    \if \@nextchar !6 \else
     \if \@nextchar @7 \else
      \if \@nextchar (8 \else
       \if \@nextchar )9 \else
  10
  \@chnum
  \if \@nextchar m\thr@@\else
   \if \@nextchar p4 \else
    \if \@nextchar b5 \else
   \z@ \@chclass \z@ \@preamerr \z@ \fi \fi \fi \fi
   \fi \fi  \fi  \fi  \fi  \fi  \fi \fi \fi \fi \fi \fi}
\gdef\arraybackslash{\let\\=\@arraycr}
\def\@textsubscript#1{{\m@th\ensuremath{_{\mbox{\fontsize\sf@size\z@#1}}}}}
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\def\abbr{}
\def\corr{}
\def\expan{}
\def\gap{}
\def\orig{}
\def\reg{}
\def\ref{}
\def\sic{}
\def\persName{}\def\name{}
\def\placeName{}
\def\orgName{}
\def\textcal#1{{\fontspec{Lucida Calligraphy}#1}}
\def\textgothic#1{{\fontspec{Lucida Blackletter}#1}}
\def\textlarge#1{{\large #1}}
\def\textoverbar#1{\ensuremath{\overline{#1}}}
\def\textquoted#1{‘#1’}
\def\textsmall#1{{\small #1}}
\def\textsubscript#1{\@textsubscript{\selectfont#1}}
\def\textxi{\ensuremath{\xi}}
\def\titlem{\itshape}
\newenvironment{biblfree}{}{\ifvmode\par\fi }
\newenvironment{bibl}{}{}
\newenvironment{byline}{\vskip6pt\itshape\fontsize{16pt}{18pt}\selectfont}{\par }
\newenvironment{citbibl}{}{\ifvmode\par\fi }
\newenvironment{docAuthor}{\ifvmode\vskip4pt\fontsize{16pt}{18pt}\selectfont\fi\itshape}{\ifvmode\par\fi }
\newenvironment{docDate}{}{\ifvmode\par\fi }
\newenvironment{docImprint}{\vskip 6pt}{\ifvmode\par\fi }
\newenvironment{docTitle}{\vskip6pt\bfseries\fontsize{22pt}{25pt}\selectfont}{\par }
\newenvironment{msHead}{\vskip 6pt}{\par}
\newenvironment{msItem}{\vskip 6pt}{\par}
\newenvironment{rubric}{}{}
\newenvironment{titlePart}{}{\par }

\newcolumntype{L}[1]{){\raggedright\arraybackslash}p{#1}}
\newcolumntype{C}[1]{){\centering\arraybackslash}p{#1}}
\newcolumntype{R}[1]{){\raggedleft\arraybackslash}p{#1}}
\newcolumntype{P}[1]{){\arraybackslash}p{#1}}
\newcolumntype{B}[1]{){\arraybackslash}b{#1}}
\newcolumntype{M}[1]{){\arraybackslash}m{#1}}
\definecolor{label}{gray}{0.75}
\def\unusedattribute#1{\sout{\textcolor{label}{#1}}}
\DeclareRobustCommand*{\xref}{\hyper@normalise\xref@}
\def\xref@#1#2{\hyper@linkurl{#2}{#1}}
\begingroup
\catcode`\_=\active
\gdef_#1{\ensuremath{\sb{\mathrm{#1}}}}
\endgroup
\mathcode`\_=\string"8000
\catcode`\_=12\relax

\usepackage[a4paper,twoside,lmargin=1in,rmargin=1in,tmargin=1in,bmargin=1in,marginparwidth=0.75in]{geometry}
\usepackage{framed}

\definecolor{shadecolor}{gray}{0.95}
\usepackage{longtable}
\usepackage[normalem]{ulem}
\usepackage{fancyvrb}
\usepackage{fancyhdr}
\usepackage{graphicx}
\usepackage{marginnote}

\renewcommand{\@cite}[1]{#1}


\renewcommand*{\marginfont}{\itshape\footnotesize}

\def\Gin@extensions{.pdf,.png,.jpg,.mps,.tif}

  \pagestyle{fancy}

\usepackage[pdftitle={A New View on Classification of Software Vulnerability Mitigation Methods},
 pdfauthor={}]{hyperref}
\hyperbaseurl{}

	 \paperwidth210mm
	 \paperheight297mm
              
\def\@pnumwidth{1.55em}
\def\@tocrmarg {2.55em}
\def\@dotsep{4.5}
\setcounter{tocdepth}{3}
\clubpenalty=8000
\emergencystretch 3em
\hbadness=4000
\hyphenpenalty=400
\pretolerance=750
\tolerance=2000
\vbadness=4000
\widowpenalty=10000

\renewcommand\section{\@startsection {section}{1}{\z@}%
     {-1.75ex \@plus -0.5ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large\bfseries}}
\renewcommand\subsection{\@startsection{subsection}{2}{\z@}%
     {-1.75ex\@plus -0.5ex \@minus- .2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large}}
\renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}%
     {-1.5ex\@plus -0.35ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\large}}
\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}%
     {-1ex \@plus-0.35ex \@minus -0.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\normalsize}}
\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}%
     {1.5ex \@plus1ex \@minus .2ex}%
     {-1em}%
     {\reset@font\normalsize\bfseries}}


\def\l@section#1#2{\addpenalty{\@secpenalty} \addvspace{1.0em plus 1pt}
 \@tempdima 1.5em \begingroup
 \parindent \z@ \rightskip \@pnumwidth 
 \parfillskip -\@pnumwidth 
 \bfseries \leavevmode #1\hfil \hbox to\@pnumwidth{\hss #2}\par
 \endgroup}
\def\l@subsection{\@dottedtocline{2}{1.5em}{2.3em}}
\def\l@subsubsection{\@dottedtocline{3}{3.8em}{3.2em}}
\def\l@paragraph{\@dottedtocline{4}{7.0em}{4.1em}}
\def\l@subparagraph{\@dottedtocline{5}{10em}{5em}}
\@ifundefined{c@section}{\newcounter{section}}{}
\@ifundefined{c@chapter}{\newcounter{chapter}}{}
\newif\if@mainmatter 
\@mainmattertrue
\def\chaptername{Chapter}
\def\frontmatter{%
  \pagenumbering{roman}
  \def\thechapter{\@roman\c@chapter}
  \def\theHchapter{\roman{chapter}}
  \def\thesection{\@roman\c@section}
  \def\theHsection{\roman{section}}
  \def\@chapapp{}%
}
\def\mainmatter{%
  \cleardoublepage
  \def\thechapter{\@arabic\c@chapter}
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \pagenumbering{arabic}
  \setcounter{secnumdepth}{6}
  \def\@chapapp{\chaptername}%
  \def\theHchapter{\arabic{chapter}}
  \def\thesection{\@arabic\c@section}
  \def\theHsection{\arabic{section}}
}
\def\backmatter{%
  \cleardoublepage
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \setcounter{secnumdepth}{2}
  \def\@chapapp{\appendixname}%
  \def\thechapter{\@Alph\c@chapter}
  \def\theHchapter{\Alph{chapter}}
  \appendix
}
\newenvironment{bibitemlist}[1]{%
   \list{\@biblabel{\@arabic\c@enumiv}}%
       {\settowidth\labelwidth{\@biblabel{#1}}%
        \leftmargin\labelwidth
        \advance\leftmargin\labelsep
        \@openbib@code
        \usecounter{enumiv}%
        \let\p@enumiv\@empty
        \renewcommand\theenumiv{\@arabic\c@enumiv}%
	}%
  \sloppy
  \clubpenalty4000
  \@clubpenalty \clubpenalty
  \widowpenalty4000%
  \sfcode`\.\@m}%
  {\def\@noitemerr
    {\@latex@warning{Empty `bibitemlist' environment}}%
    \endlist}

\def\tableofcontents{\section*{\contentsname}\@starttoc{toc}}
\parskip0pt
\parindent1em
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\newenvironment{reflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemsep}{0pt}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\itshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{sansreflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\itemsep}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\upshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{specHead}[2]%
 {\vspace{20pt}\hrule\vspace{10pt}%
  \phantomsection\label{#1}\markright{#2}%

  \pdfbookmark[2]{#2}{#1}%
  \hspace{-0.75in}{\bfseries\fontsize{16pt}{18pt}\selectfont#2}%
  }{}
      \def\TheFullDate{2017 2017-01-15 (revised: 60 Year 2017 15 January 2017)}
\def\TheID{\makeatother }
\def\TheDate{2017 2017-01-15}
\title{A New View on Classification of Software Vulnerability Mitigation Methods}
\author{}\makeatletter 
\makeatletter
\newcommand*{\cleartoleftpage}{%
  \clearpage
    \if@twoside
    \ifodd\c@page
      \hbox{}\newpage
      \if@twocolumn
        \hbox{}\newpage
      \fi
    \fi
  \fi
}
\makeatother
\makeatletter
\thispagestyle{empty}
\markright{\@title}\markboth{\@title}{\@author}
\renewcommand\small{\@setfontsize\small{9pt}{11pt}\abovedisplayskip 8.5\p@ plus3\p@ minus4\p@
\belowdisplayskip \abovedisplayskip
\abovedisplayshortskip \z@ plus2\p@
\belowdisplayshortskip 4\p@ plus2\p@ minus2\p@
\def\@listi{\leftmargin\leftmargini
               \topsep 2\p@ plus1\p@ minus1\p@
               \parsep 2\p@ plus\p@ minus\p@
               \itemsep 1pt}
}
\makeatother
\fvset{frame=single,numberblanklines=false,xleftmargin=5mm,xrightmargin=5mm}
\fancyhf{} 
\setlength{\headheight}{14pt}
\fancyhead[LE]{\bfseries\leftmark} 
\fancyhead[RO]{\bfseries\rightmark} 
\fancyfoot[RO]{}
\fancyfoot[CO]{\thepage}
\fancyfoot[LO]{\TheID}
\fancyfoot[LE]{}
\fancyfoot[CE]{\thepage}
\fancyfoot[RE]{\TheID}
\hypersetup{citebordercolor=0.75 0.75 0.75,linkbordercolor=0.75 0.75 0.75,urlbordercolor=0.75 0.75 0.75,bookmarksnumbered=true}
\fancypagestyle{plain}{\fancyhead{}\renewcommand{\headrulewidth}{0pt}}

\date{}
\usepackage{authblk}

\providecommand{\keywords}[1]
{
\footnotesize
  \textbf{\textit{Index terms---}} #1
}

\usepackage{graphicx,xcolor}
\definecolor{GJBlue}{HTML}{273B81}
\definecolor{GJLightBlue}{HTML}{0A9DD9}
\definecolor{GJMediumGrey}{HTML}{6D6E70}
\definecolor{GJLightGrey}{HTML}{929497} 

\renewenvironment{abstract}{%
   \setlength{\parindent}{0pt}\raggedright
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
   \textcolor{GJBlue}{\large\bfseries\abstractname\space}
}{%   
   \vskip8pt
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
}

\usepackage[absolute,overlay]{textpos}

\makeatother 
      \usepackage{lineno}
      \linenumbers
      
\begin{document}

             \author[1]{Babak  Sadeghiyan}

             \author[2]{Maryam  Mouzarani}

             \affil[1]{  Amirkabir University of Technology}

\renewcommand\Authands{ and }

\date{\small \em Received: 6 December 2016 Accepted: 3 January 2017 Published: 15 January 2017}

\maketitle


\begin{abstract}
        


Software vulnerability mitigation is a well-known research area, and many methods have been proposed for it. Some papers try to classify these methods from different specific points of views. In this paper, we aggregate all proposed classifications and present a comprehensive classification of vulnerability mitigation methods. We define software vulnerability as a kind of software fault, and correspond the classes of software vulnerability mitigation methods accordingly. In this paper, the software vulnerability mitigation methods are classified into vulnerability prevention, vulnerability tolerance, vulnerability removal and vulnerability forecasting. We define each vulnerability mitigation method in our new point of view and indicate some methods for each class. Our general point of view helps to consider all of the proposed methods in this review. We also identify the fault mitigation methods that might be effective in mitigating the software vulnerabilities but are not yet applied in this area. Based on that, new directions are suggested for the future research.

\end{abstract}


\keywords{}

\begin{textblock*}{18cm}(1cm,1cm) % {block width} (coords) 
\textcolor{GJBlue}{\LARGE Global Journals \LaTeX\ JournalKaleidoscope\texttrademark}
\end{textblock*}

\begin{textblock*}{18cm}(1.4cm,1.5cm) % {block width} (coords) 
\textcolor{GJBlue}{\footnotesize \\ Artificial Intelligence formulated this projection for compatibility purposes from the original article published at Global Journals. However, this technology is currently in beta. \emph{Therefore, kindly ignore odd layouts, missed formulae, text, tables, or figures.}}
\end{textblock*}


\let\tabcellsep& 	 	 		 
\section[{Introduction}]{Introduction}\par
oftware is an important part of a computer system. Being complex or created by incompetent developers, faults might be introduced to the software. There are faults that cause violating the system security. These faults are called vulnerability. There has been much research on preventing, detecting and analyzing software vulnerabilities.\par
By the time of writing this paper there is a number of surveys on the methods of mitigating vulnerabilities, i.e. \hyperref[b0]{[1]}, \hyperref[b1]{[2]}, \hyperref[b2]{[3]} and \hyperref[b3]{[4]}. Among them, \hyperref[b3]{[4]} surveys the static analysis vulnerability detection methods that are applied in three areas that are associated with sources of vulnerabilities, i.e., accesscontrol, information-flow and application-programmingconformance. It reviews around 88 papers. The studied methods, however, do not cover all the software vulnerability classes. Static analysis methods are also surveyed in \hyperref[b2]{[3]}. It reviews 23 papers and classifies their methods with a different point of view. In \hyperref[b0]{[1]} static and dynamic analysis methods are classified and 18 papers are briefly reviewed. The classification for static analysis methods presented in that paper is similar to the on in \hyperref[b2]{[3]}. The most comprehensive survey is presented in \hyperref[b1]{[2]} by \hyperref[b1]{Shahriar et al. in 2012}. They review 173 papers and classify their methods in four classes, i.e., static analysis, dynamic analysis, monitoring and hybrid analysis.\par
In this paper, we present a new definition for software vulnerability. Based on this definition, vulnerability mitigation methods are classified and reviewed with a new point of view. We use the general classification of fault mitigation methods as a base and extend it to a detailed classification of software vulnerability mitigation methods.\par
Our comprehensive classification aggregates many of the classification presented in the previous surveys, i.e., \hyperref[b0]{[1]}, \hyperref[b2]{[3]}, \hyperref[b1]{[2]} and \hyperref[b4]{[5]}. Also, the general perspective applied in our survey helps to identify the fault mitigation methods that are not yet used in mitigating software vulnerabilities. Since we consider the software vulnerability as a type of fault, these methods may be helpful in mitigating software vulnerabilities. We suggest new directions for the future researches based on our analysis during the review of the proposed vulnerability mitigation methods.\par
In this paper, our definition of software vulnerability is presented in section II. Based on this definition, software vulnerability mitigation methods are classified in section III. In this section, each class is described in details and some examples are reviewed. Section IV concludes the paper and presents some future directions. 
\section[{II.}]{II.} 
\section[{Defining Software Vulnerability}]{Defining Software Vulnerability}\par
To review vulnerability mitigation methods, a precise definition of software vulnerability is required. Different researchers have suggested definitions for this term which are nearly analogous but have differences. Matt Bishop et al. define software vulnerability by modeling the software as a state machine in \hyperref[b5]{[6]}, \hyperref[b6]{[7]}, \hyperref[b7]{[8]} and \hyperref[b8]{[9]}. In this model, a vulnerable state is the state that let unauthorized reads, changes or accessibility modifications to a source. They define vulnerability as a property in the system that let it enter into a vulnerable state. In \hyperref[b7]{[8]} Bishop defines vulnerability as a weakness that makes it possible for a threat to occur, where a threat is a potential violation of security policy. Amoroso defines vulnerability as an unfortunate characteristic that allows a threat to potentially occur \hyperref[b9]{[10]}. There are other definitions of software vulnerability in relation with S security policy, e.g. \hyperref[b10]{[11]} and \hyperref[b0]{[1]}. Most of them define it as a property, characteristic or weakness that may cause compromising the security policy.\par
In order to clarify the terms property and security policy compromise, we redefine "software vulnerability". We use the precise definitions for the concepts in software security and reliability that are presented in \hyperref[b12]{[12]} and construct our definition of software vulnerability. The taxonomy in \hyperref[b12]{[12]} is presented in 2004 for the concepts of software security and reliability, such as fault, error, failure, vulnerability and attack. The authors define fault as the cause of error, while error is a state of the system that is probable to failure. Failure -or service failure is an event in which the delivered service is deviated from the correct service. In fact, a fault may become active and produce an error. Also the error may propagate inside the system and produce more errors. If the propagated error reaches system boundaries and affects the services, it becomes a failure.\par
A service is defined in \hyperref[b12]{[12]} as the behavior perceived by users in system boundaries. Correct services are determined by the system specification. Some parts of the system behavior are specified by the security policy, which is a partial system specification. Thus when a system deviates from the security policy, a security failure occurs. This means that compromising security policy causes a security failure.\par
Faults are classified in \hyperref[b12]{[12]} based on eight criteria, such as the phase of creation or occurrence, the objective, the phenomenological cause, the system boundary and the dimension. All combinations of the eight elementary fault classes would result in 256 different combined classes. The authors, however, believe that not all combinations are possible. For example, there is no malicious non-deliberate faults, or all the natural faults are non-malicious.\par
An attack is defined in \hyperref[b12]{[12]} as a malicious external fault. An attack may be either an external hardware malicious fault, such as heating the RAM with a hairdryer to cause memory errors, or an external software malicious fault, such as a Trojan horse \hyperref[b12]{[12]}. The term vulnerability is also defined in \hyperref[b12]{[12]} as an internal fault that enables an external fault to harm the computer system, although harming the computer system is not clearly defined.\par
According to the previous definitions, we consider software vulnerabilities as:\par
We have concluded this definition, out of the definitions in \hyperref[b12]{[12]}, \hyperref[b7]{[8]}, \hyperref[b9]{[10]}, \hyperref[b10]{[11]} and \hyperref[b0]{[1]}, since looking a vulnerability as a fault, instead of a property, better clarifies the concept of vulnerability by considering its relation to error, security failure and thus security policy. Like faults, a vulnerability may be dormant and never be activated. It also may be activated and propagated in the system. The activated vulnerability might never reach the boundaries. As an example, suppose that a buffer overflow occurs and the value of a return address in the stack changes as a result. But using a monitoring procedure, the unauthorized change is detected and the program halts. Thus, the security policy is not violated. Monitoring the program, as a vulnerability detection method, is explained in section III-B. When an active vulnerability reaches the system boundaries, it causes a security failure. For example, an attacker may activate the format string vulnerability in a program and make it print some confidential data from the memory \hyperref[b13]{[13]}. Since the active vulnerability has reached the system boundaries, it has made a security failure. 
\section[{III. Vulnerability Mitigation Methods}]{III. Vulnerability Mitigation Methods}\par
Since vulnerability mitigation is a well-known research area, a structured approach is required to review the previous related works. In this paper, we review vulnerability mitigation methods using a new point of view. We classify and review these methods based on how we define software vulnerability. In the previous section, software vulnerability is defined as an internal software fault. Since we considered vulnerability as a type of fault, the classifications of fault mitigation methods can be used as a base for classifying vulnerability mitigation methods. Avizienis et al. present a classification for the means of mitigating the faults to achieve a secure and dependable system in \hyperref[b12]{[12]}. We use this general classification as a base and extend it into a detailed classification of vulnerability mitigation methods. Our classification is illustrated in figure  {\ref 1}. The vulnerability mitigation classes that are shown in figure  {\ref 1} are described in more details in the following sections. This figure presents a comprehensive view of the previous efforts in mitigating software vulnerabilities. Our classification also aggregates the classifications presented in the previous surveys, such as the ones presented in \hyperref[b0]{[1]}, \hyperref[b2]{[3]}, \hyperref[b1]{[2]}. Moreover, this classification helps to identify the fault mitigation methods that can be applied to improve current software vulnerability mitigation methods. This helps to suggest new directions for the future research. 
\section[{a) Vulnerability prevention}]{a) Vulnerability prevention}\par
Generally, fault prevention means avoiding the fault introduction and occurrence in the application during the development. A fault may be introduced during any of the development phases: requirement analysis, design and implementation. To prevent the occurrence of software vulnerabilities during these phases, software security is emerged. Software security is the process of designing, building and testing software for security \hyperref[b14]{[14]}. It aims at designing and implementing a secure software and educating developers, architects and users to build security in the software \hyperref[b14]{[14]}. There are various secure software development methods presented by now, such as Microsoft Security Development Lifecycle (SDL) \hyperref[b15]{[15]}, Security Quality Requirement Engineering (SQUARE) \hyperref[b16]{[16]} and McGraw's secure development method \hyperref[b14]{[14]}. Also, there are secure coding best practices that are suggested for different programming languages. These best practices educate the programmers to prevent introduction of well-known vulnerabilities during the coding phase, such as \hyperref[b17]{[17]} for .NET framework, \hyperref[b18]{[18]} for C/C++ and \hyperref[b19]{[19]} for Java.\par
The programmers' lack of security knowledge is an important reason for the introduction of vulnerabilities. Transferring the related information to the developers is an issue in vulnerability prevention. The SHIELDS project was an example of the attempts in this area \hyperref[b20]{[20]}. The goal in this project was to create a database of security related information for programmers that can be used automatically. A unified modeling language was proposed in SHIELDS for representing this information \hyperref[b21]{[21]}. Using this language, it is possible to specify a vulnerability class and its relations to the well-known attacks. It also helps to define the methods of preventing a vulnerability class. Thus, it helps the developers to learn how to prevent vulnerabilities in order to achieve the security goals of the application. Some tools were also developed based on this language in that project, such as GOAT \hyperref[b20]{[20]} and TestInv-Code \hyperref[b22]{[22]}. 
\section[{b) Vulnerability Tolerance}]{b) Vulnerability Tolerance}\par
In spite of vulnerability prevention efforts, vulnerabilities are created. Thus, vulnerability tolerance is required. Generally, fault tolerance methods accept the existence of faults and focus on preventing the activated faults from reaching the system boundaries and causing a failure. Fault tolerance is usually performed in two steps: error detection and recovery \hyperref[b12]{[12]}. Therefore, we study monitoring methods based on three aspects: the applied error detection, error handling and fault handling techniques. Please note that since we look a vulnerability as a fault, we consider error as an active vulnerability. Thus, the mentioned three aspects are also named as active vulnerability detection, active vulnerability handling and vulnerability handling techniques respectively. Fig.  {\ref 1}: Our classification of vulnerability mitigation methods according to the classification of fault mitigation methods in \hyperref[b12]{[12]}. The boxes with dashed borders show the methods that have not been used in mitigating software vulnerabilities yet. 
\section[{C Error detection (active vulnerability detection)}]{C Error detection (active vulnerability detection)}\par
There are vulnerability mitigation methods that control the execution of a program and detects active vulnerabilities at run-time. These methods are also called monitoring methods \hyperref[b1]{[2]}. Various active vulnerability detection techniques have been used in the proposed monitoring methods. Some examples are monitoring the memory and validating its integrity \hyperref[b23]{[23]}, \hyperref[b24]{[24]}, \hyperref[b25]{[25]}, controlling the flow of user provided data (taint analysis) \hyperref[b26]{[26]}, \hyperref[b27]{[27]}, \hyperref[b28]{[28]}, \hyperref[b29]{[29]} and validating the arguments of specific functions \hyperref[b30]{[30]}, \hyperref[b31]{[31]}, \hyperref[b32]{[32]}.\par
For example, the return addresses of functions in the stack memory of the program are monitored in \hyperref[b23]{[23]}, \hyperref[b24]{[24]} and \hyperref[b25]{[25]} to detect stack overflows at run-time. If any unauthorized changes of the return addresses is detected, it is concluded that a buffer overflow vulnerability has become active in the program. Some monitoring methods track the flow of user provided un-trusted data at run-time and react appropriately if the untrusted data reach sensitive statements in the program, such as \hyperref[b26]{[26]}, \hyperref[b27]{[27]}, \hyperref[b28]{[28]}, \hyperref[b29]{[29]}. This method is used to tolerate various vulnerabilities, such as DOM-based XSS \hyperref[b29]{[29]}, SQL injection \hyperref[b26]{[26]}, \hyperref[b27]{[27]}, \hyperref[b28]{[28]}, buffer overflow \hyperref[b26]{[26]}, \hyperref[b27]{[27]}, \hyperref[b28]{[28]} and format string \hyperref[b26]{[26]}, \hyperref[b27]{[27]}, \hyperref[b28]{[28]}. Some monitoring methods locate specific functions in the program and control their arguments during the program execution, such as \hyperref[b30]{[30]}, \hyperref[b31]{[31]} and \hyperref[b32]{[32]}.\par
For example, in \hyperref[b31]{[31]} the program code is analyzed statically and the query strings, that are used as the arguments of SQL functions, are parsed to extract the ASTs of legitimate queries. In this method, the code is instrumented to control the values of SQL queries before executing the relevant functions. Before executing a query with un-trusted data, the monitoring procedure extracts the AST of the query. It then compares the extracted AST with the AST of the legitimate queries. Any inconsistency between the two ASTs might reveal a malicious query. Thus, an appropriate reaction is taken by the monitoring procedure to prevent security failures.\par
Detecting the errors may be performed during the normal service delivery (concurrent detection). Also, it may be performed in specific times in which the application does not deliver services (preemptive detection). The latter is usually applied to eliminate the negative effects of software aging. All the studied monitoring methods detect active vulnerabilities during the normal service delivery. However, preemptive error detection can be used to detect the activation of vulnerabilities that makes the program overuse the system resources, like the memory leakage vulnerability. 
\section[{Error handling (active vulnerability handling)}]{Error handling (active vulnerability handling)}\par
After an error is detected, it is handled in one of three ways: rollback, roll-forward and compensation.\par
Many of the presented monitoring methods focus on detecting active vulnerabilities, but less attention is paid to handling the active vulnerabilities. It seems that more effort is required on designing appropriate handling methods for active vulnerabilities. Although halting the program and throwing an exception prevents a successful attack, they violate the availability of the software to the legitimate users. Thus, it may result in deniable of service. Therefore, more intelligent active vulnerability handling techniques should be designed for the monitoring methods. Since the rollback technique is usually used for the transient faults and software vulnerability is a permanent fault, this technique cannot be applied in the monitoring methods. Thus, the roll-forward and compensation techniques can be used to design more intelligent active vulnerability handling methods. 
\section[{Fault handling (vulnerability handling)}]{Fault handling (vulnerability handling)}\par
After handling the error, sometimes fault handling is performed to remove the fault and prevent the similar errors in the future. Of course, sometimes the fault is handled immediately after error detection. Fault handling is performed by first recognizing causes of the Using the rollback method, the system is restored to a previously stored error-free state. Then, the program continues normal execution from the restored state. In some applications, such as real-time applications, there is no time to rollback. Thus, roll forwarding is performed to change the system state into a degraded new state that contains no errors. Then, the program executes normally from the degraded state. Roll-forwarding is applicable for predictable errors. Another error handling method is compensation. In this method, the redundancy in the current state is used to mask the error and let the program continues the execution. Many of the monitoring methods halt the program and generate an error message when they detect an active vulnerability, e.g. \hyperref[b32]{[32]}, \hyperref[b27]{[27]}, \hyperref[b33]{[33]}, \hyperref[b24]{[24]}. In other words, many of the monitoring methods do not perform error handling. Some monitoring methods call an exception handler and take the program to a pre-defined state \hyperref[b34]{[34]}, \hyperref[b26]{[26]}, \hyperref[b28]{[28]}. Most of the monitoring methods that are used for web applications ignore the requests that result in errors and continue normal execution \hyperref[b30]{[30]}, \hyperref[b31]{[31]}, \hyperref[b35]{[35]}, \hyperref[b29]{[29]}. Calling exception handlers and ignoring the malicious requests can be considered as simple rollforwarding actions, since the erroneous state is changed into an error-free state and the program continues normal execution. However, more intelligent reactions can be performed after detecting active vulnerabilities. For example, in  {\ref [36]} the stack content and return addresses are stored to compensate for buffer overflow errors. When a buffer overflow error is detected, the monitoring procedure uses the stored data to help the program continue execution securely.\par
error. Usually, the faulty component is isolated to prevent the future activation of the fault. A spare faultfree component is then replaced by the faulty one. The system is reconfigured based on the new structure. We are not aware of any monitoring method that consists of a vulnerability handling procedure. However, there are some specific methods for automatically patching the software vulnerabilities, such as \hyperref[b37]{[37]}, \hyperref[b38]{[38]}, \hyperref[b39]{[39]}, \hyperref[b40]{[40]} and \hyperref[b41]{[41]}. These methods might be usable in the proposed vulnerability tolerance methods to handle the vulnerabilities. The automatic patching methods analyze the malicious data that is used in an attack and modify the program to filter similar data in the future. These methods can be combined with preemptive active vulnerability detection techniques to generate a complete vulnerability tolerance solution.\par
Table  {\ref I} summarizes the presented vulnerability tolerance methods so that the reader can review them easier. To sum up, there are various monitoring methods with enhanced error detection mechanisms presented by now. These methods pay more attention to detecting the errors. This might be due to the difference between software vulnerability and the other faults. Usually, software vulnerability is activated by malicious external faults. Therefore, detecting an active vulnerability reveals an ongoing attack. The software should resist the attack as soon as possible to prevent further damages. Thus, the quick detection of the active vulnerability is very important. Halting the program is the fastest low-risk response to the attack. However, it makes the program unavailable to the legitimate users as well. Thus, more intelligent error handling and vulnerability handling techniques should be added to the monitoring methods. To do so, a good starting point is inspiring by the current fault handling and error handling techniques and designing software vulnerability handling techniques. 
\section[{c) Vulnerability removal}]{c) Vulnerability removal}\par
Vulnerability removal is performed to detect and remove the vulnerabilities that are created in software despite the vulnerability prevention efforts. Based on figure  {\ref 1}, the fault removal process consists of four steps: verification, diagnosis, correction and nonregression verification. During the verification step, it is verified if the system adheres to the specification. If not, the reason (fault) is diagnosed and corrected. After removing the fault, the verification is repeated to check if the removal was effective. The verification at this step is called non-regression verification.\par
Most of the vulnerability removal methods focus on the verification step and don't suggest any diagnosis or correction methods for the detected vulnerabilities. There are, however, special vulnerability diagnosis methods that diagnose the vulnerabilities that are exploited by malicious users. For example, in \hyperref[b42]{[42]} exploitation of memory corruption vulnerabilities is detected and then the exploited vulnerability is automatically diagnosed. The result of diagnosis consists of the instruction that are exploited by an attacker to corrupt critical program data, the stack trace at the time of memory corruption and the history that the corrupted data are propagated after the initial corruption. This information helps the developers to remove the diagnosed vulnerabilities. We could not find any vulnerability diagnosis or correction procedure that is used after the verification step of a vulnerability removal method. We need vulnerability diagnosis and correction procedures that can be used after the verification step, not after detecting an attack. In other words, these procedures should not be based on the attack information, but based on the information achieved during the verification step.\par
Some vulnerability detection methods perform the verification step by checking if the software adheres to the security specification, while some of them verify if specific vulnerabilities exist in the software. Figure  {\ref 1} illustrated our classification of vulnerability verification methods. We divide the verification methods into three main classes: static, dynamic and hybrid methods.\par
i. Static analysis Static analysis methods do not execute the program. Instead, they examine the program code and study its possible behaviors. Therefore, the result of static analysis is true regardless of the input data and static methods are usually sound and conservative \hyperref[b43]{[43]}. A sound method is able to detect any specified vulnerability in the program. In other words, if a vulnerability is defined for the static analyzer and exists in a program, the analyzer will surely find it. In order to be sound, the analyzer produces conservative results that are weaker than the actual ones and may not be very useful \hyperref[b43]{[43]}. In fact, static analysis is appropriate in proving the absence of a specific vulnerability. Usually static analyzers create many false alarms, hence they cannot be very useful in proving the existence of a specific vulnerability. Static analysis may be performed on the program or on the behavior model of the program \hyperref[b12]{[12]}. Thus, static analysis methods are divided into two main classes: program-based and modelbased methods.  
\section[{ii. Program-based methods}]{ii. Program-based methods}\par
As figure  {\ref 1} shows, these methods are classified into seven subclasses. Each class is explained as follows. 
\section[{Pattern Matching}]{Pattern Matching}\par
The most basic static analysis method is pattern matching. A pattern matcher considers the program as a text file. It may not even distinguish between the code and the comments. The pattern matcher searches for vulnerable functions or patterns in the text of the program code. Thus, this method can be implemented using any pattern matching utility, such as grep. Such a tool needs a database of the vulnerability patterns. As an example, Flawfinder \hyperref[b44]{[44]} scans C/C++ programs to detect buffer overflow or format string in them. This tool ignores the text inside the comments and strings. However, it does not recognize the type of function parameters and control flow or data flow of the program. This lack of knowledge results in many false decisions. Thus, it makes many false positive and false negative alarms.  
\section[{Lexical analysis}]{Lexical analysis}\par
In this method, source code of the program is tokenized in order to recognize the variables and function arguments. Thus, the results of a lexical analyzer can be more accurate than the results of a pattern matcher. As an example, the tool ITS4 applies lexical analysis to detect buffer overflow, format string and race condition vulnerabilities in C or C++ programs \hyperref[b45]{[45]}. ITS4 scans the source code statically and breaks it into series of lexical tokens. These tokens are compared with the token streams that are defined in a vulnerability database. The vulnerability database contains several handlers for well-known vulnerable functions in C/C++. 
\section[{Parsing}]{Parsing}\par
In this method, source code of the program is parsed and represented in Abstract Syntax Trees (AST). The ASTs are then used to analyze the program syntactically and semantically. For example, Lint uses this method to detect vulnerabilities in programs written in C \hyperref[b46]{[46]}. As another example, in \hyperref[b47]{[47]} the ASTs of the source code are extracted and compared to the ASTs of different vulnerable codes. The main idea in \hyperref[b47]{[47]} is that different vulnerabilities in software may be related to the same flawed programming pattern. Thus, the suggested method uses the ASTs of known vulnerable codes and searches for similar patterns in the target program. When a similar pattern is found in the program, it may reveal an unknown vulnerability. 
\section[{Data flow and taint analysis}]{Data flow and taint analysis}\par
In this method, the flow of data among the instructions is analyzed to determine possible values that a variable holds during the run time. Two wellknown program representations are used in this method: control flow and data flow graphs. In a control flow graph, each node represents an instruction and a 
\section[{Global Journal of Computer Science and Technology}]{Global Journal of Computer Science and Technology}\par
Volume XVII Issue I Version I  \hyperref[b48]{[48]} extracts the control flow and data flow graphs from the source code. It then compares extracted graphs with some patterns of known vulnerabilities. In this method, known vulnerabilities are specified as simple patterns of vulnerable functions or more complex flow-based rules.\par
A subclass of data flow analysis is called taint analysis. A taint analyzer only tracks the flow of data that come from un-trusted resources. The un-trusted resources include the network protocols, keyboard, touchpad, webcam, files, etc. Since most of the vulnerabilities are exploited by un-trusted input data, this method pays attention to the flow of un-trusted input data in the program. If such data reach sensitive statements in the program, a vulnerability may be reported by the taint analyzer. The sensitive statements, called sinks, are defined according to the specified vulnerabilities. For example, the functions that execute SQL queries are usually defined as the sinks for SQL injection vulnerability. The propagation of tainted data among the instructions is determined based on some predefined rules. For example, if the data in a tainted variable is assigned to an un-tainted variable, the untainted variable will get tainted too.\par
Taint analysis is used in many of the proposed vulnerability detection solutions, e.g. \hyperref[b49]{[49]}, \hyperref[b50]{[50]}, \hyperref[b51]{[51]}, \hyperref[b52]{[52]} and \hyperref[b53]{[53]}, to detect various vulnerability classes. Since this method focuses on the flow of tainted data, it does not consider the execution paths in the program that are not affected by malicious data. This feature reduces the time of analysis and number of produced false positives. However, there are vulnerability classes that cannot be specified in such a source-sink structure, e.g. logic vulnerabilities. Although an attacker exploits logic vulnerabilities with malicious data, the sinks cannot be easily specified for this class of vulnerability. For example, the sinks for SQL injection vulnerability are the query execution statements. But a sink for logic vulnerabilities may be any statement that manipulates the input data. 
\section[{Annotation-based methods}]{Annotation-based methods}\par
Annotation is a comment that the programmer makes in the code about the desired behavior of a function or an instruction. It may be defined as a set of pre-and post-conditions or as simple pre-execution conditions. An annotation-based analysis algorithm reads the annotations, analyzes the code statically and verifies if the conditions are met in the program. There are plenty of annotation languages presented so far, such as SPLINT \hyperref[b54]{[54]}, MECA \hyperref[b55]{[55]}, Sparse \hyperref[b56]{[56]}, SAL \hyperref[b57]{[57]} and a Comment \hyperref[b58]{[58]}.\par
Since there is a huge number of statements and functions in the programs, manual annotation is usually very time consuming and fault prone \hyperref[b58]{[58]}. There are annotation languages that provide some facilities to annotate the program more easily, such as MECA \hyperref[b55]{[55]} and aComment \hyperref[b58]{[58]}. Among them, aComment is designed to help in detecting concurrency faults in the operating systems and allows the programmers to define the pre-and post-conditions that are related to the interrupts in each function. It also infers the annotation of some functions automatically to reduce the programmers' workload. In this way, the programmers are not supposed to annotate all the functions manually.\par
Although some of these languages help in reducing the required time and effort for annotating the programs, they usually have a different syntax and directed edge between two nodes represents their semantics than the applied programming languages. Therefore, the programmers and verifiers have to make extra efforts to learn another language in order to use this method. Also, the programmers should be familiar with the security requirements of the programs and the vulnerability classes to annotate the program appropriately. Therefore, the success of this method depends on the programmers' knowledge of software security. Moreover, this method is not helpful in analyzing the COTS 1 software and third party components since their source code is not available. 
\section[{Constraint analysis}]{Constraint analysis}\par
In this method, the program is analyzed statically and some constraints are calculated for specific objects in it. The constraints are defined according to specific vulnerabilities and are solved to verify if the program suffers from those vulnerabilities. Constraint analysis was first proposed by Wagner et al. in \hyperref[b50]{[50]}. The resulted tool, called BOON, considers the strings in a C program as an abstract data type. There are also predefined functions that manipulate this data type, such as strcpy(), strcat(), etc. BOON summarizes the state of each string by two integer values: the allocated size for the string and its current length. For each string in the buffer, it analyzes the string manipulating statements in the program to verify if the length of the string exceeds its allocated size. If such condition is inferred, the program might contains buffer overflow vulnerabilities.\par
It is important to note that the constraints are determined by the analyzer in this method, not by the programmer. This makes the constraint analysis method different from the annotation-based analysis method.\par
Moreover, constraint analysis does not increase the programmer's workload since generation of the constraints is performed automatically and does not involve the programmer. Of course, it cannot profit the programmers' knowledge of the code to do a more efficient analysis. 
\section[{Theorem proving}]{Theorem proving}\par
In this method, the software and its specification are expressed as some formulas of logics or algebraic systems. Also, the security requirements of software are expressed as some theorems. Proving these theorems demonstrates the satisfaction of the security requirements. Otherwise, there is a fault (vulnerability) in the program. As an example, in \hyperref[b59]{[59]} the source code of target program is statically analyzed and some firstorder formulas are generated that assert the absence of certain faults and vulnerabilities, such as out-of-bounds array access. If the generated asserts are proved, the program does not contain such faults and vulnerabilities.\par
Although the results of analysis are accurate in the theorem proving methods, they demand expertise and enough experience. In fact, theorem proving is difficult to be achieved automatically and requires highquality staff to apply this method, which is very timeconsuming. So it is generally used to verify correct design rather than the actual code \hyperref[b60]{[60]}. Simple, fast.A\par
Does not have any idea about the types of function parameters and control or data flow of the program and so generates many false alarms. \hyperref[b44]{[44]}. 
\section[{Lexical Analysis}]{Lexical Analysis}\par
Tokenizes the code to recognize variables and function arguments.\par
Variables and function arguments are recognized. More accurate than the pattern matching method.\par
Lack of knowledge about the syntax and semantics of the code causes false alarms. Requires the high level source code. \hyperref[b45]{[45]}. 
\section[{Parsing}]{Parsing}\par
Parses the code and represents it in Abstract Syntax Trees (AST) to be analyzed syntactically and semantically.\par
Understands the code syntactically and semantically, less false alarms in comparison with the above two methods.\par
Requires the high level source code.\par
[47],\par
[46], \hyperref[b30]{[30]}, \hyperref[b31]{[31]}, \hyperref[b66]{[66]}. 
\section[{Annotation-based methods}]{Annotation-based methods}\par
Comments that the programmer makes about the desired behavior of the code. The code is then analyzed statically to verify if the conditions are met.\par
Profits the programmers' knowledge to do a focused analysis.\par
The programmer must learn an additional language to do the annotation.\par
[54],\par
[55], \hyperref[b56]{[56]},\par
[57], \hyperref[b58]{[58]}. 
\section[{Theorem proving}]{Theorem proving}\par
The security requirements of software are expressed as some theorems. Proving these theorems, demonstrates the satisfaction of the security requirements or existence of vulnerabilities. 
\section[{Accuracy.}]{Accuracy.}\par
Difficult to be achieved automatically and requires high-quality staff to apply this method \hyperref[b59]{[59]}. 
\section[{Data flow analysis (Taint analysis)}]{Data flow analysis (Taint analysis)}\par
Tracks the flow of the data that comes from un-trusted resources and warns if the data reaches sensitive program points.\par
Reduces the analysis time and number of false positives by not considering the execution paths in the program that are not affected by un-trusted data.\par
Cannot detect vulnerabilities that are not defined specifically in a source-sink structure.\par
[51], \hyperref[b52]{[52]}, \hyperref[b53]{[53]},\par
[67], \hyperref[b50]{[50]},\par
[68], \hyperref[b69]{[69]}, \hyperref[b70]{[70]}. 
\section[{Constraint analysis}]{Constraint analysis}\par
Analyzes the program, associates constraints with some objects in the code and solves them to verify if the program is vulnerable.\par
Constraints are generated automatically and do not increase the programmer's workload.\par
Does not profit the programmer's knowledge of the code (in comparison with the annotation method).\par
[50],\par
[51], \hyperref[b52]{[52]}, \hyperref[b53]{[53]}. 
\section[{Model checking}]{Model checking}\par
Models the program and then checks the model to verify if it satisfies specified requirements.\par
Only the modeling and requirement specification is performed manually by the human analyzer, rest of the analysis is done automatically.\par
Modeling the program and specifying its security requirements-if done manuallyis time consuming and fault prone. State-explosion problem when the number of program states is large.\par
[61],\par
[62], \hyperref[b63]{[63]},\par
[71], \hyperref[b64]{[64]}. In this method, the program is modeled and then analyzed to verify if it complies with its specifications, e.g. \hyperref[b61]{[61]}, [62], \hyperref[b63]{[63]} and \hyperref[b64]{[64]}. If a specific requirement is not satisfied in the software, this method provides some counter examples. Model checking helps the human analyzers by automating a noticeable part of the analysis. Although modeling and specifying the requirements may be done manually, analyzing all possible states of the program and verifying the requirements are done automatically. This is a great help in analyzing large programs. A well-known example of using this method for detecting vulnerabilities is MOPS \hyperref[b63]{[63]}. Using MOPS, the program is modeled as a push-down automaton 2 . Also, the requirements are defined through safety properties. A safety property is represented as a finite state automaton. It defines the ordering constraints on security related operations. After modeling the program and defining its constraints, MOPS searches exhaustively through possible program states to check if a reachable state violates the safety properties.\par
Abstracting the program in a model is a challenging task in this method. The model should be expressive enough to have a precise analysis. Thus, some model checking methods 2A push down automaton is a type of computational model. It is similar to NFAs except that it uses an additional component called a stack. In this model, state transitions are chosen based on three components; input signal, current state and what is at the top of the stack. Thus, the stack plays the role of an additional memory for it. also help the analyzer to model the target program. For example, MOPS uses the control flow of the program to build its automata. Also, in \hyperref[b64]{[64]} the GCC compiler is used to automatically model and verify the programs that are written in any language supported by this compiler, i.e. C, C++, Java, etc. This is done by employing an intermediate language of GCC, called GIMPIL, that is common to all the supported languages. The model is extracted from the intermediate representation of the program and is checked against the defined specification by the use of Moped. Moped is a model checking tool for push down systems 3 65].\par
There are, however, some shortcomings in the model checking method. Although the modeling phase is performed automatically in some model checking methods, the analyzer should manually specify the security requirements in this method. This is again time consuming and may cause errors in the results. Also, the method suffers from state-explosion problem for large programs.\par
Table  {\ref II} summarizes the reviewed static analysis methods. Note that all these methods inherit the general advantages and shortcomings of static analysis. iv. 
\section[{Dynamic Analysis}]{Dynamic Analysis}\par
By executing the program with actual data, dynamic analysis studies the exact run-time behavior of the program. Dynamic analysis can be as fast as the execution of the program, whereas static analysis generally requires more computation time to obtain accurate results \hyperref[b43]{[43]}. The main challenge in dynamic analysis methods is executing all the possible execution paths in the program and activating all vulnerabilities in those paths. In fact, acquiring an appropriate test data set, that make the program behave more diversely, is an issue in these methods. The most important shortcoming of dynamic analysis methods is that they components; input signal, current state and what is at the top of the stack. Thus, the stack plays the role of an additional memory for it. are unable to guarantee the analysis of all feasible execution paths. Therefore, the dynamic analysis is not sound and is mostly used to prove the existence of specific vulnerabilities in the programs. The dynamic methods are classified into two main classes in \hyperref[b12]{[12]}: methods that use symbolic input values and methods that use actual (concrete) input values to test the program. Based on the recent advances in dynamic analysis methods, we classify these methods in three classes based on the type of applied input values: concrete execution, symbolic execution and concolic (concrete + symbolic) execution methods. The following subsections describe each class in more details. 
\section[{a) Concrete execution}]{a) Concrete execution}\par
In this method, the program is executed with actual data and its behavior is analyzed to detect vulnerabilities. There are four dynamic analysis methods that use actual data to execute the program during the analysis: fault injection, mutation-based analysis, dynamic taint analysis and dynamic model checking.\par
i. Fault injection In this method, the external faults are injected to the program to examine its behavior. According to our definition in section II, the external faults abuse the internal faults and cause unauthorized behaviors in the program. In other words, internal faults are activated by the external fault and are propagated to reach the program boundaries. Therefore, inability to handle external faults may reveal a vulnerability in the program.\par
The external faults may be injected by corrupting input data to verify if the program is able to handle them. Most of the blackbox vulnerability scanners corrupt input data and analyze the reaction of the program, such as \hyperref[b72]{[72]} and \hyperref[b73]{[73]}. The black-box scanners have access to the inputs and outputs of the program. They might also have very little knowledge about the program internal structure \hyperref[b74]{[74]}. They usually create the corrupted data based on known attack patterns to study if the program can resist these attacks or suffers from the relevant vulnerabilities. Another group of dynamic vulnerability detectors that inject corrupted input data to the programs are fuzzers. Takanen et al. introduced fuzzing for detecting vulnerabilities for the first time. They suggested injecting unexpected random input data to the program and studying its behavior \hyperref[b74]{[74]}. The difference between fuzzers and black-box vulnerability scanners is that fuzzers don't corrupt input data exactly based on a list of attack patterns. In fact, they generate numerous random faulty data hoping that some data make the program crash. The main advantages of this method were simplicity and independence from the analyzed program. Thus, the method could be used easily to detect vulnerabilities in different programs. However, fuzzers were not intelligent enough to corrupt input data effectively and cover most of the execution paths. In order to have better program coverage, new fuzzers focus on producing well-formed corrupted data \hyperref[b75]{[75]}, satisfying data validation checks in the program like checksums \hyperref[b76]{[76]}, being aware of the state of the program during the fuzzing \hyperref[b77]{[77]} and producing consistent input data with the path conditions to make the program execute all the branches \hyperref[b78]{[78]}, \hyperref[b79]{[79]}, \hyperref[b80]{[80]}, \hyperref[b81]{[81]}. All these enhancements made fuzzers play an effective role in detecting vulnerabilities during the recent years \hyperref[b82]{[82]}. Injecting faults into the program can be done randomly or intelligently. By the word random, we mean that faulty data are generated semi-randomly based on predefined patterns. For example, in order to detect buffer overflow, random input data with different lengths are generated. Here the predefined pattern determines the length of input data and the other properties are set randomly. Takanen et al. consider random fuzzers as the ones that make small random changes into the valid data. For example, a FTP fuzzer may randomly add valid/invalid commands to the test data or chose the arguments of the commands randomly \hyperref[b74]{[74]}. Random fuzzers sometimes use evolutionary algorithms to guide random choices and extend the program coverage, e.g. [83], \hyperref[b84]{[84]}. Random corruption of data is simple and independent from the logic and structure of the programs. Moreover, randomness helps to reveal a wide range of behaviors of the programs while the designed testcases by the human analyzer may not. This is because the designed test-cases are prepared by a human analyzer who may not think of all possible behaviors of the program.\par
Corrupting the data intelligently is performed based on a previous analysis of the program. Although it requires more analysis efforts, it helps in extending the program coverage. For example, imagine a program that compares one of the input values with an integer value and exits if they are not equal. Using the random method, the possibility of passing this constraint is one out of 232. By analyzing the code before injecting faulty data, the analyzer is able to extract the constraint and generate the data in a way that complies with the constraint. This helps the intelligent corruption method have more reliable program coverage \hyperref[b74]{[74]}. 
\section[{ii. Mutation-based analysis}]{ii. Mutation-based analysis}\par
As mentioned before, acquiring appropriate test data is an issue in dynamic analysis. When the program behaves normally during the test process, it means that either there is no vulnerability in the program or the test data don't reveal the vulnerabilities in the program. In the latter case, the data set is not diverse enough to activate the vulnerabilities. Mutation is a method that is concerned with enhancing the data set during the dynamic analysis. In this method, specific vulnerabilities are injected into the program code intentionally. If the current data set does not detect the injected vulnerability, it will not detect similar vulnerabilities in the original version of the program. Thus, the analyzer augments the data set so that it can detect the vulnerability. A version of a program in which a specific vulnerability is created, is called a mutant. For example, in a mutant the function strncpy( ) is replaced with strcpy( ) to make it buffer overflow vulnerable. A good test data set distinguishes the mutants from the original version of the program and kills them. If no test-case kills the mutants, the data set must be augmented \hyperref[b85]{[85]}.\par
This method is effective in detecting software vulnerabilities \hyperref[b85]{[85]}, though it requires considerable amount of time and effort. If the changed statements in a mutant are executed by the test data, the mutant would be effective. Otherwise, the result of analysis does not reveal the difference between the mutant and the original version of the program. Therefore, some computations are required to generate appropriate testcases that make the program execute the intended path which contains the vulnerability.\par
Also, automatic creation of mutants for complex vulnerabilities is a challenge. As an example, the strncpy ( ) functions are automatically changed to strcpy ( ) for creating mutants to detect buffer overflow in \hyperref[b85]{[85]}. There are, however, more complicated buffer overflow scenarios like copying an array in a loop that causes overflow. Moreover, creating mutants for logic vulnerabilities requires a deep understanding of the logic of the program. Thus, automatic generation of mutants may not be feasible.\par
iii. Dynamic model checking This method, which is also called executionbased model checking \hyperref[b86]{[86]}, \hyperref[b87]{[87]}, is a model checking method that executes the program exhaustively and checks if it satisfies the specifications. For example, the tools VeriSoft \hyperref[b88]{[88]}, JavaPathFinder \hyperref[b89]{[89]}, CMC \hyperref[b90]{[90]}, Bogor \hyperref[b91]{[91]} and DART \hyperref[b92]{[92]} apply this method in their analysis. Random execution in dynamic model checking is mostly the result of two factors: program inputs and scheduling choices of a scheduler \hyperref[b87]{[87]}. For each random input and schedule choice, the resulted behavior of the program is analyzed by monitoring the process and its environment, e.g. registers and the stack. Here, each state consists of the entire machine state. When the execution reaches a state, in which the specification is compromised, the related input value and schedule choice are presented as a counterexample.\par
An advantage of dynamic model checking is that by executing the program, the machine handles the semantics of the instructions. In other words, there is no need to formally represent the semantics of the programming language and the machine instructions \hyperref[b87]{[87]}. However, there is a time-state-soundness tradeoff in this method. Since the states represent the entire machine state, they contain many details and require more storage space. Thus, storing all the states might be infeasible for large programs. At the same time, exploring the states without a history of visited ones may cause visiting similar states again and again. When no state is recorded, the model checker spends too much time to make sure it has traversed all possible states. Storing the states reduces the verification time by making sure that no state is revisited. Yet, it requires too much space \hyperref[b87]{[87]}.\par
iv. Dynamic taint analysis This method is similar to static taint analysis as it tracks the flow of information from un-trusted sources to the sinks. However, it tracks the flow of tainted data during the execution of the program, some examples are \hyperref[b93]{[93]}, \hyperref[b94]{[94]}, \hyperref[b95]{[95]} and \hyperref[b96]{[96]}. Schwartz et al. describe this method precisely in \hyperref[b93]{[93]}. They introduce a language, named SIMPIL, that formally defines the algorithms of dynamic taint analysis. Before the execution, all the variables are considered untainted. While executing the program, variables may get tainted according to a predefined policy. This policy defines how the taint data propagate from a variable to other variables. For example, when tainted data are used in an argument of an arithmetic operation, the policy defines that the result of this operation should be considered tainted. If a tainted value reaches a sink, the analyzer reports a vulnerability.\par
The basic taint analysis methods limit taint propagation to the direct assignments. This might make the results of the analysis inaccurate \hyperref[b97]{[97]}. Sarwar et al. present some scenarios in \hyperref[b97]{[97]} to show how basic taint analysis can be ineffective. An example scenario is that the tainted data are used in a conditional statement (without any direct assignment to other variables) and affect on the control flow of the program. Also, tainted data might be used to define the number of an iterative action or as the index of an un-tainted array. The taint analysis method should pay attention to these indirect effects of the tainted data in calculating the taint propagation. Considering such effects is not always easy. For example, the tainted variable might cause information leakage through a side channel. To detect such vulnerability, the analyzer should taint a large amount of variables that results in many false alarms \hyperref[b97]{[97]}.\par
Table  {\ref III} summarizes and compares the advantages and disadvantages of the concrete execution methods. Each method inherits the advantages and shortcomings of dynamic analysis. 
\section[{b) Symbolic execution}]{b) Symbolic execution}\par
Using the symbolic execution method, the program is executed with symbolic input values instead of concrete data values \hyperref[b98]{[98]}, \hyperref[b99]{[99]}. Thus, the values of program variables are represented as symbolic expressions over the symbolic input. During the symbolic execution, the state of the program and the conditions of the current path are calculated symbolically. The path conditions are updated any time a branch instruction is executed. At the end of an executed path, the path conditions are solved using a constraint solver. There are various constraint solvers presented by now, such as STP \hyperref[b100]{[100]} and Z3 \hyperref[b101]{[101]} that solve the constraints on binary vectors and Hampi \hyperref[b102]{[102]} and S3 \hyperref[b103]{[103]} that solve the constraints on string variables. If the constraint solver solves the path conditions, it generates some concrete input data that are used to execute the intended path in the program.\par
There are several challenges with the symbolic execution method. For example path explosion, the overhead of constraint solving for complicated paths, non-determinism of concurrent programs and the tradeoff between precision and scalability of modeling the memory are some of the challenges in applying symbolic execution \hyperref[b104]{[104]}. Cadar and Sen present the challenges of this method and mention some solutions for them \hyperref[b104]{[104]}.\par
To overcome these challenges, a solution is combining symbolic execution with concrete execution. The result is a new method that is called concolic execution. This method is described in the next section. 
\section[{c) Concolic execution}]{c) Concolic execution}\par
A problem with pure symbolic execution is that the constraints of complex loops and recursive functions may get very complicated and cannot be resolved in an acceptable time \hyperref[b105]{[105]}. Concrete execution applies real data to execute the program. There is a little chance to traverse all the feasible paths in this method. Using the combined method, concolic + symbolic execution, the concrete data is used to simplify the complex constraints that are generated by the symbolic execution. This method was first presented by Godefroid et al. in \hyperref[b92]{[92]}. Concolic execution is performed by changing some symbols in the complex constraints into the concrete values. This helps to achieve better program coverage with much less computation overhead.\par
A New View on Classification of Software Vulnerability Mitigation Methods Concolic execution is used in many of the recent fuzzers to extend their knowledge about the program, such as KLEE \hyperref[b78]{[78]}, EXE \hyperref[b80]{[80]}, Simfuzz \hyperref[b75]{[75]}, CUTE \hyperref[b106]{[106]}, SAGE \hyperref[b79]{[79]}, Taintscope \hyperref[b105]{[105]} and [107]. For example, CUTE combines symbolic execution with concrete execution to create input data traverse deeper paths in the program. It first executes the program with concrete input data. During the execution, it calculates symbolically the constraints of the executed path. The calculated constraints are then negated one by one, from the last to the first. After each negation, the resulted constraints are queried from a constraint solver. If the constraint solver solves the new constraints, the result is used to generate new test data that traverse other execution paths in the program. 
\section[{Global}]{Global} 
\section[{Table 3: Concrete execution methods: a comparison}]{Table 3: Concrete execution methods: a comparison}\par
Concolic execution is also used in other dynamic vulnerability detection methods. For example in \hyperref[b107]{[108]} a dynamic model checking method is applied that uses concolic execution for state-space exploration of the analyzed application. In \hyperref[b107]{[108]}, concolic execution helps to model the application as a finitestate automata and to guide further state-space exploration. 
\section[{d) Hybrid analysis}]{d) Hybrid analysis}\par
The previous sections described static and dynamic analysis methods and their advantages and shortcomings. The idea of combining static and dynamic analysis was first proposed by Ernst in \hyperref[b43]{[43]}. He suggested that hybrid analysis can combine the static and dynamic analysis methods to generate a new analysis method that profits a great amount of soundness and accuracy advantages of each method with little sacrifices.\par
Monitoring and static analysis methods are also combined in \hyperref[b109]{[110]} to detect SQL injection errors and [83], \hyperref[b84]{[84]}, \hyperref[b75]{[75]}, \hyperref[b76]{[76]}, \hyperref[b78]{[78]}, \hyperref[b79]{[79]}, \hyperref[b80]{[80]}. 
\section[{Mutation-based Analysis}]{Mutation-based Analysis}\par
Injects vulnerability into the program code. If the current data set does not reflect the injected vulnerability, it would not detect similar vulnerabilities in the original version of the program.\par
Reduces false negatives by enriching test data.\par
Expensive in time and computation. Automatic mutation of complicated vulnerabilities is a challenge. \hyperref[b85]{[85]}. 
\section[{Dynamic taint analysis and sanitization}]{Dynamic taint analysis and sanitization}\par
Tracks the flow of information from input sources to the sinks during the run-time.\par
Reduces the analysis time and number of false positives by not considering the paths in the program that are not affected by malicious data.\par
Cannot detect vulnerabilities that are not defined in specific source-sink structure.\par
[93], \hyperref[b96]{[96]}. 
\section[{Dynamic Model checking}]{Dynamic Model checking}\par
A model checking method in which the program is executed with concrete input values exhaustively.\par
No need to formally represent the semantics of the programming languages and machine instructions. Time-state-soundness tradeoff.\par
[88], \hyperref[b89]{[89]}, \hyperref[b90]{[90]}, \hyperref[b91]{[91]}, \hyperref[b92]{[92]}.\par
From then, many researchers have combined these methods, in different manners, to make up for each other's shortcomings. For example, Monga et al. combine static and dynamic analysis to detect XSS and SQL injection vulnerabilities in PHP applications in \hyperref[b108]{[109]}. The suggested method first analyzes the code statically and extracts the control flow graph of the functions in it. These graphs are then connected together to obtain an inter-procedural control flow graph (iCFG). The iCFG is analyzed to extract the possible paths from the tainted sources to the sinks in it. For each sink, backward slicing is used to detect the statements that affect the tainted argument. These statements are monitored at run time. When a tainted value is used in a sink, the monitoring procedure passes it to an oracle to verify if it can exploit a vulnerability. The oracle have a database of well-known attack patterns that are used to exploit different vulnerabilities. For example, the implemented oracle for mysql query() performs a limited syntactically analysis on the SQL queries and searches for the tainted characters in unsafe positions. In this method, the sanitizing procedures are assumed to be perfect. prevent the successful attacks. In the static analysis phase the hotspots, that are statements in the program that execute a SQL query, are identified. Also the control flow of the program is extracted. Then, the query strings in the hotspots are parsed. Considering the control flow of the program, a FSA for each hotspot is created to model the legitimate queries. During the monitoring phase, the queries are checked against the relative FSA to prevent execution of malicious queries.\par
As the last example, hybrid analysis is used in \hyperref[b110]{[111]} to detect logic vulnerabilities in web applications. The logic vulnerabilities are usually related to the intended functionality of an application. Thus, there is no general specification for them that can be used in different applications. For example, consider an online store that allows the users to use coupons for having discount on specific items. It has a policy which determines that each coupon should be used only once. A logic vulnerability, however, allows the users to reuse a coupon and reduce the cost to zero. Since logic vulnerabilities are created based on the functionality of the application, the vulnerability detection method requires the specification of the program. The proposed method in \hyperref[b110]{[111]} consists of two steps. First, the web application is executed with normal input data. The executed traces are then analyzed to infer the specification of the application. This is based on the intuition that normal behavior of the program reflects the properties that are intended by the programmer. In fact, because the specification of the program is not always available, this method uses dynamic analysis to obtain it. The inferred specification is presented in the form of likely invariants. In the second step, model checking is used to analyze the web application based on the inferred specification. 
\section[{e) Vulnerability forecasting}]{e) Vulnerability forecasting}\par
Generally, fault forecasting is used to predict the quality or quantity of the faults that are left in the system and will be activated in the future. It is mainly concerned with estimating the current reliability of the system and predicting its future reliability. This prediction may be qualitative or quantitative (usually probabilistic). The qualitative forecasting identifies and ranks the future failure modes. Also, the event combinations that lead to the failures are identified.\par
The quantitative forecasting is performed by modeling or operational testing. These methods are complementary, since the results of operational tests are usually used to model the system more accurately. Software Reliability Growth Models (SRGM) are used generally for fault forecasting. In fact, SRGMs model the testing process \hyperref[b111]{[112]}. In most of these models, the rate of fault detection gradually reduces and the cumulative number of faults eventually approaches a fixed value. These models help to predict the number of left faults in the software and determine when the software is ready to be released. They are also used to estimate the required efforts for future maintenance.\par
There are probabilistic models for predicting the rate of vulnerability detection, named Vulnerability Detection Models (VDM). Alhazmi and Malaiya proposed a specific model, named AM 4 for vulnerability detection in \hyperref[b112]{[113]}. In this model the rate of vulnerability detection depends on two factors: one of these factors reduces as the number of remaining undetected vulnerabilities declines. The second factor increases with the time. In this way, the rate of vulnerability detection is modeled in a S-shaped form. In fact, AML is created based on the observation that the detectors 5  pay little attention to the newly published software. Gradually people become familiar with the software and the detectors pay more attention to it. Thus, the rate of vulnerability detection increases by time and peaks at some period. By the introduction of newer versions of the program, the detectors' interest becomes lower and the rate of vulnerability detection decreases. Alhazmi and Malaiya examined the applicability of this model to various operating systems in \hyperref[b112]{[113]} and \hyperref[b113]{[114]}. The results demonstrated that AML fits the data of several operating systems.\par
All the mentioned models are time-based. It means that they determine the detection rate based on the calendar time. An effort-based model, named AME 2,   is proposed by Alhazmi and Malaiya in \hyperref[b112]{[113]}. They believe that time-based models do not consider the changes that occur in the environment during the lifetime of the system. Thus, they consider the number of installations as an important environmental factor that affects the rate of vulnerability detection. It is based on the observation that the detectors are more interested in the software that is installed in many computers. Therefore, the rate of vulnerability detection is modeled in AME based on the number of installations. Sungwhan Woo et al. explore the applicability of AML and AME to some HTTP servers, i.e., IIS and Apache. The results indicate that these models are applicable to the HTTP servers in addition to the operating systems \hyperref[b111]{[112]}. Of course, this method does not consider many of the effective factors on the detection trend. For example, it only calculates the cyclomatic complexity to estimate the code complexity. There are other complexity metrics that can be considered in addition to A problem with the studied VDMs is that they are parametric models that should be fitted to real vulnerability data \hyperref[b114]{[115]}. To model the vulnerability detection rate in a specific application, a large amount of historical vulnerability data is required. Therefore, it is necessary that many of the vulnerabilities be discovered already. Hence, these models cannot be applied to predict the detection rate for newly released software. Also, it is shown in \hyperref[b115]{[116]} that the precision of VDMs depend on the number of known vulnerabilities. The precision of the VDMs are usually very low at the early stages in the lifecycle of the program. It seems that the problem is because the models don't consider the features of each application in their predictions. Thus, they need a history of detected vulnerabilities to estimate the security level of the program. There are many features in each application and its environment that affect the rate of vulnerability detection. Rahimi and Zargham present a VDM in \hyperref[b114]{[115]} based on two effective factors: code complexity and code quality. The code complexity is defined based on the cyclomatic complexity. Also, the code quality determines its compliance with secure coding practices. They believe that more vulnerabilities are detected in the applications with lower code quality. Also, the possibility of detecting vulnerabilities is less in the applications with complicated codes. Thus, the source code of the application is statically analyzed to compute the two factors. The computed data are then used to model the vulnerability detection rate. Since this model does not need a database of detected vulnerabilities, it can be used for newly released applications. The authors analyze four applications to study the impact of these factors on the vulnerability detection trend. The analysis results show that the proposed method can predict vulnerabilities even in early stages of the application's lifecycle.\par
this one. The environmental parameters can also be considered for a good prediction. As an example, even the seasonal changes affect the rate of vulnerability discovery. It is shown in \hyperref[b116]{[117]} that more vulnerabilities are reported during the mid-end and year-end months. Also, the presented method in \hyperref[b114]{[115]} is based on analyzing the source code of the application. So it cannot be helpful when the source code is not available. There are some qualitative methods for estimating the current security level of the application. For example OWASP ASVS consists of several check lists that helps to determine the security level of a web application \hyperref[b117]{[118]}. It classifies the check lists in thirteen classes, such as authentication, access control, session management, etc. In each class the check lists are grouped into three security levels. If an application passes all the check lists of a group, it is achieves the respective security level. These methods only estimate the current security level. Based on the current level, it is possible to predict the future failure modes. However, we could not find any qualitative method that predicts and ranks the future security failures based on the current state.\par
V. 
\section[{Conclusions}]{Conclusions}\par
During the past decades various methods have been presented for mitigating software vulnerabilities. A comprehensive classification of the proposed methods helps to achieve a general understanding of this research area. In this paper, we defined software vulnerability as an internal fault. By considering software vulnerability as a type of fault, we classified the vulnerability mitigation methods based on the general classification of the fault mitigation methods. We extended the general classification of fault mitigation methods, represented it in the context of software vulnerability and added more detailed subclasses into it. We divided vulnerability mitigation methods into four main classes: vulnerability prevention, vulnerability tolerance, vulnerability removal and vulnerability forecasting. The vulnerability prevention methods attempt to prevent the occurrence of software vulnerability. Software security and the secure coding best practices are examples of these efforts. The question is why, despite the vulnerability prevention efforts, vulnerabilities are still created. Oliveira et al. believe that educating the developers is not enough for preventing the vulnerabilities \hyperref[b118]{[119]}, because security is not an issue for the developers. They believe that the human's memory is limited and can only keep a limited number of mental elements available at a time. The programmers are also supposed to create applications with correct functionality and acceptable performance. Under the time pressure, an ordinary situation in software programming, the programmers usually chose the simplest solutions for developing the software and pay little attention to the security concerns. Oliveira et al. suggest developing assistant tools that remind the educated programmers the security concerns during the development.\par
Besides educating the programmers, intelligent assistant tools are required to notify the security concerns at specific statements or functions. Thus, in the future we should work on designing and implementing intelligent assistant tools that help the programmers to avoid generating vulnerabilities during the design and implementation of the applications. These tools should be intelligent enough not to bother the developers with many false alarms. They may use the enhanced static analysis methods to analyze the code during the coding phase and warn the programmers at sensitive situations. This will help the programmers to use their security knowledge more effectively in preventing the vulnerabilities.\par
Vulnerability tolerance methods accept the existence of vulnerabilities in the programs and prevent the active vulnerabilities from making security failures. In this paper, the vulnerability tolerance methods were studied based on three aspects: the applied active vulnerability detection technique, active vulnerability A New View on Classification of Software Vulnerability Mitigation Methods handling technique and vulnerability handling technique. All the reviewed vulnerability mitigation methods detect active vulnerabilities during the normal execution of the program (concurrently). However, there are active vulnerabilities that overuse system resources and make the resources unavailable to legitimate users after a period of time, such as the memory leakage vulnerability. The security failure as a result of these vulnerabilities can be prevented by checking the system resources periodically. Thus, preemptive error detection can be applied to detect if such vulnerabilities are active.\par
Most of the vulnerability tolerance methods focus on detecting the active vulnerabilities. However, less attention is paid to handling the (active) vulnerability. In the proposed methods, active vulnerabilities are handled by halting the program, restarting the program or invoking an exception handler. Although these mechanisms limit the negative effects of the active vulnerability, they violate the availability of the application to the legitimate users. Thus, more intelligent vulnerability handling techniques are required for the current vulnerability tolerance methods. A good starting point is inspiring by the current fault tolerance methods. As an example, software diversity is a fault tolerance method that is used to make the programs reliable. In this method, various versions of software with the same specification but different design or implementationprocess the same request and the correct result is achieved by voting the results of the different versions. The result of such system is more reliable, since it is less possible that all the versions of software suffer from the same fault and so a request does not cause errors in all versions. This method can be used in software security to tolerate malicious requests. For example, recently software diversity has been used in \hyperref[b119]{[120]} to tolerate active vulnerabilities in web browsers. In the proposed method, different browsers are used to process the user's requests. Since the browsers are designed and implemented differently, it is less probable that all the applied browsers contain similar vulnerabilities. Thus, malicious data cannot compromise all the browsers. The correct response to the client's request is achieved by voting the responses of the browsers. Also, some protection mechanisms, such as ASLR that protects system against memory corruption vulnerabilities \hyperref[b120]{[121]}, are inspired by the idea of using diversity to make the program unpredictable for the attackers. A new direction for the future research could be adopting the current fault tolerance methods to handle different software vulnerabilities. As there is no vulnerability handling mechanism in the current proposed methods, we should work on designing complete vulnerability tolerance methods that contain appropriate active vulnerability handling and vulnerability handling mechanisms.\par
Vulnerability removal is performed to detect and remove the vulnerabilities in the software. The focus of most of the current vulnerability removal methods is on verifying the vulnerabilities. In fact, less attention is paid on designing appropriate methods for diagnosis, correction and regression verification of software vulnerabilities. There are some vulnerability diagnosis and correction methods that are used after detecting the exploitation of a vulnerability. But specific methods are required for diagnosis and correction of the vulnerabilities that are detected during the verification of the program. Currently, automatic patching methods analyze an attack and generate software patches based on the pattern of malicious data that are used in the attack. These methods can be modified to automatically generate patches based on the results of analyzing the program and according to the mechanism of detected vulnerabilities.\par
There are numerous vulnerability detection methods presented by now. Most of the recent vulnerability detection methods tend to combine the previous methods in order to profit their advantages at the same time. For example, the concolic execution method combines the concrete and symbolic execution methods to reduce the complexity of pure symbolic execution and increase the program coverage. As another example, static taint analysis is used with the constraint analysis method to limit the overhead of program analysis and compute the constraints only on the tainted data \hyperref[b51]{[51]}. Also, the control and data flow of the program are extracted in \hyperref[b121]{[122]},  {\ref [62]} and \hyperref[b63]{[63]} to model the program automatically and detect vulnerabilities by performing the model checking. There are more possible combinations that are not applied yet and might be effective in detecting the vulnerabilities more accurately. For example, the annotation can be used in model checking to profit the programmers' knowledge for modeling the program.\par
Also, most of the vulnerability removal and vulnerability tolerance methods consider a specific vulnerability class based on their own definition of the relevant software vulnerability. Therefore, an imprecise definition of the intended vulnerability would cause inaccurate results in the proposed method. In addition, some methods only consider a limited number of vulnerability classes. To handle new vulnerability classes, the algorithm of these methods has to be changed. Many of the presented methods or tools are not able to detect all of the vulnerability classes \hyperref[b122]{[123]}, \hyperref[b123]{[124]}. By now, the researchers' focus was mainly on designing more accurate methods.\par
A new research trend is making the vulnerability detection methods extendable. In this way, an accurate method for detecting a specific vulnerability can also be used to detect other vulnerabilities. To make a vulnerability detection method extendable, we suggest designing vulnerability detection algorithms that are A New View on Classification of Software Vulnerability Mitigation Methods independent from the sought vulnerability classes. Such algorithms are able to detect any specified vulnerabilities in the program. Designing such methods requires a general model for specifying the vulnerabilities that encompasses any vulnerability classes, even the future ones. Based on this model, various vulnerabilities are specified for the detection algorithms to be detected automatically in the programs.\par
There are a few extendable vulnerability removal methods, such as \hyperref[b124]{[125]}, \hyperref[b125]{[126]} and \hyperref[b123]{[124]}. However, these methods are limited to specific programming languages. Also, some of them are not expressive enough to specify any vulnerability classes. For example, in \hyperref[b126]{[127]} an extendable vulnerability method is presented for detecting the vulnerabilities in web applications that are written in Java. The specification method of \hyperref[b126]{[127]} does not support some data types, e.g. integer, float and character. Therefore, it is not possible to define certain operations, such as mathematical operations or comparing the characters, in specifying a vulnerability. This is not a limitation for specifying vulnerabilities in object-oriented programs, such as Java. Because they encapsulate these operations in certain methods for each data type. It is, however, a limitation for specifying vulnerabilities in other languages, such as C. For example, it is not possible to specify integer overflow vulnerabilities in C programs with this method.\par
The vulnerability forecasting methods predict the number of left vulnerabilities in the software and determine when the software is ready to be released. They are also used to estimate the required efforts for the future maintenance. Some vulnerability forecasting methods use the vulnerability detection models to predict the rate of vulnerability detection during the lifecycle of the software. The first vulnerability detection models were in fact software reliability growth models that were applied for predicting the vulnerability detection rate. The next models were designed especially for the vulnerability detection rate. These models consider effective parameters on the detection of vulnerabilities, such as time and the number of installations. Since these models do not consider characteristics of the software in their predictions, they need a history of the detected vulnerabilities to predict the vulnerability detection rate in the future. These models are not accurate especially at the early stages in the lifecycle of programs. New vulnerability detection models consider the characteristics of the software to achieve more accurate predictions. In this paper, we reviewed a vulnerability detection model that is based on two characteristics of the program: cyclomatic complexity of the source code and the level of compliance with secure coding practices. There are, however, other characteristics that affect on the rate of vulnerability detection, such as software support, version of the program, availability of the source code or usage of third-party components. For example, the rate of vulnerability detection decreases in time for a program with effective support that periodically presents patches and resolves problems in the program. Also, it might be more difficult to detect vulnerabilities in the higher versions of a program than in its lower versions. The future models can use other characteristics of software to model the vulnerability prediction rate more accurately. Also, they can combine software characteristics with the effective environmental factors, such as time and number of installations, to generate more accurate models.\par
The possibility of analyzing the program and the program analysis method become important when the vulnerability detection models consider the characteristics of software. For example, a model may be based on some characteristics in the source code of the program. Thus, it is not possible to use such model when the source code of the program is not available. Also, vulnerability forecasts based on inaccurate software analysis are not reliable. In the future, static and dynamic analysis methods that are proposed for detecting the vulnerabilities can be used to better analyze the current characteristics of a program and predict the future rate of vulnerability detection accurately. \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-2.png}
\caption{\label{fig_0}A}\end{figure}
      \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{P{0.034379358437935846\textwidth}P{0.38824965132496514\textwidth}P{0.23057880055788005\textwidth}P{0.02608089260808926\textwidth}P{0.1707112970711297\textwidth}}
Reviewed Paper\tabcellsep Active vulnerability detection\tabcellsep \multicolumn{2}{l}{Active vulnerability handling Vulnerability handling}\tabcellsep Vulnerability\\
{}[23]\tabcellsep Detect unauthorized changes of return addresses. (preemp-tive)\tabcellsep Halts or restarts the program. (rollback)\tabcellsep None\tabcellsep Buffer overflow\\
{}[24]\tabcellsep Detect unauthorized changes of return addresses. (preemp-\tabcellsep Halts the program.\tabcellsep None\tabcellsep Buffer overflow\\
\tabcellsep tive)\tabcellsep \tabcellsep \tabcellsep \\
{}[25]\tabcellsep Detect unauthorized changes of return addresses. (preemp-\tabcellsep Halts the program.\tabcellsep None\tabcellsep Buffer overflow\\
\tabcellsep tive)\tabcellsep \tabcellsep \tabcellsep \\
\tabcellsep \tabcellsep \tabcellsep \tabcellsep Any vulnerability\\
{}[26]\tabcellsep Monitor the flow of un-trusted data. (preemptive)\tabcellsep Invokes exception handlers. (roll-forward)\tabcellsep None\tabcellsep that is exploitable by malicious input\\
\tabcellsep \tabcellsep \tabcellsep \tabcellsep data.\\
\tabcellsep \tabcellsep \tabcellsep \tabcellsep Any vulnerability\\
{}[27]\tabcellsep Monitor the flow of un-trusted data. (preemptive)\tabcellsep Halts the program.\tabcellsep None\tabcellsep that is exploitable by malicious input\\
\tabcellsep \tabcellsep \tabcellsep \tabcellsep data.\\
{}[30]\tabcellsep Monitor the argument of SQL-related functions. (preemptive)\tabcellsep Ignores the request. (roll-forward)\tabcellsep None\tabcellsep SQL injection\\
{}[31]\tabcellsep Monitor the argument of SQL-related functions. (preemptive)\tabcellsep Ignores the request. (roll-forward)\tabcellsep None\tabcellsep SQL injection\\
\tabcellsep Monitor the format argument\tabcellsep \tabcellsep \tabcellsep \\
{}[32]\tabcellsep of printing functions. (pre-\tabcellsep Halts the program.\tabcellsep None\tabcellsep Format string\\
\tabcellsep emptive)\tabcellsep \tabcellsep \tabcellsep \\
{}[28]\tabcellsep Monitor the flow of un-trusted data. (preemptive)\tabcellsep Invokes exception handlers. (roll-forward)\tabcellsep None\tabcellsep SQL injection Buffer overflow Format string\\
{}[36]\tabcellsep Detect unauthorized changes of return addresses. (preemp-tive)\tabcellsep Recovers the stack. (compen-sation)\tabcellsep None\tabcellsep Buffer overflow\\
{}[29]\tabcellsep Monitor the flow of un-trusted data. (preemptive)\tabcellsep Ignores the request. (roll-forward)\tabcellsep None\tabcellsep DOM-based XSS\end{longtable} \par
 
\caption{\label{tab_0}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{1} \par 
\begin{longtable}{P{0.85\textwidth}}
Year 2017\\
46\\
)\\
( C\end{longtable} \par
 
\caption{\label{tab_1}Table 1 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{P{0.1626543209876543\textwidth}P{0.5299382716049382\textwidth}P{0.05246913580246913\textwidth}P{0.06296296296296296\textwidth}P{0.0419753086419753\textwidth}}
Analysis Method\tabcellsep Description\tabcellsep Advantages\tabcellsep shortcomings\tabcellsep Examples\\
Pattern Matching\tabcellsep Considers the program as a text file and searches for vul-\tabcellsep \tabcellsep \tabcellsep \\
\tabcellsep nerability patterns in the text.\tabcellsep \tabcellsep \tabcellsep \end{longtable} \par
 
\caption{\label{tab_2}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{2} \par 
\begin{longtable}{}
\end{longtable} \par
 
\caption{\label{tab_3}Table 2 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{P{0.046788990825688076\textwidth}P{0.25110091743119267\textwidth}P{0.26045871559633027\textwidth}P{0.2791743119266055\textwidth}P{0.012477064220183487\textwidth}}
Analysis Method\tabcellsep Description\tabcellsep Advantages\tabcellsep shortcomings\tabcellsep Examples\\
Fault injection\tabcellsep Faults are generated semi-randomly. (random corrup-tion) Fault injection is based on some previous analysis of the program. (intelligent corrup-tion )\tabcellsep Simplicity and independence in random corruption of in-puts. (random corruption) More reliable code coverage, less false negatives. (intelli-gent corruption)\tabcellsep Cannot detect logic vulner-ability. Less reliable code coverage. (random corrup-tion) More effort is required for testing each single program. (intelligent corruption)\tabcellsep \end{longtable} \par
 
\caption{\label{tab_4}}\end{figure}
 			\footnote{© 2017 Global Journals Inc. (US)} 			\footnote{Commercial off-the-shelf} 		 		\backmatter  			  				\begin{bibitemlist}{1}
\bibitem[Wheeler ()]{b44}\label{b44} 	 		\textit{},  		 			D A Wheeler 		,  		 			Flawfinder 		.  		 \url{http://www.dwheeler.com/flawfinder}  		2001.  	 	 (Online; accessed 2016-10-23) 
\bibitem[Lekies et al. ()]{b94}\label{b94} 	 		‘25 million flows later: large-scale detection of dom-based xss’.  		 			S Lekies 		,  		 			B Stock 		,  		 			M Johns 		.  	 	 		\textit{Proceedings of the 2013 ACM SIGSAC conference on Computer \& communications security},  				 (the 2013 ACM SIGSAC conference on Computer \& communications security)  		2013. ACM. p. .  	 
\bibitem[Bishop and Bailey ()]{b6}\label{b6} 	 		\textit{A critical analysis of vulnerability taxonomies},  		 			M Bishop 		,  		 			D Bailey 		.  		 CSE-96-11.  		1996.  		 			Department of Computer Science, University of California at Davis. 		 	 	 (Technical Report) 
\bibitem[V Ganesh and Dill ()]{b100}\label{b100} 	 		‘A decision procedure for bitvectors and arrays’.  		 			D L V Ganesh 		,  		 			Dill 		.  	 	 		\textit{Computer Aided Verification},  				2007. Springer. p. .  	 
\bibitem[Wagner et al. ()]{b50}\label{b50} 	 		\textit{A first step towards automated detection of buffer overrun vulnerabilities},  		 			D Wagner 		,  		 			J S Foster 		,  		 			E A Brewer 		,  		 			A Aiken 		.  		2000. NDSS. p. .  	 
\bibitem[Shahriari et al.]{b8}\label{b8} 	 		\textit{A general framework for categorizing vulnerabilities regarding their impact on security policy},  		 			H R Shahriari 		,  		 			R Jalili 		,  		 			M Bishop 		.  		Computers and Security.  	 
\bibitem[Monga et al. ()]{b108}\label{b108} 	 		‘A hybrid analysis framework for detecting web application vulnerabilities’.  		 			M Monga 		,  		 			R Paleari 		,  		 			E Passerini 		.  	 	 		\textit{Proceedings of the 2009 ICSE Workshop on Software Engineering for Secure Systems},  				 (the 2009 ICSE Workshop on Software Engineering for Secure Systems)  		2009. IEEE Computer Society. p. .  	 
\bibitem[Musa and Okumoto ()]{b139}\label{b139} 	 		‘A logarithmic poisson execution time model for software reliability measurement’.  		 			J D Musa 		,  		 			K Okumoto 		.  	 	 		\textit{Proceedings of the 7 th i nternational conference on Software engineering},  				 (the 7 th i nternational conference on Software engineering)  		1984. IEEE Press. p. .  	 
\bibitem[Burrows et al. ()]{b129}\label{b129} 	 		‘A logic of authentication’.  		 			M Burrows 		,  		 			M Abadi 		,  		 			R M Needham 		.  	 	 		\textit{Proceedings of the Royal Society of London A: Mathematical, Physical and Engineering Sciences}  		1989. The Royal Society. 426 p. .  	 
\bibitem[Ren et al. ()]{b66}\label{b66} 	 		‘A method for detecting software vulnerabilities based on clustering and model analyzing’.  		 			J Ren 		,  		 			B Cai 		,  		 			H He 		,  		 			C Hu 		.  	 	 		\textit{Journal of Computational Information Systems}  		2011. 7  (4)  p. .  	 
\bibitem[Manmadhan and Manesh ()]{b30}\label{b30} 	 		‘A method of detecting sql injection attack to secure web applications’.  		 			S Manmadhan 		,  		 			T Manesh 		.  	 	 		\textit{International Journal of Distributed and Parallel Systems}  		2012. 3  (6)  p. 1.  	 
\bibitem[Clarke ()]{b98}\label{b98} 	 		‘A program testing system’.  		 			L A Clarke 		.  	 	 		\textit{Proceedings of the 1976 annual conference},  				 (the 1976 annual conference)  		1976. ACM. p. .  	 
\bibitem[Seacord and Householder]{b10}\label{b10} 	 		\textit{A structured approach to classifying security vulnerabilities},  		 			R C Seacord 		,  		 			A D Householder 		.  		 CMU/SEI-2005-TN-003.  		 	 	 (Technical report) 
\bibitem[Pistoia et al. ()]{b3}\label{b3} 	 		‘A survey of static analysis methods for identifying security vulnerabilities in software systems’.  		 			M Pistoia 		,  		 			S Chandra 		,  		 			S J Fink 		,  		 			E Yahav 		.  	 	 		\textit{IBM Systems Journal}  		2007. 46  (2)  p. .  	 
\bibitem[A Takanen et al. ()]{b74}\label{b74} 	 		 			J D A Takanen 		,  		 			C Demott 		,  		 			Miller 		.  		\textit{Fuzzing for software security testing and quality assurance},  				2008. Artech House.  	 
\bibitem[Tsuruoka et al. ()]{b56}\label{b56} 	 		‘Accelerating the annotation of sparse named entities by dynamic sentence selection’.  		 			Y Tsuruoka 		,  		 			J Tsujii 		,  		 			S Ananiadou 		.  	 	 		\textit{BMC bioinformatics}  		2008. 9  (11)  p. S8.  	 	 (Suppl) 
\bibitem[Tan et al. ()]{b58}\label{b58} 	 		‘acomment: mining annotations from comments and code to detect interrupt related concurrency bugs’.  		 			L Tan 		,  		 			Y Zhou 		,  		 			Y Padioleau 		.  	 	 		\textit{Proceedings of the 33rd international conference on software engineering},  				 (the 33rd international conference on software engineering)  		2011. ACM. p. .  	 
\bibitem[Alhazmi and Malaiya ()]{b112}\label{b112} 	 		 			O H Alhazmi 		,  		 			Y K Malaiya 		.  		\textit{Proceedings of annual reliability and maintainability symposium},  				 (annual reliability and maintainability symposium)  		2005. p. .  	 	 (Quantitative vulnerability assessment of systems software) 
\bibitem[Alhazmi et al. ()]{b113}\label{b113} 	 		 			O Alhazmi 		,  		 			Y Malaiya 		,  		 			I Ray 		.  		\textit{Security vulnerabilities in software systems: A quantitative perspective},  				2005. Springer. p. .  	 	 (Data and Applications Security XIX) 
\bibitem[Schwartz et al. ()]{b93}\label{b93} 	 		‘All you ever wanted to know about dynamic taint analysis and forward symbolic execution (but might have been afraid to ask’.  		 			E J Schwartz 		,  		 			T Avgerinos 		,  		 			D Brumley 		.  	 	 		\textit{Proceeding of the 2010 IEEE Symposium on Security and Privacy (SP)},  				 (eeding of the 2010 IEEE Symposium on Security and Privacy (SP))  		2010. IEEE. p. .  	 
\bibitem[Shahmehri et al. ()]{b22}\label{b22} 	 		‘An advanced approach for modeling and detecting software vulnerabilities’.  		 			N Shahmehri 		,  		 			A Mammar 		,  		 			E Montes De Oca 		,  		 			D Byers 		,  		 			A Cavalli 		,  		 			S Ardi 		,  		 			W Jimenez 		.  	 	 		\textit{Information and Software Technology}  		2012. 54  (9)  p. .  	 
\bibitem[Iha and Doi ()]{b35}\label{b35} 	 		‘An implementation of the binding mechanism in the web browser for preventing xss attacks: introducing the bind-value headers’.  		 			G Iha 		,  		 			H Doi 		.  	 	 		\textit{Availability, Reliability and Security, 2009. ARES'09. International Conference on},  				2009. IEEE. p. .  	 
\bibitem[Anderson ()]{b134}\label{b134} 	 		 			P Anderson 		.  	 	 		\textit{Codesurfer/path inspector, Proceeding of the 20th IEEE International Conference on Software Maintenance},  				2004. 2004.  	 
\bibitem[Alhazmi and Malaiya ()]{b115}\label{b115} 	 		‘Application of vulnerability discovery models to major operating A New View on Classification of Software Vulnerability Mitigation Methods systems, Reliability’.  		 			O H Alhazmi 		,  		 			Y K Malaiya 		.  	 	 		\textit{IEEE Transactions on}  		2008. 57  (1)  p. .  	 
\bibitem[Application Security Verification Standard (ASVS)]{b117}\label{b117} 	 		 \url{https://www.owasp.org/images/5/58/OWASP\textunderscore ASVS\textunderscore Version\textunderscore 2.pdf}  		\textit{Application Security Verification Standard (ASVS)},  				 	 	 (Online; accessed 2016-10-8) 
\bibitem[Kim et al. ()]{b48}\label{b48} 	 		‘Applying dataflow analysis to detecting software vulnerability’.  		 			H Kim 		,  		 			T.-H Choi 		,  		 			S.-C Jung 		,  		 			H.-C Kim 		,  		 			O Lee 		,  		 			K.-G Doh 		.  	 	 		\textit{Proceeding of the 10th International Conference on Advanced Communication Technology. ICACT},  				 (eeding of the 10th International Conference on Advanced Communication Technology. ICACT)  		2008. 2008. IEEE. 1 p. .  	 
\bibitem[Wang et al. ()]{b71}\label{b71} 	 		‘Automated detection of code vulnerabilities based on program analysis and model checking’.  		 			L Wang 		,  		 			Q Zhang 		,  		 			P Zhao 		.  	 	 		\textit{Proceeding of the Eighth IEEE International Working Conference on Source Code Analysis and Manipulation},  				 (eeding of the Eighth IEEE International Working Conference on Source Code Analysis and Manipulation)  		2008. IEEE. p. .  	 
\bibitem[Sparks et al. ()]{b83}\label{b83} 	 		‘Automated vulnerability analysis: Leveraging control flow for evolutionary input crafting’.  		 			S Sparks 		,  		 			S Embleton 		,  		 			R Cunningham 		,  		 			C Zou 		.  	 	 		\textit{Proceeding of Twenty-Third Annual Computer Security Applications Conference. ACSAC},  				 (eeding of Twenty-Third Annual Computer Security Applications Conference. ACSAC)  		2007. 2007. IEEE. p. .  	 
\bibitem[Godefroid et al. ()]{b79}\label{b79} 	 		‘Automated whitebox fuzz testing’.  		 			P Godefroid 		,  		 			M Y Levin 		,  		 			D A Molnar 		.  	 	 		\textit{NDSS}  		2008. 8 p. .  	 
\bibitem[Xu et al. ()]{b42}\label{b42} 	 		‘Automatic diagnosis and response to memory corruption vulnerabilities’.  		 			J Xu 		,  		 			P Ning 		,  		 			C Kil 		,  		 			Y Zhai 		,  		 			C Bookholt 		.  	 	 		\textit{Proceedings of the 12th ACM conference on Computer and communications security},  				 (the 12th ACM conference on Computer and communications security)  		2005. ACM. p. .  	 
\bibitem[Zhang and Yin ()]{b37}\label{b37} 	 		‘Automatic generation of vulnerability specific patches for preventing component hijacking attacks in android applications’.  		 			M Zhang 		,  		 			H Yin 		,  		 			Appsealer 		.  	 	 		\textit{Proceedings of the 21th Annual Network and Distributed System Security Symposium (NDSS 2014)},  				 (the 21th Annual Network and Distributed System Security Symposium (NDSS 2014))  		2014.  	 
\bibitem[Smirnov and Chiueh ()]{b40}\label{b40} 	 		‘Automatic patch generation for buffer overflow attacks, in: Information Assurance and Security’.  		 			A Smirnov 		,  		 			T Chiueh 		.  	 	 		\textit{IAS 2007. Third International Symposium on},  				2007. 2007. IEEE. p. .  	 
\bibitem[Liang et al.]{b41}\label{b41} 	 		\textit{Automatic synthesis of filters to discard buffer overflow attacks: A step towards realizing self-healing systems},  		 			Z Liang 		,  		 			R Sekar 		,  		 			D C Duvarney 		.  		 	 
\bibitem[Avizienis et al. ()]{b12}\label{b12} 	 		‘Basic concepts and taxonomy of dependable and secure computing, Dependable and Secure Computing’.  		 			J.-C Avizienis 		,  		 			B Laprie 		,  		 			C Randell 		,  		 			Landwehr 		.  	 	 		\textit{IEEE Transactions on}  		2004. 1  (1)  p. .  	 
\bibitem[Bisbey and Hollingworth ()]{b133}\label{b133} 	 		 			R Bisbey 		,  		 			D Hollingworth 		.  		\textit{Protection analysis: Final report},  				1978.  	 
\bibitem[Bishop ()]{b5}\label{b5} 	 		 			M Bishop 		.  		 CSE-95- 10.  		\textit{A taxonomy of unix system and network vulnerabilities},  				1995.  		 			Department of Computer Science, University of California at Davis 		 	 	 (Technical Report) 
\bibitem[Dwyer and Hatcliff ()]{b91}\label{b91} 	 		‘Bogor: an extensible and highly-modular software model checking framework’.  		 			M B Dwyer 		,  		 			J Hatcliff 		.  	 	 		\textit{ACM SIGSOFT Software Engineering Notes}  		2003. ACM. 28 p. .  	 
\bibitem[V Ganapathy et al. ()]{b51}\label{b51} 	 		‘Buffer overrun detection using linear programming and static analysis’.  		 			, S V Ganapathy 		,  		 			D Jha 		,  		 			D Chandler 		,  		 			D Melski 		,  		 			Vitek 		.  	 	 		\textit{Proceedings of the 10th ACM conference on Computer and communications security},  				 (the 10th ACM conference on Computer and communications security)  		2003. ACM. p. .  	 
\bibitem[Carnegie-mellon univ pittsburgh pa software engineering inst ()]{b11}\label{b11} 	 		\textit{Carnegie-mellon univ pittsburgh pa software engineering inst},  		2005.  	 
\bibitem[Musuvathi et al. ()]{b90}\label{b90} 	 		‘Cmc: A pragmatic approach to model checking real code’.  		 			M Musuvathi 		,  		 			D Y Park 		,  		 			A Chou 		,  		 			D R Engler 		,  		 			D L Dill 		.  	 	 		\textit{ACM SIGOPS Operating Systems Review}  		2002. 36  (SI)  p. .  	 
\bibitem[Halfond and Orso ()]{b109}\label{b109} 	 		‘Combining static analysis and runtime monitoring to counter sql-injection attacks’.  		 			W G Halfond 		,  		 			A Orso 		.  	 	 		\textit{ACM SIGSOFT Software Engineering Notes}  		2005. ACM. 30 p. .  	 
\bibitem[Bishop ()]{b7}\label{b7} 	 		\textit{Computer security: art and science},  		 			M Bishop 		.  		2002. Addison-Wesley.  	 
\bibitem[Kc et al. ()]{b34}\label{b34} 	 		‘Countering code-injection attacks with instruction-set randomization’.  		 			G S Kc 		,  		 			A D Keromytis 		,  		 			V Prevelakis 		.  	 	 		\textit{Proceedings of the 10 th ACM conference on Computer and communications security},  				 (the 10 th ACM conference on Computer and communications security)  		2003. ACM. p. .  	 
\bibitem[Dalton et al. ()]{b26}\label{b26} 	 		 			M Dalton 		,  		 			H Kannan 		,  		 			C Kozyrakis 		.  	 	 		\textit{Raksha: a flexible information flow architecture for software security},  				2007. ACM. 35 p. .  	 
\bibitem[Godefroid et al. ()]{b92}\label{b92} 	 		‘Dart: directed automated random testing’.  		 			P Godefroid 		,  		 			N Klarlund 		,  		 			K Sen 		.  	 	 		\textit{ACM Sigplan Notices}  		2005. ACM. 40 p. .  	 
\bibitem[Shankar et al. ()]{b127}\label{b127} 	 		‘Detecting format string vulnerabilities with type qualifiers’.  		 			U Shankar 		,  		 			K Talwar 		,  		 			J S Foster 		,  		 			D Wagner 		.  	 	 		\textit{USENIX Security Symposium},  				2001. p. .  	 
\bibitem[Xia et al. ()]{b52}\label{b52} 	 		‘Detecting memory access errors with flow-sensitive conditional range analysis’.  		 			Y Xia 		,  		 			J Luo 		,  		 			M Zhang 		.  	 	 		\textit{Embedded Software and Systems},  				2005. Springer. p. .  	 
\bibitem[Wang et al. ()]{b39}\label{b39} 	 		‘Diagnosis and emergency patch generation for integer overflow exploits’.  		 			T Wang 		,  		 			C Song 		,  		 			W Lee 		.  	 	 		\textit{Detection of Intrusions and Malware, and Vulnerability Assessment},  				2014. Springer. p. .  	 
\bibitem[Haller et al. ()]{b81}\label{b81} 	 		‘Dowsing for overflows: A guided fuzzer to find buffer boundary violations’.  		 			A Haller 		,  		 			M Slowinska 		,  		 			H Neugschwandtner 		,  		 			Bos 		.  	 	 		\textit{Usenix Security},  				2013. p. .  	 
\bibitem[Kang et al. ()]{b95}\label{b95} 	 		\textit{Dta++: Dynamictaint analysis with targeted controlflow propagation},  		 			M G Kang 		,  		 			S Mccamant 		,  		 			P Poosankam 		,  		 			D Song 		.  		2011. NDSS.  	 
\bibitem[Gupta et al. ()]{b36}\label{b36} 	 		‘Dynamic code instrumentation to detect and recover from return address corruption’.  		 			S Gupta 		,  		 			P Pratap 		,  		 			H Saran 		,  		 			S Arun-Kumar 		.  	 	 		\textit{A New View on Classification of Software Vulnerability Mitigation Methods 36},  				2006. ACM. p. .  	 	 (Proceedings of the 2006 international workshop on Dynamic systems analysis) 
\bibitem[Newsome and Song ()]{b69}\label{b69} 	 		‘Dynamic taint analysis for automatic detection, analysis, and signature generation of exploits on commodity software’.  		 			J Newsome 		,  		 			D Song 		.  	 	 		\textit{Proceedings of the 12th Network and Distributed System Security Symposium (NDSS05)},  				 (the 12th Network and Distributed System Security Symposium (NDSS05))  		2005.  	 
\bibitem[Sen et al. ()]{b106}\label{b106} 	 		‘Dynamic test generation to find integer bugs in x86 binary linux programs’.  		 			K Sen 		,  		 			D Marinov 		,  		 			G Agha 		,  		 			; D Molnar 		,  		 			X C Li 		,  		 			D A Wagner 		.  	 	 		\textit{Proceedings of the 18 th conference on USENIX security symposium},  				 (the 18 th conference on USENIX security symposium)  		2005. 2009. ACM. 30 p. .  	 	 (CUTE: a concolic unit testing engine for C) 
\bibitem[Clause et al. ()]{b28}\label{b28} 	 		‘Dytan: a generic dynamic taint analysis framework’.  		 			J Clause 		,  		 			W Li 		,  		 			A Orso 		.  	 	 		\textit{Proceedings of the 2007 international symposium on Software testing and analysis},  				 (the 2007 international symposium on Software testing and analysis)  		2007. ACM. p. .  	 
\bibitem[Esparza et al. ()]{b65}\label{b65} 	 		‘Efficient algorithms for model checking pushdown systems’.  		 			J Esparza 		,  		 			D Hansel 		,  		 			P Rossmanith 		,  		 			S Schwoon 		.  	 	 		\textit{Computer Aided Verification},  				2000. Springer. p. .  	 
\bibitem[Doup´e et al. ()]{b77}\label{b77} 	 		‘Enemy of the state: A state-aware black-box web vulnerability scanner’.  		 			L Doup´e 		,  		 			C Cavedon 		,  		 			G Kruegel 		,  		 			Vigna 		.  	 	 		\textit{USENIX Security Symposium},  				2012. p. .  	 
\bibitem[Szekeres et al. ()]{b120}\label{b120} 	 		‘Eternal war in memory’.  		 			L Szekeres 		,  		 			M Payer 		,  		 			T Wei 		,  		 			D Song 		.  	 	 		\textit{IEEE Symposium on Security and Privacy},  				2013.  	 
\bibitem[Cadar et al. ()]{b80}\label{b80} 	 		‘Exe: automatically generating inputs of death’.  		 			C Cadar 		,  		 			V Ganesh 		,  		 			P M Pawlowski 		,  		 			D L Dill 		,  		 			D R Engler 		.  	 	 		\textit{ACM Transactions on Information and System Security}  		2008. 12  (2)  p. 10.  	 	 (TISSEC)) 
\bibitem[Groce and Joshi ()]{b86}\label{b86} 	 		‘Extending model checking with dynamic analysis’.  		 			R Groce 		,  		 			Joshi 		.  	 	 		\textit{Verification, Model Checking, and Abstract Interpretation},  				2008. Springer. p. .  	 
\bibitem[Hooimeijer et al. ()]{b70}\label{b70} 	 		‘Fast and precise sanitizer analysis with bek’.  		 			P Hooimeijer 		,  		 			B Livshits 		,  		 			D Molnar 		,  		 			P Saxena 		,  		 			M Veanes 		.  	 	 		\textit{Proceedings of the 20 th USENIX conference on Security, USENIX Association},  				 (the 20 th USENIX conference on Security, USENIX Association)  		2011. p. .  	 
\bibitem[Davidson et al. ()]{b99}\label{b99} 	 		‘Fie on firmware: Finding vulnerabilities in embedded systems using symbolic execution’.  		 			D Davidson 		,  		 			B Moench 		,  		 			T Ristenpart 		,  		 			S Jha 		.  	 	 		\textit{USENIX Security},  				2013. p. .  	 
\bibitem[Livshits and Lam ()]{b67}\label{b67} 	 		‘Finding security vulnerabilities in java applications with static analysis’.  		 			B Livshits 		,  		 			M S Lam 		.  	 	 		\textit{Proceedings of the 14th conference on USENIX Security Symposium},  				 (the 14th conference on USENIX Security Symposium)  		2005. 14.  	 
\bibitem[Cowan et al. ()]{b32}\label{b32} 	 		‘Formatguard: Automatic protection from printf format string vulnerabilities’.  		 			C Cowan 		,  		 			M Barringer 		,  		 			S Beattie 		,  		 			G Kroah-Hartman 		,  		 			M Frantzen 		,  		 			J Lokier 		.  	 	 		\textit{USENIX Security Symposium},  				 (Washington, DC)  		2001. 91.  	 
\bibitem[Yamaguchi et al. ()]{b47}\label{b47} 	 		‘Generalized vulnerability extrapolation using abstract syntax trees’.  		 			F Yamaguchi 		,  		 			M Lottmann 		,  		 			K Rieck 		.  	 	 		\textit{Proceedings of the 28 th Annual Computer Security Applications Conference},  				 (the 28 th Annual Computer Security Applications Conference)  		2012. ACM. p. .  	 
\bibitem[Kiezun et al. ()]{b102}\label{b102} 	 		‘Hampi: a solver for string constraints’.  		 			V Kiezun 		,  		 			P J Ganesh 		,  		 			P Guo 		,  		 			M D Hooimeijer 		,  		 			Ernst 		.  	 	 		\textit{Proceedings of the eighteenth international symposium on Software testing and analysis},  				 (the eighteenth international symposium on Software testing and analysis)  		2009. ACM. p. .  	 
\bibitem[Howard ()]{b15}\label{b15} 	 		\textit{How do they do it? a look inside the security development lifecycle at microsoft, MSDN Magazine},  		 			M Howard 		.  		2005. p. .  	 
\bibitem[Howard (2006)]{b57}\label{b57} 	 		 			M Howard 		.  		 2016-10-22.  		 \url{http://blogs.msdn.com/b/michael\textunderscore howard/archive/}  		\textit{A brief introduction to the standard annotation language (SAL)},  				2006/05/19/602077.aspx. 2006.  	 
\bibitem[Evans and Larochelle ()]{b54}\label{b54} 	 		‘Improving security using extensible lightweight static analysis, software’.  		 			D Evans 		,  		 			D Larochelle 		.  	 	 		\textit{IEEE}  		2002. 19  (1)  p. .  	 
\bibitem[Livshits ()]{b126}\label{b126} 	 		\textit{Improving software security with precise static and runtime analysis},  		 			B Livshits 		.  		2006.  		 			Stanford University 		 	 	 (Ph.D. thesis) 
\bibitem[Rescorla ()]{b138}\label{b138} 	 		‘Is finding security holes a good idea?’.  		 			E Rescorla 		.  	 	 		\textit{Security \& Privacy},  				2005. 3 p. .  	 
\bibitem[Oliveira et al. ()]{b118}\label{b118} 	 		‘It's the psychology stupid: how heuristics explain software vulnerabilities and how priming can illuminate developer's blind spots’.  		 			D Oliveira 		,  		 			M Rosenthal 		,  		 			N Morin 		,  		 			K.-C Yeh 		,  		 			J Cappos 		,  		 			Y Zhuang 		.  	 	 		\textit{Proceedings of the 30th Annual Computer Security Applications Conference},  				 (the 30th Annual Computer Security Applications Conference)  		2014. ACM. p. .  	 
\bibitem[Viega et al. ()]{b45}\label{b45} 	 		‘Its4: A static vulnerability scanner for c and c++ code’.  		 			J Viega 		,  		 			J.-T Bloch 		,  		 			Y Kohno 		,  		 			G Mcgraw 		.  	 	 		\textit{Proceedings of the 16th Annual Computer Security Applications Conference, ACSAC'00},  				 (the 16th Annual Computer Security Applications Conference, ACSAC'00)  		2000. IEEE. p. .  	 
\bibitem[Cadar et al. ()]{b78}\label{b78} 	 		\textit{Klee: Unassisted and automatic generation of high-coverage tests for complex systems programs},  		 			D Cadar 		,  		 			D R Dunbar 		,  		 			Engler 		.  		2008. OSDI. 8 p. .  	 
\bibitem[Wang et al. ()]{b105}\label{b105} 	 		‘Linear obfuscation to combat symbolic execution’.  		 			Z Wang 		,  		 			J Ming 		,  		 			C Jia 		,  		 			D Gao 		.  	 	 		\textit{Computer Security-ESORICS 2011},  				2011. Springer. p. .  	 
\bibitem[Johnson ()]{b46}\label{b46} 	 		\textit{Lint, a C program checker},  		 			S C Johnson 		.  		1977.  		 			Bell Telephone Laboratories 		 	 
\bibitem[Long et al. ()]{b19}\label{b19} 	 		 			F Long 		,  		 			D Mohindra 		,  		 			R C Seacord 		,  		 			D F Sutherland 		,  		 			D Svoboda 		.  		\textit{The CERT Oracle Secure Coding Standard for Java},  				2011. Addison-Wesley Professional.  	 
\bibitem[Mcgraw ()]{b14}\label{b14} 	 		 			G Mcgraw 		.  		\textit{Software security: building security in},  				2006. Addison-Wesley Professional. 1.  	 
\bibitem[Mead and Stehney ()]{b16}\label{b16} 	 		 			N R Mead 		,  		 			T Stehney 		.  		\textit{Security quality requirements engineering (SQUARE) methodology},  				2005. ACM. 30.  	 
\bibitem[Yang et al. ()]{b55}\label{b55} 	 		‘Meca: an extensible, expressive system and language for statically checking security properties’.  		 			J Yang 		,  		 			T Kremenek 		,  		 			Y Xie 		,  		 			D Engler 		.  	 	 		\textit{Proceedings of the 10th ACM conference on Computer and communications security},  				 (the 10th ACM conference on Computer and communications security)  		2003. ACM. p. .  	 
\bibitem[R¨odiger ()]{b62}\label{b62} 	 		‘Merging static analysis and model checking for improved security vulnerability detection’.  	 	 		\textit{A New View on Classification of Software Vulnerability Mitigation Methods USENIX Annual Technical Conference},  				 			. W.-S R¨odiger 		 (ed.)  		2005. 2011. p. .  		 			Dept. of Com. Sc. Augsburg University 		 	 	 (General Track. Ph.D. thesis, Master thesis) 
\bibitem[Shahriar and Zulkernine ()]{b1}\label{b1} 	 		‘Mitigating program security vulnerabilities: Approaches and challenges’.  		 			H Shahriar 		,  		 			M Zulkernine 		.  	 	 		\textit{ACM Computing Surveys (CSUR)}  		2012. 44  (3)  p. 11.  	 
\bibitem[Godefroid ()]{b88}\label{b88} 	 		‘Model checking for programming languages using verisoft’.  		 			P Godefroid 		.  	 	 		\textit{Proceedings of the 24th ACM SIGPLAN-SIGACT symposium on Principles of programming languages},  				 (the 24th ACM SIGPLAN-SIGACT symposium on Principles of programming languages)  		1997. ACM. p. .  	 
\bibitem[Havelund and Pressburger ()]{b89}\label{b89} 	 		‘Model checking java programs using java pathfinder’.  		 			K Havelund 		,  		 			T Pressburger 		.  	 	 		\textit{International A New View on Classification of Software Vulnerability Mitigation Methods Journal on Software Tools for Technology Transfer},  				2000. 2 p. .  	 
\bibitem[Cho et al. ()]{b107}\label{b107} 	 		‘Model-inference-assisted concolic exploration for protocol and vulnerability discovery’.  		 			C Y Cho 		,  		 			D Babic 		,  		 			P Poosankam 		,  		 			K Z Chen 		,  		 			E X Wu 		,  		 			D Song 		,  		 			Mace 		.  	 	 		\textit{USENIX Security Symposium},  				2011. p. .  	 
\bibitem[Hadjidj et al. ()]{b64}\label{b64} 	 		‘Modelchecking for software vulnerabilities detection with multi-language support’.  		 			R Hadjidj 		,  		 			X Yang 		,  		 			S Tlili 		,  		 			M Debbabi 		.  	 	 		\textit{Proceeding of the sixth Annual Conference on Privacy, Security and Trust, PST'08},  				 (eeding of the sixth Annual Conference on Privacy, Security and Trust, PST'08)  		2008. IEEE. p. .  	 
\bibitem[Yamaguchi et al. ()]{b124}\label{b124} 	 		‘Modeling and discovering vulnerabilities with code property graphs’.  		 			F Yamaguchi 		,  		 			N Golde 		,  		 			D Arp 		,  		 			K Rieck 		.  	 	 		\textit{Proceedings of 2014 IEEE Symposium on Security and Privacy (SP)},  				 (2014 IEEE Symposium on Security and Privacy (SP))  		2014. IEEE. p. .  	 
\bibitem[Chen and Wagner ()]{b63}\label{b63} 	 		‘Mops: an infrastructure for examining security properties of software’.  		 			H Chen 		,  		 			D Wagner 		.  	 	 		\textit{Proceedings of the 9th ACM conference on Computer and communications security},  				 (the 9th ACM conference on Computer and communications security)  		2002. ACM. p. .  	 
\bibitem[Balzarotti et al. ()]{b121}\label{b121} 	 		‘Multi-module vulnerability analysis of web-based applications’.  		 			D Balzarotti 		,  		 			M Cova 		,  		 			V V Felmetsger 		,  		 			G Vigna 		.  	 	 		\textit{Proceedings of the 14th ACM conference on Computer and communications security},  				 (the 14th ACM conference on Computer and communications security)  		2007. ACM. p. .  	 
\bibitem[Salamat et al. ()]{b33}\label{b33} 	 		‘Multi-variant program execution: Using multi-core systems to defuse buffer-overflow vulnerabilities’.  		 			B Salamat 		,  		 			A Gal 		,  		 			T Jackson 		,  		 			K Manivannan 		,  		 			G Wagner 		,  		 			M Franz 		.  	 	 		\textit{proceedings of International Conference on Complex, Intelligent and Software Intensive Systems. CISIS 2008},  				 (International Conference on Complex, Intelligent and Software Intensive Systems. CISIS 2008)  		2008. IEEE. p. .  	 
\bibitem[Shahriar and Zulkernine ()]{b85}\label{b85} 	 		‘Music: Mutation-based sql injection vulnerability checking’.  		 			H Shahriar 		,  		 			M Zulkernine 		.  	 	 		\textit{Proceeding of the Eighth International Conference on Quality Software. QSIC'08},  				 (eeding of the Eighth International Conference on Quality Software. QSIC'08)  		2008. IEEE. p. .  	 
\bibitem[Nipkow et al. ()]{b130}\label{b130} 	 		 			T Nipkow 		,  		 			L C Paulson 		,  		 			M Wenzel 		.  		\textit{Isabelle/HOL: a proof assistant for higher-order logic},  				2002. Springer Science \& Business Media. 2283.  	 
\bibitem[Sarwar et al. ()]{b97}\label{b97} 	 		‘On the effectiveness of dynamic taint analysis for protecting against private information leaks on android-based devices’.  		 			G Sarwar 		,  		 			O Mehani 		,  		 			R Boreli 		,  		 			D Kaafar 		.  	 	 		\textit{Proceeding of the 10th International Conference on Security and Cryptography (SECRYPT)},  				 (eeding of the 10th International Conference on Security and Cryptography (SECRYPT))  		2013.  	 
\bibitem[Jovanovic et al. ()]{b49}\label{b49} 	 		‘Pixy: A static analysis tool for detecting web application vulnerabilities’.  		 			N Jovanovic 		,  		 			C Kruegel 		,  		 			E Kirda 		.  	 	 		\textit{Proceeding of the 2006 IEEE Symposium on Security and Privacy},  				 (eeding of the 2006 IEEE Symposium on Security and Privacy)  		2006. IEEE. p. 6.  	 
\bibitem[Chaki and Hissam ()]{b61}\label{b61} 	 		\textit{Precise buffer overflow detection via model checking},  		 			S Chaki 		,  		 			S Hissam 		.  		2005.  	 
\bibitem[Stock et al. ()]{b29}\label{b29} 	 		‘Precise clientside protection against dom-based cross-site scripting’.  		 			B Stock 		,  		 			S Lekies 		,  		 			T Mueller 		,  		 			P Spiegel 		,  		 			M Johns 		.  	 	 		\textit{Proceedings of the 23rd USENIX security symposium},  				 (the 23rd USENIX security symposium)  		2014. p. .  	 
\bibitem[Ringenburg and Grossman ()]{b13}\label{b13} 	 		‘Preventing formatstring attacks via automatic and efficient dynamic checking’.  		 			M F Ringenburg 		,  		 			D Grossman 		.  	 	 		\textit{Proceedings of the 12 th ACM conference on Computer and communications security},  				 (the 12 th ACM conference on Computer and communications security)  		2005. ACM. p. .  	 
\bibitem[Paulson ()]{b128}\label{b128} 	 		‘Proving properties of security protocols by induction’.  		 			L C Paulson 		.  	 	 		\textit{Proceedings of the 10th workshop on Computer Security Foundations},  				 (the 10th workshop on Computer Security Foundations)  		1997. IEEE. p. .  	 
\bibitem[Chiueh and Hsu ()]{b24}\label{b24} 	 		‘Rad: A compile-time solution to buffer overflow attacks’.  		 			T Chiueh 		,  		 			F.-H Hsu 		.  	 	 		\textit{Proceeding of the 21st International Conference on Distributed Computing Systems},  				 (eeding of the 21st International Conference on Distributed Computing Systems)  		2001. 2001. IEEE. p. .  	 
\bibitem[Rawat et al.]{b136}\label{b136} 	 		 			S Rawat 		,  		 			D Ceara 		,  		 			L Mounier 		,  		 			M.-L Potet 		.  		 arXiv:1305.3883.  		\textit{Combining static and dynamic analysis for vulnerability detection},  				 	 	 (arXiv preprint) 
\bibitem[Demott et al.]{b84}\label{b84} 	 		\textit{Revolutionizing the field of greybox attack surface testing with evolutionary fuzzing},  		 			J Demott 		,  		 			R Enbody 		,  		 			W F Punch 		.  		 	 	 (BlackHat and Defcon) 
\bibitem[Trinh et al. ()]{b103}\label{b103} 	 		‘S3: A symbolic string solver for vulnerability detection in web applications’.  		 			M.-T Trinh 		,  		 			D.-H Chu 		,  		 			J Jaffar 		.  	 	 		\textit{Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security},  				 (the 2014 ACM SIGSAC Conference on Computer and Communications Security)  		2014. ACM. p. .  	 
\bibitem[Balzarotti et al. ()]{b96}\label{b96} 	 		‘Saner: Composing static and dynamic analysis to validate sanitization in web applications’.  		 			D Balzarotti 		,  		 			M Cova 		,  		 			V Felmetsger 		,  		 			N Jovanovic 		,  		 			E Kirda 		,  		 			C Kruegel 		,  		 			G Vigna 		.  	 	 		\textit{Proceeding of IEEE Symposium on Security and Privacy},  				 (eeding of IEEE Symposium on Security and Privacy)  		2008. 2008. IEEE. p. .  	 
\bibitem[Seacord ()]{b18}\label{b18} 	 		 			R C Seacord 		.  		\textit{Secure Coding in C and C++},  				2005. Pearson Education.  	 
\bibitem[Joh and Malaiya ()]{b116}\label{b116} 	 		‘Seasonal variation in the vulnerability discovery process’.  		 			H Joh 		,  		 			Y K Malaiya 		.  	 	 		\textit{Proceedings of ICST'09 International Conference on Software Testing Verification and Validation},  				 (ICST'09 International Conference on Software Testing Verification and Validation)  		2009. 2009. IEEE. p. .  	 
\bibitem[Kals et al. ()]{b73}\label{b73} 	 		‘Secubat: a web vulnerability scanner’.  		 			S Kals 		,  		 			E Kirda 		,  		 			C Kruegel 		,  		 			N Jovanovic 		.  	 	 		\textit{Proceedings of the 15th international conference on World Wide Web},  				 (the 15th international conference on World Wide Web)  		2006. ACM. p. .  	 
\bibitem[Secure Coding Guidelines]{b17}\label{b17} 	 		 \url{https://msdn.microsoft.com/en-us/library/d55zzx87\%28v=vs.90\%29.aspx}  		\textit{Secure Coding Guidelines},  				 	 	 (Online; accessed 2016-10-14) 
\bibitem[Suh et al. ()]{b27}\label{b27} 	 		‘Secure program execution via dynamic information flow tracking’.  		 			G E Suh 		,  		 			J W Lee 		,  		 			D Zhang 		,  		 			S Devadas 		.  	 	 		\textit{ACM SIGOPS Operating Systems Review}  		2004. ACM. 38 p. .  	 
\bibitem[Abbott et al. ()]{b132}\label{b132} 	 		‘Security analysis and enhancements of computer operating systems’.  		 			R P Abbott 		,  		 			J S Chin 		,  		 			J E Donnelley 		,  		 			W L Konigsford 		,  		 			S Tokubo 		,  		 			D A Webb 		.  		 NBSIR-76- 1041.  	 	 		\textit{National bureau of standards Washington inst for computer sciences and technology},  				1976.  	 	 (Technical report) 
\bibitem[Anderson]{b137}\label{b137} 	 		‘Security in open versus closed system the dance of boltzmann, coase and moore’.  		 			R Anderson 		.  	 	 		\textit{Open Source Software Economics}  		 	 
\bibitem[Cui et al. ()]{b38}\label{b38} 	 		‘Shieldgen: Automatic data patch generation for unknown vulnerabilities with informed probing’.  		 			W Cui 		,  		 			M Peinado 		,  		 			H J Wang 		,  		 			M E Locasto 		.  	 	 		\textit{IEEE Symposium on}  		2007. 2007. IEEE. p. .  	 	 (SP'07) 
\bibitem[Zhang et al. ()]{b75}\label{b75} 	 		‘Simfuzz: Test case similarity directed deep fuzzing’.  		 			D Zhang 		,  		 			D Liu 		,  		 			Y Lei 		,  		 			D Kung 		,  		 			C Csallner 		,  		 			N Nystrom 		,  		 			W Wang 		.  	 	 		\textit{Journal of Systems and Software}  		2012. 85  (1)  p. .  	 
\bibitem[Detlefs et al. ()]{b59}\label{b59} 	 		‘Simplify: a theorem prover for program checking’.  		 			D Detlefs 		,  		 			G Nelson 		,  		 			J B Saxe 		.  	 	 		\textit{Journal of the ACM (JACM)}  		2005. 52  (3)  p. .  	 
\bibitem[Dahse and Holz ()]{b140}\label{b140} 	 		‘Simulation of built-in php features for precise static code analysis’.  		 			J Dahse 		,  		 			T Holz 		.  	 	 		\textit{Symposium on Network and Distributed System Security (NDSS)},  				2014.  	 
\bibitem[Jhala and Majumdar ()]{b87}\label{b87} 	 		‘Software model checking’.  		 			R Jhala 		,  		 			R Majumdar 		.  	 	 		\textit{ACM Computing Surveys (CSUR)}  		2009. 41  (4)  p. 21.  	 
\bibitem[Henzinger et al. ()]{b135}\label{b135} 	 		‘Software verification with blast’.  		 			T A Henzinger 		,  		 			R Jhala 		,  		 			R Majumdar 		,  		 			G Sutre 		.  	 	 		\textit{Model Checking Software},  				2003. Springer. p. .  	 
\bibitem[Jimenez et al. ()]{b0}\label{b0} 	 		‘Software vulnerabilities, prevention and detection methods: a review’.  		 			W Jimenez 		,  		 			A Mammar 		,  		 			A Cavalli 		,  		 			R Fourier 		.  	 	 		\textit{Proceeding of the first International Workshop on Security in Model Driven Architecture},  				 (eeding of the first International Workshop on Security in Model Driven Architecture)  		2009. SEC-MDA.  	 
\bibitem[Krsul ()]{b9}\label{b9} 	 		\textit{Software vulnerability analysis},  		 			I V Krsul 		.  		1998.  		 			Purdue University 		 	 	 (Ph.D. thesis) 
\bibitem[Liu et al. ()]{b4}\label{b4} 	 		‘Software vulnerability discovery techniques: A survey’.  		 			B Liu 		,  		 			L Shi 		,  		 			Z Cai 		,  		 			M Li 		.  	 	 		\textit{Proceeding of the Fourth International Conference on Multimedia Information Networking and Security (MINES)},  				 (eeding of the Fourth International Conference on Multimedia Information Networking and Security (MINES))  		2012. IEEE. p. .  	 
\bibitem[Cowan et al. ()]{b23}\label{b23} 	 		‘Stackguard: Automatic adaptive detection and prevention of buffer-overflow attacks’.  		 			C Cowan 		,  		 			C Pu 		,  		 			D Maier 		,  		 			J Walpole 		,  		 			P Bakke 		,  		 			S Beattie 		,  		 			A Grier 		,  		 			P Wagle 		,  		 			Q Zhang 		,  		 			H Hinton 		.  	 	 		\textit{Usenix Security}  		1998. 98 p. .  	 
\bibitem[Madan et al. ()]{b25}\label{b25} 	 		‘Stackoffence: a technique for defending against buffer overflow attacks’.  		 			B B Madan 		,  		 			S Phoha 		,  		 			K S Trivedi 		.  	 	 		\textit{Proceeding of International Conference on Information Technology: Coding and Computing. ITCC 2005},  				 (eeding of International Conference on Information Technology: Coding and Computing. ITCC 2005)  		2005. IEEE. 1 p. .  	 
\bibitem[Bau et al. ()]{b122}\label{b122} 	 		‘State of the art: Automated black-box web application vulnerability testing’.  		 			J Bau 		,  		 			E Bursztein 		,  		 			D Gupta 		,  		 			J Mitchell 		.  	 	 		\textit{Proceeding of the 2010 IEEE Symposium on Security and Privacy (SP)},  				 (eeding of the 2010 IEEE Symposium on Security and Privacy (SP))  		2010. IEEE. p. .  	 
\bibitem[Ernst ()]{b43}\label{b43} 	 		‘Static and dynamic analysis: Synergy and duality’.  		 			M D Ernst 		.  	 	 		\textit{WODA 2003: ICSE Workshop on Dynamic Analysis},  				2003. p. .  	 
\bibitem[Wassermann and Su ()]{b68}\label{b68} 	 		‘Static detection of cross-site scripting vulnerabilities’.  		 			G Wassermann 		,  		 			Z Su 		.  	 	 		\textit{Proceeding of the ACM/IEEE 30th International Conference on Software Engineering. ICSE'08},  				 (eeding of the ACM/IEEE 30th International Conference on Software Engineering. ICSE'08)  		2008. IEEE. p. .  	 
\bibitem[Zafar and Ali]{b2}\label{b2} 	 		\textit{Static techniques for vulnerability detection},  		 			K Zafar 		,  		 			A Ali 		.  		Sweden.  		 			Linkoping University 		 	 
\bibitem[Larochelle and Evans ()]{b131}\label{b131} 	 		‘Statically detecting likely buffer overflow vulnerabilities’.  		 			D Larochelle 		,  		 			D Evans 		.  	 	 		\textit{USENIX Security Symposium},  				 			. C E Landwehr,  			A R Bull,  			J P Mcdermott,  			W S Choi 		 (ed.)  		 (Washington DC)  		2001. 1994. 32 p. .  	 	 (A taxonomy of computer program security flaws) 
\bibitem[Almorsy et al. ()]{b123}\label{b123} 	 		‘Supporting automated vulnerability analysis using formalized vulnerability signatures’.  		 			M Almorsy 		,  		 			J Grundy 		,  		 			A S Ibrahim 		.  	 	 		\textit{Proceedings of the 27th IEEE/ACM International Conference on Automated Software Engineering},  				 (the 27th IEEE/ACM International Conference on Automated Software Engineering)  		2012. ACM. p. .  	 
\bibitem[Cadar and Sen ()]{b104}\label{b104} 	 		‘Symbolic execution for software testing: three decades later’.  		 			C Cadar 		,  		 			K Sen 		.  	 	 		\textit{Communications of the ACM}  		2013. 56  (2)  p. .  	 
\bibitem[Yu et al. ()]{b53}\label{b53} 	 		\textit{Symbolic string verification: Combining string analysis and size analysis, in: Tools and Algorithms for the Construction and Analysis of Systems},  		 			F Yu 		,  		 			T Bultan 		,  		 			O H Ibarra 		.  		2009. Springer. p. .  	 
\bibitem[Wang et al. ()]{b76}\label{b76} 	 		‘Taintscope: A checksum-aware directed fuzzing tool for automatic software vulnerability detection’.  		 			T Wang 		,  		 			T Wei 		,  		 			G Gu 		,  		 			W Zou 		.  	 	 		\textit{Proceeding of 2010 IEEE Symposium on Security and Privacy (SP)},  				 (eeding of 2010 IEEE Symposium on Security and Privacy (SP))  		2010. IEEE. p. .  	 
\bibitem[Su and Wassermann ()]{b31}\label{b31} 	 		‘The essence of command injection attacks in web applications’.  		 			Z Su 		,  		 			G Wassermann 		.  	 	 		\textit{ACM SIGPLAN Notices}  		2006. ACM. 41 p. .  	 
\bibitem[The Shields Project ()]{b20}\label{b20} 	 		 \url{http://www.shields-project.eu}  		\textit{The Shields Project},  				2012.  	 	 (Online; accessed 2016-10-23) 
\bibitem[Tian-Yang et al. ()]{b60}\label{b60} 	 		 			G Tian-Yang 		,  		 			S Yin-Sheng 		,  		 			F You-Yuan 		.  	 	 		\textit{Research on software security testing},  				2010. 70 p. .  	 
\bibitem[Felmetsger et al. ()]{b110}\label{b110} 	 		‘Toward automated detection of logic vulnerabilities in web applications’.  		 			L Felmetsger 		,  		 			C Cavedon 		,  		 			G Kruegel 		,  		 			Vigna 		.  	 	 		\textit{USENIX Security Symposium},  				2010. p. .  	 
\bibitem[Pellegrino and Balzarotti ()]{b72}\label{b72} 	 		‘Toward black-box detection of logic flaws in web applications’.  		 			G Pellegrino 		,  		 			D Balzarotti 		.  	 	 		\textit{Proceedings of the Network and Distributed System Security (NDSS) Symposium},  				 (the Network and Distributed System Security (NDSS) Symposium)  		2014.  	 
\bibitem[Byers and Shahmehri ()]{b21}\label{b21} 	 		‘Unified modeling of attacks, vulnerabilities and security activities’.  		 			D Byers 		,  		 			N Shahmehri 		.  	 	 		\textit{Proceedings of the 2010 ICSE Workshop on Software Engineering for Secure Systems},  				 (the 2010 ICSE Workshop on Software Engineering for Secure Systems)  		2010. ACM. p. .  	 
\bibitem[Xue et al. ()]{b119}\label{b119} 	 		\textit{Using replicated execution for a more secure and reliable web browser},  		 			H Xue 		,  		 			N Dautenhahn 		,  		 			S T King 		.  		2012. NDSS.  	 
\bibitem[Mallouli et al. ()]{b125}\label{b125} 	 		‘Vdc-based dynamic code analysis: Application to c programs’.  		 			W Mallouli 		,  		 			A Mammar 		,  		 			A Cavalli 		,  		 			W Jimenez 		.  	 	 		\textit{Journal of Internet Services and Information Security}  		2011. 1  (2/3)  p. .  	 
\bibitem[Heelan]{b82}\label{b82} 	 		‘Vulnerability detection syst ems:Think cyborg, not robot’.  		 			S Heelan 		.  	 	 		\textit{IEEE Security and Privacy}  		9.  	 
\bibitem[Rahimi and Zargham ()]{b114}\label{b114} 	 		‘Vulnerability scrying method for software vulnerability discovery prediction without a vulnerability database, Reliability’.  		 			S Rahimi 		,  		 			M Zargham 		.  	 	 		\textit{IEEE Transactions on}  		2013. 62  (2)  p. .  	 
\bibitem[Woo et al. ()]{b111}\label{b111} 	 		 			S.-W Woo 		,  		 			H Joh 		,  		 			O H Alhazmi 		,  		 			Y K Malaiya 		.  	 	 		\textit{Modeling vulnerability discovery process in apache and iis http servers},  				2011. 30 p. .  	 
\bibitem[De Moura and Bjørner ()]{b101}\label{b101} 	 		\textit{Z3: An efficient smt solver, in: Tools and Algorithms for the Construction and Analysis of Systems},  		 			L De Moura 		,  		 			N Bjørner 		.  		2008. Springer. p. .  	 
\end{bibitemlist}
 			 		 	 
\end{document}
