Hi Nicole,

Thanks for the feedback. We briefly discussed your concern during the Specification working group meeting yesterday.

I know we'd like to focus on the open source part,

The Specification working group's mission is:
Establishing trust in the Open Source from which Software Solutions are built

but as realistically there are software components shipped down the supply chain that exist of both open source
and added self-developed code, shouldn't we at least add somewhere that people need to be aware of the
existing application specific security standards?

It is true the focus is on the open source part of the hybrid solutions you referred to. Most software solutions of at least moderate complexity will typically include some % of open source. In many cases (IoT devices, SaaS) it could be between 70-90%. We initially focus on the core process of identifying "known vulnerabilities" in the open source part because it typically represents a large % and that is where much of the data about vulnerabilities exists. That is where most companies start from and invest most of their effort in. Being able to detect vulnerabilities in the self-developed code (i.e., the non-open source part) is a more complex problem with much less public data and hence lower return on investment.

Because our focus is about establishing trust in open source the initial focus should contribute to that. We anticipate we will broaden the scope overtime based on community feedback (such as yours).

62443 anyway, why bother with the OpenChain security addendum at all...

OpenChain will likely complement as opposed to compete with many other standards. It is quite possible that an organization is compliant with another given standard that will automatically make them compliant with the OpenChain security addendum. That is ok - a supplier can claim compliant with both standards (something many suppliers like to do). Because the lion share of the software of many suppliers is comprised of open source, OEMs/manufacturers have become very interested in the health and well-being of the open source part. The key is for a manufacturer to obtain assurance that their suppliers are handling open source correctly (with respect to license compliance and security assurance). As OpenChain adds additional assurances overtime (e.g., quality, export compliance, malware and functional safety) the more valuable the OpenChain compliance suite becomes. That is - OpenChain will be able to provide a one stop shop for open source assurance (trust) which is a powerful value proposition.

I'd love to discuss this in today's call, but unfortunately I'm already off to another appointment...

We look forward to your future participation. These are the kinds of concerns we need to be discussing.

best,
Mark

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





-----Original Message-----
From: main@... <main@...> On Behalf Of Nicole Pappler
Sent: Monday, August 9, 2021 10:57 PM
To: OpenChain Specification <specification@...>; main@...
Subject: Re: [openchain] FINAL REMINDER: OpenChain Security Guidance Document - Last Call

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

Hi all,

I went through the security addendum, and what I'm now really wondering is, shouldn't we address the existence of the other existing security standards? Like IEC 62443 or ISO 21434? I know we'd like to focus on the open source part, but as realistically there are software components shipped down the supply chain that exist of both open source and added self-developed code, shouldn't we at least add somewhere that people need to be aware of the existing applicatition specific security standards? That they need to evaluate if they are applicable to their scope? Not sure if we should make it a hard requirement, but I'm afraid that completely ignoring existing standards would weaken the OpenChain statement here - as people might say, I have to adhere to to IEC/ISO
62443 anyway, why bother with the OpenChain security addendum at all...

I'd love to discuss this in today's call, but unfortunatly I'm already of to another appointment...

Cheers,

Nicole


Am 10.08.21 um 07:40 schrieb Shane Coughlan:

We begin in 20 minutes :)

REMINDER: OpenChain Bi-Weekly Work Group Call - 2021-08-10 at 06:00
UTC / 07:00 BST / 08:00 CEST / 11:30 IST / 14:00 CST / 15:00 KST+JST

We are finalizing this document:
https://1drv.ms/w/s!AsXJVqby5kpnkSaMT5WBZwJBONuB

In this Zoom room:
https://zoom.us/j/4377592799

The finished document will be released this week. It will provide context to all users of OpenChain ISO 5230 on application in the context of security.

--
——————————————————————————————————————
Nicole Pappler
email: nicole.pappler@...
mobile: +49 15156078183

PAPPSTARpromotion GmbH
Nürnberger Str. 2
91717 Wassertrüdingen
Germany

Sitz der Gesellschaft: Wassertrüdingen Registergericht: Amtsgericht Ansbach, HRB 7127
Geschäftsführer: Prof. Dr. Andreas Bärwald http://www.PAPPSTARpromotion.de