Role required: User, Vulnerability Manager or User Manager
The Inherited section is designed to give you visibility into the dependencies used across all active repositories in a group, helping you monitor the status of these dependencies, regarding updates, security advisories and reachable vulnerabilities.
Views of Inherited
All packages
The All packages section within Inherited shows you all the third-party dependencies used across the code repositories of your group. This is the information provided by the table:
- Dependency: Name of the open-source component or dependency
- Root: The nickname your organization has given to the repository where the dependency is used (next to the root is the number of files within the root that contain, or correspond to, the dependency)
- Current version: Version of the dependency currently in use by your project
- Status: Indicates security-relevant status regarding the dependency version, where the following values are possible:
- Reachable: A vulnerable element of the dependency is effectively called by your application, thus generating a higher risk of the vulnerability being exploited in the context of your application.
- Vulnerable: Advisories have been issued for that dependency version.
- Outdated: A newer version of the dependency is available.
- Updated: The dependency is in its latest version.
- Malware: Malicious software was detected in that dependency version.
- % EPSS: The likelihood of the vulnerability being exploited compared to that of all other known vulnerabilities
- Latest version: The most recently released version of the dependency
- Last published: Time since the latest version was released
- Details: Link to the dependency details section
To see the specific location(s) of a given dependency, expand its row by clicking the arrow next to the Dependency column.
You can filter the dependencies by package manager, whether advisories have been identified for their version in use, and whether the latter is up to date.
Roots
The Roots section within Inherited helps you to identify potentially vulnerable packages per root.
This is the information provided by the table:
- URL: The repository URL
- Branch: The repository branch under assessment
- Nickname: The nickname your organization has given to the repository where the dependency is used
- Packages: A link to a section showing the package information for all the dependencies present in the repository
Note: The package information includes all the elements provided in the
All packages section.
Docker images
The Docker images section within Inherited helps you identify the third-party dependencies used in your container images. For a guide on adding Docker images to analyze their software supply chain security, read Manage Docker images.
This is the information provided by the table:
- URI: The unique identifier for the Docker image in a container registry
- Root nickname: The nickname your organization has given the Git repository to which the Docker image is associated
- Packages: A link to a section showing the package information for all the dependencies present in the container image
Note: The package information includes all the elements provided in the
All packages section.
Dependency details
In the All packages section, when you click on View details, you are taken to the selected third-party dependency's security details.
The table columns provide the following information:
- CPEs: The string following the Common Platform Enumeration (CPE) for identifying the dependency
- ID: The identifier for the vulnerability advisory or Common Vulnerabilities and Exposures (CVE) entry
- Namespace: Identifier indicating the supplier organization or project for the entry
- Severity: The qualitative severity rating according to the Common Vulnerability Scoring System (CVSS)
- Affected version: The versions which are affected by the vulnerability
- % EPSS: The likelihood of the vulnerability being exploited compared to that of all other known vulnerabilities
By expanding a row, you can see a description taken from the advisory source and reference URLs.
Supported package managers
Currently, supply chain analysis is supported for the following package managers:
- Alpine Package Keeper (apk)
- Pacman (Arch Linux and derivatives)
- Dart Pub (Dart)
- dpkg (Debian)
- NuGet (.NET)
- Hex (Elixir)
- APK (Android Package)
- Gradle (Java)
- Maven (Java)
- NPM (JavaScript)
- PNPM (JavaScript)
- YARN (JavaScript)
- PECL (PHP)
- Composer (PHP)
- Pipenv (Python)
- Poetry (Python)
- Pip (Python)
- RPM (Redhat)
- Bundler (Ruby)
- Cargo (Rust)
- Swift Package Manager (Swift)
- CocoaPods (Swift)
Supported Docker images
Currently, supply chain analysis is supported for the following Docker images:
- Distros based on Debian (Ubuntu, Debian)
- Distros based on Red Hat or Fedora
- Alpine Linux
- Arch Linux
Export SBOM
The inventory of open-source software in your project is available on the platform in two different formats: CycloneDX and SPDX. Each of these formats follow a standard to show dependencies, vulnerabilities and license information in an organized way.
You can easily export a software bill of materials (SBOM) for your dependencies following these steps:
-
Click on the Export SBOM button.
-
Select in which format you want to download the inventory of software dependencies: CycloneDX or SPDX.
-
Select the file type for your SBOM: JSON or XML.
-
Select the root(s) related to the project(s) of which you want to generate the SBOM. The window only shows the active roots.
- Click on Generate SBOM file.
- You then receive an email saying your SBOM is ready. Just go to the platform and click on Downloads to access the download option. If you chose more than one root, you receive a separate email for each root.
Note: The SBOM may take up to 5 minutes to be ready for download. Keep in mind that the information provided may vary depending on the standard. The file may include the package name, version, location, license and dependency tree, which shows the primary and transitive dependencies.
Free trial