2017
Software vulnerabilities are susceptible weaknesses (i.e. "bugs") in software, often from exploitable flaws written by the developer or inherent in the programming language. There are many hacker web sites around the world with thousands of individual exploits that one can download to exploit a particular vulnerability. One of the most popular free tools used by blackhats and whitehats alike is Metasploit. The process of trying to reduce the number of software vulnerabilities is now commonly known as the security development lifecycle (SDL). The SDL focuses on every component in the lifecycle of a software program, from its initial creation to its patching of newly found vulnerabilities, in order to make more secure software. Most operating systems are not only being coded by programmers steeped in the SDL and using more secure, by default, programming languages, but are also including built-in defenses against common exploit vectors.
Cited by 2
Raisa Ifquat · OSTI OAI (U.S. Department of Energy Office of Scientific and Technical Information) · 2019
Abstract not provided.
Cited by 0Open access
Maria Canellopoulou‐Bottis · SSRN Electronic Journal · 2006
Cited by 1Open access
Calín Sánchez, Mario, Carrillo de Gea, Juan Manuel, Fernández-Alemán, José Luis et al. · Zenodo (CERN European Organization for Nuclear Research) · 2025
Cited by 0Open access
Long, Frederick W. · KiltHub Repository · 2005
Java is essentially a safe language with good security features. However, there are several Java features and facilities that can compromise safety if they are misused or improperly implemented. This report briefly describes these potential software vulnerabilities in the current version of Java, Java 5.
Cited by 0Open access
Calín Sánchez, Mario, Carrillo de Gea, Juan Manuel, Fernández-Alemán, José Luis et al. · Zenodo (CERN European Organization for Nuclear Research) · 2025
Cited by 0Open access
Matthias Vallentin · 2008
Cited by 0
Fred Long · Figshare · 2005
Java is essentially a safe language with good security features. However, there are several Java features and facilities that can compromise safety if they are misused or improperly implemented. This report briefly describes these potential software vulnerabilities in the current version of Java, Java 5.
Cited by 16Open access
Shahriar, Hossain, Hossain Faruk, Md Jobair, Sobhan, Shahriar et al. · DigitalCommons - Kennesaw State University (Kennesaw State University) · 2021
Robots are widely used in our day-to-day life in various domains. For example, eldercare robots, such as CareO-Bots [1]are used to perform household tasks and provide mobility assistance [2]. Amazon uses manufacturing robots to accomplish manufacturing labor activities, such as welding and assembling equipment [2]. According to the International Data Corporation, spending on robotics is expected to reach USD 241.4 billion by the end of 2023 [4]. However, malicious users can exploit security vulnerabilities in hardware and software components of robotics systems to conduct security attacks and cause malfunction, i.e., deviate robots from their expected behaviors. Security attacks on robots can have serious consequences such as (i) bottlenecks and shutdowns in the assembly line, (ii) disruption in the food supply chain, (iii) incorrect treatment for patients, and (iv) unwanted military attacks injuring or killing civilians and military personnel [2]. Researchers [3] have observed a lack of awareness amongst practitioners related to security issues that can exist in robotics systems. Using qualitative analysis, the project aims to determine the software vulnerabilities that commonly appear in robotics systems. In this work in progress, we plan to discuss our initial findings using Robotics Vulnerability Database (RVD) repositories [5] the following questions – (i) what are the most frequent security vulnerabilities in robotics systems? (ii) what types of components are affected by the vulnerabilities? (iii) what categories of vulnerabilities exist and severity for robotics systems?
Cited by 0Open access
Irena Bojanova, John J. Guerrerio · IT Professional · 2023
Labeling software security vulnerabilities would greatly benefit modern AI cybersecurity research. The National Vulnerability Database (NVD) partially achieves this via assignment of Common Weakness Enumeration (CWE) entries to Common Vulnerabilities and Exposures (CVE) entries. In this work, we explore utilization of the Bugs Framework (BF) formalism for systematic and comprehensive CVE labeling. We specify all memory-related CWEs via BF weaknesses and examine the suitability of these formalisms to describe the corresponding CVEs mapped by NVD. We also identify similarities and overlaps in CWEs that introduce ambiguities in NVD assignments.
Cited by 3
Oleg Ivanov, Dmitry S. Silnov · SHS Web of Conferences · 2017
This article is devoted to the vulnerability of the application solution based on the “1C: Enterprise 8” platform, which can be used by only built-in tools of the platform. Possible threats and attack algorithm are described.
Cited by 0Open access
Swati Chakraborti, Atrayee Majumdar Ray, Swagata Roy Chatterjee et al. · Lecture notes in networks and systems · 2020
Cited by 2
Åuczaj, MichaÅ · Studia Iuridica Lublinensia (Uniwersytet Marii Curie-Skłodowskiej w Lublinie) · 2011
Security and cryptographic applications or libraries, just as any other generic software products may be affected by flaws introduced during the implementation process. No matter how much scrutiny security protocols have undergone, it is — as always — the weakest link that holds everything together to makes products secure. In this paper I take a closer look at problems usually resulting from a simple human made mistakes, misunderstanding of algorithm details or a plain lack of experience with tools and environment. In other words: everything that can and will happen during software development but in the fragile context of cryptography
Cited by 0Open access
Nam H. Pham · 2010
Cited by 7Open access
Ganna Pliekhova, Serhii Neronov, М. V. Kostikova et al. · AIP conference proceedings · 2025
Cited by 0
Joyce L. Tokar, Frederick Jones, Paul E. Black et al. · ACM SIGAda Ada Letters · 2011
Software vulnerabilities are defined as a property of a system's security requirements, design, implementation, or operation that could be accidentally triggered or intentionally exploited and result in a security failure [1]. Many organizations throughout the world are studying software vulnerabilities and how they allow software applications to be infiltrated and corrupted. The Common Weakness Enumeration (CWE) [2] is a collection of standard, measurable weaknesses that may be used to assess software tools and services. The CWE may be also be used to document known vulnerabilities and improve communication between parties working on software assurance. The SPARK programming language and toolset [3, 4] is designed for the development of high assurance software. The SPARK programming language is a subset of the Ada programming language plus a collection of annotations intended to provide a programming language that is unambiguous, free from implementation dependencies, and formally defined. Used together, the SPARK language and toolset enable the prevention and elimination of defects in source code during the development of the code. This paper presents an analysis of the SPARK programming language against a collection of CWEs.
Cited by 1
Bruno Goncalves de Oliveira, Maycon Vitali, Willian Massami Watanabe · 2017
Security is a real concern for the society and it is not different for software. Vulnerable applications can expose the users to multiple risks. Software disassembling is an interesting approach to discover vulnerabilities. Unmounting an application into Assembly code can reveal multiple characteristics from the software. During the disassembling, technical features can be revealed that enable the researcher to discover issues even with no source-code available. The paper has the goal of demonstratingSecurity is a real concern for the society and it is not different for software. Vulnerable applications can expose the users to multiple risks. Software disassembling is an interesting approach to discover vulnerabilities. Unmounting an application into Assembly code can reveal multiple characteristics from the software. During the disassembling, technical features can be revealed that enable the researcher to discover issues even with no source-code available. The paper has the goal of demonstrating the disassembling efficacy for detecting vulnerabilities on software and presents a case study to evaluate the concept. the disassembling efficacy for detecting vulnerabilities on software and presents a case study to evaluate the concept.
Cited by 1
UMCS Library (Maria Curie-Skłodowska University) · 2011
Cited by 0
Adarsh Anand, Navneet Bhatt, Omar H. Alhazmi · River Publishers eBooks · 2024
Cited by 0
Harshita Durgapal, Deepak Kumar · 2024
Software serves as a cornerstone in the functionality of devices and systems that seamlessly integrate into our daily lives. However, the complexity of these systems, often developed by multiple programmers, leaves room for inadvertent errors in the code. These errors, known as software vulnerabilities, represent flaws or defects in the software's construction that malicious actors can exploit to gain unauthorized access or privileges within the system. Despite advancements in understanding vulnerabilities, the prevalence of reported vulnerabilities continues to rise, emphasizing the critical importance of software security research. In response to this growing concern, there is a pressing need for tools to assist programmers in identifying and mitigating vulnerabilities during the code development process. As part of our ongoing research paper into detection of vulnerabilities, along with methods for their prevention and detection. Furthermore, we delve into recent advancements in utilizing machine learning techniques to enhance vulnerability detection across various types of software vulnerabilities. We have tested on real data set and the results are better than existing models.
Cited by 1