from ssvc.decision_points.exploitation import LATEST
from ssvc.doc_helpers import example_block
print(example_block(LATEST))The intent of this measure is the present state of exploitation of the vulnerability. The intent is not to predict future exploitation but only to acknowledge the current state of affairs. Predictive systems, such as EPSS, could be used to augment this decision or to notify stakeholders of likely changes [@jacobs2021epss].
!!! tip "Gathering Information About Exploitation"
[@householder2020historical] presents a method for searching the GitHub repositories of open-source exploit databases.
This method could be employed to gather information about whether *PoC* is true.
However, part (3) of *PoC* would not be represented in such a search, so more information gathering would be needed.
For part (3), one approach is to construct a mapping of CWE-IDs which
always represent vulnerabilities with well-known methods of exploitation.
We provide a list of possible CWE-IDs for this purpose below.
Gathering information for *active* is a bit harder.
If the vulnerability has a name or public identifier (such as a CVE-ID), a search of news websites, Twitter, the vendor's vulnerability description, and public vulnerability databases for mentions of exploitation is generally adequate.
However, if the organization has the ability to detect exploitation attempts—for instance, through reliable and precise IDS signatures based on a public *PoC*—then detection of exploitation attempts also signals that *active* is the right choice.
Determining which vulnerability a novel piece of malware uses may be time consuming, requiring reverse engineering and a lot of trial and error.
Additionally, capable incident detection and analysis capabilities are required to make reverse engineering possible.
Because most organizations do not conduct these processes fully for most incidents, information about which vulnerabilities are being actively exploited generally comes from public reporting by organizations that do conduct these processes.
As long as those organizations also share detection methods and signatures, the results are usually quickly corroborated by the community.
For these reasons, we assess public reporting by established security community members to be a good information source for *active*; however, one should not assume it is complete.
The description for *none* says that there is no **evidence** of *active* exploitation.
This framing admits that an analyst may not be able to detect or know about every attack.
Acknowledging that *Exploitation* values can change relatively quickly, we recommend conducting these searches frequently: if they can be automated to the organization's satisfaction, perhaps once a day (see also [Guidance on Communicating Results](../../howto/bootstrap/use.md)).
An analyst should feel comfortable selecting *none* if they (or their search scripts) have performed searches in the appropriate places for public *PoC*s and *active* exploitation (as described above) and found *none*.
Acknowledging that *Exploitation*.
The table below lists CWE-IDs that could be used to mark a vulnerability as PoC if the vulnerability is described by the CWE-ID.
!!! example "CWE-295"
For example, [CWE-295 Improper Certificate Validation
](https://cwe.mitre.org/data/definitions/295.html), and its child CWEs,
describe improper validation of TLS certificates. These CWE-IDs could
always be marked as *PoC* since that meets condition (3) in the definition.
{% include-markdown "../../_includes/_scrollable_table.md" heading-offset=1 %}
{{ read_csv('cwe/possible-cwe-with-poc-examples.csv') }}
from ssvc.decision_points.exploitation import VERSIONS
from ssvc.doc_helpers import prior_version, example_block
versions = VERSIONS[:-1]
for version in versions:
print(example_block(version))
print("\n---\n")