Skip to content

[roadmap] Add supplier product security deepening#42

Merged
ewilhelm1979-netizen merged 1 commit into
mainfrom
feature/supplier-product-security-deepening
Jul 9, 2026
Merged

[roadmap] Add supplier product security deepening#42
ewilhelm1979-netizen merged 1 commit into
mainfrom
feature/supplier-product-security-deepening

Conversation

@ewilhelm1979-netizen

Copy link
Copy Markdown
Owner

Problemstellung und Ziel

Supplier Reviews und Product Security waren bisher getrennte Sichten. Dieser PR verbindet Lieferanten, Produkte/Services, lokale Advisory-/PSIRT-/CVE-Metadaten, Evidence, Vertrags-/Exit-Plan-Reife und Regulatory Review Packs in einem tenantgebundenen Governance-Modell.

Wichtig: Der PR baut keine externe Feed-Integration. Es gibt keine Live-Abfragen gegen NVD, GitHub Advisories, Herstellerportale oder andere externe Quellen.

Geänderte Funktionen

  • additive Migration 0034_rust_supplier_product_security_governance
  • neuer Supplier/Product-Security-Store fuer SQLite und PostgreSQL
  • lokale Supplier/Product-Security-Datensaetze mit Advisory-, CVE-, PSIRT-, SBOM-/VEX-, Review-, Evidence-, Contract- und Exit-Plan-Metadaten
  • Ereignis-/Audit-Historie fuer Erstellung, Aenderung, Statuswechsel, Evidence-Link und Contract-/Exit-Plan-Aenderungen
  • Contract-/Exit-Plan-Historie mit Version, Akteurreferenz, Grund, Statuswechsel und Evidence-Referenzen
  • Regulatory Review Packs fuer NIS2, DORA, DSGVO und generische Governance enthalten Supplier/Product-Security-Gaps
  • deutsches Web UI unter /suppliers/product-security/ mit Filtern, Kennzahlen, Create/Edit/Status/Evidence-Flows und Detailansicht

Betroffene Dateien

  • rust/iscy-backend/src/db_admin.rs
  • rust/iscy-backend/src/supplier_product_security_store.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_STRATEGIC_ROADMAP.md
  • docs/ISCY_Handbuch.md
  • docs/ISCY_Handbuch.pdf
  • docs/GUI_SCREENSHOTS.md
  • docs/assets/iscy-supplier-product-security.png

Datenbankmigrationen

  • 0034_rust_supplier_product_security_governance
  • neue Tabellen: supplier_product_security_record, supplier_product_security_evidence_link, supplier_product_security_event, supplier_contract_exit_history
  • neue Indizes fuer Tenant/Supplier/Status, Product, Due-Date/Status, regulatorische Relevanz, Evidence, Events und Contract-/Exit-History
  • additive Migration, keine destruktiven Datenbankoperationen
  • SQLite-Restartbarkeit mit bestehenden Daten getestet

Neue oder geänderte API-Endpunkte

  • GET /api/v1/suppliers/product-security
  • POST /api/v1/suppliers/product-security
  • GET /api/v1/suppliers/product-security/{record_id}
  • PATCH /api/v1/suppliers/product-security/{record_id}
  • POST /api/v1/suppliers/product-security/{record_id}/status
  • POST /api/v1/suppliers/product-security/{record_id}/evidence
  • GET /api/v1/suppliers/product-security/{record_id}/events
  • GET /api/v1/suppliers/{supplier_id}/product-security
  • GET /api/v1/suppliers/{supplier_id}/contract-exit-history

GUI-Änderungen

  • neue Navigation: Supplier/Product Security
  • neue deutschsprachige Weboberflaeche /suppliers/product-security/
  • Filter fuer Supplier, Produkt/Service, Status, Schweregrad, DORA, NIS2, DSGVO/Daten, kritische Services, ueberfaellige Reviews und Limit
  • Kennzahlen fuer Datensaetze, offene Advisorys, kritische Datensaetze, ueberfaellige Reviews, fehlende Evidence und regulatorische Relevanz
  • Detailseite mit Status, Owner, Due-Date, Evidence-Links, Contract-/Exit-Plan-History und Events
  • Screenshot-Dokumentation aktualisiert

Tenant- und Berechtigungsgrenzen

  • alle Reads/Writes bleiben tenantgebunden in Store-Queries
  • Admin/Editor duerfen erstellen, bearbeiten, Status aendern und Evidence verknuepfen
  • Read-only/Auditor duerfen sichere Metadaten lesen, aber nicht schreiben
  • fremde Supplier-, Product-, Evidence- und Record-IDs werden nicht aufgeloest
  • Manipulierte Filter und IDs liefern sichere 4xx-Antworten ohne Store-/SQL-Details

Security-Entscheidungen

  • keine externen Live-Feed-Abfragen und damit keine neue SSRF-Flaeche
  • Advisory-/PSIRT-/CVE-Referenzen werden nur lokal gespeichert
  • URL-/Referenzfelder werden validiert und in der UI sicher ausgegeben
  • keine Secrets, Tokens, Authorization-Header, absoluten Dateipfade oder Rohpayloads in Audit/Responses/Screenshots
  • keine neue Evidence-, Risk-, Control- oder Notification-Engine
  • keine Dependency-, Docker-, Postgres-, nginx- oder Nixpkgs-Upgrades

Ausgeführte 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 nixpkgs#cargo --command cargo 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
  • env DATABASE_URL=sqlite:/tmp/iscy-nix-app-smoke-0034.sqlite nix run .#iscy-backend -- init-demo
  • Compose config validiert mit .env.example fuer base, stage, prod und prod+LLM
  • nix develop --command make docs-pdf
  • git diff --check

Bekannte Einschränkungen

  • keine externe Supplier-Advisory-, Hersteller-, NVD- oder GitHub-Advisory-Feed-Integration
  • keine automatische rechtliche Bewertung, Zertifizierung oder Behoerdenmeldung
  • keine physische Evidence-Loeschung und keine neue Evidence-Engine
  • lokale Docker-Build-Pruefung konnte nicht ausgefuehrt werden, weil kein Docker-Daemon unter /var/run/docker.sock verfuegbar ist; GitHub CI soll den hardened Docker-Build ausfuehren

Bewusst nicht umgesetzt

  • keine PRs/Bot-PRs/Dependency-Upgrades bearbeitet
  • kein Rust-Docker-, Postgres-, nginx- oder nixpkgs-Upgrade
  • keine Produktlogik fuer externe Live-Feeds
  • keine neue Risk-/Control-/Notification-Engine
  • keine CA-/PKI-/CSR- oder Agent-Signing-Funktionen

@ewilhelm1979-netizen ewilhelm1979-netizen marked this pull request as ready for review July 9, 2026 17:11
@ewilhelm1979-netizen ewilhelm1979-netizen merged commit 754ec12 into main Jul 9, 2026
7 checks passed
@ewilhelm1979-netizen ewilhelm1979-netizen deleted the feature/supplier-product-security-deepening branch July 9, 2026 17:11

@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: 1285a495fd

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

.execute(pool)
.await?;
for evidence_id in evidence_ids {
insert_evidence_link_sqlite(pool, tenant_id, record_id, actor_id, *evidence_id, "review")

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P2 Badge Preserve evidence link types during record edits

When a record already has evidence linked with a non-default link_type via the /evidence endpoint, any later PATCH to unrelated fields deletes all links and reinserts them as "review", so contract/exit/review evidence classifications are silently lost in the detail view and audit metadata. This should preserve existing link types for unchanged evidence IDs instead of resetting them on every record update.

Useful? React with 👍 / 👎.

<label>Advisory-Quelle<select name="advisory_source_type"><option value="manual">Manuell</option><option value="psirt">PSIRT</option><option value="vendor">Hersteller</option><option value="customer">Kunde</option><option value="internal">Intern</option><option value="import_preparation">Import-Vorbereitung</option></select></label>
<label>CVSS<input name="cvss_score" inputmode="decimal"></label>
<label>EPSS<input name="epss_score" inputmode="decimal"></label>
<label>Exploitation<select name="exploitation_status"><option value="unknown">Unbekannt</option><option value="not_observed">Nicht beobachtet</option><option value="proof_of_concept">Proof of Concept</option><option value="active">Aktiv</option><option value="exploited">Ausgenutzt</option></select></label>

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P2 Badge Use accepted enum values in the web form

Selecting the visible Nicht beobachtet option submits exploitation_status=not_observed, but the store normalizer accepts not_known rather than not_observed, so the create/edit flow fails with an invalid-payload error for a value offered by the UI. Align the form values with the backend enum values; the same kind of mismatch should be checked for the nearby select fields added in this panel.

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