Features

Below you can find a list of features that dependency-management-data supports.

Tooling

dependency-management-data produces three key tools to use:

• dmd: manage the creation of the database, ingesting of Datasources, enriching with data such as Advisories or Policies. Also allows reporting on the data available.
  • Intended to be interacted with by automation on a regular cadence to re-import dependencies, re-enrich data and then publish the SQLite database for use by other tooling
  • Intended to be interacted with by a human when they're exploring the data, or want to run reports on a local copy of the data
• dmd-web: a web frontend for dependency-management-data, providing access to the reports, as well as the GraphQL API. Includes the GraphQL API for consumption by other systems.
  • Intended to be interacted with by humans, could be behind your VPN/internal network where it is unauthenticated, or available on the public Internet but behind an authenticating reverse proxy like oauth2-proxy
• dmd-graph: only the GraphQL API, useful for integrating dependency-management-data into other systems without directly querying the database.
  • Intended to be interacted with automation, generally behind your VPN/internal network, optionally with authentication.

Feature

A directory of the features that dependency-management-data supports across different datasources.

SQL database

The most important result of the use of dependency-management-data is the resulting SQLite database, which can then be used by any other tooling, or interacted with over the GraphQL API.

The full database schema is documented to make it easier to understand what the columns indicate, and there is a cookbook for understanding the data model to provide more insight into how to get started with the data.

It may be worth reading the design decisions.

Advisories

You can use dependency-management-data to get more insight into your dependencies using Advisories, which indicates where dependencies are in use that maybe they shouldn't be.

When generating advisories, a number of data sources are used to discover dependency insights:

• EndOfLife.date (https://endoflife.date)
• deps.dev (https://deps.dev)

Additionally, if you use Dependency Health insights, this will also create Advisories.

End-of-Life checking

When performing End-of-Life checking for programming languages or popular packages that have a defined support window, via endoflife.date, the following lookups are currently supported:

Is there a product that EndOfLife.date supports that is missing? Drop a comment into the evergreen tracking issue or raise a fresh issue on the issue tracker to request it.

CVE + license checking

When performing Advisory checks, dependency-management-data uses deps.dev to look up any known CVEs for packages as well as information about the license, if it can be detected.

Is there an ecosystem that deps.dev supports that is missing? Drop a comment into the evergreen tracking issue or raise a fresh issue on the issue tracker to request it.

Reports

Reports are available through the command-line application, dmd, as well as when running the dmd-web web frontend.

The following datasources are supported for each of the reports:

Generating missing package data

In some cases, you may be using a datasource that doesn't always provide all the data about your full dependency tree, and so want to pick up on any data that may not be present.

To do this, you can discover that missing data using deps.dev.

Note that there are cases where this may not directly line up with the version in use in your project, as noted in blog One set of requirements, zillions of SBOMs by the Open Source Insights team.

The following package ecosystems are supported:

Policy violations via Open Policy Agent

As well as generating Advisories through external sources, as well as writing your own custom Advisories, you can use Open Policy Agent's Policy Language, Rego to write much more complex advisories, also called Policies.

Full details of supported data that can be used with policy management can be found in the Turning complex policies into custom Advisories using Open Policy Agent cookbook.

Dependency Health insights

It is possible to generate insights into your dependencies' health to gain additional information and data around your use of specific dependencies.

This consumes data from different sources to augment the understanding of dependencies in use, for instance giving an indication of whether they are (well) maintained, have been recently released, or may have supply chain hygiene issues.

Currently, this data is derived from:

• OpenSSF Security Scorecards (https://api.securityscorecards.dev/)
• Ecosystems (https://ecosyste.ms)

This data is a best-efforts attempt to provide this insight, and may be stale at the time of fetching.

Known issues:

• Performance issues and 500s upstream

Libyear calculations

It is possible to generate insights into dependencies' libyear metrics to gain additional information and data around the age of your dependencies.

This uses the Libyear metric, which is defined as "how many years between the version we're currently using and the latest version released", and then totalled across all libraries used by the project.

NOTE: that this may not include all dependencies, so the number could be higher than shown.

For further reading on the Libyear metric, check out https://libyear.com/ and https://chaoss.community/kb/metric-libyears/ for more information.

Known issues:

• Performance issues and 500s upstream

Ownership

It is possible to store ownership information for the given Repository Key, allowing you to ask questions like "which team should I get in touch with about this unmaintained dependency".

For more information, check out the cookbook for using repository ownership information and the following Case Studies:

• Elastic and understanding the spread of versions of `oapi-codegen`
• Deliveroo and a potential race condition with a Kafka sidecar
• Responding to the Log4shell incident

Repository metadata

In addition to storing ownership information, it is also possible to to store additional metadata around a source repository, such as whether it's a monorepo, or how critical it is to the business.

For more information, check out the following Case Studies:

• Deliveroo and a potential race condition with a Kafka sidecar
• Responding to the Log4shell incident