[Owasp-leaders] 2016 Developer Survey Results

Kevin W. Wall kevin.w.wall at gmail.com
Sat Mar 26 02:19:22 UTC 2016

On Tue, Mar 22, 2016 at 4:46 PM, Bill Sempf <bill at pointweb.net> wrote:
> On Tue, Mar 22, 2016 at 4:36 PM, johanna curiel curiel
> <johanna.curiel at owasp.org> wrote:
>> It will be interesting to know how to engage properly developers with zero
>> background in security.
> I can't speak for everyone on the initiative team, but this is exactly why
> I am interested in this.
> Since 2010 I have made "bridging the gap" a core focus of my community work.
> I give developer talks at security cons and security talks at developer
> cons.  Bringing the official OWASP banner to developer cons and talking to
> current devs about what they really need from us has brought be personally a
> lot of targeted focus in my content creation.
> That's why I think heading out to the large cons is a good start.

I think that Bill's strategy is the right one, but I think we need to go
further if we are to actually have a noticeable impact on assisting
developers with AppSec.

One reason for this, as Johanna has already alluded to, is that overall,
the percentages of developers who attend big development conferences is
relatively small. (If I had to guess, I'd say it is less than 2 or 3%.
If we are taking about any single specific one, those numbers surely are
even an order of magnitude or more less.) That figure is somewhat higher
for LOCAL development conferences, but I would bet that it is still way
south of 50%.

So I think that taking part in the developer conferences with the intent
to seed them with security talks is a good approach, but I don't think
it is going to nudge the appsec needle very far. (Personally, for those
appsec people who first and foremost don't consider themselves developers,
I think the more important reason for appsec folks to attend developer
conferences is to LISTEN and LEARN and try to understand why developers
struggle with application security. So often we "accuse" them of being
ignorant (sometimes wilfully) or just apathetic of security, but usually
in my experience, it is neither. I worked on an appsec team that was a
part of IT for 11 years and I have always considered myself a developer
first, and a security guy second. And my experience in IT tells me that
most developers seem to be interested in learning about application
security (and more than you think have already do so their own), but for
the most part, they:
       1) feel like security people treat them in a condescending manner,
       2) that we don't understand the other pressures facing them (e.g.,
           performance issues, late changes to requirements, schedule
issues, etc.).

So us sitting in on THEIR conferences will help us understand their
perspective and that can only be good.

However, as I said, I think (much) less than 50% of developers attend ANY
development conference at least once a year, so if our only strategic
initiative is limited to participating in their conferences, that is
not going to move the appsec bar very much.

I have always been of the belief that instead, we should do at least
two additional things to make appsec standard practice. (And note,
that should be our goal; we want this to be 'standard' practice, not
'best' practice.)

The first outreach is to volunteer to teach developer classes (paid or
unpaid) and mix in an appropriate level of security there. For instance,
if you teach a DB class, make sure to speak about SQLi and how to prevent
it. If you teach a web application development class in Java or ASP.NET,
make sure you bring up things like XSS and CSRF and SQLi. When I taught
a master's level CS class (Distributed Operating Systems) some 15 years ago,
I discussed things like various access control models, single sign-on,
etc. Many of those security-related topics were either not in the
text that was chosen or were at the end of the book and topics that
normally would not have been covered in a 1 semester course, but I
chose to include them anyway (at the exclusion of other topics,
obviously, but with the dept chair's approval). So do what you can,
when you can. We shouldn't aim to redefine non-security classes as
security classes, but we ought to look for places to naturally fit
security topics into the normal curricula flow.

The second prong of outreach that I think is even more significant
the the education outreach is that we, as appsec experts, need to collaborate
more with framework developers to assist them with designing, implementing,
and/or integrating security controls into their framework components.
I've often asked myself why we don't have OWASP members stepping up and
contributing to things like Spring Framework, the various Apache libraries,
OAuth or SAML libraries, or JavaScript libraries like AngularJS or Node,js,
etc.? Yeah, I can hear some of you saying, "well, if this isn't the case
of the pot (belly) calling the kettle black; I don't see you stepping
up!" Well, guilty, as charged. But consider this: rather than rushing off
and having US build new OWASP-branded libraries of security components,
would we not see broader use if we were to join with an established
framework and work together with their developers? For example, work with
the Spring Security development teams to add output encoding or encryption.
Or work with log4j, slf4j, or logback teams to add safe logging. Because
these other frameworks are already broadly adopted, we would have
an immediate impact. Furthermore, working closely with other development
teams would be proof to them that we are not the enemy.

As OWASPers, we much ask ourselves which is more important: building our own
brand recognition or the OWASP mission "to help organizations with application
security". If it's the former, then we should continue in building our own
libraries that are (relatively speaking) seeing little adoption in the
development community and stop the complaining when we don't see them
getting used as much as we would like.  But if it's the latter, then we
need to align ourselves much more closely with the development community.

Anyhow, in my usual TL;DR fashion, I've blathered on long enough, so don't
expect a summary. After all, if I had to stay awake while writing this, then
you can try to stay awake while reading it. (However, I would warn you not
to operate heavy machinery afterwards, as reading this may induce drowsiness.)

Best regards,
Blog: http://off-the-wall-security.blogspot.com/    | Twitter: @KevinWWall
NSA: All your crypto bit are belong to us.

More information about the OWASP-Leaders mailing list