Difference between revisions of "ORPRO-process"

From OWASP
Jump to: navigation, search
Line 2: Line 2:
  
 
* '''Project intake'''
 
* '''Project intake'''
** ''PI.01: Communication with open source project.'' Proposals for open source projects to be reviewed can be sent to one of the ORPRO project leads. Alternatively, the project actively approache open source projects. The open soure project must provide at least one primary contact.
+
** ''PI.01: Communication with open source project.'' Proposals for open source projects to be reviewed can be sent to one of the ORPRO project leads. Alternatively, the project actively approach open source projects. The open source project must provide at least one primary contact.
 
** ''PI.02: Check entry criteria.'' The open source project will be checked against entry criteria. Entry criteria are:
 
** ''PI.02: Check entry criteria.'' The open source project will be checked against entry criteria. Entry criteria are:
 
*** it must be widely used  
 
*** it must be widely used  
Line 8: Line 8:
 
*** the open source project team should be in a position to remediate security defects that are discovered
 
*** the open source project team should be in a position to remediate security defects that are discovered
 
*** the programming language must be supported by ORPRO's automated source code scanners and manual review team
 
*** the programming language must be supported by ORPRO's automated source code scanners and manual review team
** ''PI.03: Risk assessment.''  
+
** ''PI.03: Risk assessment.'' Before conducting manual reviews we perform a risk assessment on the open source software. The minimum results must be:
** ''PI.04: Assemble team.'' The project lead assigns a review project lead and the lead can additionally select a team of reviewers.
+
*** main threats for the particular software
 +
*** prioritized list of source code to be reviewed, highest risk first.
 +
** ''PI.04: Assemble team.'' The project leads assigns a review project lead and the lead can additionally assemble a team of reviewers. Reviewers may be involved with automated scanning, manual review, or both.  
 
* '''Review'''
 
* '''Review'''
 
** '''Automated review'''
 
** '''Automated review'''
*** Assuming the project uses a platform supported by [http://owasp.fortify.com/ owasp.fortify.com], the source code is run through automated analysis. Defects discovered are manually reviewed and then communicated to the owners of the open source project for remediation. For more information on this process, see the [http://www.owasp.org/index.php/Category:OWASP_Open_Review_Project_owasp.fortify.com_FAQ OWASP Open Review owasp.fortify.com FAQ]
+
*** ''AR.01: Configure tooling.'' Assuming the project uses a platform supported by [http://owasp.fortify.com/ owasp.fortify.com], the source code is run through automated analysis.
*** ''AR.01: Configure tooling.''
+
*** ''AR.02: Run tool on project.'' For more information on this process, see the [http://www.owasp.org/index.php/Category:OWASP_Open_Review_Project_owasp.fortify.com_FAQ OWASP Open Review owasp.fortify.com FAQ]
*** ''AR.02: Run tool on project.''
+
*** ''AR.03: Review findings.'' Defects discovered are manually reviewed.
*** ''AR.03: Review findings.''
+
*** ''AR.04: Document results.'' Defects are communicated to the owners of the open source project for remediation.
*** ''AR.04: Document results.''
+
 
** '''Manual Review'''
 
** '''Manual Review'''
*** ''MR.01: Configure tooling.''
+
*** ''MR.01: Configure tooling.'' For collaborating on manual reviews ORPRO will be setting up tooling. The tooling needs to be configured for the software under review.
*** ''MR.02: Perform manual review.''
+
*** ''MR.02: Perform manual review.'' The manual review is being performed under supervision of the review project lead. The review project lead assigns source code to individual reviewers. The results from PI.03 (Risk assessment) have specified the prioritization of the reviews to be performed.
*** ''MR.03: Document results.''
+
*** ''MR.03: Document results.'' Identified defects are documented and reported to the owners of the open source project for remediation.
*** Reviewers manually review the application design and source code and communicate identified issues to the owners of the open source project for remediation.
+
 
* '''Reporting'''
 
* '''Reporting'''
** ''RE.01: Report issues to project.'' Either reviewers or the open source project leaders responsibly disclose the identified security issues
+
** ''RE.01: Report issues to project.'' Either reviewers or the open source project leaders responsibly disclose the identified security issues.
** ''RE.02: Final report at OWASP site.''
+
** ''RE.02: Final report at OWASP site.'' After finishing a review and having responsibly disclosed security defects ORPRO will document the results on the OWASP site for educational purposes. Apart from the defects being documented details should be made available on the coverage of automated and manual review and the specific defects found by either method.
 +
 
  
 
The ORPRO project is a relatively new effort and it is expected that these processes will develop and change over time to accommodate new situations as they arise.
 
The ORPRO project is a relatively new effort and it is expected that these processes will develop and change over time to accommodate new situations as they arise.

Revision as of 05:57, 31 October 2008

ORPRO process detail 1.jpg

  • Project intake
    • PI.01: Communication with open source project. Proposals for open source projects to be reviewed can be sent to one of the ORPRO project leads. Alternatively, the project actively approach open source projects. The open source project must provide at least one primary contact.
    • PI.02: Check entry criteria. The open source project will be checked against entry criteria. Entry criteria are:
      • it must be widely used
      • its license must allow independent security review
      • the open source project team should be in a position to remediate security defects that are discovered
      • the programming language must be supported by ORPRO's automated source code scanners and manual review team
    • PI.03: Risk assessment. Before conducting manual reviews we perform a risk assessment on the open source software. The minimum results must be:
      • main threats for the particular software
      • prioritized list of source code to be reviewed, highest risk first.
    • PI.04: Assemble team. The project leads assigns a review project lead and the lead can additionally assemble a team of reviewers. Reviewers may be involved with automated scanning, manual review, or both.
  • Review
    • Automated review
      • AR.01: Configure tooling. Assuming the project uses a platform supported by owasp.fortify.com, the source code is run through automated analysis.
      • AR.02: Run tool on project. For more information on this process, see the OWASP Open Review owasp.fortify.com FAQ
      • AR.03: Review findings. Defects discovered are manually reviewed.
      • AR.04: Document results. Defects are communicated to the owners of the open source project for remediation.
    • Manual Review
      • MR.01: Configure tooling. For collaborating on manual reviews ORPRO will be setting up tooling. The tooling needs to be configured for the software under review.
      • MR.02: Perform manual review. The manual review is being performed under supervision of the review project lead. The review project lead assigns source code to individual reviewers. The results from PI.03 (Risk assessment) have specified the prioritization of the reviews to be performed.
      • MR.03: Document results. Identified defects are documented and reported to the owners of the open source project for remediation.
  • Reporting
    • RE.01: Report issues to project. Either reviewers or the open source project leaders responsibly disclose the identified security issues.
    • RE.02: Final report at OWASP site. After finishing a review and having responsibly disclosed security defects ORPRO will document the results on the OWASP site for educational purposes. Apart from the defects being documented details should be made available on the coverage of automated and manual review and the specific defects found by either method.


The ORPRO project is a relatively new effort and it is expected that these processes will develop and change over time to accommodate new situations as they arise.