OperationalSecurity
Week of October 4th, 2026Patch on 1.2.1: the engine and proxy images are rebuilt on a hardened base; the engine sources and configuration are unchanged. Pairs with HSM signer 1.5.x, like all of 1.2.Operational:
- Runtime base image pinned by digest. Both images now build from a digest-pinned base instead of a floating tag, so the base of a delivered image is fixed by its release tag rather than by its build date.
- The pinned base carries the current Debian OpenSSL fixes, clearing the images’ scanner findings. The library was never loaded (the engine uses rustls, and none of the bundled vendor libraries link OpenSSL), so this is scanner hygiene, not a fixed exposure.
OperationalSecurity
Week of September 14th, 2026Fixpack of the 1.2 line. Pairs with HSM signer 1.5.x.Operational:
- IBM HPCS signing backend removed. IBM discontinued the HPCS service, so the engine no longer offers it as a backend for its own signing key and no longer bundles the IBM GREP11 client library. Native IBM EP11 and every other signing backend are unchanged; only a deployment that still selected HPCS needs to move to EP11.
- Dropping the bundled GREP11 client removes the library that carried the engine image’s IBM-client CVE entries; they no longer apply to the 1.2.1 image.
New FeatureSecurity
Week of August 24th, 2026A large feature release built on a new data-model migration system that moves an organization’s governed state forward in explicit, engine-verified steps. Every protocol change is additive: a 1.2.0 proxy keeps working with engines still on 1.1.x, so a fleet can be upgraded progressively.New features:
- Engine-enforced signer authorization. The engine already required every signed action to carry a valid end-user signature; it now also checks that the user is permitted to perform the operation, verifying a permission chain against the governed permission dataset before signing. Authorization is no longer only the platform’s responsibility.
- Governed permissions. An organization’s permissions, operation sets, and assignments become governed state, so permission changes are tamper-evident like the rest of the tree.
- Organization-creation governance. A new organization is governed from its first action: its first admin and permission set enter the governed tree as one bootstrap step.
- Data-model migrations. Governed state advances through atomic, per-organization migration ceremonies with staged population, drain, and crash recovery, replacing the previous lazy, leaf-by-leaf rewrite.
- Opt-in mTLS auto-renewal for the proxy, with every acquired certificate verified offline against the engines’ trust anchor before it is installed. Off by default; the proxy serves its static certificate exactly as before unless enabled.
- The authorization gate above is the release’s central hardening item: a compromise of the DFNS backend can no longer wave through an action from a genuine user who holds no permission for it.
- Bootstrap and blind-signing paths were hardened to close state-resurrection routes, and an acquired mTLS certificate from the wrong issuer is refused at acquisition rather than failing the fleet later.
Bug FixOperationalSecurity
Week of August 17th, 2026Bug fixes:
- The proxy writes account status correctly against both the old and new platform auth schemas, so isolating a diverged organization, locking an account during bootstrap, and automatic recovery all keep working across the platform upgrade.
- A signing request polled in the brief window before the platform’s signing row is readable is now retried under a bounded budget instead of being failed permanently, closing a path that could leave a transfer stuck.
- Forwarding a log line to an engine is bounded by a short timeout, so an unresponsive engine can no longer hold up the proxy’s health-check loop.
- The engine warns at startup when its governed state is empty, distinguishing an organization awaiting its first bootstrap from one that has lost its state volume.
- A Merkle-root divergence (the tamper alarm) is now always mirrored into the customer’s own engine logs, and a failure to isolate a diverged organization is itself reported.
- The bundled IBM HPCS client library was refreshed, picking up upstream fixes for three availability-class advisories in its dependencies.
New FeatureSecurity
Week of July 27th, 2026Engine signing-backend rollup: the engine’s own integrity-signing key can now live in more places. All new backends are opt-in; existing software-key and HSM deployments are unchanged.New features:
- PKCS#11 signing wired end to end, so the engine’s signing key can be held and used inside a vendor HSM.
- AWS KMS added as a signing backend (pre-provisioned Ed25519 key), an architecture-independent cloud option alongside the software key and HSM backends.
- Vault-backed secrets for the proxy, with in-cluster Kubernetes and AWS IRSA authentication.
- EdDSA capability check at startup: the engine fails loudly at boot if its configured backend cannot produce the required signatures, instead of failing on the first signature.
- The signing key’s PIN is kept out of debug output, and startup refuses an ambiguous or incapable signing-backend configuration so the engine cannot come up signing through an unintended path.