The architecture assumes hostility — including toward us
Every FORGE OS design decision starts from the same premise: the network is hostile, the vendor might be unreachable, and code will eventually have bugs. So the posture is fail-closed — lose the tunnel and the site stops forwarding rather than degrading open. The only unauthenticated surface a spoke exposes to the WAN is a single cert-gated TLS listener that drops everything without a valid client certificate. There is no cloud dependency, no phone-home, no activation server, and the management plane is never internet-facing. Minimizing what an attacker can reach is our first and cheapest security control.
We don't write crypto. We pin validated crypto.
Data-path cryptography executes in a FIPS 140-3 validated module (CMVP certificate #5247) — third-party validated, not homegrown. Every tunnel is TLS 1.3 with mutual certificate authentication and a pinned AES-256-GCM suite, enforced at multiple layers of the stack so a misconfiguration can't silently weaken it. There are no downgrade paths and no "compatibility" cipher options, because an option you can turn off is a vulnerability with a settings page.
No code ships on trust in its author
Human-written code produced every CVE you've ever patched — which is why our pipeline treats verification, not authorship, as the security boundary. Architecture, threat model, and acceptance are human-owned. Every change goes through an adversarial cycle before it ships: build it, then actively try to break it — malformed input, dropped links, hostile-network conditions, operator misuse — and every shortcoming found goes back through review and gets rebuilt before release. In that spirit of showing rather than claiming: we use AI-assisted engineering tools in development, the same way we use compilers, linters, and emulation rigs — and nothing any tool or person produces reaches a build without surviving the process above. We'd rather state that plainly than have you find out sideways.
Every build is checked against outstanding CVEs
The firmware build pipeline checks every module in the image against published CVEs at build time — and a component with an outstanding vulnerability blocks the build. The pipeline will not cut an image over a known CVE unless a human reviews the finding and expressly overrides it; an override is a deliberate engineering decision, never a default. Dependency review is part of the build itself, not a periodic chore that can be skipped under deadline pressure, and build dependencies are version-pinned. A software bill of materials is maintained for every release and available to customers and evaluators on request.
Tested on emulated chaos and a live network
Releases run on a WAN-emulation rig that reproduces real link mixes — LEO, cellular, GEO latency, asymmetric loss — and on a live multi-site soak network of real spoke hardware that runs continuously against the current build. The performance numbers we publish come from that rig, measured, including the unflattering parts. A product that reports honest amber status to your NOC should be built by people who publish honest numbers.
Signed A/B firmware, built so patching fast is safe
Firmware updates are Ed25519-signed and install to an A/B slot scheme: a failed update rolls back automatically to the known-good slot, and monotonic anti-rollback protection prevents an attacker from downgrading a device to an old, vulnerable release. This isn't just integrity engineering — it's patch-velocity engineering. When a fix needs to go out, the update path is low-risk enough that there's no reason to sit on it. An agency should never have to choose between a risky update and a known vulnerability.
Found something? Tell us. We'll take it seriously.
Report suspected vulnerabilities to support@hamr-forge.com. Reports go directly to the people who build the product — there is no triage queue between you and the engineer. We will acknowledge your report, keep you informed as we investigate, credit you if you want credit, and take no legal action against good-faith research. Good faith means what it always means: report privately and give us reasonable time to fix before disclosure, don't access or exfiltrate data that isn't yours, don't degrade service for anyone else, and understand that this safe harbor covers finding and reporting flaws — it is not a license to extract, use, or redistribute code or proprietary information. Security claims on this page are commitments, not marketing — if you catch us falling short of one, that's a report too.