Vulnerability disclosure policy

OrbitalReg accepts vulnerability reports from anyone — security researchers, customers, contributors, accidental discoverers — under a coordinated-disclosure model. This page is the canonical long-form policy.

The short form lives in SECURITY.md at the repository root and is the version GitHub renders on the Security tab.

How to report

Email security@orbitalreg.com. The mailbox is monitored by the OrbitalReg security team during European business hours and on a best-effort rotation outside them.

For findings that include a working exploit, captured traffic, credentials, or any data that should not transit unencrypted, please encrypt with our PGP key:

• Public key: orbitalreg-security-pubkey.asc (generated and published before the first paid-tier release — placeholder until then)
• Fingerprint: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000(placeholder — the production key will be generated and published before the first paid-tier release; see Operational notes below).
• The fingerprint is also published on keys.openpgp.org and on keyserver.ubuntu.com for cross-verification.

Do not open a public GitHub issue for a suspected vulnerability. The issue tracker is mirrored to customer dashboards by the demo-seeder and would surface the report prematurely.

For non-security bugs, the GitHub issue tracker is the right channel.

What to include in a report

A complete report covers:

• Affected component — api, frontend, tools/cli, tools/k8s-operator, charts/orbitalreg, the release pipeline, or one of the docs sites — and the version that reproduces (orbital --version, image tag, chart version).
• Reproduction steps — a failing curl, a minimal repro repository, or a unit-test diff against main is ideal. The faster we can reproduce, the faster we can confirm severity and start work on the fix.
• Impact assessment — what does an attacker gain, against which deployment posture (air-gapped / SaaS / single-tenant / multi-region) and which authentication state (anonymous / read-only token / org-admin)?
• Suggested CVSS if you have one. We will recompute and may agree or disagree, but it speeds triage.
• Credit preference — name (or alias) for the Hall of Fame, or a request to remain anonymous.

What we promise

Step	Target
Initial triage + agreed severity	within 7 calendar days
Coordinated disclosure window	90 days (default)
CVE assignment (if eligible)	via MITRE during triage
Fix released to commercial-tier	as soon as available
Public advisory + open-source release	end of disclosure window

We extend the 90-day window only by mutual agreement with the reporter — for example when the fix requires a coordinated upstream change (Postgres, MinIO, a Go runtime CVE) that we cannot ship faster.

We will keep the reporter in the loop for the duration of triage. If we cannot reproduce we will say so and ask for follow-up artefacts; we will not silently close the report.

Scope

In scope

• The API server under api/.
• The single-page frontend under frontend/.
• The CLI under tools/cli/.
• The Kubernetes operator under tools/k8s-operator/ and the CRD bundle published via the release pipeline.
• The Helm chart under charts/orbitalreg.
• The release pipeline (signed images, signed Helm chart, air-gapped tarball, operator install manifest, license-issuer CLI under tools/license-issuer/).
• The license verifier and license-envelope shape.
• The signed-pull / Sigstore-trust-policy paths.
• The pull-gate engine and admin surface.

Out of scope

• Marketing sites (orbitalreg.com landing pages, status page on status.orbitalreg.com). Report to the email above and we will treat as informational.
• Bot infrastructure / CI runners themselves.
• Third-party dependencies — please report upstream first; if the issue is in how OrbitalReg uses the dependency, that is in scope.
• Volumetric DDoS, social-engineering of OrbitalReg staff, physical security of contributor laptops.
• Trial-license envelopes and seed data — both are intentionally signed by a publicly-documented dev key (see the License-issuer section in the release pipeline page).
• Findings that require root on the OrbitalReg host as a pre-condition. The host is part of the trust boundary; an attacker with root on it is already inside.
• Issues that only manifest under non-default development flags (--allow-dev-key, ORBITALREG_DEV_BYPASS=1, etc.) where the flag itself is documented as production-unsafe.

Bug-bounty programme

OrbitalReg does not currently run a paid bug-bounty programme. We do maintain a public Hall of Fame for accepted reports — see below — and reporters who prefer to stay anonymous can opt out at submission time.

We will update this section if a paid programme launches.

Coordinated disclosure timeline

A typical timeline once a report is accepted:

Day	Step
0	Reporter sends initial email; auto-reply confirms inbox.
0–2	Security team acknowledges with a triage ticket ID.
0–7	Triage call (optional) + agreed severity + agreed window.
7–	Engineering work begins; reporter updated weekly.
W-7	Pre-disclosure email to commercial-tier customer list.
W-0	Patch tagged on the release pipeline; public advisory
	drops on the GitHub Security tab; docs-site write-up;
	Hall of Fame updated.

W is the agreed disclosure window — usually 90 days from the initial acknowledgement. The pre-disclosure email gives operators time to schedule the patch window before details go public; it does not include working exploit code.

Worked example

Below is a non-real example timeline so a reporter knows what to expect.

Day 0, 14:32 UTC — Researcher emails security@orbitalreg.com with a finding: the public-config endpoint leaks the active SAML IdP entity ID even when branding is set to hide it.

Day 0, 14:34 UTC — Auto-reply: "Thanks — your report has reached us. A human will respond within 48h. Track ID ORBSEC-2026-014."

Day 1 — Triage email: "Confirmed. CVSS 4.3 (low). 90-day window starts today. Are you OK with credit as 'Jane Doe' in the Hall of Fame?"

Day 12 — Fix lands on main. Reporter cc'd on the PR.

Day 35 — Pre-disclosure email goes to commercial-tier customer list with the patched version number and the recommended upgrade window.

Day 90 — Public advisory drops on GitHub Security tab. Docs-site write-up with the root cause. Hall of Fame updated to credit Jane Doe. Reporter pings to confirm public credit looks correct.

Hall of Fame

Reporters who have contributed accepted vulnerability reports to OrbitalReg. Listed in chronological order of disclosure. Anonymous reporters are listed as Anonymous; we never publish contact details.

No advisories have been disclosed yet. This section will be populated as the project receives reports and ships fixes.

Operational notes

The PGP key referenced above is a placeholder. A production 4096-bit RSA (or Ed25519) key will be generated, the public half published at /security/orbitalreg-security-pubkey.asc, and the fingerprint embedded in this page and in SECURITY.md. The private key is backed up in a password-manager vault under a hardware-token- gated entry; subkey rotation policy follows the Operations runbooks once the first production key is in place.

Until then, reporters who require encrypted transport are welcome to send an initial un-encrypted email asking for an ad-hoc public key, and we will respond with a short-lifetime key generated on a vetted host.