Skip to content

Vista Platform 5.2.0 — full list of changes

Covers 5.2.0 through its release candidates. The release summary — what 5.2.0 adds and fixes, what to do before upgrading, and how to verify the signatures — is in CHANGELOG.md. This page is the complete, per-change record behind it.

5.2.0 makes the published Enterprise chart installable again, which 5.1.0's was not, by moving the database SQL out of the chart and into a release image. It also separates assets with nothing cryptographic to assess from assets still waiting to be scored, scores at-rest encryption, and assesses cloud KMS keys and Secrets Manager secrets. Sensors and discovery agents share one panel layout, and discovered wireless networks follow their access point's approval. You can declare a certificate no sensor can reach and get expiry alerts for it, verify it where it is served, have it re-checked nightly and merge it into the certificate actually found there; the Overview gains a world map of sites and cloud regions; and a TLS or SSH listener alone no longer classifies a host as a server. The database schema adds nullable columns and indexes for declared certificates; nothing existing changes.

Entries are grouped by kind, as they were recorded while the release was built.

Added

  • The Overview now shows where your estate is, and what is missing from it. The top panel gains a world map of your sites and cloud regions, each pin coloured by the worst risk band among its assets; click a pin to see its riskiest assets, risk bands, classes and locations beside the map. Assets Monitored adds nine linked counts (sites, AWS regions, racks, prefixes, VLANs, cloud accounts, clusters, certificates and assets to approve), and the Data quality card lists the assets with no owner, no class, no site or gone stale, each opening exactly those assets. A count that cannot be loaded shows a dash, never a zero. The map needs no internet access.
  • Declare a certificate you cannot scan. Infrastructure → Cryptography → Certificates → Add certificate now has a Declare tab: enter a certificate's common name and expiry date (and optionally its issuer, names, serial number, owner, a note and where it is served) and the platform raises the usual expiry alerts for it, even when no sensor can reach it. A declared certificate is listed with the source declared, can be edited or removed from its drawer while nothing has measured it, and never shows a made-up fingerprint. The button that read Upload cert is now Add certificate; its Upload PEM tab is the old upload, unchanged. The Certificates lens gains a Source filter. See Certificate monitoring.

The database schema adds nullable columns to certificates and one partial unique index; nothing existing changes. GET /certificates/expiring now returns asset_id: null (it was "") for a certificate with no asset, and adds declared_host. - Check a declared certificate where it is served. When you say where a declared certificate is served, Add and verify (or Verify now in its drawer) makes one TLS connection to that host and port from the sensor that sees it, or else the platform sensor, and records what it found as the certificate's Observation: Observed (a certificate declared by name and date is then filled in from the one served and checked like any discovered certificate), Not observable with the reason in plain words, or Different certificate served, which adds the served certificate as its own entry, links it, and fails the new Certificate Hygiene control CH-005 "Declared certificates match what is served". Nothing else on the host is contacted and the host is not added as an asset; a host outside your registered networks is asked about first. The lens gains an Observation filter.

Sensors report a new capability, verify_certificate_v1; an older sensor is passed over for the platform sensor. The schema adds the nullable column certificates.declared_addresses and one index on discovery_jobs. - Declared certificates are checked again every night, and can be merged into the certificate served. A declared certificate whose location is Unverified, Not observable or serving a Different certificate is verified once more each night (one check per certificate per day, a bounded number per organisation, from the sensor that last tried), and a host outside your registered networks is only checked again if someone already confirmed it. When a verification links your declaration to a certificate the platform already holds, or the host serves a renewal you accept, Merge into the certificate served in the drawer's Observation section moves your note, ownership and location onto it and removes the declaration, never overwriting anything already recorded there (POST /certificates/{id}/merge-into-observed). After a certificate has been observed, Edit location still changes where it is served and the note; moving the host, port or SNI resets the observation to Unverified. Certificate monitoring is now listed as available on the release-status page. No schema change. - At-rest encryption is scored. A nightly pass reads every at-rest record (S3 buckets, managed databases, Secrets Manager secrets) and raises crypto/unencrypted_at_rest for each resource measured as unencrypted. The score comes from the new AT-REST-PLAINTEXT row in the algorithms catalogue, so editing that row changes it. An asset whose cryptography is entirely at rest and fully measured counts as assessed. One whose encryption could not be read (for example, AccessDenied on GetBucketEncryption) stays Not assessed; it is never treated as clean. Whether the provider or the customer holds the key is a Data Protection lens distinction, not a risk. - AWS Secrets Manager secrets get at-rest records. Cloud discovery now records each secret's encryption (AWS-managed or customer-managed KMS key), which shows in the Data Protection lens and feeds the pass above. Previously a secret reached the inventory with no crypto record. - Discovery agents can send their recent log lines to the console, as sensors already could. The request rides the agent's heartbeat answer; the agent masks credentials before the lines leave its host and the platform masks them again. Lines are held in Redis for a day and are never written to the database. New routes: GET /api/v1/device-interrogation-service/agents/{id}/logs (sensors.read) and POST …/agents/{id}/logs/request (sensors.update). Agents from earlier releases cannot send logs; their Logs tab says so. - Approve button on pending wireless LANs and wireless links (Settings → Wireless), for users with wireless.manage.

Changed

  • "Not assessed" now means there is something left to score. Dashboard → Cryptographic Posture splits the assets that have no risk score into Not assessed (cryptography was seen but not yet scored) and No crypto observed. An asset is in No crypto observed when it has no TLS, SSH, IPsec or other crypto endpoint, no crypto configuration and no at-rest record, and is not a key store, secret store, VPN gateway, CDN distribution or API gateway. risk:not_assessed now matches only the first group; the new risk:no_crypto_observed matches the second. The facet rail, the asset page and the risk summary carry the split: the summary gains not_assessed and no_crypto_observed, while unknown_risk still counts every unscored asset. Asset reads add crypto_surface.
  • Sensors and discovery agents are managed from one panel layout on Discovery → Sensors & Agents: the same tabs in the same order (Overview · Discoveries · Health · Jobs · Logs · Settings), each device showing the ones it supports. Both Health tabs open with the same connection and settings-sync block. A new Jobs tab on both lists the last 10 jobs as one line each with a status, and a click expands a job to show its payload and reply; the sensor's command history no longer prints every command's JSON in a list that grew without bound. Log export has its own Logs tab on both and reads as text. The sensor's Control tab is now Settings, where both devices also have Restart.
  • GET /api/v1/device-interrogation-service/jobs accepts agent_id to list one discovery agent's jobs.
  • Discovered wireless LANs, and the VLANs they put clients on, take their status from the access point that reports them, as its interfaces do: active from an approved device, pending from one awaiting approval, and promoted at the next interrogation after the device is approved. Previously every discovered one stayed pending and the Wireless page offered no way to approve it. A WLAN or VLAN a person added, archived or rejected is not moved.
  • Wi-Fi clients are recorded as wireless stations. When a UniFi controller reports which SSID a client joined, the client's interface becomes an 802.11 station on that wireless LAN, so the asset's Interfaces tab shows the network and wireless_lan.ssid: queries find the client. Clients with a randomised MAC address are not joined, and a client never creates a wireless LAN. The weak-wireless-authentication finding still names only access points.
  • New release image: schema. ghcr.io/vistasecurity/schema (Core) and docker.io/vistasecurity/schema (Enterprise, MSP), tagged and signed like every other image. A mirrored or air-gapped registry needs it alongside the others; schemaMigration.sqlImage.{registry,repoPrefix,repository,tag,digest} override where it is pulled from, each falling back to the product images' setting.
  • Chart maintenance. The chart no longer carries a copy of schema.sql; scripts/stage-chart-sql.sh stamps files/schema/schema.sha256 from scripts/database/schema.sql and make audit fails when the stamp is stale. scripts/chart-release-record-size.mjs simulates Helm's release record for the packaged chart and fails above 900 KB, in make standards-check and in both release workflows, after first proving that the 5.1.0 shape measures over the limit.
  • After upgrading from 5.1.0, the <release>-seed-NN ConfigMaps that 5.1.0 created as pre-upgrade hooks are no longer managed by the chart and can be deleted: kubectl -n <ns> delete cm -l app.kubernetes.io/component=seed-data (the <release>-seed ConfigMap is re-created by the next upgrade).

Fixed

  • A TLS or SSH listener no longer makes a host a server. Every crypto finding from a sensor, an active scan or a device interrogation claimed the class server for the host it was about, and a host is classified by whatever creates it. Access points, switches, laptops and load-balancer addresses first found that way showed as servers, including UniFi access points whose controller reports them as access points. Such hosts are now unclassified until something says what they are. Assets already classified server keep that class; correct them with Edit on the asset page, or accept the class proposal for them in Discovery → Approvals where one is waiting.
  • The published chart installs again. Helm stores every chart file and the rendered manifest in one release Secret, which Kubernetes caps at 1 MiB. schema.sql and seed.sql (about 1 MB each) were in that record twice, so helm install of the 5.1.0 Enterprise chart failed with Secret "sh.helm.release.v1.vista.v1" is invalid: data: Too long before creating a single object, and the Core chart was one seed addition away from the same failure. The SQL now ships in a new release image, schema, built from source for both lines; the schema-migration and seed-data Jobs copy it out of that image in a fetch-sql init container, and the chart carries only the sha256 of schema.sql. The release record is about a quarter of the limit.
  • A chart can no longer apply the wrong schema. The schema-migration Job's init container compares the hash of the schema inside the image with the hash the chart was stamped with and refuses a mismatch, naming both, instead of recording a completion marker for a schema it did not apply. The schema image must therefore be the one of the same release (schemaMigration.sqlImage; the published Enterprise chart pins its digest like every backend's).
  • The Enterprise content bundle is still verified before it is applied. The bundle and its signature ship inside the Enterprise schema image (the image build verifies the signature too); the chart carries the public key, so the chart decides which key the bundle must be signed with. A chart with enterprise.contentBundle.enabled=true pointed at a Core schema image fails in the seed-data Job's init container rather than seeding an empty framework catalogue.
  • Cloud KMS keys are assessed. The crypto pass could not reach the key-store asset that a discovered KMS key belongs to, so every KMS key read Not assessed. Keys now reach their asset through the key's external reference and are scored like any other key.
  • POST /api/v2/inventory-service/infrastructure-assets/enrich-all answered 500 on every commercial (garble-obfuscated) install: the backfill's scan struct left three fields without db tags, garble renamed them, and sqlx found no destination for the ip column before reading a row. The fields are tagged, the handler now logs the underlying error, and a static test keeps every sqlx scan destination in the package tagged.
  • A UniFi controller interrogation recorded a TLS listener on port 8443 for every device the controller manages, whatever the device's state, without connecting to any of them. Each became a measured endpoint (and, for some, a crypto configuration with no protocol version), so access points and switches read as having cryptography nobody had observed. The collector now claims TLS only for the controller's own management interface, which it probes; the managed devices still reach inventory with their interfaces, neighbours and hardware facts. Endpoints recorded before this fix are not refreshed again and turn stale after 30 days; they are not closed automatically.
  • Active scans failed on our side when a device offered only legacy TLS. The scan engine's handshake had the Go client defaults: a TLS 1.2 floor and, since Go 1.22, no RSA key-exchange suites. An embedded broker that speaks only TLS 1.0/1.1, or only RSA-kex and DHE suites, was left as an open port with no endpoint or crypto configuration, so its weak TLS was never scored. The identifying handshake and the version enumeration now offer TLS 1.0+ and every suite Go implements. They measure; they do not trust. A TLS attempt that still fails records a bounded tls_handshake_error class (protocol_version, cipher_suite, timeout, reset, eof, alert, not_tls, other) next to its note.