Role required: User, Vulnerability Manager or Group Manager
The Packages section within Surface 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
All packages
The All packages section within Packages 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 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.
- 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 Packages 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 Packages 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 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 development stages only
The table columns provide the following information:
- Type: Whether the listed vulnerable files in your software are directly or indirectly related to the third-party component in question:
- D: Short for 'Direct'; the file in your project explicitly imports and uses the third-party dependency
- T: Short for 'Transitive'; the third-party dependency is required by your direct dependencies, but not directly imported by the file in your project
- ?: For this file, it is impossible to determine whether the dependency is direct or transitive
- Location: The file related to the third-party dependency
- Specific: The exact line of code that shows the relation with the third-party dependency stated in Type
- Environment: The stage(s) in which your project depends on the third-party dependency:
- Build: Your file depends on the third-party component only in the software development stage
- Run: Your file depends on the third-party component in the live production environment
- 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
- % EPSS: The likelihood of the vulnerability being exploited compared to that of all other known vulnerabilities
- Severity: The qualitative severity rating according to the Common Vulnerability Scoring System (CVSS)
- Affected version: The versions which are affected by the vulnerability
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)
- APK (Android Package)
- Bundler (Ruby)
- Cargo (Rust)
- CocoaPods (Swift)
- Composer (PHP)
- Dart Pub (Dart)
- dpkg (Debian)
- Gradle (Java)
- Hex (Elixir)
- Maven (Java)
- NPM (JavaScript)
- NuGet (.NET)
- Pacman (Arch Linux and derivatives)
- PECL (PHP)
- Pip (Python)
- Pipenv (Python)
- PNPM (JavaScript)
- Poetry (Python)
- RPM (Redhat)
- Swift Package Manager (Swift)
- YARN (JavaScript)
Supported Docker images
Currently, supply chain analysis is supported for the following Docker images:
- Alpine Linux
- Arch Linux
- Distros based on Debian (Ubuntu, Debian)
- 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:
-
Within your group, navigate to Surface > Packages > All packages.
-
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