This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "OWASP Working Session - OWASP Tools Projects"

From OWASP
Jump to: navigation, search
m (Adding vote totals)
 
(17 intermediate revisions by 11 users not shown)
Line 1: Line 1:
 +
[[Category:OWASP_Working_Session]]
 +
= About the Working Session =
 
{| style="width:100%" border="0" align="center"
 
{| style="width:100%" border="0" align="center"
 
  ! colspan="7" align="center" style="background:#b3b3b3; color:white"|<font color="black">'''Working Sessions Operational Rules''' - [[:Working Sessions Methodology|'''Please see here the general frame of rules''']].
 
  ! colspan="7" align="center" style="background:#b3b3b3; color:white"|<font color="black">'''Working Sessions Operational Rules''' - [[:Working Sessions Methodology|'''Please see here the general frame of rules''']].
Line 9: Line 11:
 
  |-
 
  |-
 
  | style="width:15%; background:#7B8ABD" align="center"| '''Short Work Session Description'''  
 
  | style="width:15%; background:#7B8ABD" align="center"| '''Short Work Session Description'''  
−
  | colspan="6" style="width:85%; background:#cccccc" align="left"|TBD
+
  | colspan="6" style="width:85%; background:#cccccc" align="left"|The working session for OWASP Tools will address standards for Tool development at OWASP. This is will include standards for documentation, supporting tools via Books, How-Tos, Webcasts, Podcasts. We will also dive deep into the OWASP Project Assessment.
 
  |-
 
  |-
 
  | style="width:15%; background:#7B8ABD" align="center"| '''Related Projects (if any)'''  
 
  | style="width:15%; background:#7B8ABD" align="center"| '''Related Projects (if any)'''  
Line 16: Line 18:
 
  |-
 
  |-
 
  | style="width:25%; background:#7B8ABD" align="center"|'''Email Contacts & Roles'''
 
  | style="width:25%; background:#7B8ABD" align="center"|'''Email Contacts & Roles'''
−
  | style="width:25%; background:#cccccc" align="center"|'''Chair'''<br>[mailto:mark.roxberry(at)owasp.org '''Mark Roxberry''']  
+
  | style="width:25%; background:#cccccc" align="center"|'''Chair'''<br>[mailto:mtesauro(at)gmail.com '''Matt Tesauro''']
−
  | style="width:25%; background:#cccccc" align="center"|'''Secretary'''<br>[mailto:name(at)name '''TBD''']
+
  | style="width:25%; background:#cccccc" align="center"|'''Secretary'''<br>[mailto:jason.li(at)owasp.org '''Jason Li''']
 
  | style="width:25%; background:#cccccc" align="center"|'''Mailing list'''<br>[https://lists.owasp.org/mailman/listinfo/owasp-tools-projects '''Subscription Page''']
 
  | style="width:25%; background:#cccccc" align="center"|'''Mailing list'''<br>[https://lists.owasp.org/mailman/listinfo/owasp-tools-projects '''Subscription Page''']
 
  |}
 
  |}
Line 46: Line 48:
 
  ! colspan="7" align="center" style="background:white; color:white"|<font color="black">
 
  ! colspan="7" align="center" style="background:white; color:white"|<font color="black">
 
  |}
 
  |}
−
{| style="width:100%" border="0" align="center"
+
= Working Session Participants =
−
! colspan="7" align="center" style="background:#4058A0; color:white"|<font color="white">'''WORKING SESSION ADDITIONAL DETAILS'''
+
 
−
|-
 
−
| style="width:100%; background:#cccccc" align="left"|
 
−
Please add here, any additional notes, links, ideas, guidelines, etc... The objective is to help the working sessions participants and attendees to prepare their participation/contribution.
 
−
|}
 
−
{| style="width:100%" border="0" align="center"
 
−
! colspan="3" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION OUTCOMES'''
 
−
|-
 
−
| style="width:7%; background:#6C82B5" align="center"|Statements, Initiatives or Decisions
 
−
| style="width:46%; background:#b3b3b3" align="center"|'''Proposed by Working Group'''
 
−
| style="width:47%; background:#b3b3b3" align="center"|'''Approved by OWASP Board'''
 
−
|-
 
−
| style="width:7%; background:#7B8ABD" align="center"|
 
−
| style="width:46%; background:#C2C2C2" align="center"|Fill in here. 
 
−
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
 
−
|-
 
−
| style="width:7%; background:#7B8ABD" align="center"|
 
−
| style="width:46%; background:#C2C2C2" align="center"|Fill in here. 
 
−
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
 
−
  |}
 
−
== Working Session Participants ==
 
−
(Add you name by editing this table. On your the right, just above the this frame, you have the option to edit)
 
 
{| style="width:100%" border="0" align="center"
 
{| style="width:100%" border="0" align="center"
 
  ! colspan="7" align="center" style="background:#4058A0; color:white"|<font color="white">'''WORKING SESSION PARTICIPANTS'''  
 
  ! colspan="7" align="center" style="background:#4058A0; color:white"|<font color="white">'''WORKING SESSION PARTICIPANTS'''  
Line 83: Line 64:
 
  |-
 
  |-
 
  | style="width:7%; background:#7B8ABD" align="center"|2
 
  | style="width:7%; background:#7B8ABD" align="center"|2
−
  | style="width:15%; background:#cccccc" align="center"|
+
  | style="width:15%; background:#cccccc" align="center"|Rogan Dawes
−
  | style="width:15%; background:#cccccc" align="center"|
+
  | style="width:15%; background:#cccccc" align="center"|Corsaire
−
  | style="width:63%; background:#cccccc" align="center"|
+
  | style="width:63%; background:#cccccc" align="center"|WebScarab lead
 
  |-
 
  |-
 
  | style="width:7%; background:#7B8ABD" align="center"|3
 
  | style="width:7%; background:#7B8ABD" align="center"|3
−
  | style="width:15%; background:#cccccc" align="center"|
+
  | style="width:15%; background:#cccccc" align="center"|Andrew Petukhov
−
  | style="width:15%; background:#cccccc" align="center"|
+
  | style="width:15%; background:#cccccc" align="center"|Moscow State University
−
  | style="width:63%; background:#cccccc" align="center"|
+
  | style="width:63%; background:#cccccc" align="center"|Access Control Rules Tester lead
−
|-
+
|-
 
  | style="width:7%; background:#7B8ABD" align="center"|4
 
  | style="width:7%; background:#7B8ABD" align="center"|4
−
  | style="width:15%; background:#cccccc" align="center"|
+
  | style="width:15%; background:#cccccc" align="center"|Christian Martorella
−
  | style="width:15%; background:#cccccc" align="center"|
+
  | style="width:15%; background:#cccccc" align="center"|Edge-Security
−
  | style="width:63%; background:#cccccc" align="center"|
+
  | style="width:63%; background:#cccccc" align="center"|WebSlayer lead
 
|-
 
|-
 
  | style="width:7%; background:#7B8ABD" align="center"|5
 
  | style="width:7%; background:#7B8ABD" align="center"|5
−
  | style="width:15%; background:#cccccc" align="center"|
+
  | style="width:15%; background:#cccccc" align="center"|Arturo 'Buanzo' Busleiman
−
  | style="width:15%; background:#cccccc" align="center"|
+
  | style="width:15%; background:#cccccc" align="center"|Independent
−
  | style="width:63%; background:#cccccc" align="center"|
+
  | style="width:63%; background:#cccccc" align="center"|Enigform & mod_openpgp SOC07/08
 
|-
 
|-
 
  | style="width:7%; background:#7B8ABD" align="center"|6
 
  | style="width:7%; background:#7B8ABD" align="center"|6
−
  | style="width:15%; background:#cccccc" align="center"|
+
  | style="width:15%; background:#cccccc" align="center"|Pavol Luptak
−
  | style="width:15%; background:#cccccc" align="center"|  
+
  | style="width:15%; background:#cccccc" align="center"|Nethemba s.r.o.
−
  | style="width:63%; background:#cccccc" align="center"|
+
  | style="width:63%; background:#cccccc" align="center"|Slovkia OWASP Chapter leader
 
|-
 
|-
 
  | style="width:7%; background:#7B8ABD" align="center"|7
 
  | style="width:7%; background:#7B8ABD" align="center"|7
−
  | style="width:15%; background:#cccccc" align="center"|
+
  | style="width:15%; background:#cccccc" align="center"|Nishi Kumar
−
  | style="width:15%; background:#cccccc" align="center"|
+
  | style="width:15%; background:#cccccc" align="center"|Fidelity Nationals
−
  | style="width:63%; background:#cccccc" align="center"|
+
  | style="width:63%; background:#cccccc" align="center"|Contributed on Live CD 2008
−
|-
 
−
| style="width:7%; background:#7B8ABD" align="center"|8
 
−
| style="width:15%; background:#cccccc" align="center"|
 
−
| style="width:15%; background:#cccccc" align="center"|
 
−
| style="width:63%; background:#cccccc" align="center"|
 
−
|-
 
−
| style="width:7%; background:#7B8ABD" align="center"|9
 
−
| style="width:15%; background:#cccccc" align="center"|
 
−
| style="width:15%; background:#cccccc" align="center"|
 
−
| style="width:63%; background:#cccccc" align="center"|
 
−
|-
 
−
| style="width:7%; background:#7B8ABD" align="center"|10
 
−
| style="width:15%; background:#cccccc" align="center"|
 
−
| style="width:15%; background:#cccccc" align="center"|
 
−
| style="width:63%; background:#cccccc" align="center"|
 
 
  |}
 
  |}
−
If needed add here more lines.
+
 
 +
=Working Session Outcomes=
 +
 
 +
==Standardized Output for OWASP Tools==
 +
====Explanation====
 +
For tools that generate output, it should be in a well-defined manner (XML-preferred) so that it can be easily used as input into another project, program, process, etc or quickly convertible into an easily readable format. Whenever possible, a project should re-use an existing standard (ex. ADVL, OVAL) for this purpose.
 +
 
 +
====Rationale====
 +
The idea is to allow easier integration to encourage tool chaining, customized report generation,  adaptability into other environments, etc.
 +
 
 +
====Voting Outcome====
 +
* For: 25 votes
 +
* Against: 0 votes
 +
 
 +
 
 +
==Official OWASP Code Repository==
 +
 
 +
====Explanation====
 +
Provide or arrange for one standard, managed, OWASP-controlled place for all tool projects to maintain their source code. This could be an OWASP branded arrangement with Google Code, Sourceforge, etc, or an OWASP-maintained SVN server.
 +
 
 +
====Rationale====
 +
Provides a central, standardized place for code repository that allows a standardized way to track metrics such as activity, usage, downloads, etc. It also provides a single point for all projects that can be linked in with the OWASP website for ease of use and documentation for new OWASP project developers.
 +
 
 +
====Voting Outcome====
 +
* For: 26 votes
 +
* Against: 0 votes
 +
 
 +
==Create Metrics for OWASP Project Evaluation==
 +
 
 +
====Explanation====
 +
Beyond current OWASP Project quality metrics, create other metrics to evaluate projects by things such as activity, usability, relevance to current standards/technologies, how well the project addresses the problem it is trying to solve, etc. This could even include a user review system (a la Star ratings).
 +
 
 +
====Rationale====
 +
Existing projects are in a state of disarray that do not readily lend themselves to OWASP Alpha/Beta/Release quality standards. Also, quality alone is not a sufficient measure of an OWASP Project.
 +
 
 +
====Voting Outcome====
 +
* For: 25 votes
 +
* Against: 0 votes
 +
[https://www.owasp.org/index.php/Image:Tools-working-session-vote1.jpg (See scanned votes)]
 +
 
 +
==Make Available an OWASP Technical Writer==
 +
 
 +
====Explanation====
 +
OWASP should make experienced technical writer(s) available to projects to review, critique and suggest changes on existing or newly created project documentation. This could be a single full-time person or a pool of part-time, on-demand technical writers.
 +
 
 +
====Rationale====
 +
To appeal to more users and corporations, projects need well written documentation. Additionally, this will help with project adoption.
 +
 
 +
====Voting Outcome====
 +
 
 +
==Standardize User Interface for OWASP Graphical Tools==
 +
 
 +
====Explanation====
 +
Create a standard UI design "kit" for tools that have a GUI that includes:
 +
* OWASP logos and icons for use in applications
 +
* Standardized OWASP color scheme specifications
 +
* Human useability guidelines such as scalar sizing, standard shortcuts, and other UI Best Practices
 +
 
 +
====Rationale====
 +
Bad user interface design can limit adoption of a tool and inconsistent UI design can hurt the OWASP brand. Consistent, well-designed UIs make tools easy to use and encourage adoption.
 +
 
 +
====Voting Outcome====
 +
* For: 21 Votes
 +
* Against: 0 Votes
 +
[https://www.owasp.org/index.php/Image:Tools-working-session-vote1.jpg (See scanned votes)]
 +
 
 +
==Make Available an OWASP UI/Graphic Designer==
 +
 
 +
====Explanation====
 +
OWASP should make experienced UI/graphic designer(s) available to projects to review, critique and suggest changes on existing or newly created project GUIs. This could be a single full-time person or a pool of part-time, on-demand UI/graphic designer.
 +
 
 +
====Rationale====
 +
Most developers are not good graphic designers and make user interface design decisions based on limited experiences. Minor UI annoyances can inhibit tool adoption.
 +
 
 +
====Voting Outcome====
 +
 
 +
==AJAX-Enabled Web Spider/Crawler Tool==
 +
 
 +
====Explanation====
 +
A tool to crawl over AJAX pages in a JS-aware manner.
 +
 
 +
====Rationale====
 +
More and more sites are moving to an AJAX-enabled design and existing open-source tools do not handle these types of sites well.
 +
 
 +
====Voting Outcome====
 +
 
 +
==Re-categorize OWASP Projects==
 +
 
 +
====Explanation====
 +
As part of the project proposal phase, tools should identify the type of tool, the intended audience of the tool, and phases in the SDLC where the tool might be useful. In addition, existing tools should undergo this classification process.
 +
 
 +
====Rationale====
 +
The "Tools" heading encompasses a broad range of projects including API Frameworks, testing tools, reporting tools, etc. This is extremely hard to navigate for a new OWASP user. Classifying tools across multiple headings would also allow the OWASP site to highlight projects or to create a "How Can OWASP Help You?" page that direct users to projects that are most relevant to them.
 +
 
 +
===Voting Outcome==

Latest revision as of 18:35, 12 December 2008

About the Working Session

Working Sessions Operational Rules - Please see here the general frame of rules.
WORKING SESSION IDENTIFICATION
Work Session Name OWASP Tools Projects
Short Work Session Description The working session for OWASP Tools will address standards for Tool development at OWASP. This is will include standards for documentation, supporting tools via Books, How-Tos, Webcasts, Podcasts. We will also dive deep into the OWASP Project Assessment.
Related Projects (if any)

OWASP Tools Projects

Email Contacts & Roles Chair
Matt Tesauro 		Secretary
Jason Li 		Mailing list
Subscription Page
WORKING SESSION SPECIFICS
Objectives
  • Discuss documentation procedures.
  • Book creation procedure.
  • Review OWASP Project Assessment.
Venue/Date&Time/Model Venue
OWASP EU Summit Portugal 2008 		Date&Time
November 4 & 7, 2008
Time TBD 		Discussion Model
"Participants + Attendees"
WORKING SESSION OPERATIONAL RESOURCES
Please add here, ASAP, any needed relevant resources, e.g. data-show, boards, laptops, etc.

Working Session Participants

WORKING SESSION PARTICIPANTS
Name Company Notes & reason for participating, issues to be discussed/addressed
1 Paulo Coimbra OWASP Has contributed to the current OWASP Assessment Criteria.
2 Rogan Dawes Corsaire WebScarab lead
3 Andrew Petukhov Moscow State University Access Control Rules Tester lead
4 Christian Martorella Edge-Security WebSlayer lead
5 Arturo 'Buanzo' Busleiman Independent Enigform & mod_openpgp SOC07/08
6 Pavol Luptak Nethemba s.r.o. Slovkia OWASP Chapter leader
7 Nishi Kumar Fidelity Nationals Contributed on Live CD 2008

Working Session Outcomes

Standardized Output for OWASP Tools

Explanation

For tools that generate output, it should be in a well-defined manner (XML-preferred) so that it can be easily used as input into another project, program, process, etc or quickly convertible into an easily readable format. Whenever possible, a project should re-use an existing standard (ex. ADVL, OVAL) for this purpose.

Rationale

The idea is to allow easier integration to encourage tool chaining, customized report generation, adaptability into other environments, etc.

Voting Outcome

  • For: 25 votes
  • Against: 0 votes


Official OWASP Code Repository

Explanation

Provide or arrange for one standard, managed, OWASP-controlled place for all tool projects to maintain their source code. This could be an OWASP branded arrangement with Google Code, Sourceforge, etc, or an OWASP-maintained SVN server.

Rationale

Provides a central, standardized place for code repository that allows a standardized way to track metrics such as activity, usage, downloads, etc. It also provides a single point for all projects that can be linked in with the OWASP website for ease of use and documentation for new OWASP project developers.

Voting Outcome

  • For: 26 votes
  • Against: 0 votes

Create Metrics for OWASP Project Evaluation

Explanation

Beyond current OWASP Project quality metrics, create other metrics to evaluate projects by things such as activity, usability, relevance to current standards/technologies, how well the project addresses the problem it is trying to solve, etc. This could even include a user review system (a la Star ratings).

Rationale

Existing projects are in a state of disarray that do not readily lend themselves to OWASP Alpha/Beta/Release quality standards. Also, quality alone is not a sufficient measure of an OWASP Project.

Voting Outcome

  • For: 25 votes
  • Against: 0 votes

(See scanned votes)

Make Available an OWASP Technical Writer

Explanation

OWASP should make experienced technical writer(s) available to projects to review, critique and suggest changes on existing or newly created project documentation. This could be a single full-time person or a pool of part-time, on-demand technical writers.

Rationale

To appeal to more users and corporations, projects need well written documentation. Additionally, this will help with project adoption.

Voting Outcome

Standardize User Interface for OWASP Graphical Tools

Explanation

Create a standard UI design "kit" for tools that have a GUI that includes:

  • OWASP logos and icons for use in applications
  • Standardized OWASP color scheme specifications
  • Human useability guidelines such as scalar sizing, standard shortcuts, and other UI Best Practices

Rationale

Bad user interface design can limit adoption of a tool and inconsistent UI design can hurt the OWASP brand. Consistent, well-designed UIs make tools easy to use and encourage adoption.

Voting Outcome

  • For: 21 Votes
  • Against: 0 Votes

(See scanned votes)

Make Available an OWASP UI/Graphic Designer

Explanation

OWASP should make experienced UI/graphic designer(s) available to projects to review, critique and suggest changes on existing or newly created project GUIs. This could be a single full-time person or a pool of part-time, on-demand UI/graphic designer.

Rationale

Most developers are not good graphic designers and make user interface design decisions based on limited experiences. Minor UI annoyances can inhibit tool adoption.

Voting Outcome

AJAX-Enabled Web Spider/Crawler Tool

Explanation

A tool to crawl over AJAX pages in a JS-aware manner.

Rationale

More and more sites are moving to an AJAX-enabled design and existing open-source tools do not handle these types of sites well.

Voting Outcome

Re-categorize OWASP Projects

Explanation

As part of the project proposal phase, tools should identify the type of tool, the intended audience of the tool, and phases in the SDLC where the tool might be useful. In addition, existing tools should undergo this classification process.

Rationale

The "Tools" heading encompasses a broad range of projects including API Frameworks, testing tools, reporting tools, etc. This is extremely hard to navigate for a new OWASP user. Classifying tools across multiple headings would also allow the OWASP site to highlight projects or to create a "How Can OWASP Help You?" page that direct users to projects that are most relevant to them.

===Voting Outcome==

Retrieved from "https://wiki.owasp.org/index.php?title=OWASP_Working_Session_-_OWASP_Tools_Projects&oldid=48505"