[Owasp-leaders] Plan approach - help fix platforms devs use

Tim tim.morgan at owasp.org
Mon Nov 23 19:07:19 UTC 2015


Hi Johanna,

Thanks for following up on this.

> Based on your last email
> http://lists.owasp.org/pipermail/owasp-leaders/2015-November/015507.html
> 
> You mentioned: "The changes can be simple and subtle, but we have to
> convince the owners of those platforms to do it"
> 
> I think we should set a concrete plan here. How can we achieve this?


Agreed.  I am happy to start writing up an initial plan on a project
page or something similar.  But roughly, I would see next steps as:

0. Form an initial project team of 3-4 volunteers.  It needs to be a
   group effort in order to carry weight.

1. Set down high-level goals for the project.  (We need a clear and
   concise explanation of what we're trying to achieve when platform
   developers read up on what we're doing and why we're submitting
   suggestions.)

2. Write up some some guiding principles on what APIs should have to
   help developers stay secure.  This can be fluid and change over
   time.  Let's not spend too much time on it up front.

3. Identify one specific *type* of API that we want to target.
   Develop a specific checklist of items that APIs in this category
   should have.  Perhaps create a grading system based on these
   criteria (e.g. A through F like the SSL Labs grading system.)

4. Evaluate multiple platforms for the same type of API to do a
   side-by-side comparison.  Write up the findings and identify gaps.
   Quietly publish this on project pages or something similar.

5. Engage each platform evaluated in step 4 by submitting feature
   requests, bug reports, and/or patches encouraging them to close
   their gaps. 

6. Update evaluation/side-by-side comparison page (from step 4) as
   vendors make improvements.  Keep track of any positive changes
   we've helped make on a page dedicated to accomplishments of the
   project.

7. Repeat Steps 3..6 for other types of APIs, tackling them one by
   one. 


The nice thing about this structure is that volunteers can come and go
fairly frequently while keeping the overall project moving forward.
If someone wants to pitch in to fix say, LDAP APIs, then they could
help out with the evaluation and outreach to platform developers,
(maybe handing off some patch development to other volunteers who are
good in particular languages) and then call it "done" when most of the
platforms have closed their gaps.


> You said"* I have some ideas on that, but I **think it is going to require
> a significant initiative that I can't Tale on alone.  Does this resonate
> with anyone?*
>
> Yes we could indeed, I'm willing to support this one. "*It should be easy
> enough to approach smaller projects and frameworks, but in order to make
> the most difference, I think we need to engage the ***big* development
> platform maintainers.* "
> 
> Agree and for that purpose I think we can organise and invite everyone to a
> webinar, virtual meeting to begin with and grow this into a more serious
> meeting. We need to identify the Project managers/leaders at this
> frameworks projects.

I could definitely use help identifying more volunteers for the
initial effort.  A large part of that is just having people that will
keep *me* on task and not let the idea fall on my back burner
indefinitely.  I could also use help setting up the OWASP project
officially, since I've never done that before.


> I like in small and realistic steps so we could begin inviting small
> framework leaders to a webinar meeting such as
> 
>    - NodeJS==> this one is relative new in the scene but growing and full
>    of security issues
>    - MongoDB==>same
>    - Fill in here

I think smaller but growing platforms would be great to include in
some initial efforts.  Submitting requests with patches attached can
go a long way toward getting changes made quickly in open source
projects and show that the project's approach can work.  Also, if we
can get several smaller vendors to fix a particular API first, then
the larger ones might feel more pressure to do the same.

However, I'm not sure if inviting framework developers to a webinar or
meeting is going to be very effective.  At least not at first.  I
suspect they'll just blow it off.  However, if we submit feature
requests and link to project pages explaining what we're doing, they
may become familiar with the project that way, and then in the future
be more willing to join meetings like that.


> Lets try to start small with small framers but definitely quite important
> in the way they are being used now

Let's also consider what our volunteers are motivated to tackle, when
it comes to setting priorities.  I'm sure plenty of OWASP folks are
frustrated by API X in platform Y because it clearly invites
developers to make mistakes.  We can leverage that frustration to
tackle API X generally across platforms and make a good case for it,
since our volunteers are already experts in the area.

tim


More information about the OWASP-Leaders mailing list