Discussion Topic: End of Life for OSS - How is it being addressed

Discussion Topic for OSS Supply Chain Risks WG

Description of Problem:

For the majority of open-source software, the concept of End Of Life (as it is defined for vendor software) does not apply. There is no official support to begin with, and thus no "end of support" either. However, OSS library releases can easily become stale, as more recent releases are available, and those more recent releases will include bug fixes and potential security vulnerability fixes, which the application developers would not benefit from unless they upgrade to those more recent releases.

It is however not obvious for an application developer to know which releases are stale, which need upgrading, and also it is particularly difficult to quantify staleness in a way that can be aggregated and reported on for multiple projects across an organization, which poses a major problem - we cannot improve what we cannot measure.

onboarding processes - refer to OSR - per Mimi Flynn
ongoing security scanning of artifacts
Version management - "straight open source" specific licenses allowed; commercial OSS restricted to groups with license; specific versions blocked based on CVEs; dependency hygiene scores
retirement processes - initiative for EOL - dashboards, hygiene inits, tooling to get devs "comfortable" w deleting stuff; shared repo could be good value to all participants

Potential Solutions:

One proposed approach is described at https://github.com/finos/devops-automation/issues/44

### Tasks

finos / devops-automation