It may arise from design, code, configuration, deployment, procedure, or a dependency. The term describes the weakness itself — not an exploit, an attack, or the likelihood and impact that make up risk.
Whether a vulnerability matters in a particular environment depends on affected versions, deployment, reachability, existing safeguards, available attack paths, and the consequences of compromise. Those factors should inform treatment without changing the underlying definition.
Key points
Possible originsVulnerabilities can result from flawed assumptions, implementation errors, insecure defaults, missing controls, unsafe composition, operational mistakes, or weaknesses inherited from third parties.
Evidence and validationFindings may come from research, testing, scanning, code review, incident analysis, supplier advisories, or coordinated disclosure, and often require confirmation against the actual environment.
Treatment choicesDepending on context, an organization may remediate the weakness, reduce exposure, add a compensating control, retire the affected component, or explicitly accept the remaining risk.
Important limitationDiscovering a vulnerability does not prove that it is reachable, exploitable, actively exploited, or high impact in every deployment; absence of a finding likewise does not prove that no vulnerability exists.