Architecture

self-hosted topology

audit-linked

Repo → watcher → sandbox → gated PR, inside your VPC.

Driftlock runs as a single deployment in your cloud account. Four signal sources feed a watcher that drafts a branch against an existing CI identity; a hermetic sandbox reproduces the test that triggered the run, signs the resulting commit, regenerates the SBOM, and opens a pull request your reviewers can actually merge.

Posture

One Helm + Terraform deployment in your VPC. No data leaves your network; no third-party LLM is ever called.

Identity

Cosign / Sigstore keys live in your KMS. OIDC federated to your IdP. Commits, SBOMs, and CI identities stay yours.

Audit

Every PR links the alert, log, or advisory that produced it — so a reviewer never asks "where did this come from?".

The pipeline, end to end

One overnight cron, eight steps, one signed PR.

The brief: an overnight dependency-scan trigger fans into a hermetic sandbox; the sandbox runs a parameterized test matrix against the failing regression; the resulting commit is ed25519-signed over commit_sha || sbom_sha256; the SBOM delta versus the last PR hash, and the audit-log row, both land on the PR — all inside your VPC. Each step on the diagram maps to an in-page anchor below.

overnight scan → sandbox bootstrap → isolation → test matrix → ed25519 sign → SBOM delta → audit-log write → gated PR · all inside your VPC

Pipeline step
Overnight scan
A fixed 02:00 UTC cron fans NVD, GHSA, OSV, and your internal advisory mirror into a single scan.yml decision per repo.
Read on ↓
Pipeline step
Sandbox isolation
A fresh network namespace mounts the same toolchain as CI; egress is restricted by policy and reviewed at deploy time.
Read on ↓
Pipeline step
Test matrix
A parameterized matrix runs against the failing regression first, then fan-outs unit, integration, and nightly-e2e in order.
Read on ↓
Pipeline step
ed25519 PR signing
cosign-keyful, signing (commit_sha || sbom_sha256); keypair lives in your KMS and verifies in the GitHub UI.
Read on ↓
Pipeline step
SBOM delta attachment
CycloneDX diff versus the previous PR hash lands as the artefact attached to the PR — reviewable in one click.
Read on ↓
Pipeline step
Audit-log write path
pg_append → KMS-signed at write → S3/OCI mirror → Rekor transparency row → immutable by the PR record.
Read on ↓

Step 01 · Overnight scan

Overnight dependency scan.

A fixed cron at 02:00 UTC triggers an overnight dependency-scan against NVD, GHSA, OSV, and your internal advisory mirror. The scan fans into a single scan.yml decision per repo — the artefact that wakes the watcher and steers the next branch draft. Continuous reads from the watcher (push, PR, advisory webhook) feed the same ingest set, so the overnight beat and the always-on desk land in the same ledger.

Why overnight and not just webhook: transitive advisories that don't carry a webhook take six to eighteen hours to surface; an overnight beat guarantees that every repo gets at least one scan window per day, even when CI is asleep.

Scan trig

schedule: cron · 02:00 UTC
feeds: NVD · GHSA · OSV · advisory mirror
always-on: webhook ingest (push · PR · advisory)
artefact: scan.yml · advisory-vector

see install runbook · cron wiring →

Step 02–03 · Sandbox isolation

Hermetic sandbox. No implicit egress.

The watcher bootstraps a fresh network namespace per run (sandbox bootstrap) and mounts the same toolchain and test cache your CI already uses — hermetic, reproducible, byte-for-byte across reviewers. Environment isolation is policy: egress is restricted and reviewed at deploy time, and the sandbox can't pull a third-party model call because that destination is not on the allow-list.

The same posture carries to the air-gapped offline runner on the Enterprise tier — nothing about isolation is cloud-specific. The sandbox retains its identity even when the network is severed.

Isolation guarantees

Same toolchainHermetic Nix / Bazel.
Fresh netnsPer-run, no cross-talk.
No implicit egressPolicy-allow-listed destinations only.
Topology-aware cacheOnly the trigger path re-runs.

see /security · isolation posture →

Step 04 · Test matrix

A parameterized test matrix. Failing regression first.

The sandbox runs a parameterized test matrix — unit, integration, and nightly-e2e — with the exact failing regression from the CI log replayed first. The matrix is fan-out against the trigger path: only the touched package and its direct consumers rerun, the rest stays warm in the topology-aware cache.

Tier selection is decided at triage: a CVE triggers unit + integration; a flaky-test or post-incident triggers the full matrix including nightly-e2e. The failing-test replay comes first regardless, so the regression stays reproducible.

Matrix tiers

unit: always · first
integration: always · second
nightly-e2e: on regression or incident
regression replay: failing test first

see install runbook · tier config →

Step 05 · ed25519 PR signing

Ed25519 PR signing. The signature is the PR's identity.

Once the test matrix is green, the sandbox signs the resulting commit with ed25519 over the compound claim commit_sha || sbom_sha256, using a cosign-keyful keypair that lives in your KMS and rotates on your schedule. The signature is verifiable in the GitHub UI with no extra plugin; on the PR, it becomes the PR's verifiable identity — reviewers can confirm the commit, the SBOM, and the signer in one click.

The signing claim is two-part on purpose: commit_sha pins the source, and sbom_sha256pins the supply-chain artefact. A reviewer who ever sees drift between the two can't pass the signature — and the SBOM delta below carries the version of the supply chain that produced this PR.

Step 06 · SBOM delta attachment

The SBOM delta. The artefact attached to the PR.

The sandbox regenerates a CycloneDX SBOM on every dependency-touching PR and diffs it against the SBOM of the previous PR on the same branch. The diff — the sbom.json + delta.json pair — is the artefact attached to the pull request. A reviewer can read the delta in one click and see exactly which packages changed, what version moved where, and which transitive edges picked up a new advisory.

The full SBOM stays in your artifact registry; the delta is what lands on the PR description itself, because that's the surface a reviewer scans at review time. CycloneDX 1.5 (JSON + XML), cosign-signed in your KMS, mirrored to your registry.

SBOM delta · attachment

format: CycloneDX 1.5 (JSON + XML)
artefact: sbom.json + delta.json
trigger: every dependency-touching PR
signing: cosign · your KMS
landing: PR description · artifact registry

see /governance · SBOM delta format →

Step 07 · Audit-log write path

Audit-log write path. Append-only, KMS-signed, mirrored to Rekor.

Each pipeline step writes a row to a pg_append table inside the customer deployment. The write path is: row produced → KMS-signed at write → mirrored to your S3/OCI bucket → transparency-logged to Rekor. Once written, a row is never mutated — the path is append-only by construction, signed at write time, and replayable from Rekor on demand.

The same write path underpins the four audit-log rows (ingest, branch-draft, sandbox-run, PR) shown further down the page. Every PR links the rows that produced it, so a regulator can replay a PR back to the alert, log line, or CVE GUID that triggered it without trusting the customer's tooling.

see /governance · write-path reference →

pg_append → KMS-signed at write → S3/OCI mirror → Rekor entry → never mutated

The topology, on one page

Four signal sources, one sandbox, two artefacts, one PR.

The spine reads left to right: your repositories feed a watcher that operates against the same test identity as you; the watcher drafts into a reproducible sandbox whose outputs become a CycloneDX SBOM and a signed commit; the sandbox hands a human-reviewable pull request to your queue.

Repo → watcher → sandbox → gated PR · offshoots: SBOM generation + commit-signing

Inputs

Four inputs the watcher reads continuously.

Where the alerts come from. Each surface is read through an app or sink you already own — Driftlock does not require new credentials per source. The watcher runs as an always-on desk — it polls each surface on the customer's own cadence, drafts a branch the moment a signal lands, and never sleeps through a paged alert.

See every connector we ship

source control · CI · on-call · advisory feeds · secrets

Source
GitHub repos
Webhook events for pushes, PRs, branch updates, and Dependabot alerts — ingested through a GitHub App your team owns.
Source
CI pipelines
Build logs, flaky-test reports, and job failure telemetry fed in from your CI so the watcher knows what already failed in this monorepo.
Source
Dependency feeds
NVD, GHSA, OSV, and your internal advisory mirror. CVE vector, severity, and call-graph reachability land in the same record set.
Source
On-call alerts
PagerDuty and Opsgenie incidents, plus dashboard SLO burns. The watcher treats a paged alert the same as a CVE — both become a branch draft.

Triage issue generation

One signal becomes one branch draft.

The watcher fans the four inputs into a single classification: which expander will author the fix, which tier the sandbox should run at, and which existing branch to base the draft on. That decision lands as a branch_draft row in the ledger, linked to the ingest payload digest that produced it — so the audit trail can always replay a PR back to the alert, log line, or CVE GUID that triggered it.

Stage
Ingest
Four sources fan into a single ledger row: GitHub webhooks, CI failure telemetry, dependency advisories, and on-call pages. Each lands with a verified payload digest.
Stage
Triage
The watcher classifies the signal — dependency, regression, posture, alert — and attaches the chosen expander, target tier, and the branch it will draft against.
Stage
Dispatch
A branch_draft row is written to the audit ledger, linked to the ingest payload digest, and routed into the sandbox queue at the tier the triage step chose.

ingest 🎯 triage 🎯 dispatch

The sandbox

A reproducible sandbox, not an LLM.

Driftlock's sandbox is a hermetic runner, not a generative agent. It mounts the toolchain and test cache your CI already uses, replays the exact regression that triggered the branch, and produces a deterministic diff. There is no free-form reasoning at the test step — the sandbox can only run code.

Network egress is restricted by policy and reviewed at deploy time. The sandbox cannot pull a third-party model call, because that destination is not on the allow-list. The same posture applies to the offline runner we ship for air-gapped deployments.

What the sandbox guarantees deterministically

Same toolchainHermetic Nix / Bazel — build is reproducible byte-for-byte across runs and reviewers.
Same cacheShared, topology-aware test cache. Only the trigger path reruns; the rest stays warm.
Replay of regressionThe exact failing test from the CI log runs first, before the diff — the regression stays reproducible.
No network outside VPCEgress is restricted by policy; no implicit calls to third-party LLMs at any step.

reproducible sandbox · hermetic · bounded egress

Side-effects

Two artefacts the sandbox produces on every run.

Each sandbox run closes with the two artefacts your security and supply-chain teams need to see — and they ship on every PR, not just the ones reviewers flag.

Artefact · SBOM

SBOM generation

A CycloneDX SBOM is regenerated on every PR that touches a dependency boundary, signed with your SBOM-signing key, and uploaded to your artifact registry. Old SBOMs are kept against the PR hash so a reviewer can compare what changed.

format: CycloneDX 1.5 (JSON + XML)
trigger: every dependency-touching PR
signing: cosign · your KMS
landing: your artifact registry

Artefact · Commit

Commit-signing

Commits are signed with cosign / Sigstore against the GitHub App identity. The keypair lives in your KMS — or your HSM on the Enterprise tier — and rotates on your schedule. The signature is verifiable in GitHub UI without any extra plugins.

identity: ed25519 · cosign keyful
claims: ed25519 (commit_sha || sbom_sha256)
rotation: your schedule · KMS-managed
verify: GitHub UI · gh CLI

Audit trail

Every run writes four rows a regulator can replay.

Each Driftlock run produces four rows — an ingest record, a branch-draft record, a sandbox-run record (carrying both the SBOM + signature hashes), and a PR record — written append-only, signed at write time, and exportable on demand. The same row lands on /app/audit and in the Rekor transparency log, so an auditor can replay any PR back to the alert, log line, or CVE GUID that produced it.

Ledger row

Ingest record

Pinned to the source delivery_id, signed by the receiver key, with payload digest and the signature-verification status the watcher wrote at receive time.

Ledger row

Branch-draft record

Links the ingest record to the commit it authored — and carries the triage decision: which class of signal, which expander, which tier the sandbox will run at.

Ledger row

Sandbox-run record

Run id, SBOM hash, ed25519 signature over `commit_sha || sbom_sha256`, trigger-path diff size, and the CI-test replay outcome — written at run close, idempotent on retry.

Ledger row

PR record

Links the three rows above, the PR description’s trigger link, the reviewer list, and the final sign-off timestamp your auditor reads.

Append-only ledger

Written once, mirrored to your bucket, replayable from Rekor.

Each row above is written through a pg_append table inside the deployment, mirrored to your S3/OCI bucket, and never mutated after sign-off. Export the full ledger as CycloneDX-style JSON, or look up any PR by its Rekor transparency-log entry id — same row, two surfaces.

Data residency + key custody

Audit viewer

Self-host runbook

pg_append · S3/OCI mirror · Rekor entry per PR · no row mutation after sign-off

Self-hosted deployment

Driftlock runs inside your perimeter; nothing leaves.

A single deployment lands in your VPC or cloud account — watcher, sandbox, SBOM pipeline, and signing stack — and the GitHub, CI, and on-call signals cross your perimeter boundary to reach it. No outbound model calls, no third-party LLM, no data exfil: egress is restricted by policy and reviewed at deploy time.

GitHub · CI/OIDC · on-call → your perimeter → watcher → sandbox → gated PR · egress restricted · keys in your KMS

What crosses the boundary

Read-only ingress

Each ingress surface is a one-way tap the customer already owns. Driftlock receives the signal and produces an audit-linked PR; it does not call back out to third-party endpoints at any step.

GitHub: App webhook · push / PR / advisory
CI: OIDC · build logs · flaky-test reports
On-call: PagerDuty · Opsgenie · SLO burn
direction: inbound only · no egress

Enterprise tier extras

Hardened posture, on request

For teams that need a tighter envelope, the Enterprise tier swaps the standard KMS-managed keys for HSM-backed signing, ships an air-gapped runner, and delivers an on-prem Helm chart for fully disconnected deployments.

keys: HSM-backed · customer-controlled
runner: air-gapped · offline-capable
chart: on-prem Helm · no internet egress
support: named CSM · 99.9% SLA

Enterprise tiersee full pricing breakdown

The handoff

A pull request you can actually approve.

Every PR links the alert, log, or CVE GUID that triggered it — so a reviewer can traverse from the page to the trigger in one click. Driftlock never lands on a protected branch without human review, and the diff stays within the trigger path: large refactors require opt-in and are out of scope for the sandbox by default.

See a sample morning PR

renders one synthetic overnight scenario · interactive sign-off · audit-trail timeline

CI hook flow

trigger ↔ PR

PR description links the alert, log line, or CVE GUID that produced it.

scope

Diff stays within the trigger path; no opportunistic refactors.

sign-off

Protected branches always require human approval; land step is reviewer-driven.

Reference docs are next

Read the self-hosting runbook in /docs.

The architecture page is the summary; the full reference — sandbox egress policy, KMS-backed signing, Helm charts, air-gapped runbook — already lives in /docs. Jump straight to the runbook, or keep this page open.

Self-hosting runbook

SBOM deep-dive

Audit-trail & SBOM story

Compare on alternatives

CI hook flow

isolation guarantees

key handling

on-prem runbook