Product CVD Policy Contract v1

Contract: stella.ops/productCvdPolicy@v1 Status: Active — documentation / planning intake schema (not runtime-served). Sprint: SPRINT_20260430_001 Owner: Stella Ops maintainer of record (security) Schema-pinning policy: Pinned per Stella minor release; do not auto-track upstream policy templates. New fields require a v2 contract bump and a corresponding update to consumers of /.well-known/stella-product-security.json (served by the Router Gateway; see stella-product-security-metadata-v1.md). Deterministic fixture location: Golden examples for the served well-known metadata live in the Router integration tests (src/Router/__Tests/StellaOps.Gateway.WebService.Tests/Integration/ProductMetadataEndpointsTests.cs); the well-known endpoint sprint is SPRINT_20260430_002_Web_well_known_endpoints.md. This contract document is the source of truth for the CVD policy parameters. Replay/offline expectations: This document and any rendered intake JSON must be readable, parseable, and verifiable in offline-kit installations without external network access.

What this document is. A versioned, machine-checkable record of the agreed Coordinated Vulnerability Disclosure (CVD) policy parameters, kept aligned with the human-readable policy. It is not a runtime-served artifact: as of this revision no Stella service serializes, deserializes, or validates a productCvdPolicy@v1 document, and there is no runtime validator for this pin. The “runtime validators reject documents whose schemaVersion does not match a supported pin” guarantee is forward design intent — the Router validates the release manifest schema versions in ProductMetadataDocumentProvider, not this intake schema. See the Implementation status section below for the full doc/code reconciliation.

Purpose

Defines the structured intake schema that backs Stella’s public Coordinated Vulnerability Disclosure (CVD) policy (../security/coordinated-vulnerability-disclosure.md). The fields below mirror the policy parameters committed in that human-readable policy (SLOs, embargo handling, CVE issuance, escalation contact).

This contract is intended to be consumed by the systems listed below. Current implementation status (verified against src/ on 2026-05-30):

• The /.well-known/stella-product-security.json endpoint (served by the Router Gateway — src/Router/StellaOps.Gateway.WebService/ProductMetadata/ProductMetadataDocumentProvider.cs, route in ProductMetadataMiddleware.ProductSecurityJsonPath). Partial overlap only. The served document conforms to a different contract, stella.ops/productSecurityMetadata@v1 (see stella-product-security-metadata-v1.md). Its productSecurityContact block carries only intakeMailbox, policyUrl, and preferredLanguages. The CVD-policy SLO/embargo/CVE/escalation fields defined here are NOT emitted in that served JSON; they remain documentation-only commitments enforced operationally.
• Stella’s CSAF 2.0 advisory exporter (src/Notify/__Libraries/StellaOps.Notify.Connectors.Csaf/ProductCsafAdvisoryExporter.cs). NOT IMPLEMENTED as described. The exporter’s publisher block writes only category, name, and namespace; it does not stamp publisher.contact_details, and the exporter emits no document.acknowledgments array at all. This is forward design intent, not current behaviour.
• Documentation linters that verify the published policy and the structured intake remain in sync. Not present as an automated linter — the available offline check is the RFC 9116 security.txt linter (docs/security/securitytxt-rfc9116-lint.ps1), which does not validate this productCvdPolicy@v1 schema.

Implementation status (doc<->code reconciliation)

Verified against the main repo src/ tree on 2026-05-30. This section is authoritative for “what actually runs” versus “what this contract describes”.

Where this document previously implied runtime enforcement (“runtime validators reject…”, “consumed by the CSAF exporter when it stamps…”), treat those statements as forward design intent.

Schema version metadata

Any document carrying schemaVersion = stella.ops/productCvdPolicy@v1 MUST conform exactly to the field set below.

JSON shape and committed planning example

The example below records the approved CRA-Q1 planning defaults. It is not, by itself, proof that the public endpoint may go live. The pgpFingerprint value is website-derived release-signing lineage evidence for the Stella key ceremony; live publication still requires a non-expired encryption-capable security-intake key or subkey, and the served metadata must use the verified live intake-key fingerprint if it differs from the lineage fingerprint.

{
  "schemaVersion": "stella.ops/productCvdPolicy@v1",
  "intakeMailbox": "security@stella-ops.org",
  "pgpFingerprint": "1A045258307194881527D2FE095C5809C63DBA65",
  "pgpKeyUrl": "https://stella-ops.org/.well-known/stella-product-security-pgp.asc",
  "acknowledgementSloHours": 72,
  "triageSloDays": 7,
  "remediationSloDays": 90,
  "embargoPolicy": {
    "defaultDisclosureWindowDays": 90,
    "extensionPolicy": "by-mutual-agreement",
    "exploitInTheWildOverride": "stella-may-shorten-after-24h-notice"
  },
  "cveIssuanceMode": "mitre-cve-request",
  "escalationContact": "product-security-escalation@stella-ops.org",
  "lastReviewed": "2026-04-30"
}

Field definitions

Validation rules

These are conformance rules for a productCvdPolicy@v1 document and for the human-authored CVD policy it mirrors. They are not enforced by an automated runtime validator today (see “Implementation status”); they describe the constraints a future validator MUST apply and the manual review checklist used until then.

• intakeMailbox MUST be a deliverable mailbox before the CVD policy is announced as live. (The Router fails the served well-known endpoint closed via the MailboxDeliveryVerified / MailboxAccessVerified preflight flags in ProductMetadataPreflightOptions; this CVD document is not itself served.)
• pgpFingerprint MUST be either a 40-character hex fingerprint (uppercase, no spaces) or the literal placeholder TBD-confirm-after-key-creation.
• acknowledgementSloHours <= 72. Documents with a higher value are non-conformant.
• triageSloDays <= 7 for the High/Critical baseline.
• remediationSloDays <= 90 for the High/Critical baseline.
• lastReviewed MUST be no more than 365 days in the past when the policy is announced as live. (This document is reviewed at least annually per coordinated-vulnerability-disclosure.md §9; the field is not consumed by the well-known endpoint, which uses the release-manifest lastModified/generatedAtUtc instead.)

Field-level rationale (audit trail)

Operational preflight

The committed 2026.9 planning document no longer contains placeholder values for pgpFingerprint or escalationContact.

The well-known endpoint (/.well-known/stella-product-security.json) MUST still fail closed when the live mailbox or PGP key preflight fails, and the served security.txt MUST NOT advertise a contact channel until those values are operationally verified.

Operational retention/access default: retain vulnerability reports, triage records, embargo notes, advisory drafts, and fix-disposition evidence for 7 years from closure; restrict mailbox/triage access to dedicated-product-security-primary, dedicated-product-security-secondary, and dedicated-product-security-fallback; review access quarterly. This is an operational default, not an additional v1 JSON field.

Revision log