Findings
One feed for everything ShellOrbit raises: what a finding holds, how to acknowledge and resolve it, and how long it is kept.
These pages describe ShellOrbit as it runs today. Breaking changes to the HTTP API are announced before they ship, and existing request and response shapes stay supported.
Every rule match, site check result, log drain hit, SDK report, silent source, and outbound host lands in one findings feed. Tripwire hits and incidents sit beside it on the overview.
What a finding holds
| Field | Meaning |
|---|---|
| Title | What happened, such as “Repository made public” |
| Severity | Critical, high, medium, or low |
| Source | Where it came from: a source, a site check, logs, or the SDK |
| Location | The detail: the source and repository, the AWS event and who made it, the page a key was in |
| Status | Open, acknowledged, or resolved |
| First and last seen | When it started, and when it last matched |
A key is only ever shown masked, such as sk_…a1b2.
Acknowledge and resolve
| Status | Use it when |
|---|---|
| Open | Nobody has looked yet |
| Acknowledged | Someone is on it. It stays in the feed, and does not alert again |
| Resolved | It is dealt with. A new match opens a new finding |
Members and above change status from the feed, or with POST /v1/leak/findings/{id}/status and {"status":"acknowledged"}. Each change records who made it and when, in the audit log. Findings from site checks, logs, silent sources, and incidents also resolve on their own once the evidence is gone.
Alerts
Critical and high findings alert straight away; see alerts for the channels and how often.
History
Findings and source events are kept for your plan’s history window: 15 days on Hobby, 30 on Starter, 60 on Pro, and 180 on Business.