Brad Larsen
288a8a8643
CodeQL / Analyze (go) (push) Waiting to run
Scan for secrets / test (push) Waiting to run
Test / test-community (push) Waiting to run
Test / test (push) Waiting to run
- wrap text for plain-text legibility - fix heading nesting - expand discussion of SSRF policy and submission guidelines for clarity
69 lines
2.7 KiB
Markdown
69 lines
2.7 KiB
Markdown
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
|
|
|
|
As part of its intended operation, TruffleHog makes network requests to
|
|
upstream secret providers in order to verify liveness of each secret.
|
|
|
|
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 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?
|