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"
Mark Miller (talk | contribs) m |
Mark Miller (talk | contribs) m |
||
Line 5: | Line 5: | ||
== 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: | + | When establishing a framework for '''Good Component Practices''', there are three gateways at which a vulnerability may occur: |
− | + | <br /><br /> | |
− | #Selection of the component and where it came from (provenance) | + | #Selection of the component and where it came from (provenance) |
− | #Integration of the component into the development environment | + | #Integration of the component into the development environment |
− | #Integration and maintenance of the component within the production environment</ | + | #Integration and maintenance of the component within the production environment |
− | + | <br /> | |
We will look at each level of vulnerability and establish a series of best practices for managing the 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. | We will look at each level of vulnerability and establish a series of best practices for managing the 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. | ||
[[User:Mark Miller|Mark Miller]] 22:04, 24 April 2013 (UTC) | [[User:Mark Miller|Mark Miller]] 22:04, 24 April 2013 (UTC) | ||
− | == Simplified Framework for Component | + | == Simplified Framework for Good Component Practices == |
==== Component Selection ==== | ==== 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 ==== | ==== 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 | ||
=Project About= | =Project About= |
Revision as of 17:24, 25 April 2013
Main
This project will document a set of best practices for managing component vulnerability at three main gateways.
Gateways of Component Vulnerability
When establishing a framework for Good Component Practices, there are three gateways at which a vulnerability may occur:
- Selection of the component and where it came from (provenance)
- Integration of the component into the development environment
- Integration and maintenance of the component within the production environment
We will look at each level of vulnerability and establish a series of best practices for managing the 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.
Mark Miller 22:04, 24 April 2013 (UTC)
Simplified 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
Project About
PROJECT INFO What does this OWASP project offer you? |
RELEASE(S) INFO What releases are available for this project? | |||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|