Maturity Model Presentation from Open Compliance Summit 2023

ShaneCoughlan3 123 views 8 slides Jul 29, 2024
Slide 1
Slide 1 of 8
Slide 1
1
Slide 2
2
Slide 3
3
Slide 4
4
Slide 5
5
Slide 6
6
Slide 7
7
Slide 8
8

About This Presentation

Maturity Model Presentation from Open Compliance Summit 2023


Slide Content

Open Chain Maturity Model Roadmap

Capability Maturity Model – What is a CMM? A framework for determining the degree of capability, adaptability and resilience of a business function within an organisation, with the aim of optimising continuous improvement.

Maturity Model – High Level Approach Indicative levels of maturity INITIAL: Minimal knowledge of open source compliance practice and procedure REPEATABLE: Some steps towards compliance. Some systems in place, but application ad hoc DEFINED/IMPLEMENTED: Policies, practice and procedure in place, but not necessarily in operation MANAGED: Policies etc. in place, and in operation, and improved as considered necessary OPTIMISING: Policies etc. in place, in operation, and actively managed using appropriate metrics and a process of continuous improvement.

Maturity Model – High Level Approach 59% 38 % 64% 50% 5 4 3 2 1 Measured Maturity Score Target Systems Information People & Organisation Process Optimising Managed Defined / Implemented Repeatable Initial The capabilities of the organisation that have been developed to manage open source software development will be considered against the requirements of the OpenChain Specification v2.1, ISO/IEC 5230:2020. They wil l be categorised into four types of capability; people and organisational, process, information, and systems. Maturity will be assessed against five levels of completeness as shown. The target level will be specific to each organisation and can be set according to their ambition and view of business risk and priorities for delivery. The gap between target level and measured level presents defines opportunities for improvement and is easily converted to implementation plans,

OpenChain Provides a Potential Framework The Specification (ISO 5230:2020) contains the set of characteristics that a quality Open Source development function possess within an organisation. Each OpenChain requirement can be mapped against a business function, and a degree of maturity can be assigned to each business function. We propose a hierarchy. Top level requirements will be applicable across all organisations. Second level requirements can be tailored to the method of implementation chosen by the organisation. It’s compatible with existing best practice in capability maturity modelling across the whole range of an organisation’s business functions, not just software development (or open source software development).

ISO Requirements and Processes Governance Strategy and Oversight 6 3.1.1 Policy Appoint policy author, owner, exec sponsor Publish policy Review policy Distribute policy Track awareness of policy Review performance against policy objectives Enablement and Performance Management 3.1.4 Program scope Define programme scope Review appropriateness of programme scope Define risks to be managed Define benefits to be achieved 3.1.2 Competence Identify roles and responsibilities Determine competence required Determine training need Assess competence achieved 3.2.2 Effectively resourced Review programme resourcing and funding Track progress against policy objectives Analyse progress against policy objectives 3.5.1 Contributions Develop policy for contributions (in and outbound) Review and maintain policy Track progress against policy Review performance (risks and benefits) 3.1.3 Awareness Communicate open source and contribution policy Track awareness of policies Communicate implications of non-compliance Track non-compliance events Track awareness of contribution policy Open Chain Delivery 3.6.1 Conformance, 3.6.2 Duration Review OpenChain conformance (18 month) Manage 3 rd party certification 3.1.5 License Obligations Identify licenses in use Document license obligations 3.3.2 License Compliance review license compliance across distribution modes Produce contributions guidelines for contributors 3.3.1 Bill of Materials Produce SBOM Review and approve SBOM Maintain version and distribution history Licence analysis Produce records of process followed 3.4.1 Compliance Artifacts Generate artefacts Distribute artifacts Record artifacts 3.2.1 Access Respond to compliance inquiries Track nature of response to inquiries Review performance of inquiry responses

Example assessment 3.3.1 Bill of Materials People and Organisation Capability Processes Capabiliity Attributes P&O Maturity Questions Process Attributes Process Maturity Questions Key role holders Development Team Leader Associated roles DevOps Specialist Does a role exist for generating (or maintaining the system which generates) SBOMs? Are role/responsibility holders suitably trained? Do role/responsibility holders have the necessary competencies? Key processes Produce SBOM Review and approve SBOM Maintain version and distribution history Produce records of process followed Does a process exist (automated or not) for generating SBOMs? Does a process exist for reviewing and approving SBOMs? As part of any process involving SBOMs, are suitable records kept? Information Capability Systems Capability Information Attributes Information maturity question Systems Attributes Systems Maturity Questions Key Information Component manifests Correct SBOMs SBOM records & metadata Are component manifests made available for compliance purposes? Are SBOMs generated? Do SBOMs contain sufficient correct data for licence compliance?* Are SBOMs generated in a way which facilitates other risk management or operational processes (e.g. security/vulnerability or export control) Are standards (e.g. SPDX, CycloneDX) used to generate SBOMs   Are the standards used to generate SBOMs consistent across the organisation? Key systems Compliance toolchain* Emerging good practice Metadata repository (such as SW360)   Does the compliance toolchain have functionality for generating SBOMs? Where issues are identified (e.g., a failing test) is it possible to remedy the issue in-situ? Is compliance metadata stored in a suitable system such as SW360?

Full Profile Assessment Rapid view of gaps and priorities Deeper analysis possible by each of the four capability lenses. Supports optimisation of open chain programme