Manage projects

Learn how to manage your Endor Labs projects.

Packages are collections of generally related software functions, which are built in a repository.

A package generally may have any of the following:

  • Versions - A point in time in the software development lifecycle of a given package’s source code. Versions may be named and published versions as well as versions based on the version of the repository.
  • Dependencies - Other software package versions that a given software package depends on.
  • Dependents - Other software package versions that depend on one or more versions of a given software package.
  • Findings - A finding is a discovery of interest derived from an evaluation. Findings are default out-of-the-box implementation of rule sets. Policy for these rule sets is coming soon.
  • Scorecards - Scorecards are data sheets of facts that are used to derive Endor Labs scores. Scorecards are based on analysis that Endor Labs performs on open-source dependencies used in your packages.

This section provides a basic overview of managing projects and their packages.

Package dependencies and dependents

Package dependencies are versions of other software packages your software relies on to deliver its functionality. Inversely, dependents are those package versions that depend on a specific package that you’ve created in one of your projects.

Endor Labs builds a bill of materials for each of your package dependencies. Package dependencies and dependents may be direct or transitive:

  • Direct package dependencies are those package versions that are explicitly defined and imported into a package’s declaration file.
  • Transitive package dependencies are those package versions that are pulled into a package as a result of their use in a direct dependency.

Dependency Metadata

A dependency of a given package version has the following metadata associated with it directly in the table of dependencies:

  • Dependency Name and Version - The name and version of the dependencies your project or package relies on.

  • Type - If a dependency is directly imported as part of a package it will be of type “Direct”. If a dependency is imported through the import of one or more direct dependencies then the dependency will be of type “Transitive”.

  • Dependent Packages - In the context of a project, dependent packages are the number of packages created by the project that rely on your package.

  • Reachability - A dependencies reachability status may have three states:

    • Reachable - A dependency is flagged as reachable when a call graph of the dependency is able to reach the dependency as it traverses the function calls made by a package.
    • Unreachable - A dependency is flagged as unreachable when a call graph of the dependency is NOT able to reach the dependency as it traverses the function calls made by a package.
    • Potentially Reachable - A dependency is flagged as potentially reachable when call graph analysis is unsupported for a given language/package manager or has failed and is unable to determine if a dependency may or may not be reachable.
  • Visibility - If a dependency is publicly available for use it is flagged as public. Otherwise, if a dependency is from a private package it is flagged as private.

  • Source Available - If the source code is auditable and directly linked with the metadata of a package then the source code is flagged as available. For dependencies where source code is unavailable, an Endor Labs scorecard is not generated for the dependency.

  • Endor Labs Dependency Scorecard - Scorecards are data sheets of facts that are used to derive Endor Labs scores. Endor Labs creates a scorecard for the security, activity, popularity and quality of a software dependency.

In addition, if you click on a given dependency a drawer with additional data points is made available to users.

  1. Dependency Paths - Dependency Paths show how a given version of a dependency is imported into a package. This may be used to understand the effort to update a dependency and to get visibility into how deeply embedded a dependency is in your ecosystem.
  2. Dependency Specification - A dependency’s specification documents the request made for a given dependency when that dependency is directly imported into a package. This helps organizations to understand if that dependency is only a test and any metadata associated with the dependency’s import.

Dependent Metadata

A dependent of a given package version has the following metadata associated with it directly in the table of dependents.

  • Dependent Package Name - The name of a package that is dependent on the package you are reviewing or that is created within the context of the project you are reviewing.

  • Dependent Package Version - The version of a package that is dependent on the package you are reviewing or that is created within the context of the project you are reviewing.

  • Repository of dependent package - The location from which the package that depends on the package you are reviewing is being developed.

View package dependencies and dependents

To view the dependencies of your package:

  1. From the left sidebar, navigate to Projects.
  2. Search for and select a project to review
  3. Under Packages, you will see a list of all packages maintained as part of your project and any findings associated with them
  4. Click the package to view all dependencies and the scorecards of those dependencies

To view the dependents of your package:

  1. From the left sidebar, navigate to Projects.
  2. Search for and select a project to review
  3. Under Packages, you will see a list of all packages maintained as part of your project and any findings associated with them
  4. Select the package whose dependents you’d like to review
  5. Select Dependencies to see dependencies associated with your packages.

Dependents can be used to communicate with downstream users of your package version regarding any major modifications to your package.

View scorecards

Scorecards are data sheets of facts that are used to derive Endor Labs scores. Scorecards are based on analysis that Endor Labs performs on open-source dependencies used in your packages.

  1. From the left sidebar, navigate to Projects.
  2. Search for and select a project to review.
  3. Under Packages, you will see a list of all packages maintained as part of your project and any findings associated with them
  4. Select the package whose dependencies you’d like to review
  5. In the list view of dependencies you are presented with scores for Quality, Activity, Security and Popularity click on any of these scores to be presented with the scorecard for the dependency.

Scorecards show the results of the analysis from which Endor Labs scores are derived. Review the scorecard to learn more about your dependency. See also Understand Endor scores


Findings

Find and manage priority issues

View dashboards

Discover Endor Labs reporting dashboards.

Understand Endor scores

Understand how packages are scored in Endor Labs

Understand call graphs

Mitigate open source vulnerabilities with call graph visualizations, pinpointing and understanding the invocation of vulnerable methods for actionable developer insights.