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.
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
Cosign / Sigstore OIDC.
The signing identity, algorithm, custody model, and rotation cadence — same on every commit.
- signer
- cosign / Sigstore OIDC (GitHub App identity)
- algorithm
- ECDSA P-256 (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
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.