Hi Tak,

>> there is no specific way to declare conformance to this guide. And each duration will be managed separately.

One can declare conformance with the guide. According to section 3.4.2:

ÿ          3.4.2.1 A document affirming the Program meets all the requirements of this guide, within the past 18 months of obtaining conformance validation.

Although it is true they are separate, they are highly complimentary. Once a company can gather up evidence that demonstrates that each of the requirements (verification materials) have been met including a document for verification artifact 3.4.2.1 above, one can claim conformance from the date of that document. At that point the company would be able to present evidence to any party (at their choice) to demonstrate conformance (e.g., major customer). Although it is NOT a requirement to publish the evidence – they would be capable should they choose to do so.

>> if a program already OpenChain conformant is newly this guide conformant, it may be possible to renew this guide conformant in conjunction with the subsequent OpenChain conformant.

Yes, that is very achievable. Although they each require a separate preparation and archiving of evidence (verifications materials) – they can be performed in parallel. Even if an organization achieved conformance with the spec 6 months prior to the security assurance guide, they can both be renewed in the future at the same time. There is no need to wait 18 months. An organization can choose to verify conformance annually (e.g., every January) – which represents a best practice. The 18 month requirement was included as a minimum baseline to make sure an organization keeps their evidence (i.e., their policies, procedures and documents) current.

Please let us know if you would like additional clarification.

best,

Mark

Hi Chris,

>> Is there some way to incorporate this guide into the basic OpenChain Specification as an added conformance item?

We introduced the security assurance guide as a separate deliverable initially to reduce friction to adoption of both the spec and security guide. We did not want to have a company feel obligated to conform with both to achieve either one. However, having noted that, they were designed to be highly similar in spirit and format, and easily achieved together should a company choose (or a customer requires it). That is, they are separate but highly complementary. The long term objective is to create trust in open source by working toward creating a suite of highly complementary conformance specifications (e.g., license compliance, security, quality, export compliance, …) such that an organization can choose the ones that best fit their needs. For that reason we are trying to avoid creating a single monolithic specification.

Let us know if that does not completely address your concern.

Hi Tak,

>>   "There is no registration procedure such as in §3.6.2 of OpenChain Specification."

That is correct - conformance is obtained once an organization has satisfied all the requirements (verification materials). This is achieved by guide requirement 3.4.2.1. I can make the case that – although registration  is a helpful aid, it is not a requirement for spec conformance. That is – there are no verification materials that require registration. What spec conformance validation ensures is that evidence exists for each of the verification material requirements. That is achieved by 3.6.2.1.

>> §3.4 of this guide corresponds to §3.6 of the OpenChain specification; if so, this clause does not necessarily mean intending to publish evidence.

That is correct. There is no requirement to publish or make the evidence public. In fact, most will likely not choose that path. However, an organization is required to maintain digital evidence that all the requirements have been met. It is conceivable that if a supplier claims conformance, that their customer may request to see the evidence. Whether the evidence is provided to a customer is up to the negotiations between the two parties and likely subject to an NDA (assuming they agree).

Best,

Mark