A software vulnerability is a weakness that can be used to violate a system’s security requirements. Impact may include unauthorized access, code execution, data disclosure, privilege escalation, integrity loss, or denial of service.
Not every software bug is security-relevant, and not every vulnerability has a public identifier or working exploit. Defenders should evaluate the affected asset and attack conditions rather than relying on one label or score.
Bug, weakness, vulnerability, and exposure
- A bug is an implementation or design error; many affect only functionality.
- A weakness is a type of flaw or unsafe pattern, often classified through CWE.
- A vulnerability is a specific weakness with security impact in a product or system.
- An exposure is reachable or disclosed functionality that increases risk, sometimes without a coding defect.
- An exploit is code or a technique that abuses a vulnerability.
CVE, CWE, CVSS, and CPE
CVE provides identifiers for publicly disclosed vulnerabilities. CWE classifies recurring weakness types such as improper input validation. CVSS expresses technical severity under stated assumptions. CPE names product platforms in machine-readable form. These systems support tracking, but none by itself proves that a particular installed asset is affected or exposed.
Common vulnerability types
Examples include memory-safety errors, injection, broken access control, authentication bypass, path traversal, insecure deserialization, race conditions, cryptographic mistakes, server-side request forgery, and unsafe default configuration. Vulnerabilities can also exist in dependencies, firmware, build systems, cloud policies, and update mechanisms.
How vulnerabilities are discovered
Researchers use code review, fuzzing, testing, dependency analysis, reverse engineering, threat hunting, and incident evidence. Responsible disclosure gives maintainers time to investigate and develop fixes while coordinating publication. Users should obtain advisories and patches from authenticated vendor sources.
How to assess real risk
- Confirm the exact product, version, configuration, and affected component.
- Determine whether the asset is reachable and what privileges an attacker needs.
- Consider data sensitivity and business criticality.
- Check for evidence of exploitation in the wild, including CISA’s KEV catalog.
- Review exploit maturity, mitigations, detection coverage, and recovery options.
A lower CVSS issue on an exposed identity system can deserve higher priority than an isolated high-score issue.
Patch, mitigation, and compensating control
A vendor patch or supported upgrade normally provides the durable fix. Temporary mitigations may disable a feature, restrict network access, change configuration, or add filtering. A compensating control reduces likelihood or impact without removing the flaw. Track temporary measures with owners and expiration dates.
How to verify remediation
Confirm the installed build or configuration, restart when required, and rescan using authenticated information. Test the previously vulnerable behavior in an authorized environment. A deployment tool reporting success does not prove every asset received the fix or that duplicate, container, or offline instances are covered.
What to do when no patch exists
Follow vendor guidance, reduce exposure, disable the affected component, isolate the asset, increase monitoring, or suspend the service. Unsupported software needs a replacement or strict containment plan. Do not download unofficial “fixes” from exploit forums.
Vulnerability-management metrics
Measure asset coverage, time to remediate by risk, known-exploited exposure, failed deployments, overdue exceptions, and verification results. Counting closed tickets alone can hide the few reachable vulnerabilities that create most of the risk.