Security
Answer-ready for the second meeting.
Driftlock’s posture for the regulated reviewer who arrives after the demo closes: the SOC 2 roadmap a regulator reads end to end, the encryption posture that crosses every internal boundary, the RBAC matrix + audit-log retention a security team verifies, the signed CycloneDX SBOM a supply-chain team ingests, and the disclosure channel a researcher reaches when something needs attention.
SOC 2
Type I certified · Type II in window
Continuous-operation attestation across all five Trust Services Criteria — the artefact your regulator asks for in the second meeting.
Keys + custody
Customer-managed by default
DEKs wrapped by a KMS-resident KEK you control. Private half never leaves your boundary — HSM on Enterprise, air-gapped on demand.
SBOM + signing
CycloneDX + cosign Rekor-anchored
Every PR emits a signed SBOM into your artifact registry — same field a supply-chain team ingests today, same posture on every PR.
SOC 2 roadmap
Type I certified · Type II on schedule.
The four phases a regulator reads on the same page — readiness, Type I point-in-time, Type II observation window, Type II continuous-operation report. Driftlock publishes each milestone under NDA on request, including the auditor’s management letter and the finding-by-finding status.
The Type II window covers all five Trust Services Criteria — Security, Availability, Processing Integrity, Confidentiality, Privacy — against real production traffic. Quarterly auditor checkpoints keep the evidence on the customer’s clock, not Driftlock’s.
SOC 2 Type II · all five TSC · 12-month continuous-operation window
Phase
Status
Scope
Framework anchor
phase readiness
Readiness & gap assessment
CompleteInternal controls mapping against the Trust Services Criteria (CC, A, C, PI). Risk register, control owners, evidence capture. Closed before audit kick-off.
framework
TSC · CC1–CC9 · AICPA 2017 (revised 2022)
phase type-i
SOC 2 Type I report
CertifiedAuditor attestation that control design is suitably designed and operational at a point in time — the second meeting artefact a buyer requests most often.
framework
Type I · point-in-time design attestation
phase type-ii-window
SOC 2 Type II observation window
In progressTwelve-month continuous-operation evidence across all five Trust Services Criteria — production traffic, every egress boundary, every signed artefact. Reviewed quarterly with the auditor.
framework
Type II · observation window · quarterly checkpoints
phase type-ii
SOC 2 Type II report
On scheduleAuditor attestation that controls operated effectively throughout the observation window. Refreshed annually; the previous report stays available as a historical reference.
framework
Type II · continuous-operation attestation · annual refresh
Data handling
Encryption posture, end to end — with keys you control.
Every Driftlock surface is encrypted at rest and in transit. The protection that lands on each surface uses your KMS as the root of trust; the private half of any key never leaves your boundary. The Enterprise tier refines the posture further: HSM-backed signing via PKCS#11, an air-gapped runner, and an on-prem Helm chart for fully disconnected deployments.
The four surfaces below are the standard checklist a security reviewer runs through on day one — encryption at rest, encryption in transit, customer-managed keys, and data residency. Each rows wraps the surface into the same posture terms Driftlock commits to in writing.
Encryption at rest
AES-256 encryption on every storage tier — primary database, ledger pg_append, object-storage mirror, snapshot bucket. Envelope encryption per tenant boundary.
custody
Per-tenant DEKs wrapped by a KMS-resident KEK you control. The KEK never leaves your KMS — Driftlock reads only the public half.
Encryption in transit
TLS 1.3 minimum across every internal hop — watcher → sandbox → signer, sandbox → registry, GitHub webhook → watcher. mTLS on the internal mesh; no plain-text on any service-to-service link.
custody
Hosted cluster pins the CA bundle in your KMS-managed trust store; Enterprise tier swaps to your private CA for air-gapped deployments.
Customer-managed keys (CMK / BYOK)
Platform tier routes every envelope key through your KMS alias — KMS-managed by default, Customer-Managed Key (CMK) opt-in via a single key alias. Enterprise tier swaps to your HSM via PKCS#11.
custody
The private half never leaves your boundary. Driftlock receives the wrapped DEK; it never holds plaintext key material outside the sandbox.
Data residency
Single Helm + Terraform deployment into your VPC or cloud account. The audit-ledger bucket is a customer-managed S3/OCI bucket in the region of your choice — no shared multi-tenant tier.
custody
Region selected at chart install. No Driftlock-managed object storage carries customer artefacts; the platform never has a path to read them.
Repository data residency
Your repository stays in the boundary you choose.
Driftlock runs in the customer environment. Platform and Enterprise deploy as a single Helm + Terraform stack into your VPC, cloud account, or on-prem Kubernetes, so repository data, SBOMs, audit rows, and signing keys stay inside your perimeter. The deployment boundary and its storage region are selected by the customer rather than assigned to a shared Driftlock tier.
Canonical repository-residency record
Canonical reference for where repository data runs, where it is stored, and which boundaries govern egress.
Processing boundary
Your deployment runs the pipeline
The watcher, sandbox, SBOM pipeline, and signing stack run in the deployment installed into your VPC, cloud account, or on-prem Kubernetes. Driftlock does not process repository artefacts in a separate shared control plane.
Storage and region
You choose and own the region
The audit-ledger bucket is a customer-managed S3/OCI bucket in the region selected at chart install. No Driftlock-managed object storage carries customer artefacts, and the platform has no path to read them.
Egress and air gap
Policy-restricted by design
Egress is restricted at the sandbox boundary, and the runner cannot fetch third-party model calls. Enterprise adds an offline binary and on-prem Helm chart with an empty destination allow-list for fully disconnected operation.
Security-review evidence
Use this checklist to validate the deployment boundary, storage ownership, and egress posture during review.
- Record the deployment target, cloud account or VPC, and the region selected during chart installation.
- Verify bucket ownership and region for the customer-managed S3/OCI audit-ledger mirror.
- Review the sandbox egress policy and confirm the permitted destination allow-list.
- For disconnected environments, confirm the Enterprise offline runner and empty allow-list mode.
RBAC & audit log
Six roles, eleven actions, seven columns, seven years.
The Driftlock control plane grants every action through an explicit RBAC matrix, denies any unlisted pair by default, and writes a seven-column row onto the audit ledger for every action that lands on a production PR. The matrix below is a summary; the full grant table, the RBAC deep-dive, the .driftlock/config.yaml snippet, and the seven-column per-PR row shape all live in the compliance reference.
human
admin
Provision / de-provision the deployment, rotate keys, manage IdP federation. Dual sign-off at the runtime before any grant executes.
human
security-reviewer
Approve signature-key rotation, approve break-glass changes, gate air-gap runbook changes. Reviewer verdict is signed at each handoff.
human
operator
Read audit/access logs, manage watchlist surfaces, route alerts. No write to ledger or signer; audit-only on the signing-controller.
automation
watcher-bot
Poll Dependabot / OSV / GHSA / PagerDuty / CI logs. Drafts branch, never signs, never writes the ledger.
automation
sandbox-runner
Runs the hermetic test replay inside the sandbox boundary. Emits the diff + SBOM, hands the resulting commit to the signing-controller.
service
signing-controller
Owns the KMS-resident keypair. Signs the commit + the SBOM; emits the Rekor transparency-log entry. Deny on every other action by default.
Audit field
Recorded
Retention
alert
Trigger source
The originating signal — CVE GUID, CI job URL, on-call incident id, NVD / OSV / GHSA reference.
7y hot · 10y cold
triage
Triage verdict
Reachability call, call-graph path, and the rule the watcher applied to mark the diff in-scope.
7y hot · 10y cold
drafted-fix
Drafted diff
Bytes-stable patch — same trigger re-run yields the same bytes, pinned to the sandbox run id that produced it.
7y hot · 10y cold
sandboxed-test
Sandbox test results
Toolchain identity, hermetic-build hash, the failing test that triggered the run, and the full sandbox log.
7y hot · 10y cold
approver-chain
Approver chain
Every reviewer who comments, approves, requests changes, or merges — GitHub identity, timestamp, signed verdict.
7y hot · 10y cold
signed-commit
Signature
Cosign signature over the commit + Rekor transparency-log entry + OIDC claim payload tying it to the sandbox run.
Indefinite · Rekor-logged
sbom
SBOM hash
SHA-256 of the CycloneDX document emitted in the same run + signature over the SBOM itself. Diff lockfile against SBOM hash.
10y hot · indefinite cold
SBOM & supply chain
A signed CycloneDX document, on every dependency-touching PR.
Every Driftlock run closes with two artefacts the security and supply-chain teams need to see — and they ship on every PR, not just the ones reviewers flag. The SBOM is cosign-signed with your SBOM key and lands in your artifact registry; the commit is cosign-signed with your signing-controller key and lands on the branch as a Rekor-anchored entry. Both signatures verify with the standard tooling a compliance team already runs.
SBOM
CycloneDX per PR.
Same fields a security reviewer and a supply-chain team both ingest without translation layer.
- format
- CycloneDX 1.5 (JSON + XML) · SPDX 2.3 alongside for downstream compliance tools
- trigger
- Every PR that touches a dependency boundary — lockfile, manifest, vendor path. Not opt-in, not on flagged PRs only.
- signer
- cosign · KMS-resident SBOM key (HSM on Enterprise)
- registry
- Your artifact registry — content-addressed (SBOM sha256 in the path). 10-year retention by default.
Signing
Ed25519 with Cosign / Sigstore OIDC.
The signing identity, algorithm, custody model, and rotation cadence — same on every commit.
- signer
- cosign / Sigstore OIDC (GitHub App identity)
- algorithm
- Ed25519 (cosign keyful)
- custody
- Private half never leaves your KMS — HSM via PKCS#11 on Enterprise. Driftlock reads only the public half when verifying prior signatures.
- rotation
- On the customer clock. 90-day KMS-managed rotation on the commit-signer key by default; rotation cadence is configurable in the chart.
- Rekor claim
- trigger · sandbox run · SBOM sha256 · approver_chain_root
SBOM ingest targets
Pulled directly from your artifact registry — no Driftlock-managed translation layer in the middle.
- deps.dev · supplier risk + dependency graph ingest
- Dependency-Track · SBOM-driven vulnerability triage
- Grype · container/repository vulnerability scan
- Internal compliance dashboards · pull directly from the registry
Signing verification
Verify the artefact, the signer, and the transparency record.
The evaluator flow is deliberately short: identify the signed commit or SBOM, resolve the signer and identity claim, verify the Ed25519 signature and Rekor inclusion, then reject any tampered or mismatched artefact. The signed claim binds the commit, SBOM hash, sandbox run, and approver-chain root into one reviewable record.
- 01
Identify the artefact
Start with the signed commit SHA or the CycloneDX SBOM emitted for that PR.
- 02
Resolve signer + claim
Resolve the signer’s public key and identity claim, including the linked commit and SBOM hashes.
- 03
Verify signature + Rekor
Verify the Ed25519 signature, then confirm the matching inclusion record in Rekor.
- 04
Reject mismatch or tampering
Fail closed when the artefact, signer identity, claim, public key, or transparency record does not match.
Customer-controlled custody
The private signing key stays in your KMS, or your HSM via PKCS#11 on Enterprise. Driftlock reads only the public half needed to verify prior signatures; key rotation remains on your clock.
Audit-log retention
Seven years hot. Ten years cold. Rekor evidence indefinitely.
The append-only per-PR audit record keeps its audit fields for 7y hot · 10y cold. The signed-commit evidence remains linked to its Rekor transparency record indefinite · rekor-logged, while the SBOM hash and signature follow their separate evidence policy of 10y hot · indefinite cold.
Per-PR record
Seven columns, one ledger row.
Trigger, triage, diff, sandbox result, approver chain, signature, and SBOM hash stay together as the record a reviewer replays. Replay and export follow the capabilities of the customer-managed storage and registry surfaces.
7 audit fields · append-only · 7y hot · 10y cold
Evidence classes
Retention follows the artefact.
- audit fields
- 7y hot · 10y cold
- Rekor link
- Indefinite · Rekor-logged
- SBOM evidence
- 10y hot · indefinite cold
Report a vulnerability
Researcher-first disclosure channel.
Driftlock operates a coordinated-disclosure channel that responds within two business days, scopes the severity, credits reporters by default, and works with researchers who prefer an embargo. The route lands on the platform-security inbox; the form below forwards through the installed contact-form module.
For cryptographic weaknesses, key-handling incidents, and supply-chain findings specifically — please mark the message security · cryptographic in the body so the platform-security on-call route picks it up on the same day.
Vulnerability disclosure
Report a vulnerability
Found something we should fix? Send it through our disclosure channel. We respond within two business days, scope severity, and credit you in the advisory — or work with you on coordinated disclosure if you'd prefer to handle it that way.
routed to the platform-security inbox · two-business-day first response · coordinated disclosure supported
The deep-dive reference
The four-section compliance record lives at /docs/compliance.
This page is the narrative — the short version a security reviewer reads first. The regulator-facing record — the RBAC matrix with a config snippet, the seven-column audit-trail row with immutability + retention, the SPDX document per merged PR, and the four cosign verifier commands — lives at /docs/compliance. Move between the two without re-aligning vocabulary.