FAQ
The questions your security reviewer asks second.
The same fourteen objections a regulated buyer raises on the second call — self-host vs. cloud, audit-trail immutability, RBAC granularity, SBOM format, signing posture, monorepo scale, sandbox CI isolation, retention windows, SOC 2 timeline, on-call integration, key custody, air-gapped operations, repo data residency, and pricing structure — surfaced as a five-item showcase at the top of the page (the canonical second-call playbook) and the full accordion below, each answered in eighty words or less and backed by one deep link into the compliance, architecture, install, security, or pricing reference your reviewer already reads.
Read time
~6 minutes end to end
Each answer is a single paragraph under eighty words; the deep link carries the depth.
Sources
five reference families
Every deep link lands on /docs/compliance, /docs/install, /docs/quickstart, /architecture, or /security.
Indexing
FAQPage JSON-LD
Server-rendered application/ld+json so search engines surface rich results with the question and a teaser.
Top 5 evaluator objections
Five answers a security reviewer reads second.
The five objections a regulated buyer raises on the second call — audit log retention, ed25519 signing verification, SOC 2 status and roadmap, repo data residency, and pricing structure — each answered in two to four sentences with one deep link into /security or /pricing. The full fourteen-item accordion below covers everything else a security checklist asks.
How long do you retain audit logs and SBOMs?
Audit ledger rows are kept seven years hot and ten years cold, replays are exportable as CycloneDX-style JSON, and each row remains linked to its Rekor transparency-log entry indefinitely. SBOMs are retained against the PR hash for the lifetime of the deployment plus the customer-configured archive window. The compliance reference spells out the per-field retention table a regulator reads end to end.
How are commits and SBOMs signed?
Commits are signed with cosign / Sigstore OIDC, identity ed25519 keyful, against the GitHub App you own. SBOMs are signed with your SBOM-signing key. Both signatures verify in GitHub UI without extra plugins and via the standard cosign verify and gh CLI commands. The keypair lives in your KMS — or your HSM on Enterprise — and rotates on your schedule.
What's the SOC 2 Type I vs. Type II timeline?
Driftlock is SOC 2 Type I certified and SOC 2 Type II on schedule. The Type II window covers all five Trust Services Criteria — Security, Availability, Processing Integrity, Confidentiality, Privacy — against real production traffic, with quarterly auditor checkpoints on the customer's clock. The full readiness phase, Type I point-in-time, Type II observation window, and Type II continuous-operation report are listed on the security page.
Where does your repo data live — in our cloud or yours?
Driftlock runs in your environment. The Platform and Enterprise tiers deploy as a single Helm + Terraform stack into your VPC, your cloud account, or your on-prem Kubernetes — your repo data, SBOMs, audit rows, and signing keys never leave your perimeter. Egress is policy-restricted at the sandbox boundary; the runner cannot fetch third-party model calls. For air-gapped buyers on Enterprise we ship a fully offline binary with an empty destination allow-list by design.
How is Driftlock priced — per seat, per repo, or per deployment?
Team is a per-seat annual subscription with self-serve onboarding; Platform is an annual commit priced against active engineers and seat count, with a ten-day scoped trial against one of your real monorepos; Enterprise is an annual commit with a separate MSA / DPA, scoped to a self-hosted deployment in your cloud account or on-prem. There are no per-PR or per-API-call fees at any tier — and moving between tiers keeps your audit trail, signing keys, and CI identity intact.
five objections · each answer 2-4 sentences · each link to /security or /pricing · the canonical second-call playbook
Buyer objections, answered
Fourteen answers, one deep link each.
Each item below is a one-paragraph restatement of a posture Driftlock already documents at length — the deep link is where the auditor-facing language begins. Read top to bottom for the canonical second-call playbook or jump to a single objection via the in-page table of contents above.
Yes. The Platform and Enterprise tiers ship a single Helm + Terraform deployment that lands in your VPC or cloud account — watcher, sandbox, SBOM pipeline, and signing stack run there. Nothing leaves your perimeter: egress is policy-restricted, and the GitHub, CI, and on-call signals cross your boundary as one-way taps you already own. The Enterprise tier also ships an on-prem Helm chart and an offline runner for fully disconnected deployments. For a step-by-step walkthrough — Docker + Postgres + S3-compatible prerequisites, the env-var reference, the DB migration step, and the overnight cron a security reviewer reads on day one — see the self-host deployment guide.
fourteen items · each answer ≤80 words · each link lands in one of five reference families · server-rendered FAQPage JSON-LD
The deep-dive references
Read on, in either direction.
Each row above points at one of the five reference pages your reviewer already reads — the SOC 2 + data-handling posture on /security, the sandboxed topology on /architecture, the RBAC + audit-trail + SBOM deep reference on /docs/compliance, the install runbook on /docs/install, and the tier composition on /pricing. Use this page to land the conversation; jump to the references when depth is required.