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

Jim Manico jim.manico at owasp.org
Tue Nov 24 00:10:09 UTC 2015

I'm in. Years ago Arshan D. built a software framework security maturity model that we could leverage to help with portions of this project. No need to start from scratch. ASVS can help inform us here as well. The ESAPI interfaces can also help us in these efforts. 

I think a continuous effort over a year or more is necessary to effect change. So when I say "I'm in" I don't say it lightly, Tim. We're trying to change the world anyhow, right?

Jim Manico
Global Board Member
OWASP Foundation
Join me in Rome for AppSecEU 2016!

> On Nov 23, 2015, at 9:07 PM, Tim <tim.morgan at owasp.org> wrote:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20151124/65a0ea27/attachment.html>

More information about the OWASP-Leaders mailing list