Category:OWASP Open Review Project FAQ

Jump to: navigation, search

Frequently Asked Questions

Project Purpose

Why should open source software be reviewed?

There are numerous reasons to examine open source software for security defects. As consumers of open source software, helping these same projects to improve the quality of their code benefits us as end-users. Also, many developers learn by example and use open source software for their education. We've found that developers often repeat the security defects found in open source projects in their own projects. Encouraging open source projects to practice better security has a trickled down effect on the developer community as a whole.

Submitting a Project

What kinds of projects are accepted?

We will accept any compilable open source project for review. Essentially, if the project meets the Open Source Initiative definition, it's kosher. Currently, we support Java and PHP projects, though support for more languages is in the works. If you have an open source project written in ASP Classic, .NET, C/C++ or ColdFusion email the Open Review Project mailing list to see about getting a scan run on the project source code and getting that scan uploaded to the site.

Are there any submission criteria?

Although we accept all valid open source projects, supplying the following information along with the submission will help make the review successful:

  • Include CVS or SVN location
  • Name of primary module in project
  • Name of dependent modules in SCM system
  • Label/tag information for current release version
  • Compilation instructions if project doesn't compile as the default Ant or Maven action
  • Project homepage
  • Project owner email address

Please contact the OWASP Open Review mailing list to have your project listed.

After Submission

How long does the review process take to get open source code scanned?

For Java and PHP projects, barring technical difficulties, the initial code will get scanned within hours of submission, depending on the number of projects queued. The time frame for getting projects developed in other languages may take longer as they must be manually scanned and uploaded.

Do we receive a detailed list of problems so we can solve them?

Yes, you will receive login information so you can view the defects within the FOR interface.

Will you review the code again when we've resolved the problems?

Yes. We will automatically download code for Java and PHP projects from your source repository on a weekly basis and re-run the analysis. Projects developed in other languages will need to be manually re-scanned so there may be a delay.

Do we need to notify you when we release a new version?

For Java and PHP projects, as long as your SCM information does not change, we should pick up the newest release version as part of the weekly analysis. If the SCM or build information does change, please email the OWASP Open Review mailing list to make the necessary changes.


What can I do to help the Open Review efforts?

  1. Help Audit Projects
    Do you have Java or PHP programming experience? Have you studied and understood the defects we find? Volunteer to help review the analysis results discovered during the automated phase of the open review process!
  2. Submit Bug Fixes
    Finding and alerting open source projects about security concerns is all well and good, but fixing issues for the projects goes one step further! Take a look at the reviewed and confirmed defects, fix the issue, and then submit a patch to the affected project!
  3. Submit Projects
    Know of an excellent project that's not on the list? Are you involved in a project that you'd like to have analyzed? Submit it to us! Try as we may, the OWASP Open Review team can't be aware of all the open source projects out there. Help by keeping us aware of what's out there.


How does this project handle disclosure responsibly?

Disclosing security issues in a manner that is both useful to software developer and software user can be a difficult task. Ultimately, it is about how to get the defect resolved with the smallest impact to the user. In the case of this project, all of the source code is publicly available. In theory, malicious individuals currently can examine the code themselves to attempt to find defects. Such a use can not be prevented, however; it would be irresponsible for this project to make an attacker's job easier. has adopted a fairly basic "responsible disclosure" policy. For the open review, we accomplish responsible disclosure by:

  • Only publishing aggregate defect information to anonymous users.
  • Letting project owners have input on who can review their code.
  • Alerting project owners of critical security defects that have been uncovered.
  • Helping project owners fix critical security defects when possible.

Project Statistics

What happened to my previous defect count?

The analysis engine has been improved so issues that were previously reported as multiple defects have been condensed into on defect.

How do you calculate the number of lines of code?

Fortify SCA only counts lines of code containing actual operations. This translates into a more accurate count of actual statements within the code base.

How do you determine if a defect is "fixed"?

During scans we compare defects found in the last previous scan, with all the issues uncovered in the current scan. If an issue found in the last scan is no longer present, we consider the defect to be "fixed".

System Availability

What are the scheduled downtime periods?

System downtime has been planned for the hours between 9PM-12AM PT every Sunday. Other than that we will try to keep the system available.

This category currently contains no pages or media.