Analyze your supply chain security

The Packages section within Inventory 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 Packages

Packages

The Packages section 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
• Repository: The nickname your organization has given to the repository where the dependency is used
• Version status: Indicates the version of the dependency currently in use by your project plus 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 the 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, in which case the column shows the suggested upgrade.
• Updated: The dependency is in its latest version.
• Malware: Malicious software was detected in that dependency version.
• Vulnerabilities: The number of detected vulnerabilities of each CVSS qualitative severity rating
• License: The license of the software package, like ISC or MIT, which defines how your project can legally use its code
• Last publish: Time since the latest version was released
• Locations: The number of files within the repo that contain, or correspond to, the dependency

You can click on the columns button (

) to open a window where you can reorder, show or hide columns.

You can filter the dependencies by variables that are visible in the table as well as the following: the Docker images containing them, the package manager used, and the stage in which your project depends on the third-party dependencies.

Filter dependencies

Apply filter by ‘Version status’

Package Imports

In the Packages section, when you click on the links in the Locations column, you are taken to a table showing information of your files related to the selected third-party dependency.

Use of the direct dependency in the production stage

Use of the transitive dependency in the development and production stages

The table columns provide the following information:

1. Transitivity: Whether the listed vulnerable files in your software are directly or indirectly related to the third-party component in question:
2. D: Short for ‘Direct’; the file in your project explicitly imports and uses the third-party dependency
3. T: Short for ‘Transitive’; the third-party dependency is required by your direct dependencies, but not directly imported by the file in your project
4. U: Short for ‘Undeterminable’; for this file, it is impossible to determine whether the dependency is direct or transitive
5. Locations: The file related to the third-party dependency
6. Specific: The exact line of code that shows the relation with the third-party dependency stated in Transitivity
7. Stage: The stage(s) in which your project depends on the third-party dependency:
8. Build: Your file depends on the third-party component only in the software development stage
9. Run: Your file depends on the third-party component in the live production environment
10. Vulnerabilities associated: The number of vulnerabilities related to the third-party dependency

By clicking on the code branch icon next to the T in each of your transitive dependencies, you will find the dependency path that goes from the direct to the affected transitive dependency in question (“grunt-if” and “y18n,” respectively, in the following example image):

Example of a dependency path

By clicking on the vulnerabilities associated link, you get a pop-up window with the vulnerability details:

1. Vulnerability: The file path where the vulnerability is found
2. Specific: The exact line of code that shows the relation with the third-party dependency stated before in Transitivity
3. Advisory ID: The identifier for the vulnerability advisory or Common Vulnerabilities and Exposures  (CVE) entry
4. Affected version: The dependency versions which are affected by the vulnerability
5. Severity: The qualitative severity rating according to the Common Vulnerability Scoring System (CVSS )
6. Reported: The link to the reported vulnerability on the platform

If you click on the downward-facing arrow, 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:

1. Alpine Package Keeper (apk)
2. APK (Android Package)
3. Bundler (Ruby)
4. Cargo (Rust)
5. CocoaPods (Swift)
6. Composer (PHP)
7. Dart Pub (Dart)
8. dpkg (Debian)
9. Gradle (Java)
10. Hex (Elixir)
11. Maven (Java)
12. NPM (JavaScript)
13. NuGet (.NET)
14. Pacman (Arch Linux and derivatives)
15. PECL (PHP)
16. Pip (Python)
17. Pipenv (Python)
18. PNPM (JavaScript)
19. Poetry (Python)
20. RPM (Redhat)
21. Swift Package Manager (Swift)
22. YARN (JavaScript)

Supported Docker images

Currently, supply chain analysis is supported for the following Docker images:

1. Alpine Linux
2. Arch Linux
3. Distros based on Debian (Ubuntu, Debian)
4. Distros based on Red Hat or Fedora

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:

1. Within your group, navigate to Inventory > Packages.

2. Click on the Export SBOM button.

   

3. Select whether you want an SBOM for packages in your Git repository or Docker images.

   

4. Select in which format you want to download the inventory of software dependencies: CycloneDX or SPDX.

   

5. Select the file type for your SBOM: JSON or XML.

   

6. Select the resources (repos or Docker images) related to the project(s) of which you want to generate the SBOM. The window only shows active resources.

   

7. Click on Generate.

8. 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.