Verify the binary
before you trust it.
Every release is signed with cosign, ships with a CycloneDX SBOM, and carries SLSA build provenance. The verification recipe below works without trusting us. Run it, and the binary either checks or it does not.
Four artifacts. One pipeline.
Every git tag matching v*.*.* triggers the release workflow. It runs on GitHub-hosted runners, signs with Sigstore via GitHub OIDC (no long-lived keys), and publishes to GitHub Releases, Docker Hub, and ghcr.io.
- Binaries. Linux x86_64 and arm64, macOS arm64. Each release tarball ships with a keyless cosign signature bundle.
- Container images. Multi-arch on docker.io/soapbucket/sbproxy, mirrored to ghcr.io at the same digest. Signed with the same cosign identity.
- SBOM. Syft CycloneDX, attached to the GitHub release and bound to the image as a cosign attestation.
- Provenance. SLSA build provenance via actions/attest-build-provenance. Verifiable with
gh attestation verify.
Use Cosign 3.1.3 or later for this recipe; it includes the legacy bundle identity-verification fix.
# grab a release, pin the signing identity
V=1.14.0; P=linux_amd64 # or linux_arm64, darwin_arm64
gh release download "v$V" \
--repo soapbucket/sbproxy --pattern "sbproxy_$P*"
ID="https://github.com/soapbucket/sbproxy/.github/workflows/release.yml@refs/tags/v$V"
ISS=https://token.actions.githubusercontent.com
# 1. binary signature
cosign verify-blob \
--certificate-identity "$ID" \
--certificate-oidc-issuer "$ISS" \
--bundle "sbproxy_$P.tar.gz.cosign.bundle" \
"sbproxy_$P.tar.gz"
# 2. container image
cosign verify "docker.io/soapbucket/sbproxy:$V" \
--certificate-identity "$ID" \
--certificate-oidc-issuer "$ISS"
# 3. SBOM attestation on the image
# Cosign 3: select the Cosign 2 format used for the CycloneDX attestation.
cosign verify-attestation \
--new-bundle-format=false \
--type cyclonedx \
--certificate-identity "$ID" \
--certificate-oidc-issuer "$ISS" \
"docker.io/soapbucket/sbproxy:$V"
# 4. SLSA provenance
gh attestation verify "sbproxy_$P.tar.gz" \
--repo soapbucket/sbproxyOne AI gateway shipped malware through PyPI in March 2026. The category response is to make every install verifiable.
We are not the first AI gateway. We are the response to what happens when an AI gateway becomes critical infrastructure and the install channel has not caught up. One signed binary. Reproducible build target. No package-manager dependency tree, no plugin marketplace pulling unsigned code at runtime. Your supply-chain audit is the binary diff and the four commands above.
First release on the current pipeline. Signed tarballs, SBOM, and SLSA provenance attached from this tag on. Container images ship from v1.2.0 onward.
Every v*.*.* tag re-runs the same pipeline. No manual signing keys. No hand-cut releases. Verification stays the same shape across every tag.
Reproducible builds on the roadmap. Vulnerability disclosures via GitHub Security Advisories. Two-person review on every release branch.
The long companion to SECURITY.md. What we sign, where we publish, how to verify in air-gapped environments, what we promise about reproducibility.
Read on GitHub →Disclosure policy, supported version table, contact for security reports. The short answer to "where do I send a vulnerability."
Read on GitHub →Want to talk
before you install?
The gateway is on GitHub under Apache 2.0 and you can install it right now, so nothing here is gated behind a sales call. Use this form for deployment questions, migration scoping, or anything you would rather not file as a public issue.