OWASP Good Component Practices Project - Revision history

Kait Disney-Leugers at 18:15, 25 April 2014

2014-04-25T18:15:29Z

James Nadeau: Fixing type, changed that to thought

2013-05-22T16:56:16Z

Fixing type, changed that to thought

Mark Miller at 15:53, 13 May 2013

2013-05-13T15:53:45Z

Mark Miller at 15:09, 1 May 2013

2013-05-01T15:09:44Z

Mark Miller at 15:07, 1 May 2013

2013-05-01T15:07:56Z

Mark Miller at 14:59, 26 April 2013

2013-04-26T14:59:25Z

Mark Miller at 19:44, 25 April 2013

2013-04-25T19:44:20Z

Mark Miller at 19:28, 25 April 2013

2013-04-25T19:28:14Z

Mark Miller at 19:26, 25 April 2013

2013-04-25T19:26:16Z

Mark Miller at 18:41, 25 April 2013

2013-04-25T18:41:31Z

← Older revision		Revision as of 18:15, 25 April 2014
Line 1:		Line 1:
		+	{\|
		+	\|-
		+	! width="700" align="center" \| <br>
		+	! width="500" align="center" \| <br>
		+	\|-
		+	\| align="right" \| [[Image:OWASP Inactive Banner.jpg\|800px\| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Inactive_Projects]]
		+	\| align="right" \|
		+
		+	\|}
	=GCP Project Overview=		=GCP Project Overview=

@@ Line 30: / Line 30: @@
 The same is true for components. What kind of assurance can be made that the component has not been altered once it enters into the development environment.
 =='''Deployment''': Component maintenance within the production environment==
-When the component moves into production, how do I ensure that what is actually running is the same thing that the developer that it was. How do I ensure that all along the path from selection through deployment, that the component is actually what I think it is. How do I verify that nothing has changed.
+When the component moves into production, how do I ensure that what is actually running is the same thing that the developer thought it was. How do I ensure that all along the path from selection through deployment, that the component is actually what I think it is. How do I verify that nothing has changed.
 The gateways where risk can get introduced are the main points for automated monitoring and enforcement of policies and procedures. If I do all that great work up front,   (this is validate, confirm integration with my current environment, etc,) then I need to ensure that that the component that was approved doesn't get invalidated by misconfiguration or manual change of version numbers to work around company policies.

@@ Line 1: / Line 1: @@
 =GCP Project Overview=
-This project documents a set of best practices for managing open source component vulnerability within enterprise applications. Fundamentally, we are concerned with usage throughout the entire component life cycle, from the time a component is selected for inclusion within the application through its deployment and maintenance within the production environment.
+This project documents a set of best practices for managing component vulnerability within enterprise applications. Fundamentally, we are concerned with usage throughout the entire process, from the time a component is selected for inclusion within the application through its deployment and maintenance within the production environment.
-The underlying premise of this project is that the application itself should be part of the assurance process. Application self assurance needs to ensure that the "things" being placed into the system are not introducing new risks. Automated vulnerability discovery must be part of any continuous delivery process. If self-assurance and automated monitoring are not integrated into the entire life cycle of the component/application relationship, it is virtually impossible to assure the security of the system.
+The underlying premise of this project is that the application itself should be part of the assurance process. Application self assurance needs to ensure that the "things" being placed into the system are not introducing new risks. Automated vulnerability discovery must be part of any continuous delivery process. If self-assurance and automated monitoring are not integrated into the development and production environment, it is virtually impossible to assure the security of the system.
 In this project, we will examine three gateways of component vulnerability and establish a series of best practices for managing component security. The output of the project will be a set of best practices for managing and monitoring open source components as part of the complete component life cycle.

← Older revision		Revision as of 15:09, 1 May 2013
Line 46:		Line 46:

	= Outline for Good Component Practices =		= Outline for Good Component Practices =
		+	(Rough outline: need details with downloadable check sheet)

	== Component Selection ==		== Component Selection ==

@@ Line 63: / Line 63: @@
 == Component Selection ==
 *Set standards and policy for component usage
 **Components must be actively maintained

← Older revision		Revision as of 14:59, 26 April 2013
Line 12:		Line 12:

	In this project, we will examine three gateways of component vulnerability and establish a series of best practices for managing component security. The output of the project will be a set of best practices for managing and monitoring open source components as part of the complete component life cycle.		In this project, we will examine three gateways of component vulnerability and establish a series of best practices for managing component security. The output of the project will be a set of best practices for managing and monitoring open source components as part of the complete component life cycle.
		+
		+	[[User:Mark Miller\|Mark Miller]] 14:59, 26 April 2013 (UTC)

	= Gateways of Component Vulnerability =		= Gateways of Component Vulnerability =

@@ Line 11: / Line 11: @@
 If self-assurance is not included in the tooling, the process is very easy to subvert. If the delivery tools themselves don't allow the subversion of the policies, and you can actually  inspect the process, then it can be asked, "Was this tool chain used?" If the answer is "Yes, the tool chain was used", it can then be asserted that the only way for this component to get deployed is through the policies built within the tool." It is no longer left up to the discretion of individual developers to manage component vulnerabilities.
-In this project, we will examine three gateways of component vulnerability and establish a series of best practices for managing component. The output of the project will be a set of best practices for managing and monitoring open source components as part of the complete component life cycle.
+In this project, we will examine three gateways of component vulnerability and establish a series of best practices for managing component security. The output of the project will be a set of best practices for managing and monitoring open source components as part of the complete component life cycle.
 = Gateways of Component Vulnerability =

@@ Line 47: / Line 47: @@
 == Component Selection ==
 *Set standards and policy for component usage
 *Identify components needed
@@ Line 67: / Line 61: @@
 == Component Selection ==
 == Integration into Development Environment ==
 == Integration and Maintenance within Production Environment ==

@@ Line 1: / Line 1: @@
-=GCP Project Objective=
+=GCP Project Overview=
 This project documents a set of best practices for managing open source component vulnerability within enterprise applications. Fundamentally, we are concerned with usage throughout the entire component life cycle, from the time a component is selected for inclusion within the application through its deployment and maintenance within the production environment.
-We will look at each level of vulnerability and establish a series of best practices for managing component usage at that level. The conclusion of the project will be a set of best practices for managing open source components as part of a larger application within an enterprise system.
+The underlying premise of this project is that the application itself should be part of the assurance process. Application self assurance needs to ensure that the "things" being placed into the system are not introducing new risks. Automated vulnerability discovery must be part of any continuous delivery process. If self-assurance and automated monitoring are not integrated into the entire life cycle of the component/application relationship, it is virtually impossible to assure the security of the system.
 = Gateways of Component Vulnerability =
-When establishing a framework for '''Good Component Practices''', there are three gateways at which a vulnerability may occur: Selection/Consumption, Integration, Deployment.  Each of these gateways must be policed and monitored to block, eliminate or manage vulnerable components. In this section, we describe the three gateways.
+There are three gateways at which a vulnerable component may be included within an application: Selection/Consumption, Integration, Deployment.  Each of these gateways must be policed and monitored to block, eliminate or manage vulnerable components. In this section, we describe the three gateways.
 =='''Consumption''': Selection of the components and where they came from (provenance)==
@@ Line 35: / Line 43: @@
 [[User:Mark Miller|Mark Miller]] 22:04, 24 April 2013 (UTC)
-= High Level Framework for Good Component Practices =
+= Outline for Good Component Practices =
 == Component Selection ==
@@ Line 46: / Line 54: @@
 **Components with known vulnerabilities must be removed or updated within 1 month of vulnerability announcement
 *Identify components needed
 == Integration into Development Environment ==
 == Integration and Maintenance within Production Environment ==
-*Scan runtime enviroment for libraries, frameworks and components
+*Automated inventory of existing components, libraries and frameworks
-*Monitor components for vulnerabilities
+*Monitor usage of deployed components
 *Update risky components
 = Detailed Framework for Good Component Practices =