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:
Conda Ecosystems
First level dependencies are supported for index.json, but the semver resolution of version is not yet supported.
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 top-level inventory only in scans of pre-build artifact source code. |
|
•
|
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. |
Support for Direct Dependencies in Go Mod Pre-Built Artifacts
Code Insight supports the detection of direct dependencies for Go modules (in go.mod and _go.mod files) that are from the GitHub forge only.
.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 files.
More About Direct Dependencies in Pre-Built 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. |
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.