Someone recently asked the GPC about one of the new requirements under the Assessment Criteria v2:   conference style presentation that describes the tool/document in at least 3 slides.

Below is Matt Tesauro’s reply:

“For some examples, look at the short slide desks that were used as project overviews at the OWASP Summit 2008.  e.g below is the one for OWASP Orizon:


The summit page is here:


I’d use the OWASP Education slide template for the look/feel of the slides.  The idea was to provide the education project with slides explaining the various projects that OWASP offers.  So an OWASPer could combine several projects slides into a review of a category of OWASP offerings (like tools/docs for developers).

The template is here:


The OWASP Report Generator has a new leader – Mark Roxberry. Know more at ORG2 Roadmap Thoughts.

Someone recently asked the GPC about one of the new requirements under the Assessment Criteria v2:   Project Flyer/Pamphlet.

Below is my reply


Here’s the general idea behind that pamphlet (as I understand it). BTW, I wrote much of the Criteria v2 content where this stuff originates. It was a synthesis of my experiences with SoC2008 & many discussions on the GPC calls plus various conferences.

The idea behind the one page pamphlet is this: Think about an OWASP booth at a conference.  If you had 1 page to get across the idea behind your project, what would it be? Think of it as a paper form of the proverbial elevator pitch. Sum up what it is that is unique, cool, useful, etc about the project and why someone would want to invest their time with it (either using it or contributing to it). Ideally, the pamphlet would allow some who knew nothing about your project to quickly decide if it would address any needs/concerns/interest they have.

This is new enough that there isn’t an established format but I’d think that at the least hitting the what, who, when ideas would be useful:

  • what is the project about?
  • who would use/benefit from your project?
  • when would your project be used?

Make sense?


The “Project Identification” frame created to support the OWASP Assessment Criteria 2.0 has been approved yesterday by the Global Projects Committee.

Check it out!

I was recently asked about the situation around two OWASP projects that are nearly duplicates.  Wanting to make this discussion very public, I’m carrying over my answer to the GPC’s new blog.

Background:  Someone asked what had become of OWASP CAL9000.  I responded that CAL9000, while still useful, was pretty much dormant and orphaned by the project lead.  I also suggest that they should look at EnDE which is an amazing bit of JavaScript encoding/decoding goodness that came out of the OWAP SoC 2008.

Below is the questions and repsones my reply inspired:

> Matt
> You are part of the Global Project Committee does Criteria 2.0 Draft
> will touch the issue of duplicated projects/efforts? And what could
> be considered a duplicated effort?
In all honesty, it doesn’t.  But that is on purpose.

Here’s why:  Now that there is a Global Project Committee (GPC), proposed projects are reviewed by the committee which should be able to catch duplicated efforts.  Paulo does a great job of running project proposals by the GPC before he doe the initial project setup.  If there is a project that has created a release and is ready to be reviewed under Criteria v2, its far too late.

In the specific case of Cal9000 & EnDe, there were a couple of factors which are hopefully fixed under the new Global Committee structure – especially the GPC:
– No peer review of proposed new projects to catch duplicates
– No good or known process to orphan projects and find new leaders for them

Call this a lesson learned which will (hopefully) be avoided in future.

> I understand 2 project might do the same thing for different
> technologies, but if they are in the same technology and one covers
> the other or they both do the same thing shouldn’t we deprecate one
> in favor of the other or simply merge them?

Absolutely.  Unfortunately there really isn’t a process to deprecate projects currently.  That is something that is actively being worked on by the GPC.  See the top item on our committee’s agenda for the year:

In future, the GPC hopes to have a mechanism to determine which projects are either orphaned or dormant.  For those project that are still relevant, we can announce their availability for new project leads to take over.  For those that are no longer relevant, they will be archived.  For example, consider these two fictitious OWASP projects which are orphaned/dormant:

OWASP PHP 3.3 coding guide:  This is a project which probably isn’t very relevant since PHP is currently up to 5.x.  The project page should be marked “Archived”, “Deprecated” or something similar and it moved to a archived/historical projects part of the OWASP Wiki.

Ruby on Rails Hardening Guide:  Ruby on Rails is still very popular and in use widely.  This project would be listed as orphaned and the GPC would try to find a new project lead to take over this project.

> IMO merging project will boost both projects (previous) into a new
> and better solution for the community, but I don’t know if people
> will like to give up the lead of their own “baby” (there project you
> have spent a lot of effort)
I’m not sure that would work for CAL9000 and EnDe considering when this issue came to light – for me about a month ago in Poland.

However, for projects in general, you’d be surprised.  Of the project leads that no longer wanted to maintain their projects, I can’t think of one that wasn’t happy to help a new project lead take over and move forward.  The GPC’s challenge is to make that process as open and easy as possible.

As you all know, we have had some internal debate about what the requirements are for an OWASP Project to continue to be an OWASP Project. This mainly surrounds the Assessment Criteria that mandates that an OWASP Project have it’s “main” page at the OWASP.org webiste.
Our current example is around the Enigform project. Luckily, Buanzo is great to deal with and he is being very cooperative about what we need from him.
He actually raised a few good points.
Many of the “enigform”‘ sites are old and may have been present before the SoC was sponsored. Many of the sites are inactive, but may still contain relevant information. (Se we don’t want to take them down, nor do we want to force leader to go back and change them all)

I think our discussion around “each main external site having to point back to the owasp wiki” has the following issues:

1. It is not enforceable. None of us have the time, or personally speaking, the desire to police each and every project and every external page they may or may not have.
2. It is unrealistic. Each OWASP project could have a life before and after, and requiring this just seems like a serious hassle.
3. Who determines what external sites should or don’t have to “point back to the wiki” (for example, a simple 4 sentence blog entry wouldn’t qualify most likely)

My proposal is that we stick with the existing requirement set forth in the ACv2 (http://www.owasp.org/index.php/Assessment_Criteria_v2.0) that very specifically states what requirements are needed for your project page on the OWASP Wiki to be considered have met the “Project Wiki Page Minimal Content “.

It seems to me that rather than try to control what Project leaders do outside of OWASP, we should just make an extra effort to be sure the the OWASP brand is something exclusive enough that they WANT to put the OWASP all over every project page.

Keep in mind, I’m not here to start an argument, just to get a dialog started.
Please post your thoughts. Ideally, I’d like to get a vote going on who agrees/disagrees and why so we can put this issue to bed.