| 1 |
On 06/23/2011 07:52 PM, Matthew Finkel wrote: |
| 2 |
> Programming secure software is not the easiest task to master. It takes |
| 3 |
> a lot of planning and enough knowledge about the components you're using |
| 4 |
> to know exactly how they all work together, as well as how they are not |
| 5 |
> supposed to be used. In many cases, vulnerabilities originate from lack |
| 6 |
> of knowledge in novice programmers. Other's are just something that was |
| 7 |
> overlooked in the planning stage, which becomes much more possible as |
| 8 |
> the size of the program increases. And, of course, sometimes people make |
| 9 |
> a mistake. |
| 10 |
|
| 11 |
It's getting easier to write "syntactically" secure code but you can't |
| 12 |
write "semantically" secure code unless you understand several domains |
| 13 |
simultaneously. There's been enough foul-ups to make the current |
| 14 |
generation of tools enforce syntactic security. But just because I *have |
| 15 |
to* use component XYZ in a function call, doesn't mean I have to make |
| 16 |
that call with *any* semblance of intelligence about the current state |
| 17 |
and environment. In other words, as Matthew wrote above, it ain't always |
| 18 |
that easy. You can bolt the doors and windows, but if your walls are |
| 19 |
merely sheetrock, a well placed foot will get you in. |
Archives