Stella Ops Coordinated Vulnerability Disclosure (CVD) Policy

Status: Published as an operational draft, pending live mailbox delivery/access checks and publication of a non-expired security-intake key.
Owner: Stella Ops maintainer of record.
Applies to: Vulnerabilities in Stella Ops itself (the BUSL-1.1 source distribution and Stella-published binaries, container images, and offline kits). Vulnerabilities in customer-deployed integrations or in third-party software running alongside Stella are out of scope for this policy unless they originate in code Stella publishes.
Last reviewed: 2026-04-30.

This policy implements Stella’s commitments under Cyber Resilience Act (Regulation (EU) 2024/2847) Annex I Part II §4-§6, and follows the ENISA Good Practice Guide on Vulnerability Disclosure as a process baseline.

Implementation status (verified against src/ on 2026-05-30). This is a human-readable process policy. The SLOs (§2), embargo handling (§3), disclosure timeline (§4), and CVE issuance (§5) are commitments enforced operationally by the product-security rotation — they are not encoded in any runtime-served JSON or runtime validator. What code actually serves is narrower: the Router Gateway (src/Router/StellaOps.Gateway.WebService/ProductMetadata/ProductMetadataDocumentProvider.cs) serves /.well-known/security.txt and /.well-known/stella-product-security.json, and its productSecurityContact block carries only intakeMailbox, policyUrl, and preferredLanguages — none of the SLO/embargo/CVE/escalation fields below appear in the served document. The structured intake schema product-cvd-policy-v1.mdthat mirrors these parameters is a documentation-only contract: no Stella service serializes, validates, or pins a productCvdPolicy@v1 document today. Treat anything described here as machine-checked or machine-served only where the cross-referenced contract docs say so.

1. Reporting a vulnerability

1.1 Primary intake

Email: security@stella-ops.org
PGP key: website-derived planning/key-lineage fingerprint 1A045258307194881527D2FE095C5809C63DBA65; this is not a live security-intake key fingerprint. Existing Stella release-signing PGP lineage was found for Stella Ops Release Signing <release@stella-ops.org>, but that key expired on 2025-07-30. The live rollout must publish a new non-expired encryption-capable security-intake key or subkey certified by that lineage at https://stella-ops.org/.well-known/stella-product-security-pgp.asc, then update the live metadata fingerprint if the ceremony produces a different intake-key fingerprint. The well-known endpoints must fail closed until that preflight passes.
Encrypted submission is preferred for issues rated High or Critical, but unencrypted reports are accepted and acknowledged on the same SLO.

Use the subject line prefix [security] so the report is routed correctly.

1.2 What to include

A useful report contains, at minimum:

Affected Stella component (module name from src/, image tag, CLI version, or release identifier).
Reproduction steps or proof-of-concept artifacts.
Impact analysis: what an attacker can read, modify, or escalate.
Disclosure intent: whether you plan to publish, when, and any constraints.
Credit preference: how you wish to be acknowledged in the published advisory. (Reality note: credit is currently recorded and honoured operationally. The CSAF advisory exporter (src/Notify/__Libraries/StellaOps.Notify.Connectors.Csaf/ProductCsafAdvisoryExporter.cs) does not yet emit a document.acknowledgments array, so machine-readable researcher credit in the CSAF feed is forward-looking, not current behaviour.)

1.3 Out-of-band escalation

If a report concerns an actively exploited vulnerability and the primary intake is unresponsive, escalate to product-security-escalation@stella-ops.org (the generic Stella Product Security Escalation Owner contact, on 24x7 paging for confirmed exploitation events).

1.4 Retention and access defaults

Stella retains vulnerability reports, triage records, embargo notes, advisory drafts, and fix-disposition evidence for 7 years from closure unless a legal hold or coordinated-disclosure agreement requires a longer period. Access to the primary mailbox and triage record is limited to dedicated-product-security-primary, dedicated-product-security-secondary, and dedicated-product-security-fallback; access is reviewed quarterly. Website access logs follow the public privacy baseline: 7 days, then sha256(ip).

1.5 Safe-harbour for good-faith research

Stella will not pursue legal action or law-enforcement referral against researchers who:

Make a good-faith effort to avoid privacy violations, service disruption, and data destruction.
Limit testing to systems you own or systems Stella explicitly invites you to test.
Do not publicly disclose details before the agreed disclosure date (see §4).
Do not attempt to exfiltrate, retain, or share customer data beyond the minimum needed to demonstrate the issue.

2. Service-level objectives

Stella commits to the following response targets, measured from the time the report is received at the primary intake mailbox.

Phase	Target	Notes
Acknowledgement	within 72 hours	Automated receipt is not an acknowledgement; a human responds within 72 hours.
Triage decision (severity assignment, accept/reject, planned disposition)	within 7 days for High and Critical reports	Other severities may take up to 14 days.
Workaround or fix availability for High and Critical	within 90 days target	Where a fix cannot be shipped in 90 days, Stella publishes a documented mitigation and a fix ETA.
Public advisory and CSAF feed entry	published with the fix or with the mitigation, whichever is earlier	See §4 disclosure timeline.

These targets follow the decisions log §CRA-Q1.

Severity is determined using CVSS v3.1 (or its successor when adopted by the wider ecosystem). Stella reserves the right to adjust the assigned severity based on real-world exploitability, deployment topology, and reachability evidence; any deviation from the reporter’s proposed score is explained in the advisory.

3. Embargo handling

Default disclosure window is 90 days from the date the report is acknowledged, extendable by mutual agreement.
Stella honours embargoes negotiated by reporters, including coordinated multi-vendor embargoes, when the embargo terms are reasonable and the reporter agrees to a fixed disclosure date.
During an embargo Stella will:
- Limit knowledge of the issue to the rotation, the assigned fix author, and (where unavoidable) directly affected enterprise customers under NDA.
- Avoid public commit messages, changelog entries, or issue tracker references that reveal the vulnerability before the agreed disclosure date.
- Maintain a private branch or feature-flagged fix until the embargo lifts.
Embargo extension requests must be made before the agreed disclosure date, in writing, with a justification.
If exploitation is observed in the wild during an embargo, Stella may unilaterally shorten the window after notifying the reporter; the reporter is given at least 24 hours’ notice unless ongoing harm makes immediate disclosure necessary.

4. Disclosure timeline policy

The default timeline for a confirmed High or Critical vulnerability is:

Day 0: report received.
Day 0-3: human acknowledgement issued; triage begins.
Day 0-7: severity confirmed, fix author assigned, advisory draft started.
Day 7-90: fix developed, tested, packaged, and queued for the next release train.
Day 90 (or earlier): fix released, advisory published in the product CSAF feed, CVE record published (see §5).

For Medium and Low severity issues, Stella may align disclosure with the next scheduled release rather than commit to a 90-day window. The advisory is still published when the fix ships.

5. CVE issuance

Stella issues CVE records for vulnerabilities in its own software through the MITRE / CVE Numbering Authority pathway:

For issues clearly within Stella-published code: Stella requests a CVE through MITRE’s CVE Request Form (or, once Stella becomes a CNA, allocates from its own CNA pool). The CVE identifier is included in the public advisory.
For issues affecting upstream dependencies that Stella vendors or repackages: Stella references the upstream CVE rather than issuing a duplicate, and notes the affected Stella version range.
For dual-locus issues (vulnerability in upstream code that is exposed because of how Stella configures or invokes it): Stella issues a Stella-side CVE in addition to the upstream record, scoped to the Stella exposure.

CVE records reference the Stella CSAF advisory by URL so downstream consumers can ingest both.

6. Publication channels

Once an advisory is published, Stella exposes it through:

The product CSAF 2.0 feed at the URL declared in /.well-known/stella-product-security.json (csafFeedUrl). The well-known document does emit csafFeedUrl and cveFeedUrl (the Router Gateway builds them by interpolating the canonical base URL — ProductMetadataDocumentProvider.GetProductSecurityJson). The individual CSAF advisory payloads are produced by the CSAF 2.0 exporter (src/Notify/__Libraries/StellaOps.Notify.Connectors.Csaf/ProductCsafAdvisoryExporter.cs), which emits CSAF v2.0 documents with CVSS v3.1 scores and a self reference plus an external CVE-record reference per vulnerability. Reality note: the declared csafFeedUrl/cveFeedUrl are static, base-URL-derived strings; the Gateway does not itself host or probe a live feed at those paths, and the published bytes are not validated for reachability.
The repository’s release notes.
An entry indexed by the cveFeedUrl declared in the same well-known document.
Direct notification to enterprise customers under support contracts via their configured Notify channels.

The security.txt file at /.well-known/security.txt (RFC 9116) points to this policy and to the well-known JSON document. Reality note: the Router Gateway serves this file as unsigned plaintext — ProductMetadataDocumentProvider.GetSecurityTxt builds the RFC 9116 body (the Contact, Encryption, Policy, Canonical, and Expires lines) with no inline PGP signature, and ProductMetadataMiddleware exposes no /.well-known/security.txt.sig route. PGP-signing the served file and publishing a detached security.txt.sig is a forward-looking operator obligation documented in security-txt.md§2/§4.2, not current runtime behaviour. The well-known endpoints carry no OAuth scope gate (there is no entry in StellaOpsScopes for this surface); access control is the fail-closed publication gate described in §7, not a scope.

7. Operational inputs to fill before publish

The following operational values must be confirmed and committed before this policy is announced as live to external researchers. Until live preflight passes, this policy is published as a draft and the well-known endpoints (/.well-known/security.txt, /.well-known/stella-product-security.json) must fail closed. The fail-closed behaviour is implemented in ProductMetadataDocumentProvider.TryBuildDocuments: the endpoints return 503 with an empty body unless platform.product.publishMetadata, sealedConfig, and releaseManifestSignatureVerified are all set, all eight ProductMetadataPreflightOptions booleans pass (MailboxDeliveryVerified, MailboxAccessVerified, KeyFreshnessVerified, KeyFingerprintVerified, PlacementAnchorVerified, SupportLifecycleVerified, RotationVerified, EscalationVerified), the canonical base URL is HTTPS, and the signed release manifest is present, schema-matched to the running build, and free of any TBD- placeholder. Caveat: the served pgpKey.fingerprint is the hardcoded constant 1A045258307194881527D2FE095C5809C63DBA65 regardless of which key the operator verified; the preflight booleans gate publication but do not substitute a verified live fingerprint into the served bytes.

[x] Select the security@stella-ops.org mailbox from the public website security page.
[x] Record website-derived PGP lineage fingerprint 1A045258307194881527D2FE095C5809C63DBA65.
[x] Assign generic dedicated rotation roles: dedicated-product-security-primary, dedicated-product-security-secondary, and dedicated-product-security-fallback.
[x] Assign generic escalation contact product-security-escalation@stella-ops.org.
[x] Record default mailbox retention/access model: 7-year report/triage retention, three-role access, quarterly access review, and public website access-log privacy baseline.
[x] Confirm live key path: create a new security-intake encryption-capable key or subkey certified by the website release-signing lineage during the Stella key ceremony.
[ ] Verify security@stella-ops.org mailbox delivery and live access control.
[ ] Generate, renew, or derive the security-intake PGP key from Stella’s key ceremony; publish the non-expired public key and confirm the live fingerprint in this policy and in /.well-known/stella-product-security.json (pgpKey.fingerprint).
[ ] Verify mailbox auto-acknowledgement does not leak triage information to the sender beyond a generic receipt.

These inputs are tracked operationally; they are not open product decisions.

8. Cross-references

Machine-readable product security metadata: /.well-known/stella-product-security.json (schema: ../contracts/stella-product-security-metadata-v1.md).
RFC 9116 security.txt template and operator runbook: security-txt.md.
CVD intake schema (versioned contract for the policy itself): ../contracts/product-cvd-policy-v1.md.
Placement-anchor ADR: ../legal/cra-product-placement-anchor.md.
Product classification ADR: ../legal/cra-product-classification.md.
Decisions log: ../europe/decisions-log.md §CRA-Q1.

9. Revision policy

This document is reviewed at least annually and whenever any of the following triggers fire:

Mailbox, PGP key, rotation, or escalation contact changes.
The CRA harmonised standards (M/606) materially change ENISA SRP intake or CVD process expectations.
The product CSAF feed format graduates from CSAF 2.0 to a later version.
A reported issue exposes a process gap (delay, miscommunication, embargo break) that warrants a policy change.

Revisions bump the policy contract version when any field semantics change. (Correction: the served /.well-known/stella-product-security.json document has no lastReviewed field; its only timestamp is lastModified, emitted verbatim from the sealed Platform:Product:GeneratedAtUtc configuration value — see ProductMetadataDocumentProvider.GetProductSecurityJson and stella-product-security-metadata-v1.md. The Last reviewed date lives in this policy’s header and in the productCvdPolicy@v1 intake schema’s lastReviewed field, neither of which is the served well-known JSON.)