Perspectives on Code Scanning

[michaelslists at gmail.com (Michael Silk)]

On 6/8/07, Gunnar Peterson <gunnar at arctecgroup.net> wrote:
> > and that's the problem. the accountability for insecure coding should
> > reside with the developers. it's their fault [mostly].
>
> I find it fascinating that an industry like security, that has delivered a
> grand total of TWO working mechanisms[1] over several decades of effort, is
> so willing to throw others under the bus. Methinks they doth protesteth too
> much and all that...

what? i'm a programmer. i'm not laying the blame 'elsewhere' or
throwing someone else under the bus.

it's pretty obvious, though, that 'secure' programming should be part
of the general knowledge and practice that we do. just like we should
all understand algorithms and linked lists and how to use an array, we
should know how to do it securely.

pretty basic stuff.


> Instead it would be more productive for security to roll up their collective
> sleeves and help build better tools and services.

yeah well that's what you've been doing and it's nice and profitable,
of course, but it isn't really helping a whole lot if it requires so
many external 'things'. customer education, customer care, management
care, cost to business, and so on.

i mean yes, you have a profitable industry, so well done. but there
are better ways to solve the problem.



> 1. Get proactively involved in the SDL, tomorrow if not sooner:
> http://www.cigital.com/justiceleague/2007/05/24/sdlc-on-the-shoulders-of-gia
> nts/
>
> 2. Make sure that involvement is pragmatic, and helps the enterprise make
> the hard decisions to improve things instead of standard IT Security CYA:
> http://1raindrop.typepad.com/1_raindrop/2007/06/cost_effective_.html
>
> -gp
>
> 1. "one being the reference monitor and the other crypto" blaine burnham


-- 
mike
68 65 6c 6c 6f 20 74 6f 20 79 6f 75 2c
20 68 65 78 20 64 65 63 6f 64 65 72 2e