react-doctor/key-lifecycle-risk

A private key or release credential committed inline to the repo is exposed in git history and must be rotated and revoked.

Validation prompt

Confirm the detector match and collect the required evidence before deciding whether an edit is warranted.

Fires when the file contains a PEM private-key header (-----BEGIN [RSA|EC|OPENSSH|DSA ]PRIVATE KEY-----) followed by a real base64 body of ≥38 chars, or a release-key NAME assigned an inline literal: SSH_PRIVATE_KEY/GPG_PRIVATE_KEY/DEPLOY_KEY/SIGNING_KEY set to a '…' string of ≥16 chars.

Suppress when: the PEM header is a placeholder with no/short body, is preceded within ~40 chars by placeholder/example/sample/dummy/fake, or is a truncated docs sample (a ... ellipsis appears early in the body): all excluded: and a key-shaped env NAME that merely references a secret store (no inline literal value) is not flagged, because a name alone is the correct way to point at a secret.

Evidence boundary

The diagnostic proves only that the detector’s modeled source pattern matched. It does not prove runtime impact, product intent, rendered failure, or that one remediation is correct.

Establish the environment, repository policy, exceptions, and required rendered or runtime evidence before deciding the occurrence.

Record one outcome:

• Confirmed failure: The required evidence establishes the violation.
• Rejected: A documented exception or false-positive predicate applies.
• Needs evidence: Named evidence can still be collected.
• Unavailable: Required evidence cannot be collected in this run.
• Waived with evidence: An authorized, scoped exception applies to an established failure.
• Observation: The review records an optional tradeoff without claiming a defect.

A waiver records its scope, authority, evidence, and review condition. It is not a pass or false positive.

Default severity is registry metadata. Use the occurrence’s JSON severity after repository configuration when ordering real findings.

Fix prompt

Apply this candidate correction only after the required evidence confirms the risk.

Remove the private key or inline credential from source and purge it from git history (for example git filter-repo), then rotate and revoke it now, because the history is already compromised. Load key material at runtime from a secrets manager or CI secret store referenced by name only, prefer short-lived scoped deploy credentials, and document the rotation, expiry, and revocation procedure for any long-lived release or signing key.

Repository-wide copy prompt

Use this repository-wide prompt only after validating each occurrence. For one occurrence, use the guidance above.