End-of-life impact report

What is the end-of-life impact report?

The end-of-life impact report allows a user to analyze any of their catalogs in-use package versions for possible end-of-life data and insights. This report will provide both our raw data on release and version end-of-life along with a host of meta-data that allows users to evaluate and measure the scope and impact of releases in question.

What questions does the report answer?

The end-of-life impact report will allow users to answer the following questions:

  • How up-to-date are the versions in use within my projects?
  • What CVEs exist on end-of-life versions and the parent package? 
  • How many versions behind are the end-of-life versions currently being used?
  • How many days out-of-date from the next supported version is the end-of-life version currently being used?
  • Which projects of mine contain these end-of-life versions?

How can I generate the end-of-life impact report?

There are two ways to generate this report. First, by navigating to the reports page, selecting a specific catalog, and selecting “generate report”.

Second, by using our reports API to “run a report” contains the same information as what a user can generate from within the UI.

How do we source the data for the end-of-life impact report?

The data for the end-of-life impact report is curated and researched from a number of different sources. The specific release-level data (Release_is_not_eol), is a calculation based on the most recently supported version and any maintenance plan indicated by the maintainer. If a maintenance plan is present, then we generate end-of-life data for all versions that fall outside of the stated maintenance plan. If a plan is not present, we look at the most recent major version and minor version and generate end-of-life for versions falling outside of that range. In most cases, we recommend users focus on the oldest versions in use which contain vulnerabilities as the first priority.

How is the data updated?

The data is refreshed and reviewed, both automated and manually (as needed), every 24 hours to ensure we have the latest and most accurate data.

This report contains the following data fields:

  • Purl: The package URL for the package.
  • Platform: The platform for the package.
  • Package_name: The name of the package.
  • Version_in_use: The version in use within the catalog.
  • Latest_stable_version: The nearest stable (supported) version relative to the version in use.
  • Days_out: The number of days from the release date of the in-use version to the next supported/stable version.
  • Versions_out: The number of major and minor versions away from the next stable and supported version.
  • Release_is_not_eol: Indicates if the release passes or fails our end-of-life check
  • Release_is_not_eol_explanation: A short explanation about the “Release_is_not_eol” field.
  • Maintenance_plan: Shown if a maintainer maintenance plan is present.
  • Package_is_not_eol: Indicates if the parent package is past its end-of-life date, making all versions ebd-of-life by default.
  • Package_is_not_eol_explanation: An explanation of the “Package_is_not_eol” field.
  • Package_eol_effective_on: The date when the package was marked end-of-life.
  • Package_vuln_count: The number of vulnerabilities summed for all versions of this package.
  • Release_vuln_count: The number of vulnerabilities present on the exact version in use.
  • Direct: A boolean value indicated if this version is used as a direct dependency within the given catalog.
  • Project_count: The number of projects within this catalog that use this exact version.
  • Project_names: The names of the projects that use this exact version.
  • Report_date: The date this report was created.


Was this article helpful?
0 out of 0 found this helpful



Article is closed for comments.

Articles in this section