This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "OWASP Good Component Practices Project"

From OWASP
Jump to: navigation, search
m
m
Line 6: Line 6:
  
 
= Gateways of Component Vulnerability =
 
= Gateways of Component Vulnerability =
When establishing a framework for '''Good Component Practices''', there are three gateways at which a vulnerability may occur. Each of these gateways need to be policed and monitored to block or eliminate the inclusion of vulnerable components. In this section, we describe the gateways vulnerable components can be recognized and monitored for reduced risk: Consumption, Integration and Deployment.
+
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.
 +
 
 
=='''Consumption''': Selection of the components and where they came from (provenance)==
 
=='''Consumption''': Selection of the components and where they came from (provenance)==
 +
The first gateway of entrance to monitor for risk management is provenance - where does the componenent come from from. There are three levels of risk to examine at first gateway:
 +
  -- Licensing
 +
  -- Security
 +
  -- Quality
 +
There must be a way to verify that the component downloaded is actually the component selected.
 +
 +
Once the component has crossed through the first gate, it becomes part of the development environment with other risk types
 +
 
=='''Integration''': Component management within the development environment==
 
=='''Integration''': Component management within the development environment==
 +
Is the component I'm using actually what I have downloaded. How do I know that what I originally said was "ok" is actually what is being used? A simplified scenario for a downloaded file is:
 +
<blockquote>I download a file and virus scan it on my machine.<br />
 +
The virus scan says it is clean so I put it in my local file directory.<br />
 +
At some later point in time, I use the file that I downloaded.<br />
 +
How do I insure that the thing that I downloaded is still what I thought it was?<br />
 +
How do I know the name wasn't changed, or the contents of the file haven't been altered?</blockquote>
 +
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==
 
=='''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.
 +
 +
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.
  
 +
Validation must be done through ever step in the supply chain to confirm that the component in use is what it says it is and hasn't been changed during the process.
 +
  
 
[[User:Mark Miller|Mark Miller]] 22:04, 24 April 2013 (UTC)
 
[[User:Mark Miller|Mark Miller]] 22:04, 24 April 2013 (UTC)

Revision as of 18:41, 25 April 2013

GCP Project Objective

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.

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.

Consumption: Selection of the components and where they came from (provenance)

The first gateway of entrance to monitor for risk management is provenance - where does the componenent come from from. There are three levels of risk to examine at first gateway:

  -- Licensing
  -- Security
  -- Quality

There must be a way to verify that the component downloaded is actually the component selected.

Once the component has crossed through the first gate, it becomes part of the development environment with other risk types

Integration: Component management within the development environment

Is the component I'm using actually what I have downloaded. How do I know that what I originally said was "ok" is actually what is being used? A simplified scenario for a downloaded file is:

I download a file and virus scan it on my machine.

The virus scan says it is clean so I put it in my local file directory.
At some later point in time, I use the file that I downloaded.
How do I insure that the thing that I downloaded is still what I thought it was?

How do I know the name wasn't changed, or the contents of the file haven't been altered?

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.

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.

Validation must be done through ever step in the supply chain to confirm that the component in use is what it says it is and hasn't been changed during the process.


Mark Miller 22:04, 24 April 2013 (UTC)

High Level Framework for Good Component Practices

Component Selection

  • Set standards and policy for component usage
    • Components must be actively maintained
    • Component projects must have a security contact and security announcement list
    • Component projects must use security tools and make the results public
    • Component projects must have a history of responding to security vulnerability reports in a timely manner
    • Component binaries must be generated directly from project source code using trusted tools
    • 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
  • Monitor components for vulnerabilities
    • Use Maven “Versions” plugin to check which components are out of date
  • Update risky components

Detailed Framework for Good Component Practices

Component Selection

Integration into Development Environment

Integration and Maintenance within Production Environment

Project About

PROJECT INFO
What does this OWASP project offer you?
RELEASE(S) INFO
What releases are available for this project?
what is this project?
Name: OWASP Good Component Practices Project (home page)
Purpose: Good Component Practice is one of the most over looked silver bullets in the Open Source arsenal. Because of business pressure, we have found that companies are willing to risk using unverified open source components, trading off security for enhanced speed in development.

This project will use community input to document an industry acceptable process for the creation, maintenance and use of open source components.

License: Creative Commons Attribution ShareAlike 3.0 License (best for documentation projects)
who is working on this project?
Project Leader(s):
  • Mark Miller @
Project Contributor(s):
  • Trusted Software Alliance
  • Sonatype
how can you learn more?
Project Pamphlet: Not Yet Created
Project Presentation:
Mailing list: Mailing List Archives
Project Roadmap: View
Key Contacts
  • Contact Mark Miller @ to contribute to this project
  • Contact Mark Miller @ to review or sponsor this project
current release
Not Yet Published
last reviewed release
Not Yet Reviewed


other releases