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.

[azabujuban]

Is there any standard field in SBOM that can be used to keep the EOL info? The only thing i can think of is the properties field, but it's not standard no?

[Najafov007]

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

But until then, there's no chance of getting any info about EOL of our components as I've searched the whole internet, right sir?

[stevespringett]

Is there any standard field in SBOM that can be used to keep the EOL info? The only thing i can think of is the properties field, but it's not standard no?

No. The EOL/EOS data is too dynamic and subject to change often. Its also prone to change due to market conditions where something that was previously unsupported, suddenly becomes supported for a while again, and eventually retired again. Happens all the time with open source and commercial software.

The Common Lifecycle Enumeration (CLE) project is looking into devising a time-series specification to represent milestone events as well as other things that happen frequently in the supply chain, such as products being renamed/rebranded, mergers and acquisitions, etc. If anyone wants to get involved in that effort, there's a dedicated Slack channel on the OWASP Slack workspace and regularly scheduled working group calls.

One major issue with endoflife.date and similar efforts is that they are not time-series. They simply specify dates for various things and that's all. Product lifecycles are much more fluid than that, so we're trying to capture events in a time-series way.

Once CLE is complete it will be incorporated into the Transparency Exchange API being co-developed by OWASP and Ecma TC54. The API will eventually be added to Dependency-Track which would make consuming SBOMs and other supply chain intelligence much more scalable than it is today.

That said, there likely is a need for a short-term solution. Once that can work for the limited use cases we have today, while still being designed in a way that will work with these more robust future efforts.

[moulsonp]

Agree with @stevespringett it doesn't make sense to add this in the SBOM itself as it is too dynamic. But there is definately a need and demand for a short-term solution.

Can an attribute be added within dependency track where this EoS/EoES information can at least be manually added, ideally with an option to attempt to retreive via the endoflife.date API.