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 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, SAST, and SCA 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.
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) about open source projects. These provide insight into the Community, Strategy, Governance, and 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, 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: 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. You can ping me (Gary White!) while you’re there.
