I'm working with a large legacy project that relies on many C++ and .NET libraries. I've noticed it's tough to figure out which libraries are officially end-of-life (EOL) or abandoned. Researching each one manually by checking vendor pages is quite cumbersome. How do others manage this? I created a small tool that attempts to automate the process by crawling the web and gathering data, but it's not comprehensive. Right now, it checks one library at a time, but I'd like to eventually scan the entire project with a software bill of materials (SBOM). Am I on the right track with this strategy?
3 Answers
Honestly, if you have too many dependencies to manage, it points to possible design issues in your project. With C++, handling dependencies is challenging, but .NET makes it easier through NuGet. You can easily check if a dependency has been updated recently. Keep in mind, if you discover that many of your libraries are no longer maintained, it could be worth evaluating why you have so many dependencies in the first place. Removing dead weight could save you a lot of headaches down the line.
You might want to check out https://endoflife.date/; they have a good resource on this topic. It could help you see if any of your libraries are EOL.
Thanks for the suggestion! I've looked into their project, but it seems more focused on applications than individual libraries. I'll consider reaching out to them for specifics.
But is ending support for a library truly a big issue? Unless it’s a core library like for JSON parsing or API calls, I don’t see much risk since the chances of exploitation are usually low.
I totally get your point. Maybe as DevOps, we can assist developers by providing tools similar to what Dependency-Track does for vulnerabilities. If we generate an SBOM for the project, we can also alert about EOL libraries. This way, developers are reminded to stay on top of their dependencies.