Add End-of-life (EOL) / End-of-support (EOS) information for components

[hvardhan20]

Current Behavior

Currently, Dtrack identifies Out-of-date components by checking for newer versions of components. But it does NOT identify whether a component is Out-of-Support or not.

Proposed Behavior

We should be able to get EOL/EOS information of components.

Use case: Take Spring boot for example. Couple of versions(2.7, 3.0) of Spring boot are nearing End of support date(for OSS). Support timelines of recent Spring boot versions from https://spring.io/projects/spring-boot#support:

Branch | Initial Release | End of Support | End Commercial Support * -- | -- | -- | -- 3.2.x | 2023-11-23 | 2024-11-23 | 2026-02-23 3.1.x | 2023-05-18 | 2024-05-18 | 2025-08-18 3.0.x | 2022-11-24 | 2023-11-24 | 2025-02-24 2.7.x | 2022-05-19 | 2023-11-24 | 2025-08-24 2.6.x | 2021-11-17 | 2022-11-24 | 2024-02-24

Which means there will not be a patch available if a critical security vulnerability is identified. Given how widely Spring boot is used globally, there would a security crisis if another Log4j scenario occurs.

EOL/EOS feature would be a proactive step towards mitigating another Log4j.

This information is tracked by https://endoflife.date/ We could add an analyzer for https://endoflife.date/ to fetch this information for components that are tracked currently.

Checklist

• [X] I have read and understand the contributing guidelines
• [X] I have checked the existing issues for whether this enhancement was already requested

[CorbyAsCode]

+1

I've always found it to be a good practice to provide viable and safe options instead of saying "Don't do this". Development teams will be searching for alternatives for packages if the ones they're using are flagged for vulnerabilities. Why not provide at least the latest version that's not vulnerable and isn't nearing end of support? At best, we could provide a list of package versions that pass vuln tests.

[nscuro]

We've been waiting for endoflife.date to support PURL, which as far as I can tell is still not the case. Without PURL support, we can't reliably correlate packages we ingest from SBOMs with the EOL data provided by endoflife.date.

[valentijnscholten]

Related to #8

[setchy]

+1 - this would be a great enhancement to Dependency Track, especially when paired with Policy Management to define organizational operational/security policies

[setchy]

Found this issue which talks about PURL support for endoflife.date - https://github.com/endoflife-date/release-data/issues/51

[jimklimov]

Slightly agreeing with #8 that using not-outdated components may be safer than using those on life support (LTS dependencies). Makes sense.

On the other hand, code that was out in the wild for months or years and only collected a few known vulnerabilities (and one-off backports to fix them) may have something to it, compared generally to new experimental code that has frankly an unknown attack surface. For teams that deal with their own LTS product support, the presumed lack of API breaking changes coming via bug-fixes to LTS streams of their dependencies is a greater benefit than having some all-new code complete with new APIs and new bugs.

After all, the development tips and recent rolling releases of products may depend on "everything new", while "stable/LTS" releases may have to depend on something predictable, prioritizing for minimum human work (and minimal end-user surprise) needed to make it secure vs. problems that become known during the LTS timeframe.

[ptdropper]

I agree with @jimklimov . Latest and most current software version does not at all mean most secure. We know that as a fact in software. For security libraries, such as openssl, there are defined branches of that library that provide support for specific classes of hardware and operating system combinations. Older branches have fewer features thus a smaller attack surface, thus in my world those are MORE secure.

[jamietanna]

FYI I've built functionality in a similar project for this.

I'd be happy to chat through the pURL-to-package name lookup, the code I've got is Apache-2.0 licensed.

[AppSecAmael]

Hello, why not check what is done in xeol ? That open-source tool can parse SBOMs and output end-of-life data.

[stevespringett]

Xeol now as an API, which would be ideal for Dependency-Track to integrate with.