Vulnerability (computer security): Difference between revisions

Revision as of 03:40, 1 June 2025

Latest revision as of 03:46, 13 August 2025

(11 intermediate revisions by 9 users not shown)

Line 1:

{{merge from|security bug|discuss=Talk:Vulnerability (computer security)#Merge proposal|date=May 2025}}

{{short description|Exploitable weakness in a computer system}}

{{Computer hacking}}

Line 8 ⟶ 7:

[[Vulnerability management]] is a process that includes identifying systems and prioritizing which are most important, scanning for vulnerabilities, and taking action to secure the system. Vulnerability management typically is a combination of remediation, mitigation, and acceptance.

Vulnerabilities can be scored for riskseverity according to the [[Common Vulnerability Scoring System]] (CVSS) and added to vulnerability databases such as the [[Common Vulnerabilities and Exposures]] (CVE) database. As of November 2024, there are more than 240,000 vulnerabilities catalogued in the CVE database.<ref name="Metrics">{{cite web |url=https://www.cve.org/About/Metrics |title=CVE - Program Metrics |date=15 November 2024 }}</ref>

A vulnerability is initiated when it is introduced into hardware or software. It becomes active and exploitable when the software or hardware containing the vulnerability is running. The vulnerability may be discovered by the administrator, vendor, or a third party. Publicly [[Coordinated vulnerabilityFull disclosure (computer security)|Disclosingdisclosing the vulnerability]] (through a [[Patch (computing)|patch]] or otherwise) is associated with an increased risk of compromise, as attackers can use this knowledge to target existing systems before patches are implemented. Vulnerabilities will eventually end when the system is either patched or removed from use.

==Causes==

Despite a system administrator's best efforts, virtually all hardware and software contain bugs.{{sfn|Ablon|Bogart|2017|p=1}} If a bug creates a security risk, it is called a vulnerability.{{sfn|Ablon|Bogart|2017|p=2}}{{sfn|Daswani |Elbayadi|2021|p=25}}{{sfn|Seaman|2020|pp=47-48}} Software patches are often released to fix identified vulnerabilities, but [[zero-days]] are still liable for exploitation.{{sfn|Daswani |Elbayadi|2021|pp=26-27}} Vulnerabilities vary in their ability to be [[Exploit (computer security)|exploited]] by malicious actors, and the actual risk is dependent on the nature of the vulnerability as well as the value of the surrounding system.{{sfn|Haber |Hibbert|2018|pp=5-6}} Although some vulnerabilities can only be used for [[denial of service]] attacks, more dangerous ones allow the attacker to perform [[code injection]] without the user's awareness.{{sfn|Ablon|Bogart|2017|p=2}} Only a minority of vulnerabilities allow for [[privilege escalation]], which is typically necessary for more severe attacks.{{sfn|Haber |Hibbert|2018|p=6}} Without a vulnerability, an exploit typically cannot gain access.{{sfn|Haber |Hibbert|2018|p=10}} It is also possible for [[malware]] to be installed directly, without an exploit, through [[Social engineering (security)|social engineering]] or poor [[physical security]] such as an unlocked door or exposed port.{{sfn|Haber |Hibbert|2018|pp=13–14}}

===Design factors===

Line 25 ⟶ 24:

Some [[software development]] practices can affect the risk of vulnerabilities being introduced to a code base. Lack of knowledge about secure software development or excessive pressure to deliver features quickly can lead to avoidable vulnerabilities to enter production code, especially if security is not prioritized by the [[company culture]]. This can lead to unintended vulnerabilities. The more complex the system is, the easier it is for vulnerabilities to go undetected. Some vulnerabilities are deliberately planted, which could be for any reason from a disgruntled employee selling access to cyber criminals, to sophisticated state-sponsored schemes to introduce vulnerabilities to software.

Poor [[software development]] practices can affect the likelihood of introducing vulnerabilities to a code base. Lack of knowledge or training regarding secure software development, excessive pressure to deliver, or an excessively complex code base can all allow vulnerabilities to be introduced and left unnoticed. These factors can also be exacerbated if security is not prioritized by the [[company culture]]. {{sfn|Strout|2023|p=17}} Inadequate [[code review]]s can also lead to missed bugs, but there are also [[Static application security testing|static code analysis]] tools that can be used during the code review process to help find some vulnerabilities.{{sfn|Haber |Hibbert|2018|p=143}}

In some cases, vulnerabilities can also be deliberately planted by an [[insider threat]], such as by a disgruntled emplpoyee selling access to cyber criminals or state-sponsored schemes.{{cn}}

[[DevOps]], a development workflow that emphasizes automated testing and deployment to speed up the deployment of new features, often requires that many developers be granted access to change configurations, which can lead to deliberate or inadvertent inclusion of vulnerabilities.{{sfn|Haber |Hibbert|2018|p=141}} Compartmentalizing dependencies, which is often part of DevOps workflows, can reduce the [[attack surface]] by paring down dependencies to only what is necessary.{{sfn|Haber |Hibbert|2018|p=142}} If [[software as a service]] is used, rather than the organization's own hardware and software, the organization is dependent on the cloud services provider to prevent vulnerabilities.{{sfn|Haber |Hibbert|2018|pp=135-137}}

Line 111 ⟶ 108:

{{refbegin|indent=yes}}

*{{cite book |last1=Ablon |first1=Lillian |last2=Bogart |first2=Andy |title=Zero Days, Thousands of Nights: The Life and Times of Zero-Day Vulnerabilities and Their Exploits |date=2017 |publisher=Rand Corporation |isbn=978-0-8330-9761-3 |language=en|url=https://www.rand.org/content/dam/rand/pubs/research_reports/RR1700/RR1751/RAND_RR1751.pdf}}

*{{cite journal | last1=Agrafiotis | first1=Ioannis | last2=Nurse | first2=Jason R C | last3=Goldsmith | first3=Michael | last4=Creese | first4=Sadie | last5=Upton | first5=David | title=A taxonomy of cyber-harms: Defining the impacts of cyber-attacks and understanding how they propagate | journal=Journal of Cybersecurity | volume=4 | issue=1 | date=2018 | issn=2057-2085 | doi=10.1093/cybsec/tyy006|ref={{sfnref|Agrafiotis et al.|2018}}| doi-access=free }}

*{{cite book |last1=Daswani |first1=Neil|authorlink=Neil Daswani |last2=Elbayadi |first2=Moudy |title=Big Breaches: Cybersecurity Lessons for Everyone |date=2021 |publisher=Apress |isbn=978-1-4842-6654-0}}

*{{cite book |last1=Garg |first1=Shivi |last2=Baliyan |first2=Niyati |title=Mobile OS Vulnerabilities: Quantitative and Qualitative Analysis |date=2023 |publisher=CRC Press |isbn=978-1-000-92451-0 |language=en}}