I was recently invited to take an online “software supply chain maturity assessment” which got me into thinking about the concept of Software Supply Chain Maturity and why it is very important for an organization that develops products and solutions. Based on some quick research that I did, here are a few key aspects that I was able to uncover around this –
The Software Supply Chain Maturity of an organization describes various aspects of the organization’s processes, tools & frameworks used to help the organization keep up with the industry best practices. It is a measure of the organization’s effort to enhance the value of its products and solutions in the value chain proposition that it brings to the industry. At a high level, the maturity model encompasses the following major themes:
Inventory — Tracks the presence of process and tools to report application inventory, who the application stakeholders/owners are, how they are built, and the Software Bill of Materials (SBOM) for the Open-Source Software (OSS) components they include.
Suppliers
- Tracks the presence of process and tools to analyze, evaluate & approve new OSS components.
- Define criteria for deciding on the use of an OSS component — Popularity, Feature Set, Ease of Integration, Security History, Rate of security and bug fixes, OSS license, Commercial Support Availability, Foundation/Corporate sponsorship.>
Build & Release — Tracks the presence of DevOps & DevSecOps infrastructure & tooling to report on build and release process to feed into optimization efforts. Key focus areas in this theme include:
- Continuous Integration (CI)/Continuous Delivery (CD) infrastructure — team specific vs centrally managed
- Enforcement of OSS component governance (security, licensing) within the CI infrastructure
- Fully automated application deployments & configuration management
- Use of artifact repository
- Software Composition Analysis tools and integrating them with daily developer workflows (e.g., Black Duck, GitHub Dependency Check, OSS Index, Snyk, Sonatype, Whitesource, etc.)
- Use of Static Application Security Testing (SAST) & Dynamic Application Security Testing (DAST) tools
- Centrally analyze all deployed artifacts for open-source governance compliance
Consumption — Tracks the presence of governance processes to drive proactive selection of trusted OSS components & continuously monitoring them for new risk. Key focus areas in this theme include:
- Ease of upgrade, breaking upgrades
- Approval processes for use of new open-source libraries
- Maintaining internal modified versions of open-source dependencies/components — depending on urgency, good community support, and precedence of newer versions mostly having the fixes that are impacting us
Contribution — Tracks the presence of processes & tools to report on which OSS projects does your organization contribute back to and which OSS components used in your application have been modified. Key focus areas within this theme include:
- Company sponsored OSS projects — budget, engineering time, conferences, and tools
- Internal modifications to open-source components — contributed back or pushed upstream
Risk Management — Tracks the presence of and conformance to OSS policies defined at the organization level. Key focus areas in this theme are:
- Assess open-source libraries on their vulnerabilities, be aware of the licensing requirements for open-source libraries, organization policy regarding open-source licenses
- Proactively remove problematic dependencies
Execution Plan — Tracks the presence of transformation or socialization initiatives (plans, resources & trainings) within the organization to help institutionalize new processes and tools to drive DevSecOps adoption. Also involves setting up a centralized committee/group/team responsible for monitoring and enforcing open-source component
Remediation — Tracks the presence of processes and tools to address OSS component risks in a proactive and continuous manner. Key focus areas in this theme include:
- Processes to alert teams regarding new vulnerability discovered in open-source component and the time taken for the team to be aware of it
- Processes to define mitigation plan when vulnerability is discovered in open-source component and the time take for the team to mitigate the vulnerability
Its been a good revelation for me having undertaken this research. Some key focus areas have been uncovered with regards to how a technology company should strategize its journey towards improving the value addition of its products & solutions in the value chain proposition. I hope all of you had a good insightful read with this article. Keep innovating, don’t forget to be up there in the Software Supply Chain Maturity Model!
