Threat model: auth × bind matrix

[nalyk]

Background

PR #58 closed GHSA-8jr5-6gvj-rfpf — CWE-306, unauthenticated network exposure of the GitLab tool surface. The post-mortem produced an auth × bind matrix in SECURITY.md, enforced at three layers: the runtime startup gate (src/transport.ts:60 + src/index.ts:169-178), the chart's auth-validation.yaml fail-loud guard, and the CI negative tests added in #56.

The matrix lives in SECURITY.md and isn't restated here. This thread is for the next-iteration questions where operator and security-researcher perspective adds the most value, plus one discipline note from this round of CI tests that's worth baking in.

What's locked in across deployment surfaces

Surface	AUTH_MODE default	HOST default	Transport default	Why
.env.example (local dev)	pat	127.0.0.1	both off → stdio	safest local default; PAT only on loopback
helm install (chart values.yaml)	oauth	0.0.0.0	USE_SSE=true	the K8s Service is cluster-reachable, so PAT is refused at install time
docker run (Dockerfile ENV)	runtime default pat	runtime default 127.0.0.1	USE_SSE=true (#57)	image stays runnable out-of-box; loopback bind matches PAT

Every default combination either ships safe or refuses to start.

Three open questions

Modernize to Streamable HTTP as the default transport

Chart and Dockerfile both default USE_SSE=true. Streamable HTTP is the spec-approved successor; SSE is the legacy MCP transport. @ecthelion77 raised this in #57 as a future modernization — flipping chart/values.yaml to USE_SSE=false, USE_STREAMABLE_HTTP=true and updating the Dockerfile ENV to match. The piece I can't resolve alone is client compatibility — whether any current Claude Desktop / Cursor / Zed / VS Code build still needs SSE specifically, or whether Streamable HTTP is a clean cutover today. Operator data on this is the missing input.

Localhost name-resolution caveat

isLoopbackHost in src/transport.ts:28-40 accepts the literal string localhost (case-insensitive) but doesn't resolve through DNS or /etc/hosts. Commit 0baa230 flagged this asymmetry in SECURITY.md and recommended the IP literal for hardening configs. The open call is whether the safety guard should reject localhost entirely and require the IP literal. Stricter is more rigorous against hosts-file mistakes downstream; looser keeps any operator script that uses the hostname working. Lower-priority than question 1, but worth a decision before the next minor.

Substring-anchoring discipline for future chart CI tests

#56 added six negative tests for the chart's fail-loud guards. One assertion substring (config.AUTH_MODE must be one of) broke between Helm 3 and Helm 4 because gojsonschema reworded its enum-violation message between majors. The fix was to anchor on Helm's stable wrapper (values don't meet the specifications) instead of the inner library's text.

Going forward when adding chart CI assertions: anchor on the tool's own wrapper — Helm's Error: prefix, template execution error at prefix, schema values don't meet the specifications prefix — rather than the wrapped library's wording. The wrapped library may rephrase across versions; the wrapper usually doesn't. CI uses azure/setup-helm@v4 which resolves to Helm 4.1.4 as of May 2026; bumps land via Dependabot, so the test surface has to stay version-stable. Worth folding into a one-paragraph note in CONTRIBUTING.md or the chart README before the next test contribution.

Invitation

@ecthelion77 — you've walked the transport, chart, and Docker surfaces. Question 1 is the most concrete; question 2 is a security-rigor judgment call. No timeline. Anyone else with operator-side or security-researcher context welcome.

[ecthelion77]

Thanks for opening this — great framing of the three questions. Here's my take from running this server in production behind an OAuth gateway (streamable-http transport, network-bound, multi-session).

Q1: Flip default to Streamable HTTP — Yes

We've been running USE_STREAMABLE_HTTP=true in production since our initial deployment. The E2E suite in PR #63 (81 tests) runs exclusively against streamable-http and has been green throughout.

On client compatibility:

• VS Code (GitHub Copilot agent): uses StreamableHTTPClientTransport from @modelcontextprotocol/sdk — works perfectly
• Claude Desktop: negotiates streamable-http automatically with SDK ≥ 1.x
• Cursor / Windsurf: both support it (tested in our team)

I'm not aware of any current MCP client that requires SSE specifically. The SDK's transport negotiation (Accept: text/event-stream, application/json) means even older clients get a graceful fallback if SSE remains compiled in.

Suggestion: flip chart + Dockerfile to USE_STREAMABLE_HTTP=true, keep USE_SSE as opt-in fallback, add a deprecation note in CHANGELOG. We can remove SSE entirely in the next major.

Q2: Keep accepting localhost string — don't break scripts

The hosts-file attack vector is real in theory but is a self-sabotage scenario. If an operator's /etc/hosts maps localhost to a non-loopback address, they have bigger problems than this server's bind check.

Rejecting localhost would break:

• Docker Compose setups using --network host with GITLAB_API_URL=http://localhost:...
• Developer scripts that hardcode localhost
• systemd unit files / launch configs

Suggestion: document the caveat clearly (SECURITY.md already does) and recommend IP literals for hardened deployments. The current behavior is the right tradeoff between rigor and usability.

Q3: Anchor assertions on wrapper prefix — Agreed

We hit this exact issue in the E2E work: inner library messages are unstable across versions. Our tests anchor on:

• The tool's own error prefix (e.g. execution error at)
• Structural shape (key present, status code class)
• Never on third-party library wording

A short paragraph in CONTRIBUTING.md under a "Chart CI tests" section is sufficient. No over-engineering needed.

---

Happy to help with the implementation on any of these. No rush on our side — we're running fine with current defaults overridden in our values.

[musaabhasan]

The auth/bind matrix is a strong control because it makes unsafe deployment shapes fail loudly instead of depending on documentation. For the next iteration, I would add one more dimension: tool capability class.

A GitLab MCP server exposes tools with very different risk profiles. Read-only project metadata, issue creation, repository write actions, CI variable access, and pipeline trigger operations should not all inherit the same exposure policy just because they share the same transport.

A practical matrix could classify tools as:

• read-only public metadata
• read-only private/project metadata
• write workflow actions, such as issues or comments
• repository mutation
• CI/CD or secret-adjacent operations
• admin/configuration operations

Then the startup gate can enforce stricter requirements for higher-risk classes: network-bound and unauthenticated should always fail; network-bound with weak token handling should fail for write/admin tools; localhost-only may be acceptable for development but should still warn when high-risk tools are enabled.

That would make the threat model more precise without making operators reason through every individual tool manually.