Hunt our own code. Bug bounty, responsible disclosure, hall of fame.
Safeguard runs a public bug bounty for researchers willing to look at the platform itself. We pay for findings, we credit publicly, we patch.
What is in and out of scope.
In scope
- Production app at app.safeguard.sh
- Public marketing site (safeguard.sh)
- REST API endpoints exposed by the platform
- CLI binary distribution and update channel
- IDE extension binaries (VS Code, JetBrains)
- MCP Server reference implementation
- Lion weight verification flow and signing chain
Out of scope
- Customer tenants you do not own
- Sandbox tenants belonging to anyone other than you
- Social engineering of Safeguard staff or contractors
- Denial-of-service or volumetric attacks
- Physical attacks against Safeguard premises or staff
- Third-party integrations not owned by Safeguard
- Recently disclosed issues already in our advisory feed
What a finding is worth.
Specific amounts are documented in the bug bounty terms. The table below is how we think about severity vs reward.
| Tier | Severity | Reward | Notes |
|---|---|---|---|
| Tier 1 | Critical | Top-tier reward | Remote code execution against the control plane; cross-tenant data exposure; weight-signing key compromise. |
| Tier 2 | High | High reward | Authentication bypass; significant authorisation flaw; recovery of secrets from logs or storage; CSRF on a sensitive action. |
| Tier 3 | Medium | Moderate reward | Reflected XSS with practical impact; SSRF against an internal but non-sensitive surface; lesser tenant-data leaks. |
| Tier 4 | Low | Small reward + swag | Self-XSS with a believable trigger; rate-limit weaknesses; minor information disclosure; misconfigurations with limited impact. |
| Informational | Credit only | Public credit, no payout | Best-practice findings, hardening suggestions, theoretical issues without a working PoC, and useful research write-ups. |
Four steps, one inbox.
Reproduce in your own sandbox
Sign up for a free sandbox tenant — work only against resources you own. Do not test against another customer's tenant or production data under any circumstances.
Email security@safeguard.sh
Send a detailed write-up: affected component, reproduction steps, impact, and your PGP key if you want encrypted correspondence. Include a working PoC where applicable.
Acknowledge within 1 business day
We acknowledge inbound reports within one business day. You will hear from a Safeguard security engineer — not an autoresponder — with the next steps and an internal tracking ID.
Triage, reward, public credit
We triage, agree a remediation timeline, pay the reward on the agreed tier, and publish public credit on the advisory with your consent and chosen handle.
Credit where it is due.
Published quarterly
The hall-of-fame is published quarterly with researcher consent. We use the handle, attribution, and link you specify — or no attribution at all if you prefer to stay private.
For technical write-ups of remediated findings — by us and by researchers — see /research. We publish the analysis once the fix is in customer hands.
Good-faith research is protected.
Our commitment
Good-faith researchers operating within this programme are not pursued legally by Safeguard. We will not initiate or support legal action against researchers who respect scope, avoid disruption of customer environments, and report findings to security@safeguard.sh.
The full policy — including jurisdictional notes, conflict-of-laws guidance, and the conditions under which safe-harbour applies — is documented in the bug bounty terms.
Found something? Tell us.
One business day to acknowledge. A real engineer in the loop. Reward, credit, and a fix that lands.