Difference between revisions of "Category:OWASP Project Assessment"

• Be reasonably easy to use
• Include online documention built into tool (based on required user documentation)
• Include build scripts that facilitate building the application from source (Goal: One-click build)
• Publicly accessible bug tracking system established, ideally at the same place as the source code repository (e.g., at Google code, or Sourceforge)
• Java projects should be run through Fortify Software's open source review (if appropriate) and FindBugs.
  • WebGoat would not be appropriate for example since it would light up like a Christmas tree :-)
• C/C++ apps (if we have any) should consider being run through Coverity's open source review. Coverity also accepts submissions for open source Java applications.
• When approved to be Release Quality: Update the link to it on: the OWASP Project page and update its project quality tag on its project page to be Release Quality.

Recommendations:

• Conference style Powerpoint presentation that describes the use and status of the tool. (This could be used by others to discuss the tool at OWASP Chapter meetings, serve as easy to review offline documentation, etc.)
• UAT pass on functionality of the tool
• Developer documents any limitations

• Requirement: 2 Reviewers + 1 OWASP Board Member.
  • If possible, the project's lead should suggest two Project Reviewers. One of them should be an OWASP Project Leader.
  • If the project's lead can't find the Project Reviewers, the OWASP Board will identify them. The same will happen whenever the reviewers suggested do not have the required approval.

• Have an easy to use installer (Goal: Fully automated installer) (or stand alone executable version)
• Include user documentation in Project's OWASP Wiki page(s)
• Add a common About Box or help menu in the tool itself
  • (which lists name of tool, author, e-mail address of author, current version number and/or release date)
• Include documentation on how to build it from code, starting with getting it directly from the code repository. (Ideally, this would include easy to use build scripts, which is required for Release Quality)
• This documentation must stored be in the same repository as the code.
• When approved to be Beta Quality: Update the link to it on: the OWASP Project page and update its project quality tag on its project page to be Beta.

• Requirement: 2 Reviewers.
  • If possible, the project's lead should suggest two Project Reviewers. One of them should be an OWASP Project Leader.
  • If the project's lead can't find the Project Reviewers, the OWASP Board will identify them. The same will happen whenever the reviewers suggested do not have the required approval.

• Agree to OWASP's open source license
• The “main” page for any OWASP tool must be on the OWASP website. This page must:
  • describe the tool, the project leader, contact info, and include all relevant links, including a download link for the code and the executable version,
  • include the Alpha Quality Tool project tag. (Which we still need to define),
  • be placed at OWASP Project page.
• Have its code and any documentation in Googlecode, or Sourceforge.
• Mailing list for project created.
• Solves a core application security need.

• Requirement: 1 Reviewer.
  • If possible, the project's lead should suggest a Project Reviewer who is an existing OWASP Leader.
  • If the project's lead can't find a Project Reviewer, the OWASP Board will identify one. The same will happen whenever the reviewer suggested does not have the required approval.

All Beta Quality Requirements plus:

• Document has been reviewed and updated to be consistent and not overly repetitive with all other Release Quality OWASP Documentation.
• Conference style Powerpoint presentation that describes the use and status of the project. (This could be used by others to discuss the project at OWASP Chapter meetings, serve as easy to review offline documentation, etc.)
• Wiki content, if more than 30 pages, has been converted to an OWASP Book and is available for download or purchase at the OWASP Lulu bookstore.
• When approved to be Release Quality: Update the link to it on: the OWASP Project page and update its project quality tag on its project page to be Release Quality.

• Requirement: 2 Reviewers + 1 OWASP Board Member.
  • If possible, the project's lead should suggest two Project Reviewers. One of them should be an OWASP Project Leader.
  • If the project's lead can't find the Project Reviewers, the OWASP Board will identify them. The same will happen whenever the reviewers suggested do not have the required approval.

All Alpha Quality Requirements plus:

• The document seems sufficiently or substantially complete with respect to the topic or process it is intended to cover.
• All wiki content has been reviewed by a technical editor to ensure that English grammar is correct, understandable, and the content flows well.
• Clear efforts to interlink this document to other appropriate Beta and Release Quality OWASP Documentation and Tools projects have been made.

• When approved to be Beta Quality: Update the link to it on: the OWASP Project page and update its project quality tag on its project page to be Beta.

• Requirement: 2 Reviewers.
  • If possible, the project's lead should suggest two Project Reviewers. One of them should be an OWASP Project Leader.
  • If the project's lead can't find the Project Reviewers, the OWASP Board will identify them. The same will happen whenever the reviewers suggested do not have the required approval.

• Agree to OWASP's open source license
• The “main” page for any OWASP documentation project must be on the OWASP website. This page must:
  • describe the purpose and scope of project, the project leader, contact info, and include all relevant links,
  • includes a list of contributors, if a team effort.
  • include the Alpha Quality Tool project tag. (Which we still need to define),
  • be placed at OWASP Project page.
• Have all its content stored in the OWASP wiki.
• Mailing list for project created.
• Solves a core application security documentation/process need.

• Requirement: 1 Reviewer.
  • If possible, the project's lead should suggest a Project Reviewer who is an existing OWASP Leader.
  • If the project's lead can't find a Project Reviewer, the OWASP Board will identify one. The same will happen whenever the reviewer suggested does not have the required approval.