I don't see what updates you expect on CISA guidance because the very documents you reference already acknowledge that rewriting all code is not a viable strategy in the general case and that other options for improvement exist
For example, they recommend evaluating hardware backed solutions such as CHERI
> There are, however, a few areas that every software company should investigate. First, there are some promising memory safety mitigations in hardware. The Capability Hardware Enhanced RISC Instructions (CHERI
) research project uses modified processors to give memory unsafe languages like C and C++ protection against many widely exploited vulnerabilities. Another hardware assisted technology comes in the form of memory tagging extensions (MTE) that are available in some systems. While some of these hardware-based mitigations are still making the journey from research to shipping products, many observers believe they will become important parts of an overall strategy to eliminate memory safety vulnerabilities.
And acknowledge that strategies will need to be adjusted for every case
> Different products will require different investment strategies to mitigate memory unsafe code. The balance between C/C++ mitigations, hardware mitigations, and memory safe programming languages may even differ between products from the same company. No one approach will solve all problems for all products.
However, and that's where the meat of the papers is: They require you to acknowledge that there is a problem and do something about it
> The one thing software manufacturers cannot do, however, is ignore the problem. The software industry must not kick the can down the road another decade through inaction.
and the least you can do is make it a priority and make a plan
> CISA urges software manufacturers to make it a top-level company goal to reduce and eventually eliminate memory safety vulnerabilities from their product lines. To demonstrate such a commitment, companies can publish a “memory safety roadmap” that includes information about how they are modifying their software development lifecycle (SDLC) to accomplish this goal.
It's clearly not the case that these papers say "Rewrite all in Rust, now!". They do strongly advocate in favor of using memory safe languages for future development and I believe that's the rational stance to take, but they appear well groundet in their stance on existing software.
For example, they recommend evaluating hardware backed solutions such as CHERI
> There are, however, a few areas that every software company should investigate. First, there are some promising memory safety mitigations in hardware. The Capability Hardware Enhanced RISC Instructions (CHERI ) research project uses modified processors to give memory unsafe languages like C and C++ protection against many widely exploited vulnerabilities. Another hardware assisted technology comes in the form of memory tagging extensions (MTE) that are available in some systems. While some of these hardware-based mitigations are still making the journey from research to shipping products, many observers believe they will become important parts of an overall strategy to eliminate memory safety vulnerabilities.
And acknowledge that strategies will need to be adjusted for every case
> Different products will require different investment strategies to mitigate memory unsafe code. The balance between C/C++ mitigations, hardware mitigations, and memory safe programming languages may even differ between products from the same company. No one approach will solve all problems for all products.
However, and that's where the meat of the papers is: They require you to acknowledge that there is a problem and do something about it
> The one thing software manufacturers cannot do, however, is ignore the problem. The software industry must not kick the can down the road another decade through inaction.
and the least you can do is make it a priority and make a plan
> CISA urges software manufacturers to make it a top-level company goal to reduce and eventually eliminate memory safety vulnerabilities from their product lines. To demonstrate such a commitment, companies can publish a “memory safety roadmap” that includes information about how they are modifying their software development lifecycle (SDLC) to accomplish this goal.
It's clearly not the case that these papers say "Rewrite all in Rust, now!". They do strongly advocate in favor of using memory safe languages for future development and I believe that's the rational stance to take, but they appear well groundet in their stance on existing software.