Stella Ops Security Policy & Responsible Disclosure
Version 4 · 2026‑07‑28
This policy explains how to report a vulnerability in Stella Ops, what to expect from our coordinated-disclosure process, and the safeguards that protect every release. It is written for security researchers, downstream packagers, and operators who need to verify the integrity of what they deploy.
0 · Supported versions 🗓️
| Release line | Status | Security fix window |
|---|---|---|
| v1.0.0-RC1 | Current release candidate | Until v1.0 GA |
| v1.0 GA | Planned LTS | 24 months from release |
Earlier pre-release builds are not supported; upgrade to the current release candidate. Pre‑GA lines receive critical and high‑severity fixes only.
1 · How to report a vulnerability 🔒
| Channel | PGP‑encrypted? | Target SLA |
|---|---|---|
security@stella-ops.org | Yes – PGP key: /keys/#pgp | 72 h acknowledgement |
Matrix DM → @sec‑bot:libera.chat | Optional | 72 h acknowledgement |
Public issue with label security | No (for non‑confidential flaws) | 7 d acknowledgement |
Please include:
- Affected version(s) and environment
- Reproduction steps or PoC
- Impact assessment (data exposure, RCE, DoS, etc.)
- Preferred disclosure timeline / CVE request info
2 · Our disclosure process 📜
- Triage – confirm the issue, assess severity, assign CVSS v4 score.
- Patch development – branch created in a private mirror; PoCs kept confidential.
- Pre‑notification – downstream packagers & large adopters alerted 72 h before release.
- Co‑ordinated release – patched version + advisory (GHSA + CVE) + SBOM delta.
- Credits – researchers listed in release notes (opt‑in).
We aim for 30 days from report to release for critical/high issues; medium/low may wait for the next scheduled release.
3 · Existing safeguards ✅
| Layer | Control |
|---|---|
| Release integrity | cosign signatures + SPDX SBOM on every artefact |
| Build pipeline | Reproducible, fully declarative CI; SBOM diff verified in CI |
| Runtime hardening | Non‑root UID, distroless‑glibc base, SELinux/AppArmor profiles, cgroup CPU/RAM caps |
| Access logs | Retained 7 days, then sha256(ip) hash |
| Air‑gap support | Signed Offline Update Kit (OUK) validated before import |
| Secure defaults | TLS 1.3 (or stronger via plug‑in), HTTP Strict‑Transport‑Security, Content‑Security‑Policy |
| SBOM re‑scan | Nightly cron re‑checks previously “clean” images against fresh CVE feeds |
4 · Cryptographic keys 🔑
| Purpose | Key material | Fingerprint |
|---|---|---|
| PGP (sec‑team) | /keys/#pgp→ https://stella-ops.org/keys/pgp.asc | Published on that page, computed from the key file itself |
| Cosign release key | /keys/#cosign→ https://stella-ops.org/keys/cosign.pub | Published on that page, computed from the key file itself |
Fingerprints are not reproduced here so that this document cannot drift out of step with the key material. Take them from /keys/, or derive them yourself:
# PGP (OpenPGP v4 fingerprint)
curl -sSL https://stella-ops.org/keys/pgp.asc | gpg --show-keys --fingerprint
# Cosign public key (SHA-256 of the published file)
curl -sSL https://stella-ops.org/keys/cosign.pub | sha256sum
Verify all downloads (TLS 1.3 by default; 1.2 allowed only via a custom TLS provider such as GOST):
cosign verify \
--key https://stella-ops.org/keys/cosign.pub \
registry.stella-ops.org/stella-ops/stella-ops:<VERSION>
5 · Private‑feed mirrors 🌐
The Concelier (vulnerability ingest/merge/export service) provides signed JSON and Trivy DB snapshots that merge:
- OSV + GHSA
- (optional) NVD 2.0, CNNVD, CNVD, ENISA, JVN and BDU regionals
The snapshot ships in every Offline Update Kit and is validated with an in‑toto SLSA attestation at import time.
6 · Hall of Thanks 🏆
We are grateful to the researchers who help keep Stella Ops safe. Acknowledged reporters are listed here, by release, on an opt-in basis.
| Release | Researcher | Handle / Org |
|---|---|---|
| No entries yet | Your name here | — |