Skip to content

Security & Isolation

Every job runs in an ephemeral container, destroyed after completion. Network isolated. Short-lived tokens. No code stored.

Deep Dive

Security that's built in, not bolted on

Every Ovvoc job runs in an ephemeral Docker container that is destroyed immediately after completion. There is no persistent storage of customer code. No shared filesystems. No cached builds.

During the build and test phases, all network access is disabled. Your code cannot make outbound connections. No data exfiltration. No supply chain injection.

GitHub access uses short-lived installation tokens with the minimum required permissions: repository contents read + pull request write. Tokens are invalidated after each job.

Container Lifecycle

+Create
Clone
Transform
Buildnetwork off
Testnetwork off
PR
×Destroy

How It Works

Defense in depth

1

Short-Lived Token

GitHub installation token generated with 1-hour expiry. Only repo read + PR write permissions. Invalidated after job completion.

2

Ephemeral Container

Code cloned into a fresh Docker container with full security hardening: read-only rootfs, dropped capabilities, no privileged access.

3

Network Isolation

During build and test phases, all outbound network access is disabled. Your code runs in a completely isolated environment.

4

Immediate Destruction

Container destroyed immediately after job completion. No code, no build artifacts, no test output persisted on our infrastructure.

5

Metadata Only

We store only job metadata: package names, versions, test results, timestamps. Never source code. Never build artifacts.

Security Layers

Every layer hardened

Container Security

  • Ephemeral containers destroyed after every job
  • Read-only root filesystem
  • Dropped Linux capabilities (no privilege escalation)
  • gVisor sandbox on Cloud Run
  • Non-root user execution

Network Security

  • Network disabled during build & test phases
  • No outbound connections during code execution
  • TLS encryption for all API communication
  • Registry access via HTTPS only

Access Control

  • GitHub App with minimal permissions
  • Installation tokens expire in 1 hour
  • Token invalidated after job completion
  • Customer-scoped resource isolation
  • JWT authentication with HttpOnly cookies

Use Cases

Built for teams that care about security

Enterprise: Code Never Leaves

Deploy the Ovvoc agent on your own infrastructure. Code is cloned, processed, and destroyed within your network boundary.

Regulated Industries

Healthcare and financial services teams get audit trails for every job: who triggered it, what changed, full pipeline logs.

Agency Multi-Client

Agencies managing multiple client repositories get strict isolation. Each client's code runs in its own container with its own token.

Security Architecture

Five layers, each independent

Ovvoc's security model uses defense in depth. Five independent isolation layers ensure that a compromise of any single layer does not affect the others. Each layer is designed to function as a standalone security boundary.

Container Isolation

Ephemeral Docker containers with full security hardening. Read-only root filesystem, dropped Linux capabilities, non-root user execution, PID namespace isolation.

Network Isolation

All outbound network access disabled during build and test phases. Code cannot make external connections, preventing data exfiltration and supply chain injection.

Filesystem Isolation

Read-only root filesystem prevents persistent modifications. Temporary directories are allocated per-job and destroyed with the container.

Process Isolation

PID namespace isolation prevents processes from seeing or interacting with other containers. Resource limits on CPU, memory, and PIDs prevent denial-of-service.

Access Isolation

Short-lived tokens with minimum permissions. Each job gets its own token, scoped to only the repositories it needs. Token invalidated immediately after job completion.

Compliance

Built for regulated environments

SOC 2 Type II Aligned

Our security practices align with SOC 2 Type II requirements. Access controls, audit logging, data handling procedures, and incident response processes are designed to meet compliance standards.

GDPR Ready

No persistent storage of personally identifiable information. Data processing agreements available upon request. Customer data lifecycle is fully documented and auditable.

Encryption Standards

TLS 1.3 for all data in transit. AES-256 encryption for all data at rest. API keys and tokens stored with envelope encryption. No plaintext secrets in logs or configuration.

Audit Logging

Every operation is timestamped and traceable. Job execution, token generation, repository access, PR creation — all logged with actor, action, timestamp, and result.

Data Lifecycle

Your code's journey through Ovvoc

Clone

Code pulled into an ephemeral container via short-lived GitHub token. Only the branch needed for the update is cloned.

Process

Transforms, build, and test all run inside the container. No code leaves the container during processing. Network disabled.

Extract

Only results leave the container: pass/fail status, PR diff, test summary, error output. Source code never extracted.

Destroy

Container and all code deleted immediately after job completion. No backups. No source code logs. No persistent storage of any kind.

Vulnerability Response

If we find a vulnerability in Ovvoc itself

No software is immune to vulnerabilities. What matters is how they are handled. Our vulnerability response process is designed for speed and transparency:

  • 1Immediate triage — Every reported vulnerability is assessed within hours for severity and potential impact on customer environments.
  • 224-hour patch for critical issues — Critical vulnerabilities are patched and deployed within 24 hours of confirmation. Non-critical issues are addressed in the next release cycle.
  • 3Transparent disclosure — Affected customers are notified directly with the nature of the vulnerability, its potential impact, and the remediation applied.
  • 4Post-mortem published — A detailed post-mortem is published covering root cause, timeline, impact assessment, and measures taken to prevent recurrence.

Ready to automate your dependency updates?

Start with one repo. See the difference in your first PR.