Release notes

Known issues & release notes

The current release is v1.0.3. Every install bundle ships a full CHANGELOG.md; this page summarizes the headline changes and known caveats per tagged release so you don't have to dig through it, newest first.

This page was three releases out of date Until 2026-08-18 it said the current release was v1.0.0-rc.1 and its history stopped there — while 1.0.0, 1.0.1 and 1.0.2 had shipped, the last of them carrying a security fix. The first pilot client reported it (their P-04) and was right about why it matters: a product sold on supply-chain integrity that publishes a security release with no release note leaves the customer unable to justify the upgrade. The entries below were written from the tagged CHANGELOG, not from memory.

v1.0.3 — current

Released 2026-08-19. Forty findings from twelve hours of real testing by a pilot customer on 1.0.2 — a live Entra ID tenant of 1411 users and 1997 devices, a wildcard certificate, Jira Server 8.4.0, an internal Zabbix. Upgrade if you use connectors, rely on the audit trail as evidence, or run a wildcard certificate.

Applies to on-prem installs — connectors could not reach internal sources If you tried to connect an on-premises source before 1.0.3, it could not have worked. The SSRF guard rejected every private address unconditionally, so Zabbix, FortiGate, FortiAnalyzer, FortiClient EMS, Splunk, vCenter, Jira Server and generic HTTP/JSON to an internal endpoint all failed with Blocked destination. There was no supported workaround. A multi-tenant SaaS threat model had been applied unchanged to a single-tenant on-prem product.
.env — list your internal networks
CONNECTOR_ALLOWED_CIDRS=192.168.10.0/24,10.0.0.0/8

Empty by default, so nothing changes until you set it. It applies to connectors only — webhooks and OIDC discovery keep the strict transport — and loopback, link-local (including cloud metadata at 169.254.169.254), unspecified and multicast stay blocked even if you list them. See Connectors.

  • Sign-ins are recorded, attributed and hash-chained. Authentication events had a null actor, no sequence_number and no prev_hash, and were invisible through the API because their organization_id was null — so the audit trail could show that someone signed in from an address, not who. The rule now held, and asserted by a test, is that every event visible in an organization's audit view is in that organization's chain, with contiguous sequence numbers. The API also returns sequence_number, prev_hash and entry_hash, without which an external auditor could not verify the chain at all.
  • Deployment-level events stay outside the chain — by design, not by omission. A completed backup, or a failed sign-in for an address belonging to no account, is recorded with its context but belongs to no organization, so it is in no organization's chain; attributing it to one would be an invention. SELECTing backup.completed will therefore still show a null sequence_number. A verifiable deployment-level chain does not exist yet — if you need one for a certification, say so. An earlier draft of these notes said the chain covered backup events too; it does not, and that wording was corrected before release after checking our own deployment rather than our changelog.
  • Imported devices no longer merge on hostname. Entra ID devices were keyed on displayName, so two hosts sharing a name collapsed into one asset irrecoverably — 545 of 1997 records at the pilot customer, while the run summary reported 1997 imported. Devices key on the source's own identifier now, the run reports created / updated / total separately, and migration 0041 replaces the database constraint that required the collapse. Re-run your connectors after upgrading to re-key existing assets.
  • MFA coverage is computed over one population. The denominator included disabled accounts; the numerator counted registration-report rows that were never matched to the directory, guests included. It is now enabled, non-guest member accounts matched by directory id. Expect the number to change — the old one was not measuring what it named. It still cannot be expanded to a list of people; identities are not stored as an entity yet.
  • A long form no longer fails after a session refresh. The CSRF nonce rotated on refresh, so a request replayed afterwards carried the value read at page load and was rejected. Refresh no longer rotates it.
  • Wildcard certificates are accepted. Hostname matching implements RFC 6125 §6.4.3, so *.example.com covers host.example.com (and correctly does not cover a.b.example.com).
  • Connector failures say what the provider said. The Azure error code, description and trace id reach the operator instead of Token request failed (400), and confusing the tenant ID with the client ID is called out by name.
  • "Test connection" tests what the sync actually reads. It probed one resource that needs no permission, so it went green and the sync then failed with 403. It now probes every resource the sync uses and reports them line by line.
  • Required permissions are shown in the connect form — the scopes, the admin-consent note, and whether the source has to be reachable on your internal network. They were previously only in the source code.
  • Jira Server / Data Center is supported alongside Jira Cloud.
  • Licence usage shows assets, the limit an import actually consumes.
  • Maturity scores carry their coverage, so a percentage cannot read as complete while most controls are unassessed; the control matrix distinguishes "gap" from "not yet assessed".
  • A licence gate is no longer shown as a loading error, and is shown in your language.
  • Localisation completed for the maturity questionnaire, sectors, turnover bands and role names.
  • New page: Connectors — reachability, the permissions each source needs, per-product notes (Jira Cloud vs Server, EU endpoints), and how to read a failed run. There had been no connector documentation at all for a catalogue of sixteen.
  • Documentation matches the shipped version, and the reverse proxy emits exactly one Content-Security-Policy header.

v1.0.2

Released 2026-08-17 in response to a pilot customer's install report. Contains a security fix: upgrade if you installed 1.0.1 or earlier.

Security — .env was left world-readable

install.sh ran chmod 600 .env and then wrote each secret with awk … > .env.tmp && mv. mv gives the replacement the temp file's mode — the caller's umask, 0644 — so the hardening was undone by the first secret written and by every one after it, while the installer printed ok (chmod 600) without checking.

Affected: every install performed with 1.0.1 or earlier. SECRET_KEY, DATA_ENCRYPTION_KEY, POSTGRES_PASSWORD and MINIO_ROOT_PASSWORD were readable by every local account on the host.

Upgrading does not fix an existing file — it is already written. Check and repair it yourself:

on the server
cd <install dir> && stat -c '%a %n' .env    # 644 means you are affected
chmod 600 .env && stat -c '%a %n' .env      # must print 600

Whether to rotate those secrets is your call — it depends on what else reads files on that host (log shippers, EDR agents) and on your retention. If you rotate, DATA_ENCRYPTION_KEY needs a specific procedure because data is encrypted with it; ask us rather than rotating it blind.

  • An access-gate login page is no longer misdiagnosed as tampering. A gate answers an unauthorised download with HTTP 200 and an HTML page, so get.sh failed two steps later with SIGNATURE VERIFICATION FAILED — sending the operator after a supply-chain incident when the real cause was an unauthorised egress address. Both downloads now detect markup first and say so.
  • get.sh states its own revision (grep -m1 GETSH_REVISION= get.sh), so a stale saved copy is recognisable instead of having to be trusted.
  • Install documentation corrected: the outbound-access table (destination, port, reason, phase) that was missing, the git clone of a private repository that should never have been there, and docker compose version wording that read as rejecting anything newer than v2.
  • The self-signed certificate covers the server's IP too, and --tls-san takes extra names.
  • CVE-2026-53615 (util-linux, HIGH) patched in the API and control-plane images.
  • SBOM is now actually published alongside the bundle. It had been generated for every release and never uploaded, while the install guide listed it among the shipped artifacts.

v1.0.1

Released 2026-08-16 — the first build fit to hand to a pilot customer.

  • The on-prem bundle stopped shipping Cerynix's own internals. The tarball is git archive of the tag, so v1.0.0 delivered CI workflows, agent instructions and — the reason this is a fix and not housekeeping — our internal security-finding registers to every customer who unpacked it.
  • Seven follow-ups from the pre-release adversarial reviews: an LDAP first-login race, DN comparison, clamping directory-controlled strings, a billing-event watermark that could be poisoned by a far-future timestamp, and the licence entitlement basis recorded on the licence row.

v1.0.0

Released 2026-07-30 — the first stable release, cut after two independent adversarial review passes and a systematic audit of every claim the product makes about itself. That audit found roughly 70 claim defects, ten of them release-blocking, and all ten were fixed before the tag rather than shipped with an asterisk.

  • Audit-evidence chain: hash-chained ledger, immutable snapshots with a database append-only trigger, and a minisign-signed export package that verifies offline with a stdlib-only verifier.
  • Clean-VM install qualification: signature verified inside the VM, installer self-test, licence issued and activated, and the golden path driven through to a signed export verified offline.
  • Legal and documentation corrections, including removing a Art. 32 measure from the DPA that did not exist in the code.

v1.0.0-rc.1 — superseded

The v1.0 release candidate: a signed release (cosign-signed container images, an SPDX SBOM and a minisign-signed on-prem bundle) covering the full NIS2 + ISO/IEC 27001:2022 + GDPR control library, findings/CAPA/RCA workflow, management review and a signed Audit Room export. Deployed to production on 2026-07-28 under explicit owner authorization.

Known caveat — /version git_commit Applies to the Cerynix-managed cloud deployment, not to your on-prem install — a distinction this page used to blur, which the first pilot client flagged (their P-07) after confirming their own 1.0.2 install reports a real commit hash. On Cerynix's managed deployment, GET /version reports git_commit: unknown instead of the deployed commit hash — the cloud upgrade path doesn't yet thread the build-provenance value into the built image, unlike the staging pipeline, which stamps it correctly. The deployed commit is still independently verifiable from the host's git HEAD and the signed release manifest; self-reporting it in /version on production is a tracked follow-up, not a hot production edit.

Private preview: self-registration is off and access is invite-only while we validate the platform with a small number of organizations before general availability.

v0.3.0 — 2026-07-11

The Cerynix rebrand release. Added SSO (SAML) and LDAP sign-in with SCIM 2.0 provisioning, TOTP MFA, a threat-intelligence / CISA KEV exposure feed, AURA RAG v2 (grounded, conversation-log AI assistant), third-party connectors, white-label PDF reports, and the Control Plane / HQ fleet-management console.

v0.2.0 — 2026-07-01

Added TLS/HTTPS via a bundled reverse proxy (with bring-your-own certificate support), offline Ed25519-signed commercial licensing across four editions, an application version/build footer, auth-endpoint rate limiting, mobile navigation, Prometheus metrics and a /readyz readiness probe, and end-to-end tests covering the core readiness claims.

v0.1.0 — 2026-06

The initial tagged release: the multi-tenant foundation (organizations, workspaces, five-role RBAC, JWT auth with bcrypt and account lockout, a tamper-evident hash-chained audit ledger) and the first version of the NIS2 control library with assessments and an evidence vault.