Dependency Supplychain Check

Dependency & Supply-Chain Check

Directs the agent to enumerate every NuGet dependency (direct and transitive), surface known CVEs, flag supply-chain risks (floating versions, missing lock files, unguarded package sources), and produce a prioritized remediation list with the exact commands and config changes required.

When to use

• A PR adds, upgrades, or removes a NuGet package in any .NET project or solution.
• A periodic security audit requires a point-in-time vulnerability sweep across the dependency graph.
• CI is failing on a --locked-mode restore because the lock file is out of date or absent.
• A private Azure Artifacts feed is in use alongside nuget.org and no source mapping is configured (dependency-confusion risk).

Process

1. Enumerate all dependencies. Run dotnet list package --include-transitive on the solution or each project to capture the full dependency graph (direct + transitive). Note the SDK version and `` — some advisories are framework-specific.
2. Check for known vulnerabilities. Run dotnet list package --vulnerable --include-transitive. The CLI queries the GitHub Advisory Database (via NuGet's vulnerability metadata endpoint) and reports each vulnerable package, the affected version range, the advisory URL, and severity. Treat every High/Critical advisory as a blocker; Medium advisories require a documented risk-acceptance comment or a fix.
3. Check maintenance health. Run dotnet list package --deprecated to catch packages the NuGet gallery has marked deprecated (absorbed into another package, legacy, or has a known critical bug). Run dotnet list package --outdated to see how many major/minor versions behind each dependency is. Cross-reference heavily outdated packages against NuGet.org and the package's GitHub repo for commit activity — a package with no releases in 3+ years and no open-source maintainer is an abandonment risk.
4. Check supply-chain hygiene. Audit four areas in order: (a) version pinning — no floating * or open-ended >= version specs in .csproj or Directory.Packages.props; (b) lock file — packages.lock.json present and committed, RestoreLockedMode set in project or CI uses --locked-mode on dotnet restore; (c) package source mapping — nuget.config lists a ` section that maps every known package prefix to its authoritative feed, preventing a same-named private package from resolving from nuget.org (dependency confusion); (d) signed packages — nuget.config ` or the NuGet audit settings require package signing from trusted publishers for critical packages.
5. Output a prioritized remediation list. Group findings: Critical/High CVEs → must fix before merge; Deprecated/abandoned → fix in current sprint or log a ticket; Floating versions / no lock file → fix in this PR (no merge until hygiene is clean); Source mapping gaps → fix before next private-feed onboarding. For each finding, give the exact package name, current version, required action, and the command or config snippet to apply it.

.NET / Azure checks

• dotnet list package --vulnerable --include-transitive. Run against every project (or pass the .sln file). The output shows the direct or transitive package, the version in use, and the advisory severity and URL. A transitive vulnerable package requires either upgrading the direct dependency that pulls it in, or adding an explicit `` to the fixed transitive version as an override. Never ignore a High or Critical advisory without a written risk-acceptance entry in the PR description and a linked tracking issue.
• dotnet list package --deprecated and --outdated. Deprecated packages report the deprecation reason (Legacy, CriticalBugs, Other) and the recommended replacement. Outdated shows Current / Resolved / Latest columns — a package multiple major versions behind warrants a compatibility check before upgrading. Pay extra attention to packages owned by organisations that have changed hands or gone silent.
• Central Package Management (Directory.Packages.props). In multi-project solutions, all version numbers should live in a single Directory.Packages.props at the repo root and individual .csproj files use ` without a Version attribute. This eliminates version skew across projects and makes upgrades a single-file change. When CPM is in use, apply all floating-version and pinning checks to Directory.Packages.props (where entries live) — .csproj files under CPM carry bare with no Version attribute, so they are not the right place to look. Conversely, flag any .csproj that still carries its own Version` attribute when CPM is (or should be) in use, because that itself is a hygiene violation.
• No floating * versions. A ` or Version="13.*" in Directory.Packages.props (or a in a .csproj) resolves to whatever latest version exists at restore time, making builds non-reproducible and supply-chain attacks easier. Every version specifier must be an exact pinned version (e.g. Version="13.0.3"`).
• Lock files (packages.lock.json) and RestoreLockedMode. packages.lock.json (generated by dotnet restore --use-lock-file) records the complete resolved graph including transitive dependencies and their content hashes. Commit it to source control. In CI, pass --locked-mode to dotnet restore (or set true in the project / Directory.Build.props) so that any graph change that was not committed triggers a build failure rather than silently pulling a different package. This is the primary control against a "floating transitive" attack.
• Package source mapping in nuget.config. When a project uses both nuget.org and a private feed (Azure Artifacts, GitHub Packages, an internal Nexus), every package must be mapped to exactly one authoritative source. Without `, NuGet may resolve a private package name from nuget.org if an attacker publishes a higher-versioned package there (dependency confusion). Example of a correct nuget.config` mapping:

```xml

`` Private package prefixes (MyCompany.) must point exclusively at the private feed; the nuget.org catch-all ` must not match them.

• Signed-package validation. For critical infrastructure packages, add ` entries in nuget.config to require repository or author signatures from known publishers. At minimum, enable NuGet audit in Directory.Build.props: set true so that dotnet restore itself surfaces advisories without a separate dotnet list package step; set all to extend the audit scope to transitive packages (not just direct dependencies); set low (or high) to control the minimum severity that gets reported. Note that audit mode and level alone only produce warnings — to actually fail the build on vulnerabilities, promote the audit warning codes to errors via NU1901;NU1902;NU1903;NU1904 (or true) in Directory.Build.props`.
• Abandoned packages. A package with its last NuGet release more than 2–3 years ago, an archived or deleted GitHub repository, or one listed as unmaintained in its README carries long-term risk: CVEs will not be patched, and the package may disappear from the feed. For such packages, identify an actively maintained alternative or vendor the source.
• License compatibility. Review the licenses of new direct dependencies (and high-risk transitive ones) for compatibility with the project's own license and enterprise policy. GPL-licensed transitive dependencies can impose copyleft obligations on a commercial product. Tools such as dotnet-project-licenses or NuGet Package Manager audit screens can automate this. Flag GPL, AGPL, or "non-commercial only" licenses as requiring legal review.

Red flags

| Signal | Why it matters | |--------|----------------| | dotnet list package --vulnerable --include-transitive reports a High or Critical severity advisory | A known, exploitable CVE is present in the deployed dependency graph; the advisory URL contains PoC or exploitation context in most cases. | | ` in Directory.Packages.props or Version="" in .csproj | Floating versions make the build non-reproducible; a malicious publisher can push a higher version to the feed and have it silently picked up on the next restore. | | packages.lock.json absent or not committed to source control | The full resolved graph is never validated; transitive dependencies can change between restores without any record or alert. | | dotnet restore in CI without --locked-mode (and no RestoreLockedMode in the project) | CI pulls whatever the registry serves today; a supply-chain compromise or accidental version bump is invisible until runtime. | | Private Azure Artifacts feed in nuget.config with no section | Any MyCompany. package can be shadow-published to nuget.org at a higher version and will be preferred by NuGet's version resolution (dependency-confusion attack). | | dotnet list package --deprecated reports a CriticalBugs deprecation reason | The NuGet gallery owner has flagged the package as having a known critical defect; the fix is the named replacement package, not a version pin. | | A key dependency (e.g. a serializer, crypto library, or JWT library) with no NuGet release in 3+ years and an archived GitHub repo | Unmaintained packages accumulate unpatched CVEs; no patch will be forthcoming. Replace or vendor the dependency. | | All packages resolve from nuget.org only — no source mapping — but the team uses an internal feed for Internal.*` packages | Indicates source mapping was never configured; any internal package name can be hijacked on nuget.org. |

Example

See [examples/dependency-supplychain-check/](../../examples/dependency-supplychain-check/).

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: tunahanaliozturk
• Source: tunahanaliozturk/secure-dotnet-skills
• License: MIT

Install and usage instructions live in the source repository linked above.