Governance
The audit trail, the signature, and the SBOM — laid out the way a regulator asks.
Driftlock produces three artefacts on every audit-linked PR: a per-PR record a regulator can replay, a cosign signature over the commit that survives a key rotation, and a CycloneDX SBOM a compliance tool can ingest without translation. The three sections below lay out exactly what lands, where it lives, and how a buyer verifies it.
Audit trail
Every per-PR datum recorded, retained, and replayable from the trigger source to the approver chain — verifiable without a Driftlock-managed control plane.
Commit signing
Cosign / Sigstore OIDC against the GitHub App identity. Key lives in your KMS (or HSM on Enterprise); signatures verify in the GitHub UI without extra plugins.
SBOM emission
CycloneDX 1.5 in JSON and XML, signed on every dependency-touching PR, landed in your artifact registry and ingestable by deps.dev, Dependency-Track, and Grype.
Audit trail
What lands on every pull request — and where it lives.
Regulated buyers do not ask whether a tool has an audit log; they ask what fields land on a row, who records them, and what survives a key or tool rotation. Driftlock records the same seven-column row on every PR — alert id, triage verdict, diff bytes, hermetic-build hash, approver chain, signature, and SBOM hash — and retains them in the customer's own storage tier.
The diff itself is bytes-stable: the same trigger re-run yields the same patch, the same patch yields the same SBOM, and reviewer sign-off is signed at each handoff so a later rotation cannot relocate an approval.
replay by sandbox run id · 7-year hot + 10-year cold retention by default
Field
Recorded
Retention
column
Trigger source
value
The originating signal: Dependabot advisory GUID, CI job URL, on-call incident id, or NVD / OSV / GHSA record pulled into the watcher.
retention
7 years hot · 10 years cold
column
Triage record
value
Reachability call, call-graph path, and the rule the watcher applied to mark the diff in-scope. Stored alongside the alert id the watcher triaged.
retention
7 years hot · 10 years cold
column
Diff
value
The exact patch proposed for review — bytes-stable, byte-identical across reruns, and pinned to the sandbox run id that produced it.
retention
7 years hot · 10 years cold
column
Sandbox test results
value
Toolchain identity, hermetic-build hash, the failing test that triggered the run, and the full sandbox log. Verifiable by replaying the run id.
retention
7 years hot · 10 years cold
column
Approver chain
value
Every reviewer who comments, approves, requests changes, or merges the PR — GitHub identity, timestamp, and the review verdict, signed at each handoff.
retention
7 years hot · 10 years cold
column
Signature
value
Cosign / Sigstore signature over the commit, including the Rekor transparency-log entry and the OIDC claim payload tying it to the sandbox run.
retention
Indefinite · Rekor-logged
column
SBOM hash
value
SHA-256 of the CycloneDX document emitted in the same run, plus the signature over the SBOM itself — so a reviewer diffs the lockfile and the SBOM hash together.
retention
10 years hot · indefinite cold
Commit signing
Who signs, where the key lives, and how a reviewer verifies.
Driftlock signs commits with cosign / Sigstore against the GitHub App identity — the same identity used to open the PR. The private half of the signing key never leaves the customer's KMS; the Enterprise tier swaps to an HSM and keeps the same Rekor-logged claim payload on every signature. A reviewer verifies the commit without installing anything: GitHub UI, the GitHub CLI, or cosign itself.
Rotation is on the customer's clock, not Driftlock's. When the key rotates, older signatures still verify against the corresponding Rekor entry — a buyer months into a rotation cycle does not lose its previous signed PRs.
cosign · Sigstore OIDC · Rekor-logged · KMS-resident private key
Signing identity
Cosign / Sigstore OIDC against the GitHub App identity. Claims payload:
- signer
- cosign / Sigstore OIDC (GitHub App identity)
- key mode
- Keyful cosign · KMS-resident private key
- custody
- The private half never leaves your KMS — Enterprise tier swaps to your HSM. The watcher reads only the public half when verifying prior commits.
- claims
- trigger · sandbox run · SBOM hash · approver
Verification
Cosign · verify-blob on the SBOM
cosign verify-blob --bundle sbom.bundle --certificate-identity-regexp ".*" sbom.json
GitHub CLI · verify the PR attestation
gh attestation verify --owner <org> <sha>
Cosign · verify the commit signature
cosign verify --certificate-identity-regexp ".*" <sha>
verify in GitHub UI · gh CLI · cosign · no extra plugins
SBOM emission
A signed CycloneDX document, on every dependency-touching PR.
Every PR that touches a dependency boundary emits a fresh CycloneDX 1.5 document in both JSON and XML — the same shape a compliance tool can ingest without translation. The document is cosign-signed with the customer's SBOM key and lands in their artifact registry; downstream tooling pulls it from there on its own cadence.
SBOM contract
The contract a downstream tool reads. The format, the trigger, the signer, and the landing surface — same on every run.
- format
- CycloneDX 1.5 · JSON and XML (byte-identical across reruns)
- trigger
- Every PR that touches a dependency boundary (lockfile, manifest, or vendor path)
- signer
- cosign · your KMS-resident SBOM key (HSM on Enterprise)
- registry
- Your artifact registry — searchable, immutable, retention-pinned
Downstream ingest
Read straight from your artifact registry — no Driftlock-managed translation layer in the middle.
- deps.dev · supplier risk and dependency graph
- Dependency-Track · SBOM-driven vulnerability triage
- Grype · container and repository vulnerability scan
- Internal compliance dashboards · pull directly from the registry
registry → deps.dev · Dependency-Track · Grype · internal dashboards
Compliance pack
Request the SOC 2 pack, the key-handling runbook, and the audit-trail replay.
The compliance pack ships under NDA: the SOC 2 Type II report, the air-gapped deployment runbook, and a documented walkthrough of how a regulator replays an audit-linked PR on their own tooling. Submit your buyer email and we'll send the pack within two business days.
Request the compliance pack
Drop your buyer or platform-security email below and we'll send the pack from the same inbox that scoped your trial. No follow-up sequence.