Skip to content

[roadmap] Add evidence worker disposition storage#43

Merged
ewilhelm1979-netizen merged 1 commit into
mainfrom
feature/evidence-worker-disposition-object-storage
Jul 9, 2026
Merged

[roadmap] Add evidence worker disposition storage#43
ewilhelm1979-netizen merged 1 commit into
mainfrom
feature/evidence-worker-disposition-object-storage

Conversation

@ewilhelm1979-netizen

Copy link
Copy Markdown
Owner

Problemstellung und Ziel

Dieser Roadmap-Block bringt den Evidence-Integrity-/Disposition- und Storage-/Restore-Stand aus PR #38/#39 naeher in den Betriebsmodus. ISCY erhaelt begrenzte Evidence-Worker-Laeufe, kontrollierte physische Disposition nach dokumentierter Freigabe und ein vorbereitetes Object-Storage-Statusmodell ohne echte Cloud-Credentials.

Zusaetzlich wurde der aus PR #42 offene PostgreSQL-Live-Haertungstest fuer Migration 0034_rust_supplier_product_security_governance nachgezogen.

Geaenderte Funktionen

  • Evidence-Integritaets-Worker mit enabled/batch/runtime/cooldown/dry-run Signalen.
  • Worker-Laufhistorie mit Ergebniszaehlern fuer valid, mismatch, missing, failed und skipped.
  • Kontrollierte Disposition mit Kandidatenliste, Preview, Approval, Execute, Cancel und Event-Historie.
  • Physische Aussonderung nur nach Approval, Begruendung und Legal-Hold-Pruefung.
  • Lokale Artefaktloeschung nur ueber canonical-path-gepruefte Storage-Abstraktion.
  • Tombstone-Metadaten fuer ausgefuehrte oder fehlgeschlagene Disposition.
  • Storage-Backend-Status fuer local_filesystem und vorbereitetes s3_compatible.
  • Regulatory Review Packs erhalten Evidence-Worker-, Storage-/Restore- und Disposition-Gaps.
  • Deutsche UI-/Doku-Texte fuer die neue Evidence-Operations-Schicht.

Betroffene Dateien

  • rust/iscy-backend/src/db_admin.rs
  • rust/iscy-backend/src/evidence_artifact_storage.rs
  • rust/iscy-backend/src/evidence_store.rs
  • rust/iscy-backend/src/lib.rs
  • rust/iscy-backend/src/report_store.rs
  • rust/iscy-backend/tests/http_tests.rs
  • CHANGELOG.md
  • docs/ISCY_STRATEGIC_ROADMAP.md
  • docs/ISCY_Handbuch.md
  • docs/ISCY_Handbuch.pdf
  • docs/GUI_SCREENSHOTS.md

Datenbankmigrationen

  • Neue additive Migration 0035_rust_evidence_worker_disposition_storage.
  • Neue Tabelle evidence_integrity_worker_run.
  • Neue Tabelle evidence_storage_backend_status.
  • Neue additive Evidence-Spalten fuer Disposition-Ausfuehrung, Tombstone und Storage-Backend-Referenz.
  • SQLite-Restart-Test fuer 0035 ergaenzt.
  • PostgreSQL-Live-Migrationstest fuer 0035 lokal mit temporaerer Wegwerf-Instanz erfolgreich ausgefuehrt.

Neue oder geaenderte API-Endpunkte

  • GET /api/v1/evidence/integrity/worker
  • POST /api/v1/evidence/integrity/worker/run
  • GET /api/v1/evidence/integrity/worker/runs
  • GET /api/v1/evidence/disposition/candidates
  • POST /api/v1/evidence/{evidence_id}/disposition/preview
  • POST /api/v1/evidence/{evidence_id}/disposition/approve
  • POST /api/v1/evidence/{evidence_id}/disposition/execute
  • POST /api/v1/evidence/{evidence_id}/disposition/cancel
  • GET /api/v1/evidence/{evidence_id}/disposition/events
  • GET /api/v1/evidence/storage/backends
  • POST /api/v1/evidence/storage/drills als Alias fuer bestehende Storage-Drills

GUI-Aenderungen

  • /evidence/integrity/ zeigt jetzt Integritaets-Worker-Status, letzte Worker-Laeufe, Storage-Backend-Status und Disposition-Kandidaten.
  • Admin-/Editor-Rollen sehen Worker-Start, Disposition-Freigabe und kontrollierte Aussonderung.
  • Read-only-Rollen sehen sichere Metadaten, aber keine Schreibaktionen.

Tenant- und Berechtigungsgrenzen

  • Alle Reads/Writes bleiben tenantgebunden.
  • Worker-Start, Disposition-Approval und Disposition-Execute erfordern schreibende Rollen.
  • Read-only sieht nur sichere Statusdaten, Kandidaten, Previews und Ereignisse.
  • Foreign-Tenant Evidence-IDs werden nicht aufgeloest.
  • Execute ohne Approval, ohne Grund oder bei aktivem Legal Hold wird verweigert.

Security-Entscheidungen

  • Keine Storage-Operation vor Approval-/Reason-/Legal-Hold-Pruefung.
  • Verweigerte Execute-Versuche werden als disposition_execution_denied auditierbar dokumentiert.
  • Physische Loeschung nutzt nur die bestehende canonical-path-gepruefte Filesystem-Storage-Abstraktion.
  • Keine absoluten Pfade, Rohpayloads, Dateiinhalte, SQL-Details, Tokens oder Secrets in API, UI, Audit oder Doku.
  • Object Storage bleibt vorbereitetes Statusmodell: keine echten Credentials, keine externen Netzwerkaufrufe, keine produktive S3-Anbindung.
  • Keine CI-, CodeQL-, cargo-audit- oder cargo-deny-Abschwaechung.

Additional PostgreSQL Live Migration Drill for 0034

  • Temporaere lokale PostgreSQL-Instanz verwendet.
  • Migrationen von leerer DB bis main-Stand erfolgreich ausgefuehrt.
  • Tabellen supplier_product_security_record, supplier_product_security_evidence_link, supplier_product_security_event und supplier_contract_exit_history vorhanden.
  • Supplier/Product-Security-Datensatz erzeugt, gelesen, geaendert, Status geaendert und Evidence verknuepft.
  • Events und Contract-/Exit-History gelesen.
  • Cleanup bestaetigt: temporaere PostgreSQL-Prozesse gestoppt und temporaere Daten geloescht.

Ausgefuehrte Tests

  • cargo fmt --manifest-path rust/iscy-backend/Cargo.toml -- --check
  • cargo clippy --locked --manifest-path rust/iscy-backend/Cargo.toml --all-targets -- -D warnings
  • cargo test --locked --manifest-path rust/iscy-backend/Cargo.toml
  • cargo audit --file rust/iscy-backend/Cargo.lock --ignore RUSTSEC-2023-0071
  • cargo deny --manifest-path rust/iscy-backend/Cargo.toml check advisories licenses sources
  • make rust-smoke
  • make rust-restore-smoke
  • nix flake check
  • make docs-pdf
  • git diff --check
  • PostgreSQL-Live-Migrationstest fuer 0034
  • PostgreSQL-Live-Migrationstest fuer 0035

Nicht lokal ausfuehrbar

  • Docker-Compose-Validierung und hardened Docker-Build konnten lokal nicht ausgefuehrt werden, weil docker in dieser Shell nicht installiert ist.

Bekannte Einschraenkungen

  • Keine produktive S3-/Object-Storage-Anbindung.
  • Kein echter Cloud-Credential-Pfad.
  • Keine automatische Hintergrundplanung ausserhalb manueller begrenzter Worker-Laeufe.
  • Kein Vier-Augen-Prinzip fuer Disposition erzwungen.
  • Keine automatische Rechtsbewertung, Zertifizierung, Behoerdenmeldung oder formale Einreichung.

Bewusst nicht umgesetzt

  • Keine Dependency-, Docker-, Postgres-, nginx-, Nix- oder Plattform-Upgrades.
  • Keine neuen Risk-/Control-/Notification-Engines.
  • Keine externen Live-Feeds.
  • Keine PKI/CSR, signierten Agent-Pakete oder Release-Provenance.
  • Keine Performance-, HA- oder Visual-Regression-Erweiterung.

@ewilhelm1979-netizen ewilhelm1979-netizen marked this pull request as ready for review July 9, 2026 18:26
@ewilhelm1979-netizen ewilhelm1979-netizen merged commit 19f740f into main Jul 9, 2026
7 checks passed
@ewilhelm1979-netizen ewilhelm1979-netizen deleted the feature/evidence-worker-disposition-object-storage branch July 9, 2026 18:26

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7bcf3281b2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +1165 to +1166
| "disposition_executed"
| "disposition_failed"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Reject physical statuses on decision-only updates

Because decide_disposition_* is still used by the generic /api/v1/evidence/{id}/disposition endpoint and web disposition form, accepting disposition_executed or disposition_failed here lets a writable caller mark evidence as physically disposed/failed without going through delete_artifact, without setting execution metadata/tombstone fields, and with the file still present. Keep physical execution outcomes restricted to the execution path so the audit state cannot diverge from storage.

Useful? React with 👍 / 👎.

"Disposition-Ausfuehrung wurde durch Schutzregeln verweigert.",
);
}
let disposition = storage.delete_artifact(&evidence_artifact_ref_from_item(&item));

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Record disposition durably before deleting bytes

At this point the artifact is removed before the final execute_disposition database transaction succeeds. If the DB write fails, or if a legal hold/approval change lands after the earlier read but before the store revalidation, the route can return an error with the evidence file already gone and no tombstone/audit update recorded. For controlled evidence disposal, make the DB-side execution state/lock durable before deleting, or otherwise make deletion conditional on a successful guarded update.

Useful? React with 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant