Vulnerability Management (Polycrate API)

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.

Ü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):

Quelle Voraussetzung Ergebnis
OSV ecosystem + Package-Name (product) CVESourceRecord source=osv
NVD cpe explizit gesetzt (kein synthetisches CPE aus vendor/product) source=nvd; optional SystemConfig.config.NVD_API_KEY (ohne Key: Rate-Limit + Cap pro Product)
CISA KEV nach OSV/NVD bekannte exploitierte CVEs → source=cisa_kev

Finding-Match nutzt OSV- und NVD-Records. Ohne ecosystem liefert OSV keine brauchbaren Treffer; ohne cpe entfällt NVD.

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 der aktuellen API-Version
  2. Template-Blocks mit vulnerability.products befüllen (oder Products manuell anlegen)
  3. Optional: GitHub-Credential für Upstream-Sync (GITHUB_RELEASE_SYNC_CREDENTIAL_ID)
  4. Optional: NVD_API_KEY in SystemConfig, sonst strenges NVD-Rate-Limit
  5. Optional einmalig Sync Now / Beat abwarten für Product- und Release-Catch-up

Siehe auch