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
Many of the recent high-profile Fortinet issues have involved memory-safety bugs, such as buffer overflows and out-of-bounds writes. These are classic C/C++ failure modes, and memory-safe languages like Rust can reduce the size of that risk substantially.
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