Prove the Advisory Is Unreachable
Two HIGH advisories on a direct production dependency. No upgrade available. The audit tool's suggested fix would have rolled a framework back and defended a path that did not exist. Here is what I did instead, and the general form of it.
No Upgrade
Both advisories covered every version of an image-sizing library up to and including the latest published one. Nobody upstream has fixed it. It is not that I am behind. An override has nothing to point at. Removing it means removing the framework that pulls it in.
So the honest options were accept it blind, or find out whether it is reachable.
Reachability by Import Trace, Not by Name
The library is imported by one file in the framework's server bundle, a metadata-route build helper. The file's name suggests build time. I did not trust the name. I traced the imports from the production start command through the CLI to the server entry. Everything that loads from there comes to 42 modules. That file is not one of them.
One nuance. The CLI does statically import a module that reaches the helper, so the library does get loaded in the production process. Loaded, never called. That is not the same as unreachable and I wrote it down as the weaker claim.
The Load-Bearing Check, By Execution
The place an image-sizing library would actually matter is an image-optimization endpoint that takes a URL. That is where an attacker would put a crafted file. So I ran the production build and hit it.
A remote URL with a crafted extension: 400. A protocol-relative URL: 400. A path traversal toward the environment file: 400. A legitimate local image: 200, streamed unmodified.
Verified by running it against a live production build, not by reading. The endpoint refuses everything that would reach the vulnerable code. The app itself feeds it nothing: intake photos arrive as base64 in a JSON body and go straight to the inference provider, never decoded locally, never written to disk.
What Would Change This
Adding a metadata image to the app, an icon or a social-preview image, would run the build-time helper. Even then the exposure would be build time only. That is written next to the decision, so the next person who adds an icon knows what they are re-opening.
Deliberately not done: an image-host allowlist in the framework config. That would defend a path that does not exist here. Adding it would make the hardening pass look more thorough and make the config lie about what the app does.
The Other Direction
The same week, in a different repo, the audit tool's suggested fix for a HIGH advisory on a database driver was to install an older major version of the driver. I tried it and reverted it. The older version drags in an HTTP client with about ten HIGH advisories of its own. The audit count does not improve, and the driver goes back four years.
The live exposure was low. The driver is optional and only loads when something asks for it, and the vulnerable path is its installer, not its query path. So the advisory is carried, with the reasoning written into the roadmap: do not take the suggested fix, here is why, here is what would change the answer.
The same trade-off came up in a second repo with the same driver. It was turned down there too, on its own, and written down there too. That is the actual lesson. An advisory you have decided to carry needs a written reason, or every future hygiene pass will argue it again, including the automated ones, including the one that runs next week.
The Form
Is there an upgrade? If not, what is the reachable path from the production entry point, traced, not guessed from filenames? What input does the app actually feed it? Hit the endpoint that would matter, with the payloads that would matter, and record the status codes. Say what would change the answer. Do not add a defense for a path that is not there.
Then write it all down where the next audit will read it, because the next audit will not remember you did this, and the next audit is on Tuesday.
-- Justin Higgins. Software Engineer, Midwest. Traced the import closure, hit the endpoint, and refused the allowlist.
Companion pieces: Read It Cold - what a clone can actually do. Verify the Artifact, Not the Process - by request, not by assumption.
Reactions, disagreements, war stories: jchigg2000.dev@gmail.com