Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: What do you take for secure programming? |
|---|---|
| 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....
pgp4Pt81ruim5.pgp
Description: PGP signature
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: What do you take for secure programming?, Dave Aronson |
|---|---|
| Next by Date: | Dll Security, VP |
| Previous by Thread: | Re: What do you take for secure programming?, Dave Aronson |
| Next by Thread: | tools for analyzing java code, Mads Rasmussen |
| Indexes: | [Date] [Thread] [Top] [All Lists] |