[Owasp-leaders] Instead of OWASP libraries, why don't we ...

johanna curiel curiel johanna.curiel at owasp.org
Mon Nov 23 21:34:50 UTC 2015


Yes, that's an excellent point.  We need to start small in this effort and
get the framework in place that helps us make good
recommendations.

I just volunteered to the NodeJS evangelist team to support them with
implementation and testing of security issues
I think in order to be part of these communities we need to get involved
with them,as they are also run by volunteers efforts

There is a project in place where Matt Konda has asked 50K for Developer
outreach, not sure if this means only traveling and assisting to developer
conferences since the project plan is not very detailed so far but it will
be submitted for approval of the board, however  I think these kind of
actions will not have any major results if is only about being in a
conference, as many leaders have done this in the past already.

https://docs.google.com/document/d/1KWTChGVzcw2lZopod5xLWWS4Ux9_5wIAPYMU3DBMPRE/edit

Being part of the SDLC as volunteer in the role of security
specialist/developer of security features might have a bigger impact I
think. I will try this approach with NodeJS, help promote to get a security
badge through the https://www.coreinfrastructure.org/programs/badge-program and
help improve security of the platform in this way





On Mon, Nov 23, 2015 at 5:10 PM, Tim <tim.morgan at owasp.org> wrote:

>
> Hi Kevin,
>
> Not responding to everything you said, but I did read it all. =)
>
>
> > If you have to "turn them on" then obviously they are not
> secure-by-default.
> > That's one point we need to emphasize.
>
> Yeah, exactly.  And going out to find a secure third-party library to
> do something for you implicitly means it isn't "on" by default.
>
>
> > Anyway, why do I bring this up? Because without a mechanism to allow
> > developers a *simple* migration path, you won't get developers to switch
> > to the new version. To illustrate with the extreme opposite case, lot at
> > everyone's favorite bogeyman, Struts 1.x. Major revisions were needed to
> > applications for applications to migrate from Struts 1 to Struts 2. As a
> > result, there are still many applications which large code bases that are
> > still using Struts 1 even though it is unsupported and has many RCE
> > vulnerabilities.
>
> Right, makes sense.  And we probably won't be able to get every
> developer to move off of the old, insecure APIs.  But we can at least
> guide new applications and new developers down a safer path.  It does
> work, BTW.  I have seen the number of XXE vulnerabilities in .NET apps
> drop dramatically over the last 5 years.  .NET still supports legacy,
> vulnerable-by-default XML parsers, but all of the newer stuff that
> they place front-and-center in their docs are secure by default.  It
> does make a big difference.  By contrast, Oracle isn't anywhere close
> to implementing this kind of proactive API security in Java.
>
>
> > How do we address this? Good question. I do not know of any general way
> to
> > do so, but maybe I'm overlooking something.
>
> I think as we evaluate APIs, we should include a checklist item:
> "Platform docs guide developers away from less secure and deprecated
> APIs to safer ones."  If they don't do that, then they get dinged in
> the rating.
>
>
> > Assuming this was not a rhetorical question there are a couple of reasons
> > that drive this:
> >     1) you end up in a development shop where they are already using that
> >        3rd party library.
> >     2) developers believe that using it will help them developing code to
> >        accomplish their business task at hand more quickly than not
> using it.
> >     3) some developers just want something new and shiny to put on their
> resume.
>
>
> Right, it happens.  And I wouldn't rule out approaching third-party
> platform developers, like Spring/Struts/etc, especially if the core
> platform doesn't provide an API for something everyone needs.  The
> LDAP APIs are a good example of that, so I just analyzed the APIs that
> came up first in google searches like "Python LDAP" and "Java LDAP".
> But in a given area, I think we should start with whatever is most
> likely to be used by novice developers for a particular task.
>
>
> > But that almos assumes that the original implementers of that core API
> have
> > a reasonable amount of security expertise. You might be able to do this
> for
> > platform APIs like the JDK or the .NET Framework, but I don't see that as
> > likely for most 3rd party platforms. And security folks don't gravitate
> to
> > libraries like Apache Commons (to use a recent example in the news) until
> > something bad is discovered. Where were we security people when these
> > interfaces of these Commons-Collections classes were being originally
> designed?
>
> Yes, that's an excellent point.  We need to start small in this effort
> and get the framework in place that helps us make good
> recommendations.  However, once it is in place, I think we definitely
> should look at new, up-and-coming platforms and "head them off at the
> pass", so to speak.  That is, try hard to catch these new whiz-bang
> frameworks early and help them build better APIs before we end up with
> a lot of less secure legacy implementations and technical debt.  The
> hard part here is anticipating where to spend our time and energy...
> Which new platforms will become the next fad?  That will take some
> guesswork, but it is still worth trying for.
>
> Thanks again,
> tim
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20151123/1b2bde0d/attachment-0001.html>


More information about the OWASP-Leaders mailing list