It is the high-performance/high-scale data processing and storage engines for data-intensive applications, some of which are used in high-assurance environments. These are used outside of defense/intel (the data models are generic) but defense/intel tends to set the development standards for government since theirs are the strictest and most rigorous.

An increasingly common requirement is the ability to robustly reject adversarial workloads in addition to being statically correct. Combined with the high-performance/high-scale efficiency requirements, this dictates what the software architecture can look like.

There are a few practical reasons Rust is not currently considered an ideal fit for this type of development. The required architecture largely disables Rust's memory-safety advantages. Modern C++ has significantly better features and capabilities under these constraints, yielding a smaller, more maintainable code base. People worry about supply chain attacks but I don't think that is a major factor here.

Less obvious, C++ has strong compile-time metaprogramming and execution features that can be used to extensively automate verification of code properties with minimal effort. This allows you to trivially verify many correctness properties of the code that Rust cannot. It ends up being a comparison of unsafe Rust versus verification maximalist C++20, which tilts the safety/reliability aspects pretty hard toward C++. Code designed to this standard of reliability has extremely low defect rates regardless of language but it is much easier in some languages than others. I even shipped Python once.

A lot of casual C++ code doesn't bother with this level of verification, though they really should. It has been possible for years now. More casual applications also have more exposure to memory safety issues but those mostly use Java in my experience, at least in government.