Security hardening: SAST findings — JWT lifetime validation disabled; connector image runs as root

[SharedQA]

Summary

The SAST gate (semgrep p/default, added in #1317) surfaces pre-existing security-hardening findings. The gate runs report-only for now so it doesn't block all merges on this backlog; this issue tracks fixing the findings so the gate can flip to blocking (--error).

Findings

1. JWT lifetime validation disabled — src/backend/services/identity/src/Insight.Identity.Api/Program.cs:156

   ValidateLifetime = false,
   

   With ValidateLifetime = false, expired JWTs are accepted. Confirm this is intentional (e.g. lifetime enforced upstream at the gateway); if not, set it to true (line 135 has the commented-out true) or document why it's off.

2. Container runs as root — src/ingestion/tools/declarative-connector/Dockerfile
   No USER directive; the image ends on ENTRYPOINT as root. Add a non-root USER before the entrypoint.

(Additional lower-severity items may appear in the full semgrep --config p/default run; this issue covers the blocking ones.)

Acceptance

• Each finding fixed or explicitly waived with a rationale (.semgrepignore / inline # nosemgrep with justification).
• security-gates.yml sast step re-enabled with --error (blocking) once the baseline is clean.

[SharedQA]

Re-validated against merged main (08f0527, after #1314 "Migrate to gears"). Neither finding is resolved by that merge — #1314 only touched the Rust backend (api-gateway, analytics-api, oidc-authn-plugin), not the .NET identity service.

Finding 1 (JWT lifetime). identity/.../Program.cs:156 still has ValidateLifetime = false. Reading the surrounding block (lines 118–138), this is intentional and documented: the identity service treats the JWT as a context-bearing envelope, enforces no auth itself, and defers full validation to TODO(#346) once the IdP authority is pinned per environment.

What changed with #1314 is the upstream side this issue asked us to confirm: the new gears OIDC plugin on the api-gateway now validates signature/iss/aud/exp (require_exp: true + validate_claims in oidc-authn-plugin/src/domain/service.rs). So the "enforced upstream at the gateway" assumption now holds. The residual gap is identity being reached directly (bypassing the gateway) — defense-in-depth, tracked by #346 / the swap-in block in Program.cs.

Finding 2 (root container). src/ingestion/tools/declarative-connector/Dockerfile still has no USER before its ENTRYPOINT — unchanged. trivy confirms it (DS-0002).

Keeping this open. Suggest reframing finding 1 from "disabled = bug" to "confirm gateway is the sole ingress + flip the identity validation block under #346", since the gateway validation now exists.