T08 · Insecure Dependencies
- Location
SKILL.md:32- Finding
Floating NuGet Versions Create Supply-Chain Risk
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 32–34
Vulnerability Type: Floating third-party dependency versions
Risk Level: Mediumxml <PackageReference Include="NUnit" Version="4.*" /> <PackageReference Include="NUnit3TestAdapter" Version="4.*" /> <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.*" />Technical Analysis
The recommended project configuration uses wildcard NuGet versions rather than exact, reviewed versions. Consequently, separate restores of the same project can resolve to different package releases without any source-code change.
These packages participate in test discovery, build integration, and test execution. If a future matching release is compromised, malicious, or incompatible, its components may be restored and loaded automatically by developer workstations or CI systems. This undermines reproducible builds and weakens dependency provenance controls.
The audit found no evidence that the named packages are currently malicious. The risk arises from the unsafe floating-version configuration and its exposure to future package changes.
Attack Path
- An attacker compromises the publishing account or distribution channel for a referenced package, or otherwise causes a malicious matching release to become available from a configured NuGet source.
- The attacker publishes a version satisfying
4.*or17.*. - A developer or CI runner follows the documented setup and performs package restore, build, or
dotnet test. - NuGet resolves the floating reference to the new release when permitted by source priority and cache state.
- Package-controlled build or test components are loaded or executed under the developer or CI runner account.
This path depends on compromise or manipulation of a configured package source; the wildcard alone does not establish such access.
Impact Assessment
Successful exploitation could execute code with the permissions of the restoring, building, o ...[truncated 458 chars]
- Remediation
View remediation
Remediation Suggestions
- Replace wildcard versions with exact, reviewed package versions.
- Generate and commit
packages.lock.json. - Enable locked restore mode in CI so unexpected dependency changes fail the build.
- Restrict NuGet to explicitly trusted sources through a committed
NuGet.config. - Use package source mapping where multiple feeds are necessary.
- Review dependency updates through controlled pull requests and automated vulnerability scanning.
- Pin or otherwise verify the .NET SDK and CI environment to improve build reproducibility.
- Run test jobs with least privilege and avoid exposing unrelated secrets to them.
A hardened configuration should resemble:
xml <ItemGroup> <PackageReference Include="NUnit" Version="REVIEWED_EXACT_VERSION" /> <PackageReference Include="NUnit3TestAdapter" Version="REVIEWED_EXACT_VERSION" /> <PackageReference Include="Microsoft.NET.Test.Sdk" Version="REVIEWED_EXACT_VERSION" /> </ItemGroup>The placeholders should be replaced with exact versions validated by the project maintainers.
