Deps.dev already supports npm, Go, Maven, PyPI, Cargo and we’re excited to add support for NuGet as another major open source ecosystem. As software supply chain attacks continue to increase in number and in complexity, it’s becoming more important than ever to understand the software that we depend on. We hope that more developers will be able to gain insight into their dependencies through our NuGet support.
NuGet is our first supported ecosystem to feature dependency requirement data instead of dependency graphs.
Requirements are the link between a package and its dependency graph. In NuGet,
requirements are specified by including a
.nuspec or a
tag in the
These requirements are read by the NuGet resolver and resolved into a dependency graph. For example, the requirements above would resolve into the following graph.
In the case of NuGet, it’s possible to specify requirements for specific target frameworks.
Requirements are usually interpreted within the rules of semantic versioning (semver), but the semver standard only covers version numbers. It doesn’t go into how requirements should be specified. So for each ecosystem there are different requirement operators and rules for requirement interpretation. For NuGet, there is official documentation on requirement rules and resolution. You can find a brief comparison of requirement specification rules across ecosystems in our glossary.
Since requirements determine the allowable dependency graphs, some interesting analysis can be done on how and why dependency graphs change. For example, it might be interesting to know whether a package would automatically pick a recently released version of a package for its dependency graph. Requirements can be used to determine this. Knowing whether a package would automatically pick up a new version of an existing dependency is particularly useful when we think about remediating vulnerabilities introduced by transitive dependencies.
Where does the data come from?
The main source of data is the
.nuspec file of the package itself, which is
available from the NuGet
We also use the
NuGet Search API
for version metadata fields not available in the
We’d like to thank the NuGet team for helping us develop support for NuGet on deps.dev. Each time we develop support for a new ecosystem we discover interesting differences across ecosystems that require us to expand our backend data model and infrastructure. It was great having the official maintainers lend a hand in helping us understand the NuGet ecosystem.
What are some ways in which I can use the data?
The data that’s available:
- Requirements: The
has been added to the UI, the
GetRequirementsendpoint has been added to the API and the
NuGetRequirementstable has been added to the BigQuery dataset.
- Hashes: You can use the
QueryAPI endpoint to query for the name of a mystery NuGet package by using its hash.
- Advisories: You can check whether a NuGet package version is directly affected by an advisory, and if so, whether there is an unaffected version you could use.
- Version metadata: Finally, there’s metadata like licenses, publish dates, descriptions, owners and reference links.
We’re hoping to improve our license support for NuGet, as NuGet allows multiple ways to specify a package’s license.
We’re also planning on adding requirement information for other ecosystems.
We’d love to hear what you think about our NuGet support. As mentioned earlier, NuGet is our first ecosystem to feature requirements, so we’re interested in hearing about your experiences (both good and bad) working with this new kind of data. Get in touch via email at firstname.lastname@example.org or file an issue to our GitHub repository.