I'm working on a large legacy project that utilizes numerous C++ and .NET libraries. I've been facing challenges in identifying which libraries are officially end-of-life (EOL) or simply abandoned. Manually checking vendor pages for each library seems tedious. How do others approach this issue? I created a small tool that attempts to automate this process by crawling the web and saving results, though it's not definitive. Right now, it only checks one library at a time, but I'm considering expanding it to scan my entire project, potentially through an SBOM upload. I'm open to feedback on this method!
3 Answers
In my experience, keeping track of dependency support is crucial for developers. If your project has too many dependencies to handle, it's a sign that it might be poorly structured. C++ can complicate managing this, but .NET is easier thanks to NuGet tools that let you check for updates. Regardless, it’s essential to actively manage dependencies. If you discover that a lot of your libraries are outdated, it might be worth reevaluating why you're using so many in the first place.
But is it really a problem if a library reaches EOL? If it’s not a core part of your application, like a JSON parser or API library, maybe the risk isn’t that high, and it’s not something to worry too much about.
You might consider contributing to a project like endoflife.date. They gather information about libraries and their support status, though they seem more focused on applications and frameworks than individual libraries. Reaching out to them could be a good idea for collaboration!
Thanks for the suggestion! I checked out endoflife.date, and it's helpful, but I think I need something more focused on libraries specifically.
I agree with you. It's definitely the developer's responsibility. Maybe we can provide them with tools to help out, like a system that doesn’t just check for vulnerabilities but also alerts about EOL libraries. That way, we support developers instead of overwhelming them!