stella export — Command Guide
Audience: compliance and release operators who produce deterministic, locally verifiable evidence bundles (mirror, conformity dossiers, CRA technical files, NIS2 and DORA filings) from a connected or air-gapped Stella Ops install.
Product-facing assurance pack summaries live under NIS2 SoA export, NIS2 KPI dashboard, CRA technical file, and CRA conformity dossier. This guide documents the CLI command surface and local/offline execution details. Use stella assurance to list optional packs, inspect embedded descriptors, and check tenant readiness before running pack-specific exports.
Commands
stella export mirror --bundle <path> --profile <name> [--offline]stella export verify --bundle <path> --trust-roots <file>stella export plan --output json(preview bundle contents)stella export conformity-dossier --module <A|B+C|H> --product <ref> --input <file> --output <file> [--overwrite] [--json]stella export cra-tech-file --product <ref> --since <yyyy-MM-dd> --input <file> --output <file> --signing-key-file <file> [--json]stella verify cra-tech-file <file> --signing-key-file <file> [--json]stella export standards-mapping --target <target> [--mapping-dir <dir>] [--signing-key-file <file>] [--output <file>] [--json]stella export nis2-soa --since <yyyy-MM-dd> --snapshot <file> (--tenant-profile <file>|--tenant <tenant>) --signing-key-file <file> [--output <file>] [--json]stella export nis2-effectiveness --month <yyyy-MM> --report <file> [--signing-key-file <file>] [--output <file>] [--json]stella verify nis2-effectiveness --bundle <file> [--signing-key-file <file>] [--json]stella export dora-roi --year <yyyy> --tenant <tenant> --input <file> --output <zip> --signing-key-file <file> [--json]stella verify dora-roi <zip> --signing-key-file <file> [--json]stella export dora-incident-report <incidentId> --variant <initial|intermediate|final> --input <file> --output <dir> --signing-key-file <file> [--json]stella verify dora-incident-report <path> --signing-key-file <file> [--json]stella export dora-info-sharing --input <file> --output <dir> [--signing-key-file <file>] [--json]stella verify dora-info-sharing <path> [--signing-key-file <file>] [--json]
Flags (common)
--offline: enforce no network; fail with exit code 5 if registry/object-store calls would occur.--profile: named export profile (schema/manifest version); defaults to latest supported.--trust-roots: PEM/TUF/DSSE trust roots for verification.--output: json (default) or table for plan outputs.
Inputs/outputs
- Inputs: export profiles, mirror configuration, optional cached artefacts.
- Outputs: deterministic bundle tarball + manifest (checksums, signatures, metadata); verify emits status + detailed reasons.
- Exit codes follow output and exit codes; verification failure uses exit code
3.
Assurance readiness
stella assurance pack status <packId> --tenant <tenant> is the generic readiness check for optional packs. It composes Authority pack enablement, ExportCenter export readiness, and Notify reporting timeline readiness. A non-configured result fails closed with stable reason codes and does not print secret values or local secret paths.
Assurance status does not replace export commands. It points operators to the pack-specific command that creates the artifact:
nis2:stella export nis2-soaandstella export nis2-effectivenesscra.technical-documentation:stella export cra-tech-fileandstella export conformity-dossiercra.product-security: public metadata and advisory feed publication readiness before product-security publication workflows
CRA conformity dossier
stella export conformity-dossier is an offline/local command that calls the Export Center cra:conformity-dossier adapter directly. It does not query live services and does not synthesize missing evidence.
Flags:
--module <A|B+C|H>: CRA conformity module.Ais internal production control self-assessment,B+Cis EU type-examination plus production conformity, andHis full quality management system.--product <ref>: Product reference written to the dossier index.--input <file>: Localconformity-dossier-cli-input-v1JSON file.--output <file>: Destination.tar.gzbundle path.--overwrite: Allow replacing an existing output file.--json: Print deterministic command summary JSON.
Example:
stella export conformity-dossier \
--module A \
--product product:stella-ops \
--input ./cra/conformity-input.json \
--output ./out/stella-ops.conformity-dossier-a.tar.gz \
--json
The input file binds frozen local evidence refs to the adapter contract. The shape below is abbreviated; arrays shown as empty must be populated according to the fail-closed rules for the selected module.
{
"schemaVersion": "conformity-dossier-cli-input-v1",
"generatedAt": "2026-04-30T10:00:00Z",
"product": {
"name": "Stella Ops",
"version": "2026.04",
"manufacturer": "Stella Ops",
"description": "Self-hosted release control plane"
},
"release": {
"version": "2026.04",
"releaseManifestRef": "attestor://release-manifests/stella-2026.04",
"sbomRef": "evidence://cra/sbom",
"placedOnMarketAt": "2026-04-30",
"supportUntil": "2031-04-30"
},
"evidenceRefs": [],
"harmonisedStandards": [],
"euDeclarationOfConformity": {
"status": "draft",
"manufacturerName": "Stella Ops",
"manufacturerAddress": "TBD",
"responsibleRole": "product-owner",
"declarationRef": "docs/legal/cra-product-classification.md"
},
"supportPolicy": {
"policyRef": "docs/europe/stella-supplier-security-statement.md",
"supportWindow": "5-year minor-train security support baseline",
"securityContactRef": "docs/product/security-contact.md"
},
"sourceRefs": {},
"declaredControls": [],
"evidenceLinks": [],
"testCertificates": [],
"auditSignatures": [],
"qmsEvidence": [],
"iso27001ControlEffectiveness": []
}
Fail-closed rules:
- All modules require at least one technical-file evidence ref, declared control, and conformity evidence link.
- Module
B+Crequires at least one test certificate or notified-body reference. - Module
Hrequires at least one QMS evidence reference and one ISO/IEC 27001 control-effectiveness evidence reference. - Missing production audit signatures do not block local bundle generation; the adapter records the signing/audit blocker in
index.jsonuntil durable Attestor/CAdES signing support is available.
CRA technical file
stella export cra-tech-file creates the deterministic CRA Annex VII technical file bundle from a local cra-tech-file-cli-input-v1 JSON file and verifies the generated archive before reporting success. stella verify cra-tech-file replays bundle integrity and the local HMAC DSSE signature offline.
See stella export cra-tech-file for the input schema, signing-key options, and fail-closed verification rules.
NIS2 Statement of Applicability
stella export nis2-soa creates a deterministic signed NIS2 Statement of Applicability bundle from a local nis2-control-register-v1 snapshot and a tenant compliance profile. The profile can be supplied from a local file or resolved from Authority by tenant id when the CLI is configured for live API access.
Flags:
--since <yyyy-MM-dd>: UTC date selecting the stored control-register snapshot.--snapshot <file>: Local NIS2 control-register snapshot JSON file.--tenant-profile <file>: Local tenant-compliance-profile JSON file.--tenant <tenant>: Tenant id used to resolve the profile from Authority when--tenant-profileis omitted.--signing-key-file <file>: Local HMAC signing key file for deterministic offline DSSE wrapping.--signing-key-id <id>: Optional signing key id recorded in the DSSE envelope.--evidence-locker-bundle-ref <ref>: Optional content-addressed EvidenceLocker bundle reference for the snapshot.--output <file>: Destination bundle JSON path.--redact-internal-only: Omit internal-only descriptions and metadata from exported control rows.--json: Print deterministic command summary JSON.
Fail-closed rules:
- Missing snapshots, malformed profiles, invalid dates, or missing signing key material fail before successful output is reported.
- Authority profile lookup is only used when
--tenant-profileis omitted. - The local HMAC DSSE signature is an offline reproducibility and tamper check; it is not production CAdES/KMS signing.
Standards mapping
stella export standards-mapping is an offline/local command that calls the Export Center standards:mapping adapter directly. It reads only local YAML files and writes a deterministic signed .tar.gz bundle.
Supported targets:
iso27001iec62443-4-1iec62443-4-2en303645jrc-cra
Flags:
--target <target>: Standards-mapping target to export.--mapping-dir <dir>: Local mapping directory. Defaults todocs/europe/standards-mappingrelative to the current working directory.--output <file>: Destination.tar.gzbundle path. Defaults to<target>.standards-mapping.tar.gz.--overwrite: Allow replacing an existing output file.--generated-at <timestamp>: UTC timestamp embedded in the bundle index. Defaults to2026-04-30T00:00:00.0000000+00:00for reproducible CLI output.--signing-key-file <file>: Local HMAC signing key file. If omitted, the command usesSTELLAOPS_STANDARDS_MAPPING_HMAC_KEY.--signing-key-id <id>: Optional signing key id recorded in the DSSE envelope.--json: Print deterministic command summary JSON.
Example:
stella export standards-mapping \
--target iso27001 \
--mapping-dir docs/europe/standards-mapping \
--signing-key-file ./keys/standards-mapping.hmac \
--signing-key-id eu-local-standards-mapping \
--output ./out/iso27001.standards-mapping.tar.gz \
--json
Fail-closed rules:
- Unsupported targets fail before any output file is written.
- Missing local mapping files fail before any output file is written.
- Missing signing key material fails before any output file is written.
jrc-crafails before output if the local mapping is blocked, pending, draft, has zero reviewed mapping rows, or emits bundle blockers. The command must not fetch remote mapping text at export time.
NIS2 effectiveness report
stella export nis2-effectiveness creates the deterministic monthly NIS2 effectiveness report bundle from a local nis2-effectiveness-dashboard-v1 JSON report and verifies the generated bundle before reporting success. stella verify nis2-effectiveness replays the same checks offline.
Flags:
--month <yyyy-MM>: Calendar month bound into the report.--report <file>: Local Platform/Telemetry NIS2 effectiveness dashboard report. This is required until live Platform export resolution is wired into the CLI path.--output <file>: Destination JSON bundle path. Defaults tonis2-effectiveness-<tenant>-<yyyyMM>.bundle.json.--overwrite: Allow replacing an existing output file.--signing-key-file <file>: Local HMAC signing key file. If omitted, the command usesSTELLAOPS_NIS2_EFFECTIVENESS_HMAC_KEY.--signing-key-id <id>: Optional key id recorded in the DSSE envelope.--source-report-ref <ref>: Optional immutable source report ref.--target-document-ref <ref>and--target-document-hash <sha256:...>: Optional target override source pointers.--control-register-snapshot-ref <ref>and--control-register-snapshot-hash <sha256:...>: Optional Policy control register snapshot pointers.--policy-snapshot-ref <ref>: Optional Policy snapshot ref used for replay pinning.--json: Print deterministic command summary JSON.
Example:
stella export nis2-effectiveness \
--month 2026-04 \
--report ./out/nis2-effectiveness-dashboard.json \
--signing-key-file ./keys/nis2-effectiveness.hmac \
--signing-key-id eu-local-nis2-effectiveness \
--target-document-ref policy://target-documents/nis2/2026-04 \
--control-register-snapshot-ref policy://control-registers/nis2/2026-04 \
--policy-snapshot-ref policy://snapshots/nis2/2026-04 \
--output ./out/nis2-effectiveness-tenant-a-202604.bundle.json \
--json
Verify:
stella verify nis2-effectiveness \
--bundle ./out/nis2-effectiveness-tenant-a-202604.bundle.json \
--signing-key-file ./keys/nis2-effectiveness.hmac \
--signing-key-id eu-local-nis2-effectiveness \
--json
Fail-closed rules:
- Source reports with anything other than exactly 13 areas numbered 1 through 13 fail before output is written.
- A missing source report or missing signing key fails before output is written.
- Missing target document hash, control-register snapshot hash, or Policy snapshot ref is recorded as a blocker in the monthly report instead of fabricated.
- The local HMAC DSSE signature is only an offline reproducibility and tamper check. It is not production CAdES/KMS signing.
DORA Register of Information
stella export dora-roi creates a deterministic signed ZIP bundle from a local dora-roi.v1 register JSON file. stella verify dora-roi replays the ZIP index, manifest, template hashes, bundle hash, and local HMAC signature offline.
Flags:
--year <yyyy>: DORA RoI reporting year.--tenant <tenant>: Tenant id expected in the input register.--input <file>: Localdora-roi.v1input JSON.--output <zip>: Destination deterministic signed ZIP bundle.--signing-key-file <file>: Local HMAC signing key file.--signing-key-id <id>: Optional key id recorded insignature.json.--prior-year-bundle <zip>: Optional previous annual bundle whose archive hash is bound intomanifest.json.--prior-year-hash <sha256:...>: Optional previous annual archive hash when the previous bundle is already retained elsewhere.--retention-years <5..10>: Effective annual snapshot retention. Defaults to 7.--retention-override-ticket <id>and--retention-override-reason <text>: Required together when retention is not 7 years.--offline: Operator assertion that only local files are used.--overwrite: Replace an existing output file.--jsonor--format json: Print deterministic command summary JSON.
Example:
stella export dora-roi \
--year 2026 \
--tenant tenant-bank-de \
--input ./inputs/dora-roi/tenant-bank-de/2026/register.json \
--output ./out/tenant-bank-de.roi-2026.zip \
--signing-key-file ./keys/dora-roi.hmac \
--json
Verify:
stella verify dora-roi \
./out/tenant-bank-de.roi-2026.zip \
--signing-key-file ./keys/dora-roi.hmac \
--json
Fail-closed rules:
- Missing or malformed input, mismatched tenant/year, missing signing key material, invalid prior-year hashes, and invalid retention overrides fail before successful output is reported.
- The bundle is marked with the local taxonomy marker
its-eu-2024-2956-local-contract-v1; official EBA XSD/XBRL validation is not performed until the approved taxonomy package is available offline. - The local HMAC signature is an offline reproducibility and tamper check. It is not production CAdES/KMS signing or regulator submission.
DORA major incident report
stella export dora-incident-report creates an offline filesystem handoff for an initial, intermediate, or final DORA major-incident report. stella verify dora-incident-report replays the handoff manifest, artifact hashes, DSSE payload binding, and local HMAC signature without live Stella services.
Flags:
--variant <initial|intermediate|final>: Report variant to render.--input <file>: Localdora-major-incident-report.v1report input JSON.--output <dir>: Root directory for the deterministic handoff tree.--signing-key-file <file>: Local HMAC signing key file.--signing-key-id <id>: Optional signing key id recorded in the DSSE envelope and checked by the verifier when supplied.--produced-at <timestamp>: UTC timestamp embedded in the handoff. Use this for reproducible regeneration.--overwrite: Replace an existing generated handoff directory.--json: Print deterministic command summary JSON.
Example:
stella export dora-incident-report incident-dora-payments-001 \
--variant initial \
--input ./inputs/dora/incident-dora-payments-001/initial.json \
--output ./out/dora \
--signing-key-file ./keys/dora-incident.hmac \
--signing-key-id eu-local-dora-incident \
--produced-at 2026-04-30T10:15:00Z \
--json
Verify:
stella verify dora-incident-report ./out/dora/tenant-bank-de/incident-dora-payments-001/initial-report \
--signing-key-file ./keys/dora-incident.hmac \
--signing-key-id eu-local-dora-incident \
--json
Fail-closed rules:
- Missing or malformed input, mismatched incident id, missing signing key material, and unsupported variants fail before successful output is reported.
- Verification fails when the manifest is missing, multiple manifests are found under the supplied directory, any artifact hash differs, the DSSE payload is not bound to the unsigned envelope artifact, or the local HMAC signature does not match.
- The local HMAC signature is an offline reproducibility and tamper check. It is not production CAdES/KMS signing or regulator submission.
DORA information sharing
stella export dora-info-sharing creates an offline filesystem handoff for a DORA Article 45 STIX/TAXII information-sharing batch. stella verify dora-info-sharing replays the receipt, artifact hashes, TAXII manifest purpose, DSSE payload hash, and local HMAC signature without live Stella services or a live TAXII endpoint.
Flags:
--input <file>: Localdora-info-sharing-cli-input-v1source-event input JSON.--output <dir>: Directory that receivesstix-batch.json,taxii-manifest.json,stix-batch.dsse.json, anddora-info-sharing.receipt.json.--signing-key-file <file>: Local HMAC signing key file. If omitted, the command usesSTELLAOPS_DORA_INFO_SHARING_HMAC_KEY.--signing-key-id <id>: Optional key id recorded in the DSSE envelope and checked by the verifier when supplied.--overwrite: Replace existing output directory contents.--json: Print deterministic command summary JSON.
Example:
stella export dora-info-sharing \
--input ./inputs/dora-info-sharing/peer-bank-a.json \
--output ./out/dora-info-sharing/peer-bank-a \
--signing-key-file ./keys/dora-info-sharing.hmac \
--signing-key-id eu-local-dora-info-sharing \
--json
Verify:
stella verify dora-info-sharing ./out/dora-info-sharing/peer-bank-a \
--signing-key-file ./keys/dora-info-sharing.hmac \
--signing-key-id eu-local-dora-info-sharing \
--json
Fail-closed rules:
- Missing or malformed input, missing signing key material, unsupported event kinds, missing redaction authorisation data, and non-empty output directories without
--overwritefail before successful output is reported. - Verification fails when the receipt is missing, multiple receipts are found under the supplied directory, an artifact hash differs, the TAXII manifest purpose is not
dora-info-sharing, the DSSE payload hash differs, or the local HMAC signature does not match. - The setup command
stella notify setup-dora-feedcreates only a disabled local feed setup document. It does not activate live TAXII delivery. - The local HMAC signature is an offline reproducibility and tamper check. It is not production CAdES/KMS signing, live TAXII submission, or regulator submission.
Determinism rules
- Manifest ordering is stable; checksums hex-lowercase; timestamps UTC.
- No network-dependent mutation; offline bundles must be reproducible.
Offline/air-gap notes
--offlinemust be honored; registry pulls are forbidden unless cached in profile path.- Verification uses only local trust roots; no remote key fetch.
Related Documentation
- stella export cra-tech-file — input schema, signing-key options, and fail-closed verification for the CRA Annex VII technical file.
- stella export dora-roi — Annual Filing Runbook — end-to-end annual DORA Register of Information filing flow, prior-year binding, and retention overrides.
- stella assurance — list optional packs and check tenant readiness before running pack-specific exports.
- Output and exit codes
