Security
Security at BidStride
We are a small team managing data for contractors pursuing government work. We take that responsibility seriously. Here is exactly what we do to protect your data.
Infrastructure
Vercel — SOC 2 Type II
- +Hosting and edge network
- +Automatic TLS certificate management
- +DDoS protection and rate limiting
- +No server state retained between requests
Supabase — SOC 2 Type II
- +Database and authentication
- +AES-256 encryption at rest
- +Row-level security enforced at DB layer
- +Point-in-time recovery and audit logs
Stripe — PCI DSS Level 1
- +All payment processing
- +We never see or store card numbers
- +Tokenized payment methods only
- +Highest PCI compliance tier
Data practices
Row-level security
Enforced at the Supabase database layer. Your records cannot be returned in another user's query — even if the application layer had a bug.
No credential storage
We do not store your password anywhere in our system. Authentication is handled by Supabase Auth using secure session tokens. If you use email/password login, your password is hashed with bcrypt before it reaches any storage layer.
HMAC-signed tokens
Session tokens and API tokens are signed with HMAC-SHA256. A token that has been tampered with is rejected before it reaches any data access layer.
Rate limiting
All API endpoints are rate-limited to prevent brute force and credential stuffing attacks. Repeated failed authentication attempts trigger a temporary lockout.
Email verification
New accounts require email verification before access is granted. This prevents account creation with someone else's email address.
Session management
Sessions expire automatically. We do not use persistent cookies that survive browser restarts by default. Session tokens are rotated on each refresh.
What we do not store
- X
Credit card numbers
Stripe handles all payment processing. We receive only a Stripe customer ID and tokenized payment method reference — never the card number, CVV, or expiration date.
- X
Passwords in plaintext
Passwords are hashed with bcrypt before storage. Our team cannot recover your password — only reset it.
- X
SAM.gov or government portal credentials
BidStride does not ask for or store your SAM.gov login, government email, or any procurement portal credentials. We pull public data from federal sources using public APIs.
- X
Third-party account credentials
We do not integrate with your government email or agency portals. BidStride is read-only against public data sources.
Encryption
In transit
All traffic between your browser and BidStride uses TLS 1.3 — the current industry standard. Older protocol versions (TLS 1.0, 1.1, SSL) are not accepted. HTTP connections are redirected to HTTPS automatically.
At rest
Database storage is encrypted at rest using AES-256 via Supabase’s managed encryption layer. This includes all user data, account records, saved searches, and application configuration.
Working toward
We are a young product. The items below are on our security roadmap — not yet completed. We are being transparent about where we stand rather than claiming certifications we don’t hold.
- —SOC 2 Type II certification (audit in progress)
- —FedRAMP authorization (long-term roadmap for agency customers)
- —Penetration testing by independent third party (scheduled Q3 2026)
- —Bug bounty program (planned for post-SOC 2)
Authentication
BidStride uses Supabase Auth for all account authentication. The system supports email/password login with bcrypt password hashing and email verification. Sessions are managed via JWT tokens with automatic expiration and rotation.
If you believe your account has been compromised, email security@bidstride.com immediately. We will invalidate all active sessions and issue a password reset.
Security questions
Yes. Data in transit is encrypted with TLS 1.3. Data at rest is encrypted with AES-256 via Supabase's managed encryption layer. Your session tokens use HMAC signing. We do not store credentials in plaintext at any layer of the stack.
Your data is protected by row-level security (RLS) enforced at the database layer. This means that even if a query were misconfigured at the application level, the database would not return another user's records. Our team has administrative access for support and debugging purposes, subject to internal access controls and audit logging.
No. We do not sell your data to third parties. We do not share your account information, search history, or NAICS codes with any external parties for marketing purposes. We use third-party infrastructure providers (Vercel, Supabase, Stripe, SendGrid) who process data on our behalf under their own security certifications. See our Privacy Policy for full details.
BidStride is a commercial SaaS product, not a defense contractor system. We are not currently CMMC certified. If you work with controlled unclassified information (CUI) and require CMMC-compliant tooling, consult your program security officer before using any commercial tool for work-related tracking. We are working toward SOC 2 Type II certification, which will be our first major compliance milestone.
Report a security issue
If you have found a potential security vulnerability in BidStride, please contact us at security@bidstride.com. Please do not disclose vulnerabilities publicly until we have had a chance to investigate and respond.
We aim to respond to security reports within 48 hours. We do not currently have a formal bug bounty program, but we genuinely appreciate responsible disclosure and will acknowledge valid findings.
This page reflects BidStride’s security practices as of April 2026. Security practices evolve — check back for updates. For questions, contact security@bidstride.com.