All projects violations report

Prioritize developer actions with a list of standards violations and available actions to take across all projects.

This report can help managers answer the following questions:

  • What violations exist in my team’s projects?
  • What are the patterns of risk associated with higher-level dependencies, and how can I use this information to guide developers effectively?
  • What are some specific upgrades developers can perform to remove multiple violations?

 

This report contains the following columns:

  • project: Project name.
  • external_identifier: The optional external identifier set on this project.
  • catalog: Catalog name.
  • groups: A comma separated list of Groups this project belongs to.
  • violation_type: The standard being violated.
  • platform: The platform for the affected package.
  • direct_package: The name of the package bringing the violating release into your project.
  • direct_version: The version of the package bringing the violating release into your project.
  • direct_version_published_at: The date and time the direct version was published to the Internet
  • direct_version_is_unknown: TRUE if the package is an internally-developed, or unknown, package
  • direct_purl: A purl representing the release bringing the violating release into your project.
  • violating_package: The name of the package causing the violation
  • violating_version: The version of the package causing the violation
  • violation_version_published_at: The date and time the violating version was published to the Internet
  • violating_purl: A purl representing the release causing the violation
  • violation_first_introduced_at: The date and time the violation first appeared for a project in the Catalog
  • dependency_chain: The chain of releases leading up to the violating release. The first node is the direct dependency and the last node is the dependency causing the violation.
  • dependency_scope: The scope as defined in your manifest. This can vary by package manager, but it is often things like “runtime” or “test”.
  • dependency_type: How the dependency is brought into your application, either "direct" in your manifest file, or "transitive", a dependency of a dependency
  • action: (beta) The suggested dependency chain which will remove this violation from your project along with a text-based representation of the action to take. If there is no action detected, the report will state that.

    This column is built from the following additional columns:
    • action_status: The type of suggested action to take:
      • direct_upgrade: A dependency listed in your manifest file needs to be upgraded.
      • transitive_upgrade: A dependency of a dependency can be upgraded. Read more about upgrading transitive dependencies.
      • no_upgrade_path: Tidelift could not calculate a way to remove this violation.
    • action_recommendation: The text-based representation of the action you can take to remove this violation from your project.
    • recommended_dependency_chain: The path from direct to non-violating package/version that will remove this violation from your project.
  • violation_description: Description of the violation.
  • violation_allowed: Boolean indicating whether the violation is allowed in your catalog, either by the standard configuration or by an override.
  • violation_link: A URL to the violation information (only available for Vulnerabilities violations)
  • lifter_recommendation: The recommendation provided by the maintainer exclusively for Tidelift subscribers
  • report_date: When this report was generated

The JSON version of this report includes an additional column: violation details

  • violation_details: More detailed information about why Tidelift decided to mark a package and version as violating. The contents depend on the violation_type.
    • When a violation_type is a vulnerability: CVE id, severity rating, description, date, and the url for more details is included
    • When a violation_type is a disallowed license: the name of the license (MIT, etc)
    • When a violation_type is a deprecation: details about the reason, and any available alternative package is included
    • When a violation_type is that a package is declared End of Life: reference urls, effective date of EOL status, package renaming status, and confirmation that no maintenance is planned is returned
    • When a violation_type is a that the release in use is not recommended: the latest stable release is included
  • The JSON report also includes the release date of the violating release

 

 

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

Comments

0 comments

Article is closed for comments.

Articles in this section