Date   

OpenChain Automation Case Study launches September 22nd at 06:00 UTC (8am Berlin / 3pm Tokyo)

 

Dear all

As previously discussed, we will be launching a rolling case study between September and December 2021. This case study will be anchored by webinars in and around a new GUI tool from Facebook + TNG.

We initially planned to begin on September 15th. However, Michael (FB) and Max (TNG) are holding a launch event in Germany on the 22nd, so we will align the global launch with that date.

You will find the event details in the OpenChain global calendar. You can join this event via our normal Zoom room. No registration is necessary.
https://zoom.us/j/4377592799

Regards

Shane

Shane Coughlan
OpenChain General Manager
+818040358083
Book a meeting:
https://meetings.hubspot.com/scoughlan


Re: Open Source and ISO Standards - OpenChain and the Future of Compliance @ Open Source Summit - Sept 28th 2021

 

Hi Steve!

OpenChain has had an extraordinary impact across multiple sectors of governance, including security and M&A, pushing beyond the boundaries of OSPOs per se. Because of this, my general hint is to filter event schedules by “OpenChain” to see what turns up :)

Another tip is that you will find four OpenChain mini-summits around Linux Foundation events throughout the year, normally Open Source Summit North America, Open Source Summit Europe, Open Source Summit Japan and the Linux Foundation Membership Summit.

And, of course, everything we do will be flagged on this list unless our individual community members forget something they are doing :P

Regards

Shane

On Sep 9, 2021, at 17:59, Steve Kilbane <stephen.kilbane@analog.com> wrote:

Thanks for highlighting these, Shane. I'd gone straight for the OSPOCon filter, which is where I assumed all OpenChain-relevant content would be, so missed all of them. 😊

I'm gonna have to read all those blurbs more carefully, aren't I?

steve

-----Original Message-----
From: main@lists.openchainproject.org <main@lists.openchainproject.org> On Behalf Of Shane Coughlan
Sent: 08 September 2021 05:59
To: OpenChain Main <main@lists.openchainproject.org>
Subject: [openchain] Open Source and ISO Standards - OpenChain and the Future of Compliance @ Open Source Summit - Sept 28th 2021

[External]

We have three major talks Open Source Summit in Seattle, kicking off with Open Source and ISO Standards - OpenChain and the Future of Compliance, continuing with our friends at Huawei discussing practical usage in a large operating system project, and concluding with our (traditional) mini-summit. Links below.

Open Source and ISO Standards - OpenChain and the Future of Compliance - Shane Martin Coughlan, Linux Foundation Tuesday, September 28 • 12:00pm - 12:50pm https://urldefense.com/v3/__https://sched.co/lARA__;!!A3Ni8CS0y2Y!vJl30UjGopGtsC2PrJlpkj6JK5KkMO5yrVk3R5bh1s-80WPRW4RX9T3JaeclwOanIimL$

Meet All Scenarios OS: A Distributed O.S. with Feet on the Ground - Davide Ricci, Huawei Tuesday, September 28 • 9:00am - 9:50am https://urldefense.com/v3/__https://sched.co/lAMZ__;!!A3Ni8CS0y2Y!vJl30UjGopGtsC2PrJlpkj6JK5KkMO5yrVk3R5bh1s-80WPRW4RX9T3JaeclwLx-KImd$

OpenChain Quarterly Mini-Summit (Pre-Registration Required) Thursday, September 30 • 2:00pm - 5:30pm https://urldefense.com/v3/__https://sched.co/l90E__;!!A3Ni8CS0y2Y!vJl30UjGopGtsC2PrJlpkj6JK5KkMO5yrVk3R5bh1s-80WPRW4RX9T3JaeclwDwQGlA7$









External Resource: Growing the CHAOSS Community Globally - CHAOSS 社区的全球化故事 - with Xiaoya, Willem, King, and Clement

 

This podcast with some pillars of the Chinese open source community covers OpenChain thanks to our good friend King at Huawei:
https://podcast.chaoss.community/43

From a more general perspective, you can also find out more about current events in the Community Health Analytics Open Source Software Project :)


CfP - Open Compliance Summit - December 16th 2021 - Deadline October 1st

 

Reminder about upcoming deadlines/dates to be aware of regarding the Open Compliance Summit CFP:

• CFP Closes: Friday, October 1
• CFP Notifications: Tuesday, October 19
• Schedule Announcement: Thursday, October 21

https://events.linuxfoundation.org/open-compliance-summit/program/cfp/#%E6%A6%82%E8%A6%81


SPDX Becomes Internationally Recognized Standard for Software Bill of Materials

 

Backed by many of the world’s largest companies for more than a decade, SPDX formally becomes an internationally recognized ISO/IEC JTC 1 standard during a transformational time for software and supply chain security


Re: Open Source and ISO Standards - OpenChain and the Future of Compliance @ Open Source Summit - Sept 28th 2021

Steve Kilbane
 

Thanks for highlighting these, Shane. I'd gone straight for the OSPOCon filter, which is where I assumed all OpenChain-relevant content would be, so missed all of them. 😊

I'm gonna have to read all those blurbs more carefully, aren't I?

steve

-----Original Message-----
From: main@lists.openchainproject.org <main@lists.openchainproject.org> On Behalf Of Shane Coughlan
Sent: 08 September 2021 05:59
To: OpenChain Main <main@lists.openchainproject.org>
Subject: [openchain] Open Source and ISO Standards - OpenChain and the Future of Compliance @ Open Source Summit - Sept 28th 2021

[External]

We have three major talks Open Source Summit in Seattle, kicking off with Open Source and ISO Standards - OpenChain and the Future of Compliance, continuing with our friends at Huawei discussing practical usage in a large operating system project, and concluding with our (traditional) mini-summit. Links below.

Open Source and ISO Standards - OpenChain and the Future of Compliance - Shane Martin Coughlan, Linux Foundation Tuesday, September 28 • 12:00pm - 12:50pm https://urldefense.com/v3/__https://sched.co/lARA__;!!A3Ni8CS0y2Y!vJl30UjGopGtsC2PrJlpkj6JK5KkMO5yrVk3R5bh1s-80WPRW4RX9T3JaeclwOanIimL$

Meet All Scenarios OS: A Distributed O.S. with Feet on the Ground - Davide Ricci, Huawei Tuesday, September 28 • 9:00am - 9:50am https://urldefense.com/v3/__https://sched.co/lAMZ__;!!A3Ni8CS0y2Y!vJl30UjGopGtsC2PrJlpkj6JK5KkMO5yrVk3R5bh1s-80WPRW4RX9T3JaeclwLx-KImd$

OpenChain Quarterly Mini-Summit (Pre-Registration Required) Thursday, September 30 • 2:00pm - 5:30pm https://urldefense.com/v3/__https://sched.co/l90E__;!!A3Ni8CS0y2Y!vJl30UjGopGtsC2PrJlpkj6JK5KkMO5yrVk3R5bh1s-80WPRW4RX9T3JaeclwDwQGlA7$


SK Telecom is the first Telecommunications Operator to adopt OpenChain ISO 5230

 

SK Telecom, South Korea’s largest wireless carrier, is the first telecommunications operator to adopt OpenChain ISO 5230. This leap forward in governance builds on their long-term mission as a global ICT leader. Learn more:
https://www.openchainproject.org/featured/2021/09/08/sk-telecom


Open Source and ISO Standards - OpenChain and the Future of Compliance @ Open Source Summit - Sept 28th 2021

 

We have three major talks Open Source Summit in Seattle, kicking off with Open Source and ISO Standards - OpenChain and the Future of Compliance, continuing with our friends at Huawei discussing practical usage in a large operating system project, and concluding with our (traditional) mini-summit. Links below.

Open Source and ISO Standards - OpenChain and the Future of Compliance - Shane Martin Coughlan, Linux Foundation
Tuesday, September 28 • 12:00pm - 12:50pm
https://sched.co/lARA

Meet All Scenarios OS: A Distributed O.S. with Feet on the Ground - Davide Ricci, Huawei
Tuesday, September 28 • 9:00am - 9:50am
https://sched.co/lAMZ

OpenChain Quarterly Mini-Summit (Pre-Registration Required)
Thursday, September 30 • 2:00pm - 5:30pm
https://sched.co/l90E


OpenChain Webinar #30 – Automation Case Study + Continual Improvement In Compliance Programs

 

OpenChain Webinar #30 – Automation Case Study + Continual Improvement In Compliance Programs

Check out the full recording and the slides here:
https://www.openchainproject.org/news/2021/09/07/webinar-30

This is a pretty important webinar. One key take-away? We are going to be doing a massive, rolling case study from September through December 2021. The focus will be on automation, interoperability and ease-of-use. If you are considering automation, or improving automation, this is a great place to start.

Regards

Shane


Shane Coughlan
General Manager, OpenChain
e: scoughlan@linuxfoundation.org
p: +81 (0) 80 4035 8083
w: www.linuxfoundation.org

Schedule a call:
https://meetings.hubspot.com/scoughlan


Webinar in one hour (06:00 UTC): Automation Case Study from September through December 2021 + Continual improvement around open source license compliance programs

 

Today we are talking about an 'Automation Case Study from September through December 2021' + 'Continual improvement around open source license compliance programs'

Join Zoom Meeting
https://zoom.us/j/4377592799

Meeting ID: 437 759 2799
One tap mobile
+13126266799,,4377592799# US (Chicago)

Need to confirm your timezone?
2021-09-07 at 06:00 UTC / 07:00 BST / 08:00 CEST / 11:30 IST / 14:00 CST / 15:00 KST+JST


Reminder: submit your papers for Open Source Summit Japan / Automotive Linux Summit by September 19th

 

Reminder: submit your papers for Open Source Summit Japan / Automotive Linux Summit by September 19th

Here are the key dates:
• CFP Closes: Sunday, September 19 at 11:59pm PDT
• CFP Review: September 21 - October 15
• Internal Review & Preparation: Week of October 18
• CFP Notifications: Tuesday, October 26
• Schedule Announcement: Thursday, October 28
• Event Dates: Tuesday, December 14 – Wednesday, December 15

Learn more about OSS Japan:
https://events.linuxfoundation.org/open-source-summit-japan/

Learn more about ALS:
https://events.linuxfoundation.org/automotive-linux-summit/


Webinar #29 – OpenChain ISO 5230 in real-world project management + Governance in humanitarian deployments

 

File this under unmissable. Find out about where Huawei’s leadership is taking the future of OpenHarmony in terms of community and OpenChain ISO 5230 adoption. Plus, learn something new about the humanitarian space is exploring open source approaches and governance.
https://www.openchainproject.org/featured/2021/08/26/webinar-29


OpenChain Global Work Team Call 2021-08-23

 

If you want to dive into the full background on the recent discussion regarding compliance program quality and continual improvement, check out the recording of the latest work team call:
https://www.openchainproject.org/news/2021/08/26/openchain-global-work-team-call-2021-08-23


Re: Proposal - OpenChain Quality of Conformance Assessment Levels (including a sub-proposal for tooling quality assessment levels)

 

It does appear this mental model can provide an avenue forward.

Speculation: if the market(s) dictate various concepts of evolution, we will probably see differentiation by sector regarding preferred evolution paths. For example, what aerospace and defense sees as natural may be alien to automotive, despite neither sector being better or worse in where they land. This applies with perhaps greater contrast when we consider sectors like consumer electronics or consumables. When a cigarette company (for example) thinks about continual evolution of their compliance program, where they land will probably be significantly different to where a global phone-maker lands.

This is no bad thing. It provides plenty space for user-company groupings or third-party certifiers to model grading for open source license compliance programs. And it does not undermine the fact that OpenChain ISO 5230 defines the key requirements of a quality open source compliance program.

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.


Re: Proposal - OpenChain Quality of Conformance Assessment Levels (including a sub-proposal for tooling quality assessment levels)

 

All, context slides at link:

During our last call we had some strong push-back in terms of the project itself defining levels of competence. However, we may have an elegant way forward.

If the project defines the context (continual improvement), we can leave the specific implementation to the market with a natural dynamic addressing the “are people just making stuff up?”

For fields like defense, automotive and aerospace, some companies are likely to prefer third-party certification rather than self-certification in the context of procurement. This creates a market opportunity for companies like PwC or Hitachi Solutions to consider the product they offer. Currently it runs along the lines of “OpenChain certified and occasionally audited as per the standard”, but with our signaling for evolution, it makes sense for PwC and Hitachi Solutions to diversify and offered stepped products. This is to their benefit (more product) and to the community benefit (third-party grading if desired). 

While not being intrusive, the project and broader community can signal through official examples and case studies that provide a mental model for where grading may land. For example, this is slide 10 of the current deck:

The most important feedback we received is that no one should feel undervalued for having reached OpenChain ISO 5230 conformance. Adoption of the standard itself is transformative for the ecosystem, and we do not want to dilute that. That said, it is useful to offer inspiration when the question of “what next?” is raised.

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.


Re: Proposal - OpenChain Quality of Conformance Assessment Levels (including a sub-proposal for tooling quality assessment levels)

 

All, context slides at link:
https://1drv.ms/p/s!AsXJVqby5kpnkShuUGG9M2Ki9MEc

Jari, I think it’s a good idea, but I also fear it might add a little too much complexity at this time. How about we see how the slides are understood in Asia etc., seeing if any confusion exists, before action?

On Aug 25, 2021, at 17:35, Jari Koivisto <jari.p.koivisto@iki.fi> 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


External Article: Happy birthday, Linux: From a bedroom project to billions of devices in 30 years

 

In a break from our usual governance-related discussions, Linux has hit a big milestone and Greg KH has a few words to share in an interview on the topic. Those who know Greg will know that he is one of the most effective communicators and bridge-builders across multiple domains in the open ecosystem. This short article is a nice starting point for people seeking context:
https://www.theregister.com/2021/08/25/linux_kernel_30_years_old/


Re: Proposal - OpenChain Quality of Conformance Assessment Levels (including a sub-proposal for tooling quality assessment levels)

Christopher Wood
 

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.



On Wednesday, August 25, 2021, 10:52:57 AM CDT, 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.

 

 

 

Jacob Wilson

Senior Security Consultant
M: 773-372-8868 | jacob.wilson@...

Synopsys Software Integrity Group (SIG)

http://www.synopsys.com/software

 

From: main@... <main@...> On Behalf Of Jari Koivisto
Sent: Wednesday, August 25, 2021 4:36 AM
To: OpenChain Main <main@...>
Subject: Re: [openchain] Proposal - OpenChain Quality of Conformance Assessment Levels (including a sub-proposal for tooling quality assessment levels)

 

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

 


---
Jari Koivisto
E-mail: jari.p.koivisto@...
Mobile: +41 78 7479791
Skype: jari.p.koivisto
LinkedIn: http://www.linkedin.com/in/jarikoivisto

 

 

On Wed, 25 Aug 2021 at 07:16, Shane Coughlan <scoughlan@...> wrote:

Thanks Steve. Slide 10 has been refined to place emphasis on the actions being non-normative evolution on the part of a single example company:

 

Regarding SPDX or other SBOM badges, I am sure we will see movement in this direction in the coming weeks.

 

Shane



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


Re: Proposal - OpenChain Quality of Conformance Assessment Levels (including a sub-proposal for tooling quality assessment levels)

Jacob Wilson
 

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.

 

 

 

Jacob Wilson

Senior Security Consultant
M: 773-372-8868 | jacob.wilson@...

Synopsys Software Integrity Group (SIG)

http://www.synopsys.com/software

 

From: main@... <main@...> On Behalf Of Jari Koivisto
Sent: Wednesday, August 25, 2021 4:36 AM
To: OpenChain Main <main@...>
Subject: Re: [openchain] Proposal - OpenChain Quality of Conformance Assessment Levels (including a sub-proposal for tooling quality assessment levels)

 

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

 


---
Jari Koivisto
E-mail: jari.p.koivisto@...
Mobile: +41 78 7479791
Skype: jari.p.koivisto
LinkedIn: http://www.linkedin.com/in/jarikoivisto

 

 

On Wed, 25 Aug 2021 at 07:16, Shane Coughlan <scoughlan@...> wrote:

Thanks Steve. Slide 10 has been refined to place emphasis on the actions being non-normative evolution on the part of a single example company:

 

Regarding SPDX or other SBOM badges, I am sure we will see movement in this direction in the coming weeks.

 

Shane



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


Re: Proposal - OpenChain Quality of Conformance Assessment Levels (including a sub-proposal for tooling quality assessment levels)

Jari Koivisto
 

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


---
Jari Koivisto
E-mail: jari.p.koivisto@...
Mobile: +41 78 7479791
Skype: jari.p.koivisto
LinkedIn: http://www.linkedin.com/in/jarikoivisto



On Wed, 25 Aug 2021 at 07:16, Shane Coughlan <scoughlan@...> wrote:
Thanks Steve. Slide 10 has been refined to place emphasis on the actions being non-normative evolution on the part of a single example company:

Regarding SPDX or other SBOM badges, I am sure we will see movement in this direction in the coming weeks.

Shane

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

41 - 60 of 4227