Holger Secure Update Gateway — MVP limitations
Maintained. State these plainly to any evaluator. The MVP is a verified, approved, signed delivery gateway — not a deployment system.
The MVP explicitly does not:
- Install or flash updates. It delivers a verified, approved, signed bundle and serves it read-only. The actual update to a PLC / drive / host is performed out-of-band by a human.
- Implement TUF or Uptane. The bundle format is versioned (
holger.update-bundle/v1) so TUF-style metadata roles can be layered later. - Use an HSM or PKCS#11. Signing keys are files the operator holds. Key custody is the operator's responsibility; the two-person rule + distinct release signer limit (not eliminate) the impact of a stolen key.
- Perform online certificate revocation (OCSP/CRL) in the protected zone. Trust is fingerprint/subject pinning; a compromised-but-listed signer stays trusted until the trust policy is updated and re-imported. No offline-CRL mechanism ships in this MVP.
- Provide active-active HA or automatic failover.
- Provide multi-site continuous replication. (Holger's replication remains a gated one-shot copy.)
- Automatically deploy to PLCs, change SCADA, or orchestrate maintenance windows.
- Replace the customer's SIEM. The audit log is an append-only local record, not a correlation/alerting platform.
- Guarantee an SBOM is semantically complete merely because one is attached. Attaching an SBOM proves it was attached and hashed — nothing about its coverage.
- Treat the demo advisory database as production vulnerability intelligence. A bundle's
policy_result.non_productionflag istrueunless a real imported advisory snapshot digest is supplied;holger-verifysurfaces the non-production marker.
Known MVP technical limitations
- Signer trust is a fingerprint/subject allowlist plus a single-level chain-to-root check (leaf directly signed by a trusted root). No full path building, no intermediate CAs beyond one level.
- Signatures are ed25519 only (the certificates must carry an ed25519 key).
- The container is a single znippy archive; no delta/patch bundles.
- Protected serving is the raw backend over HTTPS: the node serves the signed bundle as one artifact and the maintenance workstation runs
holger-verify extract. An airgap export bundle (holger-server export) is the exception: its import lands each artifact AVAILABLE in the intake chain's production repository, and Python wheels are served through a PEP 503 index there, so an unmodifiedpip installworks (seedocs/demo-airgap.md). Indexes for the other ecosystems (cargo, npm, …) are a follow-up. - OCI push/import of bundles is a stretch goal, deferred until the raw flow is proven.
Security assumptions
- The build toolchain and the crates the gateway itself is compiled from are trusted (supply-chain compromise of the gateway is out of scope).
- The airgap transport is untrusted (tamper/replay are defended); the media is assumed to physically reach the protected side.
- Operators keep private keys off the repository and the protected node; the node holds only public trust roots and signer certificates.
Deferred (designed-for, not built)
TUF/Uptane metadata roles · HSM / PKCS#11 · OCSP / full CRL distribution · automated PLC flashing · SCADA integration · asset discovery / CMDB · maintenance-window orchestration · canary deploys · automatic rollback execution · APT/RPM repository signing · CSAF ingestion · active-active clustering · multi-site continuous replication · a new SIEM · AI features · major GUI redesign · support for every package ecosystem.