The Proof

Define. Build. Audit. Prove.

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.

1

Define the device image as a controlled blueprint

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.

  • — Real-time search across the full package catalog
  • — Kernel hardening flags as reviewable configuration
  • — Full build history per profile, with status and logs
TraceOS Image Factory: multiple controlled image profiles with blueprint, latest audit, and build status. TraceOS Image Factory: multiple controlled image profiles with blueprint, latest audit, and build status.
2

Build deterministically, audit in isolation

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.

TraceOS audit report for a completed build: 970 packages, 97 CVEs matched, 22,950 tracked files, and measured image size. TraceOS audit report for a completed build: 970 packages, 97 CVEs matched, 22,950 tracked files, and measured image size.
3

Every package, identified and source-verified

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.

  • — Runtime vs. build-time dependency classification
  • — CPE and PURL identifiers for ecosystem interoperability
  • — Deterministic source hashes for reproducibility claims
TraceOS Package Browser: each package with runtime classification, file counts, and its exact build derivation path. TraceOS Package Browser: each package with runtime classification, file counts, and its exact build derivation path.
4

Every file, hashed and mapped to source

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.

TraceOS Audit Explorer: the full deployed file tree, tens of thousands of files, each with a cryptographic hash. TraceOS Audit Explorer: the full deployed file tree, tens of thousands of files, each with a cryptographic hash.
5

Licenses and vulnerabilities, continuously watched

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

TraceOS License Audit: 40 unique licenses, 100% coverage, compliance status PASSED, and the obligations across the build grouped by what each licence demands of a release. TraceOS License Audit: 40 unique licenses, 100% coverage, compliance status PASSED, and the obligations across the build grouped by what each licence demands of a release.
TraceOS vulnerability surveillance: CVEs matched to the exact packages in the image, ranked by severity. TraceOS vulnerability surveillance: CVEs matched to the exact packages in the image, ranked by severity.
6

Bring your application into the same chain

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.

TraceOS product code analysis: a customer repository ingested at a pinned commit, 34 units documented, and a synthesized Software Detailed Design document. TraceOS product code analysis: a customer repository ingested at a pinned commit, 34 units documented, and a synthesized Software Detailed Design document.
7

Absorb your test evidence. Close the gaps.

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.

  • — Standard JUnit XML ingest — no new test tooling required
  • — Risk-driven test obligations, satisfied as evidence arrives
  • — Coverage gaps detected, then closed with generated tests
TraceOS test fulfilment run: units verified by their authors' own tests run in the isolated audit harness, units verified by TraceOS-written tests, and units still unverified, each counted separately. TraceOS test fulfilment run: units verified by their authors' own tests run in the isolated audit harness, units verified by TraceOS-written tests, and units still unverified, each counted separately.
8

Assemble the regulatory file. Approve it. Ship it.

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.

  • — Controlled milestones with explicit progression gates
  • — Hazards tagged in code flow into the ISO 14971 risk table
  • — One-click export of the complete evidence package
TraceOS Final Release: the generated IEC 62304 final compliance summary with executive compliance status, and one-click release archive export. TraceOS Final Release: the generated IEC 62304 final compliance summary with executive compliance status, and one-click release archive export.

Autopilot

Or press one button.

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

TraceOS Autopilot: define the image, point at your product repository, and run the entire compliance pipeline from one screen — human review tracked in parallel. TraceOS Autopilot: define the image, point at your product repository, and run the entire compliance pipeline from one screen — human review tracked in parallel.

See it run for yourself.

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