docs: threat-intelligence (EPSS/KEV) fields are editable on the Add/Edit Finding form

docs/content/asset_modelling/engagements_tests/PRO__findings.md

@@ -77,10 +77,11 @@ Mitigation policies can be found and edited in the sidebar under **Configuration
     - Unlike the Unique ID From Tool, this identifier is not unique to an individual Finding and may appear on many Findings that match the same detection rule. 
     - Unlike Vulnerability IDs, these identifiers are specific to the reporting tool and are not publicly standardized.
         - Example: `semgrep.rule.lang.security.sql-injection`
-- **EPSS Score / Percentile**: ESS score and percentile for the CVE.
+- **EPSS Score / Percentile**: EPSS score and percentile for the CVE.
 - **Known Exploited**: Whether there is confirmation that the vulnerability has been exploited. 
 - **Ransomware Used**: Whether ransomware was involved in the exploitation of the vulnerability. 
 - **KEV Date**: The date the Finding was added to the KEV catalog.
+    - The EPSS and KEV values are maintained by the [EPSS / KEV sync](/triage_findings/finding_scoring/epss_kev/). They can also be set by hand in the **Threat Intelligence** panel of the Add and Edit Finding forms; on a Finding that references a CVE, the next sync overwrites what was entered.
 - **Found By**: The type of tool that identified the vulnerability.
 - **CVSSv3 and CVSSv4 Vector and Score**: The CVSS3 and CVSS4 vector and score of the selected Finding.
 - **Integrator Tickets**: Third-party issue tracker ticket numbers associated with the Finding. 

docs/content/triage_findings/finding_scoring/epss_kev.md

@@ -135,7 +135,7 @@ This flows automatically — priority is recomputed for exactly the Findings upd
 
 Once Findings are enriched, the EPSS and KEV values are available throughout the Pro UI:
 
-- **On the Finding** — EPSS score, EPSS percentile, Known Exploited, Ransomware Used, and KEV Date all display on the Finding detail.
+- **On the Finding** — EPSS score, EPSS percentile, Known Exploited, Ransomware Used, and KEV Date all display on the Finding detail. They can also be set by hand in the **Threat Intelligence** panel of the Add and Edit Finding forms, which matters for a Finding that has no CVE and is therefore never enriched. On a Finding that does reference a CVE, the next sync overwrites hand-entered values; see [Editing Findings](/triage_findings/findings_workflows/editing_findings/#edit-finding-form-fields).
 - **Sorting** — Finding tables can be ordered by EPSS score / percentile to surface the most likely-to-be-exploited Findings first.
 - **Filtering** — the Findings list offers **Known Exploited** and **Ransomware Used** filters, so you can build views or reports scoped to confirmed real-world-exploited vulnerabilities.
 

docs/content/triage_findings/findings_workflows/create_findings_manually.md

@@ -14,3 +14,5 @@ Normally, most of the Findings in your environment will be imported from other s
 2. This opens the **New Finding** form, which you can fill out with any relevant information surrounding your Finding. You will need to assign this Finding to a previously created Test in DefectDojo.
 
 ![image](images/Creating_Findings_Manually_2.png)
+
+Most of the form sits under the collapsible **Optional Fields** panel. That includes a **Threat Intelligence** panel for the EPSS and CISA KEV values, which are otherwise only filled in by the [EPSS / KEV sync](/triage_findings/finding_scoring/epss_kev/) for Findings that reference a CVE. Setting them here lets a manually created Finding without a CVE carry exploit evidence for prioritization; see [Editing Findings](/triage_findings/findings_workflows/editing_findings/#edit-finding-form-fields) for how the sync treats hand-entered values.

docs/content/triage_findings/findings_workflows/editing_findings.md

@@ -35,7 +35,9 @@ This will open the **Edit Finding** form, where you can edit the metadata, chang
 ​
 * **Active / Verified** are the primary Finding statuses used by a tool. Active Findings are Findings that are currently active in your network and have been reported by a tool. Verified means that this Finding has been confirmed to exist by a team member.  
 ​
-* **SAST / DAST** are labels used to organize your Findings into the context they were discovered in. Generally, this label is populated based on the scanning tool used, but you can adjust this to a more accurate level (for example, if the Finding was found by both a SAST and a DAST tool).
+* **SAST / DAST** are labels used to organize your Findings into the context they were discovered in. Generally, this label is populated based on the scanning tool used, but you can adjust this to a more accurate level (for example, if the Finding was found by both a SAST and a DAST tool).  
+​
+* **Threat Intelligence** (a collapsed panel under **Optional Fields**) holds the EPSS Score, EPSS Percentile, Known Exploited, Used in Ransomware and KEV Date Added values. These are normally written by the [EPSS / KEV sync](/triage_findings/finding_scoring/epss_kev/), which runs nightly, after each import, and on demand from the Vulnerability Explorer. You can set them by hand, but treat a hand-entered value as provisional on any Finding that references a CVE: the next sync replaces it with the feed's values, and clears the KEV fields when none of the Finding's CVEs are in the CISA catalog. A Finding without a CVE is never enriched, so it keeps whatever you enter. Hand-set values feed the priority and risk calculation exactly as synced values do. A Rules Engine rule that should react to a hand-set flag needs a condition on **KEV: Known Exploited**; the FedRAMP "route unrated findings for impact review" template keys on **Exploit Maturity**, which comes from the threat-intelligence feed and is not affected by these fields.
 
 ### Editing the Mitigated Date and Mitigated By