Auto detection

Endor Labs can automatically detect the toolchains your projects need from the manifest files in your repository. Auto detection works for Java, Python, Go, .NET (C#), Ruby, Swift, and JavaScript (Node.js, Yarn, pnpm, and Rush) projects. See the Toolchain support matrix for a complete list of supported toolchain versions for auto detection. Scans run by the Endor Labs SCM apps use auto detection by default.

How auto detection works

Endor Labs begins auto detection by scanning your project repository to locate manifest files and identify the languages used in your project. Based on the results, it runs language-specific detectors to extract version information. Each detector operates independently and follows a consistent process. It reviews the associated manifest or build configuration files to determine the toolchain version. If a file contains multiple version fields, the detector uses a fixed priority order to select the most appropriate one. After identifying a version, the detector sends the version details to the assigner. The assigner checks the Endor Labs toolchain support matrix to see whether Endor Labs supports the version for the host operating system and architecture. If it finds an exact match, it selects that version. If it doesn’t, it selects the newest supported version with the same major version number. For Go, Endor Labs matches the minor version, so go 1.21 installs the newest supported 1.21 release. Node.js follows different rules, described in Node.js version selection. For example, when analyzing Java projects, the Java detector checks config files like pom.xml or build.gradle to find the Java version used in the project.

Config files scanned for version detection

The following table lists the config files Endor Labs scans to detect the toolchain versions your project uses. JavaScript projects can use Yarn, pnpm, or Rush as the build tool. The following examples show how to define versions in each config file.

Java with Maven

Define the Java version in pom.xml. If pom.xml sets more than one Java version field, Endor Labs uses the first one it finds in the following order:

maven.compiler.source
source in maven-compiler-plugin
release in maven-compiler-plugin
maven.compiler.release
java.version

Endor Labs reads the Maven version from distributionUrl in .mvn/wrapper/maven-wrapper.properties. Without a wrapper, pom.xml selects the Maven family. A modelVersion of 4.1.0 or a root="true" attribute on <project> selects Maven 4, and 4.0.0 selects Maven 3. Endor Labs doesn’t provide a Maven 4 toolchain yet, so a Maven 4 project builds with the Maven on the scan machine’s PATH. Maven 4 requires Java 17 or later.

Version property
Compiler plugin
maven-wrapper.properties

<properties>
  <maven.compiler.source>17</maven.compiler.source>
</properties>

<build>
  <plugins>
    <plugin>
      <artifactId>maven-compiler-plugin</artifactId>
      <version>3.8.1</version>
      <configuration>
        <source>11</source>
      </configuration>
    </plugin>
  </plugins>
</build>

distributionUrl=https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.9.9/apache-maven-3.9.9-bin.zip

Java with Gradle

Define the Java version using sourceCompatibility or targetCompatibility in build.gradle or build.gradle.kts. In build.gradle, quote the version value, such as '17'. Endor Labs also detects the version in a Java toolchain block, such as JavaLanguageVersion.of(17).Endor Labs reads the Gradle version from the -bin.zip distribution in gradle/wrapper/gradle-wrapper.properties. Endor Labs doesn’t detect -all.zip distributions.

build.gradle
build.gradle.kts
gradle-wrapper.properties

sourceCompatibility='17'
targetCompatibility='17'

java.sourceCompatibility = JavaVersion.VERSION_17

distributionUrl=https\://services.gradle.org/distributions/gradle-7.6.4-bin.zip

Python

Specify the Python version in any of the following config files.

setup.py
pyproject.toml
.python-version

Use python_requires inside the setup() block.

setup(
    ...
    python_requires='>=3.8, <4'
)

Use requires-python in the [project] table to define the Python version range.

[project]
requires-python = ">=3.8, <4.0"

For Poetry projects, use python in the [tool.poetry.dependencies] table. If the file sets both fields, Endor Labs uses the one that appears first.

[tool.poetry.dependencies]
python = "3.12.1"

Specify the exact Python version.

3.12.1

Node.js

Specify the Node.js version in any of the following config files. See Node.js version selection to learn which release Endor Labs installs.

package.json
.nvmrc
.node-version

Use engines.node or volta.node.

"engines": {
  "node": ">=22.0.0 <25"
}

This range installs 22.23.4, the newest supported release in the lowest major version the range allows.

Specify the Node.js version.

22.23.4

Specify the Node.js version.

22.23.4

Yarn

Specify the Yarn version in any of the following config files. Endor Labs also infers the Yarn major version from the format of yarn.lock.

package.json
.yarnrc.yml
.yarnrc

Use engines.yarn, packageManager, or volta.yarn. If the file sets more than one, Endor Labs uses them in that order.

"engines": {
  "yarn": ">=1.22.0 <2.0.0"
}

Use yarnPath.

yarnPath: ".yarn/releases/yarn-3.2.1.cjs"

For Yarn 1, use --version.

--version 1.22.19

pnpm

Specify the pnpm version in package.json using engines.pnpm, packageManager, or volta.pnpm. If the file sets more than one, Endor Labs uses them in that order. Endor Labs also infers a pnpm version range from lockfileVersion in pnpm-lock.yaml.

"engines": {
  "pnpm": ">=6.0.0"
}

.NET

Specify the .NET version using any of the following config files.

global.json
*.csproj
Directory.Build.props
Directory.Packages.props

Use sdk.version.

{
  "sdk": {
    "version": "7.0.203"
  }
}

Use TargetFramework or TargetFrameworks.

<Project>
  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
  </PropertyGroup>
</Project>

Use TargetFramework or TargetFrameworks in a PropertyGroup to define the .NET version for the directory and subdirectories.

<Project>
  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
  </PropertyGroup>
</Project>

Use TargetFramework or TargetFrameworks in a PropertyGroup to define the .NET version when using central package management.

<Project>
  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
  </PropertyGroup>
</Project>

Specify the Go version in go.mod with the go directive.

module github.com/example/project

go 1.21

Ruby

Specify the Ruby version in any of the following config files.

Gemfile
.ruby-version
.rvmrc

Use the ruby directive.

ruby "3.4.5"

Specify the Ruby version.

3.4.5

Use rvm use.

rvm use 3.4.5

Swift

Specify the Swift version in any of the following config files.

Package.swift
.swift-version

Use the swift-tools-version comment in the first lines of the file.

// swift-tools-version: 6.1

Specify the Swift version.

6.1.2

Auto detection is best-effort and works only if your project’s config files are correctly configured.

Node.js version selection

Endor Labs installs the newest supported release in the major version that your config files request, even when they name an exact version. For example, a request for 24.8.0 installs 24.22.1. When a range allows more than one major version, Endor Labs uses the lowest supported major version in the range. When Endor Labs detects a request for Node.js 25, it usually installs the newest supported Node.js 26 release. A detected request for Node.js 20 or earlier, or for any other unsupported major version, installs the default Node.js version. Endor Labs still uses the detected Yarn and pnpm versions when they’re supported. macOS AMD64 has no default toolchain versions. See Node.js version selection for scan profiles to learn how Endor Labs handles a pinned version.

Enable auto detection for endorctl scans

To enable auto detection for endorctl scans, run the following command.

endorctl scan --install-build-tools --enable-build-tools-version-detection

Enabling these options downloads the necessary build toolchains during each scan. This works well for one-time scans but may cause scan failures in CI environments due to intermittent network issues.

Introduction

Setup & Deployment

Inventory & Insights

Scan with Endor Labs

Risk Remediation

Integrations

Secure AI Coding

Platform Administration

Best Practices

Threat Center

Trust & Compliance

How auto detection works

Config files scanned for version detection

Node.js version selection

Enable auto detection for endorctl scans

​How auto detection works

​Config files scanned for version detection

​Node.js version selection

​Enable auto detection for endorctl scans

How auto detection works

Config files scanned for version detection

Node.js version selection

Enable auto detection for endorctl scans