Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 08 Oct 2014 20:20:04 -0400 (EDT)
From: "David A. Wheeler" <>
To: "oss-security" <>
Subject: Re: Thoughts on Shellshock and beyond

On Wed, 8 Oct 2014 15:48:10 -0700, Tim <> wrote:
> To me, it's not about anticipating the next bug, it is about providing
> guidance to developers who care only so much about security so that we
> can avoid some bugs that we didn't anticipate.


> PS- I'm of two minds on this.  More recently I've decided that educating
>     developers isn't nearly as effective as providing developers APIs and
>     development environments that make it unlikely they will shoot
>     themselves in the foot.  It's not that developers can't be trained,
>     it is that they will probably only be developers for a handful of 
>     years and move on to other roles later, with a whole new batch of
>     green coders coming in to fill their positions.  Anyway...

I don't think there's an either/or here.  Yes, if you *can* change the
tools/libraries/development environments to prevent attacks, or reduce
their effectiveness, you *should*.

That said, a fool with a tool is still a fool.  There's no way to create
a development environment that can't be misused.  Thus, you'll always need
to educate and train developers for situations the system cannot prevent.
In the long term I think this will be easier, because novice developers will be able
to learn from the many experts around them.  Today, the number of
developers who understand security issues is a vanishingly small percentage
of the total, so the novice has no one to learn from.

--- David A. Wheeler

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ