Security

Security is Orbit’s own audit surface for your registered projects — separate from the Convergence Gate, which reviews a single prompt’s diff. Security looks across a project’s working tree (or its recent Git history) for saved credentials, vulnerable dependencies, and risky code patterns, then walks you through deciding what to do about each one.

Two ways to look

Every audit runs one or more deterministic scanners against your working tree: a saved-secret pattern check, a dependency audit (npm lockfiles, and pinned Python requirements when present), and — only when Semgrep is installed — a set of bundled Semgrep rules. These checks are local and free; no source leaves your machine.

A Deep review additionally sends redacted source, bounded to a limited number of files, to a configured model provider for a closer read of code patterns a deterministic scanner can’t reason about. It needs a ready account or credits, and Orbit is explicit that this uses your account before it runs: redaction and model review can still miss context or findings, and Orbit does not claim a full audit or ASVS compliance from it. A history profile runs the deterministic checks against your Git history instead of the working tree, bounded to the 50 most recent commits.

Findings and their lifecycle

Each problem Security surfaces is a finding: a title, a plain-language impact statement, a severity (Urgent, Important, or Smaller), and one or more occurrences with masked evidence. A finding stays open until you act on it. From there it can be:

Set aside — as not a problem, an accepted risk, or deferred to a future date — with a required reason. This is reversible.
Marked fixed, pending an independent re-scan that actually confirms it.
Verified, when a fresh targeted audit confirms the underlying condition is gone.
Regressed, if a later audit finds the same condition again after it looked resolved.

A not-a-problem decision on an eligible finding can optionally create a future-match suppression — a policy that keeps matching findings from resurfacing on later audits. It only applies where a finding is marked suppression-eligible, requires an explicit opt-in, and can be disabled again at any time; every matching finding still stays in Orbit’s record even while suppressed.

Secret findings carry an extra step: fixing the code that exposed a credential doesn’t make you safe on its own, so Security also tracks whether the credential itself was rotated or revoked with its provider, separately from the code fix.

Reviewed fixes

Security never edits your code directly. For a finding it can address, it builds a fix preview — a source-bound, scoped proposed change tied to a previewHash. You review the exact diff, then approve that one preview by its unchanged hash. If the underlying source drifts or the preview goes stale, approval fails and a fresh preview is required. There is no bulk approval anywhere in Security — not for a single finding’s fix, and not for a plan’s steps.

Fix plans (campaigns)

When an audit turns up more than one priority finding, Security can build a fix plan: a sequenced, phased list of steps derived from that audit, ordered so shared fixes and secrets come first. Starting a plan turns it into a running campaign, but a campaign changes nothing about the approval model — each step still gets its own preview and its own individual approval, and a step that depends on a prior rotation stays blocked until that rotation is confirmed. A plan can be exported as a portable Markdown report at any time.

The OWASP ASVS checklist

For a completed audit baseline, Security exposes an OWASP ASVS 5.0.0 checklist scoped to that baseline and project, at a chosen cumulative level (1, 2, or 3). This is a reviewer record, not an automated pass: each control needs a human status (unassessed, needs-work, evidence-recorded, or not-applicable) and, outside of “unassessed,” written evidence. Orbit never calculates or claims a certification from these records — they exist so a human reviewer’s rationale is captured alongside the automated findings.

Schedules

A weekly deterministic audit schedule re-runs the same scope on a cadence and compares each run against the one before. Deep review is deliberately excluded from scheduling: a recurring model review would spend account credits without a per-run approval, so Security refuses to create a recurring Deep schedule — only the deterministic standard and history profiles can be scheduled. If a schedule’s project or scanner scope changes, its comparison series doesn’t silently carry forward; the schedule pauses rather than joining an older baseline it’s no longer measuring.

Safety principles

Security is built around a small set of guarantees that hold everywhere in the surface:

One audit at a time. Starting a new audit while one is already running is refused outright.
Cancellation is never a clean result. A cancelled or partially-completed run is recorded as cancelled or partial — never rewritten into a clean, all-good outcome.
Evidence is masked. Occurrence text shown in findings has known secret patterns and configured vault values redacted before it’s ever displayed or stored.
Approvals are single-item and hash-bound. Every fix and every campaign step is approved one at a time, against the exact preview you reviewed — never in bulk, and never against a preview that’s gone stale.
Recurring Deep reviews are refused. A schedule can only run deterministic audit profiles, so a model-backed review is never spent on your behalf without you asking for it that run.