Skip to content

docs(security): document default deployment trust model#5611

Open
ibondarenko1 wants to merge 1 commit into
bentoml:mainfrom
ibondarenko1:docs/security-deployment-trust-model
Open

docs(security): document default deployment trust model#5611
ibondarenko1 wants to merge 1 commit into
bentoml:mainfrom
ibondarenko1:docs/security-deployment-trust-model

Conversation

@ibondarenko1
Copy link
Copy Markdown

Why

SECURITY.md does not document the default authentication posture of a deployed BentoML service. A bento started with bentoml serve listens on 0.0.0.0:3000 and accepts HTTP and gRPC requests without authentication; there is no built-in API-key validation, JWT check, or OAuth flow.

A search of past issues (#1273, #2768, #2809, #1031) shows that the "add auth to bentoml" question keeps coming up and getting closed without a documented design answer. Peer projects (HuggingFace transformers, NVIDIA Triton, vLLM) document their default-auth posture up front and route the responsibility to the operator. This PR brings BentoML in line with that practice.

What

Adds a new section "Default deployment trust model" to SECURITY.md, between "Reporting a Vulnerability" and "Exceptions". The section:

  • States that the default deployment has no built-in authentication.
  • Names the bento author's responsibility: add Starlette middleware (HTTP) or a gRPC interceptor before exposing to an untrusted network.
  • Provides a 5-line example using the public API svc.add_asgi_middleware(...) (defined at src/bentoml/_internal/service/service.py:445).
  • References the gRPC interceptors package at bentoml.grpc.interceptors.
  • Scopes the threat model: "default has no auth" reports are out of scope; auth-middleware bypass once enabled is in scope.

No code change. No behavior change. No backwards compatibility risk.

Impact

  • Operators reading the security policy see the boundary up front.
  • Security inbox can triage "no default auth" reports against a written design choice instead of re-arguing per advisory.
  • New BentoML deployers understand they need to add auth before going public.

Testing

Pure docs PR; no automated test applies. Verification:

  • GitHub markdown preview confirms section renders between "Reporting a Vulnerability" and "Exceptions".
  • Code block syntax-highlights as Python.
  • Internal API reference checked: svc.add_asgi_middleware exists on HEAD e570eb2b (grep verified).
  • bentoml.grpc.interceptors package exists (verified).

References

Checklist

  • No code change.
  • No behavior change.
  • No backwards compatibility break.
  • Aligned with peer-project security policies.

A deployed BentoML service has no built-in authentication on its HTTP
or gRPC endpoints. The bento author is expected to add Starlette
middleware or a gRPC interceptor before exposing the service to
untrusted networks. Document this expectation in SECURITY.md so that
operators reading the security policy see the boundary up front, and
so that reports of 'service has no auth' can be triaged against a
written design choice instead of being argued in every advisory.
@ibondarenko1 ibondarenko1 requested a review from a team as a code owner May 16, 2026 00:34
@ibondarenko1 ibondarenko1 requested review from ssheng and removed request for a team May 16, 2026 00:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant