Dependency Vulnerabilities

Count the code in the orders application. A few tens of thousands of lines you wrote, and several hundred packages you did not — the web framework, the data access library, the JSON serialiser, the logging pipeline, the front-end build toolchain, and everything each of those depends on in turn.

All of it runs with your application's privileges. A weakness in a package you have never opened is a weakness in your application, and it arrives without a commit, a review or a deployment on your side: an advisory is published and the code you shipped last month is now known to be vulnerable.

That is why this is the module's first lesson rather than a footnote. Most of what a security review finds in a mature codebase is not a flaw the team wrote. It came in through the dependency tree, and the work is not clever analysis — it is knowing what you depend on, checking it regularly, and being able to update without drama.

This lesson assumes you have added a NuGet or npm package before, and can read a project file. The commands are the .NET and Node ones; the reasoning applies to any package manager.

# Packages with published advisories, including ones you never chose.
# Leaving off --include-transitive is the most common reason this looks clean.
dotnet list package --vulnerable --include-transitive

# Behind the latest version. A different question: outdated is not vulnerable.
dotnet list package --outdated

# Anything no longer maintained by its author, which is a slower-moving risk.
dotnet list package --deprecated

# Front end. --omit=dev narrows it to what ships, though a compromised
# build-time package still runs on your build agent.
npm audit
npm audit --omit=dev

# Reproducible restores: install exactly what the lock file records, and fail
# if the manifest disagrees with it rather than quietly resolving something new.
npm ci
dotnet restore --locked-mode

• The --include-transitive flag is the important one. Without it you see only the packages named in your project files, which is a small fraction of what you ship, and the report comes back reassuringly empty.
• The vulnerable listing is a comparison against advisory data, so the answer depends on when you ask. A clean result from last month means nothing today. That is the argument for running it in the pipeline on a schedule, not only when someone thinks of it.
• Outdated and vulnerable are separate reports because they are separate decisions. A package four minor versions behind with no advisory is technical debt you can plan; one with an advisory is work with a clock on it. Conflating them produces either constant churn or a backlog nobody reads.
• The deprecated listing is worth a monthly glance. A package whose author has stopped maintaining it will not be fixed when an advisory does arrive, so finding a replacement is better done calmly than under pressure.
• npm audit reports severity from the advisory's own point of view, not yours. A high-severity finding in a package used only by your test runner is not the same as the same finding in your request pipeline. Read what the package does before reacting to the colour.
• npm ci and restore --locked-mode make the build reproducible: the same inputs every time, and a loud failure when the lock file and the manifest have drifted apart. The .NET side needs RestorePackagesWithLockFile enabled in the project first, otherwise there is no lock file to enforce.
• Add an SBOM step if you have anywhere to put it. A software bill of materials is a machine-readable list of what an artefact contains, and its value is on the day an advisory lands: you can answer which builds are affected in minutes rather than by checking out old tags.

Transitive dependencies are the difficult half of this, for a simple reason: you cannot upgrade what you do not reference. The report names a package three levels down, and there is no line in your project file to change.

The first move is to upgrade the parent. If the package that pulled in the vulnerable version has a newer release that depends on a fixed version, one change to a direct dependency resolves the finding properly, and the dependency graph stays consistent.

When no such release exists, the fallback is to add a direct reference to the patched version yourself. In .NET, a direct reference wins over a transitive one, so naming the fixed version in your project file lifts it for everything. It works, and it is an override: you now have a package in your project file that your code never uses, holding a version its parent was not tested against. Comment the line with the advisory it addresses and a note to remove it once the parent catches up, because otherwise it becomes a permanent mystery.

Central package management makes both moves less painful. One file at the root of the solution declares the version for every package, and every project uses it. Instead of the same override edited in nine project files and missed in the tenth, there is one place to change and one place to read.

The honest caveat: not every finding can be fixed the week it appears. Sometimes the parent is abandoned, sometimes the fixed version needs a framework upgrade you cannot schedule yet. In that case, record the decision — the advisory, why it cannot be fixed now, whether your application reaches the affected code path, what compensating control is in place, and a date to look again. A documented accepted risk with a review date is a reasonable engineering position. An ignored report is not, and the difference is entirely in whether anyone wrote it down.