For Regulatory Affairs & Quality
SOUP is software you didn't develop and can't fully document. TraceOS removes that condition. Every component in your image is built from pinned source you hold, by a toolchain that is itself traced, and carries life-cycle documentation — unit designs, requirements, risks, and test evidence — produced under your own process. What genuinely remains third-party is inventoried and managed as SOUP: completely, mechanically, as the exception rather than the rule.
TraceOS does not certify your device — no tool can. It produces, repeatably, the objective evidence the classification demands.
IEC 62304 treats everything not developed under your own life-cycle process as SOUP — in a conventional Linux image, that is nearly everything. TraceOS inverts it: with full source access, verifiable builds, and generated life-cycle documentation, the stack is developed and documented under your process. Each obligation below is met either way you classify.
| Obligation | IEC 62304 reference | How TraceOS meets it |
|---|---|---|
| Identify every component by title, manufacturer, and unique version | §8.1.2 | The audit enumerates the complete system image — every package actually deployed — with exact name, version, build derivation, and upstream origin. Nothing is inventoried by hand; nothing is missed. |
| Specify functional, performance, and system requirements | §5.3.3, §5.3.4 | Each package's role is documented from its actual position in the dependency graph: runtime vs. build-time classification, the components that depend on it, and the requirements traced to it. |
| Verify software units, integration, and system behavior | §5.5 – §5.7 | Your test evidence is ingested and linked to the units, requirements, and risks it verifies. TraceOS then runs each component's own author-written suite in its isolated audit harness and links those results the same way; whatever is still unsupported is closed with additional tests it writes and executes there. Every record names who wrote the tests and who ran them, alongside yours. All of it is documented. |
| Evaluate published anomaly lists | §7.1.3 | Two independent scanners match known CVEs continuously against the exact versions in your shipped image, scored by CVSS and linked to the affected packages — a living anomaly review, not a snapshot. |
| Consider software failure as a cause of hazardous situations | §7.1.2 | Hazards are tagged at the source-code level during analysis and flow into the ISO 14971 risk table, where they are assessed for probability and severity and linked to mitigating requirements — and to the tests that verify those mitigations. |
| Maintain configuration management of software units | §8.1, §8.2 | The entire operating system is configuration: declared in version-controlled files, rebuilt deterministically, and snapshotted per build. A change to a single kernel flag is a diff, a review, and a new audited build. |
| Plan and document software maintenance | §6.1, §6.2 | Every rebuild re-audits the full system image and re-baselines the SBOM, hash ledger, license audit, and vulnerability report — post-market maintenance produces the same evidence quality as initial release. |
Traceability under 62304 is usually asserted in a matrix maintained by hand. In TraceOS it is a property of the data model: each link below is a database relationship, populated by the audit, and checked by gap analysis.
Every requirement resolves to the verified source unit that implements it, the binary that shipped, and the test evidence that proves it works.
Every generated document records the input data snapshot and template version it was produced from. An auditor can reconstruct any artifact's lineage.
Requirements without proof, risks without mitigation, and components without adequate tests are surfaced automatically — then closed in the isolated audit harness, first with the component's own author-written suite and then with tests TraceOS writes, before your auditor finds them.
A conventional Linux distribution is assembled from binary packages whose exact build inputs are unknown — provenance is a matter of trust. TraceOS builds the operating system from a complete, declarative specification: the same configuration always yields the same system, and every component carries a derivation recording precisely how it was produced and from what source. That is what converts software of unknown provenance into software of known, cryptographically verifiable provenance.
The same property covers the toolchain. The compilers, linkers, and build utilities that produced your image are part of its traced dependency graph — pinned, hashed, and source-mapped like everything else. A compromised toolchain is a detectable difference, not an invisible one. The audit does not sample or estimate — it walks the actual graph of the system that will ship, and of everything that built it.
Generated documents follow established IEC 62304 technical-documentation templates, with a readiness indicator that tells you when a project holds enough audited data to populate each one. Your quality system keeps its shape; TraceOS fills it with evidence.
Bring your notified body's last round of findings. We will show you, item by item, where the evidence now comes from.
Request a Demo