Security & Trust

Verifying and trusting Busbar

Busbar is one static binary you run inside your own infrastructure. It holds provider credentials and sits in front of every model call, so how you know the binary matches the source (and how you report a problem) matters. This page is the answer to a security review: what we ship, how to verify it, what we consider in scope, and how to reach us.

Verify your download

Every tagged release publishes a keyless Sigstore build-provenance attestation (recorded in the public Rekor transparency log) that binds each artifact's digest to the exact GitHub Actions workflow run and source commit that produced it. A swapped or backdoored artifact on the release page fails verification. Verify a binary tarball:

gh attestation verify busbar-x86_64-unknown-linux-gnu.tar.gz \
  --repo GetBusbar/busbar

The container image carries the same provenance. Verify the image you pulled:

gh attestation verify oci://index.docker.io/getbusbar/busbar:1.4.1 \
  --repo GetBusbar/busbar

The GHCR image is additionally cosign-signed (keyless / OIDC). Verify the signature against the issuing workflow identity:

cosign verify ghcr.io/getbusbar/busbar:1.4.1 \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp '^https://github.com/GetBusbar/busbar/'

Supply chain

Each release ships a set of artifacts designed to answer enterprise / EO 14028 procurement questions without you having to decompile anything:

• SBOM (CycloneDX). A full Software Bill of Materials (every dependency, version, and license) is attached to each GitHub Release, so you can answer "is the crate in advisory X inside Busbar v1.4.1?" directly.
• Build provenance (SLSA Build L2). A signed, in-toto/SLSA-format provenance attestation for the binaries and both container images, generated by the release workflow itself and verifiable with the commands above.
• Signed images. The GHCR image is cosign-signed keyless via GitHub OIDC.
• Reproducible from source. Releases are built only from a signed version tag by a public GitHub Actions workflow. Normal pushes to main never produce a release artifact, so the published binary is always exactly the tagged source.

Threat model

We publish a scoped threat model so a reviewer gets a map instead of "read the source". It covers the trust boundaries (client ↔ gateway ↔ upstream, the separate admin plane, and configuration/secrets), the assets Busbar guards (provider credentials, virtual keys, admin certificates), and the threats we design against with pointers to the mitigation in code, including:

• SSRF against a config-controlled upstream (a cloud-metadata / IMDS denylist that normalizes hosts the way the connecting stack does: backslashes, userinfo, alternate IPv4 encodings, IPv4-mapped IPv6).
• Front-door authentication bypass (fail-closed auth chains; constant-time, anti-short-circuit secret comparison).
• Credential leakage (redacting Debug impls, reason-agnostic error surfaces, secrets never relayed to clients or logs).
• Outbound-signing correctness (AWS SigV4 signed == sent, verified end-to-end).
• Admin-plane isolation (a separate listener, loopback by default, mTLS-required to expose).
• Routing confusion and circuit-breaker state leakage across pools, models, or providers.

Architecture that reduces your attack surface

• One static binary. No interpreter, no database, no sidecars to patch. It runs air-gapped and does not phone home.
• Your credentials never leave your infrastructure. Busbar runs where you run it; there is no hosted tier behind it.
• TLS and mutual TLS are native: termination and client-cert enforcement are built in, not bolted on.
• Least privilege by construction. The admin/control plane is a physically separate listener from the data plane, and virtual-key secrets are hashed at rest.

Reporting a vulnerability

Please report privately. Do not open a public issue, pull request, or discussion. Two channels:

• Email [email protected].
• Or GitHub private vulnerability reporting (the repository's Security tab).

We aim to acknowledge a report within 48 hours, work with you on a fix, and coordinate disclosure. Confirmed vulnerabilities are published as GitHub Security Advisories, through which we request and issue CVE identifiers. We credit reporters who wish to be credited once a fix ships. Full policy in SECURITY.md.

Supported versions

Security fixes land on the latest main and the most recent tagged release (currently 1.4.1). Pin to a tag for production, and verify it with the recipes above.