Embedded and space systems often need code close to the hardware, predictable timing and no garbage collector. The 2024 White House report says the most widely used languages with all three properties were C and C++, so teams there rely on hardware features, formal methods and hardening while memory safe options mature.
The three constraints
The ONCD report lists them for space systems:
- The language must allow code to be close to the kernel, to interact tightly with software and hardware.
- It must support determinism, so the timing of outputs is consistent.
- It must not have, or must be able to override, the garbage collector.
The third constraint rules out languages that depend on a garbage collector you cannot override. The report says that both memory safe and unsafe languages can meet the requirements, according to experts, and names Rust as one memory safe language with the three properties, though not yet proven in space systems when the report was written. It says further progress on toolchains, workforce education and fielded case studies is needed.
What to do in the meantime
The report offers a complementary route: memory safety through hardware. It mentions memory tagging and CHERI, with the caution that tagging is not a comprehensive fix. It also describes formal methods, including sound static analysis, model checkers and assertion based testing, as a way to show that classes of bugs are absent.
For a typical embedded team that adds up to a practical list.
A practical list
- Restrict the language subset. Use a coding standard, and enforce it with a checker in CI.
- Add hardening where the target supports it. Stack protection and non executable memory depend on the toolchain and the chip, so check both.
- Isolate parsers. Run code that handles untrusted input in a separate component with minimal privileges, if the hardware allows.
- Test with sanitizers on a host build. Compile the same logic for a desktop and run it under AddressSanitizer and UndefinedBehaviorSanitizer.
- Plan a safe language pilot. Choose one new, self contained component and build it in a memory safe language, then compare costs.
- Track your third party code. Firmware often vendors libraries, and those need an inventory and a patch path.
What the formal methods options look like
The ONCD report names three techniques. Sound static analysis examines software for specific properties without running it, and can work on source, architecture, requirements and executables. Model checkers answer questions about higher level properties but are limited at scale by computational cost. Assertion based testing records properties in the code so faults surface closer to their source.
The report adds that formal methods deployment remains limited, and that making them more accessible is vital. For a small team, the realistic first step is assertions in the code plus a static analyzer in CI, not a proof of the whole system.
Supply chain angle
Embedded products usually vendor third party libraries, such as protocol stacks and parsers, and those are often C. A memory bug in a vendored library is your bug in the field. Keep an inventory with versions, and watch advisories for each entry, so you know when to patch. A scanner that reads your build can produce that inventory from the dependency files you already have.
Be honest about the gaps
Resource limits, certification rules and available toolchains may block some of these. Write the gap down and revisit it each release, instead of dropping the item.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a dependency inventory lists versions, which is what firmware teams need for vendored libraries.
Quick check
Does the report say memory safe languages cannot be used in space systems?
No. It says Rust has the required properties but had not yet been proven there, and that more tooling, education and case studies were needed.
Sources
Last reviewed: 19 October 2026.
