More specifically:
1. How do you know if the vulnerable package is called in a way that it can be exploited? For example, if the package has a critical vulnerability in a method "myFunc" but it is never called by your code, it won't be exploitable.<p>2. How do you know if it is safe to upgrade a package and it won't break changes? For example, if version 1.2.3 has "myFunc(p1,p2)" and it is called by your code, but the vulnerability was fixed in version 1.2.4, which has "myFunc(p1,p2,p3)".<p>3. What do you do if the vulnerable package is a sub-package of another package used by your code?
There are tools for it, I have seen Contrast Security being used in workplace for Java applications. It reports insecure code and out of date libraries. I have seen it flag some Basic Authentication classes from Spring framework. It can be integrated with the CI/CD build pipeline. It also has a Java agent, which monitors runtime API calls to track if any vulnerable class is being accessed at runtime.<p>1. Use some software like Contrast Security to do it for you. Tools like these can tell you if your code accesses some vulnerable class/method at runtime. However, you'll have to determine whether you want to fix it. For example it has recently started flagging iText 2.1.7 libraries, but we determined that it was not exploitable in our application. It has to be done on case by case basis.<p>2. Only your unit/integration tests and QA testing can tell you if it works. Our team creates stories to update libraries, developers work on upgrade, do a superficial test that every thing seems to work and hand it over to QA team. They then test the running application in test environment and give it a go ahead if everything works.<p>3. We try to exclude the sub package (Maven/Gradle) and see if it breaks the application, we also try to upgrade the sub package to a newer version. If you're lucky, there won't be breaking changes. But sometimes, there are breaking changes and you'll have to rewrite your code to bring newer version of parent package, which in turn brings newer version of sub package.<p>Bottom line is it's hard work, there's no magic bullet.<p>I'm not affiliated with Contrast in anyway, there should be other tools for the same purpose.