[Owasp-leaders] Back into the Hornet's nest- Kick Off Projects

johanna curiel curiel johanna.curiel at owasp.org
Fri Jan 8 11:51:38 UTC 2016


Hi Kevin

Some clarifications regarding the proposal

On the 13th we want to get a feedback from the board on the proposal and
additional comments . At that moment no voting or decision will be done but
after the 27th January. Thats why I invite project leaders to be on the
meeting to help provide form to the proposal as you are doing through your
comments.

   - The incentive is to be spent only in the project itself or needs for
   the project leader as already defined by the actual rules regarding
   spending project budget, is not prize (see my comments on the proposal)
   - Agree regarding ranking as libraries through Toolswatch. However, we
   still want a form of vote, so we could change this to a 'survey' regarding
   the library. We need to get a form of community vote and form of measuring
   adaption of the library or any OWASP project. Please feel free to make
   suggestions for this part (example: amount of downloads, forks, measuring
   user adoption)
   - A yearly release with a clear versioning, it does not have to be about
   a major 'release'. Believe it or not there are many projects that do not
   even use versioning control. As a form of quality they should have a
   version.
   - At OWASP we do not count with staff able to deploy on the SWAMP or
   Coverty so the most logical will be to request the project leader, who
   knows his project code to provide a proof their project builds without
   issues. Thats why my proposal will rely must on Testers

Regarding 'stinking' Badges :
I think we do agree that we need to implement a form of showing that we
practice what we preach. We preach security, and ideally OWASP projects
should demonstrate they implement a form of Secure Development LifeCycle
especially when we talk about 'security libraries' like CRSF, Java HTML
sanitiser etc. This is what we want through a 'badge'. Now, the Core
foundation badge is nothing more than a maturity model showing that an open
source project actually exercises and implements 'secures coding' as
advised by many of our own guidelines such as SAMM, ASVS, Code Review etc.

So Kevin , while I understand is a burden, yes, it is because we want more
quality especially when a project wants to become a flagship and is being
used as a security library. A project does not need a badge if the project
does not want to graduate and become flagship,  but if this is want they
want, then the project needs to demonstrate it has a serious commitment to
security.Now this rule might have some exceptions when the project is an
'insecure' application like WebGoat or Security Shepherd, still it should
have a clear warning that installing that application will make the users
computer vulnerable to attacks.

About the Badge program:
https://www.coreinfrastructure.org/programs/badge-program
"The Best Practices Badge is a secure open source development maturity
model. Projects having a CII badge will showcase the project's *commitment
to security*. Open source project maintainers will be able to run an
automated tool and answer a short questionnaire to be awarded a "Best
Practices Badge". The CII Best Practices Badge is inspired by the multitude
of badges available to projects on Github."

Cheers

Johanna

On Fri, Jan 8, 2016 at 2:36 AM, Kevin W. Wall <kevin.w.wall at gmail.com>
wrote:

> On Thu, Jan 7, 2016 at 2:31 PM, johanna curiel curiel
> <johanna.curiel at owasp.org> wrote:
> > Hi All,
> >
> > After having many discussions in the past around multiple issues related
> to
> > governance and projects, I would like to congratulate the Board for the
> > latest decisions made. These have not been easy and without altercations
> > (including me quite upset with the situation) , but I believe that the
> > latest actions have shown that everyone is trying to achieve common goals
> > and the community's opinions has not been ignored.
> >
> > This year we hope we can kick off Projects with some serious actions.
> >
> > I have set this proposal which I'll be presenting to the Board meeting on
> > the 13th January so we can discuss this further and I strongly invite all
> > leaders to participate in the upcoming meeting on the 27th January
>
> I plan to be at the 1/27 meeting, even if I have to take PTO to do so.
>
> >
> https://docs.google.com/document/d/1PvNeEWgoO1w51VhHLwqqSgo0mBh-RvmSFUKMTz4QrYg/edit#heading=h.lw77ixr6kxi
> >
> > Come with an idea you can help implement, any small actions do help.
>
> There's a lot of stuff that I like here, some stuff that I'm uncertain
> about,
> and a few things that I have concerns over.
>
> I like the idea of the "year graduation incentives" as long as you
> change them all that the $$ go to the project budget and not merely
> to the project leader(s) or contributors. IMO, it should be used to
> help people attend various OWASP sponsored events that they might
> not otherwise be able to afford or to somehow help drum up other
> volunteers rather than just being spent on a giant pizza party / beer
> blast (not that I dislike those), but of course that's for the projects
> to decide for themselves. Question: Should any stipulations be placed
> on how the funds are used or when they must be used by? Better to
> think about that now before it gets adopted.
>
> I'm uncertain about the Project Reviews Code thing. I agree that
> we don't want it to turn into a popularity contest, but I think that
> using rankings via the Toolswatch Project is not a good solution
> because many of the projects we have are not "tools" per se and
> thus would be unlikely to receive votes. (Think Java Encoder
> Project, Java HTML Sanitizer, ESAPI, etc.) They don't fit into
> that "tools" category and thus would not likely garner many
> votes regardless of how good there were or how much they
> improved. Also, I think that it somewhat turns the project into
> evangelism. I personally suck at that. Manico OTOH (IMO) is very good
> at that. I suck at it mostly because I disdain doing it. It seems too
> much like tooting one's own horn IMO so anything that "smells"
> like that and I'm out as a leader. I'm sure I'm not the only project
> leader who feels that way.
>
> Regarding continuous monitoring...good concept, but the
> devil is in the details. All but the most successful FOSS projects
> seem to run in spurts. I think a yearly release is acceptable
> if it doesn't have to be a major point release with lots of
> (or any) enhancements...bug fixes (a certain percentage of
> the total or some minimal # perhaps) should be required.
> As for project activity, how to you measure that. In the past,
> I've had a tendency to create a private branch (in SVN days)
> and work on that and only rarely do commits. A lot of people
> work like that because they know what they have is a
> work-in-progress and they don't feel ready to share it with
> the world at any given moment. So if (for example) we were
> to measure "activity" somehow by regular commits and it
> was the habit of the few contributors to do most of the work
> privately and then only do 1 or 2 massive commits in the end,
> how would that compare to those who prefer to do much
> smaller weekly commits? In other words, we need to measure
> this 'activity' in some neutral manner that doesn't force a
> certain way of working. As for suggestions, I have none, but
> I'll try to think about it.
>
> Lastly what I am concerned about. I think your intent is good..to
> drive quality, but some important projects where we can barely
> get people to assist volunteering and are barely hanging one because
> they are 1 or 2 person shows, the additional requirements of
> using SWAMP and/or Coverity or getting Badges is just going to
> place an additional burden on these projects and most likely
> cause them to shrivel up and die. I am not against those things
> per se, but most SAST tools are full of false positives and it can
> take quite a bit of time going through all the identified instances and
> vetting each of them. If OWASP wants to volunteer someone to
> help out the projects with this--using SWAMP or Coverity and
> possibly doing a first pass at tossing out the false positives, then
> I think it might be workable. Otherwise, I think that the projects
> that are just hanging on are going to throw in the towel.
>
> @Tom: Can we suggest topics for the 1/27 (or future meetings) somewhere
>              or is the agenda already full?
>
> -kevin
> P.S.- You know how hard it was to refrain from stating that famous
>   quote from the movie _The Treasure of the Sierra Madre_?
>   https://www.youtube.com/watch?v=VqomZQMZQCQ :D
> --
> Blog: http://off-the-wall-security.blogspot.com/
> NSA: All your crypto bit are belong to us.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20160108/0e6e97e7/attachment-0001.html>


More information about the OWASP-Leaders mailing list