@Bulb The solution at the end of the article - to merge the source of the library with the project to eliminate the dependency on the vulnerable library - doesn't work if an organization has rules in place other than cargo-culty "run the dependency graph through a checker a walk away" type rules.
In a mature organization, the guy who merges it in now has a new, and more immediate, problem; code review. Either his team takes on the debt by becoming active maintainers, starting with reviewing every line. Or, they take one of the more rational approaches. One would be to only merge in the exact parts of the library that's needed. It's often the case that a big library is used for a single functionality (lpad/kik anyone?). Fine, pull in the three lines of code, they're probably reasonably written, if not, fix them, and have them reviewed. It's what should have happened in the first place.
Another approach, assuming the article is correct and there isn't another reputable library that does the job, is to just write the functionality. Really, what are the odds that you need a big and sophisticated lump of code that no one else in your ecosystem needs? If you do, then you should be writing it yourself. Or maybe changing ecosystems.