Skip to content
BMO

Security posture

BMO’s security posture is local-first by default and explicit about where that boundary widens. This page is the short public entrypoint for reviewers and operators; it summarizes the posture and points to the canonical technical threat model.

What this page is

Section titled “What this page is”
  • Public summary: concise reviewer/operator framing for CNCF, NLnet, and Manifund readiness work.
  • Not the technical source of truth: the canonical technical artifact is the security threat model.
  • Scope: current default-branch repository posture, last reviewed 2026-05-09. Supported-release and disclosure policy still live in SECURITY.md.

Core posture

Section titled “Core posture”
  • Local-first by default. BMO runs on the operator’s machine and uses the operator’s working tree, data directory, and provider credentials unless the operator enables additional surfaces.
  • Optional remote/protocol surfaces widen exposure. HTTP server modes, MCP integrations, plugins, provider fallback chains, and non-local sandbox backends are explicit trust expansions, not hidden defaults.
  • Sandbox backends are first-party, not implied. BMO ships local, docker, and ssh execution backends configurable under options.sandbox.backend; the default local backend offers no host isolation, while docker and ssh change where commands execute. Layered controls — command blocklist, sensitive-path denylist, SSRF guard, and approval gates — apply across all backends. See the security threat model for the per-backend trust expansion.
  • No overclaiming. BMO does not claim host isolation, hermetic sandboxing, formal verification, or safe execution of arbitrary third-party plugins/MCP servers simply because they can be configured.
  • Known gaps stay visible. Publicly safe gaps are linked from the canonical threat model; issues still under private intake can be acknowledged with a sanitized coordinated-disclosure placeholder instead of exposed exploit detail.
  • Release evidence is tag-scoped. Public RCs are not treated as ready until the tagged GitHub release page contains the verified evidence bundle for that tag.

Why this matters

Section titled “Why this matters”

BMO’s public-benefit value is inspectability, not security theater. A candid threat model lets external reviewers reuse one technical story when evaluating autonomy, transparency, interoperability, and AI-resilience claims, while giving operators a realistic picture of what changes when they enable remote or extensible surfaces. The project aims to be explicit about both controls and non-goals so trust decisions are based on evidence rather than implication.

Canonical technical source

Section titled “Canonical technical source”

For the full threat-boundary, control, and known-gap details, read the canonical technical document:

That document includes:

  • the risk-control matrix for major surfaces
  • current evidence anchors for present-tense control claims
  • explicit non-goals and unsupported posture
  • maintenance triggers and linked follow-up issues for material known gaps

Disclosure and support posture

Section titled “Disclosure and support posture”
  • Vulnerability reporting uses GitHub private vulnerability reporting via SECURITY.md.
  • Public linked issues are not the reporting path; they are follow-up artifacts once disclosure is safe.
  • Supported-release posture lives in SECURITY.md, not in this summary page.
  • Release integrity evidence lives in the published GitHub release object, not in mutable issue comments or branch-only notes.
Section titled “Related”