Security

Security & responsible disclosure

How Buildfyio secures your workloads, and how to report a vulnerability.

Responsible disclosure

If you believe you've found a security issue in Buildfyio, please email security@buildfyio.com before disclosing it publicly. We'll acknowledge within one business day and aim to triage within three.

Safe harbor: as long as you act in good faith, don't exfiltrate customer data, and don't degrade our service or others', we won't pursue legal action.

Scope

  • buildfyio.com and every subdomain we host.
  • The public API at /v1 (documented at /v1/docs).
  • The buildfyio-cli and buildfyio-agent binaries we distribute.

Out of scope: customer applications deployed on our platform (contact the customer directly), volumetric DoS, missing security headers that don't lead to a concrete vulnerability, findings from automated scanners without an exploitable POC.

What we do

  • Isolation: every user pod runs under PSA restricted, drops ALL Linux capabilities, and lives behind a per-tenant NetworkPolicy that denies cross-tenant traffic.
  • Encryption: env vars, API tokens, MFA secrets, and provider tokens are AES-256-GCM encrypted at rest with versioned keys.
  • Auth: rotating refresh tokens (jti), optional TOTP MFA, scoped API tokens with an audited reveal step for secrets. SSO/SAML, SCIM and IP allowlists are on the roadmap, not shipped — we don't claim them.
  • Supply chain: platform images are built in CI from pinned actions; dependency and manifest scanning runs on every push. Every user image we build is scanned with Trivy for HIGH and CRITICAL CVEs and gets an SPDX SBOM you can download from the deployment page; the source tree is scanned for committed secrets before the build and the counts are shown on the deployment. Image signing is planned.
  • Edge: per-project firewall rules (path, IP/CIDR, country, user agent; block, challenge or log) are enforced at the edge before a request reaches your app, and your vercel.json / buildfy.json redirects, rewrites and headers are compiled into the same edge route. Non-production URLs can be put behind a password or team sign-in.
  • Egress: outbound webhooks and log drains refuse private and metadata addresses. A default egress policy for user pods is planned.
  • Monitoring: a probe on a separate machine checks the public endpoints every minute; the status and SLA pages are computed from those off-host results, not from the host's view of itself. Deployment, domain and alert events can be delivered to your own HTTPS endpoint as signed outbound webhooks.

Contact

Prefer PGP? Grab the public key at /security/pgp-key.txt.

Hall of fame

Researchers who help us fix a real security issue get named here (with permission).

  • (You could be first.)