Trekport
Legal

Security Policy

Trekport migrates production Oracle databases to PostgreSQL. That means we handle credentials, schemas, and source code that customers cannot afford to expose. This page describes the specific measures we use to protect your data on the website, in the desktop application, and during a migration run.

Last updated · May 20, 2026

Air-gapped execution

Trekport Studio (the desktop application) and Trekport CLI run entirely on the operator’s machine. They make no outbound network calls during a migration run other than to the source Oracle and target PostgreSQL databases the operator has explicitly configured. There is no “phone home,” no remote extraction, no upload of source code or schema metadata.

The two exceptions are explicit and minimal: a license-validation handshake at activation (license key, non-reversible hardware hash, and product version), and opt-in crash reports if the operator enabled them in Settings. Neither transmits customer database content. See the Privacy Policy for the full data inventory.

Credential isolation

Database credentials entered into Trekport Studio are stored in the host operating system’s native secure storage (macOS Keychain, Windows Credential Manager, or libsecret on Linux), scoped per project. They are never written to plain-text configuration files, never serialized into checkpoint files, and never appear in log output or crash reports. The Rust backend retrieves them only when establishing a database connection and zeroizes the in-memory copy on disconnect.

Source data isolation

Source schemas, PL/SQL bodies, table data, and conversion output are written exclusively to the project working directory under the operator’s home directory (typically ~/.trekport/projects/<project-id>/). The location is operator-configurable. No copy leaves the machine. When the operator deletes the project, the working directory is removed.

Signed binaries

macOS releases are signed with an Apple Developer ID certificate and notarized through the Apple notary service before distribution. Windows releases are signed with a hardware-stored EV code-signing certificate. Linux releases are distributed as signed AppImages with detached GPG signatures. The signing keys are stored in HSM-backed vaults and used only by the release pipeline; no individual engineer has direct access.

Build provenance

Production binaries are built by the release pipeline from tagged commits in a private repository. Every release ships with a SLSA-style provenance file that records the commit SHA, builder identity, and toolchain versions. Customers can verify that a downloaded binary corresponds to the published commit using the published public key.

Conversion determinism

The AST-based conversion engine is deterministic: identical inputs produce byte-identical outputs given the same engine version and configuration. This is a security property as much as a quality property — it means an operator can audit converted SQL once and trust that subsequent runs against the same source will reproduce that result. The --seed flag (CLI) and the equivalent setting in the desktop application lock any non-deterministic phase such as identifier collision resolution.

Engine sandboxing

The Python engine that performs PL/SQL conversion runs embedded inside the desktop binary via GraalPy. It has no access to the host filesystem outside the explicit project working directory, no network access beyond the licensed database endpoints, and no ability to execute arbitrary system commands. The engine receives source code as in-memory strings and returns converted output the same way.

Website authentication

License-portal authentication on trekport.sh uses email OTP and OAuth (Google, Microsoft) via Clerk. Passwords are never handled or stored by Trekport. All session tokens are HTTP-only, Secure, SameSite=Lax, and transmitted over TLS 1.2 or newer exclusively. Session expiry follows the principle of least privilege — short-lived access tokens with rotating refresh tokens.

Payment security

Payment processing is handled by Stripe, which is PCI DSS Level 1 compliant. We never store, process, or have access to your full card numbers. Payment details are submitted directly to Stripe via their client-side SDK and never touch our servers. Stripe handles tokenization, fraud detection, and sales tax or VAT compliance.

Application security (website)

We enforce a comprehensive set of HTTP security controls across trekport.sh:

  • Content-Security-Policy restricting which scripts, styles, and resources may load on each page.
  • X-Frame-Options: DENY preventing the site from being embedded in iframes (clickjacking mitigation).
  • Strict-Transport-Security (HSTS) with preload and includeSubDomains, ensuring browsers only connect over HTTPS.
  • Permissions-Policy disabling unused browser capabilities (camera, microphone, geolocation, payment APIs outside Stripe’s SDK).
  • Rate limiting on every API and form endpoint to prevent abuse and brute-force attacks.
  • Schema-validated input on every server route. Each request body is parsed and validated against a strict schema before processing; unknown fields are rejected.
  • Turnstile bot protection on contact, waitlist, and trial-request forms.

Infrastructure

trekport.sh is hosted on Vercel, which provides automatic HTTPS via Let’s Encrypt, a global edge network for low-latency delivery, and DDoS protection at the infrastructure level. All deployments are immutable, traceable to a Git commit, and rolled out through a build pipeline with no manual server access required. The license server runs on Fly.io with the same provenance and immutability guarantees.

Encryption

  • In transit. TLS 1.2 or newer for every connection, including license validation, payment processing, and transactional email.
  • At rest. AES-256 encryption for database fields containing personal data (email, name, billing address) and for the license server’s key store.
  • Customer database content. Never reaches our infrastructure, so on-server encryption does not apply. Encryption of data in transit between Oracle, Trekport, and PostgreSQL is the operator’s responsibility, configured via the connection-string SSL parameters on both endpoints.

Error monitoring

We use Sentry for error tracking. Error reports are pre-sanitized to exclude personally identifiable information (PII) and customer database content. Stack traces, error types, and runtime metadata are captured; SQL statements, identifiers, file paths, and any customer-supplied strings are stripped in-process before transmission. Sentry data is retained according to their data-processing agreement and used solely for diagnosing and resolving application issues.

Access controls

Internal access to production systems and customer data is limited to a small operations team and granted on a least-privilege basis. All administrative access requires hardware-key two-factor authentication. Access logs are retained for 12 months and reviewed quarterly. New engineering hires complete onboarding security training before receiving any production credentials.

Dependency hygiene

Every Trekport release is preceded by an automated dependency scan (Cargo audit for Rust, pip-audit for Python, npm audit for the web tier). Critical vulnerabilities block the release. We track upstream security advisories for every direct dependency and ship a security release within seven days of a disclosed critical CVE in any shipped package.

Vulnerability disclosure

We value the security community and welcome responsible disclosure of any vulnerabilities you may find in the website, the desktop application, the CLI, or the license server. If you discover a security issue, contact us at:

Trekport
Email: security@trekport.sh

We ask that you give us reasonable time to investigate and address any reported vulnerability before making it public. We will acknowledge receipt of your report within 48 hours and aim to provide a resolution timeline within five business days. Researchers acting in good faith under this policy will not be pursued legally for testing or disclosure.

Incident response

If we identify a security incident affecting customer data, we will notify affected customers without undue delay and within 72 hours, in accordance with GDPR Article 33. Notifications include the nature of the incident, the data potentially affected, the corrective measures taken, and the steps customers should take to protect themselves. We maintain a written incident-response plan that is reviewed annually.

Compliance roadmap

Trekport’s architecture is compatible with HIPAA, FedRAMP, PCI-DSS, and air-gapped government deployments by design — no customer data leaves the operator’s environment. SOC 2 Type II audit is in progress; a Data Processing Agreement (DPA) is available to enterprise customers on request. Contact security@trekport.sh for a current security review, vulnerability-disclosure policy, or penetration-test results.