Cryptographic Identification and Verification
In addition to traditional manifest based package identification, SOOS also supports package identification through the use of cryptographic identification and verification. This techniques leverages SOOS's database of pre-computed file hashes to identify and verify open source components.
By default SCA scans only look for the manifest files listed under Supported Languages and Files, however there are three file match options available to use when running SCA scans. These are controlled using the --fileMatchType argument (for example --fileMatchType=Manifest).
- Manifest - The default option, which only locates manifest files.
- FileHash - Only run file hashing on the supported file extensions and do not try to locate manifest files. Typically use this for instances where manifest files are not available or for languages or instances where no package manager is used.
- ManifestAndFileHash - Locate manifest files and run file hashing. Use this option for languages such as Java where SOOS supports both manifest and file hashing. The located file hashes will be used to verify the existence of packages identified in the manifest file(s).
This option is used for languages such as C-Family Scanning (C, C++, & Objective C) if no c-based package manager is used.
The results in the dependency tree will show that the package was identified using a cryptographic identifier and not by a manifest.
Cryptographic verification can be used for languages such as Java where SOOS supports both manifest and file hashing, allowing you to verify the existence of packages listed in the manifest with the files located on disk.
The results in the dependency tree will show that the package was identified using a cryptographic identifier and also in the manifest (or perhaps only identified in the manifest, or only identified in the file system).
In the example below joda-time was only identified in the pom.xml manifest and was not located on disk.
In the example below log4j was identified in the pom.xml manifest and was also verified on disk.
In the example below org.elasticsearch was only identified on disk and was not located in the pom.xml file.
