[Security/Privacy] Remove raw CDC engine diagnostics from service logs

[seonghobae]

Buyer / acquisition risk

Protected develop@622e5e6c3d534f230c390f10e3832efadfc01825 still contains two ordinary CDC-service logging paths that serialize runtime-controlled diagnostics rather than finite failure classifications:

// CdcService.shutdown()
log.warn("Error while stopping CDC engine during shutdown", e);

// CdcService.maybeMapCanonical(...)
log.debug("Canonical map failed for topic={}: {}", topic, e.toString());

The first records an IOException plus nested cause/stack state from Debezium shutdown. Connector/offset/file/network failures can include filesystem locations, brokers, database coordinates, provider diagnostics or credential-adjacent values. The second writes the raw Kafka/Debezium topic plus RuntimeException.toString(); topic names may encode tenant/schema/table or customer context, while mapper exceptions can echo parser/event diagnostics. Neither is required to preserve CDC correctness.

Status: known_gap on protected develop; source mutation is currently defer_until_trigger because active PR #139 owns CdcService.java and issue #141 owns the stop lifecycle contract. This issue must not race that branch or broaden #139 while it remains independently reviewable.

RCA

• Immediate cause: SLF4J receives the exception object or e.toString() and, for canonical-map failure, the unbounded source topic.
• Technical root cause: CDC correctness/lifecycle classification is coupled to raw third-party diagnostic transport.
• Control failure: existing lifecycle/canonical-map tests verify behavior and counters but do not assert confidentiality of log output.
• Systemic context: adjacent protected CDC diagnostics had the same pattern and are now separately repaired by fix(cdc): prevent replication probe diagnostic leakage #170 (replication-slot status), fix(cdc): keep replicated DDL out of logs #171 (replicated DDL logs), fix(cdc): keep stop failure diagnostics out of API responses #172 (stop HTTP body), and fix(cdc): keep row replica diagnostics out of logs #174 (replica row/parser logs). CdcService is the remaining shared service-level surface discovered in that audit.

Distinct remedies / feasibility

1. Preferred after the CdcService writer lane is clear: replace raw exception/topic transport with stable finite classifications, retaining the existing counters and exception propagation/lifecycle behavior where needed. For example, shutdown can log only a bounded cdc_engine_stop_failed classification; canonical-map failures can increment the existing failure counter and log only a finite canonical_map_failed event.
2. Alternative: if operators need deeper diagnostics, emit them only through a separately designed privileged diagnostic facility with purpose-bound authorization, bounded retention, access auditing and explicit field allowlisting. Do not make ordinary application logs that facility.
3. Reject: regex-only masking of exception messages/topics. Unknown provider/parser formats make masking incomplete and can destroy diagnostic truth while still leaking values.
4. Reject: suppressing the failures entirely. Operators still need finite failure evidence and existing counters/lifecycle outcomes must remain observable.

No new secret, credential, dependency, cross-repository change, or PII masking is needed.

TDD acceptance

When the active CdcService.java writer lane is clear, add fail-first captured-log tests that reach the actual production methods and inject realistic sensitive diagnostics, including a credential-bearing JDBC/offset-store path and a tenant-like topic. Final acceptance must prove:

• shutdown failure still executes the documented lifecycle/failure path but ordinary logs contain no exception message, nested cause text, file path, JDBC URL, credential-like value or stack trace;
• canonical-map failure still increments canonicalMapFailure, remains fail-open for raw Kafka publication as currently designed, and ordinary logs contain no raw topic or exception text;
• stable finite classifications remain available for operator correlation without job IDs, principals, payloads, raw topics, SQL, credentials or exception classes/messages;
• successful paths and existing counters are unchanged;
• 100% owned production statement/branch coverage remains non-vacuous under the [Quality gate] Make JaCoCo fail closed when production class selection is empty #162/fix(coverage): make JaCoCo production gate non-vacuous #164 control;
• beginner-readable Javadoc documents the diagnostic boundary;
• authoritative Security/Threat Model/Operability/Traceability and CDC diagnostic doctoring reconcile this control when docs: establish canonical commercial architecture baseline #149/[Documentation] Close canonical architecture coverage and live traceability gaps #159 is safe;
• exact source, dependency, SBOM, SAST/security, review and protected-merge evidence is regenerated for the final head.

Sequencing

Do not modify CdcService.java while #139 or another live writer owns it. Once the file/branch lane is stable or #139 integrates, re-read protected source and active PR diffs before deciding whether to implement here, fold into a necessary CdcService successor, or close as already superseded by an equivalent exact-source repair. Waiting on this lane never blocks other path-disjoint mightyETL work.