Category:OWASP Open Review Project OWASPFortify FAQ

Frequently Asked Questions

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.

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.

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 your OWASP co-ordinator to have your project listed.

How long does the review process take to get open source code scanned?
Barring technical difficulties, the initial code will get scanned within hours of submission, depending on the number of projects queued.

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 the code from your source repository on a weekly basis and re-run the analysis.

Do we need to notify you when we release a new version?
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 ask your OWASP co-ordinator to make the necessary changes.

What can I do to help the Open Review efforts?
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! 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! 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 Java 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.
 * 1) Help Audit Projects
 * 1) Submit Bug Fixes
 * 1) Submit Projects

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.

The Fortify Open Review project 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.

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 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".