Library Certification
A qualified compiler covers only the code you write. Every Rust program also depends on libraries — the core library at minimum, usually third-party crates as well — and each has to be addressed in the safety case.
The service covers:
Certification of Rust core, alloc and std, scoped to the subset a project actually uses
Certification of individual third-party crates
Dependency and code-flow analysis to establish what falls inside the safety boundary
Support for code-generating features: procedural macros and build scripts
Mixed C and Rust architectures, including FFI boundary verification
| Library | Status |
|---|---|
| Rust core (libcore) | Certified core subset available for ISO 26262 ASIL-B and IEC 61508 SIL 2, expandable to other safety standards on request. |
| alloc / std | Certification work ongoing. Scopeable to the specific subset a project uses. |
| Third-party crates | Certified per project. libm, micropb and heapless among those completed or in progress. |
| ASIL-D (core library) | Available on request, using the MC/DC approach described in Section 3. |
What this gives you
Certification cost is driven by scope, not by application functionality.
An unconstrained Rust application typically carries a dozen or more third-party crates. The large ones dominate cost: serialisation frameworks, database bindings, async runtimes, platform abstraction layers.
Analysis identifies what is genuinely reachable from safety-critical entry points. The rest is removed, moved outside the boundary, or replaced with a direct platform call.
Certifiable surface commonly falls to a small purpose-built set, often two or three crates.
Certification Tooling and Infrastructure
Safety certification produces a large and continuously changing body of evidence: coverage reports, requirements traces, tool qualification records, supply chain documentation. Ferrous Systems provides tooling across that workflow, most of it open source, and integrates it into existing CI rather than replacing it.
Standard Rust tooling — cargo, clippy, rustfmt, rustdoc and the built-in test harness — is Quality Managed and validated at TCL 1 or better in the relevant use context, so normal workflow is preserved. On top of that sit the certification-specific tools:
| Tool | Purpose |
|---|---|
| codeflow | Generates the validation scope report for a codebase. This report, with a rough code size figure, is what a quotation is built from. |
| callgraph analysis | Static analysis identifying which library functions and code paths are reachable from safety-relevant entry points. |
| blanket | Code coverage with assertion support, including the branch coverage evidence used in the MC/DC equivalence approach. |
| symbol-report | Symbol-level coverage reporting. |
| mantra | Requirements tracing for Rust projects, maintained as part of the development workflow. |
Supporting infrastructure
CI Docker images prepared for qualified builds
Private crate registries and local crates.io hosts
Dependency governance and crate approval workflows
Reproducible builds and SBOM generation
Air-gapped and non-privileged build environments
CriticalUp for toolchain distribution
Cargo natively; Bazel and other enterprise build systems where projects require them
What this gives you
Evidence stays current as code changes, rather than being reconstructed before each assessment.
Documentation, tests and code are linked by the toolchain itself, so traceability is not assembled across separate systems.
Clippy ships over 700 lints, a significant number directly relevant to safety-critical code.
In-context qualification brings custom scripts and integration points into the safety case without a standalone qualification effort.
Commercial partners fill the gaps where no open-source option exists: AbsInt for stack depth and timing analysis, TrustInSoft for formal verification including mixed Rust/C code, Solid Sands for C compiler qualification, Vector for AUTOSAR integration, and KDAB, JetBrains, Slint and Critical Section in their respective areas.