History says that security is a process, not a product (or artifact). I get it that C can be difficult. Pointers allow NULL dereferencing and use-after-free, strings are open to poor handling, etc. That said: we have OpenBSD w/ their re-written string/memory management and static and dynamic analysis tools with decades of development behind them.
I'm more hesitant to crucify C than I feel others are... are we throwing out the baby with the bathwater ?
To your comment -- that a C program is probably not secure -- most code written (regardless of language) is probably junk, with different classes of errors. Its tough.
Comments
History says that security is a process, not a product (or artifact). I get it that C can be difficult. Pointers allow NULL dereferencing and use-after-free, strings are open to poor handling, etc. That said: we have OpenBSD w/ their re-written string/memory management and static and dynamic analysis tools with decades of development behind them.
I'm more hesitant to crucify C than I feel others are... are we throwing out the baby with the bathwater ?
To your comment -- that a C program is probably not secure -- most code written (regardless of language) is probably junk, with different classes of errors. Its tough.
I was thinking of history as what actually happens as opposed to what should happen.
Assessing C#, code for example, you have at least two fewer entire classes of vulnerabilities to look for.