DEV Community

Cover image for C/CPP and the NISTIR 8397 Standard, Minimum Verification Tests for Cybersecurity
Mustafa Unal
Mustafa Unal

Posted on

C/CPP and the NISTIR 8397 Standard, Minimum Verification Tests for Cybersecurity

I’m a fan of Herb Sutter. He is a wonderful teacher and information sharer. During CPPCon 2022 talk (which you must listen) he said something that I’ve never heard before. A presidential directive which discourage usage of C/C++. So I find it, Executive Order (EO) 14028, Improving the Nation’s Cybersecurity, 12 May 2021 signed by US president Joe Biden. In it National Institute of Standards and Technology (NIST) was directed to recommend minimum standards for software testing with in 60 days and NIST developed NISTIR 8397, Guidelines on Minimum Standards for Developer Verification of Software.
In this standard They recommend the following eleven todo list:

  1. Threat modeling to look for design-level security issues
  2. Automated testing for consistency and to minimize human effort
  3. Static code scanning to look for top bugs
  4. Heuristic tools to look for possible hardcoded secrets
  5. Use of built-in checks and protections
  6. “Black box” test cases
  7. Code-based structural test cases
  8. Historical test cases
  9. Fuzzing
  10. Web app scanners, if applicable
  11. Address included code (libraries, packages, services)

NIST consulted National Security Agency (NSA) while developing it. So they get the best help they can get. It’s a pretty good list. In fact your code should have already been tested with them. But this is another story.
So what all of this has to do with C and C++ ? In Section 3.2 Supplemental: Memory-Safe Compilation C and C++ is directly referenced.

3.2 Supplemental: Memory-Safe Compilation
Some languages, such as C and C++, are not memory-safe. A minor memory access error can lead to vulnerabilities such as privilege escalation, denial of service, data corruption or exfiltration of data.
Many languages are memory-safe by default but have mechanisms to disable those safeties when needed, e.g., for critical performance requirements. Where practical, use memory-safe languages and limit disabling memory safety mechanisms.
For software written languages that are not memory-safe, consider using automated source code transformations or compiler techniques that enforce memory safety.

What this means is, you are actively encouraged not to use C/C++. Every firm that have a contract with government or regulated, will act accordingly. In the future one can expect the "Where practical" changed to "Must". And I think I’m not the only one that will predict in the future a change like this will happen.
Any good news? Herb Sutter show a new leaner C++ compiler with new syntax that has security features by default as an experiment. All hope is not lost, yet.

The standard is at https://doi.org/10.6028/NIST.IR.8397

Cover photo:(U.S. Air Force photo/Senior Airman Timothy Taylor)

Top comments (1)

Collapse
 
mrfamioii001 profile image
Mrfamioii001