Call for Software Developers to Cease Using C/C++ by 2026

According to the Product Security Best Practices report, the federal government is urging software creators to move away from C/C++ and implement other measures aimed at “mitigating customer risk.

Software Makers Encouraged to Stop Using C/C++ by 2026

According to the Product Security Best Practices report, the federal government is urging software creators to move away from C/C++ and implement other measures aimed at “mitigating customer risk.” Notably, CISA and the FBI have established a deadline of Jan. 1, 2026, for adhering to memory safety standards.

The report primarily presents guidelines and suggestions rather than enforceable regulations, especially for software developers engaged in critical infrastructure or national essential functions. The focus is on on-premises software, cloud services, and software-as-a-service offerings.

Although the report does not explicitly state that the use of ‘unsafe’ languages could disqualify developers from government projects, and it is considered “non-binding,” the message is clear: Such practices are unsuitable for any work related to national security.

“By adhering to the recommendations outlined in this guidance, developers will demonstrate to customers that they are actively addressing customer security outcomes, a foundational principle of Secure by Design,” notes the report.

The Introduction of Potential Flaws by Memory-unsafe Programming Languages

The report characterizes memory-unsafe languages as “hazardous and significantly heightens risks to national security.” The report highlights development in memory-unsafe languages as the initial practice to address.

Memory safety has been a subject of discourse since at least 2019. According to a 2023 NSA report on memory safety, languages like C and C++ “allow significant freedom and flexibility in managing memory while placing heavy reliance on the programmer to conduct necessary checks on memory references.” However, the report points out that these languages lack built-in memory protections to thwart memory management issues. Threat actors can exploit memory-related challenges that may emerge in such languages.

Key Actions Required from Software Developers by January 2026

By the onset of Jan. 1, 2026, developers should have:

  • Outlined a memory safety roadmap for existing products coded in memory-unsafe languages, detailing the approach to eliminating vulnerabilities associated with memory safety in critical code segments.
  • Provided a demonstration of how the memory-safety roadmap will mitigate memory-safety vulnerabilities.
  • Shown “reasonable effort” in adhering to the roadmap.
  • Alternatively, adopted the usage of memory-safe languages.

The NSA-approved memory-safe languages include:

  • Python.
  • Java.
  • C#.
  • Go.
  • Delphi/Object Pascal.
  • Swift.
  • Ruby.
  • Rust.
  • Ada.

SEE: Benefits, risks, and best practices of password managers (TechRepublic)

Various ‘Poor Practices’ Range from Weak Passwords to Disclosure Failures

CISA and the FBI have classified other practices as “extremely risky,” including:

  • Directly allowing user-provided input within the raw content of a SQL database query string.
  • Directly allowing user-provided input within the raw content of an operating system command string.
  • Employing default passwords. Instead, developers should ensure that their product offers initial passwords that are random and unique during installation, mandates users to create new passwords at the outset of installation, necessitates physical presence for initial setup, and transitions existing deployments away from default passwords.
  • Releasing a product with vulnerabilities listed in CISA’s Known Exploited Vulnerabilities (KEV) Catalog.
  • Implementing open source software with known security vulnerabilities.
  • Failing to utilize multifactor authentication.
  • Lacking the capacity to collect evidence of intrusion in case of an attack.
  • Delaying the publication of CVEs containing the Common Weakness Enumeration (CWE), which identifies the underlying weakness of the CVE.
  • Omitting a vulnerability disclosure policy.

The complete report features recommended steps that organizations can take to align with the guidelines set forth by the agencies.

About Author

Subscribe To InfoSec Today News

You have successfully subscribed to the newsletter

There was an error while trying to send your request. Please try again.

World Wide Crypto will use the information you provide on this form to be in touch with you and to provide updates and marketing.