Stella Supplier Evidence Profile v1

Contract ID: CONTRACT-STELLA-SUPPLIER-EVIDENCE-V1-001 Status: Draft Owner: Architecture Guild Schema version: stella-supplier-evidence-v1 Profile id: stella.supplier-evidence

Implementation status (verified against src/ 2026-05-30): this is a forward-looking schema. No serializer, validator, export profile, or endpoint for the stella-supplier-evidence-v1 payload exists in the codebase yet; the field set below is not produced or consumed by any service. What is implemented and tested is the reference to this profile by id (stella.supplier-evidence): the Assurance pack descriptors point at it via coverageSummary.supplierEvidenceProfile (src/Cli/StellaOps.Cli/Commands/Assurance/Descriptors/{nis2,dora,cra.product-security,cra.technical-documentation}.json, covered by AssurancePackCommandTests). The supplier-evidence export itself remains a roadmap item. Do not cite this profile as a delivered export.

Purpose

stella-supplier-evidence-v1 defines the supplier evidence Stella can provide when Stella Ops itself is part of a customer’s NIS2 or DORA software estate. It does not make Stella the customer’s regulated entity, financial entity, or manufacturer for the customer’s products.

Audience: Assurance-pack and ExportCenter planners scoping the supplier-evidence export, and operators who deploy Stella as an ICT third party and need to attach supplier evidence to their own NIS2/DORA records.

This profile reuses CRA product-security and release evidence where possible so customers can attach Stella supplier evidence to their own operator-owned NIS2/DORA records. It is the packaging of the stella-supplier evidence scope defined in Assurance Pack v1 — the same signed release, SBOM/VEX, support lifecycle, security-contact/CVD, build-attestation, and incident-notification facts surfaced by the CRA Product Security Pack (stella-product scope), re-expressed for an operator that deploys Stella as an ICT third-party.

Consumers

This profile is discovery/packaging metadata. It is referenced by:

Assurance Pack v1 — coverageSummary.supplierEvidenceProfile carries the profile id stella.supplier-evidence; the stella-supplier evidence-scope label and source-lane shape live there.
CRA Product Security Pack — lists this contract under Source Docs and states the stella-product facts can be repackaged as stella-supplier evidence.
Assurance pack descriptors for nis2, dora, cra.product-security, and cra.technical-documentation, each of which sets supplierEvidenceProfile = "stella.supplier-evidence".

It does not replace the module-owned contracts that produce the underlying artifacts (Stella Product Security Metadata v1, the signed SBOM archive spec, and the Attestor proof-chain spec).

Required Fields

Field	Type	Required	Notes
`schemaVersion`	string	yes	MUST be `stella-supplier-evidence-v1`.
`supplierId`	string	yes	Stable supplier id, normally `stella-ops`.
`productRef`	string	yes	Product or package identity for the Stella release.
`releaseVersion`	string	yes	Stella release version.
`releaseDate`	date	yes	Release date in UTC calendar form.
`supportLifecycleRef`	string	yes	Public or signed lifecycle evidence ref. Typically the `/.well-known/stella-product-security.json` document defined by Stella Product Security Metadata v1 (`supportPolicy` block).
`securityContactRef`	string	yes	CVD/security contact evidence ref. Typically `security.txt` or the `productSecurityContact` block of the product-security metadata document.
`signedReleaseRefs[]`	array	yes	Release manifest, signature, and verification refs.
`sbomRefs[]`	array	yes	SBOM artifact refs with hashes.
`vexRefs[]`	array	yes	VEX or advisory feed refs with hashes. May be empty only when no VEX exists for the release.
`buildAttestationRefs[]`	array	yes	Build/provenance/attestation refs.
`incidentNotificationProfile`	object	yes	Supplier incident notification posture and contact route refs.
`subprocessorRefs[]`	array	no	Stella support/subprocessor metadata refs when required by the operator workflow.
`evidenceHash`	string	yes	Canonical SHA-256 of the profile payload excluding `evidenceHash`.

Example

{
  "schemaVersion": "stella-supplier-evidence-v1",
  "supplierId": "stella-ops",
  "productRef": "pkg:oci/stellaops/control-plane@sha256:...",
  "releaseVersion": "2026.09.01",
  "releaseDate": "2026-09-01",
  "supportLifecycleRef": "https://www.stella-ops.org/.well-known/stella-product-security.json",
  "securityContactRef": "https://www.stella-ops.org/.well-known/security.txt",
  "signedReleaseRefs": ["dsse://releases/stellaops/2026.09.01"],
  "sbomRefs": ["cas://sbom/stellaops/2026.09.01"],
  "vexRefs": ["https://www.stella-ops.org/security/advisories/index.json"],
  "buildAttestationRefs": ["dsse://builds/stellaops/2026.09.01"],
  "incidentNotificationProfile": {
    "contactRef": "https://www.stella-ops.org/.well-known/security.txt",
    "pgpKeyRef": "https://www.stella-ops.org/.well-known/security.txt#encryption",
    "operatorNoticeRoute": "operator-controlled"
  },
  "subprocessorRefs": [],
  "evidenceHash": "sha256:..."
}

Determinism Rules

Arrays are sorted by ref using ordinal ordering.
Hashes use lower-case sha256: prefixes.
Ref values follow the platform URI conventions already used by the evidence spine: cas://... for content-addressed store objects (see Evidence Locker architecture), dsse://... for DSSE-enveloped release/build attestations, and https://... for published well-known/feed documents. These schemes are illustrative of the intended packaging; the supplier-evidence export that emits them is not yet implemented (see Implementation status).
The profile must not contain private keys, tokens, mailbox passwords, or service credentials.
Release candidates must re-check the profile links, signing key lineage, support lifecycle, and advisory feed status before publication.