ORPRO-process - Revision history

Njama at 15:54, 8 February 2009

2009-02-08T15:54:11Z

Njama: Changes in RA

2009-02-08T14:38:08Z

Changes in RA

Njama at 10:57, 31 October 2008

2008-10-31T10:57:49Z

Njama at 10:38, 31 October 2008

2008-10-31T10:38:09Z

Njama: Documented activities

2008-10-31T10:30:31Z

Documented activities

Njama at 10:04, 31 October 2008

2008-10-31T10:04:37Z

Njama at 08:51, 31 October 2008

2008-10-31T08:51:04Z

Njama: New page: * Proposal ** Proposals for open source projets to be reviewed can be sent to the ORPRO project lead. The open source project will be checked against some entry criteria - for example the...

2008-10-31T08:43:40Z

New page: * Proposal ** Proposals for open source projets to be reviewed can be sent to the ORPRO project lead. The open source project will be checked against some entry criteria - for example the...

New page

* Proposal
** Proposals for open source projets to be reviewed can be sent to the ORPRO project lead. The open source project will be checked against some entry criteria - for example the open source project team should be in a position to remediate security defects that are discovered.
* Team Development
** The project lead assigns a review project lead and the lead can additionally select a team of reviewers.
* 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]
** Reviewers manually review the application design and source code and communicate identified issues to the owners of the open source project for remediation.
** Either reviewers or the open source project leaders responsibly disclose the identified security issues

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.

@@ Line 1: / Line 1: @@
-[[Image:ORPRO_process_detail_1.jpg]]
+[[Image:ORPRO_process_detail_2.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.
+** ''PIN.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:
+** ''PIN.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 steps taken are:
+** ''PIN.03: Risk assessment.'' Before conducting manual reviews we perform a risk assessment on the open source software. The steps taken are:
 *** based on typical business use, conduct a business impact assessment (BIA): determine the maximum business impact of loss of confidentiality, loss of integrity and unavailability of the software under review;
 *** using the results of the BIA, conduct a threat assessment. The results are
@@ Line 14: / Line 14: @@
 **** main threats for the software under review;
 **** prioritized list of source code to be reviewed, highest risk first. In its simplest forms, the list might be based on source code files or directories. In many cases, other ways to address this may be more appropriate: examples are high risk use cases, API calls, and interfaces;
-** ''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.
+** ''PIN.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 architecture review, automated scanning, and/or manual review.
 * '''Review'''
-** '''Automated review'''
+** '''Automated code review'''
-*** ''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.
+*** ''ACR.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.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]
+*** ''ACR.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.03: Review findings.'' Defects discovered are manually reviewed.
+*** ''ACR.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.
+*** ''ACR.04: Document results.'' Defects are communicated to the owners of the open source project for remediation.
-** '''Manual Review'''
+** '''Manual code 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.
+*** ''MCR.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.
+*** ''MCR.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.
+*** ''MCR.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.
+** ''REP.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.
+** ''REP.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.

@@ Line 8: / Line 8: @@
 *** 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:
+** ''PI.03: Risk assessment.'' Before conducting manual reviews we perform a risk assessment on the open source software. The steps taken are:
-*** main threats for the particular software
+*** based on typical business use, conduct a business impact assessment (BIA): determine the maximum business impact of loss of confidentiality, loss of integrity and unavailability of the software under review;
-*** prioritized list of source code to be reviewed, highest risk first.
+*** using the results of the BIA, conduct a threat assessment. The results are
 ** ''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'''

@@ Line 2: / Line 2: @@
 * '''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:
 *** 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 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
 * '''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.
 ** '''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.
 * '''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.

@@ Line 2: / Line 2: @@
 * '''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.
+** ''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.02: Check entry criteria.'' The open source project will be checked against some entry criteria - for example the open source project team should be in a position to remediate security defects that are discovered.
+** ''PI.02: Check entry criteria.'' The open source project will be checked against entry criteria. Entry criteria are:
-** ''PI.03: Risk assessment.''
+*** it must be widely used
 ** ''PI.04: Assemble team.'' The project lead assigns a review project lead and the lead can additionally select a team of reviewers.
 * '''Review'''

@@ Line 1: / Line 1: @@
 [[Image:ORPRO_process_detail_1.jpg]]
-* Project intake
+* '''Project intake'''
-** Proposals for open source projets to be reviewed can be sent to the ORPRO project lead.  The open source project will be checked against some entry criteria - for example the open source project team should be in a position to remediate security defects that are discovered.
+** ''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.
-* Team Development
+** ''PI.02: Check entry criteria.'' The open source project will be checked against some entry criteria - for example the open source project team should be in a position to remediate security defects that are discovered.
-** The project lead assigns a review project lead and the lead can additionally select a team of reviewers.
+** ''PI.03: Risk assessment.''
-* Review
+** ''PI.04: Assemble team.'' The project lead assigns a review project lead and the lead can additionally select a team of reviewers.
-** 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]
+* '''Review'''
-** Reviewers manually review the application design and source code and communicate identified issues to the owners of the open source project for remediation.
+** '''Automated review'''
-** Either reviewers or the open source project leaders responsibly disclose the identified security issues
+*** 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.''
 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.

← Older revision		Revision as of 10:04, 31 October 2008
Line 1:		Line 1:
		+	[[Image:ORPRO_process_detail_1.jpg]]
		+
	* Project intake		* Project intake
	** Proposals for open source projets to be reviewed can be sent to the ORPRO project lead. The open source project will be checked against some entry criteria - for example the open source project team should be in a position to remediate security defects that are discovered.		** Proposals for open source projets to be reviewed can be sent to the ORPRO project lead. The open source project will be checked against some entry criteria - for example the open source project team should be in a position to remediate security defects that are discovered.