The Proof
Every screen below is the live product operating on a real device image — nearly a thousand packages, twenty-three thousand files, all accounted for. This is the pipeline your auditors will see.
Your operating system starts as a declarative specification, not a golden disk image. In the Image Factory you compose from 110,000+ source-verified packages, configure kernel security flags, and manage profiles side by side. Every change is versioned; every build snapshots the exact configuration that produced it.
Each build produces the complete system image from source-controlled configuration — and the compilers and build tools that produce it are part of the same traced graph. The image then boots inside an isolated virtual machine, where a separate audit appliance mounts it read-only and inspects it from the outside. The system under test never audits itself.
The audit walks the entire dependency graph: which packages are deployed, where each was fetched from, and the cryptographic hash of every file installed.
The audit resolves each package in the image to its build derivation, output path, upstream source archive, and — where the source lives on a public forge — a browseable source tree pinned to the exact commit. Title, version, provenance: the precise identification IEC 62304 demands, produced mechanically. A navigable dependency tree with measured sizes answers "why is this on my device?" in two clicks.
The Audit Explorer is a file-level ledger of the deployed system. Every binary, library, and configuration file carries a SHA-256 hash and, wherever resolvable, a link to the exact upstream source file it was compiled from. Traceability for every line of code — not a sampled spot-check.
Each build receives a full license audit — unique licenses, package and file coverage, an explicit pass/fail status, and a human attestation workflow. In parallel, two independent scanners match known CVEs against the exact package versions in the image, ranked by CVSS severity. Your risk file reflects the system as built, not as remembered.
40
unique licenses identified
100%
coverage of the image
PASS
compliance status
Point TraceOS at your product repository. Your application code is analyzed into unit designs and software requirements in the same V-model as the operating system — linked to the same risks, the same tests, the same traceability matrix. One process for the whole device, not one for the OS and another for your code.
Upload the test results you already have — every result links to the units, requirements, and risks it verifies. Then TraceOS runs each component's own author-written test suite in its isolated audit harness, and those results link into the chain exactly the same way. Whatever the two together still leave unsupported is flagged, and additional tests are written, executed, and documented to close the rest. Every record says who wrote the tests — the component's original authors, TraceOS, or you — and who ran them.
Each project walks a guided V-model: from the audited build through unit designs, software and system requirements, and user needs — then back down through verification to release. Every artifact records the exact data snapshot it was derived from and passes human review before approval. The approved record assembles into a Design History File and exports as a complete release package in one click.
Autopilot
Every step above runs unattended: define the image, point at your repository, and TraceOS executes the full pipeline — build, audit, analysis, tests, documentation, DHF — with review tracked in parallel, never blocking. Re-run it on an existing product any time and measure what improved.
BlueprintDeterministic BuildIsolated AuditAnalysisTest EvidenceRisk FileDHF
A demo takes thirty minutes: the full pipeline on a live sample device, and a clear picture of what your own evidence package would look like.
Request a Demo