OgmaProtect
Compliance & assurance

The answers your assessor will ask for.

Not a certificate. A map from the controls frameworks ask about to what OgmaProtect actually does — every line backed by evidence in the source tree, and anything not yet shipped badged as such.

Controls

By control family

The letters are NIST SP 800-53 family codes, because that is the vocabulary most questionnaires borrow.

IA · AC

Identification, authentication & access

  • Named accounts with role-based permissions; every privileged action is checked against the role.
  • TOTP multi-factor authentication per user, with recovery codes. Mandatory for the support role; for other roles it is per-user enrolment, not enforced fleet-wide.
  • Lockout after repeated failures, scoped to user and source, so an attacker at one address cannot lock the administrator out from another; floors stop a policy that could lock everyone out.
  • Session lifetime and lockout thresholds are administrator policy, not constants.
  • Sessions are opaque, server-issued tokens in HttpOnly, Secure, host-locked cookies; CSRF tokens are bound to the session.
AU

Audit & accountability

  • Every privileged action is recorded with who, what, when and from where.
  • Each record carries an integrity tag and a sequence; deletions, splices and truncation are detectable, and the box checks itself on a schedule and alerts when the verdict is not clean.
  • An exported trail can be re-verified off the box with a standalone, dependency-free tool we provide to auditors.
  • Every record is mirrored byte-for-byte to syslog, for forwarding to your collector over TLS.
  • Audit export is part of the one-command support bundle.
CM

Configuration & change management

  • One canonical configuration; the native OpenBSD files are rendered from it, and a hand edit shows up as drift.
  • Every apply is validated first and recorded as a revision with its author; most domains roll back.
  • Drift between intent and live state is detected continuously and raised as an alert.
  • Risky changes revert automatically unless confirmed.
  • Default-deny and anti-lockout baselines in every ruleset the system writes; management HTTPS can be scoped to the sources you declare.
  • An unconfirmed configuration never boots live.
SI · RA

System integrity & vulnerability management

  • Every published release is signed offline; the package manager refuses anything unsigned.
  • The update check is off by default and sends nothing about the box when it runs.
  • Updates are two steps: stage and verify now, apply in your window behind a typed confirmation with an automatic snapshot.
  • A published security policy: acknowledgement within three working days, coordinated disclosure, advisories with a CVE state.
  • Only the latest release is supported — stated, not hidden.
  • C code runs under AddressSanitizer and UndefinedBehaviorSanitizer on every change; parsers are fuzzed daily.
SC

Boundaries & communications

  • Management over HTTPS only, with HSTS and a per-host certificate provisioned at first boot.
  • Each domain runs in its own sandboxed process; the web tier holds no secrets and no configuration.
  • Root-only sockets between tiers, and a capability token on every inter-daemon request.
  • No telemetry; nothing reaches us unless you turn the update check on, and even then it says nothing about the box.
  • DNS over TLS upstreams and DNSSEC validation for the resolver it manages.
CP · IR

Contingency & recovery

  • Signed, optionally encrypted configuration backups with role-gated import, verifiable on a different box.
  • A disaster-recovery runbook and a console-only restore path, rehearsed across two boxes.
  • High-availability pairs: CARP virtual addresses, pfsync state, authenticated configuration sync.
  • Unattended filesystem repair at boot, so an unclean shutdown does not strand a headless box — one command to enable on the software edition, pre-applied on the image edition.
  • A redacted support bundle in one command; a support role with its own MFA rule; root-console break-glass for a lost admin or a lockout.
SR · SA

Supply chain

  • The signing key exists only on offline media, held by two named custodians; CI never sees it.
  • The public key is published out of band — a DNS record on a separate domain at a separate provider — with its fingerprint printed on the download page.
  • The source is available to auditors and licensees on request; what a release ships is built from a published allowlist, so nothing internal rides along.
  • 2 packages beyond OpenBSD base and one vendored parser; third-party licences are listed.
  • Appliances arrive with the key anchored at the bench; no product credential is created at the factory. In progress

Where these land in the frameworks

Family-level pointers, deliberately. Your assessor's mapping governs and your scope decides what applies; this table tells them where to look.

Control area PCI DSS v4.0.1 NIST SP 800-53 ISO/IEC 27001:2022 Annex A Cyber Essentials
Identification, authentication & access Req. 7, Req. 8 AC, IA A.5.15–5.18, A.8.5 User access control
Audit & accountability Req. 10 AU A.8.15, A.8.16 —
Configuration & change management Req. 1, Req. 2, Req. 6.5 CM A.8.9, A.8.32, A.8.20–8.22 Firewalls · Secure configuration
System integrity & vulnerability management Req. 6 SI, RA A.8.8, A.8.19 Security update management — your process, using the signed releases
Boundaries & communications Req. 2, Req. 4 SC A.8.20, A.8.24 Secure configuration
Contingency & recovery Req. 12.10 CP, IR A.8.13, A.8.14, A.5.29–5.30 —
Supply chain Req. 6.3.2, Req. 12.8 SR, SA A.5.19–5.21 —

OgmaProtect holds no certification against any of these frameworks and is not listed as a validated product by any of them. Requirements that sit with your organisation — policy, training, physical access, scoping — are yours regardless of what runs on the firewall.

Component inventory

Direct dependencies of the package

Everything the package pulls in beyond the product's own code, and what the appliance image adds on top.

  • OpenBSD base Kernel, PF, CARP and pfsync, libc, LibreSSL, Perl, httpd and slowcgi, Unbound, iked, ospfd and bgpd, dhcpd, ntpd, WireGuard. One qualified release, named in every package.
  • databases/sqlite3 Configuration, revision and user stores. Public domain. From the OpenBSD package mirror.
  • www/p5-CGI Request parsing in the chrooted web tier. Same terms as Perl. From the OpenBSD package mirror, with its own run dependencies.
  • jsmn JSON parsing at daemon ingress. One vendored header. MIT.
  • resflash Builds the appliance image. Vendored and pinned, ISC. Not present on a software-edition box.
  • OpenBSD release sets and firmware Image edition only: the build downloads the OpenBSD release sets, verified with signify, and device firmware through fw_update.

Third-party licences are listed on the licence page. We do not publish a machine-readable SBOM file today; if your process needs one, ask — the list above is what it would contain.

Vendor assurance

What you can hold us to

  • A published security policy. Acknowledgement within three working days, coordinated disclosure, CVE identifiers requested from MITRE, and no fix cadence we might not keep.
  • Public advisories. Each states affected versions, impact, remedy, credit and CVE state. One is published so far.
  • A supported-versions statement. The latest release only, upgrades forward-only, no maintenance branches.
  • A pre-commercial audit, reported in aggregate. 8 lenses, 107 findings distilled to 23 root causes, remediated durability-first. Open findings are not published; the security page has the method.
  • An honest maturity label. v0.5.5, early access, pre-1.0 — on the home page, the roadmap and the FAQ, not in the small print.
3 daysworking days to acknowledge a report
1advisory published, CVE state stated
0telemetry or licence calls from the product
2packages beyond OpenBSD base

What we do not claim

  • No certification against PCI DSS, NIST, ISO/IEC 27001 or Cyber Essentials. No PCI DSS assessment has been performed on the product or on us. A PCI DSS review of a deployment raised a short list of hardening items; they are scoped, not yet scheduled, and will be described here as they ship.
  • No automatic updates — by design. Every update is staged and applied by an administrator.
  • No machine-readable SBOM file yet; the inventory above and the licence page are the published form. No idle-timeout claim either: session lifetime and lockout are policy today, and re-authentication after inactivity is being hardened.
  • No fleet inventory on our side: we know who has asked us for access, not what is running where. If you run OgmaProtect and we do not have a current contact for you, tell us — that is how an advisory reaches you.
Questionnaires

Send us the spreadsheet.

We will answer it line by line, point at the evidence for each, and say plainly where the answer is “not yet”.

Ask a compliance question Read the architecture