On Aug 23, 2021, at 23:06, Mark Gisi <mark.gisi@...> wrote:

One of the core guiding principles for the OpenChain Specification is to focus on the what and why of compliance (and avoid the how and when). This is highlighted in the introduction of the spec. That is avoid being prescriptive.

It was always understood that the OpenChain Project would foster the creation of various materials around best practices to educate how other companies achieve conformance. That is - to describe the prescriptive ways of others. This has not been done with any formal structure yet within the project. The proposed levels approach is the first attempt to do this which I commend. What I disagree with is mixing the specification to tightly with prescriptive ways because it undermines a core principle and purpose of the specification.

I suggest we create a complimentary best practice program/guide that encourages companies to consider various prescriptive levels. That is, have Best Practice Levels (bronze, silver, gold, …) but DON’T confuse it with the spec (which is: about what and why, practice neutral, non-prescriptive, …). For instance, have a program with its own logo (for example - see attached)

best,

Mark Gisi
Director, Open Source Program Office
Empowering Customers to Prosper using Open Source
(510) 749-2016





-----Original Message-----
From: specification@... <specification@...> On Behalf Of Shane Coughlan
Sent: Monday, August 23, 2021 1:43 AM
To: OpenChain Main <main@...>
Cc: OpenChain Japan <japan-wg@...>; OpenChain Korea <korea-wg@...>; OpenChain Germany <germany-wg@...>; OpenChain India <india-wg@...>; OpenChain UK <uk-wg@...>; OpenChain Partners <partners@...>; OpenChain Automotive <openchain-automotive-work-group@groups.io>; OpenChain Tooling <oss-based-compliance-tooling@groups.io>; OpenChain Specification <specification@...>
Subject: [specification] Proposal - OpenChain Quality of Conformance Assessment Levels (including a sub-proposal for tooling quality assessment levels)

[Please note: This e-mail is from an EXTERNAL e-mail address]

Dear all

During a recent OpenChain Japan Planning meeting we discussed the challenge of “next steps” in OpenChain ISO 5230 conformance. Our initial goal of adoption in the supply chain is well underway. Our basic concept of “raising all the boats” is working. But now it is time to talk in more detail about “raising the boats to where?”

From its launch in October 2016 until today, the OpenChain Project has been based on the concept of continual improvement (or Kaizen). We can now provide a “map” to help guide companies in this process, and to help customer companies judge the sophistication of suppliers who have adopted OpenChain ISO 5230.

Attached is a slide-deck exploring how this can be done. We will be discussing this in the OpenChain bi-weekly global work team meeting today (Monday 23rd of August) at 14:00 UTC. All welcome. No registration.
https://zoom.us/j/4377592799

You can add comments to this document online:
https://1drv.ms/p/s!AsXJVqby5kpnkShuUGG9M2Ki9MEc

Regards

Shane












<ocbp-logo.jpg>

On Aug 23, 2021, at 23:06, Mark Gisi <mark.gisi@...> wrote:

One of the core guiding principles for the OpenChain Specification is to focus on the what and why of compliance (and avoid the how and when). This is highlighted in the introduction of the spec. That is avoid being prescriptive.

It was always understood that the OpenChain Project would foster the creation of various materials around best practices to educate how other companies achieve conformance. That is - to describe the prescriptive ways of others. This has not been done with any formal structure yet within the project. The proposed levels approach is the first attempt to do this which I commend. What I disagree with is mixing the specification to tightly with prescriptive ways because it undermines a core principle and purpose of the specification.

I suggest we create a complimentary best practice program/guide that encourages companies to consider various prescriptive levels. That is, have Best Practice Levels (bronze, silver, gold, …) but DON’T confuse it with the spec (which is: about what and why, practice neutral, non-prescriptive, …). For instance, have a program with its own logo (for example - see attached)

best,

Mark Gisi
Director, Open Source Program Office
Empowering Customers to Prosper using Open Source
(510) 749-2016





-----Original Message-----
From: specification@... <specification@...> On Behalf Of Shane Coughlan
Sent: Monday, August 23, 2021 1:43 AM
To: OpenChain Main <main@...>
Cc: OpenChain Japan <japan-wg@...>; OpenChain Korea <korea-wg@...>; OpenChain Germany <germany-wg@...>; OpenChain India <india-wg@...>; OpenChain UK <uk-wg@...>; OpenChain Partners <partners@...>; OpenChain Automotive <openchain-automotive-work-group@groups.io>; OpenChain Tooling <oss-based-compliance-tooling@groups.io>; OpenChain Specification <specification@...>
Subject: [specification] Proposal - OpenChain Quality of Conformance Assessment Levels (including a sub-proposal for tooling quality assessment levels)

[Please note: This e-mail is from an EXTERNAL e-mail address]

Dear all

During a recent OpenChain Japan Planning meeting we discussed the challenge of “next steps” in OpenChain ISO 5230 conformance. Our initial goal of adoption in the supply chain is well underway. Our basic concept of “raising all the boats” is working. But now it is time to talk in more detail about “raising the boats to where?”

From its launch in October 2016 until today, the OpenChain Project has been based on the concept of continual improvement (or Kaizen). We can now provide a “map” to help guide companies in this process, and to help customer companies judge the sophistication of suppliers who have adopted OpenChain ISO 5230.

Attached is a slide-deck exploring how this can be done. We will be discussing this in the OpenChain bi-weekly global work team meeting today (Monday 23rd of August) at 14:00 UTC. All welcome. No registration.
https://urldefense.com/v3/__https://zoom.us/j/4377592799__;!!A3Ni8CS0y2Y!rSyuQmZ37tkXPfAEMCXKiRLUbYiVBKpseV5yI3tiH0QCwRW-ScqwcILPLBoN9QooyMCh$

You can add comments to this document online:
https://urldefense.com/v3/__https://1drv.ms/p/s!AsXJVqby5kpnkShuUGG9M2Ki9MEc__;!!A3Ni8CS0y2Y!rSyuQmZ37tkXPfAEMCXKiRLUbYiVBKpseV5yI3tiH0QCwRW-ScqwcILPLBoN9cDiU-x-$

Regards

Shane












<ocbp-logo.jpg>

On Aug 24, 2021, at 16:35, Steve Kilbane <stephen.kilbane@...> wrote:

Hi Shane,

As a comment on the revised slides, slide 10 doesn't work for me, since it shows a cycle, but you wouldn't go from your intended end-point (audit done) back to "just" OpenChain compliance without SBOM or automation.

As noted on the call, these aren't linear journeys, and an organisation could collect these plot tokens by wandering the map in whichever order they choose. They may add external audit first, then automation, then use that automation to produce their SBOMs.

I did like the idea of identifying them as best practices rather than "levels", because they can be adopted in any order. I did wonder whether it made sense to have a receiver award the SBOM badge to the supplier, but that might be problematic with respect to confidential business arrangements.

It would be nice if there were an SBOM badge that could be awarded to open source projects that are producing suitable output - uses SPDX Ids, includes an SBOM - but that's probably more down to the SPDX project than the OpenChain project.

steve

On Aug 25, 2021, at 17:35, Jari Koivisto <jari.p.koivisto@...> wrote:

Hi All,

I think that this new slide 10 is better now. It might add unnecessary complexity, but maybe each of the 4 arrows could have a small loop arrow on top depicting the nature of iterative work involved at each state, e.g. a company may try several types of automation to create the artefacts.

Jari

On Aug 26, 2021, at 0:52, Jacob Wilson via lists.openchainproject.org <Jacob.Wilson=synopsys.com@...> wrote:

I agree with Steve’s sentiment of wandering tokens, in my opinion levels of assurance with progressive technology independent criteria are required.
Borrowing from other ISO standards, I propose these "levels" outline a 1) goal 2) business case 3) metric. Goal criteria should increment as assurance or level of trust is achieved, while the case and metric move as the technology and supplier landscape change around the business.
 
In the below table I outline one view of this concept:

• Let’s say for example SBoM incorporates distributed ledger technology as discussed in other conversation threads. First the organization would build the business case around adapting SBoM technology to include blockchain, then they would establish a viable metric to measure this business justification. Ultimately the goal would remain intact because it was forward thinking and progressive in level of assurance.

• Now let’s say that an organization is considering the move from internal assessment of OpenChain ISO 5230 to an external 3rd party assessment. They may revise their business case from “Prevent uncertainty through alignment with OpenChain ISO 5230” to “Prevent bias and uncertainty through independent confirmation of OpenChain ISO 5230 compliance”. The Metric remains intact to facilitate the audit process and the goal of dedicating assurance resources remains intact as well.

 
These are a couple of ways we can move along the field while keeping the goal posts intact. Of course I’m always open to feedback, and I realize this doesn’t prevent an organization from collecting artifacts of conformance (silver) before establishing a management framework (bronze). But we can see the crawl, walk, run analogy in the progression in levels of assurance (goals).. Perhaps platinum level is hiring Toni Kroos for 3rd party assessment.

On Aug 26, 2021, at 6:22, Christopher Wood <cvw01@...> wrote:

Hello all
This is a great discussion.  I do like Jacob's suggestion with some simple notation that indicates that the "levels" or whatever you call them are cumulative going from the base (Level 1 up through Level 4).  I also believe that formal adoption of each level's requirements will become necessary for any "vendor or supplier" due to market demands and agree with Shane that they should probably not be dictated by the OpenChain Project.  To show that the additive features of the Chart 10 could be added to an inverted stack of the levels. (Level 1 is foundational to the concept and building on Level 1 gives you advanced capabilities as a 4th column.