18.1 What Vulnerabilities, Bugs, and CVEs Are
A Bug Only Becomes a Vulnerability at a Trust Boundary
A bug is any deviation between what code does and what its author intended. Most are harmless: a button that overlaps text, a rounding error in a report. A vulnerability is a bug that an attacker can steer across a trust boundary to break confidentiality, integrity, or availability. The same memory-safety defect is a crash in a single-user toy and a remote code execution flaw in a parser that accepts untrusted network bytes. Common families repeat constantly: out-of-bounds writes and reads, use-after-free, integer overflow feeding an allocation size, missing or broken input validation that enables injection, weak or misused cryptography, improper authorization checks, and insecure default configuration. The CWE catalogue names these patterns so teams can classify a finding mechanically instead of writing prose.
How a CVE Identifier Gets Minted
The CVE programme is an index, not a database of fixes. Authorized assigners called CNAs -- vendors, distros, research firms -- reserve identifiers in the form CVE-YYYY-NNNNNN, where the sequence number is padded to at least seven digits, then publish a record containing a short description, a list of affected product and version ranges, and references to advisories and patches. One identifier covers one distinct issue; when the same root cause is disclosed by two parties, duplicates get rejected or superseded, and reserved-but-unpublished entries sit in a pending state. The National Vulnerability Database and vendor advisories enrich the same ID with scores and fix guidance, which is why one CVE number can appear under many slightly different summaries.
Reading a CVSS v3.1 Vector
CVSS v3.1 splits scoring into three groups: Base, fixed by the vendor; Temporal, adjusted for exploit maturity and available workarounds; and Environmental, adjusted for your deployment. The Base group is the one quoted in reports: Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope, and the three impact metrics Confidentiality, Integrity, Availability. Those answers compute a 0 to 10 score banded Low 0.1 to 3.9, Medium 4.0 to 6.9, High 7.0 to 8.9, Critical 9.0 to 10.0. Scope is the tricky metric: it captures whether a flaw in one component impacts a second security authority, which is why container and hypervisor bugs score so high.
Severity Is Not Urgency
CVSS describes what happens if exploitation succeeds, never whether exploitation is plausible in your estate. Two 9.8 Criticals can differ by months of real risk: one unauthenticated over the internet with public exploit code and in-the-wild use, the other requiring local administrative access on an air-gapped box. Track exploitability signals separately -- public proof of concept, functional modules, and inclusion in the CISA Known Exploited Vulnerabilities catalogue -- and combine them with exposure when you schedule work. Severity ranks impact; exposure and evidence rank the queue.
Architecture Diagram
Key Takeaways
- A vulnerability is a bug that crosses a trust boundary; the CWE list names the recurring families.
- CNAs mint CVE-YYYY-NNNNNN identifiers for one distinct issue, with description, affected versions, and references.
- CVSS v3.1 has Base, Temporal, and Environmental groups; the Base metrics are AV, AC, PR, UI, S, and CIA impact.
- Severity bands are Low 0.1-3.9, Medium 4.0-6.9, High 7.0-8.9, Critical 9.0-10.0.
- Score measures impact of success, not likelihood: exploit evidence and exposure set your actual priority.