Security Policy

The Platform is hosted using third-party infrastructure providers, including Vercel (application hosting) and Supabase (database, authentication, and storage). These providers publish their own security and compliance materials, and our architecture relies in part on the controls they make available.

The production Platform is intended to be served over HTTPS using modern TLS protections. We rely on our hosting and network providers to terminate and manage transport security for browser and API traffic.

We rely on encryption-at-rest and storage-protection capabilities offered by our infrastructure providers for databases, backups, and uploaded files.

Each company's data is isolated at the database level. Company data is accessible only to authenticated users who belong to that company. Isolation is enforced by access policies built directly into the database, not just application code. Your session credentials are cryptographically verified on every request.

Authentication is handled by Supabase Auth. Session issuance, password handling, and token lifecycle controls are managed through that authentication service and our application-layer access checks.

Access control is enforced at multiple layers, including route protection, server-side checks, and database rules that keep each company's records separate. Even if an application-layer check fails, those database rules are designed to block access across company boundaries.

We validate user input in application code and use managed data-access libraries intended to reduce unsafe query construction and common injection risks. Not every control is identical across every route, and we continue to improve validation coverage over time.

We monitor dependencies, review updates, and apply security-related fixes as part of our normal maintenance process. Patch timing depends on severity, exploitability, and operational risk.

API keys, database credentials, and other secrets are stored exclusively as environment variables in deployment infrastructure where possible. We do not intentionally expose secrets in client-side code or public source control, and we rotate credentials when operationally necessary or when compromise is suspected.

We aim to limit internal access to production systems and customer data to the minimum needed to operate, support, and improve the Platform.

Where supported by our infrastructure and admin tooling, we use multi-factor authentication and recommend that customers protect their email and related business systems with MFA as well.

We review internal access and remove or adjust it when it is no longer required for a person's role or responsibilities.

Each company's data is logically isolated at the database layer. A user should not be able to access another company's records through the Platform, even if a request is malformed or intentionally manipulated.

When you use AI features, relevant portions of your data are sent to Anthropic or OpenAI to generate responses. We configure and use those services according to the data handling options and contractual terms available to us, and we attempt to send only the context required for the requested output.

We rely on backup, replication, and recovery features made available by our hosting and database providers. Recovery approaches may change over time as the Platform matures.

We maintain access and error logs for security monitoring and debugging. Logs are retained according to provider capabilities, operational need, and applicable legal requirements. Logs containing personal data are protected with the same access controls as production data. We do not intentionally log API keys, passwords, or authentication tokens in plaintext.

We use application logging, infrastructure telemetry, and alerting to help detect service issues, anomalous behavior, and security-relevant events.

Our incident response process covers detection, containment, investigation, remediation, and post-mortem analysis. In the event of a confirmed security incident:

• We will notify affected customers when required by applicable law or our contractual obligations and when doing so is appropriate in light of the incident.
• Notifications will include the nature of the incident, data categories affected, likely impact, and the remediation steps we are prepared to share at that time.
• We will cooperate with any government or regulatory investigation as required by law.

We maintain operational recovery procedures for major infrastructure or service failures, but recovery timelines depend on the nature of the incident and the capabilities of affected third-party providers.

Email security@govetract.com with:

• A clear description of the vulnerability
• Steps to reproduce the issue
• Potential impact assessment
• Any relevant screenshots, payloads, or proof-of-concept

In response to responsible disclosures, we aim to:

• Acknowledge receipt of reports promptly
• Review and triage credible issues in a reasonable timeframe
• Work toward remediation based on severity and operational risk
• Keeping you informed of remediation progress
• Not pursuing legal action against researchers who follow this responsible disclosure process

The following are out of scope for our disclosure program:

• Social engineering attacks against GovEtract employees
• Physical attacks against GovEtract offices or infrastructure
• Denial of service testing
• Vulnerabilities in third-party services not controlled by GovEtract (report to the relevant provider directly)
• Issues that require access to another user's account to reproduce