Auto-Remediation Architecture
Overview
Auto-Remediation (T3.7) turns a finding from any scanner tier into an Infrastructure-as-Code patch and routes it through the delivery channel you pick. One of four modes applies per tenant, set from Remediation Settings:
- Dry-run — patches are generated and audit-logged, never auto-applied; an operator marks them applied or dismisses them. (Default; safe.)
- Pull Request — each new patch opens a PR (GitHub) or MR (GitLab) in the repository you nominate. Your reviewers merge.
- Approval queue — patches land in a pending-approval inbox; an admin clicks Approve to promote.
- Auto-apply — non-review-required patches apply automatically (
kubectl/terraform). Templates flagged as review-required still route through the approval queue.
The same pipeline runs in three deployment shapes — pick whichever matches your trust model.
The three tiers
Tier 1 — SaaS-side generator (default; works out of the box)
Patches are rendered server-side from new findings and your tenant's settings, then presented for review in the dashboard. Strict-ZK posture: SaaS has no plaintext access to the encrypted finding payload, so patch bodies carry REPLACE_ME placeholders instead of real resource names — your operator substitutes them during review.
- •Detects IOCs / processes / syscalls
- •AES-GCM encrypts sensitive fields
- •Ships ciphertext only
- •Reads the tenant's remediation settings
- •Picks template from 11-rule catalogue
- •Renders body with REPLACE_ME placeholders
Best for: every customer's first week. No infrastructure changes needed.
Tier 2 — Pull Request connector (your repo, your token)
Same generator, but in Pull Request mode the patch opens a PR/MR in *your* repository as soon as it is rendered. The access token is held in a managed secret store rather than our application database, so it survives a database compromise, and it never round-trips back through the dashboard after the initial paste.
- •mode
- •github_default_repo
- •github_api_base ← self-hosted GHE
- •github_token_secret (resource name)
- •Token held here, never in our database
- •Rotated in place
- •Only a reference is stored
- •TLS 1.2 floor + retry/backoff
- •Body cap 256 KiB + panic recovery
- •APIBase honours self-hosted hostname
Best for: teams that already gate infrastructure changes through PR review. Patches arrive with the rollback snippet pre-populated in the description.
Tier 3 — Agent-side full path (Master agent applies in your cluster)
The Master agent runs the remediation engine locally: it scans Kubernetes for misconfigurations (e.g. a missing default-deny NetworkPolicy), renders the patch, optionally applies it via kubectl / terraform, and audit-reports the outcome. SaaS sees only the audit row — no patch bodies, no resource names — unless your operator chose to apply, in which case the log reflects what actually ran. Mode and auto-apply are set at install.
Best for: regulated environments where exfiltration is unacceptable, or air-gapped clusters where the Master must apply patches itself. Agent-produced rows carry a green AGENT badge.
Self-hosted Git Enterprise
The connector handles GitHub Enterprise Server and GitLab self-hosted natively — each exposes the same REST API as its public counterpart, at a hostname you control. Bitbucket Data Center is not yet supported (open a feature request).
| Platform | Public default | Self-hosted format |
|---|---|---|
| GitHub.com | https://api.github.com | — |
| GitHub Enterprise Server | — | https:// |
| GitLab.com | https://gitlab.com/api/v4 | — |
| GitLab self-hosted | — | https:// |
An optional API base URL points at your instance; blank means public GitHub.com / GitLab.com. The token must come from that same instance. Required scopes: GitHub repo; GitLab api.
Network reachability: Tier 2 calls these APIs from our Cloud Run egress. If your Git server isn't publicly reachable, either allow-list our egress IPs (provided under NDA) or use Tier 3, where the Master pod reaches it from inside your network.
Where secrets live
| Item | Storage | Plaintext exposed to SaaS? |
|---|---|---|
| GitHub / GitLab token | Managed secret store, outside the application database | Only in transit at save time (HTTPS), never at rest |
| Patch body (Tier 1 SaaS) | Our platform | Yes (REPLACE_ME placeholders only — no resource names) |
| Patch body (Tier 3 Agent) | Our platform | Yes — your operator chose to delegate apply, so the row reflects what ran |
| Customer infrastructure code | YOUR GitHub / GitLab | No — we open a PR; your reviewer merges |
Choosing a mode (decision tree)
Operational notes
- Duplicate collapse — repeat detections collapse onto one row ("matched 12× · last 2m ago").
- Rotation — a new token supersedes the old one immediately; earlier versions stay available for audit and can be disabled.
- Rollback — every patch stores a reverse snippet; applied rows get a Rollback button, and on Tier 1 you run the snippet yourself.
- Dismiss — false positives are set aside with a reason, so re-detections don't re-noise the list.
- Failures surface on the row with the upstream error (a token missing
reposcope, a branch that already exists).
Next step
A call covers which mode fits your change process, which tier matches your trust model, and what Git and cluster access would look like. Talk to us about deployment