CompTIA Security+ SY0-801 Threat Intelligence, CVSS and CVE Explained

A threat is anything with the potential to cause harm, a vulnerability is a weakness a threat could exploit, and risk is the combination of how likely a harmful event is and how much damage it would do. The three terms describe different things and must not be swapped: a phishing crew is a threat, a database left with its default administrator password is a vulnerability, and "a likely breach of customer records followed by weeks of cleanup" is a risk.

A useful test: if you can patch it, reconfigure it or encrypt it, it is a vulnerability; if it acts against you, it is a threat. Neither one on its own is risk. A weakness that no threat can reach carries little risk, and a determined attacker facing no exploitable weakness carries little risk too. Two related words also appear in this objective's neighbourhood. A threat vector is the path an attacker uses to reach a target (email, an exposed service, removable media) and is covered in the threat vectors lesson. An exploit is the technique or code that takes advantage of a vulnerability; an exploit chain links several of them.

Because the organization controls its vulnerabilities but not its threats, most security work changes risk by removing or shielding weaknesses. When a clinic replaces the default passwords on its device-management console, the people who try default passwords are still out there; the weakness they relied on is gone.

Likelihood is the probability that a threat will successfully exploit a weakness; impact is the magnitude of harm if it does. Risk assessments estimate the two separately, because they move for different reasons and are reduced by different controls.

Read scenarios factor by factor and ask which one a change actually moves. A cloud storage bucket switched from private to public becomes far more likely to be exposed, yet the files in it, and so the impact, are the same as before. A business-continuity note saying "a two-day outage of the booking site would lose about a week of revenue" describes consequences, not probability, so it is an impact estimate. Often both factors move together, so assess each one separately rather than letting one rating stand in for the other.

Controls fit the same split. Controls that make an attack less likely to succeed (patching, hardening, multifactor authentication, email filtering, user awareness) lower likelihood. Controls that limit the damage once an attack has succeeded lower impact: encrypting a laptop's disk does not stop the laptop being stolen, but it limits what the thief can read, and a tested failover site does not prevent an outage but shortens it.

Insurance is a different kind of response. It transfers the financial cost of an incident to an insurer (risk transference) rather than reducing the harm itself, so it belongs to risk management decisions, not to the list of controls that lower likelihood or impact.

Threat intelligence sources are where an organization gets information about adversaries, their infrastructure and their techniques, and the right source depends on the question being asked. No single source answers everything, so mature programs combine several.

Two other terms appear around these. Human intelligence (HUMINT) is gathered from people (interviews, contacts, informants) rather than from published material. A threat map is a visual, often real-time display of attack activity around the world, used mainly for awareness and presentations.

The sources differ mainly in who produces the information and who can see it: anyone can read open-source material, a contract buys commercial intelligence, membership opens a sharing community, government advisories are published for all, and only the organization itself holds its internal telemetry. Asking those two questions about a source usually classifies it.

A threat feed is a continuously updated, machine-readable stream of indicators of compromise, such as malicious IP addresses, domains, URLs and file hashes, designed to be ingested automatically by a SIEM, firewall, proxy or endpoint tool. Feeds come from commercial vendors, open-source projects, ISACs and governments; what they share is the delivery model, not the source.

Two OASIS standards make feeds interoperable:

• STIX (Structured Threat Information Expression) is the content language. STIX 2.1 is JSON-based and describes indicators, attack patterns, malware, threat actors, campaigns and the relationships between them.
• TAXII (Trusted Automated Exchange of Intelligence Information) is the transport. TAXII 2.1 is a client-server API over HTTPS for publishing and retrieving threat intelligence, usually STIX.

In short: STIX is what is said, TAXII is how it is sent. The two are separate standards that are commonly paired, and STIX content can also be shared as files by other means.

What makes a feed good

IP addresses and domains age quickly because attackers reuse cheap, shared infrastructure, so volume is not a virtue: blocking every entry from a large, low-confidence feed causes outages. Verify indicators and age out stale ones before automating blocks.

The threat intelligence life cycle is the repeating process that turns questions into usable intelligence: planning and direction, collection, processing, analysis, dissemination and feedback. Each phase depends on the one before it, so a failure in one shows up as a symptom later.

1. Planning and direction (requirements). Decide what questions the program must answer and for whom: which threats, assets and decisions matter.
2. Collection. Gather raw data from the chosen sources: feeds, logs, packet captures, OSINT, ISAC reports, forums.
3. Processing. Turn raw data into a usable form: normalize formats, translate, decrypt, filter and de-duplicate.
4. Analysis (and production). Interpret the processed data to reach findings and produce intelligence products, such as reports and indicator lists.
5. Dissemination. Deliver finished intelligence to the people who need it, in a format and at a time they can act on.
6. Feedback. Consumers evaluate the intelligence they received and report whether it met their needs, which shapes the next round of requirements.

To diagnose a struggling program, ask where the chain broke: unclear questions at the start make everything downstream look unhelpful, and sound analysis is wasted if it never reaches the people who act on it in a usable form and in time.

Common Vulnerabilities and Exposures (CVE) is the program that gives each publicly disclosed vulnerability a unique identifier, such as CVE-2024-12345, so that vendors, scanners, advisories and defenders can all refer to the same flaw. A CVE ID is a name, not a score and not a prediction.

• Format: CVE-year-sequence number, where the sequence has four or more digits. The year is the year the ID was reserved or the year the vulnerability was made public, not necessarily when the flaw was found.
• CVE Numbering Authorities (CNAs) are organizations authorized by the CVE Program to assign IDs and publish CVE Records within an agreed scope. Many large software vendors are CNAs for their own products; others request IDs from a CNA whose scope covers them. The CVE Board oversees the program's strategy and policy.
• Authorized Data Publishers (ADPs), such as CISA, add enrichment to existing CVE Records.
• The National Vulnerability Database (NVD), run by NIST, separately enriches CVE Records with CVSS scores, CWE classifications and CPE data (which product configurations are affected). NVD analysis is a separate step that can run behind publication, so the CVE Record on cve.org is the authoritative source for a newly published ID, with scores and product data sometimes following later.

Because a CVE ID refers to one specific vulnerability, it works as a common key across products: a vendor bulletin, a SIEM alert, a patch note and a change ticket that quote the same ID are all talking about the same flaw. Flaws in unpublished in-house code usually never receive a CVE.

Vulnerability types are classes of weakness, such as injection, buffer overflow or missing authorization, and the standard catalog of them is MITRE's Common Weakness Enumeration (CWE): a community-developed list of software and hardware weakness types. CVE names individual flaws; CWE names the kind of mistake behind them.

The relationship is many-to-one: a buffer overflow in a router's firmware and another in a media player are separate vulnerabilities with their own CVE IDs, yet both map to the classic buffer-overflow weakness, CWE-120. Because a CWE describes the cause of a flaw, it supports root-cause work such as secure-coding standards and reusable libraries; a CVSS score describes how severe a flaw is and says nothing about what kind of mistake produced it.

The individual vulnerability types themselves (application, memory, operating-system, web, hardware, cloud, supply-chain and so on) and attack surfaces are taught in the lesson on types of vulnerabilities and attack surfaces; this objective is about how vulnerabilities are characterized, named and scored.

The Common Vulnerability Scoring System (CVSS), maintained by FIRST, is the vendor-neutral standard for expressing a vulnerability's severity as a number from 0.0 to 10.0, calculated from standardized metrics and recorded as a vector string. Version 3.1 and version 4.0 are both in wide use. The qualitative ratings are the same in both:

Each band starts on a whole number and ends at .9, so a whole-number score such as 4.0 or 7.0 starts the higher band.

Exploitability base metrics

Delivery method does not set the attack vector; where the vulnerable component is reached does. When a flaw sits in software that processes a file locally after someone opens it, the CVSS v3.1 specification scores the attack vector as Local and user interaction as Required, even if the file arrived over a network. A booby-trapped PDF downloaded from a website and opened in a vulnerable reader is scored that way. Privileges Required is judged separately, by what access the attacker needs on the target before exploiting it.

Impact base metrics

Impact is scored for confidentiality, integrity and availability, each None/Low/High. CVSS v3.1 adds Scope (whether the impact crosses into another security authority). CVSS v4.0 drops Scope and instead scores the vulnerable system (VC/VI/VA) and subsequent systems (SC/SI/SA) separately, and adds Attack Requirements (AT) for deployment conditions the attack depends on.

A vector string records every value, for example CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. Because v4.0 changed the metrics and the scoring method, the same flaw can have different v3.1 and v4.0 base scores. Always check which version a score uses before comparing.

CVSS separates metrics into groups so that a vulnerability's intrinsic severity, its current exploitation status and an organization's own context are scored separately. The group names differ between versions:

Base metrics describe the flaw itself and stay the same over time and across organizations; anything about the current state of exploitation belongs in Temporal (v3.1) or Threat (v4.0). An organization adjusts a score for its own assets in the Environmental group, for example by setting a high Integrity Requirement for a payment-processing system, or by using modified base metrics to reflect a compensating control. Supplemental metrics record extra characteristics, such as how much effort a fix takes or how urgently the provider says to act, without changing the number.

CVSS v4.0 labels each score by the groups used to produce it:

• CVSS-B: Base metrics only (what vendors and the NVD usually publish).
• CVSS-BT: Base plus Threat.
• CVSS-BE: Base plus Environmental.
• CVSS-BTE: Base plus Threat plus Environmental.

Check the label before comparing two v4.0 numbers. A CVSS-B and a CVSS-BT score for the same flaw can legitimately differ, because only the second includes current exploit maturity.

Vulnerability prioritization is deciding which flaws to fix first, and it must weigh risk, not just severity: CVSS measures how severe a flaw is in the abstract, while risk depends on whether it is being exploited, how exposed the affected system is and how valuable the asset is.

CISA KEV lists CVEs with reliable evidence of active exploitation and clear remediation guidance; it is a list of facts, so it cannot rank the many CVEs that have not yet been exploited. EPSS is a forecast: a probability from 0 to 1 (often shown with a percentile) that helps rank hundreds of findings with similar CVSS scores. The CVSS v4.0 Threat group records current exploit maturity, which is what is known now, not a forward-looking probability.

Put together, these inputs can reorder a list sorted by score. A Medium-rated flaw in an internet-facing remote-access gateway with a high EPSS probability can deserve attention ahead of a Critical-rated flaw in a library that no reachable service loads. The operational process of scanning, validating, remediating and reporting is covered under vulnerability management later in the exam.