• Русский

Supported ecosystems and analysis methods

Manifests

To find dependencies, CodeScoring primarily relies on parsing package manager manifest files. The platform supports parsing the following technologies:

Ecosystem	Package manager or build tool	File format
Java and Kotlin	Gradle	*.gradle *.gradle.kts gradle-dependency-tree.txt gradle.lockfile
	Maven	pom.xml maven-dependency-tree.txt
	Apache Ivy	ivy.xml
JavaScript and TypeScript	npm	package.json package-lock.json npm-shrinkwrap.json
	yarn	yarn.lock package.json package-lock.json
	pnpm	pnpm-lock.yaml
Python	pip	requirements.txt requirements.pip requires.txt pip-resolved-dependencies.txt pipdeptree.txt
	Poetry	pyproject.toml poetry.lock
	Pipenv	Pipfile Pipfile.lock
	Conda	environment.yml meta.yml conda-lock.yml
	uv	pyproject.toml uv.lock
C and C++	Conan	conanfile.txt conan.lock conanfile.py
	GCC, Clang, CMake, Make etc.	Build scanning
Go	Go Modules	go.mod go.sum
PHP	Composer	composer.json composer.lock
Ruby	RubyGems	Gemfile Gemfile.lock *.gemspec gems.locked
.NET	Nuget	*.nuspec packages.lock.json Project.json Project.lock.json packages.config *.csproj project.assets.json dependencyReport.json deps.json *.sln
	Paket	paket.dependencies paket.lock
Objective-C	CocoaPods	Podfile Podfile.lock *.podspec
Swift	Swift Package Manager	Package.swift Package.resolved
Rust	Cargo	Cargo.toml Cargo.lock
Scala	sbt	scala-dependency-tree.txt sbt-dependency-tree.txt

The best result will be achieved by combining the main manifest file and the corresponding lock file, if provided by the package manager mechanism.

PURL Types and Components

For unified dependency description, CodeScoring uses the Package URL (PURL) standard.

PURL example

pkg:maven/org.apache.logging.log4j/log4j-core@2.17.2

When analyzing SBOM via the agent command or importing into the platform, CodeScoring recognizes and supports the following PURL types according to the specification:

PURL type	Description	Specification
cocoapods	Libraries for Objective-C / Swift via CocoaPods	CocoaPods Definition
conan	Packages in the C / C++ (Conan) ecosystem	Conan Definition
conda	Packages in the Python / Conda ecosystem	Conda Definition
nuget	Components for .NET / NuGet	NuGet Definition
golang	Go Modules packages	Go Definition
maven	Java / Kotlin artifacts (Maven / Gradle)	Maven Definition
npm	JavaScript / TypeScript packages	NPM Definition
composer	PHP (Composer) packages	Composer Definition
pypi	Python (PyPI) packages	PyPI Definition
gem	Ruby (RubyGems) packages	RubyGems Definition
cargo	Rust (Cargo) packages	Cargo Definition
generic	General type for arbitrary binary or custom artifacts	Generic Definition
apk	Alpine Linux system packages	APK Definition
deb	Debian / Ubuntu system packages	DEB Definition
rpm	RHEL / CentOS / Fedora system packages	RPM Definition
swift	Swift Package Manager packages	Swift Definition
oci	OCI / Docker container images	OCI Definition
docker	Docker Hub / Docker images	Docker Definition
github	GitHub repositories	GitHub Definition
huggingface	Hugging Face Hub models	HuggingFace Definition
mlflow	MLflow Model Registry models	MLflow Definition
pub	Dart / Flutter (pub.dev) packages	Pub Definition
swid	SWID Tags (Software Identification Tags)	SWID Definition

Each component with a PURL is classified by type, which CodeScoring recognizes when importing SBOM files. The type is indicated in the type field within the component description.

Difference between PURL and component types

A component type describes its functional role within a product—for example, a library, framework, or firmware. A PURL type, in turn, defines the ecosystem and source from which the component was obtained.

SBOM component example

{
  "components": [
    {
      "name": "log4j-core",
      "version": "2.17.2",
      "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.2",
      "type": "library"
    }
  ]
}

Supported component types:

Component type	Description
library	A library, package, or third-party code module used in the project.
framework	An infrastructure or application framework containing a set of libraries.
firmware	Executable binary or embedded software analyzed for the presence of third-party components.

System packages

As part of the OSA module, the platform supports analysing system packages of the following formats:

• Debian;
• Alpine;
• RPM;
• Astra Linux;
• ALT Linux;
• RED OS.

Resolution mechanism in the absence of a lock file

If there is no lock file the system will try to resolve transitive OSS dependencies itself:

• Maven
  • for pom.xml and build.gradle format generation of maven-dependency-tree via the corresponding maven plugin
  • Maven version 3.8.8 and OpenJDK version 11 are used
• PyPi
  • generation of poetry.lock using the Poetry package manager
  • Python version 3.11.7 is used
• N.P.M.
  • generation of yarn.lock using the Yarn package manager
  • uses Node.js version 20.9.0
• Nuget
  • for csproj and sln format generation of project.assets.json using built-in nuget tools
  • uses .NET SDK version 8.0.404
• Packagist
• generation of composer.lock using the Composer package manager
• PHP version 8.2.26 is used
• Rubygems
  • generation of Gemfile.lock using the Bundler package manager
  • uses Ruby version 3.1.2p20

Generation of lock files by the system does not produce the best results in every case, since it often depends on the environment.

Resolving dependencies in the build environment

Some package managers do not include transitive dependencies in their manifests by default. For high-quality compositional analysis when working with them, it is recommended to use a dependency resolution mechanism in the build environment.

When resolving dependencies in the environment, the agent checks for the absence of a lock file, independently launches the package manager or build tool, and generates a complete list of components taking into account the correct version of the build. The functionality is currently available for the following ecosystems:

• .NET
• Go
• Gradle
• Maven
• npm
• Poetry
• sbt
• yarn
• Conda

Mechanism for searching dependencies using hashes

Search using hashes implies detection of direct inclusion of libraries in project's code. As part of this mechanism, all project files are hashed and these signatures are compared with known open source libraries.

Currently, hash searches occur for the following package manager indexes and the following file types:

• Maven
  • .jar
  • .war
  • .ear
• npm
  • .min.js
• PyPI
  • .whl
  • .egg
• Nuget
  • .nupkg

Hashes of files whose size does not exceed 512 bytes are not sent to the cloud.

Build scanning for C and C++

If the Conan package manager and corresponding manifests are not used to build a C/C++ project, a special mode for analyzing the build process output can be used to get a list of used libraries.

In this mode, the Johnny console agent analyzes the build process using compiler flags and identifies the libraries used. Then, using the system cache, the location of the libraries and their source are determined.