Security

Build Infrastructure

Our build infrastructure has been architected with security as a primary consideration, implementing best practices to protect customer code, sensitive credentials and signing certificates. This section explains the security features of our build pipeline.

Secure Authentication & Configuration

The build process begins when our CLI authenticates with the ToDesktop API using your unique API key. After authentication, your app’s configuration is retrieved from our database and from the local todesktop.json file.

Secure File Management

Your application files are handled through a secure upload process:

1. The CLI requests pre-signed URLs from our API, which are temporary, scoped access tokens to our Amazon S3 storage.
2. After verification of upload permissions, your files are transferred to S3.
3. File integrity is maintained by calculating and storing checksums, ensuring the files used in the build process are identical to those you uploaded.

Ephemeral Credentials with Principle of Least Privilege (PoLP)

One of our key security features is the creation of ephemeral credentials:

• Temporary credentials are generated with a short 2-hour time-to-live (TTL)
• Access is strictly limited to only the specific resources needed for your build
• Each build receives unique credentials, preventing any potential credential reuse
• Credentials are automatically destroyed after build completion

This approach ensures that even in the unlikely event of a security breach, the potential impact is minimized through strict isolation and time constraints.

KeyVault Gatekeeper Architecture

While our ephemeral credentials already provides security through isolation, we maintain an additional layer of protection through our KeyVault Gatekeeper:

• The Gatekeeper acts as a secure sidecar that mediates all access to Azure KeyVault
• Communication between the build process and Gatekeeper occurs over localhost HTTPS

Secure Code Signing & Notarization

For distributing trusted applications:

• Code signing certificates for both Windows and macOS are securely managed in Azure KeyVault
• The signing and notarization process is handled by the KeyVault Gatekeeper
• The process follows platform-specific requirements for creating properly signed and notarized applications

Integrity Verification

Throughout the build process, we verify file integrity:

• Checksums created during upload are compared with files retrieved from storage
• This verification ensures that the exact files you uploaded are used in the build process
• Any integrity mismatch would trigger a build failure

Fault Tolerance

Our build system is designed for reliability:

• Builds that encounter errors are automatically retried once
• Error reporting is provided if builds ultimately fail
• The build status is continuously communicated back to you through the CLI and web UI

Build Distribution

After successful builds:

• Artifacts are securely stored and made available through our CDN
• We employ Cloudflare Workers with R2 storage for primary distribution
• A full backup of builds is stored in Amazon S3

Release Process

Our release process is designed with multiple security layers to ensure that only authorized individuals can publish updates to your applications. This section explains the security features of our release pipeline.

Security Key Authentication

The most critical security feature of our release process is the requirement for user verification via security keys:

• All release actions require WebAuthn authentication with user verification turned on (i.e. a physical security key or biometric or pin is required)
• This verification is managed through a dedicated security token service
• The authentication system operates independently from our main infrastructure
• Even if other systems are compromised, releases remain protected
• We recommend using a physical security key like a YubiKey

Granular Permission Controls

We implement strict permission-based access controls:

• Account administrators can assign specific release permissions to team members
• Team members can be granted build-only access without release capabilities
• An audit trail records release attempts

Partial Release Capability

To enhance security and reliability:

• Releases can be configured as full or partial rollouts
• Partial releases limit distribution to a subset of users
• This allows for controlled testing before wider deployment

Secure Distribution Architecture

Released builds are distributed through:

• Cloudflare Workers with R2 storage providing edge distribution
• Automatic cache invalidation to ensure immediate availability of updates
• In the case of an R2 outage, we can fall back to a backup storage system using Amazon S3

Self-hosted Distribution Infrastructure

Principles

• Follows the previous TD release process but allows you to have control over the infrastructure that has direct access to your end-users.
• ToDesktop has no access to the buckets and workers that serve your application releases and updates.
• The only interaction ToDesktop has is firing a webhook to your release-relay, which you fully control.
• The build is not released to your customers until you verify the release details and merge the corresponding PR into the main branch.
• You can enable branch protection rules in GitHub to require at least one/two specific reviewers (e.g., security lead or dev lead) to approve PRs before merging.

For the latest security details and implementation instructions, see the self-hosted README on GitHub.

Self-hosted Distribution Diagram

Vulnerability Disclosure Policy

Third-party Audits

We have engaged third-party auditors to review our build process and infrastructure. We will complete at least one audit per year to ensure our security measures are up to date.

The following audits have been completed:

• Completed on 25^th February 2025: Security Audit conducted by Doyensec — https://www.doyensec.com/