Skip to content

Vista Platform 4.2.0 — full list of changes

Released 2026-09-30. The release summary — highlights, what to do before upgrading, what each edition includes, and how to verify the signatures — is in CHANGELOG.md. This page is the complete, per-change record behind it.

Added

  • Per-connection scan consent (Enterprise). CMDB profiles gain Assets from this source may be actively scanned and NetBox connections Devices from this source may be actively scanned, both off by default. Off: an asset Vista knows only from that connection's pulls or imports is left out of auto-scan; Settings → Auto-scan → Not scanned counts them as Imported, not cleared for scanning. On: they become auto-scan candidates, still subject to owned networks, exclusions and sensitive assets — the setting never makes a public address scannable. Scanning them yourself in Active Scan, any asset a sensor, agent or device interrogation has also seen, and assets uploaded or listed in a spreadsheet are unaffected. The choice is recorded with the profile or connection (a save that cannot record it is refused, 502, nothing stored); deleting the connection withdraws it; each change is audit-logged. Needs Update Settings.
  • CMDB dry run, confirmed first sync, run changes and undo (Enterprise). A CMDB profile's card has Dry run: what the next push or pull would create, update and retire, with examples, writing nothing in Vista or in the CMDB; Confirm runs it. A new profile's first sync can only be made that way — until then its card says Not synced yet, Sync and Pull open the dry run, and scheduled runs wait. Sync history shows what each run created or changed on each side (kept 90 days; each asset a pull created or wrote to also names the run on its timeline), and Undo this run… — confirmed first — archives the assets the run created in Vista (never deletes; an asset another source has also reported is kept) and lists what it wrote in the CMDB without changing anything there. Undo never deletes or edits anything in your CMDB. Undo is audit-logged. Dry run and undo need Manage Assets; the changes list, View Settings. New endpoints: the dry-run, changes-list and undo routes named above, and ?plan= on Sync / Pull.
  • CMDB field-mapping editor (Enterprise). Each CMDB profile's card and edit dialog open an editor for how the CMDB's records and Vista's inventory translate: class rules, field rules (with per-field authority — which side wins — and the value-map / default / constant / join / conversion transforms; no scripting), value maps and identity rules. Vista's side is picked from the canonical vocabulary; the CMDB's fields and types are listed from its own schema where it has one (ServiceNow's dictionary and class list, SolarWinds' Orion.Nodes metadata) or from a sample of 25 of your records (Device42, Oomnitza), and the editor says which. Personal-data fields are marked. Preview maps up to ten live records — pulled from the CMDB or about to be pushed — through the mapping as it stands in the editor, saved or not, and shows the result and whether the mapping is valid; it writes nothing on either side. The editor stores only the profile's changes to the default mapping, and a save that does not validate is refused with the entry to fix. Reading the mapping needs Read Settings; listing the CMDB's fields, previewing and saving need Update Settings. New endpoints: the vocabulary, schema and preview routes named above.
  • Device42 custom fields can be mapped as custom_fields.<name>.

Changed

  • CMDB sync runs in the integration service (Enterprise). The ServiceNow, Device42, SolarWinds and Oomnitza connectors, their field mappings and the sync engine moved out of the inventory service. Nothing changes on Settings → Integrations: profiles, credentials, schedules, field-mapping overrides, links to CMDB records and sync history carry over as they are, and a push or a pull sends and writes what it did before. What changed is underneath: a push reads the inventory only through the inventory service's new internal CI export, and a pull writes it only through the inventory service's identity engine, approval rules and plan limits (the internal source-import API NetBox already uses) — never its tables.
  • The CMDB API moved to the integration service's own route prefix (the exact path is in the Enterprise edition of these notes; only the tenant UI calls it, with no compatibility route), and it now answers a tenant session only — a platform-admin token or a service call gets 403. The old /api/v2/inventory-service/cmdb/profiles* paths are gone from every edition.
  • The inventory service serves an internal CI export (/api/v1/inventory-service/internal/ci-export/*): the configuration items in push scope, per-asset detail through a field allowlist, and approved relationships. Its source-import API gained link and presence writes. All are HMAC-signed service calls only, each naming one tenant in a signed header; refused with any user token and denied at the edge on every host.
  • Core's Integrations page shows the CMDB section as an Enterprise upgrade from the connector catalogue and the feature flag, without a request.
  • Connector egress is now only where connectors run. With the SIEM, NetBox and CMDB connectors all in the integration service, the inventory service is off the chart's private-network dialer list (VISTA_PLATFORM_INTERNAL_CIDRS is no longer injected into it; its only outbound call, the configured ai.provider endpoint, never used it), and the audit service no longer carries an ENCRYPTION_MASTER_KEY — the SIEM credential store that key guarded lives in the integration service. Both services stay in networkPolicy.externalEgressBackends, for the model provider and S3 archival respectively and nothing else. The chart egress test now fails if either returns to the connector or private-dialer set.
  • The CMDB guide and glossary are Enterprise documentation. They moved out of the Core feature guides into the Enterprise integrations guides, next to the NetBox guide; Core pages link to them only from Enterprise sections.
  • The Core export gate builds and tests both web consoles. Before a Core release is published, the exported source tree is installed clean and both the tenant and admin consoles are type-checked and built exactly as their production images build them, then their unit-test suites, and the shared primitives' suite, are run. A failure stops the release and names the failing build or test. Until now the gate built only the Go modules, so a build break that exists only in the Core source tree could be found first by the public image build.
  • Go lint is a hard gate in CI and runs over the whole tree nightly. In CI, a missing golangci-lint now fails the standards check instead of skipping it (locally it still finds the tool in the Go bin directory, and says loudly when it cannot). The pull-request lint step sees only new issues, so a new nightly job lints every Go module in full and reports findings a dependency bump or a removed caller creates.
  • Go lint findings on main are cleared (11 across four modules): two unused test helpers removed, and the AWS SDK's deprecation notices for the S3 transfer manager and ACM's certificate-transparency option annotated with their reasons rather than migrated — the replacement is a new pre-1.0 module and needs its own change with S3 coverage.

Fixed

  • Backends no longer start before an upgrade's schema migration finishes. Each backend's wait-for-schema init container waited only for the tenants table, which exists on every upgrade, so new pods started while the schema-migration Job was still adding columns and a first query could fail with SQLSTATE 42703 (undefined column) until the Job caught up. The gate now waits for the Job's completion marker for the chart's own schema hash — the same check the seed Job already made. It applies to all 16 backends that use Postgres. With schemaMigration.enabled=false it checks only that a schema exists, and it gives up after ~10 minutes with the reason in its log (kubelet then retries) instead of waiting silently. On a fresh install, backends now wait for the whole schema rather than its first table.
  • The integration service tolerates an in-flight schema migration at start-up (Enterprise). During the 4.1.0 upgrade its first SIEM configuration load ran before the migration had added a column, logged a warning and recovered ten seconds later. A missing column or table is now recognised as "schema not ready": logged at INFO ("waiting for the database schema migration"), retried after 1, 2, 4 and 8 seconds (never longer than the normal poll interval) and back to normal once a read succeeds. Any other error still logs a warning. This stays useful where the chart gate does not apply, such as an external database with schemaMigration.enabled=false.
  • The connector-registry check for Enterprise implementations was silently skipping them. It decided it was looking at a Core checkout by the absence of services/inventory-service/ee, which the CMDB move deleted, so a renamed or removed connector package would have passed. It now probes any services/*/ee tree and the probe has its own test.
  • A test-only wall-clock flake is fixed. The identity-enrichment replay test failed every time it ran between 23:40 and 00:00 UTC, because its clock crossed the day boundary that legitimately starts a new rescan cycle. The test clock now starts inside a cycle and the test also asserts that the same evidence in the next cycle does dispatch. No production behaviour changed.

Upgrading

  • An upgrade that changes the schema now waits for the migration. New backend pods sit in Init until schema-migration has applied the new schema; under the default rolling update the old pods keep serving, while a backend on strategy: Recreate is down for the whole migration. helm upgrade --wait now includes the migration time, and Helm's default --timeout is 5 minutes: give it a --timeout that covers the migration plus the rollout. A release that doesn't change the schema passes the wait at once. On a single-node cluster, new pods hold their CPU requests while they wait, so the surge lasts for the whole migration. With schemaMigration.enabled=false the old wait (a schema exists) still applies.
  • Auto-scan no longer scans imported-only assets until their connection allows it (Enterprise). Scan consent is off for every existing CMDB profile and NetBox connection after the upgrade; nothing is migrated. An asset that exists only because a CMDB pull or NetBox import created it — no sensor, agent or device interrogation has seen it, and no spreadsheet upload has listed it — and that auto-scan was scanning because its address is private stops being scanned automatically. Assets from spreadsheet uploads and SBOM uploads are not affected. To keep scanning them, turn on Assets / Devices from this source may be actively scanned on the connection. Assets a sensor or agent has observed are unaffected, as is Active Scan. The schema gains source_scan_consents (RLS; no row = no consent) and the inventory service a signed internal route, PUT /internal/sources/scan-consent, used only by the integration service and denied at the edge like the other source routes.
  • CMDB (Enterprise): a never-synced profile needs a confirmed dry run first. A profile that has never written anything has its scheduled runs skipped, and its Sync and Pull open the dry run, until that first run is confirmed. A profile that has linked a record or pushed or created anything counts as already synced, so its schedule and its Sync / Pull buttons work as they did.
  • CMDB (Enterprise): run provenance table. The schema gains cmdb_sync_job_items (one row per record a run created or changed; RLS; pruned after 90 days by the integration service). Nothing is backfilled: runs before the upgrade have no recorded changes and cannot be undone. A plan made by a dry run is valid for an hour and only for the mapping it was made with.
  • The inventory service gains two more internal source routes used only by the integration service — /internal/sources/assets/runs (tag assets with a run) and /internal/sources/assets/archive (undo a run: archive what it created) — HMAC-signed service calls only, one signed tenant per call, denied at the edge like the other source routes.
  • CMDB (Enterprise): a sync running during the upgrade is cut off and closed. A push or pull the old inventory-service pod was running when it was replaced is left "in progress" and closed as failed with "interrupted (service restarted)" by the integration service about an hour after it started (the run budget plus a margin); scheduled profiles then run at their next due time, and Sync / Pull re-run a manual one straight away. The old and the new pods share one run lock per profile, so a profile is never synced twice at once during the rollout. No data is migrated: the profiles, jobs and entity-mapping tables are adopted as they are.
  • CMDB operator settings move to the integration service. An HTTPS_PROXY / NO_PROXY or CONNECTOR_ALLOW_PRIVATE_ENDPOINTS set on inventory-service for the CMDB connectors must be set on the integration service now, and the integration service must run with the same ENCRYPTION_MASTER_KEY as the inventory service. The exact values key is in the Enterprise edition of these notes.
  • Egress exceptions for the connectors are no longer needed on the inventory or audit service. If you added a NetworkPolicy exception, proxy bypass or NO_PROXY entry on inventory-service for NetBox / CMDB, or on audit-service for SIEM collectors, it can be removed; the destinations are dialled from the integration service now. inventory-service no longer receives VISTA_PLATFORM_INTERNAL_CIDRS, and audit-service no longer receives ENCRYPTION_MASTER_KEY by default.
  • CMDB mapping editor: ServiceNow schema access is optional. To list ServiceNow's fields and classes in the editor, the integration user needs read access to sys_db_object and sys_dictionary (the base itil role does not give it). Without it the editor lists the default mapping's fields and says why; sync, pull and preview are unaffected. Existing mappings are unchanged: the editor reads and writes the same stored overrides.