|
Secure Programming
What do you take for secure programming? Jan 27 2005 06:25PM Gustavo Rios (vieira rios gmail com) (3 replies) Re: What do you take for secure programming? Jan 28 2005 06:45PM mac4-security theory org (1 replies) Re: What do you take for secure programming? May 05 2005 04:54PM Gustavo Rios (rios gustavo gmail com) (2 replies) Re: What do you take for secure programming? May 05 2005 10:31PM Dave Aronson (sfsecprog2dave davearonson com) (1 replies) Re: What do you take for secure programming? May 05 2005 08:37PM Valdis Kletnieks vt edu (2 replies) Re: What do you take for secure programming? May 05 2005 09:17PM Gustavo Rios (rios gustavo gmail com) Re: What do you take for secure programming? May 05 2005 09:13PM Gustavo Rios (rios gustavo gmail com) (1 replies) RE: What do you take for secure programming? May 06 2005 04:31PM David LeBlanc (dleblanc mindspring com) |
|
Privacy Statement |
> could have a very lengthy thread trying (in vain) to define the exact
> differences between:
>
> - programmers (and whether it should have one m or two)
> - coders
> - systems analysts
> - software engineers
(yadda yadda)
One possibly useful metric is that the ability of automated checkers to detect
flaws is related to the level of abstraction the flaw is at.
Errors made at the coder level (fencepost errors, buffer overruns, double free()
errors, dereferencing after free(), and so on) are for the most part detectable
by automated means (C checkers like Splint, and languages like Java detect many
of them at runtime).
The next level up are errors like API issues - was the caller required to verify
the data passed, or does the called function have to do it? Who frees the memory
that a function malloc()s? These are usually *not* expressible in the language
as part of the API, and usually hand-checking of code is needed to find these
bugs (although automated checkers are making progress here).
At the top are errors at the systems analysis level - where conceptual errors
in the specifications introduce flaws and vulnerabilities. These are almost
impossible to detect automagically....
[ reply ]