Viability: An Open Source CHAOSS Metric (Super)Model  ## Metadata - Author: [[Gary White]] - Full Title: Viability: An Open Source CHAOSS Metric (Super)Model - Category: #articles - Document Note: # Title: Understanding Software Supply Chains and the Viability Model - - - tags: #SoftwareSupplyChain #ViabilityModel #OpenSource Author: Gary White Source: CHAOSS Blog Reference: [CHAOSS Blog](https://chaoss.community/blog/) date created: 2023-03-15T09:30 - - - ## Table of Contents: - Introduction - The Importance of Software Bills of Material (SBOM) - Prioritizing Component Updates - The Viability Model - Metrics for Viability Assessment - Practical Application of Viability Metrics - Conclusion ## Index Creation: - Software Supply Chains - Vulnerabilities - License Risks - Prioritization - Viability Metrics - Community - Strategy - Governance - Compliance - Security ## 📝 Summary: Companies using open source software are increasingly concerned about understanding their software supply chains, vulnerabilities, and license risks. This is driven, in part, by recent efforts regarding Software Bills of Material (SBOMs). The proliferation of SBOMs, SAST, and SCA scanning tools allows users and developers to gain insights into their risk portfolio, particularly regarding vulnerabilities and licensing information. However, there is a lack of industry practice for prioritizing component updates, leading to the entrenchment of old dependencies. The Viability model aims to address this by providing metrics related to Community, Strategy, Governance, and Compliance/Security, helping organizations make more informed decisions about open source software. ## 📖 Main Content: The article discusses the increasing importance of understanding software supply chains, especially in the context of open source software. It highlights the significance of Software Bills of Material (SBOMs) and the need to prioritize component updates. The article then introduces the Viability model, which focuses on metrics related to Community, Strategy, Governance, and Compliance/Security. ### 🗒️ Notes: - Understanding software supply chains is crucial for organizations. - SBOMs, SAST, and SCA scanning tools provide insights into vulnerabilities and licensing. - There is a lack of industry practice for prioritizing component updates. - The Viability model offers metrics to assess the viability of open source projects. - Metrics cover Community, Strategy, Governance, and Compliance/Security. - Viability helps in making informed decisions about software dependencies. ## 📖 References: - [CHAOSS Blog](https://chaoss.community/blog/) ## 🗣️ Paraphrase: 1. "Companies using open source software are increasingly concerned about understanding their software supply chains, vulnerabilities, and license risks due to recent efforts regarding Software Bills of Material (SBOMs). The proliferation of SBOMs, SAST, and SCA scanning tools allows users and developers to gain insights into their risk portfolio, particularly regarding vulnerabilities and licensing information." 2. "The Viability model aims to address the lack of industry practice for prioritizing component updates, which often leads to the entrenchment of old dependencies. It provides metrics related to Community, Strategy, Governance, and Compliance/Security, helping organizations make more informed decisions about open source software." ## 🧪 Hypotheses: 1. Future research could explore the effectiveness of the Viability model in reducing the risk associated with outdated software dependencies. 2. Investigate whether organizations that prioritize component updates based on Viability metrics experience fewer security incidents and licensing issues. ### 📊 Methodology: 1. Conduct surveys and interviews with organizations implementing the Viability model to assess its impact on software supply chain management. 2. Analyze historical data on security incidents and licensing disputes in organizations that have adopted Viability metrics. 3. Compare the performance of software projects that prioritize updates using Viability metrics with those that do not. ### 💡 Implications: The research on the Viability model's impact could inform organizations about the benefits of using such metrics for software supply chain management. It may lead to more widespread adoption and improved decision-making in selecting and maintaining software dependencies. ### 🔮 Future Research: 1. Investigate the correlation between Viability metrics and the long-term sustainability of open source projects. 2. Explore how the Viability model can be adapted for use in different industries and geographical regions. 3. Assess the impact of Viability metrics on stakeholder communication and decision-making processes within organizations. ### ❓ Implications: Research on the impact of the Viability model may influence the adoption of similar metrics in other domains, potentially improving decision-making processes and reducing risks associated with software supply chains. ### ✅ Logical validity: The article presents a logical and coherent argument about the importance of understanding software supply chains, the challenges related to component updates, and the introduction of the Viability model. It employs a straightforward tone and provides practical insights. ## Conclusion: The article emphasizes the growing importance of comprehending software supply chains and the need for prioritizing component updates. It introduces the Viability model, which offers metrics related to various aspects of open source projects. These metrics can help organizations make more informed decisions about software dependencies and mitigate risks associated with outdated components. - Summary: Companies using open source software are increasingly concerned about bills of material, vulnerabilities, and license risks. The United States' efforts regarding Software Bills of Material (SBOMs) have prompted a focus on software supply chains. This has led to the proliferation of SBOMs, SAST, and SCA scanning tools, which help users and developers understand their risk portfolio. However, there is a need for a way to prioritize and update dependencies to reduce risk. The Viability metric model, developed by CHAOSS, provides insight into the Community, Strategy, Governance, and Compliance/Security of open source projects. It offers guidance for making software choices and can be used to measure the viability of open source projects. - URL: https://chaoss.community/oss-viability-metric-supermodel/ *This post is part of a three part series. This is part one. Stay tuned to the CHAOSS blog for a deep dive into the metrics around Viability, and a guide on how we can use this model.* Companies who use open source software (so, all of them) have been thinking more and more about bills of material, vulnerabilities, and license risks. This has especially been encouraged through recent [United States efforts](https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity) regarding Software Bills of Material (SBOM’s). This push is a good opportunity to observe and report on software supply chains. We can all learn a lot from knowing what’s in our software dependencies! Proliferation of [SBOM’s](https://en.wikipedia.org/wiki/Software_supply_chain), [SAST](https://en.wikipedia.org/wiki/Static_application_security_testing), and [SCA](https://en.wikipedia.org/wiki/Software_composition_analysis) scanning tools allows for users and developers of software everywhere to better understand their risk portfolio. Most people find significant value by using these reports to surface critically important vulnerabilities and license information. #### Choosing and Updating Components When Verizon, and the OSPO within, looked through our own SBOM’s and assessed which dependencies we should update. We found that common practice sparsely dictates relative priority. Barely any priority is set as industry practice for updating dependencies. Outside of CVE’s (with their own criticality rating), and licensing resolution (usually a hard yes/no from legal teams). Old dependencies without any open vulnerabilities are regularly put behind new features and critical breakages. That felt **wrong** to us. Over time, dependencies that had “never needed updating” find themselves painfully entrenched in our applications. When they *do* need upgrading the effort to do so can take dramatic time away from other development. We thought for sure, there has to be a way to identify (and reduce) that risk. A visual representation of open source libraries available to accomplish a minor engineering task Photo by Zaini Izzuddin on Unsplash What else should we be looking for in our open source software **choices**? What guidance can we give to encourage good decisions not just when maintaining software? Should that guidance be different than when people decide on software to use? Software technologists regularly make decisions about which software they should use in their project. Rarely is this done with an SCA tool, SAST tool, or an SBOM. Could we provide tools and metrics to guide decisions? How can we create less risk in our choices, providing more sustainable software infrastructure? From these question we set to develop a model to make sense of the complexity. #### More than Vulnerabilities and Licensing Enter: Viability. Metrics (and [metrics models](https://chaoss.community/kbtopic/all-metrics-models/)) about open source projects. These provide insight into the [Community](https://chaoss.community/kb/metrics-model-oss-project-viability-community/), [Strategy](https://chaoss.community/kb/metrics-model-oss-project-viability-strategy/), [Governance](https://chaoss.community/kb/metrics-model-oss-project-viability-governance/), and [Compliance/Security](https://chaoss.community/kb/metrics-model-oss-project-viability-compliance-security/) of open source projects. This series of blog posts will cover the motivation and background, what metrics are included in the model, and finally how we can use those metrics to measure Viability in OSS. Viability is built with metrics [detailed by CHAOSS](https://chaoss.community/kbtopic/all-metrics/), as CHAOSS has spent a while talking about how to make these metrics serviceable and understandable for technologists across geography and industry focus. For brevity and focus Viability is split into four [metrics models](https://chaoss.community/kbtopic/all-metrics-models/): Community, Strategy, Governance, and Compliance + Security. The individual value proposition of metrics per model is best described in their respective pages. The whole includes many metrics, and some overlap per sub-model. We did this so they may be used independently or in concert for a full picture of viable open source projects. We recommend using all of the models together, but mixing and matching them is also expected and appropriate. The application of these metrics at Verizon allows us to operationalize tasks for choosing and maintaining software. While evaluating dependencies, engineers have a better idea of what parts of an open source project excel, and what may fall short. Depending on the application intended, OSPOs and application teams can decide if the risk is worth taking on a project together. Viability provides direction to what dependencies should be updated. Instead of lumping old dependencies into a ball of vague “technical debt”, we can estimate the fit of community, strategy, governance, and compliance / licensing against a particular project. We can also approximate the risk of **not** addressing projects in a way that is quantifiable to stakeholders; and in review of priorities. #### Thanks, and come see us! I’m excited to share this model with everyone; it’s been a while in the making. Be part of the next project, ask questions, and get involved with CHAOSS working group by dropping into the [CHAOSS slack channel.](https://join.slack.com/t/chaoss-workspace/shared_invite/zt-1fah5gu35-5oUQEPT32O2Zt~3MFVNMlw) You can ping me (Gary White!) while you’re there., Viability: An Open Source CHAOSS Metric (Super)Model, Gary White, 01hgtd00ngrtgqmzph40s6cx1k.