Security

1. Our Security Commitment

Security is not an afterthought at Ovvoc — it is a foundational architectural principle. Our platform is designed from the ground up with a security-first approach, reflecting the reality that our customers entrust us with access to their source code and development infrastructure.

Ovvoc is built on the principle of ephemeral by design. Customer code is processed in isolated, short-lived containers that are created for a single task and destroyed immediately upon completion. There is no persistent storage of customer source code. This architecture fundamentally limits the blast radius of any potential security incident and ensures that sensitive data exposure is minimized at every layer.

This document provides a transparent overview of the security measures we implement to protect your code, data, and accounts. We believe that trust is earned through transparency, and we encourage you to review this document carefully. If you have any questions or concerns, please contact us at [email protected].

2. Infrastructure Security

The core of Ovvoc's security model is the ephemeral container architecture. Every dependency update job is executed in a freshly provisioned Docker container that is destroyed the moment the job completes or fails. This approach ensures that no customer code, dependencies, or build artifacts persist beyond the lifetime of a single job.

2.1 Ephemeral Containers

• Lifecycle: Each container is created for a single dependency update job. Upon completion — whether successful or failed — the container and all of its contents are immediately and irrecoverably destroyed.
• No code persistence: Customer source code is cloned into the container's ephemeral filesystem and never written to any persistent storage volume, database, object store, or backup system.
• Clean state: Every job starts from a known-good base image with no residual data from previous jobs. There is no risk of cross-contamination between customers or between jobs.

2.2 Container Sandboxing

• gVisor (production): In production environments, containers run within gVisor sandboxes, which provide an additional kernel-level isolation layer between the container workload and the host operating system. gVisor intercepts and filters system calls, significantly reducing the attack surface.
• Resource limits: Every container is subject to strict resource constraints, including CPU allocation limits, memory caps, disk usage quotas, and maximum execution time. These limits prevent resource exhaustion attacks and ensure fair utilization across all customers.

2.3 Network Isolation

• Outbound-only access: Ephemeral containers are configured with outbound-only network access, restricted exclusively to package registries (such as the npm registry) and source code hosting platforms (such as GitHub). Inbound connections to containers are not permitted.
• Internal segmentation: Internal services communicate over private networks with firewall rules enforcing the principle of least privilege. Production databases, application servers, and worker processes each operate in distinct network segments.

3. Data Encryption

All data handled by Ovvoc is protected by industry-standard encryption at every stage of its lifecycle.

3.1 Data in Transit

• All connections between customers and Ovvoc are encrypted using Transport Layer Security (TLS) version 1.2 or higher.
• All internal service-to-service communications are encrypted using TLS.
• All connections to third-party services (GitHub, Paddle, Resend, Google Gemini) are encrypted using TLS.
• Connections to databases are established exclusively over encrypted channels.

3.2 Data at Rest

• Secrets and tokens: All sensitive credentials, including authentication tokens, API keys, and private registry credentials, are encrypted at rest using AES-256-GCM (Advanced Encryption Standard with 256-bit keys in Galois/Counter Mode).
• Database: Database connections use encrypted channels. Sensitive fields stored in the database (such as encrypted registry credentials) use application-level encryption in addition to any infrastructure-level encryption provided by the hosting platform.

3.3 Password Storage

• User passwords are hashed using Argon2id, the algorithm recommended by OWASP for password storage. Argon2id is resistant to both GPU-based and side-channel attacks.
• Passwords are never stored in plaintext, logged, or transmitted in unencrypted form.
• Password hashes are never exposed through the API or included in any server response.

4. Authentication and Access Control

Ovvoc implements multiple layers of authentication and access control to protect customer accounts and administrative functions.

4.1 Customer Authentication

• Multi-provider authentication: Customers may authenticate using GitHub OAuth, Google OAuth, or email and password. Account linking allows customers to associate multiple authentication providers with a single account.
• JWT with short expiry: Access tokens are JSON Web Tokens (JWT) with a 15-minute expiry, limiting the window of exposure in the event of token compromise.
• Refresh token rotation: Refresh tokens have a 7-day lifetime and are rotated on every use. When a refresh token is used, the old token is immediately invalidated and a new token is issued, preventing token replay attacks.
• Secure cookies: Authentication tokens are stored in HttpOnly, Secure, SameSite cookies, preventing access from client-side JavaScript and mitigating cross-site request forgery (CSRF) and cross-site scripting (XSS) attacks.
• Brute-force protection: Login attempts are rate-limited to 5 attempts per email address and 20 attempts per IP address within a 15-minute window. Accounts are temporarily locked after exceeding these thresholds.

4.2 Administrative Access

• Database-verified on every request: Administrative access is verified by querying the database on every request, rather than relying solely on JWT claims. This ensures that administrative privileges can be revoked instantly and take effect immediately.
• Dedicated rate limiting: Administrative endpoints are subject to a separate rate limit of 30 requests per minute, independent of the standard user API rate limiter.
• Audit logging: All administrative actions are recorded in a dedicated audit log, including the administrator's identity, the action performed, the target of the action, and a timestamp.

5. Code Handling

We understand that source code is among the most sensitive assets a software organization possesses. Ovvoc's code handling practices are designed to minimize exposure and ensure that customer code is accessed only to the extent strictly necessary for performing dependency updates.

5.1 Minimum Permission Access

• GitHub App permissions: The Ovvoc GitHub App requests only the minimum permissions required to perform its function: contents:write (to read repository contents and push updated branches) and pull_requests:write (to create pull requests with dependency updates).
• Installation tokens: Repository access is mediated through GitHub installation tokens with a 1-hour expiry. Tokens are generated on demand for each job and are not cached beyond their intended use.
• Repository selection: Customers have full control over which repositories the Ovvoc GitHub App can access. Access can be granted on a per-repository basis or for all repositories within an organization.

5.2 Code Lifecycle

• Customer code is cloned into an ephemeral container workspace at the start of each job.
• The container and all of its contents — including the cloned source code, installed dependencies, and build artifacts — are destroyed immediately upon job completion or failure.
• Code is never written to persistent storage, never backed up, and never retained beyond the lifetime of the ephemeral container.
• Code is never used for model training, analytics, benchmarking, or any purpose other than performing the requested dependency update.

6. AI Security

Ovvoc uses artificial intelligence (currently Google Gemini) for complex code transformations that cannot be handled by deterministic rules alone. AI is employed in a narrow, scoped manner, and we implement the following safeguards to protect customer data:

• Minimum context: Code snippets sent to AI models contain only the minimum context necessary for the specific transformation task. Full repository contents are never transmitted. Prompts are carefully constructed to include only the relevant code fragments, dependency information, and transformation requirements.
• Encrypted transmission: All communication with AI model providers occurs over TLS-encrypted connections.
• Provider agreements: Ovvoc maintains data handling agreements with AI model providers that prohibit the use of customer data for model training, benchmarking, or any purpose other than generating the requested response.
• No model training: Customer code submitted to AI models is not used to train, fine-tune, or improve any AI model. This is enforced both through provider agreements and through the use of API tiers that explicitly exclude training data usage.
• Scoped tasks: AI is invoked only for specific, well-defined transformation tasks (such as migrating a deprecated API call to its replacement). AI is not used for general-purpose code generation, code review, or any function outside the scope of dependency update transformations.

7. Third-Party Security

Ovvoc integrates with a limited number of carefully vetted third-party services. Each provider has been evaluated for its security posture and compliance certifications:

• GitHub (Microsoft): SOC 2 Type II certified. Source code hosting, repository access, OAuth authentication, and pull request creation.
• Paddle.com Market Limited: PCI DSS Level 1 compliant. Payment processing, subscription management, and tax compliance as Merchant of Record.
• Google Cloud Platform: ISO 27001, SOC 2 Type II certified. Infrastructure hosting and Gemini AI API for code transformations.
• Cloudflare: SOC 2 Type II, ISO 27001 certified. CDN, DDoS protection, DNS management, and TLS termination.
• Resend: SOC 2 certified. Transactional email delivery for notifications, verification emails, password reset, and weekly digest reports.

We regularly review the security posture and compliance status of our third-party providers. In the event that a provider's security posture materially degrades, we will evaluate alternatives and migrate as appropriate. Our Data Processing Agreement provides additional detail on subprocessor management and notification obligations.

8. Vulnerability Disclosure

Ovvoc is committed to working with the security research community to identify and address vulnerabilities in our platform. We operate a responsible disclosure program and welcome good-faith security research.

8.1 Reporting a Vulnerability

If you believe you have discovered a security vulnerability in the Service, please report it to [email protected]. Please include the following information in your report:

• A detailed description of the vulnerability, including the affected component, endpoint, or feature
• Step-by-step instructions to reproduce the vulnerability
• The potential impact and severity of the vulnerability, if known
• Any proof-of-concept code, screenshots, or other supporting evidence
• Your name and contact information (optional, but helpful for follow-up communication)

8.2 Response Timeline

• Acknowledgment: We will acknowledge receipt of your report within 2 business days.
• Triage: We will triage the reported vulnerability and assess its severity within 5 business days of acknowledgment.
• Remediation: We will work to remediate confirmed vulnerabilities within the following timeframes based on severity:
  • Critical: 30 days or fewer
  • High: 60 days or fewer
  • Medium/Low: 90 days or fewer
• Notification: We will notify the reporter when the vulnerability has been remediated and provide information about the fix.

8.3 Safe Harbor

Ovvoc will not pursue legal action against security researchers who discover and report vulnerabilities in good faith, provided that the researcher:

• Does not access, modify, or delete data belonging to other users
• Does not disrupt or degrade the availability of the Service
• Does not publicly disclose the vulnerability before Ovvoc has had a reasonable opportunity to remediate it
• Makes a good-faith effort to avoid violating privacy, causing data destruction, or interrupting or degrading the Service
• Reports the vulnerability promptly upon discovery

8.4 Scope

The following assets are within the scope of our responsible disclosure program:

• The Ovvoc web application at ovvoc.com
• The Ovvoc API at api.ovvoc.com
• The Ovvoc GitHub App

The following are explicitly out of scope: third-party services (GitHub, Paddle, Google Cloud, Cloudflare, Resend), social engineering attacks, denial-of-service testing, and physical security testing.

9. Incident Response

Ovvoc maintains a documented incident response plan to address security incidents promptly and effectively. Our incident response process follows industry best practices and consists of the following phases:

• Detection: Automated monitoring systems and security alerts continuously monitor for anomalous activity, unauthorized access attempts, and potential security breaches.
• Triage: Upon detection of a potential incident, the security team assesses the severity, scope, and potential impact of the incident to determine the appropriate response level.
• Containment: Immediate measures are taken to contain the incident and prevent further damage, including isolating affected systems, revoking compromised credentials, and blocking malicious traffic.
• Remediation: The root cause of the incident is identified and addressed. This may include patching vulnerabilities, restoring systems from backups, rotating credentials, and implementing additional security controls.
• Post-mortem: A thorough post-mortem analysis is conducted to identify lessons learned, improve incident response procedures, and implement preventive measures to reduce the likelihood of similar incidents in the future.

9.1 Regulatory Notification

In the event of a Personal Data breach, Ovvoc will notify the relevant supervisory authority within 72 hours of becoming aware of the breach, as required by Article 33 of the GDPR. Notification will include the nature of the breach, the categories and approximate number of affected Data Subjects, the likely consequences, and the measures taken or proposed to address the breach.

9.2 Customer Notification

Customers affected by a data breach will be notified without undue delay via email to the address associated with their account. The notification will include a description of the incident, the types of data potentially affected, the measures taken to contain and remediate the incident, and recommendations for any actions the customer should take. For additional detail on breach notification obligations, please refer to our Data Processing Agreement.

10. Compliance Roadmap

Ovvoc is committed to achieving and maintaining compliance with industry-recognized security standards and data protection regulations:

• SOC 2 Type II (planned): We are working toward SOC 2 Type II certification, which will provide independent third-party validation of our security controls, availability, and confidentiality practices. We expect to complete this certification as the organization scales.
• GDPR compliance (current): Ovvoc is compliant with the European Union General Data Protection Regulation (EU) 2016/679. We have implemented appropriate technical and organizational measures, maintain a Data Processing Agreement, and support Data Subject rights as required by the regulation.
• CCPA/CPRA compliance (current): Ovvoc is compliant with the California Consumer Privacy Act (CCPA) and the California Privacy Rights Act (CPRA). Our Privacy Policy describes the categories of personal information we collect, the purposes for which it is used, and the rights available to California residents.
• Regular security assessments: We conduct regular internal security assessments, including code reviews, dependency vulnerability scanning (using the Ovvoc platform itself), and infrastructure configuration audits. As the organization grows, we plan to engage independent third-party security firms for periodic penetration testing and security audits.

11. Contact

For security-related inquiries, vulnerability reports, or questions about this Security Policy, please contact us at [email protected].

For general legal and privacy inquiries, please refer to our Terms of Service, Privacy Policy, and Data Processing Agreement.