[roadmap] Add agent package signing provenance

[ewilhelm1979-netizen]

Problemstellung und Ziel

ISCY hat Zero-Trust-Agent-Onboarding, Deployment-Artefakte und Fleet-Governance bereits im Rust/Axum-Runtime. Dieser PR ergaenzt den naechsten Roadmap-Schritt: vorhandene Agent-/Deployment-Artefakte werden als pruefbare Release-Artefakte mit Manifest, SHA-256, Signaturstatusmodell und Release-Provenance sichtbar, ohne produktive Signierschluessel oder externe PKI einzufuehren.

Geaenderte Funktionen

• Neues Agent-Release-Artefaktmanifest aus fester Repo-Allowlist fuer README, systemd Service/Timer/Env-Beispiel, NixOS-Modul, Windows PowerShell Scheduled Task und macOS LaunchDaemon.
• SHA-256 wird serverseitig aus eingebetteten Allowlist-Artefakten berechnet und kann verifiziert werden.
• Signaturstatusmodell vorbereitet: unsigned, not_configured und spaetere produktive Statuswerte, ohne echte Zertifikate oder private Schluessel.
• Release-Provenance-Metadaten mit Commit-/Branch-/Workflow-/Lockfile-Hash-Bezug und sicherem Incomplete-Status.
• Zero-Trust-Webansicht und gefuehrtes Agent-Onboarding zeigen Artefakte, SHA-256, Signaturstatus, Provenance und bekannte Limitierungen deutschsprachig.
• Management-/Regulatory-Review-Pakete erhalten Agent-Supply-Chain-Gaps fuer NIS2, DORA, DSGVO und generische Governance.
• Docker-/Compose-Build-Kontext wurde minimal angepasst, damit die compile-time Allowlist-Dateien auch im hardened Docker-Build verfuegbar sind.

Betroffene Dateien

• .github/workflows/ci.yml
• docker-compose.yml
• rust/iscy-backend/Dockerfile
• rust/iscy-backend/src/agent_release_store.rs
• rust/iscy-backend/src/db_admin.rs
• rust/iscy-backend/src/lib.rs
• rust/iscy-backend/src/main.rs
• rust/iscy-backend/src/report_store.rs
• rust/iscy-backend/tests/http_tests.rs
• CHANGELOG.md
• docs/ISCY_Handbuch.md
• docs/ISCY_Handbuch.pdf
• docs/ISCY_STRATEGIC_ROADMAP.md
• docs/ZERO_TRUST_AGENT.md
• docs/GUI_SCREENSHOTS.md

Datenbankmigrationen

• Additive Migration 0036_rust_agent_release_artifact_provenance fuer SQLite und PostgreSQL.
• Neue Tabellen: agent_release_artifact, agent_artifact_signature, agent_release_provenance, agent_artifact_verification_event.
• Tenant-/Artifact-Unique-Keys, Foreign Keys und Status-/Tenant-Indizes sind enthalten.
• SQLite-Restartbarkeit und PostgreSQL-Live-Restore-Drill wurden getestet.

Neue oder geaenderte API-Endpunkte

• GET /api/v1/agents/artifacts
• GET /api/v1/agents/artifacts/{artifact_id}
• POST /api/v1/agents/artifacts/refresh
• POST /api/v1/agents/artifacts/{artifact_id}/verify-checksum
• POST /api/v1/agents/artifacts/{artifact_id}/verify-signature
• GET /api/v1/agents/artifacts/{artifact_id}/provenance
• GET /api/v1/agents/release-provenance
• GET /api/v1/agents/release-provenance/{provenance_id}
• GET /api/v1/agents/onboarding/artifacts

GUI-Aenderungen

• /zero-trust/ zeigt Agent-Artefakte und Release-Provenance mit SHA-256, Signaturstatus, Provenance, Verifikationsstatus und schreibrollenbasierten Aktionen.
• Der gefuehrte Agent-Onboarding-Assistent zeigt passende Deployment-Artefakte je Plattform, SHA-256 und Hinweise zur nicht produktiv verifizierten Signatur.
• Sichtbare neue Texte sind deutsch formuliert; technische Akronyme und etablierte Begriffe bleiben erhalten.

Tenant- und Berechtigungsgrenzen

• Alle Lese- und Schreibpfade sind tenantgebunden in den Datenbankqueries.
• Read-only-Rollen duerfen sichere Metadaten lesen.
• Refresh, Checksum-Verify und Signature-Verify sind auf schreibende Rollen beschraenkt.
• Fremde Tenant-Artefakte liefern sichere 404/403-Antworten, keine Store-Details.

Security-Entscheidungen

• Keine produktiven Code-Signing-Zertifikate.
• Keine privaten Schluessel, keine Secrets, keine Cloud-Credentials.
• Keine externe PKI/CA, keine CSR-Funktion, keine mTLS-CA-Ausstellung.
• Keine Sigstore-/Rekor-/Fulcio-Netzwerkaufrufe.
• Keine GitHub-Release-Erstellung oder automatische Veroeffentlichung.
• Keine absoluten lokalen Pfade, Rohdateien, Tokens oder Authorization-Header in API/UI/Audit.
• Keine Dependency-, Postgres-, nginx-, nixpkgs- oder Plattform-Upgrades.
• CI wurde nicht abgeschwaecht; der Docker-Build-Kontext wurde erweitert, damit der bestehende hardened Build die neuen Allowlist-Artefakte sieht. .dockerignore schliesst .env, .git, Media und lokale Artefakte weiter aus.

Ausgefuehrte Tests

• nix develop --command cargo fmt --manifest-path rust/iscy-backend/Cargo.toml -- --check
• nix develop --command cargo clippy --locked --manifest-path rust/iscy-backend/Cargo.toml --all-targets -- -D warnings
• nix develop --command cargo test --locked --manifest-path rust/iscy-backend/Cargo.toml
• nix shell nixpkgs#cargo-audit --command cargo-audit audit --file rust/iscy-backend/Cargo.lock --ignore RUSTSEC-2023-0071
• nix shell nixpkgs#cargo-deny nixpkgs#cargo --command cargo-deny --manifest-path rust/iscy-backend/Cargo.toml check advisories licenses sources
• nix develop --command make rust-smoke
• nix develop --command make rust-restore-smoke
• nix flake check
• PostgreSQL 16.14 Live-Restore-Drill mit zwei lokalen Wegwerf-Datenbanken und Migration 0036
• Docker Compose statische Validierung fuer dev, stage, prod und prod+LLM mit Dummy-Env
• nix develop --command make docs-pdf
• git diff --check

CI-Befund und Korrektur

Der erste CI-Lauf zeigte einen reproduzierbaren Fehler im docker-config Job: Der hardened Docker-Build nutzte rust/iscy-backend als Kontext, waehrend agent_release_store.rs Allowlist-Artefakte aus deploy/agent und flake.lock per include_bytes! benoetigt. Korrigiert wurde der Build-Kontext auf Repo-Root mit selektivem Dockerfile-Copy; Compose und CI nutzen denselben Kontext. Keine Security-Pruefung wurde entfernt oder abgeschwaecht.

Bekannte Einschraenkungen

• Der lokale Docker-Daemon ist nicht verfuegbar; der hardened Docker-Build wird durch GitHub CI validiert.
• Signaturverifikation ist bewusst vorbereitend und liefert ohne produktive Konfiguration not_configured.
• Provenance ist eine sichere Metadaten-/Nachweisschicht, keine externe Attestation.

Bewusst nicht umgesetzt

• Echte Produktionssignaturen, MSI/PKG/deb/rpm-Signierung und produktives Schluesselmanagement.
• Externe PKI/CA, CSR-Erzeugung, mTLS-Zertifikatsausstellung.
• GitHub Release, automatische Veroeffentlichung oder externe Sigstore-/Rekor-/Fulcio-Nutzung.
• Dependency- oder Plattform-Upgrades.
• Neue Risk-, Control-, Notification- oder Evidence-Engine.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 156b20066d

ℹ️ 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".

[chatgpt-codex-connector]

Include agent release gaps in gap filters

When a review package only has the new agent-release supply-chain gaps, these keys are added to gap_summary_json and rendered in the gap groups, but regulatory_review_has_open_gaps / regulatory_review_has_critical_gaps still enumerate only the older gap keys. In that scenario the has_open_gaps=true or has_critical_gaps=true list filters in apply_regulatory_review_gap_filters_* will omit the package even though the UI shows open/critical agent artifact gaps.

Useful? React with 👍 / 👎.