Clarify security policy (#5295)

- wrap text for plain-text legibility
- fix heading nesting
- expand discussion of SSRF policy and submission guidelines for clarity

SECURITY.md

@@ -1,22 +1,68 @@
-Please report security issues to security@trufflesec.com and include `trufflehog` in the subject line. If your vulnerability involves SSRF or outbound requests, please see our policy for that specific class of vulnerability below.
+Please report security issues to security@trufflesec.com and include
+`trufflehog` in the subject line. If your vulnerability involves SSRF or
+outbound requests, please see our policy for that specific class of
+vulnerability below.
+
 
 ## Blind SSRF & Outbound Request Policy
-Truffle Security treats blind SSRF (the ability to induce outbound requests without data retrieval) as a hardening opportunity rather than a vulnerability. We do not issue CVEs or formal advisories for reports showing outbound interactions unless they demonstrate a tangible security risk to users.
 
-#### Policy Criteria
-**Vulnerability (CVE Issued):** We will issue a CVE if a researcher demonstrates a clear exploit chain. For example:
-- Credential Exfiltration: Forcing TruffleHog to send third-party secrets (discovered during a scan) or the host's own environment credentials (e.g., IAM metadata) to an attacker-controlled endpoint.
-- Internal Exploitation: Using a blind request to trigger secondary vulnerabilities (e.g. RCE) on restricted internal services configured for defense-in-depth.
+As part of its intended operation, TruffleHog makes network requests to
+upstream secret providers in order to verify liveness of each secret.
 
-**Hardening (No CVE):** We generally will not issue a CVE for:
-- Reflected Payloads: Inducing a request to an attacker-controlled URL by inserting a URL into the scan input (i.e., the attacker receiving data back that they already had access to).
-- Basic Outbound Control: Demonstrating control over the request URL, Path, or Body, without demonstrating a path to credential leakage or internal system exploitation.
-- Service Probing: Simple open/closed port verification or basic interaction with internal services (e.g., triggering a GET request to a local web server) without a demonstrated compromise of data or system integrity.
-- Secondary Vulnerability Dependencies: Where the impact relies entirely on the pre-existing lack of authentication, misconfiguration, or known vulnerabilities of a third-party internal service.
+Truffle Security treats blind SSRF (i.e., the ability to induce outbound
+requests without data retrieval) as a hardening opportunity rather than
+a vulnerability.
+
+We do not issue CVEs or formal advisories for reports showing outbound
+interactions unless they demonstrate a tangible security risk to users.
+
+### Policy Criteria
+
+#### Vulnerability (CVE Issued):
+We will issue a CVE if a researcher demonstrates a clear exploit chain.
+For example:
+
+- Credential Exfiltration: Forcing TruffleHog to send third-party
+  secrets (discovered during a scan) or the host's own environment
+  credentials (e.g., IAM metadata) to an attacker-controlled endpoint.
+
+- Internal Exploitation: Using a blind request to trigger secondary
+  vulnerabilities (e.g. RCE) on restricted internal services configured
+  for defense-in-depth.
+
+#### Hardening Opportunity (No CVE):
+We will not issue a CVE for:
+
+- **Reflected Payloads:** Inducing a request to an attacker-controlled endpoint
+  that requires the attacker to have write access to the scan input (i.e., the
+  attacker receiving data back that they already had access to).
+
+- **Basic Outbound Control:** Demonstrating control over the request
+  URL, Path, or Body, without demonstrating a path to credential leakage
+  or internal system exploitation.
+
+- **Service Probing:** Simple open/closed port verification or basic
+  interaction with internal services (e.g., triggering a GET request to
+  a local web server) without a demonstrated compromise of data or
+  system integrity.
+
+- **Secondary Vulnerability Dependencies:** Where the impact relies
+  entirely on the pre-existing lack of authentication, misconfiguration,
+  or known vulnerabilities of a third-party internal service.
 
 ### Submission Guidelines
+
 To help us evaluate your report, please specify:
-- Level of Control: Which request components are controllable (Method, Host, Path, Headers, or Body)?
-- Secret Context: Can you prove that a legitimate secret (not the attacker's payload) is attached to or contained within the outbound request?
-- Target Reach: Can the request reach restricted internal IPs (e.g., 127.0.0.1 or 169.254.169.254)?
-- Demonstrated Impact: What is the specific risk to a user or environment beyond a simple DNS/HTTP interaction?
+
+- **Level of Control:** Which request components are controllable (Method,
+  Host, Path, Headers, or Body)?
+
+- **Secret Context:** Can you prove that a legitimate secret that the attacker
+  did not already have access to (i.e., not the attacker's payload) is attached
+  to or contained within the outbound request?
+
+- **Target Reach:** Can the request reach restricted internal IPs (e.g.,
+  127.0.0.1 or 169.254.169.254)?
+
+- **Demonstrated Impact:** What is the specific risk to a user or environment
+  beyond a simple DNS/HTTP interaction?