Don't trust us. Check every release offline.
Your security team verifies every Kernwall OS release offline. Every request leaves a record, and nothing calls out. Below are the threat model, the supply chain and a dated plan for each certificate.
Threat model
Five ways in, and what stands in each.
Kernwall OS draws the trust boundary at your site wall and treats everything that crosses it as hostile, us included. Each threat names its control and the record your assessor gets.
Insider
- Attack
- An admin or user reads data they shouldn't, or quietly changes a model or a log.
- Control
- The OS image is read-only, so changing it takes a signed bundle, not a login. Retrieval inherits source-system ACLs. Every prompt, retrieval and tool call joins a hash-linked chain tied to user identity.
- Evidence
- The audit chain, anchored to TPM quotes and exported by media or diode.
Supply chain
- Attack
- A tampered OS image, driver, container or model arrives on the update media.
- Control
- One signed release bundle. The import station verifies signatures against an offline trust root, re-scans, and re-signs with your site key before anything reaches the appliance.
- Evidence
- The verify report, SBOM and scan report for each bundle imported.
Malicious model
- Attack
- Weights that execute code on load, or a fine-tune of a base your rules bar.
- Control
- Ingest accepts safetensors or GGUF only, with no pickle and no unreviewed remote code. Lineage is checked against policy, and every promotion passes eval and red-team gates.
- Evidence
- A signed AI-BOM and eval report for each model you serve.
Prompt injection
- Attack
- A document in the RAG index tells the model to leak data or call a tool.
- Control
- Retrieval is limited to what the asking user may read, chunks carry classification labels, and tools run only from signed, allow-listed manifests. Egress is denied, so there is nowhere to send data to.
- Evidence
- Tool calls and retrieved document IDs in the audit chain. Mitigated, not solved: no vendor can promise more.
Physical access
- Attack
- Someone pulls a disk, boots their own kernel or swaps the root filesystem.
- Control
- Owner-enrolled Secure Boot keys, a signed unified kernel image, a dm-verity root, and a data volume sealed to the TPM's signed boot policy. Lockdown and signed-only modules are on.
- Evidence
- Measured-boot PCR values and a continuous TPM + IMA attestation record.
Whoever holds your owner keys can sign what they like. Kernwall records every signing in the audit chain; it can't make one impossible. Implants in the server hardware itself belong to your procurement chain and the OEM. A model that is simply wrong is out of scope too: evals make it rarer, and your process still decides what a model may do.
Supply chain
Every byte on your appliance has a receipt.
Each release crosses the gap as one bundle: OS image, GPU drivers, runtime and model shards. Every step leaves a record your team checks offline, without trusting us.
- Source
Pinned upstream sources, reviewed and mirrored. Nothing fetched at build time.
- Reproducible build
Two independent builders produce the same bytes, or no release is cut.
- SLSA provenance
A signed attestation of what was built, from which commit, on which builder.
- Signature
TUF metadata, ML-DSA and LMS signatures, a trusted-time floor for expiry checks.
- SBOM · AI-BOM · VEX
Every package and model listed, to the G7/CISA minimum elements for AI SBOMs; VEX says which CVEs actually reach the image.
- Site import
Kernwall verifies it offline, re-scans it and re-signs it with your key. Your key decides what runs.
Certification roadmap
Every certificate we plan, in order.
Kernwall holds no certificate today. This is the order we pursue them in, and the page moves as each one starts.
Status as of 29 Oct 2026 · nothing held
From the first release
CRA vulnerability handling
Before first release · planned
PSIRT, coordinated disclosure, security.txt and the ENISA reporting process. CRA reporting has applied to products on the EU market since 11 Sep 2026.
SBOM and VEX per release
Before first release · planned
CycloneDX or SPDX for every bundle, with VEX statements and the scan report beside them.
Secure development lifecycle
planned
Built to NIST SSDF and IEC 62443-4-1 from the start, so the later audit checks a process that already runs.
OSCAL and SCAP content
planned
Kernwall ships an OSCAL component definition and OpenSCAP checks for your assessor.
First certificates
ISO/IEC 27001
planned
Information security management for the company that builds and signs the releases.
IEC 62443-4-1
planned
Secure product development, audited. The certificate your fab, utility or OT assessor asks for.
SOC 2 Type II
planned
The controls report your bank or hospital auditor asks for.
ISO/IEC 42001
planned
AI management system.
DISA Vendor STIG
planned
Intent form, then a vendor-written STIG for US assessors. Supports a faster ATO; it is not one.
European government
ANSSI CSPN
planned
France's time-boxed first-level certification of the security functions, recognised by Germany's BSZ.
CRA conformity and CE marking
planned
Operating systems are CRA important products (Annex III, Class I). Required before the CRA fully applies.
EUCC (substantial)
planned
The only EU Common Criteria route since national schemes ended on 27 Feb 2026. Evaluation starts in this phase.
BSI VS-NfD approval
planned
Germany's restricted-data approval, through the qualified-manufacturer route.
IEC 62443-4-2
planned
Component requirements for the appliance as a host device, at SL2: the level ISASecure recommends as the minimum for off-the-shelf components.
NATO NIAPC listing
planned
Through a sponsoring nation, on the back of EUCC.
Later, with a US partner
NIAP GPOS evaluation
planned
US Common Criteria for general-purpose operating systems, after the European certificates.
Your assessor grants the authority to operate, and no vendor can ship one. Kernwall ships the evidence that shortens it: SBOMs, scan results, OSCAL documents and an audit chain mapped to the controls your assessor tests.
Documents and policies
What every release must carry.
Nothing here downloads yet, because no release exists yet. Kernwall calls a build a release only when it carries every item below.
- Architecture and security whitepaper
- SBOM, AI-BOM and VEX for every release
- Scan reports for every release, beside a stock Ubuntu + CUDA image
- Penetration-test summary from an outside lab
- STIG and SCAP results
- OSCAL component definition
- Signed release feed and changelog
- Disclosure
- A coordinated disclosure policy, security.txt and a PGP key, published when the security contact goes live. Until then there is no product to report against.
- KEV fixes
- Design target: a signed fix bundle on the day a CVE in the image joins CISA's KEV list, as its own emergency channel.
- Telemetry
- None by default. If you want health data out, it leaves through a one-way diode you control.
- Vendor access
- No remote access path for Kernwall. Support happens on site or through media you inspect.
- Keys
- Release keys sign bundles; your site key decides what runs. We never hold your site key.
Open source we build on
Upstream licences as of Oct 2026 · final list ships as each release's SBOM- Linux kernel (opens in a new tab)Kernel, lockdown, IMAGPL-2.0-only
- systemd (opens in a new tab)UKI, measured boot, sysextLGPL-2.1-or-later
- cryptsetup (opens in a new tab)dm-verity, LUKS2GPL-2.0-or-later
- NVIDIA open GPU kernel modules (opens in a new tab)GPU driverMIT / GPL-2.0
- vLLM (opens in a new tab)Inference serverApache-2.0
- llama.cpp (opens in a new tab)Edge inferenceMIT
- python-tuf (opens in a new tab)Update metadataApache-2.0 / MIT
- Keylime (opens in a new tab)Remote attestationApache-2.0
- Keycloak (opens in a new tab)Identity gatewayApache-2.0
- OpenSCAP (opens in a new tab)Compliance scansLGPL-2.1
Test it
Bring your assessor's questions to a pilot.
Your pilot runs on your hardware, inside your walls. Your security team checks every claim on this page.