Skip to main content
Endor Labs uses build tools to scan projects, generate reliable Software Bill of Materials (SBOM), and detect security or operational risks. For languages like Java, Python, and .NET that depend on the build environment, it relies on specific runtime or package manager versions to ensure precise results. When tools are missing, you can define and install them in the CLI, and Endor Labs sets them up in an isolated sandbox during the scan. This feature works on Linux and macOS. You need to install and initialize endorctl before configuring the build toolchains in a scan profile.

​
Toolchain priority in monitoring scans

Endor Labs SCM integrations continuously monitor your projects for security and operational risks. Each app monitors the projects in your organization and runs a scan once every 24 hours. The SCM apps check the toolchain specifications in the following order:
  1. The scan workflow, if present.
  2. The toolchain configuration set through the endorctl API.
  3. The toolchain configuration set in the scanprofile.yaml file.
  4. The toolchains that auto detection finds in your manifest files.
  5. The system default toolchains.

​
Configure build tools for endorctl scans

After installing and initializing endorctl, run the endorctl scan with the --install-build-tools flag. endorctl downloads any missing toolchains and installs them in an isolated sandbox, so language-specific scans and dependency resolution run correctly.
  1. For the first time, run the endorctl scan to create a project with Endor Labs.
  2. Run the following command to automatically download and install build tools as part of your scan.
Before endorctl installs toolchains in the sandbox, it checks for toolchain specifications in the following order:
  1. Scan workflow configured through the endorctl API
  2. Toolchain profile configured through the endorctl API
  3. Toolchain profile configured in the scanprofile.yaml file
  4. Toolchains found by auto detection
  5. System default toolchains

​
Scan with a preconfigured build environment

If your build tools are already installed in your scan environment, use --use-scan-profile to apply the project’s scan profile configuration without downloading and installing tools in a new sandbox. Endor Labs fetches the scan profile associated with the project and applies its automated scan parameters with the tools already available on the machine. These parameters include custom paths, environment variables, and any custom scripts. This approach is useful when you have a container or CI runner with the required tools already installed and you want the scan profile to control scan behavior. Before you run the scan:
  1. Verify that the project already exists in Endor Labs. If it does not, run endorctl scan first to create it.
  2. Configure a scan profile for the project. See Configure scan profile through the Endor Labs user interface, through the API, or through a YAML file.
  3. Verify that the required build tools are installed on the machine.
To scan with the project’s scan profile, run the following command.
You can’t use --use-scan-profile and --install-build-tools at the same time. Use --install-build-tools if you want to download and install build tools rather than using pre-installed ones.

​
System default toolchain versions

If you don’t provide a toolchain profile, endorctl installs the default toolchains in the sandbox when you run endorctl scan with the --install-build-tools flag. See Toolchain support matrix for details on default versions.

​
Toolchain support matrix

The following table outlines the toolchain profile support details across different languages and platforms.
.NET 5 and earlier versions are not supported for auto detection or manual configuration.
If a project uses Java 8, Endor Labs installs both Java 8 and Java 17.0.11. It builds the project with Java 8 and scans it with Java 17.

​
Node.js version selection

See Node.js version selection in auto detection to learn how Endor Labs maps the Node.js version a project requests to an installed release. When a scan profile pins an official nodejs.org release, Endor Labs selects the Node.js version to install by the following rules:
  • A pin older than the newest supported release in its major version installs that newest release. For example, a pin to 24.8.0 installs 24.22.1.
  • A pin to Node.js 20 or earlier, or to Node.js 21 or 23, installs the default Node.js version.
  • A pin to Node.js 25 installs the newest supported Node.js 26 release.
  • A pin equal to or newer than the newest supported release in its major version installs as configured.
  • A pin above every supported major version, such as Node.js 27 or later, installs as configured.
  • On macOS AMD64, which has no default toolchain versions, a pin that would otherwise get the default installs as configured.
A pin that downloads Node.js from a location other than nodejs.org, such as an internal mirror, always installs as configured. A pin also installs as configured when the supported release it would move to doesn’t download from nodejs.org. Endor Labs never changes the saved scan profile. The installed Node.js version can differ from the version in a project’s engines field. Endor Labs turns off engine checks for npm, pnpm, and Yarn 1, so the mismatch produces a warning instead of a failed scan. Endor Labs installs pnpm 7 to 11 as an npm package that runs on the installed Node.js. This applies when the pnpm version downloads from the official pnpm GitHub releases and the installed Node.js version is 22.13 or later. Otherwise pnpm installs as a standalone binary, as do pnpm 12 and later. A pnpm version pinned in a scan profile keeps its version either way. pnpm 6 can’t run on a supported Node.js version, so Endor Labs installs the default pnpm version in place of a pinned or detected pnpm 6.

​
Pin Python package manager versions

Endor Labs installs the Python package managers as pip packages in the scan sandbox, so they do not appear as separate toolchains. If you do not pin a version, the sandbox uses the default versions listed in the toolchain support matrix. Endor Labs also installs setuptools, wheel, and click 8.1.8. To use a different version, pin the package under the Python toolchain in your scan profile. A version you pin replaces the Endor Labs default. Packages you leave out keep their defaults. This works for any package that publishes a wheel, so you can pin a package manager plugin that your build needs as well. Endor Labs installs pip packages with --only-binary=all, so a package that ships only a source distribution fails to install. Set pip_packages under python_tool_chain. Each key is the pip package name, and name is the version to install. Enter the key in lowercase, exactly as it appears on PyPI. Endor Labs matches keys exactly, so Poetry does not replace the poetry default. The python_tool_chain block must also carry a complete version for the Python runtime, with name, urls, sha256_sum, and relative_tool_chain_path. Endor Labs does not fill the runtime version in for you when you set pip_packages, and a version without urls fails validation with python toolchain urls cannot be empty. Use a full patch version such as 3.12.11, not 3.12.
Add more packages as further keys under pip_packages. Pin Poetry the same way, using a poetry key. The python_tool_chain.poetry_version field in the API schema is deprecated, and Endor Labs does not use it. Endor Labs installs Poetry 1.7.0 by default, so check that your build works with the version you pin before you move to a different major version. Use the same python_tool_chain block under toolchain_profile when you create a scan profile through the API. See Configure scan profile through the Endor Labs API to create the profile and associate it with a project. To pin a version without supplying the runtime details yourself, use the Endor Labs user interface. It fills in the urls and sha256_sum for the runtime version you select. See Pin a Python package manager version to follow the procedure.

​
Configure automated scan parameters

Automated scan parameters are endorctl parameters and environment variables that you define in a scan profile. They apply to projects linked to that profile and help customize scan behavior during cloud scans. You can define the following parameters in your scan profile:
  • included_paths: List of paths to include in the scan.
  • excluded_paths: List of paths to exclude from the scan. Excluded paths don’t apply to secrets scanning. Secrets detection always scans the full repository. To filter or suppress secret findings, use policies or a .gitleaksignore file instead.
  • languages: List of languages to scan. If empty, Endor Labs uses the default values.
  • call_graph_languages: List of languages to use for generating call graphs. If empty, Endor Labs uses the default values.
  • segment_match_languages: List of languages to scan using segment-based analysis. If you don’t also set languages, this clears the default language list.
  • additional_environment_variables: Additional environment variables to set during the scan. Endor Labs passes only environment variables that start with ENDOR_ to the scan and ignores all others. It also drops a few reserved ENDOR_ variables that the scanner sets itself. See Global flags and environment variables for a complete list of available environment variables.
  • enable_automated_pr_scans: Enables automatic scanning of pull request changes.
  • enable_pr_comments: Enables adding scan results as comments in pull requests.
  • enable_sast_scan: Enables SAST during the scanning process.
  • disable_code_snippet_storage: Disables the storage of code snippets.
If you use Bazel in your build, set bazel_configuration to configure Bazel scans. See Bazel flags to learn more about these settings. bazel_configuration takes the following sub-fields:
  • bazel_show_internal_targets: Includes internal build targets in the dependency analysis.
  • bazel_workspace_path: Path to the Bazel workspace.
  • bazel_include_targets: Bazel targets to include in the scan.
  • bazel_exclude_targets: Bazel targets to exclude from the scan.
  • bazel_targets_query: Bazel query that selects the targets to scan.
The following YAML example defines automated scan parameters with kind: AutomatedScanParameters.