Re: What do you take for secure programming?

Valdis.Kletnieks_at_vt.edu
Date: 05/06/05

  • Next message: David LeBlanc: "RE: What do you take for secure programming?" 
    To: Dave Aronson <sfsecprog2dave@davearonson.com>
Date: Thu, 05 May 2005 20:14:17 -0400

    On Thu, 05 May 2005 18:31:38 EDT, Dave Aronson said:

    > 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....

  • Next message: David LeBlanc: "RE: What do you take for secure programming?"