Our regular monthly meeting continued our work to edit the next generation of our license compliance and security assurance specifications. Our focus this time was on some open issues around the next generation of the Security Assurance Specification.

The specific issues we covered:

Add triage entry to specific situations where vulnerability not applicable:
https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/29

Outcome: improved language suggested, needs work to further tighten phrasing.

Comments on the Known Vulnerability in the proposed Security Assurance Specification:
https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/19

Outcome: issue closed with adjustment to language in the specification.

Current draft of next generation security specification here:
https://github.com/OpenChain-Project/Security-Assurance-Specification/blob/main/Security-Assurance-Specification/2.0/en/openchain-security-specification-2.0.md

Check out the details and the full recording and slides here:

A reminder that our monthly North America / Asia call is taking place in a five minutes: 2023-03-21 at 09:00 CST / 10:00 KST+JST (01:00 UTC). That will be 18:00 Pacific on the 20th of March for our colleagues in North America. I look forward to seeing you at: https://zoom.us/j/4377592799

Slides attached. Check below for a quick recap of what we did on the last call and what we will do on this call.

On the previous call we recapped / reviewed:

Comments on the Known Vulnerability in the proposed Security Assurance Specification:
https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/19

Please add definitions for “remediate” and “mitigate”:
https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/22

We adjusted “obtain customer agreement”) as per this issue:
https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/27

Under the Competence category, add requirements:
https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/23

Add references to ISO/IEC Standards:
https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/24

We also opened this new issue:

Add triage entry to specific situations where vulnerability not applicable:
https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/29

We have the following items pending for *this* call:

= Security =

We will return to…

Add triage entry to specific situations where vulnerability not applicable:
https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/29

Comments on the Known Vulnerability in the proposed Security Assurance Specification:
https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/19

+

Add program objectives
https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/14

Clarify Stated Purpose (Github) and Scope (specification):
https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/28

= Licensing =

Consider adding definition of 'bill of materials’
https://github.com/OpenChain-Project/License-Compliance-Specification/issues/35

Move "Access" to be part of "Compliance Artifact Delivery”
https://github.com/OpenChain-Project/License-Compliance-Specification/issues/53

Some notes from Chris on the last meeting:

In the meeting we discussed and approved the following changes:

[Improvement] Add new term and refined term in Definitions Section 2.7 and 2.8

1.   We discussed and approved the addition of the Term Mitigation as a new term in the definitions section for "remediation" and "mitigation" (Section 2.7 Remediate and 2.8 Mitigate).

[Improvement] add the term "mitigate" to Section 3.1.5 as an available practice.

2.    We discussed and approved the insertion of Mitigation as an additional practice into Section 3.1.5 that can be used if remediation is not possible or is determined to be unnecessary based on the use of the software deemed to be vulnerable.

[Improvement] Include "mitigation" in Section 3.3.2 - Security Assurance

3.     We discussed and approved the insertion of a new term mitigation into Section 3.3.2 as an available practice:

For each identified Known Vulnerability assign a risk/impact score;

Edited line 252 for clarity: For each detection and assigned score determine and document necessary remediation or mitigation steps suitable for the use-case of the software;

Adjacent to this, we returned to a previously discussed improvement in the same section by deleting: “and get Customer Agreement at or above a previously determined level (i.e., all severity scores above 4.5 …);”

And the moment of  the concept to Line 254 in order to clarify that the owning organization is to clear the proposed resolution with the Customer only if that is a requirement from the customer.

Added for clarity: obtain Customer Agreement that the proposed resolution is acceptable if necessary; at or above a previously determined level (i.e., all severity scores above 4.5 …) 

China Electronics Standardization Institute (CESI) is the latest official partner of the OpenChain Project. From today, CESI is offering third-party certification around the standards produced by the OpenChain Project, with an initial focus on ISO/IEC 5230:2020, the International Standard for open source license compliance.

“The OpenChain Project is delighted to deepen our collaboration with CESI,” says Shane Coughlan, OpenChain General Manager. “CESI has an exceptionally important role in helping the world’s most populous country engage with, leverage and innovate around open source. Their new status as an official partner of the OpenChain Project opens doors for more companies in China to begin using our standards, and to begin benefiting from increased efficiency in their supply chains.”

“CESI is delighted to become an official partner of the OpenChain Project,” says Liyun Yang, Director of Cloud Computing Research Office. “We will offer third-party certification and assist in developing next generation versions of the OpenChain standards to help support Chinese companies, and the wider global supply chain.”

About CESI

Founded in July 1963, CESI is a nonprofit institution directly under the MII that is engaged in standardization, conformity assessment and measurement activities in the field of electronic information technologies. Authorized by government competent departments, CESI organizes the development of national and industry standards and participation in the international standardization activities in electronic information technologies. CESI provides product certification, quality system certification, experiments and tests, measurement and calibration as well as training for the public.

The objective of CESI is to become a world-renowned, domestically authoritative institution for standardization and conformity assessment in the field of electronic information technologies.

Learn More

• http://www.cesi.cn/page/index.html