cpv-harden-and-redact

Harden and Redact — leak-redaction and safeguard-hardening catalog

Overview

This catalog rewrites two classes of security finding so the threat itself disappears — not the finding. A leak is removed (or the value moved to a runtime read), and a missing safeguard is implemented, both verified by the same unchanged scanner at the same --strict level.

The one rule: remove the leak / add the safeguard, or flag it — never weaken the scan. Never mute a rule, never add an ignore/skip flag, never relax --strict, never edit a CPV validator. The only acceptable "clear" is the scanner no longer firing because the secret is gone or because the safeguard now exists — not because it was silenced.

This is the leaks-and-hardening counterpart to the cpv-devitalize-threats catalog. Devitalize neutralizes the executable shape of a shipped threat; cpv-harden-and-redact removes exposed data and adds missing defenses. A plugin can need both — the two are complementary, not overlapping (full bucket map in the parent spec; the live report's rule_id decides which catalog a finding belongs to).

Prerequisites

• A security report from validate_security.py + native skillaudit (the cpv-plugin-leaks-preventer-agent agent produces it via the isolation launcher).
• The flagged file open, with each finding's file:line + rule_id + matched span + bucket (B leak / C safeguard / both).

The decision gate (per finding)

Run these questions in order before any edit. The gate decides redact vs runtime-read vs harden vs flag.

• Q1 — is this a SECRET (leak) or a MISSING SAFEGUARD? A leak is a credential, token, key, webhook, or private path committed in source. A missing safeguard is an absent defense on a path that processes data — TLS off, no SSRF guard, an unsafe parser, no input sanitization, no prompt-injection pre-scan.
• Q2 (leak) — is the secret needed at runtime? No → redact to an obvious placeholder (the value was never needed). Yes → redact the literal AND replace it with a runtime read from the environment (env var / exported shell var / GitHub repo+Actions variable / OS keychain), with a fail-fast when unset.
• Q2 (safeguard) — can the safeguard be added without changing behavior? Yes → apply the least-invasive safe form (safe parser, sanitizer, containment, correct launch params). No / ambiguous → FLAG, do not rewrite.
• Q3 (leak reverse-case) — is the secret already committed AND live? If an external scanner verifies the value as live, redacting the working-tree file is NOT enough — the value is already in git history. FLAG it: rotate the credential and purge git history. Do not silently edit a file to hide a real leak.