Notes About Ecosystem Support
The following sections provide additional information (such as limitations, requirements, and clarifications) to consider for the various ecosystems supported in the Code Insight Automated Analysis process:
Cargo Ecosystems
Note the following about Cargo ecosystems:
|
•
|
Code Insight reports top-level inventory from pre-build and post-build artifacts such as Cargo.toml and .crate files, respectively. |
|
•
|
If a probable component is discovered but not matched against the crates forge in the Code Insight Data Library, Code Insight creates a non-published Work In Progress inventory item for the component. |
Cocoapod Ecosystems
Note the following about Cocoapod ecosystems:
|
•
|
For the detection of direct dependencies, having the .podspec file in the scan directory is desirable. In cases where the .podspec file is not present, the system does the following: |
|
•
|
Uses the podfile.lock file to identify direct dependencies. |
|
•
|
Uses the directory name to identify top-level inventory. |
|
•
|
For the detection of transitive dependencies, having both the .podspec and the podfile.lock file is desirable. In cases where podfile.lock is missing, the system uses the following external APIs to retrieve transitive- dependency information. |
|
•
|
https://cdn.jsdelivr.net/cocoa/Specs |
|
•
|
https://cdn.cocoapods.org/ |
Conda Ecosystems
First-level dependencies are supported for index.json, but the semver resolution of version is not yet supported.
Debian Ecosystems
Scans discover and report top-level inventory in Debian (.deb) packages as follows:
|
•
|
If an inventory item discovered in a Debian package has a match in the Debian forge, the item is created as a published top-level inventory item with a High confidence level. |
|
•
|
Any item that does not have a match in the forge is created as an unpublished top-level inventory item with a “Work in Progress” designation and a Low confidence level. |
Git Ecosystems
Code Insight scans the configuration file (config or gitconfig) inside a .git folder in a project codebase to identify OSS and third-party components and evidence and then uses this information to create inventory items.
Note:To support the detection of components in a Git repository, the configuration file in a .git folder will always be included in scans even if this folder has been added to the Scan Exclusions list in the scan profile.
Go Ecosystems
Note the following for Go ecosystems:
|
•
|
Currently, Code Insight supports the discovery of inventory in scans of only pre-built artifact source code. |
|
•
|
Go module inventory is reported from the Go forge. If an item is not found in the Go forge, Code Insight searches for it in the GitHub forge. |
|
•
|
All Go module inventory will be associated with the go.mod or _go.mod file. |
|
•
|
The name of Go module inventory includes the module name, version, and license name (if applicable) in the format componentName <version> (<license>). The following is an example: |
match v1.1.0 (MIT)
|
•
|
If the codebase is uploaded from the release section of the VCS repository, Code Insight must use the version in the name of the project’s parent folder as the version in the top-level inventory name. Any changes to the version in the parent folder name can result in the wrong version being reported in the inventory. |
|
•
|
For a pseudo version of a direct or transitive dependency, Code Insight shows only the main version part. For example, if the pseudo version is v0.0.0-20191202100458-e7afc7fbc510, Code Insight displays the dependency version as v0.0.0 (created as a custom version). |
|
•
|
Top-level inventory that is generated with a Work in Progress type during Automated Analysis is not automatically published in the Analysis Workbench (even if the auto-publish feature is enabled for the project). You must manually publish such inventory items. |
Direct Dependencies in Go Mod Pre-Built Artifacts
Code Insight supports the detection of direct dependencies in Go modules (go.mod and _go.mod files).
Transitive Dependencies in Go Mod Pre-Built Artifacts
All transitive dependencies found in the Go module go.sum are mapped to top-level inventory.
Gradle Ecosystems
Code Insight reports top-level inventory whenever a build.gradle file is located in the scan path. The top-level inventory name is either the rootProject.name attribute in settings.gradle or the name of the directory in which build.gradle resides.
Note:The settings.gradle file should be available in the same directory as build.gradle.
Dependencies are reported from build.gradle if they are referenced with a dependencies tag within the file.
Gradle Version Catalog
A Gradle version catalog is a list of dependencies, represented as dependency coordinates, from which a user can select when declaring dependencies in a build script.
If the version catalog exists in a *.versions.toml file and the dependencies in the catalog are also listed in the versionCatalogs tag (available in the settings.gradle and settings.gradle.kts files), Code Insight will support these same dependencies referenced in any other build.gradle or build.gradle.kts files.
As recommended by Gradle, Code Insight supports, by default, the libs.versions.toml file if it exists under the project root or gradle folder.
Additionally, if the scan’s profile is configured to detect Only First Level Dependencies or All Transitive Dependencies, top-level inventory items are created for all items in the libraries section of the *.versions.toml file, with the exception of those items also referenced in build.gradle or build.gradle.kts. These top-level inventories are created with their Part of Product usage property set to No.
Dependency Scope Reported
A dependency scope of either Runtime or Non-Runtime can be reported for dependencies found in the build.gradle or build.gradle.kts file. For more information, see Dependency Scopes.
Kotlin Support
Code Insight currently provides Beta support for Kotlin kts files. Code Insight reports top-level inventory from a .kts file and any dependencies with a dependencies tag within the file.
The top-level inventory name is either the rootProject.name attribute in the settings.gradle.kts file or the name of the directory in which build.gradle.kts resides.
Note:The settings.gradle.kts file should be available in the same directory as build.gradle.kts.
The Gradle version catalog is also supported for build.gradle.kts files. See Gradle Version Catalog.
Maven Ecosystems
A dependency scope of either Runtime or Non-Runtime can be reported for dependencies found in .jar, pom.xml, and .pom files. For more information, see Dependency Scopes.
.NET Ecosystems
When .NET projects are created using .NET Core and no information about top-level items is available within the .csproj file, Code Insight does the following:
|
•
|
Reports top-level inventory by using the .csproj filename as the inventory name |
|
•
|
Locates and reports the inventory’s associated direct and transitive dependencies from this same file |
This process requires an Internet connection to access the NuGet forge. For offline connections, top-level items and any associated dependencies are reported only if the top-level items are directly available in the .csproj file.
NPM Ecosystems
Note the following for NPM ecosystems:
|
•
|
Code Insight provides scan support for package.json alone or for package.json with either package-lock.json or npm-shrinkwrap.json. |
|
•
|
The package-lock.json or npm-shrinkwrap.json file is scanned only if it co-exists with package.json. (The package.json file contains the component and dependency data. The package-lock.json or npm-shrinkwrap.json file is used to identify the exact dependency versions for components that Code Insight should pull from package.json.) |
|
•
|
If both package-lock.json or npm-shrinkwrap.json are present with package.json, Code Insight scans npm-shrinkwrap (along with package.json) and ignores package-lock.json. |
PyPI Ecosystems
Code Insight supports the discovery of top-level inventory and direct dependencies for both pre-build and post-build artifacts of a Python project. Pre-build artifacts include source packages, such as tar.gz, .zip, and other such files. Post-build artifacts are binary packages such as .whl and .egg files.
More About Direct Dependencies in Pre-Build Artifacts
Direct dependencies for the pre-build artifacts are retrieved from the requirements.txt file if it exists. (In the absence of requirements.txt, direct dependencies are reported from the install_requires section in the setup.py file.)
When direct dependencies are retrieved from requirements.txt, the top-level inventory item to which these dependencies are mapped is determined as follows:
|
•
|
If PKG-INFO or setup.py resides in the same directory as requirements.txt, the top-level inventory item is determined by information in either PKG-INFO or setup.py. |
|
•
|
If PKG-INFO or setup.py does not reside in the same directory as requirements.txt, the top-level inventory item is determined in one of two ways: |
|
•
|
If the Code Insight obtains the codebase through a git sync or git clone operation, the top-level inventory item to which direct dependencies are mapped is created from the configuration information found in the .git file. |
|
•
|
If the codebase has been directly downloaded from a GitHub or PYPI repository and then uploaded to Code Insight for the scan, the top-level inventory item is created using the name of the directory under which requirements.txt resides. Direct dependencies identified in requirements.txt are then mapped to this inventory item. |
Note that, upon creation, such an inventory item is considered a “place holder” item because it is created from a directory name, which might or might not be a valid component name. The item is published during the automated analysis only if its name matches a valid component in the Code Insight Data Library, its forge is PyPI or GitHub, and it meets your site’s inventory publication policies. Otherwise, the item remains unpublished for further review.
The inventory type for the item is determined as follows:
|
•
|
If the component name matches a component name in the Code Insight Data Library, the inventory type is Component. |
|
•
|
If the component is not found in the Data Library but the inventory’s license matches a license in the Data Library, the inventory type is License Only. |
|
•
|
If neither the component nor license has a match in the Data Library, the inventory type is Work In Progress. |
More About Direct Dependencies in Post-Build Artifacts
Direct dependencies for the post-build artifacts are retrieved from the indicator files within these built artifacts.
|
•
|
.whl file—The top-level inventory and direct dependencies are reported from the METADATA file, which resides within the .whl file. The Requires-Dist tag specified within the METADATA file resolves the direct dependencies. |
|
•
|
.egg file—The top-level inventory is reported from the PKG-INFO file, which resides within the .egg file. The direct dependencies are reported from the requires.txt file, which is bundled along with PKG-INFO file inside the .egg file. |
Ruby Ecosystems
Note the following for Ruby ecosystems:
|
•
|
For RubyGem projects, Code Insight shows all platform-related dependencies and those dependencies that are not part of a “test” or “dev” group as inventory. Any gems identified as “dev” or “test” are not considered for inventory. |
|
•
|
Only SemVer expressions in the major.minor.patch format are supported to resolve dependencies listed in the manifest file. |
Yarn Ecosystems
Note the following for Yarn ecosystems:
|
•
|
Code Insight provides scan support for package.json alone or for package.json with the yarn.lock file. |
|
•
|
The scan yarn.lock file is scanned only if it co-exists with package.json. (The package.json file contains the component and dependency data. The yarn.lock file is used to identify the exact dependency versions for components that Code Insight should pull from package.json.) |
Yocto Ecosystems
Code Insight parses a .bb file only if it contains an SRC_URI property value that starts with git:// or https://. If the SRC_URI property contains more than one URI, only the first supported URI is considered.