Supply chain analysis

Last updated: Oct 26, 2026

The Packages section in Inventory shows the dependencies used in all the active repositories of a group. With this section, you can monitor the status of these dependencies: updates, security advisories and reachable vulnerabilities.

Views of Packages

Packages

The Packages section shows all the third-party dependencies used in the code repositories of your group. The table shows this information:

• Dependency: The name of the open-source component or dependency
• Repository: The nickname that your organization gave to the repository that uses the dependency
• Vulnerabilities: The number of detected vulnerabilities of each CVSS qualitative severity rating
• Locations: The number of files in the repository that contain, or are related to, the dependency

  Click on the link to enter the Package Imports section.

Click the columns button () to open a window. In this window, you can reorder, show or hide columns.

You can filter the dependencies by the values that the table shows. You can also filter them by the Docker images that contain them, the ecosystem, and the stage in which your project depends on the third-party dependencies.

Filter dependencies

For example, apply filter by 'Ecosystem'

Package Imports

In the Packages section, when you click the links in the Locations column, the platform opens a table. This table shows information about 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 show this information:

• Transitivity: Shows if the listed vulnerable files in your software are directly or indirectly related to the third-party component:
  • D: Short for 'Direct'. The file in your project explicitly imports and uses the third-party dependency
  • T: Short for 'Transitive'. Your direct dependencies use the third-party dependency, but the file in your project does not import it directly
  • U: Short for 'Undeterminable'. For this file, it is not possible to know if the dependency is direct or transitive
• Locations: 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 Transitivity
• Stage: 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
• Vulnerabilities associated: The number of vulnerabilities related to the third-party dependency

Click the code branch icon next to the T of a transitive dependency. The platform shows the dependency path from the direct dependency to the affected transitive dependency. In this example image, the direct dependency is "grunt-if" and the transitive dependency is "y18n":

Click the link in the Vulnerabilities associated column. A pop-up window shows the vulnerability details:

• Vulnerability: The file path where Fluid Attacks found the vulnerability
• Specific: The exact line of code that shows the relation with the third-party dependency in the Transitivity column
• Advisory ID: The identifier for the vulnerability advisory or Common Vulnerabilities and Exposures (CVE) entry
• Affected version: The dependency versions that the vulnerability affects
• Severity: The qualitative severity rating according to the Common Vulnerability Scoring System (CVSS)
• Reported: The link to the reported vulnerability on the platform

How vulnerabilities are counted in monorepos

Fluid Attacks reads the root lockfile to build the dependency graph. It reports each CVE once per repository, for any number of workspaces or modules that use the affected dependency.

Fluid Attacks thinks that this approach is correct for three reasons:

• One lockfile, one problem. In a monorepo with a shared lockfile, there is a single installed copy of each dependency. Thus, one vulnerable copy is one vulnerability, not N.

• One finding, one fix. To remediate a vulnerable dependency, you always update the root lockfile one time. If a tool reports the same CVE for each workspace, the count increases but the remediation work does not change.

• Accurate prioritization. Your finding count shows the different vulnerabilities, not the number of workspaces that use them. This gives you a clearer view of the real exposure.

Supported package managers

The Packages section detects dependencies with the same package managers and OS-level package formats that Fluid Attacks' software composition analysis covers. This includes the dependencies in Docker images. For the full, up-to-date list of supported package managers, minimum versions, and analyzed files, read Package managers.

Export SBOM

The inventory of open-source software in your project is available on the platform in two formats: CycloneDX and SPDX. Each format follows a standard to show dependencies and vulnerabilities in an organized way.

To export a software bill of materials (SBOM) for your dependencies, follow these steps:

1. In your group, go to Inventory > Packages.

2. Click the Export SBOM button.

   

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

   

4. Select the format of the inventory of software dependencies that you want to download: 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) that you want to generate the SBOM for. The window only shows active resources.

   

7. Click Generate.

8. You then receive an email that tells you that your SBOM is ready. Go to the platform. Then, click Downloads to see the download option. If you selected more than one repository, you receive a different email for each one.