To be fair, Fortinet, like so many security vendors are under the hammer at all times....BUT.......

Based on the last 12 months worth of vulnerability reports, may I offer my 2c worth on how they could have been avoided?

Memory Safe Languages / Strict Design Requirements

The majority of critical Fortinet vulnerabilities are memory safety issues (buffer overflows, out-of-bounds writes). These are classic C/C++ problems that memory-safe languages like Rust would prevent entirely.

If Rust isn't an option, use this checklist...

• No raw malloc/free or new/delete
• No strcpy, strcat, sprintf
• All array accesses bounds-checked
• All pointers validated before use
• All integer operations checked for overflow
• All error conditions handled
• Memory ownership clearly defined

Thorough Code Supply Chain Audits

While not directly evident in these specific vulnerabilities, supply chain security is crucial for enterprise security products.

Valgrind and Memory Analysis Tools

Tools like Valgrind, AddressSanitizer, or static analysis would have caught most of these buffer overflow vulnerabilities during development or testing.

Input Validation Always

Many vulnerabilities stem from improper handling of crafted requests or malformed input.

Proof Suite Before New Code

Comprehensive testing with edge cases and malformed inputs would have caught these vulnerabilities before deployment.

Cross-Platform Design for Code Quality

While not directly preventing these specific vulnerabilities... I always code for FreeBSD, Linux and Solaris (where applicable) as cross-platform development forces better coding practices and abstraction.

Fuzz Your Code

Try make it do unexpected things, does it crash, does it crash other pieces of infrastructure (yes software is infrastructure), etc. At the very least you'll sleep a little better knowing that it tends to behave well when unexpected junk is thrown at your code at high speed.

. #fortinet . #developeradvice