Last modified: 2026-04-26

The supply-chain detail lives separately in SUPPLY-CHAIN.md; this file covers the disclosure policy and a fast-path summary of how to verify a release.

If you believe you have found a security vulnerability in SBproxy, please do not file a public GitHub issue.

Email security@soapbucket.com with:

• A description of the vulnerability
• The version, tag, or commit SHA where you reproduced it
• A minimal reproduction (steps, config, payload)
• Your contact information for follow-up

You can encrypt your report with our PGP key at https://sbproxy.dev/.well-known/pgp-key.txt.

Primary key (Ed25519, sign+cert):  4C28 5392 FE49 C61D 94F1  02B6 6EFA 300A 32BF E26C
Encryption subkey (Cv25519):       140E DCF4 2C2B E3EF CA79  2D44 A76A 9BE3 914E 08C5
Issued:  2026-05-04
Expires: 2028-05-03

The same fingerprint is published on https://sbproxy.dev/security under "Disclosure & PGP". Compare both before trusting an imported copy.

We acknowledge receipt within 48 hours. We aim for a triage update within 5 business days and a remediation plan within 10 business days, depending on severity. Critical issues affecting the gateway path get same-day attention.

We follow coordinated disclosure: we will work with you on a public advisory and credit you in the release notes if you wish, after the fix is shipped and a reasonable upgrade window has elapsed (typically 7 to 30 days).

The Go implementation source lives at https://github.com/soapbucket/sbproxy-go and on the archive/go branch of this repository.

Every release artifact is signed with cosign (keyless, Sigstore), ships a CycloneDX SBOM generated by Syft, and carries SLSA build provenance via GitHub native attestations.

If you are pulling SBproxy into production, verify before you run. Four commands:

# 1. Download the artifact and its cosign bundle
VERSION=1.0.0
PLATFORM=linux_amd64
BASE="https://github.com/soapbucket/sbproxy/releases/download/v${VERSION}"
curl -fsSL -o sbproxy.tar.gz       "${BASE}/sbproxy_${PLATFORM}.tar.gz"
curl -fsSL -o sbproxy.tar.gz.bundle "${BASE}/sbproxy_${PLATFORM}.tar.gz.cosign.bundle"

# 2. Verify the binary signature (keyless, Rekor-backed)
cosign verify-blob \
  --bundle sbproxy.tar.gz.bundle \
  --certificate-identity "https://github.com/soapbucket/sbproxy/.github/workflows/release.yml@refs/tags/v${VERSION}" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  sbproxy.tar.gz

# 3. Verify the container image signature
cosign verify ghcr.io/soapbucket/sbproxy:${VERSION} \
  --certificate-identity "https://github.com/soapbucket/sbproxy/.github/workflows/release.yml@refs/tags/v${VERSION}" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com"

# 4. Verify SLSA build provenance
gh attestation verify sbproxy.tar.gz --repo soapbucket/sbproxy

All four must pass. If any fails, do not run the binary. Report it to security@soapbucket.com.

For full verification including SBOM inspection and air-gapped flows, see SUPPLY-CHAIN.md.

A signature only matters if you check it against the right identity. The cert identity for SBproxy releases follows this exact pattern:

https://github.com/soapbucket/sbproxy/.github/workflows/release.yml@refs/tags/vMAJOR.MINOR.PATCH

The OIDC issuer is always:

https://token.actions.githubusercontent.com

Anything signed by a different workflow path, repo, or issuer is not an official SBproxy release. The Sigstore Rekor transparency log records every signing event; if you suspect a release has been tampered with, query Rekor at https://rekor.sigstore.dev/ for the artifact hash.

Every tagged release (v*.*.*) ships:

• Binaries for linux_amd64, linux_arm64, darwin_amd64, darwin_arm64, each signed with cosign keyless and accompanied by a .cosign.bundle file containing the signature, certificate, and Rekor inclusion proof
• Container image at ghcr.io/soapbucket/sbproxy:<version> (and :<major> for the latest in a major line), signed via cosign and pushed with multi-platform manifests
• CycloneDX SBOM for source and image, attached as both a release asset (sbom.cyclonedx.json) and a cosign attestation on the image
• SLSA build provenance as a GitHub-native attestation, verifiable via gh attestation verify

Pre-release tags (v*.*.*-rc.*, v*.*.*-beta.*) are signed under the same identity but should be considered staging artifacts, not production releases.

When you deploy SBproxy:

• Pin the Docker image by digest, not by tag. Tags can be re-pushed; digests cannot.

  image: ghcr.io/soapbucket/sbproxy@sha256:<digest>

• Verify the digest matches the cosign-signed image before pinning it.
• Fetch SBOMs at deploy time if your security team requires per-deploy artifact inventory. The SBOM is attached to the image as a cosign attestation:

  cosign download attestation \
    --predicate-type=https://cyclonedx.org/bom \
    ghcr.io/soapbucket/sbproxy:1.0.0 | jq -r .payload | base64 -d > sbom.cyclonedx.json

• Store the cert identity you accept in your CI verification step. Rotating to a different identity (a new workflow file, a new repo) is a deliberate decision, not a silent one.
• Run the gateway as non-root. The container image's default user is non-root; do not override.
• Configure least-privilege for upstream API keys. The gateway is a privileged position in your traffic path. Treat its config as sensitive.

The gateway terminates and originates TLS as configured. Defaults:

• TLS 1.3 minimum for all configured listeners
• Certificate pinning is supported per upstream (certpin module); enable it for sensitive upstreams
• mTLS is supported for both client-to-gateway and gateway-to-upstream

Specifics, including cipher suites and curve preferences, are documented in the configuration reference.

Sensitive configuration values (API keys, OAuth secrets) referenced from sb.yml should be sourced from environment variables, files mounted with restricted permissions, or a secrets manager. The gateway does not encrypt values it loads from disk; it relies on filesystem permissions and the surrounding deployment environment to protect them.

The enterprise build's billing and audit-log surfaces persist data at rest; the storage backend you configure (Postgres, ClickHouse, etc.) is responsible for at-rest encryption per your standards.

We track open hardening items publicly. As of the latest release:

• Streaming SSE response capture in the semantic cache is intentionally bypassed. See SUPPLY-CHAIN.md for the rationale and the framing-aware capture roadmap (Q3 2026).
• First-party prompt-injection detection is heuristic. For strict use cases, integrate one of the supported guardrail vendors (Aporia, Lakera, Model Armor, Patronus, Pangea, CrowdStrike) via the enterprise tier.
• Reproducible builds are deterministic at the dependency-graph level (pinned Cargo.lock, pinned rust-toolchain.toml, --locked flag). Bit-for-bit reproducibility across builders is on the roadmap; we publish CI verification status as it lands.

• Security reports: security@soapbucket.com (PGP at https://sbproxy.dev/.well-known/pgp-key.txt)
• General contact: hello@soapbucket.com
• Public advisories: https://github.com/soapbucket/sbproxy/security/advisories