Every operating system, application and network device contains software, and software can contain vulnerabilities. These weaknesses may allow attackers to gain unauthorised access, steal information, disrupt services or compromise systems.
Understanding how vulnerabilities are discovered, disclosed, classified and remediated is fundamental to effective vulnerability management and maintaining compliance with standards such as Cyber Essentials.
1. How are vulnerabilities first discovered?
Security vulnerabilities are discovered in several ways.
Security researchers actively examine software for weaknesses using techniques such as penetration testing, code analysis, fuzzing and reverse engineering. Some participate in bug bounty programmes, receiving financial rewards for responsibly reporting vulnerabilities.
Software manufacturers discover weaknesses through internal security testing, automated code scanning and quality assurance processes.
Cybercriminals also discover vulnerabilities, sometimes exploiting them before manufacturers or security researchers become aware of their existence.
Increasingly, automated security tools analyse software and systems to identify known weaknesses, insecure configurations and potentially vulnerable components.
A vulnerability might exist for years before anybody discovers it. The important distinction is between when a weakness is introduced into software and when someone first identifies it.
2. What is a zero-day vulnerability?
A zero-day vulnerability is a software security weakness for which no official fix is available and which is generally unknown to the vendor or has only recently become known.
The term zero-day reflects the fact that defenders have had little or no opportunity to prepare an effective response.
A zero-day exploit is the technique or code used to take advantage of that vulnerability. A zero-day attack occurs when an attacker actively exploits it.
Not every zero-day vulnerability is being exploited, and not every newly disclosed vulnerability is a zero-day.
Zero-days are particularly concerning because conventional patch management cannot immediately eliminate the underlying weakness. Organisations may need temporary protective measures while waiting for the manufacturer to release a fix.
3. How are vulnerabilities reported?
When a researcher discovers a vulnerability, the preferred approach is coordinated vulnerability disclosure.
The researcher privately contacts the software manufacturer, usually through its Product Security Incident Response Team (PSIRT), security reporting portal or published vulnerability disclosure programme.
The manufacturer investigates the report, attempts to reproduce the weakness, determines which product versions are affected and develops a suitable fix.
Researchers and manufacturers may agree on a disclosure timeline, allowing time for remediation before technical details become public.
Where manufacturers cannot be contacted or coordination is difficult, organisations such as CERT Coordination Center or national cybersecurity authorities may help manage disclosure.
Once the vulnerability is ready for public disclosure, the manufacturer typically publishes a security advisory describing the affected products, severity and recommended corrective action.
4. How does MITRE assign a CVE?
To make vulnerabilities consistently identifiable, the cybersecurity industry uses Common Vulnerabilities and Exposures (CVE) identifiers.
The CVE programme is operated by MITRE with a network of authorised CVE Numbering Authorities (CNAs), including major software manufacturers and security organisations.
A CVE identifier looks like this:
CVE-2026-12345
The identifier consists of the CVE prefix, year and a unique numerical sequence.
Importantly, vulnerabilities are not necessarily reported to MITRE after disclosure. Many manufacturers are themselves CNAs and can assign CVE identifiers directly. Other reports are handled by an appropriate CNA or the programme's designated assignment process.
The CVE record provides a common reference for the vulnerability, affected products and supporting information.
MITRE's CVE programme identifies vulnerabilities; it does not itself determine their severity or provide security fixes.
5. How is vulnerability severity calculated?
Vulnerability severity is commonly expressed using the Common Vulnerability Scoring System (CVSS), maintained by FIRST.
CVSS evaluates technical characteristics such as:
Attack vector: Can the vulnerability be exploited remotely or does it require local access?
Attack complexity: How difficult is exploitation?
Privileges required: Does an attacker need an existing account?
User interaction: Must somebody click a link or perform another action?
Impact: Could exploitation compromise confidentiality, integrity or availability?
These characteristics are combined using a published scoring formula to produce a numerical score between 0.0 and 10.0.
For CVSS v3.1, severity ratings are:
CVSS v4.0 introduces additional scoring considerations, but the fundamental objective remains consistent.
A CVSS score describes technical severity, not necessarily the actual risk to a particular organisation. Whether the vulnerability is being actively exploited, whether the affected system is internet-facing and how important the asset is to the business also influence remediation priority.
6. How are vulnerabilities remediated or mitigated?
Once a vulnerability is confirmed, the manufacturer normally develops and releases a security fix.
Remediation addresses the underlying weakness. This might involve installing a software patch, upgrading to a corrected version or applying a vendor-approved configuration change.
Mitigation reduces the likelihood or impact of exploitation without necessarily removing the vulnerability.
Examples include disabling a vulnerable service, restricting network access, applying firewall rules or temporarily removing an affected system from service.
Mitigations can be particularly important when no official fix is available, but they should not automatically be treated as equivalent to a permanent remediation.
For Cyber Essentials, applicable high-risk or critical vendor-approved security fixes must generally be installed within 14 days of release.
7. Why continuous vulnerability management matters
The vulnerability lifecycle does not end when a patch becomes available. Organisations must determine which assets are affected, prioritise action, deploy the appropriate fix and verify that remediation has succeeded.
SecureX7 helps automate this process through asset and software discovery, vulnerability identification, security posture assessment and AI-powered actionable remediation guidance.
By connecting vulnerability information with the systems actually present in an organisation, SecureX7 helps security teams move from simply knowing that vulnerabilities exist to understanding which systems are affected, what matters most and what needs to be done next.
Effective vulnerability management is a continuous cycle: Discover → Assess → Prioritise → Remediate → Verify.
