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 is supported 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. For performing scans, the SCM apps check the toolchain specifications in the following order:
  1. Scan workflow, if present.
  2. Toolchain configuration specified through endorctl API.
  3. Toolchain configuration specified in scanprofile.yaml file.
  4. Enable auto detection to automatically detect the toolchains from your manifest files.
  5. Uses the system defaults.

​
Configure build tools for endorctl scans

After installing and initializing endorctl, run the endorctl scan with the --install-build-tools flag to automatically download and install any missing toolchains in an isolated sandbox to properly execute language-specific scans and dependency resolution.
  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.
  3. The system checks for the required toolchain specifications in the following order before installing them in the sandbox.

​
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, including custom paths, environment variables, and any custom scripts, using the tools already available on the machine. 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 using the project’s scan profile, run:
--use-scan-profile and --install-build-tools cannot be used 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 do not provide a tool profile, the default toolchains are installed in the sandbox while performing the 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.

​
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 the package is named 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 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: Enable to specify a list of paths to include in the scan.
  • excluded_paths: Enable to specify a list of paths to exclude from the scan. Excluded paths do not 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: Enable to specify a list of languages to scan. If empty, default values are used.
  • call_graph_languages: Enable to specify a list of languages to use for generating call graphs. If empty, default values are used.
  • segment_match_languages: Enable to specify a list of languages to scan using segment-based analysis.
  • additional_environment_variables: Enable to specify additional environment variables to set during the scan. Only the environment variables starting with ENDOR_ are passed to the scan, all others are ignored. 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 are using Bazel in your build, you can further configure:
  • bazel_configuration: Enable to specify configuration settings for Bazel scans. See Bazel flags for more details.
  • bazel_show_internal_targets: Enable to include internal build targets in the dependency analysis.
  • bazel_workspace_path: Enable to specify the path to the Bazel workspace.
  • bazel_include_targets: Enable to specify Bazel targets to include in the scan.
  • bazel_exclude_target: Enable to specify Bazel targets to exclude from the scan.
The following toolchain profile shows a yaml definition with configured automated scan parameters: