Export Center Profiles

Export Center profiles define what data is collected, how it is encoded, and which distribution paths are enabled for a run. Profiles are tenant-scoped and deterministic: identical selectors and source data produce identical bundles. This guide summarises built-in profiles, configuration fields, schema conventions, and compatibility notes.

Profile catalogue

Profiles can be cloned and customised; configuration is immutable per revision to keep runs reproducible.

Provisioning & CRUD model

There are two distinct profile classes, and they are provisioned differently. Conflating them is the source of the “export profiles have no CRUD” confusion — one class is fully CRUD-able, the other is intentionally read-only.

1. Tenant export profiles (ExportProfile entity) — full tenant CRUD, backed by Postgres and audited. These are the profiles operators create/clone/customise:

   • GET /v1/exports/profiles (scope ExportViewer) — list
   • GET /v1/exports/profiles/{profileId} (ExportViewer) — read one
   • POST /v1/exports/profiles (ExportOperator, audited create_profile) — create
   • PUT /v1/exports/profiles/{profileId} (ExportOperator, audited update_profile) — update
   • DELETE /v1/exports/profiles/{profileId} (ExportAdmin, audited delete_profile) — archive (soft-delete)
   • POST /v1/exports/profiles/{profileId}/runs (ExportOperator) — start a run

   The console currently wires only the read side (listProfiles); create/update/archive are available on the API and are the intended console follow-up. This is an FE-wiring gap, not a missing backend.

2. Assurance / compliance export profiles (NIS2 / DORA / CRA — the AssuranceExportProfileRegistry) are provisioned via ExportCenter service configuration (AssuranceExportOptions, Nis2SoaExportOptions) and are read-only by design. They are discovery/readiness descriptors bound to signed adapters/routes; there is deliberately no create/update/delete surface. Change them by editing the ExportCenter service config and redeploying (see the Assurance export profile catalogue and architecture). Their read surface is /v1/exports/assurance/profiles.

Assurance export profile catalogue

The generic Assurance registry uses dot-form profile ids and is exposed at /v1/exports/assurance/profiles. These descriptors are discovery/readiness records; execution remains adapter-owned or route-owned by the compatibility surface.

Every built-in Assurance profile sets signingRequired=true and supportsOfflineVerification=true. Readiness fails closed and reports stable reason codes without exposing secret/config values.

DORA route-owned profile targets

DORA RoI is a built-in fail-closed Assurance readiness descriptor and an HTTP-expressible source-supplied produce path. Web/CLI can render stable blocked readiness reasons instead of probing a missing route; when a request supplies a complete dora-roi.v1 register and ownerApprovalRef, ExportCenter materializes the signed RoI ZIP, validates the vendored EBA taxonomy package, and signs with operator-owned Export:Assurance:DoraRoi key material. The descriptor does not fetch workflow data, does not claim regulator submission, and never accepts signing key material from the request body. The ZIP wrapper uses the same DoraRoiBundleAssembler manifest/signature shape as stella export dora-roi --offline, so deterministic HMAC HTTP output can byte-match the CLI; HTTP-only approval/source refs remain request/readiness metadata instead of artifact fields. In deployed images, Export:Assurance:DoraRoi:TaxonomyPackagePath may point at a mounted read-only copy of the pinned EBA outer ZIP; readiness uses that same configured path before clearing dora-roi-schema-mapping-missing.

Other DORA handoff routes remain documented target profiles so Web/CLI can use stable ids. TLPT is HTTP-expressible only by delegating to EvidenceLocker. Major incident and information sharing are HTTP-expressible when the request supplies the Notify-owned source payloads and JSON-friendly Notify channel DTOs; ExportCenter maps those DTOs into the existing Notify contracts and does not invent workflow state.

dora.major-incident-report HTTP produce accepts { "doraMajorIncidentReport": { "report": <DoraMajorIncidentReportInput>, "channel": <AssuranceProduceNotifyChannelInput>, "producedAt": "..." } }, uses the Notify DORA major-incident encoder/outbound handoff, and signs with operator-owned Export:Assurance:DoraMajorIncidentReport HMAC material. Its wrapper media type is application/vnd.stellaops.dora-major-incident-report.http-bundle.v1+json.

dora.info-sharing HTTP produce accepts { "doraInfoSharing": { "request": <AssuranceProduceDoraInfoSharingExportRequest>, "subscriberApprovalRef": "..." } }, maps the request DTO into Notify DoraInfoSharingExportRequest, emits the Notify STIX/TAXII/DSSE artifacts, and signs with operator-owned Export:Assurance:DoraInfoSharing HMAC material. Its wrapper media type is application/vnd.stellaops.dora-info-sharing.http-bundle.v1+json.

dora.tlpt-evidence-pack HTTP produce accepts { "tlptEvidencePack": <CreateTlptEvidencePackRequest> } and delegates to EvidenceLocker POST /api/v1/evidence/capsules/tlpt-packs. ExportCenter persists the sealed EvidenceLocker response JSON as the Assurance run artifact; it does not assemble, sign, or mutate TLPT evidence locally. The delegated call still requires EvidenceLocker authorization/tenant context in deployed environments.

Common configuration fields

Selectors (time windows, tenants, products, SBOM subjects, ecosystems) are supplied per run, not stored in the profile.

JSON profiles

json:raw

• Content: Exports raw advisories, VEX statements, and SBOMs as newline-delimited JSON (.jsonl.zst).
• Schema: Follows canonical StellaOps schema with casing and timestamps normalised. Each record includes tenant, source, linkset, and content fields.
• Options:
  • include defaults to ["advisories", "vex", "sboms"].
  • compression defaults to zstd level 9.
  • maxRecordsPerFile (optional) splits outputs for large datasets.
• Compatibility: Intended for analytics platforms, data escrow, or feeding downstream normalisation pipelines.
• Sample manifest excerpt:

{
  "profile": { "kind": "json", "variant": "raw" },
  "outputs": [
    { "type": "advisories.jsonl.zst", "sha256": "...", "count": 15234 },
    { "type": "vex.jsonl.zst", "sha256": "...", "count": 3045 },
    { "type": "sboms.jsonl.zst", "sha256": "...", "count": 872 }
  ],
  "selectors": { "tenant": "acme", "products": ["registry.example/app"] }
}

json:policy

• Content: Everything from json:raw plus:
  • policy_snapshot.json (policy metadata, version, hash).
  • findings.policy.jsonl.zst (evaluated findings with decision, rationale, rule id, inputs hash).
• Determinism: Requires a policy snapshot id; runs fail if snapshot is missing or non-deterministic mode is active.
• Use cases: Compliance exports, auditor packages, policy attestation archives.
• Guardrails: AOC boundaries preserved: policy outputs are clearly partitioned from raw evidence.

Trivy profiles

trivy:db

• Detailed adapter behaviour is documented in docs/modules/export-center/trivy-adapter.md.
• Content: Produces a Trivy DB-compatible bundle (SQLite database or tarball as required by Trivy version).
• Mapping rules:
  • Advisory namespaces mapped to Trivy vendor IDs (e.g., ubuntu, debian, npm).
  • Version ranges translated into Trivy’s semantic version syntax.
  • Severity mapped to Trivy standard (UNKNOWN, LOW, MEDIUM, HIGH, CRITICAL).
• Validation: Adapter enforces supported Trivy schema versions; configuration includes targetSchemaVersion.
• Distribution: Typically pushed to OCI or object storage for downstream scanners; Console download remains available.

trivy:java-db

• Refer to docs/modules/export-center/trivy-adapter.md for ecosystem-specific notes.
• Content: Optional Java ecosystem supplement for Trivy (matching Trivy’s separate Java DB).
• Dependencies: Requires Java advisories in Findings Ledger; run fails with ERR_EXPORT_EMPTY if no Java data present and allowEmpty=false.
• Compatibility: Intended for organisations using Trivy’s Java plugin or hardened pipelines that split general and Java feeds.

Mirror profiles

mirror:full

• Bundle structure and delta strategy are covered in docs/modules/export-center/mirror-bundles.md.
• Content: Complete export with:
  • Raw advisories, VEX, SBOMs (/data/raw).
  • Policy overlays (/data/policy), including evaluated findings and policy snapshots.
  • Indexes for fast lookup (/indexes/advisories.pb, /indexes/sboms.pb).
  • Manifests and provenance (/manifests/export.json, /manifests/provenance.json).
• Layout: Deterministic directory structure with hashed filenames to reduce duplication.
• Encryption: Optional encryption block enables age/AES-GCM encryption of /data. strict=true encrypts everything except export.json.
• Use cases: Air-gap replication, disaster recovery drills, Offline Kit seeding.

mirror:delta

• See docs/modules/export-center/mirror-bundles.md for delta mechanics and application order.
• Content: Includes only changes relative to a base manifest (specified by baseExportId when running).
  • changed, added, removed lists in manifests/delta.json.
  • Incremental indexes capturing only updated subjects.
• Constraints: Requires the base manifest to exist in object storage or artifact registry accessible to the worker. Fails with ERR_EXPORT_BASE_MISSING otherwise.
• Workflow: Ideal for frequent updates to mirrored environments with limited bandwidth.

CRA profiles

cra:tech-file

• Content: Produces the deterministic cra-tech-file-v1 bundle described in docs/contracts/cra-tech-file-v1.md.
• Generic registry profile: cra.technical-file.
• Use cases: Annex VII technical documentation for Stella releases or customer products with immutable evidence refs.
• Signing: Local file-backed exports use HMAC DSSE for offline tamper checks. Production exports default to Signer/KMS-backed DSSE, can opt into cadenced DSSE+CAdES companion metadata, and record durable EvidenceLocker regulatory audit and ledger rows once the archive hash is known.
• Determinism: Uses canonical JSON and fixed tar/gzip metadata. Missing control-register inputs or production CAdES provider packs are recorded as blockers.

cra:conformity-dossier

• Content: Embeds tech-file/cra-tech-file.tar.gz and adds conformity-dossier-v1 overlays from docs/contracts/conformity-dossier-v1.md.
• Generic registry profile: cra.conformity-dossier.
• Module selection: Module A is the Stella default. B+C adds EU type-examination/test-certificate overlays. H adds full-QMS and ISO/IEC 27001 control-effectiveness overlays.
• Use cases: Self-assessment-ready Module A packages, notified-body evidence packs, and full-QMS customer-product dossiers.
• Determinism: Same inputs and selected module produce byte-identical bundles. Missing module evidence is represented by explicit blocked overlays rather than fabricated data.

Standards profiles

standards:mapping

• Content: Produces the deterministic standards-mapping-bundle-v1 archive described in docs/contracts/standards-mapping-v1.md.
• Targets: iso27001, iec62443-4-1, iec62443-4-2, en303645, and jrc-cra. All targets map to local YAML files under docs/europe/standards-mapping/; jrc-cra requires reviewed non-zero rows and no blocker state before publication.
• Use cases: Standards evidence crosswalks for NIS2 Article 21 control discussions, CRA standards evidence, procurement questionnaires, and auditor handoff.
• Determinism: Uses local files only, canonical JSON, fixed tar/gzip metadata, DSSE-signed index output, and explicit blockers for draft or pending review states.

NIS2 profiles

nis2:statement-of-applicability

• Content: Produces the deterministic nis2-soa-v1 signed bundle described in docs/contracts/nis2-soa-v1.md.
• Generic registry profile: nis2.statement-of-applicability.
• Inputs: Policy control-register snapshot, Authority tenant compliance profile, EvidenceLocker bundle ref, signing key/provider, storage root, and tenant export trust roots.
• Use cases: NIS2 Statement of Applicability handoff, auditor evidence review, and operator release/compliance records.
• Fail-closed behavior: Missing Authority profile access, storage root, signing key/provider, or tenant export trust roots blocks production export. Fixture data may be used for tests but must not be reported as live SoA evidence.

nis2:effectiveness-report

• Content: Produces the deterministic nis2-effectiveness-report-bundle-v1 JSON bundle described in docs/contracts/nis2-effectiveness-report-v1.md.
• Generic registry profile: nis2.effectiveness-report.
• Inputs: A local nis2-effectiveness-dashboard-v1 source report, a normalized yyyy-MM month, signing key material, and optional target document, Policy snapshot, and control-register snapshot references.
• HTTP produce (Sprint 20260616.003): POST /v1/exports/assurance/profiles/nis2.effectiveness-report/runs (scope export.operator) materializes the signed monthly bundle by reusing Nis2EffectivenessExporter verbatim; the run-based response carries a bundleDownloadUrl (GET /v1/exports/assurance/runs/{runId}/bundle). The request body supplies the data inputs ({ nis2Effectiveness: { reportMonth, sourceReport, ...refs } }); the HMAC signing key is operator-owned config only (Export:Assurance:Nis2Effectiveness:SigningKeyFile, preferred key-custody file, or :SigningKey for lab/dev) — it is never accepted in the request body, and the path fails closed (409 effectiveness-signing-material-missing) when no key material is configured. The HTTP output is byte-identical to the CLI for the same frozen inputs.
• Use cases: Monthly NIS2 effectiveness evidence packs for offline audit review, including the 13 thematic areas, live KPI readings, target state, linked controls, and explicit blockers.
• Determinism: Canonical JSON, fixed manifest entry paths, report hash excluding its self-reference, and local HMAC DSSE output. Production CAdES/KMS signing is not claimed by the file-backed CLI path.
• Fail-closed behavior: The adapter rejects source reports that do not contain exactly 13 ordered NIS2 areas and records missing upstream hashes/refs as blockers instead of inventing target, control-register, or policy evidence.

Compatibility and guardrails

• Aggregation-Only Contract: All profiles respect AOC boundaries: raw evidence is never mutated. Policy outputs are appended separately with clear provenance.
• Tenant scoping + approvals: Profiles are tenant-specific. When selectors.tenants includes additional tenants or wildcards, approval.required=true plus approvedBy and ticket must be present (validated by verify-export-kit.sh and schema).
• Retriable runs: Re-running a profile with identical selectors yields matching manifests and hashes, facilitating verify-on-download workflows.
• Offline operation: JSON and mirror profiles function in offline mode without additional configuration. Trivy profiles require pre-seeded schema metadata shipped via Offline Kit.
• Quota integration and backpressure: Profiles declare limits.maxActiveRuns, limits.maxQueuedRuns, and backpressureMode (reject|defer|throttle). When limits trigger, exporters emit 429 with X-Stella-Quota-* plus Retry-After to keep retries deterministic.
• Concelier tactical exporter compatibility: In-Concelier export:json maps to the JSON profile family, export:trivy-db maps to trivy:db, and feedser-bundle/1.0 must expose manifest/cursor/digest/signature metadata that Export Center runs can represent when ownership moves. stellaops-mirror-seed-v1 is not a routine Export Center profile; it is disaster-recovery / replication only. See ADR-003.

Example profile definition (CLI)

{
  "name": "daily-json-raw",
  "kind": "json",
  "variant": "raw",
  "include": ["advisories", "vex", "sboms"],
  "distribution": ["http", "object"],
  "compression": { "codec": "zstd", "level": 9 },
  "retention": { "mode": "days", "value": 14 }
}

Create via stella export profile create --file profile.json (CLI command documented separately).

Verification workflow

• Download bundle via Console/CLI and extract export.json and provenance.json.
• Run cosign verify --key <tenant-key> export.json (for detatched signatures use --signature export.json.sig).
• Validate Trivy bundles with trivy --cache-dir <temp> --debug --db-repository <oci-ref> or local trivy module db import.
• For mirror bundles, run internal mirror verify script (bundled in Offline Kit) to ensure directory layout and digests match manifest.

Extending profiles

• Use API/CLI to clone an existing profile and adjust include, distribution, or retention policies.
• Adapter plug-ins can introduce new variants (e.g., json:raw-lite, mirror:policy-only). Plug-ins must be registered at service restart and documented under /docs/modules/export-center/profiles.md.
• Any new profile must append the imposed rule line and follow determinism and guardrail requirements.

Imposed rule: Work of this type or tasks of this type on this component must also be applied everywhere else it should be applied.