The USA ONCD (Office of the National Cyber Director) is joining the chorus of people demanding that developers use memory-safe programming languages to “protect the security of our nation,” – though some C++ language experts reckon memory safety is just one small piece of the security puzzle.
The ONCD also took aim at software vendors who “are not sufficiently incentivized to devote appropriate resources to secure development practices,” and at their customers who “do not demand higher quality software because they do not know how to measure it.”
The strategy is condensed in a new report on the subject of “a path towards secure and measurable software.” The report includes a strong focus on memory safety and in particular, a statement that “using memory safe languages can eliminate most memory safety errors.”
The report acknowledges that “in some distinct situations, using a memory safe language may not be feasible,” using space systems as an example, where garbage-collected languages are not sufficiently deterministic. Rust has the requisite properties, the report says, but “has not yet been proven in space systems.”
The ONCD also points to hardware protections such as Memory Tagging in Arm chips, or CHERI (Capability Hardware Enhanced RISC Instructions), a research project of SRI International and the University of Cambridge, as possible solutions.
What though of measurability? The report has more questions than answers. “Software measurability is one of the hardest open research problems to address,” it says. Challenges include that most software lacks a uniform structure, making quality assessment subjective and context-dependent. Further, the behavior of software is not always deterministic; and its constant evolution means that assessments soon go out of date. The conclusion is that software measurability is a “research priority”.
The ONCD sought comments while preparing its support, and these are posted here. The Rust Foundation, for example, calls for “good practice requirements for publicly-funded organizations and their contractors to default to using memory-safe programming languages, such as Rust.” Microsoft puts the focus on software supply chains and the lack of sufficient investment in open source. IBM says that rewriting software may be too expensive and promoted ways “to protect existing software from memory-safety vulnerabilities.” Google says it is on board with the government championing “the transition to memory-safe languages and frameworks.” AWS adopts a nuanced response which “fully supports the practice of writing new projects in memory-safe languages” but also that this is “only a small factor in the overall efforts to improve open source software security,” highlighting that developers may disable the features that make Rust memory safe, for example, and that logic errors can end up being “bigger security problems than those related to memory safety.”
A notable response came from a group which describes itself as “a few C++ senior members with decades experience in ISO C++ (ISO/IEC SC22/WG21) acting as the ISO C++ Directions Group.” Their paper says that “memory safety is a very small part of security,” and that “C++ benefits from having a formal specification, a fully-specified memory model, and an active community of users and implementers. In contrast, some languages regarded as safe lack a formal specification,” this last point perhaps with Rust in mind. C++ is unfairly targeted, they reckon. “Much of the criticism of C++ is based on code that is written in older styles, or even in C, that do not use the modern facilities aimed to increase type-and-resource safety.”
There are plenty of other ways to make programming errors, they say in the paper, including logic errors, resource leaks, concurrency errors, type errors, timing errors, termination errors and more. They favour improved education of C++ programmers which “address safety issues from the start.”