1.Invalid inputs potential:
Inputs->outputs. If you can stuff invalid input and the code can't detect it or crashes, its a vulnerability.
Fuzzers automate this step by creating lots of hostile/invalid input state.
2.Off-by-one,length/stack/buffer-overflows: check the length of input/buffers, does the code handle all cases?
C memory leak detectors/memory sanitizers can detect this.
3.Logic/Design flaws: Does code path assumes something that can be changed before or after execution? Does the code assumes a fast path that requires all circumstances to be correct?
Does the code ignores something that influences later execution(e.g. generic approach where special handling is required, special handling deferred to later step, losing global state information(e.g.with function calls))?
Static analysis tools will find most of this.
4. Exceptional/Corner cases: is the code exhaustive?
Can it handle all states of program? Usually the error is programmer assuming X can't happen and optimize it out, but due code evolution X suddenly becomes possible or was possible with exotic configuration/state.
This often can't be automated even with static analysis tools because is program-specific knowledge.
Rewriting it in Ada/rust/ocaml might be an alternative: they allow to specify exhaustive compliance with requirements and check all state combinations at compile time. Functional programming can also handle this with additional overhead and restricting the program global state. Security-centric stuff should not be manual:
C requires to do it manually or introduces run-time asserts.
The reason world doesn't run everything in Ada or equivalent, is that flexibility and speed are often as critical as security:
network stack that is 100% proven secure but twice slower will be replaced by network stack that is 99% secure and is twice faster. Same applies to most latency requirements:
if you program is secure but introduces X latency, it will be replaced by faster stuff that works reasonably well.
I guess a lot of desktop users would be very fine if they had 100% proven secure hostile-environment-exposing network stacks as long its able to handle some dozens of mbits. However I don't think that a proven secure network stack will be so slow, so that's interrupting normal network experience.
Most users don't see security, they see speed and latency.
Example for gaming: why are most games in C++?
C++ provides fastest speed/latency from the hardware without low-level effort.
In all areas where real-time control is critical, speed/latency are most important.
Imagine a Java GC stopping a program for a few milliseconds to recover memory, while it controls a fighter jet.
A server that is 30% slower because its written in Ada.
A program that requires 50% more memory, exceeding physical RAM and starting to swap.
Even C sometimes not fit to the task of extracting maximum performance, especially on embedded/mobile devices. Assembler(which is far less secure than C) is still used for speed-critical loops, audio/video decoders, cryptography and compression.
Users can sometimes see security failures (e. g. ransomware, data loss) as well as performance failures.
If it's only about speed you could argue games could have been written in C, I think C++ is used because it give the best trade-off between performance and productivity/software maintenance.
Imagine that people perfectly lived with lower computing resources few years ago and a small amount of performance gains could be traded in favor for security leading to a world with less security nightmares.
I think Javas misplacement in safety-critical or real-time-critical environments is not primarily because of its low performance, but because of its non-determinism. The most important thing in real-time applications is not primarily performance but rather timeliness.
Safety-critical or mission critical environments (aviation, military) often prefer Ada or its safer subset SPARK over error-prone languages such as C.
2.Off-by-one,length/stack/buffer-overflows: check the length of input/buffers, does the code handle all cases? C memory leak detectors/memory sanitizers can detect this.
3.Logic/Design flaws: Does code path assumes something that can be changed before or after execution? Does the code assumes a fast path that requires all circumstances to be correct? Does the code ignores something that influences later execution(e.g. generic approach where special handling is required, special handling deferred to later step, losing global state information(e.g.with function calls))? Static analysis tools will find most of this.
4. Exceptional/Corner cases: is the code exhaustive? Can it handle all states of program? Usually the error is programmer assuming X can't happen and optimize it out, but due code evolution X suddenly becomes possible or was possible with exotic configuration/state. This often can't be automated even with static analysis tools because is program-specific knowledge.
Rewriting it in Ada/rust/ocaml might be an alternative: they allow to specify exhaustive compliance with requirements and check all state combinations at compile time. Functional programming can also handle this with additional overhead and restricting the program global state. Security-centric stuff should not be manual: C requires to do it manually or introduces run-time asserts.
The reason world doesn't run everything in Ada or equivalent, is that flexibility and speed are often as critical as security: network stack that is 100% proven secure but twice slower will be replaced by network stack that is 99% secure and is twice faster. Same applies to most latency requirements: if you program is secure but introduces X latency, it will be replaced by faster stuff that works reasonably well.