-
Software distribution method or binary type: .NET local tool manifests (.config/dotnet-tools.json)
-
Any critical, emergent vulnerability associated with software from the distribution method: None
-
Popularity of distribution method: Local tools have been the standard way to pin per-repository .NET CLI tooling since .NET Core 3.0. The manifest is created with dotnet new tool-manifest, restored with dotnet tool restore, and is committed to source control by design, so it is reliably present on scanned filesystems and in container images. The tools it lists are ordinary NuGet packages (e.g. dotnet-ef, csharpier, dotnet-format, gitversion.tool, dotnet-reportgenerator-globaltool, husky) pinned at exact versions, so they can be matched directly against the NuGet OSV ecosystem already used by OSV-SCALIBR's existing dotnet extractors (dotnet/depsjson, dotnet/packageslockjson, dotnet/projectassetsjson, ...). Exact-version pins make this a high-signal source: no version-range resolution is needed.
-
Resources:
An example of a .config/dotnet-tools.json file:
{
"version": 1,
"isRoot": true,
"tools": {
"dotnet-ef": {
"version": "10.0.9",
"commands": ["dotnet-ef"]
},
"csharpier": {
"version": "1.3.0",
"commands": ["dotnet-csharpier"],
"rollForward": false
},
"gitversion.tool": {
"version": "6.7.0",
"commands": ["dotnet-gitversion"]
}
}
}The proposed extractor (e.g. dotnet/dotnettools) would emit one package per entry in the tools map — the key is the NuGet package ID and version is the exact pinned version — mapped to the NuGet PURL type and OSV ecosystem.
Software distribution method or binary type: .NET local tool manifests (
.config/dotnet-tools.json)Any critical, emergent vulnerability associated with software from the distribution method:
NonePopularity of distribution method: Local tools have been the standard way to pin per-repository .NET CLI tooling since .NET Core 3.0. The manifest is created with
dotnet new tool-manifest, restored withdotnet tool restore, and is committed to source control by design, so it is reliably present on scanned filesystems and in container images. The tools it lists are ordinary NuGet packages (e.g.dotnet-ef,csharpier,dotnet-format,gitversion.tool,dotnet-reportgenerator-globaltool,husky) pinned at exact versions, so they can be matched directly against the NuGet OSV ecosystem already used by OSV-SCALIBR's existing dotnet extractors (dotnet/depsjson,dotnet/packageslockjson,dotnet/projectassetsjson, ...). Exact-version pins make this a high-signal source: no version-range resolution is needed.Resources:
An example of a
.config/dotnet-tools.jsonfile:{ "version": 1, "isRoot": true, "tools": { "dotnet-ef": { "version": "10.0.9", "commands": ["dotnet-ef"] }, "csharpier": { "version": "1.3.0", "commands": ["dotnet-csharpier"], "rollForward": false }, "gitversion.tool": { "version": "6.7.0", "commands": ["dotnet-gitversion"] } } }The proposed extractor (e.g.
dotnet/dotnettools) would emit one package per entry in thetoolsmap — the key is the NuGet package ID andversionis the exact pinned version — mapped to the NuGet PURL type and OSV ecosystem.