AF antonio.fontes at gmail.com
Wed Mar 11 14:15:17 EDT 2009

Hi All,

I clicked (and read the content of) some of the links in Paulo's and
Dini's email and it seems to me that something is missing in the
updated assessment criteria, at the alpha level I guess: what
meta-information should a new project provide for better integration
in the portal? The problem of projects classification was already
raised in discussions during the EU08 summit, and it appeared that
there was a tight connection with how they are listed, sorted,
classified, etc. on the OWASP's portal. Hence, this email.

For those who don't have the time to read my entire email, here is a
one phrase summary:

"What about adding access links to projects, sorted by specific
positions in the software development lifecycle? ("business analyst"
link, "designer" link, "security officer" link, "developer" link,
"code reviewer" link, "tester" link, "pentester" link, "project
manager" link, etc ?"

For the others, the text below just explains how I came to ask this...

--a very short story (it appears that people love short stories)
During a training, which I gave recently to a web project team
(developers/designers/testers mostly), I asked the audience to browse
the OWASP website projects page.

After 2 minutes, I asked them "Can someone tell me which projects
might be useful for your job?", they could not answer except for one
(who already knew well about the OWASP). The others, I had to tell

Aaaargh, how many people can't actually see that many products answer
their needs?
--end of the very short story

As I browse the projects page of the OWASP wiki, I see I can access
them through their achievement level (release, beta, alpha, inactive),
their 'category' (detect, protect, life-cycle) and but not least,
their name (they seem to be sorted alphabetically). This gives us 3
different ways for accessing projects:
- through their status
- through their name
- through their category

But...who actually comes to the OWASP projects page and looks for
projects according to their status, name or category? I guess
statistics will mostly tell us that visitors search by their status.
Indeed, there are four "status" tabs only and there's no way to access
them otherwise. (I might be wrong, I just browsed the home page and
clicked 'OWASP Projects')

Let's have a look at what the others do. Specially, those who sell for
a living: multi-product/services company websites. We will see that
they generally show their product/service offer in at least 2 ways: by
business or by function. Almost every company (driven by sales, I
mean) with its own  website actually tries to get that answer by
asking the visitor: "Tell us who you are, and we will tell you what we
have for you." This is a central, basic, worldwide, marketing issue
for thousands of companies that don't sale just because their
potential customers don't even know that some guy somewhere found the
right answer to their needs.

"Our mission is to make application security visible"

I translate this mission into 2 sub-missions:
 1) establish good tools and documents
 2) make them visible

Everyone in this list knows we have fantastic tools and documents. Why
doesn't the website offer developers, designers, QA assurance guys,
project managers, etc. a quick way to clearly identify which
tools/documents are available for them and in what way do they solve
their problem? (that would actually be the 'visibility' part)

I am proposing new tabs for the projects, ordered in accordance with
the SDLC, accompanied with action-oriented invitations. Something

 "Which projects best suit your needs?
  - Are you buying a web application? click here
  - Are you managing a web application project ? click here
  - Are you in charge of collecting business requirements? click here
  - Are you designing software ? click here
  - Are you coding software ? click here
  - Are you reviewing the code ? click here
  - Are you testing software ? click here
  - Are you maintaining software? click here
  - Are you the security officer or the member of a SSG ? click here

A developer should see projects such as the building guide, the
antisammy library, the ESAPI library, etc.

A tester should see the testing guide, tiger, wsfuzzer, scavenger,
dirbuster, etc..

A reviewer should see the code reviewer, the ASVS, etc.


Wherever you work in the SDLC, there should be a page that shows you
all things the OWASP can do for you.

Now, the last topic I need to address here is: in what way does this
relate to the OWASP project assessment project? Well, very simply: if
we want the project listings to follow such organization, that
information needs to be provided sometime between the project creation
and its appearance in the listings. The project assessment alpha stage
can easily request this: a newly initiated OWASP project should
clearly indicate where it stands in the SDLC and which need it
addresses, precisely. Nothing more.

I think this would first help visitors of the website finding what
they need. I also think that providing and formalizing that
information during project initialization would give some strong
direction to follow towards the accomplishment of the tool/document.

Just my 2 cents, as usual ; )

More information about the OWASP-Leaders mailing list