Ask HN: How do you deal with vulnerabilities in transient dependencies?

I've noticed a significant amount of tooling built around identifying supply chain issues with dependencies. Lots of SAST/DAST “scanner”-type tools available in the market. These tools typically work by searching CVE/similar databases against packages listed in your manifest/BOMs (such as pom.xml, requirements.txt, environment.yml, package.json, go.mod, cargo.toml, etc.).

The ideal scenario would involve upgrading the dependency to a version that is not vulnerable. However, in practice, there are some limiting factors. Sometimes, there is no fix available in the latest version, or the latest version comes with other challenges that must be first addressed (e.g. API changes).

Many times, vulnerabilities are found in transient dependencies. For instance, dep A requires dep B, which in turn requires dep C. Say dep C has a vulnerability. Dep A has to wait for B to first upgrade.

There are several options available in such cases. In the simplest scenario, a patch can be applied to dep C code to fix the vulnerability. Alternatively, one can insert some code between B and C, like an API wrapper, or perform fixes at A to prevent the critical path of the vulnerability from being reached in C. Is this what the community is currently doing?