Talk:OWASP Good Component Practices Project

10 May 2013: Notes for phone conference

Mark Miller 16:49, 10 May 2013 (UTC)

It was agreed that each of us would layout our own steps so that we can look at them as a whole, because each will come at it from a different perspective. Following are the notes from our phone discussion, starting with a rough first "straw man" to get things started.

A community agreeable "set of outcomes" when utilizing good component practice is the goal.

Step One: Understand how your environment works

Step Two: Understand how your applications are built and delivered

• How are developers choosing components
• How are components being brought into the environment
• How are components introduced into the build
• How is the process managed

Step Three: Inventory your existing environment

Discussion Notes:

One of the first steps is to "know what you have". The steps we currently have are around the survey, and not generalized for better practices around component development

One of the first steps is not necessarily even creating the policy, it's understanding what you have. You need to understand your component based development practices before you can even begin to think about what a policy should be.

Even if you have an inventory, unless you understand the process of how applications are built and delivered, you're not going to succeed. You want to be able to create policies to guide the process, but must first understand how your environment works so that you can then come up with long term strategies for your policies and enforcement.

Many companies get hung up trying to inventory the environment, but they never finish inventorying because it's such a big job, so they never get to the stage where they can think about how the practices and processes are going to work. If we lead the recommendations with step one as "take inventory", that will never be completed, it's just too much to expect.

Our goal is to define a series of steps that consists of a set of practices that creates a series of outcomes. Not all practices need to be done as long as the process is meeting the outcomes defined. Outcomes should be able to be delivered whether it's an internal set things, whether it's services you apply, tools being applied, etc. The goal is to define the outcomes we are looking for and then back into the steps it would take to reach the desired outcomes.

As a model program, define the outcomes, then define the processes that will lead to those outcomes (people, processes and technologies). People can then choose to tailor that for implementation within their own organization in a way that makes sense for them.

Decision points for component management:

• Consumption
• Development
• Integration
• Deployment