[Product/Security Gap] Replace direct ETL HTTP Basic trust boundary

[seonghobae]

Buyer-visible security gap

Protected develop@622e5e6c3d534f230c390f10e3832efadfc01825 configures etl-service with .requestMatchers("/api/**").authenticated() and httpBasic(...). PR #157 correctly models that shipped boundary in OpenAPI, and GitHub Advanced Security/Semgrep raises yaml.openapi.security.use-of-basic-authentication.use-of-basic-authentication on the truthful basic scheme. This is not an OpenAPI-documentation bug: changing or suppressing the contract would hide the current runtime authentication mechanism rather than remove the weak-authentication finding.

Gateway JWT hardening in #140/#142 is a different trust boundary. A production acquisition review still needs an explicit answer for direct or east-west access to etl-service: whether it is independently authenticated, reachable only through an authenticated gateway/private network, or protected by a service identity mechanism. The current Basic boundary must not be left implicit merely because the edge gateway is being modernized.

Fresh gate evidence — 2026-08-09

PR #157's live source ref is aa558f25363bfb833e49ed79b49cfdbea39c8eea on protected base 622e5e6c3d534f230c390f10e3832efadfc01825; its body still names historical predecessor head d43c257c044ed3006980317bd8932cb5b22a32ab, so body gate claims are stale until reconciled by its active writer.

Current workflows for the live #157 source head show:

• CI 31315084630: success;
• Dependency Review 31315084615: success;
• CycloneDX SBOM 31315084635: success;
• Security Scan 31315084626: success;
• SAST Semgrep 31315084629: failure.

Semgrep job 93248924149 completed its engine scan successfully and found exactly one unsuppressed blocking result after three explicitly suppressed findings were removed. The hard finding is:

yaml.openapi.security.use-of-basic-authentication.use-of-basic-authentication
path=contracts/openapi/mightyetl.yaml
line=266
message=Basic authentication is considered weak and should be avoided.

The SAST job checked out synthetic PR merge 95579e529a677fe70209cb6abd56f86bc628a89d (Merge aa558f25363bfb833e49ed79b49cfdbea39c8eea into 622e5e6c3d534f230c390f10e3832efadfc01825) rather than the literal source head. That source-identity limitation remains separate from the semantic finding: the merged tree contains a truthful Basic-auth OpenAPI scheme because protected etl-service itself still uses Basic.

This is therefore a valid product/security finding, not an engine failure and not a false-positive documentation mismatch. Re-running the unchanged #157 tree cannot remove it. Suppressing the rule or changing the OpenAPI scheme without changing runtime authentication is rejected because it would make contract evidence less truthful.

PR #157's source branch is currently under another active writer and has moved during this commercial-loop invocation. Source/ref mutation from this loop is branch-locally frozen for the remainder of the invocation; that does not prevent this issue from maintaining the RCA and acceptance boundary.

Protected deployment/runtime revalidation

The architecture questions above are now partially answered from protected source rather than left hypothetical:

1. Direct reachability exists in the shipped default Docker stack. docker-compose.yml publishes etl-service as host port 8000:8000 independently of gateway port 8080:8080. Therefore a claim that ETL is gateway-only/private is false for the current default deployment topology. The same Compose stack waits for ETL before starting the gateway but does not make ETL network-internal-only.
2. ETL independently authenticates /api/**. Protected etl-service/src/main/java/com/xtrmetl/etl/security/SecurityConfig.java registers a servlet SecurityFilterChain, disables CSRF, requires authentication for /api/**, permits other paths, and enables HTTP Basic. That is a real runtime service boundary, not merely prose or an unregistered helper.
3. Gateway routing does not establish downstream service identity. Protected zuul-gateway/src/main/resources/application.yml routes /etl/** to lb://etl-service with only StripPrefix=1. Repository search found no Authorization removal/replacement, token-relay, service credential, mTLS, or downstream identity filter. Thus the protected gateway configuration provides routing only; it does not prove a separate gateway→ETL authentication principal or authorize blindly trusting a forwarded caller header.
4. Independent JWT Resource Server support is not currently declared by ETL. Protected etl-service/pom.xml has spring-boot-starter-security but no spring-boot-starter-oauth2-resource-server. Adding a maintained JWT Resource Server therefore requires a dependency/POM change in addition to the security-chain change; it cannot truthfully be implemented as configuration-only work.

These facts materially narrow the remediation set. A gateway-only external trust outcome is rejected for the current default product topology unless a separately reviewed deployment change first removes direct ETL exposure and introduces a real downstream service-identity/authorization control. The preferred target architecture is therefore independent fail-closed ETL service authentication, with gateway and standalone callers satisfying the same service boundary. OAuth 2.0 Resource Server JWT is the leading bounded option because #142 already establishes the organization-local Spring Security/JWT pattern, but issuer/JWK/audience ownership and backward-compatible standalone rollout still require an explicit source-backed contract rather than invented deployment secrets.

Mutation feasibility this invocation

A new ETL Resource Server implementation would necessarily modify etl-service/pom.xml. Active PR #164 is concurrently modifying that same POM to repair the non-vacuous JaCoCo gate and its branch has moved under another writer during this invocation. Opening a second path-overlapping direct-develop authentication implementation now would create avoidable integration conflict and could cause either branch to validate against a stale quality-gate configuration.

Classification for source mutation therefore remains defer_until_trigger, with trigger = #164 branch stabilizes/integrates or otherwise proves a non-overlapping exact POM boundary. This is not passive waiting: the architecture decision has been narrowed from four plausible outcomes to one preferred production class of solution and the invalid gateway-only assumption has been disproved with protected deployment evidence.

RCA

• Immediate symptom: machine-readable documentation of the actual ETL service security scheme triggers the Basic-auth security rule.
• Technical cause: the service itself still uses HTTP Basic as its authentication mechanism.
• Control failure: current architecture does not make the gateway-to-service credential propagation / service-authentication contract explicit enough to prove that Basic is an intentionally bounded compatibility mechanism rather than a permanent production identity boundary.
• Deployment cause: the default Compose product exposes ETL directly on host port 8000, so the product cannot rely on an undocumented gateway-only perimeter to make Basic acceptable.
• Detection-control success: Semgrep is correctly preventing a truthful weak-authentication contract from being reclassified as acquisition-ready merely because functional/API tests pass.

Required architecture decision before mutation

The protected evidence now fixes several inputs. The remaining implementation contract must determine:

1. the exact standalone secure mode and configuration precedence when no gateway is present;
2. issuer/JWK/audience/algorithm requirements and startup behavior when trust metadata is absent/unavailable;
3. whether a bounded deprecated Basic compatibility mode is required for upgrades and, if so, how it is explicitly disabled by secure production defaults and retired;
4. whether the gateway preserves the original bearer token for independent ETL validation or obtains a distinct downstream service credential in a later service-identity slice;
5. migration/rollback behavior for deployments currently using Basic credentials;
6. whether direct host publication of ETL remains a supported deployment profile after independent JWT authentication, or is separately tightened as defense in depth.

Do not invent an identity provider, client secret, certificate authority, PAT, or repository secret to complete this decision.

Bounded remediation outcomes

Classify against actual deployment requirements before implementation:

• preferred — productionize independent service authentication: replace Basic with a maintained fail-closed resource-server or service-identity mechanism and deterministic tests; current deployment evidence makes this the defensible product direction;
• rejected on current protected topology — gateway-only external trust: direct port 8000 publication and absence of a downstream identity filter disprove this as a description of today's product. Reconsider only with a separately tested deployment/network + downstream authority change;
• possible migration aid only — temporary compatibility mode: permitted only if explicitly named, disabled by secure production defaults where practical, time/owner bounded, and never described as the target production control;
• reject: hiding basic in OpenAPI, nosemgrep/rule suppression without a reviewed exception control, plaintext credential forwarding, or treating fix(gateway): replace placeholder token handling with JWT resource server #142 gateway JWT as automatic proof that the downstream service boundary is solved.

TDD / security acceptance

Before production changes, add tests that fail on the actual registered service security chain. The completed design must prove, as applicable:

• protected ETL routes fail closed without valid service authentication;
• malformed/invalid credentials cannot reach controllers;
• the historical Basic path is absent in secure production mode;
• standalone and gateway-backed deployment modes have explicit deterministic behavior;
• direct port-8000 access, while supported, satisfies the same independent authentication policy as gateway-routed access;
• credential/token/certificate material is not logged or emitted in metrics;
• principal scope used by idempotency and durable-job ownership remains stable and cannot be spoofed by an untrusted forwarded header;
• gateway-to-service identity propagation cannot turn external caller input directly into an authenticated downstream principal;
• failure, key/certificate rotation, clock-skew, issuer/audience or mTLS trust failures are handled according to the chosen mechanism;
• exact owned production statement/branch coverage and beginner-readable public Javadoc remain complete under the non-vacuous [Quality gate] Make JaCoCo fail closed when production class selection is empty #162/fix(coverage): make JaCoCo production gate non-vacuous #164 control;
• OpenAPI is updated to the integrated mechanism and the current SAST finding disappears because the runtime boundary changed, not because the contract was falsified or the rule was weakened.

Documentation / acquisition evidence

Update the canonical Security/Threat Model/Architecture/API/deployment/operability/traceability material with the final external-vs-east-west trust boundary, principal propagation, network assumptions, secrets/certificate provenance, rollout/rollback, telemetry, and residual risks. Keep #157 truthful while this issue is open: its Basic scheme represents protected-develop reality and should remain a known gap rather than being rewritten to advertise an unshipped mechanism.

The eventual accepted proof must include a fresh SAST run after the runtime and machine-readable contract move together. Old #157 failed/synthetic evidence, #142 gateway JWT evidence, and any predecessor-head review do not transfer.

Relationship to existing work

• [Product/Security Gap] Replace placeholder gateway token handling with standards-based JWT enforcement #140/fix(gateway): replace placeholder token handling with JWT resource server #142: gateway edge JWT enforcement; complementary, not a substitute for this downstream boundary.
• feat(api): add machine-readable HTTP and CDC contracts #157/[Interoperability] Add machine-readable OpenAPI and AsyncAPI contracts #152: machine-readable contract; must describe current protected truth and later move with the integrated service-authentication change.
• docs: establish canonical commercial architecture baseline #149/[Documentation] Close canonical architecture coverage and live traceability gaps #159: canonical architecture and traceability must record this as planned/known_gap until protected integration.
• [Quality gate] Make JaCoCo fail closed when production class selection is empty #162/fix(coverage): make JaCoCo production gate non-vacuous #164: independent non-vacuous coverage control; the authentication implementation necessarily touches the same ETL POM dependency/quality boundary, so do not race fix(coverage): make JaCoCo production gate non-vacuous #164's active writer.

Do not resolve the current #157 security finding merely because this issue exists; resolution requires an implemented/accepted control or a formally justified security exception tied to an explicit architecture decision.