Coordinated disclosure. Signed receipts. No silent fixes.
Jelleo is an AI-driven security audit firm. This page describes how to report security issues against Jelleo itself, how Jelleo handles findings against its audit targets, and how to verify a signed cycle receipt — in your browser, without trusting us.
How to report
If you have found a security issue in Jelleo itself — the audit engine, the hypothesis library, the CLI, the dashboard, the website, the in-browser scanner, or the signing/attestation key handling — please report it directly to us.
Machine-readable contact details are published at /.well-known/security.txt (RFC 9116).
For findings Jelleo has produced against a third-party protocol, the protocol maintainer is the disclosure target — Jelleo's role is to coordinate that disclosure. Direct disclosures from external researchers about a Jelleo customer's protocol are routed via the same email above.
What is in scope, what is not.
In scope
- The audit engine (audit-pipeline-cli) — CLI, hypothesis library, findings DB, dashboard
- The Jelleo website source (
website/deploy/) - The Ed25519 signing implementation (
src/audit_pipeline/commands/sign.py) - The in-browser scanner on the Solana Security Standard page (
standard/sss-scan.js) - The on-chain attestation program (jelleo-attestation, devnet)
- Any signed Jelleo cycle receipt that is claimed but cryptographically invalid
Out of scope
- The programs Jelleo audits (report those upstream — Jelleo will help coordinate)
- The Anthropic API, the Solana RPC providers, or other third-party services Jelleo depends on
- Self-XSS, missing security headers absent demonstrable impact, or other low-impact web findings without an exploit chain
- Issues requiring physical access to the maintainer's workstation
- Social engineering attacks against Jelleo personnel
Jelleo maintains the open Solana Security Standard — 52 rules across 8 surfaces (source: github.com/Copenhagen0x/solana-security-standard). Issues in those rules — false positives, missed cases, regex DoS — are reported via the standard's own SECURITY.md rather than here. The same email (security@jelleo.com) reaches both queues.
For findings Jelleo produces
Jelleo follows a coordinated-disclosure model. The defaults below are floors; specific engagements may extend any of them by mutual agreement.
Timeline
| State | Action | Default duration |
|---|---|---|
confirmed | PoC reproduces. Disclosure email sent to the maintainer with a private GitHub issue or alternative. | Day 0 |
disclosed | Maintainer acknowledged. Embargo begins. | 30 days |
fixed (in window) | Maintainer ships patch within the 30-day window. Public disclosure proceeds coordinated. | within 30 days |
fixed (extension) | Maintainer requests extension — granted by default for active fix work, up to 90 days total. | 30–90 days |
| Public release | Writeup, PoC, fix bundle, attestation made public. | Day 30 or after fix |
| No-acknowledgement | If no acknowledgement after 14 days of repeated outreach, public disclosure proceeds. | Day 30 |
Embargo conditions
- Critical findings affecting deployed mainnet protocols receive maximum embargo flexibility — Jelleo will not publish until a fix is shipped or the protocol's funds are no longer at risk.
- High findings against active protocols default to 30 days, extensible to 90.
- Medium / Low / Info findings default to public disclosure on the next regular cadence (weekly or monthly rollup).
- Embargo duration is recorded in the signed cycle receipt (methodology §08).
Findings are sent to maintainers before any third party.
Customers, partners, and Jelleo employees do not receive in-embargo finding details until the embargo lifts.
Every finding eventually becomes public — either with a fix in place or with the maintainer's explicit acknowledgement that no fix will ship.
Jelleo does not sell findings. It does not sell early access to findings. Customers receive findings against their own protocol; nothing more.
External researchers who report platform vulnerabilities are credited in the disclosure unless they request anonymity.
How to verify a Jelleo signature.
Every Jelleo cycle produces an Ed25519-signed receipt. The signing public key is published at one canonical URL, mirrored elsewhere — every copy must match, and a mismatch is itself reportable.
https://api.jelleo.com/keys/jelleo.ed25519.pub— canonicalhttps://jelleo.com/keys/jelleo.ed25519.pub— same-origin mirrorkeys/jelleo.ed25519.pubin the engine repo- Referenced from methodology §08
To verify a Jelleo signature:
$ curl -sO https://api.jelleo.com/keys/jelleo.ed25519.pub
$ audit-pipeline sign verify <file> <file>.sig --pubkey jelleo.ed25519.pub
✓ VALID signature on <file>If a signature does not verify, do not trust the file. A failed verification means either the file has been altered since signing, or the file was not signed by the published Jelleo key. Either case warrants a direct report to security@jelleo.com.
Bug bounty
Jelleo does not currently operate a formal bug bounty program. We extend courtesy compensation for impactful findings on a case-by-case basis, and credit every reporter who wants it (see below).
Researcher honor roll
We thank every researcher who has improved Jelleo's security. As of the date below, no external researchers have reported platform vulnerabilities. This list will grow.
Last updated: 2026-05-07.