Security at BidFrame.

1. Overview

BidFrame stores production briefs, project data, rate cards, and bid scenarios on behalf of commercial production teams. We treat that data as confidential and design the platform to keep it that way.

This page describes our current security posture honestly. Where a control is in place, we mark it In place. Where it is on the roadmap, we mark it Planned with a target window. We will not claim controls we do not yet have.

2. Infrastructure

BidFrame runs on managed cloud infrastructure operated by providers with mature security programs.

BidFrame inherits operational and physical security controls from these underlying providers. The application layer (everything BidFrame builds and operates on top of these providers) is governed by the controls described below.

3. Encryption In place

In transit

• All connections to BidFrame use TLS 1.2 or higher, terminated by our hosting provider (Vercel)
• HTTPS is enforced by the platform; HTTP requests redirect to HTTPS automatically
• API calls to subprocessors (Supabase, Anthropic) occur over TLS

HSTS preload header Planned: 2026 The Strict-Transport-Security header is being added to our application headers configuration.

At rest

• Customer Content stored in Supabase Postgres and Supabase Storage is encrypted at rest using AES-256
• Backups are encrypted at rest
• Encryption keys are managed by the underlying providers (AWS KMS via Supabase)

Customer-managed keys (BYOK) are not currently offered. Available on enterprise plans on the roadmap.

4. Authentication In place

• User authentication is provided by Supabase Auth
• Passwords are hashed using industry-standard algorithms (bcrypt). BidFrame does not store, log, or transmit plaintext passwords.
• Sessions use Supabase Auth defaults: signed JWTs, rotating refresh tokens, and idle timeouts
• Multi-factor authentication is enabled on the dashboard accounts (Vercel, Supabase, GitHub, Anthropic) used by Vismu LLC personnel to administer the Services

End-user MFA in the app Planned: 2026 TOTP enrollment for end users via Supabase Auth is on the roadmap and will be available before the first enterprise pilot.

SAML/SSO Planned: Enterprise tier, 2026 Single sign-on via SAML 2.0 and OIDC will be available on enterprise plans.

5. Access controls In place

Customer-side

• Role-based access controls within each organization (owner, admin, editor, viewer)
• Row-level security policies enforce that users can only access data for their own organization
• Sharing settings on projects and scenarios are explicit and revocable

Vismu LLC personnel

• Production access is restricted to a small number of authorized personnel under written confidentiality obligations
• Access is granted on a least-privilege, need-to-know basis and reviewed regularly
• Multi-factor authentication is enabled on the infrastructure dashboards used for production administration
• Access to Customer Content is logged. Routine engineering work uses synthetic or anonymized data. Access to live Customer Content occurs only for incident response, support requests authorized by the customer, or as required by law.

6. Multi-tenant isolation In place

BidFrame is a multi-tenant SaaS application. Tenant isolation is enforced at the database layer using PostgreSQL row-level security (RLS) policies. Every query for tenant-scoped data is evaluated against an organization context derived from the authenticated session. A misconfigured query that omits the organization filter is rejected by the database, not just by the application.

• Each row is tagged with an org_id
• RLS policies are defined on every table containing Customer Content
• File storage uses organization-scoped paths so each tenant's objects live in isolated keyspaces

RLS integration tests in CI Planned: 2026 Database-backed integration tests that simulate cross-organization access attempts are on the roadmap. Today, RLS is enforced at the database layer and exercised through application code paths.

Signed URL access for storage Planned: 2026 Short-lived signed URL generation for attachment downloads is on the roadmap.

7. Audit logging In place

• Database-level triggers and application-level logs record sensitive actions: project creation, scenario edits, version restores, exports, member invitations, role changes, and authentication events
• Logs include actor, action, target, and timestamp
• Server logs include request IDs for incident triage; cross-correlation between server logs and audit logs is on the roadmap
• Logs are retained for 24 months
• Audit log access for customers (org admins can view their organization's audit log in-app) is being rolled out across surfaces. Where not yet self-serve, customers can request a copy via support.

8. Application security In place

• Code is reviewed before merging to main
• Input validation at API boundaries: Zod schemas in our domain layer, with route-level validation on each handler
• Output encoding and React escaping by default to mitigate XSS
• Parameterized queries through Supabase clients to prevent SQL injection
• Rate limiting on authentication and high-cost endpoints (current implementation is in-process; persistent, cross-instance rate limiting on the roadmap)
• Secrets are stored in managed secret stores. Secrets do not appear in source control or logs.

Application security headers Planned: 2026 A Content Security Policy and standard security headers (Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy) are being added to our application headers configuration.

9. Vulnerability management

• Critical vulnerabilities are patched within 7 days of confirmation; high-severity within 30 days
• We monitor security advisories from our framework, library, and subprocessor maintainers

Automated dependency scanning Planned: 2026 Dependabot and CI-integrated dependency scanning are being added to our build pipeline.

Third-party penetration testing Planned: 2026 An independent penetration test is scheduled for completion before our first enterprise pilot. Summary letters available under NDA to qualified prospects.

10. Incident response

Our incident response approach covers detection, triage, containment, eradication, recovery, and post-incident review. The internal runbook is being formalized; the operational commitments below apply today and will be reflected in the runbook as it is finalized.

Commitments:

• Customer notification within 72 hours of confirmation that an incident has materially affected customer data, regardless of jurisdictional minimums
• Notice includes what we know, what we have done, and recommendations for the customer
• Post-incident review with affected customers, including a written summary and remediation timeline
• On-call rotation for production issues. Security incidents are escalated immediately.

11. Backups & recovery In place

• Daily automated database backups via the Supabase managed service
• Backups are encrypted at rest, separated from primary data
• Backup retention: up to 90 days from the last appearance of the data in production

Recovery testing Planned: 2026 Periodic recovery testing will be implemented and documented before our first enterprise pilot.

12. Subprocessor governance In place

• Subprocessors are listed in our Privacy Policy and reviewed against their security attestations before onboarding
• 30 days' advance notice to customers before adding a new subprocessor that processes Customer Content or Personal Information
• Enterprise customers may object to a new subprocessor and terminate the affected service for cause without penalty if we cannot accommodate
• Subprocessor relationships are governed by data processing terms incorporating Standard Contractual Clauses where applicable

13. Compliance roadmap

BidFrame is a pre-revenue platform on the path to enterprise readiness. We will not claim certifications we do not have. The current state:

14. Responsible disclosure

If you believe you have found a security vulnerability in BidFrame, we appreciate your report. Please email [email protected] with:

• A description of the issue and where you found it
• Steps to reproduce
• Any proof-of-concept code or screenshots
• Your contact information for follow-up

Our commitments to good-faith reporters:

• We will acknowledge receipt within 3 business days
• We will provide an initial assessment within 10 business days
• We will not pursue legal action against researchers who follow this policy and act in good faith
• We will credit reporters in our security notes if they wish

Please do not access data that does not belong to you, modify or destroy data, or degrade service availability. Stop testing and contact us if you encounter customer data inadvertently.

15. Contact

Security questions, vendor security questionnaires, audit requests:

Vismu LLC (BidFrame)
Security: [email protected]
Privacy: [email protected]