Zum Inhalt

Vulnerability Management (Polycrate API)

Ab Polycrate API 0.32.0 verwaltet die Plattform einen Security-Bereich für App-bezogene Schwachstellen: CVE-Katalog, Vulnerability Products an Catalogue Apps, Findings und optionale Verknüpfung mit Incidents.

Abgrenzung

Diese Seite beschreibt die Polycrate-API-/Catalogue-App-Pipeline. Cluster-Image-Scanning (Harbor), Runtime (Falco) und Plattform-SLAs: Compliance Portal — Vulnerability Management · SDP Features — Falco.

Überblick

flowchart LR
  Block["Template Block<br/>block.poly vulnerability.products"] --> Sync["Product Sync"]
  Sync --> VP["VulnerabilityProduct"]
  VP --> OSV["OSV Enrichment"]
  OSV --> CVE["CVE + CVESourceRecord"]
  CVE --> Match["Finding Matcher"]
  Match --> Finding["VulnerabilityFinding"]
  Finding --> Incident["Incident optional"]
Objekt Scope Zweck
CVE global Kanonischer CVE-Eintrag inkl. Quellen (MVP: OSV)
VulnerabilityProduct an CatalogueApp Produkt-Identity für Enrichment/Matching
VulnerabilityFinding org-/workspace-bezogen Treffer an deployter App / Instanz
ComplianceReport Organisation monatliches Evidence Pack (automatisch)

UI: Navigation Security bzw. am Catalogue App die Tabs Vulnerability Products und Upstream Releases.

Vulnerability Products an Template-Blocks

Source of Truth für wiederkehrende Apps ist die optionale Sektion in der block.poly:

vulnerability:
  products:
    - vendor: goauthentik
      product: authentik
      ecosystem: Go
      purl: "pkg:golang/goauthentik.io/authentik"

Details und Felder: Blöcke: Vulnerability Products · Empfehlungen.

Sync-Verhalten

Trigger Verhalten
Template-Block Create / Hub-Import Signal → Product-Sync für die Catalogue App
Celery Beat (sync_vulnerability_products) Catch-up über Catalogue Apps mit Registry-/Template-Block
UI/API Action sync-vulnerability-products ObjectTask am Catalogue App
  • Einträge aus dem Block erhalten source=block.
  • Manuell angelegte Products (source=manual) werden nicht orphan-gelöscht.
  • Fehlt vulnerability.products und es gibt keine manuellen Rows: kein OSV-Enrichment für diese App.

CVE-Katalog und Enrichment

  • Beat-Task enrich_cve_catalog (typisch nachts) fragt OSV anhand der Products (ecosystem + Name).
  • Pro Treffer: Upsert CVE und CVESourceRecord (source=osv).
  • NVD / CISA KEV sind vorbereitet, im MVP noch nicht Pflichtpfad.

Ohne ecosystem (und sinnvolle Product-Identity) liefert OSV keine brauchbaren Treffer.

Findings und Incidents

  • Beat-Task match_vulnerability_findings verknüpft Katalog-CVEs mit deployten Apps (z. B. über CatalogueApp / installierte Version).
  • Findings sind org-scoped; Status-Übergänge (accept / false positive) über die UI/API.
  • Findings können an Incidents gehängt werden (Security-Workflow).

Upstream Releases (verwandt)

Catalogue Apps können GitHub-Releases als Notes (kind: app-release) synchronisieren:

  • Meta aus Block (releases_url / git_repository_url / app_version → tracked_app_version)
  • Beat sync_catalogue_app_releases oder Action Sync releases
  • Platform-Credential in SystemConfig: GITHUB_RELEASE_SYNC_CREDENTIAL_ID (sonst strenge Rate-Limits / keine privaten Repos)

Versionsnormalisierung entfernt nur ein führendes v, wenn danach eine Ziffer folgt (v1.2.3 → 1.2.3). Tags wie version/0.7.10 bleiben unverändert.

Voraussetzungen nach Deploy

  1. Django-Migrationen und Celery Worker/Beat mit API-Version ≥ 0.32.0
  2. Template-Blocks mit vulnerability.products befüllen (oder Products manuell anlegen)
  3. Optional: GitHub-Credential für Upstream-Sync setzen
  4. Optional einmalig Sync Now / Beat abwarten für Product- und Release-Catch-up

Siehe auch