Add Packager and Location fields for container scanning components in group dependency list
Problem to solve
When exporting dependencies, packages that come from the container scanning dependencies do not show location information. Today, the exporter still only supports dependencies generated by the dependency scanner, so the schema for location assumes fields that aren't compatible with container scanning locations. See &10904 (comment 1487173047) for example.
Proposal
- Add "Packager" field for container scanning in the SBOM.
- For OS packages, the package manager depends on the OS package type. For example,
dpkgmaps toaptandrpmmaps todnf.
- For OS packages, the package manager depends on the OS package type. For example,
- For language level packages, the package manager depends on the application package type. For exam
Add "Location" field for containers scanning in the SBOM.
- For containers, the location should list the image that was scanned, and if possible include a
filePathquery parameter with the location of the dependency. For example, this could be/usr/local/lib/node_modules/@colors/colors/package.json.
- For containers, the location should list the image that was scanned, and if possible include a
Proposed mappings
OS Pkg Type => Pkg Manager Mappings
| Trivy OS Package Type | Package Manager |
|---|---|
| apk | apk |
| dpkg | apt |
| dpkg-license | apt |
| rpm | dnf |
| rpmqa | dnf |
Language Pkg Type => Pkg Manager Mappings
| Trivy Language Package Type | Package Manager |
|---|---|
| bundler | bundler |
| gemspec | bundler |
| rustbinary | cargo |
| cargo | cargo |
| composer | composer |
| jar | maven |
| pom | maven |
| gradle-lockfile | gradle |
| npm | npm |
| node-pkg | npm |
| yarn | yarn |
| pnpm | pnpm |
| nuget | nuget |
| dotnet-core | nuget |
| conda-pkg | conda |
| python-pkg | pip |
| pip | pip |
| pipenv | pipenv |
| poetry | poetry |
| gobinary | go |
| gomod | go |
| conan-lock | conan |
| mix-lock | mix |
| swift | cocoapods |
| cocoapods | cocoapods |
| pubspec-lock | pub |
Relevant links
- Add Packager and Location fields for container ... (#421041 - closed)
- Trivy package types
- Trivy CycloneDX props
- Store Container Scanning image and operating sy... (#425995 - closed)
Intended users
Implementation plan
-
Create a class Sbom::Properties::Trivyclass-
Add a PKG_TYPE_PACKAGE_MANAGER_MAPPINGSfrozen hash with the proposed mappings -
Add a .package_manager_from_package_typeclass methoddef package_manager_for_package_type(package_type) PACKAGE_TYPE_TO_PACKAGE_MANAGER_MAPPINGS[package_type] end
-
-
Update the Sbom::Ingestion::OccurrenceMapclass-
Update the #packagermethod so that it returns the first non-nil value in the following look up.- Component
gitlab:dependency_scanning:package_manager:nameprop value. - Component
aquasecurity:trivy:PkgTypeprop value mapped using theSbom::Properties::Trivy.package_manager_from_package_typeclass method.
- Component
-
Update the #input_file_pathmethod so that it returns the first non-nil value in the following look up.- Component
gitlab:dependency_scanning:package_manager:nameprop value - The full container image reference constructed from the
gitlab:container_scanning:image:nameand thegitlab:container_scanning:image:namesource props. If the component has anaquasecurity:trivy:FilePathproperty, then this should be added as well. Code example:delegate :operating_system, :image_name, :image_tag, to: :report_source, allow_nil: true def container_input_file_path report_component.properties&.input_file_path end def image_ref ref = "container-image:#{image_name}:#{image_tag}" ref += "?file_path=#{container_input_file_path}" if container_input_file_path.present? ref end
- Component
-
-
Add specs for the classes.
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.