The federal government is urging software manufacturers to move away from using C and C++ languages to improve customer security, as highlighted in the Product Security Best Practices report. CISA and the FBI have set a deadline of January 1, 2026, for adherence to memory safety guidelines, especially for those involved with critical infrastructure and national functions.
The report doesn’t impose hard rules but offers suggestions for manufacturers to enhance security. It focuses on on-premises software, cloud services, and software-as-a-service. While the report doesn’t outright say that using “unsafe” languages could bar manufacturers from government contracts, it clearly communicates that such practices are not suitable for areas tied to national security.
The report points out that manufacturers can show their commitment to customer safety by following these guidelines, aligning with the Secure by Design principle.
It discusses the risks linked to memory-unsafe languages, labeling them as “dangerous” and a serious risk to national security. These languages, like C and C++, offer flexibility in memory management, but they also shift the burden of memory checks onto programmers. The NSA’s findings echo this, noting that they lack built-in protections against memory management issues that attackers could exploit.
Now, what should software manufacturers aim for by January 2026? They need to:
1. Develop a memory safety roadmap for existing products using memory-unsafe languages, outlining how they’ll tackle vulnerabilities.
2. Show how this roadmap will minimize memory safety risks.
3. Prove they’re making a “reasonable effort” to follow this plan.
4. Alternatively, they could switch to a memory-safe language.
The NSA backs several memory-safe languages, including Python, Java, C#, Go, Delphi/Object Pascal, Swift, Ruby, Rust, and Ada.
CISA and the FBI also call out several risky practices, such as:
– Allowing user-input in SQL queries or operating system command strings without proper validation.
– Using default passwords instead of generating unique, random initial passwords and requiring users to create their own during setup.
– Releasing vulnerable products listed in CISA’s Known Exploited Vulnerabilities Catalog.
– Incorporating open-source software with known vulnerabilities.
– Neglecting multifactor authentication.
– Lacking systems to track intrusions during an attack.
– Failing to publish timely Common Vulnerabilities and Exposures (CVEs) or weaknesses.
– Not having a vulnerability disclosure policy.
The report details next steps for organizations to align with these recommendations.
