Skip to content

v0.3.2 - Audited STIX Export Overrides

Corrobore v0.3.2 publishes the narrow forced-export patch delivered after v0.3.1. Operators can explicitly export an otherwise eligible CTI record when a semantic validation rule, such as the built-in confidence threshold, rejects it, while every overridden finding remains visible in deterministic export diagnostics.

Highlights

  • Adds force=true to GET /v1/export/stix with an opt-in default of false.
  • Adds StixExportOptions::force to the embedded Rust API.
  • Keeps low-confidence and other overridden semantic findings in the bounded export_diagnostics.exclusions array even when the associated record is included in the bundle.
  • Preserves default strict and permissive behavior for callers that do not request force.

Contracts

  • Built-in CTI confidence, evidence-presence, and graph-addressed provider validation findings may be overridden only by an explicit force request.
  • Validation still runs before every export; force changes record selection, not the validation evidence or diagnostic result.
  • Force does not bypass lifecycle export status, supported-profile selection, canonical STIX identity, retained-evidence integrity, relationship endpoint integrity, CTI licensing, provider readiness, or provider capability checks.
  • The public OpenAPI version and all workspace-owned package versions are 0.3.2; the storage manifest and record format remain V1 and JsonLinesV1.

Upgrade notes

No storage migration is required from v0.3.1. Existing HTTP and embedded callers remain strict by default. Operators should use force only as an audited, exceptional decision and inspect export_diagnostics.exclusions in the returned STIX bundle before distributing it.

Downstream Rust embedders must initialize the new public force field when constructing StixExportOptions directly; StixExportOptions::default() keeps it disabled.

Known boundaries

  • There is no dedicated STIX export CLI command in this release; a future CLI may map an explicit --force flag to the same engine option.
  • Corrobore does not parse PDF files; document parsing, OCR, and model-driven extraction remain upstream responsibilities before evidence ingestion.
  • Force is not a blanket malformed-data or authorization bypass.
  • GitHub release archives, the Elastic-free OpenCTI archive, and container tags are publication evidence only after their tag-triggered workflows succeed.
  • Enterprise CTI provider binaries remain external licensed artifacts and are not bundled in the OSS release.

Validation and provenance

Release preparation is accepted only after the merged release commit passes:

  • Rust formatting and Clippy across the whole workspace and all features;
  • the complete locked workspace test suite, including the strict/forced STIX export and non-bypassable safety-gate contracts;
  • JavaScript documentation, release-note, distribution, security, and acceptance contracts;
  • a strict MkDocs build;
  • required pull-request checks on the exact commit that will receive the tag.

The v0.3.2 tag must identify that exact merged commit. The tag-triggered release workflow must build and test five native archives before publishing the GitHub release, and Docker publication is verified separately.

Full comparison: v0.3.1...v0.3.2.