Quickstart reference — zero to your first overnight PR.

Connect GitHub

Install the Driftlock GitHub App — six steps from OAuth scope to a verified first delivery.

Every Driftlock trial begins with the GitHub App install. The six steps below are the day-one onboarding checklist — every row names both the platform-team action and the verification the operator runs to confirm the row landed. None of the steps ask for write scope on your repo; the Driftlock App manifest declares a read-only grant set and the platform team can revoke per-repo access without uninstalling.

install · select-repos · scope-oauth · webhook-subscription · receiver-ack · rbac-bootstrap

Scan cadence

Five cadences a reviewer learns on day one.

Five cadences a reviewer learns on day one. Each runs inside the in-VPC sandbox with default-deny egress; a 4-hourly re-scan picks up advisories that gain a CVE after the nightly sweep. The cron syntax mirrors the schedule documented on `/docs/self-host#cron-and-scheduling` — the platform team can move each row without rewriting the pipeline. /docs/self-host › cron-and-scheduling carries the cron-syntax reference the platform team owns.

02:14 nightly · on-PR <60s · 4-hourly re-scan · on-alert replay · sbom-reaper + rekor-prune

Rollback

Five steps the platform team runs on a bad merge.

When a merged PR needs to come back out — the test passes locally but fails in production, the CVE was mis-graded, or the lockfile churn unmasked a regression — the rollback recipe below is the canonical path. Every step is auditable; the cosign `verify-blob` confirmation ensures the head SHA on the Rekor log survives the revert. /docs/install › upgrade-rollback carries the install-side flip side of the same recipe — pre-flight, apply, rollback — for the platform team that owns the helm chart.

1. rollback · step 01

   Revert the merge commit and push

   Run `git revert -m 1 <merge-sha> && git push origin main`. The revert commit carries the original PR head SHA in its message; the watcher re-runs the pup-line SBOM delta table against the revert and stamps a new run id onto the audit-trail `drafted-fix` slot for the revert itself.

2. rollback · step 02

   Close any follow-up PRs that depended on the reverted SHA

   Run `gh pr close <pr-number>` on every PR that referenced the reverted head SHA in its `risk` section. Driftlock stamps a `reverted-by=<merge-sha>` trailer onto each closed PR so a future audit day can trace the chain.

3. rollback · step 03

   Re-open the /demo review queue

   On the /demo dashboard the queue card flips from `merged` to `reverted`. Reviewers get an inbox ping on every PR whose `risk` section still pins to the reverted SHA. The queue drift surfaces in the audit-trail `approver-chain` row — no PR is silently skipped.

4. rollback · step 04

   Stamp audit row `rollback-issued`

   The audit-trail row for the original merge receives a `rolled-back-by <revert-sha> at <UTC>` line. The existing Rekor claim stays valid — the rolled-back commit is still in the transparency log — but the live `signed-commit` row now points at the revert. A regulator tracing the chain reads the trail intact, with the rollback stamped onto the original row.

5. rollback · step 05

   Re-run cosign `verify-blob` against the SBOM sha256

   Run `cosign verify-blob --key kms://<your-kms-key-alias> --signature <sig-b64> <sbom-sha256>.spdx.json`. The exit code is `0` for already-verified commits: the Rekor claim is still valid even after the revert. The full upgrade / rollback lifecycle is documented on `/docs/install#upgrade-rollback`.

revert · pr-close · queue-reopen · audit-stamp · verify-blob · Rekor-anchored

Incoming notification

The wrapper shape — HMAC + signing header, then the alert-id pin.

The wrapper around the dependency advisory carries the same HMAC + signing-header surface every Driftlock inbound envelope uses — cryptographic signing covers the verifier path. The receiver-key on the in-VPC webhook receiver accepts the payload before the watcher pins the alert id, so a tampered advisory fails closed before the run begins.

{
  "delivery_id": "019284f3-1a6c-71e2-b4f1-9c8a7e2d4a55",
  "event": "dependency.advisory.detected",
  "webhook_id": "dependency-webhook",
  "advisory_id": "GHSA-xxxx-yyyy-zzzz",
  "source": "GHSA",
  "cve": {
    "id": "CVE-2026-9999",
    "cvss_v3": 7.5
  },
  "affected": [
    { "purl": "pkg:npm/lodash@4.17.20" }
  ],
  "call_graph": [
    "api/users",
    "middleware/audit",
    "utils/dep"
  ],
  "severity": "high",
  "first_detected": "2026-08-12T02:14:09Z",
  "ingested_at": "2026-08-12T02:14:11Z",
  "alert_id_hint": "driftlock-alert-2026-08-12-7421",
  "headers": {
    "X-Driftlock-Advisory-Signature": "t=1762884849,v1=2cf24d…",
    "X-Driftlock-Delivery":         "019284f3-1a6c-71e2-b4f1-9c8a7e2d4a55"
  }
}

dependency · advisory · detected · HMAC-SHA256 · alert_id hint