Software Vulnerability Prediction Techniques

This assignment delves into the field of software vulnerability prediction. It examines a range of research papers that present diverse methods for predicting software vulnerabilities. These methods encompass approaches like using code complexity metrics, identifying secure coding standard violations, and analyzing patterns within source code. The assignment emphasizes understanding the principles behind each technique and evaluating their effectiveness in mitigating security risks associated with software development.

Running head: IT SECURITY
IT SECURITY
Name of the Student
Name of the University
Author Note

2IT SECURITY
Table of Contents
Introduction....................................................................................................................3
Loss due to exploitation.................................................................................................3
Vulnerability disclosers types........................................................................................8
Cost related issue..........................................................................................................12
Conclusion....................................................................................................................13
References....................................................................................................................15

3IT SECURITY
Introduction
Computer software vulnerability can be considered as threats that have been playing a
very much vital role in every sphere related to the concept of modern technology. Relating to
when a breach takes place the first question which arises in the mind is that who is mainly
gained from the incident. The answers are mainly the attackers to initiate the attack. The main
concept is breaking into the system and stealing information or money, this task is considered
to be very much easy from the side of the attacker and profitable also (Li et al. 2017). To be
very much precise a software vulnerability can be stated as a flaw within a software product
that can cause it deviation from the proper working and tend to lend the control of the entire
software in the hand of the hackers who focus mainly to deliver profit on his basis from the
vulnerability which is detected in the software and its peripherals.
This report directly puts emphasis on the concept of the vulnerable which is related to
the software and what stands in the way of delivering a software which does not face any
issue related to vulnerability. The main point of emphasis is the issue which are taken into
account after a vulnerability is taken into account bringing into limelight the different tactics
that are followed in order to resolve the issue and take necessary steps to reduce the after
affect.
Loss due to exploitation
Taking into consideration the complex communication system and information gives rise
to implementation, design and management errors. These errors can directly lead to the
concept of vulnerability. The term vulnerability can be used to describe a flaw in the
information technology product that could be mainly used for the exploitation of the product.
There can be several methods which can be included in the term of exploitation. Exploitation

4IT SECURITY
can be classified on the type of vulnerability they intent to attack. Few example which can be
included in this concept are:
 Buffer overflow: in terms of computer security and programming the term buffer
overflow or buffer overrun can be stated as an anomaly with regards to a program,
while mainly the action of writing data to a buffer, overruns the boundary of the
buffer and overwrites the adjacent location of the memory (Rahimi and Zargham
2017).
Figure 1: BUFFER OVERFLOW
(SOURCE: Rahimi and Zargham 2017).
Situation a: when the main program is running
Situation b: after the program A is called
Situation c: buffer overflow concept which is shown in grey
 Memory corruption

5IT SECURITY
The concept of the memory corruption usually occurs in the computer program when
the overall content of the memory location is unintentionally modified. It can be referred to as
a violation of the memory safety ( Li et al. 2017).
Figure 1: MEMORY CORRUPTION
(SOURCE: Rahimi and Zargham 2017).
 Race condition
The race condition can be considered as situation which is undesirable that mainly
occur when a device of a system mainly attempts to perform two or more operations with
regards to the same instance of time, but due to the factor of nature of the device or the
system, the operation should be done in the proper sequence in order to do it correctly.

6IT SECURITY
Figure 1: RACE CONDITION
(SOURCE: Rahimi and Zargham 2017).
 SQL injection
SQL injection is mainly considered as a code technique of injection which is mainly
done to attack the data driven application, in which the nefarious statement of the SQL is
injected into an entry field with the intention of execution.

7IT SECURITY
Figure 1: SQL INJECTION
(SOURCE: Rahimi and Zargham 2017).
The main classification of the exploits can also be done on how the exploit contacts
with the vulnerable software (Rahimi and Zargham 2017). There are mainly two types which
can be involved in the concept, one being remote exploit and the other being local exploit. A
remote exploit works mainly over a predefined network with the intention of exploiting the
security vulnerability and on the other hand the local exploit requires the access prior to the
vulnerable system and which usually increase the privileges in regards to the person running
the main action of the exploit (Sibal, Sharma and Sabharwal 2017).
Mainly due to the popularity in the concept of the internet, the network borne virus
which are the computer virus and the worms can be termed as the main forms of exploitation.
Taking into consideration a computer worm, it can the ability of self-replicating itself and can
be considered as a self-contained exploitation. The computer worm can spread from one
system to another system without the intervention of human activity ( Spanos et al. 2016).
Onm the other hand a computer virus requires the action on the part of the user, for example
emails attachments etc. the computer worms and the virus can be termed as a most cited
example form of exploitation which has achieved overall 82% of the activity. The reco9very
aspect which is related to the case are that almost 33% of the victim recovered from the
attack in one day, 30% recovered in a tenure of one to seven days and 37% took more than a
weeks’ time to recover completely from the attack ( Li et al. 2017).
Exploits can also be classified on the concept of the main purpose of the attack and
the main intention behind the attack. Few of the example which can be related in this type of
classification are: personal frame (trespasser), curiosity (vandal), personal gain(thief) and
interest of national (spy). The slammer, blaster and the code red attack mainly infected

8IT SECURITY
millions and millions of computer all over the world, it can be considered as very much
expensive in order to recover from the incident. In recent times the attack which I s related to
the personal gain can be considered as one of the most fastest growing sectors in the segment
(Sibal, Sharma and Sabharwal 2017). These exploits can be terms of email phasing, email
spam, keystroke loggers, bots and credential theft. Taking into consideration this types of
attack many of the people who are victim of the attack are spoofed, where more than 60% of
the victim visited the spoofed site and more than 15% have mainly admitted of giving their
personal data to unwanted resources.
Vulnerability disclosers types
Taking into account a software vulnerability, each and every software vulnerability
can be stated as different mainly on the basis of the process by which the flaws are mainly
discovered to the ways in which the vulnerability is disclosed. There can be few categories in
which the software vulnerability can be classified which are:
Non – discloser
The first discloser type which is taken into account is the non-discloser. This discloser is
probably the easiest type of discloser which can be described and on the other hand
quantification is very much difficult. In the case of this type of discloser, the researchers have
discovered a vulnerability concept in a piece of a software, rather than the contact the
software vendors or the security of the computer authority coordinating the event, the
researchers mainly kept the concept of the vulnerability a mere secret. The community which
is mainly involved in this type of practice are the black hat hackers.
The concept of quantification which is very much difficult is due to the fact of the
paradox that are no ways in which measurement of the flaws can be obtained but not
disclosed (Sibal, Sharma and Sabharwal 2017). Based on the communication model it can be

9IT SECURITY
estimated that up to 17.3% of the finding of the vulnerability were not disclosed, however the
statement of the how many vulnerabilities were discovered but remain undisclosed is a very
important point of consideration in such a case. There was fairly a huge amount of critic on
the concept of the vulnerability, the main point of concern is that the system remains open to
the vulnerability even though the vulnerability is known, the main reason of this fact is that
the vendors lack of publicity concept in the vulnerability may not be motivating on the point
of the software vendors in order to repair the flaws immediately when it is known. Others
variations which are taken into account on the non-discloser method tend to have the same
result at the net end of the process which include greater risk towards the user in the point of
view of the exploitation of the vulnerability. For example, it can be state that a researcher
may find out any sort of vulnerability in a piece of software, the result of the action is taken
in such a way that apart from reporting the vulnerability to the concerned authority the
attackers would directly share the vulnerability which is involved in the software with other
hackers which directly increase the risk associated to the user which are termed as the end
user in this case (Joh and Malaiya 2016).
Full discloser
When a researchers find out a vulnerability they tend to inform the community at a
whole about the vulnerability and mainly specifies how the vulnerability is found out, which
software products can be affected by such vulnerability and the overall affect which is
involved in due to the incident. On the broader sense they also tend to focus on the points on
how the to exploit the flaws and how to protect the system against being a victim of the
vulnerability. There can be many arguments against the main concept of the full discloser
vulnerability in the sense that the total argument is taken into interest of the attackers and the
informing the community about the attack. The main argument can be stated in two different
way notability the first being that it is very much unethical to inform the community as a

10IT SECURITY
whole about the software flaws which are involved as soon as it is detected even before any
patch is taken into account in order to reduce the overall impact of the vulnerability so that
from the users point of view they can protect themselves. The second point of emphasis is
that tactic motive in regards to the vendors of the software as when a software flaw is
detected is to sit behind and acknowledge the event and informs the community about that an
event has taken place rather than trying to generated some sort of patches in order to reduce
the overall impact of the attack.
One of the advantage that is faced in concept to the full discloser that when a flaw is
detected the credit goes to the researchers on the incident of detecting the flaw. The credit
goes directly in the hand of the researchers. Clearly it can be stated that incentives and the
motivation which is related to the security industry being for personal or professional, the full
discloser can be considered as a discloser technique that can be a field of attraction for the
researchers of the security (Ghaffarian, S.M. and Shahriari 2017).
On the other hand, the argument against the category of the full discloser method tend
to go parallel with the full discloser. It can be seen that one of the most silent argument which
usually takes place with the incident is that the exposing part of the vulnerability without the
proper consultation with the software vendor related to the main event, this may directly
result in increase of the risk being widespread in the point of view of the user of the system of
the computer (Joh and Malaiya 2016). A very common example which can be related to the
incident is that with few days or hours following the detection of the vulnerability a full script
is ready and very much available for the script Kidde’s toc consume and use the concept.
Additionally, taking into account the vendors are not informed on the first hand about the
vulnerability and the incident and main emphasis is put on informing the community about
the incident, the work on the patches and the security measures that should be implemented
takes very much time, the testing phase which is related to any software flaws can take time

11IT SECURITY
to about few days before a patch van be launched in order to reduce the overall effect of the
vulnerability. So it can have stated that there always lies a big window in which the user or
the community is informed about the flaws but no patches or security measures are involved
in the process to lack of information which is landed to the vendors in order for them to work
on it and provide the necessary patches to the community or the users in order to protect them
(Ghaffarian, S.M. and Shahriari 2017).
Responsible discloser
This can be termed as a final step of the discloser. The responsible discloser mainly falls
into what can be stated as a class of vulnerability which can be known as partial discloser or
in simple terms limited discloser. The responsible discloser may be stated as a policy of
software discloser in which software vulnerability are mainly disclosed in a manner with the
intention of putting the user at a minimum risk stage without the alteration related to the
stifling the research security community. To make the term simple, when a vulnerability is
detected in any software the researchers directly inform the vendors who are related to the
software, and if the vendors in some cases are not responsive to the event , the researchers
takes the overall control over the event and proceed with it. The main stages that are followed
in this type of disclosers are as follows:
 The researchers first step after discovering of the flaw is to inform the vendors about
the vulnerability (Shin and Williams 2016).
 If the vendor’s quickie responds the event and acknowledges the flaw and credit the
researchers in order of identify the flaw and conduct the testing phase on the flaw and
immediately after the testing issue of the patch related to the flaw is made the process can
be stated to be complete.

12IT SECURITY
 On the other hand, if the vendors do not respond quickly enough to the flaw or mainly
fail to continue the communication related to the event, the originator has no other option
than to proceed with the public discloser without the vendor’s direct intervention in the
event of no patches being supplied.
 Taking into account both the scenarios, the concept of when the vulnerability is
detected the principle should be to response quickly to the flaws. This can be done on the
point of view of the vendors and also on the point of view of the researchers who have
identified the issue and work on the always so that the common people are not affected to
much by the incident (Joh and Malaiya 2016).
Cost related issue
The cost of the software vulnerability towards the vendor can be broadly be classified
mainly into two categories: the cost of distributing a patch for the defect and loss of cost sales
due to the factor of dissatisfaction from the point of view of the customer.
1. Cost of patch: the cost which is relating to fixing any sort of problem after the release of
the software can be considered to be always on the higher point than the cost of fixing a
problem prior to the release of the software. It can be estimated that the cost of fixing any
problem after the realise is eight times more than prior to the release. Researchers have
found out that fixing a bug after a realise is very much difficult and time consuming then
prior to the release. Taking an example of one of the giants in the field of technology
Microsoft, the company spends nearly $100000 on an average for the security related
issue in order to distribute patch for any fault which is detected. However, the cost of the
releasing aspect of each of the patches can be on a lower end by distributing the patches
online

13IT SECURITY
2. Cost of loss related to sales: software vulnerability can directly lead to customer
dissatisfaction, loss of reputation of the vendor and disruption. Defective software can
superimpose many types of problem related to the user as stated below:
a. The breaches which occur due to software may lead to disruption, downfall as well as
compromised information which is related to confidentiality.
b. Using of defective software from the point of view of the user can impose many types of
cost related issue.
The magnitude of the second point which is discussed above can be directly be related
to the Amount of loss which is generated from the point of view of the customers. Moreover,
putting emphasis on the vendors they can future loss many of the users due to user’s
avoidance in order of buying the product and with the existing customers delay can purchase
can be exhibited due to the insecurity which is seen in the product. It can also be stated that
the software products have largest cost related issue when relating to the switching which
makes it difficult for the users to switch between the vendors. Therefore, the cost related to
the sales lost depends mainly on the market structure as well.
Conclusion
The report puts direct emphasis on a contemporary and interesting issue of whether
vendors of the software are adversely affected by the security issue related vulnerability
which is related to the software products. It can be stated that due to the unique
characteristics of the software industry in the near future the damage which is imposed on the
vendor’s point of view on an event of a software vulnerability would be very much minimal
and unneglectable. The vulnerability issue which is related to the software product can be
state to be very much on a higher side if after the detection of the vulnerability no patches or
security measures are involved in the process. there should be always a high end testing of
the vulnerability and why it is caused so that the end users are not affected by such events.

14IT SECURITY
On the other hand the report also states that the cost related to the include patches after the
release of a software is always on a higher hand, so it must always be taken into consideration
that the testing and other security issue related problems are solved before the software is in
the hand of the common users. This would be directly beneficial from the point of view of the
vendors as well as the user of the software.

15IT SECURITY
References
Alves, H., Fonseca, B. and Antunes, N., 2016, September. Software Metrics and Security
Vulnerabilities: Dataset and Exploratory Study. In Dependable Computing Conference
(EDCC), 2016 12th European (pp. 37-44). IEEE.
Anand, P., 2016, August. Overview of Root Causes of Software Vulnerabilities-Technical
and User-Side Perspectives. In Software Security and Assurance (ICSSA), 2016 International
Conference on (pp. 70-74). IEEE.
Cai, J., Zou, P., Ma, J. and He, J., 2016. SwordDTA: A dynamic taint analysis tool for
software vulnerability detection. Wuhan University Journal of Natural Sciences, 21(1), pp.10-
20.
Dam, H.K., Tran, T., Pham, T., Ng, S.W., Grundy, J. and Ghose, A., 2017. Automatic feature
learning for vulnerability prediction. arXiv preprint arXiv:1708.02368.
Ghaffarian, S.M. and Shahriari, H.R., 2017. Software Vulnerability Analysis and Discovery
Using Machine-Learning and Data-Mining Techniques: A Survey. ACM Computing Surveys
(CSUR), 50(4), p.56.
Hovsepyan, A., Scandariato, R. and Joosen, W., 2016, September. Is Newer Always Better?:
The Case of Vulnerability Prediction Models. In Proceedings of the 10th ACM/IEEE
International Symposium on Empirical Software Engineering and Measurement (p. 26).
ACM.
Hovsepyan, A., Scandariato, R., Joosen, W. and Walden, J., 2017, September. Software
vulnerability prediction using text analysis techniques. In Proceedings of the 4th international
workshop on Security measurements and metrics (pp. 7-10). ACM.

16IT SECURITY
Jimenez, M., Papadakis, M. and Le Traon, Y., 2016, October. Vulnerability Prediction
Models: A case study on the Linux Kernel. In Source Code Analysis and Manipulation
(SCAM), 2016 IEEE 16th International Working Conference on (pp. 1-10). IEEE.
Joh, H. and Malaiya, Y.K., 2016. Periodicity in software vulnerability discovery, patching
and exploitation. International Journal of Information Security, pp.1-18.
Lagerström, R., Baldwin, C., MacCormack, A., Sturtevant, D. and Doolan, L., 2017, July.
Exploring the Relationship Between Architecture Coupling and Software Vulnerabilities. In
International Symposium on Engineering Secure Software and Systems (pp. 53-69). Springer,
Cham.
Li, H., Kwon, H., Kwon, J. and Lee, H., 2016. CLORIFI: software vulnerability discovery
using code clone verification. Concurrency and Computation: Practice and Experience, 28(6),
pp.1900-1917.
Li, X., Chang, X., Board, J.A. and Trivedi, K.S., 2017, January. A novel approach for
software vulnerability classification. In Reliability and Maintainability Symposium (RAMS),
2017 Annual (pp. 1-7). IEEE.
Nord, R.L., Ozkaya, I., Schwartz, E.J., Shull, F. and Kazman, R., 2016, August. Can
Knowledge of Technical Debt Help Identify Software Vulnerabilities?. In CSET@ USENIX
Security Symposium.
Piancó, M., Fonseca, B. and Antunes, N., 2016, June. Code Change History and Software
Vulnerabilities. In Dependable Systems and Networks Workshop, 2016 46th Annual
IEEE/IFIP International Conference on (pp. 6-9). IEEE.

17IT SECURITY
Piessens, F. and Verbauwhede, I., 2016, March. Software security: Vulnerabilities and
countermeasures for two attacker models. In Proceedings of the 2016 Conference on Design,
Automation & Test in Europe (pp. 990-999). EDA Consortium.
Rahimi, S. and Zargham, M., 2017. Vulnerability scrying method for software vulnerability
discovery prediction without a vulnerability database. IEEE Transactions on Reliability,
62(2), pp.395-407.
Shin, Y. and Williams, L., 2016, October. An empirical model to predict security
vulnerabilities using code complexity metrics. In Proceedings of the Second ACM-IEEE
international symposium on Empirical software engineering and measurement (pp. 315-317).
ACM.
Shin, Y., Meneely, A., Williams, L. and Osborne, J.A., 2016. Evaluating complexity, code
churn, and developer activity metrics as indicators of software vulnerabilities. IEEE
Transactions on Software Engineering, 37(6), pp.772-787.
Sibal, R., Sharma, R. and Sabharwal, S., 2017. Prioritizing software vulnerability types using
multi-criteria decision-making techniques. Life Cycle Reliability and Safety Engineering,
6(1), pp.57-67.
Spanos, G., Angelis, L. and Kosmidou, K., 2017. Is the Market Value of Software Vendors
Affected by Software Vulnerability Announcements?. In Strategic Innovative Marketing (pp.
465-469). Springer, Cham.
Spanos, G., Angelis, L. and Kosmidou, K., 2017. Is the Market Value of Software Vendors
Affected by Software Vulnerability Announcements?. In Strategic Innovative Marketing (pp.
465-469). Springer, Cham.

18IT SECURITY
Stuckman, J., Walden, J. and Scandariato, R., 2017. The Effect of Dimensionality Reduction
on Software Vulnerability Prediction Models. IEEE Transactions on Reliability, 66(1), pp.17-
37.
Sultana, K.Z., Deo, A. and Williams, B.J., 2016, June. A preliminary study examining
relationships between nano-patterns and software security vulnerabilities. In Computer
Software and Applications Conference (COMPSAC), 2016 IEEE 40th Annual (Vol. 1, pp.
257-262). IEEE.
Sultana, K.Z., Deo, A. and Williams, B.J., 2017, January. Correlation Analysis among Java
Nano-Patterns and Software Vulnerabilities. In High Assurance Systems Engineering
(HASE), 2017 IEEE 18th International Symposium on (pp. 69-76). IEEE.
Yang, J., Ryu, D. and Baik, J., 2016, January. Improving vulnerability prediction accuracy
with secure coding standard violation measures. In Big Data and Smart Computing
(BigComp), 2016 International Conference on (pp. 115-122). IEEE.
Yu, C., Mannan, A.M., Yvone, G.M., Ross, K.N., Zhang, Y.L., Marton, M.A., Taylor, B.R.,
Crenshaw, A., Gould, J.Z., Tamayo, P. and Weir, B.A., 2016. High-throughput identification
of genotype-specific cancer vulnerabilities in mixtures of barcoded tumor cell lines. Nature
biotechnology, 34(4), pp.419-423.
Zhu, X., Cao, C. and Zhang, J., 2017. Vulnerability severity prediction and risk metric
modeling for software. Applied Intelligence, pp.1-9.