Software composition analysis is the identification of the bill of materials for first-party software packages and the mapping of vulnerabilities to these software component versions. SCA helps teams to maintain compliance and get visibility into the risks of their software inventory.

Endor Labs supports the following major capabilities to help teams reduce the risk and expense of software dependency management across the lifecycle of software reuse.

• Endor Scores: Endor Labs provides a holistic risk score that includes the security, quality, popularity and activity of a package. Risk scores help in identifying leading indicators of risk in addition to if a software component is outdated, or unmaintained. Risk analysis helps teams to go beyond vulnerabilities and approach the risk of their software holistically.
• Reachability Analysis: Reachability analysis is Endor Labs’ capability to perform static analysis on your software packages to give context to how each vulnerability may be reached in the context of your code. This includes mapping vulnerabilities back to vulnerable functions so that deep static analysis can target vulnerabilities with higher levels of granularity as well as the identification of unused software dependencies.
• Upgrade Impact Analysis: Upgrade impact analysis allows security teams to set better expectations with their development teams by identifying breaking changes associated with an update of a direct dependency.

The resource requirements, both minimum and recommended, for build runners or workers executing scans using endorctl are listed here.

System specifications for local and CI/CD scan

Ensure that your local machine or CI/CD runner has the minimum and recommended resources to successfully scan your software.

Supported languages

For scanning monorepos or projects that use Bazel as the build tool (Java, Go, Python, Scala, Rust), see Bazel.

Complete support matrix

The following comprehensive matrix lists the supported languages, build tools, manifest files, and supported requirements.

Define supported languages when running endorctl scan command as a comma-separated list: c,c#,go,java,javascript,kotlin,php,python,ruby,rust,scala,swift,typescript,swifturl

Endor Labs has developed a systematic approach to conduct call graph analysis. Here is a structured overview:

• Scope Expansion: Traditional methods of static analysis typically analyze a single project at a time. Endor Labs, however, expands its scope to include not only the client projects but also their dependencies, often comprising over 100 packages.

• Enhanced Dependency Analysis: Endor Labs employs static call graphs to conduct detailed dependency analysis, enabling a comprehensive understanding of how different external components interact within client projects. By leveraging these call graphs, Endor Labs aims to minimize false positives and more accurately identify the specific locations of problems in dependencies.

• Multiple Data Sources: Endor Labs uses both source code and binary artifacts to enrich the analysis. This approach ensures swift results without a heavy reliance on test coverage.

• Benchmarking for Continuous Improvement: Endor Labs maintains accuracy and relevance by using dynamic call graphs internally to benchmark and refine static call graphs, thereby actively identifying and addressing gaps.

• Scalability: Endor Labs addresses the challenge of scalability and generates call graphs not only for each project release but also for all its dependencies. This approach effectively manages large projects with multiple versions, ensuring that the analysis remains both relevant and applicable across the entire spectrum of client dependency sets.

For more information, see Visualizing the impact of call graphs on open source security.

Endor Labs uses static call graphs to perform dependency analysis at a fine-grained level. It is minimally intrusive to the developer workflow and provides results during development.

The Endor Labs user interface provides visualizations of call graphs that annotate vulnerability data and simplify it into informative call paths. This empowers developers to identify and address problematic invocations of vulnerable methods efficiently.

Endor Labs supports call paths for Java, Python, Rust, JavaScript, Golang, .NET (C#), Kotlin, and Scala.

View call paths

View call paths in Endor Labs to see the sequences of functions that your program invokes during execution.

1. Select Projects from the left sidebar.

2. Select the project for which you want to view the call path.

3. Select FINDINGS and select the finding from the list view.

4. Expand a specific finding to view more details.

   

5. In the details section, select CALL PATHS.

   

   A finding may have multiple call paths.

Modern software relies on complex code, external libraries, and open-source components (OSS). Managing risks requires understanding where issues come from, such as internal code, OSS, or other external dependencies.

Projects contain two types of dependencies, direct and transitive. Developers explicitly add direct dependencies, such as when they include a specific library in a project. Transitive dependencies enter the project indirectly through other libraries. While direct dependencies are easier to track and manage, transitive dependencies can introduce complexity, as they may not be immediately visible in the project’s configuration files.

Categorizing code as reachable, potentially reachable, or unreachable is another important step. Reachable code is actively invoked during normal execution. Unreachable code, on the other hand, is not used and can accumulate over time, leading to unnecessary complexity and potential issues. Identifying and managing these categories ensures that the codebase remains efficient and maintainable.

Types of Reachability Analysis

Endor Labs offers multiple types of reachability analysis to help you accurately assess vulnerability exposure in your applications. Each type provides different levels of granularity and accuracy depending on your specific use case and available analysis context.

• Function-level reachability and Dependency-level reachability: These analyses run during a full scan, when the project builds successfully and Endor Labs generates complete call graphs. They use actual code paths and dependency metadata to provide the most precise vulnerability assessment.
• Pre-computed reachability: A pragmatic, manifest-based analysis technique that enables you to assess whether vulnerabilities in transitive dependencies could be reachable from your direct dependencies—all without requiring code compilation, builds, or full call graph generation. With approximately 95% of vulnerabilities existing in transitive dependencies according to Endor Labs’ State of Dependency Management report, pre-computed reachability helps you deprioritize security issues that can’t be called by your application by filtering out vulnerabilities that affect functions in transitive dependencies that are not used by your direct dependencies. This approach works by analyzing how your direct dependencies interact with their transitive dependencies, providing valuable reachability insights as a fallback for full scans when builds fail, or as an optional enhancement for quick scans when you want reachability analysis without build requirements. Learn more about pre-computed reachability.

Function-level reachability

To help developers and security teams make informed decisions for SCA results, Endor Labs uses a static analysis technique called program analysis to perform function-level reachability analysis on direct and transitive dependencies. This is the most accurate way to determine exploitability in the context of your application, which is critical for determining which risks you should remediate.

Function-level reachability labels

The different function reachability labels include:

• Reachable Function: Endor Labs has determined that there is a path from the developer-written code to a vulnerable function, indicating that the finding is exploitable in your environment. This is demonstrated by a call graph that illustrates each step between the source code and the vulnerable library.

• Unreachable Function: Endor Labs determines that no risk of exploitation exists, as no path exists from the source code to the vulnerable function. A call graph supports this conclusion by demonstrating the absence of such a path.

• Potentially Reachable Function: Endor Labs is unable to determine whether a finding is reachable or unreachable, typically because call graph analysis is unsupported for a given language or package manager. This means that the function in question may be executable in the context of the dependent project, but the analysis cannot definitively determine if it is reachable or not.

Dependency-level reachability

Endor Labs supports dependency-level reachability by default for all supported languages. This type of reachability analysis is more coarse-grained than function-level reachability. It indicates that the application uses the imported package somewhere but does not determine whether the source code calls the vulnerable package.

Dependency-level reachability serves as a good indicator for prioritization. If you’re not actually using the dependency at all, consider removing that dependency. Determining whether your code calls or uses a dependency provides another layer of prioritization you can add to your remediation process.

Dependency reachability labels

The different dependency reachability labels include:

• Reachable Dependency: Endor Labs established that an imported package is being used somewhere in the application.

• Unreachable Dependency: Endor Labs determined that the imported dependency is not being used. The customer can use this information to remove the dependency, which is helpful for technical debt reduction initiatives.

• Potentially Reachable Dependency: Endor Labs cannot definitively determine whether the application uses a dependency, generally because Endor Labs does not support the given language or package manager.

Comparison of reachability analysis types

The following table compares the three types of reachability analysis available in Endor Labs:

Phantom dependencies

Phantom dependencies are packages that your codebase uses but does not explicitly declare in your project’s manifest files, for example, package.json, or requirements.txt. These undeclared dependencies can pose significant security and operational risks, as they may contain vulnerabilities that standard dependency analysis does not track or assess. Identifying and managing phantom dependencies is crucial for accurate reachability analysis and comprehensive risk assessment.

Detection of phantom dependencies

Endor Labs’ reachability analysis conducts thorough scans of your codebase to identify functions and methods that both declared and undeclared dependencies invoke. By analyzing the actual usage of packages in your source code, the system identifies phantom dependencies—those that your code uses but does not explicitly declare. This detection ensures that all utilized code paths are assessed for potential vulnerabilities, providing a more accurate and comprehensive security evaluation.

Endor Labs collects and analyzes a large amount of information about open-source packages and uses it to compute scores.

• Every open-source package is scored across different dimensions that capture both security and operation aspects of a risk.

• Every AI model is scored on a multidimensional scoring system grouped into four main categories: security, activity, popularity, and operational integrity.

Each category’s Endor score represents the average of all contributing factors within that category. See View scorecards for more information on checking Endor scores.

See Package scores for more information on package scores.

As you deploy Endor Labs in your environment, it’s important for your team to understand key scanning strategies.

Set a default branch

The findings, metrics, and data shown on the dashboard and the project listing page are based on scanning the default branch, which is also known as the main context.

endorctl scan --as-default-branch

If you do not set the flag as-default-branch, the first branch you scan is automatically considered as the default branch. After a scan, if you switch the default branch to another using --as-default-branch, scans from the previous branches are erased, and their findings will no longer be available.

You do not need to set a default branch if you are using the Endor Labs GitHub App or not scanning multiple branches.

Testing and monitoring different versions of your code

Across the software engineering lifecycle it is important that continuous testing is separated from what is monitored and reported on regularly. Often, engineering organizations want to test each and every change that enters a code base, but if security teams reported on each test they would quickly find themselves overwhelmed with noise. Endor Labs enables teams to separate what should be reported on relative to what should be tested but not reported on. Endor Labs allows teams to select reporting strategies for their software applications when integrated into CI/CD pipelines.

Here are the primary scanning and reporting strategies:

• Reporting on the default branch - All pull request commits are tested and all pushes or merges to the default branch are reported on and monitored by security and management teams.
• Reporting on the latest release - All reporting and monitoring is performed against tagged release versions. This requires each team have a mature release tagging strategy.

How to deploy a strategy for reporting

The endorctl scan command by default will continuously monitor a version of your code for new findings such as unmaintained, outdated or vulnerable dependencies in the bill of materials for a package. To test a version of your code without monitoring and reporting on it, use the flag --pr or environment variable ENDOR_SCAN_PR as part of your scan.

When adopting a strategy such as reporting on the default branch, you will want to run any push or merge event to the default branch without the --pr flag and run any pull_request or merged_request event with the --pr flag. This allows you to test changes before they have been approved and report what has been merged to the default branch as your closest proxy to what is in production.

Let’s use the following GitHub Actions workflow as an example! In this workflow any push event will be scanned without the --pr flag but any pull_request event is scanned as a point in time test of that specific version of your code.

name: Endor Labs Scan
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  scan:
    permissions:
      security-events: write # Used to upload sarif artifact to GitHub
      contents: read # Used to check out a private repository but actions/checkout.
      actions: read # Required for private repositories to upload sarif files. GitHub Advanced Security licenses are required.
      id-token: write # Used for keyless authentication to Endor Labs
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v3
      - name: Setup Java
        uses: actions/setup-java@v3
        with:
          distribution: 'microsoft'
          java-version: '17'
      - name: Build Package
        run: mvn clean install
      - name: Endor Labs Scan Pull Request
        if: github.event_name == 'pull_request'
        uses: endorlabs/github-action@v1.1.1
        with:
          namespace: 'example'
          pr: true
          sarif_file: 'findings.sarif'
          pr_baseline: $GITHUB_BASE_REF
      - name: Endor Labs Reporting Scan
        if: github.event_name == 'push'
        uses: endorlabs/github-action@v1.1.1
        with:
          namespace: 'example'
          pr: false
          sarif_file: 'findings.sarif'
      - name: Endor Labs Testing Scan
        if: github.event_name == 'pull_request'
        uses: endorlabs/github-action@v1.1.1
        with:
          namespace: 'example'
          pr: true
          sarif_file: 'findings.sarif'
      - name: Upload findings to github
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: 'findings.sarif'

Scanning detached refs

In some CI/CD based environments, each time code is pushed to the default branch the exact commit SHA is checked out as a detached Git Reference. This is notably the case with Jenkins, CircleCI and GitLab Pipelines.

In these scenarios, on push or merge events Endor Labs must be told that the reference should be monitored as the default branch. You can do this with the --detached-ref-name flag or ENDOR_SCAN_DETACHED_REF_NAME environment variable. You should also couple this flag with the --as-default-branch flag or ENDOR_SCAN_AS_DEFAULT_BRANCH environment variable. This allows you to set this version of code as a version that should be monitored as well as define the name associated with the branch.

This strategy may be used for both a strategy reporting on the default branch on push events and a strategy reporting on tag creation event for that version of code.

You can see in the below GitLab Pipelines example defining the logic to manage a detached reference on GitLab.

    - if [ "$CI_COMMIT_REF_NAME" == "$CI_DEFAULT_BRANCH" ]; then
        export ENDOR_SCAN_AS_DEFAULT_BRANCH=true;
        export ENDOR_SCAN_DETACHED_REF_NAME="$CI_COMMIT_REF_NAME";
      else
        export ENDOR_SCAN_PR=true;
      fi

You can find the full GitLab pipelines reference below:

Endor Labs Dependency Scan:
  stage: Scan
  image: node # Modify this image to align with the build tools necessary to build your software packages
  dependencies: []
  variables:
    ENDOR_ENABLED: "true"
    ENDOR_ALLOW_FAILURE: "true"
    ENDOR_NAMESPACE: "demo"
    ENDOR_SCAN_PATH: "."
    ENDOR_ARGS: |
      --show-progress=false
      --detached-ref-name=$CI_COMMIT_REF_NAME
      --output-type=summary
      --exit-on-policy-warning
      --dependencies --secrets --git-logs
  before_script:
    - npm install yarn
  script:
    - curl https://api.endorlabs.com/download/latest/endorctl_linux_amd64 -o endorctl;
    - echo "$(curl -s https://api.endorlabs.com/sha/latest/endorctl_linux_amd64)  endorctl" | sha256sum -c;
      if [ $? -ne 0 ]; then
       echo "Integrity check failed";
       exit 1;
      fi
    - chmod +x ./endorctl
    - if [ "$DEBUG" == "true" ]; then
        export ENDOR_LOG_VERBOSE=true;
        export ENDOR_LOG_LEVEL=debug;
      fi
    - if [ "$CI_COMMIT_REF_NAME" == "$CI_DEFAULT_BRANCH" ]; then
        export ENDOR_SCAN_AS_DEFAULT_BRANCH=true;
        export ENDOR_SCAN_DETACHED_REF_NAME="$CI_COMMIT_REF_NAME";
      else
        export ENDOR_SCAN_PR=true;
      fi
    - ./endorctl scan ${ENDOR_ARGS}
  rules:
  - if: $ENDOR_ENABLED != "true"
    when: never
  - if: $CI_COMMIT_TAG
    when: never
  - if: $CI_COMMIT_REF_NAME != $CI_DEFAULT_BRANCH && $ENDOR_FEATURE_BRANCH_ENABLED != "true"
    when: never
  - if: $ENDOR_ALLOW_FAILURE == "true"
    allow_failure: true
  - if: $ENDOR_ALLOW_FAILURE != "true"
    allow_failure: false

Implementing baseline scans

One of the common concerns software development teams have when adopting preventative controls is ownership of issues. Often, software has accrued significant technical debt, or new vulnerabilities arise that don’t directly impact their changes. Security teams want to have all known issues addressed while the development teams are focused on fixing issues or delivering core business value. They can’t be hindered each time a new issue impacts their entire code base.

To prevent new issues from entering the environment, security teams sometimes set policies that may break the build or return a non-zero exit code that can fail automated tests. This creates friction as there is no context around what changes a developer is responsible for versus what technical debt exists in a codebase on that day.

Establishing a baseline of what issues already exist in a software project and what issues may occur because of new updates is crucial to enabling preventative control adoption.

Accelerating preventative control adoption with CI baselines

The high-level steps to establish and measure policies against a baseline scan are as follows:

1. Establish a baseline scan of your default branch or any other branch that undergoes regular testing
2. Integrate baseline scans into your automated workflows
3. Evaluate policy violations within the context of the branches to which you routinely merge

Implementing baseline scan into your program

Development teams often have different delivery strategies. Some merge changes to a default branch. Others merge to a release branch that is then released to their environment. While these strategies differ across organizations, a baseline scan must exist to measure against attribute ownership.

To establish a baseline scan, your team must perform regular scans on the branch to which you merge. This often means that you scan each push of your default branch to monitor your environment and you test each pull request using the --pr and --pr-baseline flags.

The --pr flag is a user’s declaration that they are testing their code as they would in a CI pipeline. The --pr-baseline flag tells Endor Labs which Git reference to measure any changes.

For this example, we will use the default branch as a merging strategy. In this strategy, you’ll want to scan the default branch on each push event to re-establish your baseline. You’ll also want to establish your CI baseline as the default branch.

The following GitHub workflow illustrates this strategy.

name: Endor Labs Scan
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  scan:
    permissions:
      security-events: write # Used to upload sarif artifact to GitHub
      contents: read # Used to check out a private repository but actions/checkout.
      actions: read # Required for private repositories to upload sarif files. GitHub Advanced Security licenses are required.
      id-token: write # Used for keyless authentication to Endor Labs
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v3
      - name: Setup Java
        uses: actions/setup-java@v3
        with:
          distribution: 'microsoft'
          java-version: '17'
      - name: Build Package
        run: mvn clean install
      - name: Endor Labs Scan Pull Request
        if: github.event_name == 'pull_request'
        uses: endorlabs/github-action@v1.1.1
        with:
          namespace: 'example'
          pr: true
          sarif_file: 'findings.sarif'
          pr_baseline: $GITHUB_BASE_REF
      - name: Endor Labs Reporting Scan
        if: github.event_name == 'push'
        uses: endorlabs/github-action@v1.1.1
        with:
          namespace: 'example'
          pr: false
          sarif_file: 'findings.sarif'
      - name: Endor Labs Testing Scan
        if: github.event_name == 'pull_request'
        uses: endorlabs/github-action@v1.1.1
        with:
          namespace: 'example'
          pr: true
          sarif_file: 'findings.sarif'
      - name: Upload findings to github
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: 'findings.sarif'

Each CI environment includes default environment variables that you can use to reference CI baselines in a template. See your CI providers’ documentation on default environment variables to determine the most suitable option for your requirements.

• See the GitHub Actions documentation for GitHub default variables.
• See the GitLab CI/CD documentation for the GitLab default variables.

Understand SARIF files

SARIF (Static Analysis Results Interchange Format) is an OASIS standard format for reporting static analysis results.

This standardized format allows you to:

• Integrate with multiple platforms: Upload results to GitHub Security, Azure DevOps, or other tools that support SARIF.
• Consolidate findings: Combine results from different security tools in a unified format.
• Automate workflows: Process and act on security findings programmatically.
• Track remediation: Monitor the status of security issues over time.

Endor Labs generates SARIF files that contain detailed information about security findings, dependency issues, and other analysis results from your scans.

SARIF file structure

A SARIF file contains several key components:

• Runs: Each scan execution creates a run with metadata about the scan.
• Results: Individual findings with details about dependency vulnerabilities, SAST findings, and secrets.
• Rules: Descriptions of the checks that were performed.
• Artifacts: Information about the files and dependencies that were analyzed.

Generate SARIF output using endorctl

SARIF files standardize security findings, enabling CI/CD integration, unified dashboards, and compliance reporting. They provide PR-level feedback, support long-term monitoring, and preserve historical data for auditing and tool migration.

To generate SARIF output with Endor Labs, use the --sarif-file or -s flag with the endorctl scan command:

endorctl scan --namespace=<your-namespace> --sarif-file findings.sarif

You can specify additional scan options when generating SARIF output, for example to include dependency scanning and git history secrets detection:

endorctl scan --sarif-file findings.sarif --dependencies --secrets --git-logs

Upload SARIF files to GitHub

GitHub Security supports SARIF file uploads, allowing you to view Endor Labs findings directly in your repository’s Security tab. You can upload SARIF files automatically using the GitHub App (Pro), through GitHub Actions, or manually.

Automatic upload using GitHub App (Pro)

When you configure Endor Labs GitHub App (Pro) with a GHAS SARIF exporter, findings are automatically exported and uploaded to GitHub after each scan. See Export findings to GitHub Advanced Security for detailed setup instructions.

Automated upload using GitHub Actions

Use the following GitHub Actions workflow step to automatically upload SARIF files.

- name: Upload SARIF file to GitHub
  uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: 'findings.sarif'

Manual upload via GitHub

To manually upload a SARIF file to GitHub:

1. Navigate to your GitHub repository.
2. Go to Security > Code scanning > Upload SARIF.
3. Select your SARIF file and upload it.

Endor-specific SARIF extensions

Endor Labs extends the standard SARIF format with custom fields that provide additional context for vulnerability analysis and remediation. These properties are included in the properties field of each SARIF result.

The following fields are available in SARIF results generated by Endor Labs:

• action-policies-triggered: List of action policies triggered by this finding.
• categories: List of categories the finding belongs to.
• cvss-score: Common Vulnerability Scoring System (CVSS) score, ranging from 0.0 to 10.0.
• cvss-vector: CVSS vector string describing the characteristics of the vulnerability.
• cvss-version: The version of the CVSS score used.
• epss-percentile-score: EPSS percentile score, showing how severe the vulnerability is compared to others.
• epss-probability-score: Exploit Prediction Scoring System (EPSS) probability score, indicating likelihood of exploitation.
• explanation: Detailed explanation of the finding and its implications.
• finding-url: URL to view the finding in Endor Labs.
• finding-uuid: Unique identifier for the finding.
• impact-score: Custom impact score assigned to the finding.
• project-uuid: Unique identifier for the project where the finding was discovered.
• remediation: Recommended steps to fix or mitigate the finding.
• tags: List of tags associated with the finding, used for categorization and filtering.

Here are examples of SARIF output for SCA, secrets, and SAST findings, including Endor-specific extensions.

• SCA findings
• Secrets detection
• SAST findings

{
  "results": [
    {
      "ruleId": "SCA-Vulnerability",
      "kind": "fail",
      "level": "error",
      "message": {
        "text": "CVE-2021-44228 in org.apache.logging.log4j:log4j-core@2.14.1 (maven) — upgrade to 2.17.1 or later."
      },
      "locations": [
        {
          "physicalLocation": {
            "artifactLocation": {
              "uri": "pom.xml"
            },
            "region": {
              "startLine": 42
            }
          }
        }
      ],
      "properties": {
        "action-policies-triggered": ["block-critical-vulns"],
        "categories": ["dependency", "security"],
        "cvss-score": 10.0,
        "cvss-vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
        "cvss-version": "V3_1",
        "epss-percentile-score": 0.97,
        "epss-probability-score": 0.97576,
        "explanation": "This version of log4j-core contains CVE-2021-44228, also known as Log4Shell. This is a critical remote code execution vulnerability that allows attackers to execute arbitrary code by controlling log message content.",
        "finding-url": "https://app.endorlabs.com/findings/abc123",
        "finding-uuid": "abc123-def456",
        "impact-score": 10.0,
        "project-uuid": "proj-789",
        "remediation": "Upgrade log4j-core to version 2.17.1 or later. If immediate upgrade is not possible, set the JVM parameter -Dlog4j2.formatMsgNoLookups=true as a temporary mitigation.",
        "tags": ["CVE-2021-44228", "log4shell", "critical", "rce"]
      }
    }
  ]
}

{
  "results": [
    {
      "ruleId": "AWS Access Token",
      "message": {
        "text": "Invalid AWS Access Token: ID #3da668"
      },
      "fullDescription": {
        "text": "Invalid secrets should be audited for suspicious activity and ignored."
      },
      "help": {
        "text": "Inspect any service logs to determine if the exposed secret has been used for suspicious activity.\n\nIf you'd like to ignore this issue add the comment \"endorctl:allow\" to the secret location in your code.\n"
      },
      "shortDescription": {
        "text": "Invalid AWS Access Token: ID #3da668"
      },
      "properties": {
        "finding-url": "https://app.endorlabs.com/findings/secret-456",
        "finding-uuid": "secret-456-def",
        "project-uuid": "proj-789",
        "security-severity": "1.0",
        "tags": [
          "INVALID_SECRET",
          "NORMAL",
          "POLICY"
        ]
      }
    }
  ]
}

{
  "results": [
    {
      "level": "note",
      "locations": [
        {
          "physicalLocation": {
            "artifactLocation": {
              "uri": "BackendServer/middlewares/validateToken.js"
            },
            "region": {
              "startLine": 77
            }
          }
        }
      ],
      "message": {
        "text": "Problem:\nHardcoded JWT secret or private key was found. Hardcoding secrets like JWT signing keys poses a significant security risk. If the source code ends up in a public repository or is compromised, the secret is exposed. Attackers could then use the secret to generate forged tokens and access the system. Store it properly in an environment variable.\n\nSolution:\nHere are some recommended safe ways to access JWT secrets:\n- Use environment variables to store the secret and access it in code instead of hardcoding. This keeps it out of source control.\n- Use a secrets management service to securely store and tightly control access to the secret. Applications can request the secret at runtime.\n- For local development, use a .env file that is gitignored and access the secret from process.env.\n\nsample code snippet of accessing JWT secret from env variables\n```\nconst token = jwt.sign(payload, process.env.SECRET, { algorithm: 'HS256' });\n```\n"
      },
      "properties": {
        "explanation": "The rule detects the use of hardcoded JWT secrets or private keys in JavaScript code. Hardcoding secrets like JWT signing keys poses a significant security risk because if the source code is exposed, the secret is compromised. This allows attackers to generate forged tokens, potentially gaining unauthorized access to systems and sensitive data. The impact is high because it directly affects the confidentiality and integrity of the application.",
        "finding-url": "https://app.endorlabs.com/findings/sast-789",
        "finding-uuid": "sast-789-ghi",
        "impact-score": 8.7,
        "project-uuid": "proj-789",
        "remediation": "To remediate the use of hardcoded JWT secrets, avoid embedding secrets directly in the source code. Instead, use environment variables to store secrets securely and access them in your code. For example, in JavaScript, you can use `process.env.SECRET` to access the secret stored in an environment variable:\n\n```javascript const token = jwt.sign(payload, process.env.SECRET, { algorithm: 'HS256' }); ```\n\nAdditionally, consider using a secrets management service to securely store and manage access to secrets. For local development, use a `.env` file that is gitignored to prevent it from being included in version control.",
        "tags": [
          "A07:2021",
          "Identification-and-Authentication-Failures",
          "OWASP-Top-10",
          "SANS-Top-25"
        ]
      },
      "ruleId": "Use of hard-coded credentials in JWT"
    }
  ]
}

Java is a high-level, object-oriented programming language widely used by developers. Endor Labs supports scanning and monitoring of Java projects.

Using Endor Labs, application security engineers and developers can:

• Scan their software for potential security issues and violations of organizational policy.
• Prioritize vulnerabilities in the context of their applications.
• Understand the relationships between software components in their applications.

System specifications for deep scan

Software prerequisites

Endor Labs requires the following prerequisites in place for successful scans.

• Install JDK versions between 11 and 25.0.2
  • For JDK 8, see Scan the projects on JDK version 8
• Make sure your repository includes one or more files with .java extension.
• Install Maven Package Manager version 3.6.1 and higher if your project uses Maven.
• Install Gradle build system version 6.0.0 and higher, if your project uses Gradle. To support lower versions of Gradle, see Scan projects on Gradle versions between 4.7 and 6.0.0.
• For projects not using Maven or Gradle, make sure that your project is set up properly to scan without the pom.xml file. See Scan projects without pom.xml for more information.

Build Java projects

You must build your Java projects before running a scan. Additionally, ensure that the packages are downloaded into the local package caches and that the build artifacts are present in the standard locations.

Use Gradle

To analyze your software built with Gradle, Endor Labs requires that the software be able to be successfully built. To perform a quick scan, dependencies must be located in the local package manager cache. The standard $GRADLE_USER_HOME/caches or /User/<username>/.gradle/caches must exist and contain successfully downloaded dependencies. To perform a deep scan the target artifact must be generated on the file system as well.

To build your project with Gradle, use the following procedure:

1. If you would like to run a scan against a custom configuration, specify the Gradle configuration by setting an environment variable.

      export endorGradleJavaConfiguration="<configuration>"
   

   When no configuration is provided, runtimeClasspath is used by default.

   If neither the user-specified nor the default configuration exists in the project, the system falls back to the following configurations, in order:

   1. runtimeClasspath
   2. runtime
   3. compileClasspath
   4. compile

   If the listed configurations are not found in the project, the system selects the first available configuration in alphabetical order.

2. Ensure that you can resolve the dependencies for your project without errors by running the following command:

   For Gradle wrapper:

      ./gradlew dependencies
   

   For Gradle:

      gradle dependencies
   

3. Run ./gradlew assemble or gradle assemble to resolve dependencies and to create an artifact that may be used for deep analysis.

Override subproject level configuration

In a multi-build project, if you set the environment variable endorGradleJavaConfiguration=[GlobalConfiguration], the specified configuration is used for dependency resolution across all projects and subprojects in the hierarchy below.

\--- Project ':samples'
     +--- Project ':samples:compare'
     +--- Project ':samples:crawler'
     +--- Project ':samples:guide'
     +--- Project ':samples:simple-client'
     +--- Project ':samples:slack'
     +--- Project ':samples:static-server'
     +--- Project ':samples:tlssurvey'
     \--- Project ':samples:unixdomainsockets'

To override the configuration only for the :samples:crawler and :samples:guide subprojects, follow these steps:

1. Navigate to the root workspace, where you execute endorctl scan, and run ./gradlew projects to list all projects and their names.

2. Run the following command at the root of the workspace:

   echo ":samples:crawler=testRuntimeClasspath,:samples:guide=macroBenchMarkClasspath" >> .endorproperties
   

   This creates a new file named .endorproperties in your root directory. This enables different configurations for the specified subprojects in the file.

3. Run endorctl scan.

At this point, all other projects will adhere to the GlobalConfiguration. However, the :samples:crawler subproject will use the testRuntimeClasspath configuration, and the :samples:guide subproject will use the macroBenchMarkClasspath configuration.

Configure private Gradle package repositories

Endor Labs supports fetching and scanning dependencies from private Gradle package registries. Endor Labs will fetch resources from authenticated endpoints and perform the scan, allowing you to view the resolved dependencies and findings. See Gradle package manager integrations for more information on configuring private registries.

Use Maven

To analyze your software built with Maven, Endor Labs requires that the software be able to be successfully built. To perform a quick scan, dependencies must be located in the local package manager cache. The standard .m2 cache must exist and contain successfully downloaded dependencies. To perform a deep scan the target artifact must be generated on the file system as well.

To build your project with Maven, use the following procedure:

1. Ensure that you can resolve the dependencies for your project without error by running the following command.

    mvn dependency:tree
   

2. Run mvn install and make sure the build is successful.

 mvn install -DskipTests

3. If you have multiple Java modules not referenced in the root pom.xml file, make sure to run mvn install separately in all the directories.

Configure private Maven package repositories

Endor Labs supports fetching and scanning dependencies from private Maven package registries. Endor Labs will fetch resources from authenticated endpoints and perform the scan, allowing you to view the resolved dependencies and findings. See Maven package manager integrations for more information on configuring private registries.

Run a scan

Use the following options to scan your repositories. Perform a scan after building the projects.

Option 1 - Quick scan

Perform a quick scan to get quick visibility into your software composition. This scan won’t perform reachability analysis to help you prioritize vulnerabilities.

endorctl scan --quick-scan

You can perform the scan from within the root directory of the Git project repository, and save the local results to a results.json file. The results and related analysis information are available on the Endor Labs user interface.

endorctl scan --quick-scan -o json | tee /path/to/results.json

You can sign in to the Endor Labs user interface, click the Projects on the left sidebar, and find your project to review its results.

Option 2 - Deep scan

Use the deep scan to perform dependency resolution, reachability analysis, and generate call graphs. You can do this after you complete the quick scan successfully.

endorctl scan

Use the following flags to save the local results to a results.json file. The results and related analysis information are available on the Endor Labs user interface.

endorctl scan -o json | tee /path/to/results.json

When deep analysis is performed all private software dependencies are completely analyzed by default if they have not been previously scanned. This is a one-time operation and will slow down initial scans, but won’t impact subsequent scans.

Organizations might not own some parts of the software internally and the related findings are not actionable by them. They can choose to disable this analysis using the flag disable-private-package-analysis. By disabling private package analysis, teams can enhance scan performance but may lose insights into how applications interact with first-party libraries.

Use the following command flag to disable private package analysis:

endorctl scan --disable-private-package-analysis

You can sign in to the Endor Labs user interface, click the Projects on the left sidebar, and find your project to review its results.

Scan projects without pom.xml

Endor Labs supports projects that do not use Maven or Gradle, and have no pom.xml in the following cases.

Uber jars

If there is an uber jar (fat jar) that contains all application classes and dependency jars of the project, you can set the environment variable, ENDOR_JVM_USE_ARTIFACT_SCAN as true and run the scan.

export ENDOR_JVM_USE_ARTIFACT_SCAN=true
endorctl scan --package --path=<jar/ear/war location> --project-name=<project name>

For example:

export ENDOR_JVM_USE_ARTIFACT_SCAN=true
endorctl scan --package --path=/Users/johndoe/projects/project21.jar --project-name=Project21

Application dependencies in classpath

If you do not have an uber jar with dependencies, but only have application dependency files (like jar, war, or ear), you can set the path to these files in the environment variable, ENDOR_JVM_USE_ARTIFACT_SCAN_CLASSPATH and run the scan.

export ENDOR_JVM_USE_ARTIFACT_SCAN=true
export ENDOR_JVM_USE_ARTIFACT_SCAN_CLASSPATH=<path that contains application depedencies>
endorctl scan --package --path=<jar/ear/war location> --project-name=<project name>

For example:

export ENDOR_JVM_USE_ARTIFACT_SCAN=true
export ENDOR_JVM_USE_ARTIFACT_SCAN_CLASSPATH=/Users/johndoe/caches/modules/files-2.1
endorctl scan --package --path=/Users/johndoe/projects/project21.jar --project-name=Project21

Application classes and dependencies extracted as first-party class files

If application class files and dependency jar files are extracted as first-party class files, you can provide the first-party files in an environment variable, ENDOR_JVM_FIRST_PARTY_PACKAGE.

export ENDOR_JVM_USE_ARTIFACT_SCAN=true
export ENDOR_JVM_FIRST_PARTY_PACKAGE="<dependency/application 1>,<dependency/application 2>,...,<dependency/application N>"
endorctl scan --package --path=<jar/ear/war location> --project-name=<project name>

For example:

Your project jar has the following structure where com.org.doe and com.org.deer are application class files and dependencies.

fawn.jar
├── com.org.doe
│   ├── A.class
│   └── B.class
├── com.org.deer
│   ├── Util.class
│   └── Utilities.class
├── com.org.dep1
│   ├── Dep1.class
│   └── Dep2.class
└── com.org.dep2
    ├── 2Dep1.class
    └── 2Dep2.class

export ENDOR_JVM_USE_ARTIFACT_SCAN=true
export ENDOR_JVM_FIRST_PARTY_PACKAGE="com.org.doe,com.org.deer"
endorctl scan --package --path=/Users/johndoe/projects/fawn.jar --project-name=Fawn

Scan the projects on JDK version 8

Endor Labs supports JDK versions between 11-25.0.2, however, you can scan projects on JDK 8 using the following procedure:

1. Build your Java project on JDK 8.

2. After building, switch your Java home to JDK 11 or higher versions.

   export JAVA_HOME=/Library/Java/JavaVirtualMachines/openjdk-11.jdk/Contents/Home
   

3. Run a scan

Scan projects on Gradle versions between 4.7 and 6.0.0

To scan Java projects on Gradle versions between 4.7 and 6.0.0, make sure to

1. Check the version of your project using:

   ./gradlew --version
   

2. The project must have a Gradle wrapper. You can generate the Gradle wrapper using:

   --gradle-version <your required version>.
   

   Endor Labs prioritizes Gradle wrapper over Gradle and it is a recommended best practice to use Gradle Wrapper.

3. Before executing the endorctl scan, ensure the project can be built in your required version.

   Execute ./gradlew assemble.
   

4. Use --bypass-host-check during endorctl scan to execute scans on projects that have Gradle versions lower than 6.0.0.

Understand the scan process

Endor Labs analyzes your Java code and dependencies to detect known security issues, including open-source vulnerabilities and generates call graphs.

How Endor Labs resolves dependencies for package versions

Endor Labs resolves the dependencies for Java packages based on the following factors:

• For packages built using Maven, it leverages the Maven cache in the .m2 directory of your file system to resolve the package’s dependencies and mirrors Maven’s build process for the most accurate results.
• For Maven, Endor Labs respects the configuration settings present in the settings.xml file. If this file is included in your repository, you need not provide any additional configuration.
• For packages built using Gradle, it uses Gradle and Gradle wrapper files to build packages and resolve dependencies.
• Endor Labs supports EAR, JAR, RAR, and WAR files.

How Endor Labs performs static analysis on the code

Endor Labs performs static analysis on the Java code based on the following factors:

• Call graphs are created for your package. These are then combined with the call graphs of the dependencies in your dependency tree to form a comprehensive call graph for the entire project.
• Endor Labs performs an inside-out analysis of the software to determine the reachability of dependencies in your project.
• The static analysis time may vary depending on the number of dependencies in the package and the number of packages in the project.

Known limitations

• If a package can not be successfully built in the source control repository, static analysis will fail.
• Spring dependencies are analyzed based on spring public entry points to reduce the impact of Inversion of Control (IOC) frameworks. Dependencies and functions are identified as reachable and unreachable in the context of a spring version and its entry points.
• Annotation processing is limited only to the usage of the code they annotate.
• Static analysis of reflection and callbacks are not supported.
• Endor Labs requires JDK 11 to generate call graphs for Java projects. Gradle versions lacking JDK 11 support are not compatible.

Troubleshoot errors

Here are a few error scenarios that you can check for and attempt to resolve them.

• Host system check failure errors:

  • Java is not installed or not present in the PATH environment variable. Install Java and try again. See Java documentation for more information.
  • The installed version of Java is lower than the required version. Install JDK versions between 11-25.0.2 and try again.
  • Java is installed but Maven or Gradle is not installed. In such cases, the dependency resolution may not be complete.

• Unresolved dependency errors: Maven is not installed properly or the system is unable to build root pom.xml. Run mvn dependency:tree in the root of the project and try again. In such cases, the dependency resolution may not be complete.

• Resolved dependency errors: A version of a dependency does not exist or it cannot be found. It may have been removed from the repository.

• Gradle variant incompatibility message: Gradle performs JVM toolchain checks for subprojects or dependencies and may raise errors indicating a Java version mismatch between dependencies declared in Gradle manifest and Java home setup.

  Example error message:

  Incompatible because this component declares a component for use during compile-time, compatible with Java version 21 and the consumer needed a component for use during runtime, compatible with Java version 17 - To resolve this and taking advantage of Java’s backward compatibility, instruct Gradle to use the higher version of JDK detected in the error message. For example, for the message above, specify org.gradle.java.home=<path of java> in .gradle/gradle.properties. The path needs to be to the root of the directory bin/java. For example, if your Java is at /Users/Downloads/jdk-21/Contents/Home/bin/java, specify org.gradle.java.home=/Users/Downloads/jdk-21/Contents/Home. - If you are scanning a purely Java 8 Gradle project and if you encounter the above error, set org.gradle.java.home to point to Java 8 home, before you execute the endorctl scan. - A general guideline for determining which Java version to use, is to match the Java version specified in .gradle/gradle.properties with the one used for building your Gradle project.

• Call graph errors: - The project can not be built because a dependency cannot be located in the repository. - Sometimes, the project is not built, if a Java version discrepancy exists between the required repository version and the version on the system running the scan. For example, the Java required version is 1.8 but the system has 12 installed. Install the required version and try again.

• If you have a private registry and internal dependencies on other projects, you must configure the credentials of the registry. See Configure Maven private registries.

• If you have a large repository or if the scan fails with out-of-memory issues, you may need to increase the JVM heap size before you can successfully scan. Export the ENDOR_SCAN_JVM_PARAMETERS environment variable with additional JVM parameters before performing the scan as shown below:

  export ENDOR_SCAN_JVM_PARAMETERS="-Xmx32G"
  

• If you use a remote repository configured to authenticate with a client-side certificate, you must add the certificate through an endorctl parameter. Export the ENDOR_SCAN_JVM_PARAMETERS parameter before performing a scan. See Maven documentation for details.

  export ENDOR_SCAN_JVM_PARAMETERS="-Xmx16G,-Djavax.net.ssl.keyStorePassword=changeit,
  -Djavax.net.ssl.keyStoreType=pkcs12,
  -Djavax.net.ssl.keyStore=/Users/myuser/Documents/nexustls/client-cert1.p12"
  

Python is a high-level, interpreted programming language widely used by developers. Endor Labs supports the scanning and monitoring of Python projects.

Using Endor Labs, application security engineers and developers can:

• Scan their software for potential security issues and violations of organizational policy.
• Prioritize vulnerabilities in the context of their applications.
• Understand the relationships between software components in their applications.

System specifications for deep scan

Software prerequisites

Ensure that the following prerequisites are complete:

• Install Python 3.6 or higher versions. Refer to the Python documentation for instructions on how to install Python.
• For UV managed projects, Python 3.8 or higher is required. To enable UV support, set the environment variable ENDOR_SCAN_ENABLE_UV_PACKAGE_MANAGER=true.
• Ensure that the package manager pip, Poetry, PDM, UV, or Pipenv is used by your projects to build your software packages.
• If you are using pip with Python 3.12 or higher versions, install setuptools.
• Set up any build, code generation, or other dependencies that are required to install your project’s packages.
• Organize the project as one or more packages using setup.py, setup.cfg, pyproject.toml, or requirements.txt package manifest files.
• Make sure your repository includes one or more files with .py extension or pass either one of requirements.txt, setup.py, setup.cfg or pyproject.toml using the --include-path flag. See Scoping scans.

Build Python projects

Creating a virtual environment and building your Python projects before running the endorctl scan is recommended for the most accurate results. Endor Labs attempts to automatically create and configure a virtual environment when one is not provided, but this may not work for complex projects. Ensure that the packages are downloaded into the local package caches and that the build artifacts are present in the standard locations.

1. Configure any private repositories
   • If you use dependencies from a PyPI compatible repository other than pypi.org, configure it in the Integrations section of the Endor Labs web application. See Configure private PyPI package repositories for more details.
2. Clone the repository and optionally create a virtual environment inside it

   1. Clone the repository using git clone or an equivalent workflow.

   2. Enter the working copy root directory that’s created.

   3. Create a virtual environment based on your package manager:

      For pip or setuptools

      • Use python3 -m venv venv. Set up the virtual environment in the root folder that you want to scan and name it venv or .venv.
      • Install your project’s dependencies using venv/bin/python -m pip install -r requirements.txt or venv/bin/python -m pip install.
      • If the virtual environment is created outside the project, use one of the ways defined in Virtual environment support to specify the path of the Python virtual environment to Endor Labs.

      For Poetry projects

      • Install your project’s dependencies using poetry install.

      For PDM projects

      • Install your project’s dependencies using pdm install.

      For Pipenv projects

      • Run pipenv install in the project directory. This creates a Pipfile.lock (if it doesn’t exist) and sets up a virtual environment while installing the required packages.

Virtual environment support

Creating a virtual environment is recommended to ensure consistent and accurate scan results, and to verify that all dependencies install correctly before scanning. Automatic setup may encounter issues such as:

• Complex dependency chains or conflicting package requirements
• Private packages requiring authentication
• System-level dependencies not available in the scan environment
• Non-standard project structures or custom build scripts

Endor Labs attempts to automatically detect, create, or configure virtual environments for your projects. The behavior varies by package manager.

If you do not set up the virtual environment, Endor Labs attempts to set it up with all the code dependencies, however, we recommend that you install all dependencies in a virtual environment for the most accurate results.

If you are using custom scripts without manifest files to assemble your dependencies, make sure to set up the virtual environment and install the dependencies.

Configure private PyPI package repositories

Endor Labs supports fetching and scanning dependencies from private PyPI package registries. Endor Labs will fetch resources from authenticated endpoints and perform the scan, allowing you to view the resolved dependencies and findings. See PyPI package manager integrations for more information on configuring private registries.

Run a scan

Use the following options to scan your repositories. Perform the endorctl scan after building the projects.

Option 1 - Quick scan

Perform a quick scan to get quick visibility into your software composition and perform dependency resolution. It discovers dependencies that the package has explicitly declared. If the package’s build file is incomplete then the dependency list will also be incomplete. This scan won’t perform reachability analysis to help you prioritize vulnerabilities.

endorctl scan --quick-scan

You can perform the scan from within the root directory of the Git project repository, and save the local results to a results.json file. The results and related analysis information are available on the Endor Labs user interface.

endorctl scan --quick-scan -o json | tee /path/to/results.json

You can sign in to the Endor Labs user interface, click the Projects on the left sidebar, and find your project to review its results.

Option 2 - Deep scan

Use the deep scan to perform dependency resolution, reachability analysis, and generate call graphs. You can do this after you complete the quick scan successfully. The deep scan performs the following operations for the Python projects.

• Discovers explicitly declared dependencies,
• Discovers project dependent OSS packages present in the venv/global and scope/python.
• Performs reachability analysis and generates call graphs.
• Detects dependencies used in source code but not declared in the package’s manifest files called phantom dependencies.

endorctl scan

Use the following flags to save the local results to a results.json file. The results and related analysis information are available on the Endor Labs user interface.

endorctl scan -o json | tee /path/to/results.json

When a deep scan is performed all private software dependencies are completely analyzed by default if they have not been previously scanned. This is a one-time operation and will slow down initial scans, but won’t impact subsequent scans.

Organizations might not own some parts of the software internally and the related findings are not actionable by them. They can choose to disable this analysis using the flag disable-private-package-analysis. By disabling private package analysis, teams can enhance scan performance but may lose insights into how applications interact with first-party libraries.

You can sign in to the Endor Labs user interface, click the Projects on the left sidebar, and find your project to review its results.

Understand the scan process

Endor Labs uses the following two methods to analyze your Python code.

• Dependency resolution using manifest files
• Dependency resolution using static analysis

Endor Labs uses the results from both these methods to perform superior dependency resolution, identify security issues, detect open-source vulnerabilities, and generate call graphs.

Dependency resolution using manifest files

In this method, Endor Labs analyzes the manifest files present in a project to detect and resolve dependencies. The manifest files are analyzed in the following priority.

For Poetry, PDM, and UV, when both lock and toml files are present, both files are analyzed to detect and resolve dependencies.

For pip, the dependency resolution is as follows, where the first available file in the priority list is analyzed to detect and resolve dependencies, and others are ignored.

On initialization of a scan, Endor Labs identifies the package manager by inspecting files such as the pyproject.toml, poetry.lock, pdm.lock, setup.py, and requirements.txt. When the files, poetry.lock or pyproject.tomlfiles are discovered, Endor Labs will use the Poetry package manager to build the project. When the files, pdm.lock or pyproject.toml files are discovered, Endor Labs will use the PDM package manager. Otherwise, it will use pip3.

Example

This is an example that demonstrates scanning a Python repository from GitHub on your local system using the endorctl scan. Here we are assuming that you are running the scan on a Linux or Mac operating system environment and that you have the following Endor Labs API key and secret stored in the environment variables. See endorctl flags and variables.

• ENDOR_API_CREDENTIALS_KEY set to the API key
• ENDOR_API_CREDENTIALS_SECRET set to the API secret
• ENDOR_NAMESPACE set to your namespace (you can find this when logged into Endor Labs by looking at your URL: https://app.endorlabs.com/t/NAMESPACE/...; it is typically a form of your organization’s name)

pip

git clone https://github.com/HybirdCorp/creme_crm.git
cd creme_crm
python3 -m venv venv
source venv/bin/activate
venv/bin/python3 -m pip install
endorctl scan

Poetry

git clone https://github.com/HybirdCorp/creme_crm.git
cd creme_crm
poetry lock
endorctl scan

PDM

git clone https://github.com/HybirdCorp/creme_crm.git
cd creme_crm
pdm install
endorctl scan

UV

git clone https://github.com/example/repo.git
cd repo
endorctl scan

Pipenv

git clone https://github.com/example/repo.git
cd repo
pipenv install
endorctl scan

The scan for this repository is expected to be completed in a few minutes depending on the size of the project. You can now visit app.endorlabs.com, navigate to Projects, and choose the helloflas/flask-examples project to see your scan results.

Handling custom and multiple requirement files in pip

In some organizations, custom file names, such as default.txt, are used for requirement files instead of the standard requirements.txt. Additionally, some repositories may include multiple requirement files with different names.

To specify custom file names as requirement files, export the file name using the ENDOR_SCAN_PYTHON_REQUIREMENTS environment variable and then run the endorctl scan.

export ENDOR_SCAN_PYTHON_REQUIREMENTS=default.txt

To resolve dependencies from multiple requirement files, export them as a comma-separated list using the ENDOR_SCAN_PYTHON_REQUIREMENTS environment variable and then run the endorctl scan.

export ENDOR_SCAN_PYTHON_REQUIREMENTS=default.txt,requirements.txt

Dependency resolution using static analysis

All Python projects do not always include manifest files. A project can be a series of install statements that are assembled by custom scripts. Even when manifest files are present, the dependency information and version declared in the manifest file may be drastically different from what is used in a project.

To solve this problem, Endor Labs has developed a unique method for dependency resolution by performing a static analysis on the code, giving you complete visibility of what is used in your code.

• Endor Labs enumerates all Python packages and recognizes the import statements within the project. An import statement is a Python code statement that is used to bring external modules or libraries into your Python script.
• It performs a static analysis of the code to match the import statements with the pre-installed packages and recursively traverses all files to create a dependency tree with the actual versions that are installed in the virtual environment.
• It detects the dependencies at the system level to identify which ones are resolved and retrieves the precise name and version information from the library currently in use.
• Also, it gives you accurate visibility into your project components and helps you understand how the components depend on one another.

Through this approach, Endor Labs conducts comprehensive dependency management, assesses reachability, and generates integrated call graphs.

Known Limitations

• Endor Labs specifically looks for the requirements.txt file for a Python project using pip. If you use a different file name, it won’t be automatically discovered.
• Python versions older than 3.7 are not supported but may work as expected.
• If a virtual environment is not provided, Python version constraints are not assumed based on the runtime environment of CI. Dependencies are shown for all possible versions of Python at runtime. If a virtual environment is provided, Endor Labs respects what is installed in the virtual environment.
• Symbolic links into manifest files may result in the same package being duplicated in the project.
• If a dependency is not available in the PyPI repository or in a configured private package repository, Endor Labs will be unable to build the software and scans may fail without first building the package in the local environment successfully.
• A project is treated as UV-managed if its pyproject.toml file contains the tool.uv key. Additionally, any member of a UV workspace is also considered UV-managed, even if its individual manifest file does not include the tool.uv key.
• When scanning UV workspaces, Endor Labs uses the workspace-level lock file for dependency resolution. Individual workspace members are not scanned as independent projects, ensuring consistency with UV’s workspace architecture.
• Inline script dependencies defined within Python script files are not currently detected during scanning.

Call Graph Limitations

• Function calls using dispatch table calls might not be included in the call graph.
• Function calls using unresolved variables might not be included in the call graph.
• Dynamically modified or extended function calls used to declare methods or attributes at run time might not be included in the call graph.
• Functions called indirectly through a function pointer and not by their direct name, might not be included in the call graph.
• Type stubs that provide hints or type annotations for functions, methods, and variables in your Python modules or libraries have to be installed manually before performing a scan.
• If your project has a pyproject.toml file that includes tools.pyright section, it overrides Endor Labs settings for Pyright and may result in incorrect call graph results. You will need to remove the tools.pyright section from the pyproject.toml file.

Troubleshoot errors

Here are a few error scenarios that you can check for and attempt to resolve them.

Go or Golang is a software development programming language widely used by developers. Endor Labs supports scanning and monitoring of Go projects.

Using Endor Labs, application security engineers and developers can:

• Scan their software for potential security issues and violations of organizational policy.
• Prioritize vulnerabilities in the context of their applications.
• Understand the relationships between software components in their applications.

System specifications for deep scan

Software prerequisites

• Make sure that you have Go 1.12 or higher versions.
• Make sure your repository includes one or more files with .go extension.

Build Go projects

You must build your Go projects before running the scan. Additionally, ensure that the packages are downloaded into the local package caches and that go.mod file well formed and is available in the standard location.

To ensure that your go.mod file is well formed, run the following command:

go mod tidy

go get ./

This removes any dependencies that are not required by your project and ensures to resolve the dependencies without errors.

Run a scan

Use the following options to scan your repositories. Perform the endorctl scan after building the projects.

Option 1 - Quick scan

Perform a quick scan to get quick visibility into your software composition. This scan won’t perform reachability analysis to help you prioritize vulnerabilities.

endorctl scan --quick-scan

You can perform the scan from within the root directory of the Git project repository, and save the local results to a results.json file. The results and related analysis information are available on the Endor Labs user interface.

endorctl scan --quick-scan -o json | tee /path/to/results.json

You can sign into the Endor Labs user interface, click the Projects on the left sidebar, and find your project to review its results.

Option 2 - Deep scan

Use the deep scan to perform dependency resolution, reachability analysis, and generate call graphs. You can do this after you complete the quick scan successfully.

endorctl scan

Use the following flags to save the local results to a results.json file. The results and related analysis information are available on the Endor Labs user interface.

endorctl scan -o json | tee /path/to/results.json

You can sign into the Endor Labs user interface, click the Projects on the left sidebar, and find your project to review its results.

Understand the scan process

Endor Labs resolves your Golang-based dependencies by leveraging built-in Go commands to replicate the way a package manager would install your dependencies.

To discover package names for Go packages Endor Labs uses the command:

GOMOD=off go list -e -mod readonly -json -m

To analyze the dependency graph of your package Endor Labs uses the command:

GOMOD=off go list -e -deps -json -mod readonly all

To assess external dependencies, specifically third-party packages or libraries that your Go project relies on, Endor Labs uses the command:

GOMOD=off go list -e -deps -json -mod vendor all

These commands allow us to assess packages’ unresolved dependencies, analyze the dependency tree, and resolve dependencies for your Go projects.

Known Limitations

Endor Labs creates go.mod files for you when projects do not have a go.mod file. This can lead to inconsistencies with the actual package created over time and across versions of the dependencies.

Troubleshoot errors

Here are a few error scenarios that you can check for and attempt to resolve them.

• Host system check failure errors:

  • Go is not installed or not present in the PATH environment variable. Install Go and try again.
  • The installed version of Go is lower than 1.12. Install Go version 1.12 or higher and try again.

• Resolved dependency errors:

  • A version of a dependency does not exist or it cannot be found. It may have been removed from the repository.
  • If the go.mod file is not well-formed then dependency resolution may return errors. Run go mod tidy and try again.

• Call graph errors:

  These errors often mean the project won’t build. Please ensure any generated code is in place and verify that go build ./... runs successfully.

JavaScript is a high-level, interpreted programming language primarily used for creating interactive and dynamic web content widely used by developers. Endor Labs supports the scanning and monitoring of JavaScript projects.

Using Endor Labs, application security engineers and developers can:

• Scan their software for potential security issues and violations of organizational policy.
• Prioritize vulnerabilities in the context of their applications.
• Understand the relationships between software components in their applications.

System specifications for deep scan

Software prerequisites

• Endor Labs requires the following pre-requisite software to be installed to successfully perform a scan:
  • Yarn: Any version
  • npm: 6.14.18 or higher versions
  • pnpm: 3.0.0 or higher versions
• Make sure your repository includes one or more files with .js or .ts extension.

To run deep scanning for JavaScript and TypeScript projects make sure you have the following prerequisites installed:

• Ensure you have endorctl version 1.7.0 or higher installed.

• Ensure Node.js version 4.2.6 or higher is installed to support TypeScript version 4.9.

• Ensure TypeScript version 4.9 or higher is installed.

• Install tsserver. tsserver is included with TypeScript, so installing the appropriate TypeScript version automatically installs tsserver.

  Install the appropriate TypeScript version based on your Node.js version.

• Use the following command based on your Node.js version to install typescript:

• 14.17 or higher
• Between 12.2 and 14.17
• Lower than 12.2

npm install -g typescript

npm install -g typescript@5.0

npm install -g typescript@4.9

• If you’re unsure make sure you check the tsserver installation

# Run 'which tsserver' to confirm installation
which tsserver

If you are running the endorctl scan with --install-build-tools, you don’t need to install tsserver. See Configure build tools for more information.

Build JavaScript projects

You can choose to build your JavaScript projects before running a scan. This will ensure that either a package-lock.json, yarn.lock, or pnpm-lock.yaml file is created enhancing the scan speed.

Ensure your repository has package.json and run the following command making sure it builds the project successfully.

• For npm
• For Yarn
• For pnpm

npm install

yarn install

pnpm install

If the project is not built, endorctl builds the project during the scan and generate either package-lock.json, yarn.lock, or pnpm-lock.yaml file. Make sure that either npm, Yarn, or pnpm is installed on your system. If your repository includes a lock file, endorctl uses the existing file for dependency resolution and does not create it again.

The npm install command may fail in a subdirectory if your project is set up with a package-lock.json file available at the root of the repository and not in the sub-packages as shown in the following example.

 .
 ├── package.json
 ├── package-lock.json
 └── sub-package/
     └── package.json

You need to instruct endorctl to use the root-level lock file to avoid scan failures in monorepo setups where dependencies are centrally managed at the root.

Set the following environment variable before you run the scan.

export ENDOR_JS_USE_ROOT_DIR_LOCK_FILE=true

Configure call graph generation timeout

When generating call graphs for JavaScript/TypeScript projects, endorctl uses tsserver to analyze the code. By default, tsserver waits 15 seconds for a response before timing out. For large or complex projects, you may need to increase this timeout.

Set the ENDOR_JS_TSSERVER_TIMEOUT environment variable to specify the timeout in seconds.

export ENDOR_JS_TSSERVER_TIMEOUT=30

Increasing the timeout might be beneficial in the following scenarios:

• Large monorepos with many TypeScript files
• Projects with complex type hierarchies
• Projects with extensive type checking requirements

Override JavaScript package manager detection

endorctl detects the JavaScript package manager automatically. You can override this detection by setting the ENDOR_JS_PACKAGE_MANAGER environment variable to npm, yarn, pnpm, or lerna.

For example, to use npmas the package manager run the following command.

export ENDOR_JS_PACKAGE_MANAGER=npm

This setting forces endorctl to use the specified package manager and overrides all other JavaScript package manager configuration variables.

Run a scan

Perform a scan to get visibility into your software composition and resolve dependencies.

endorctl scan

Understand the scan process

Dependency analysis tools analyze the lock file of an npm, yarn, or pnpm based package and attempt to resolve dependencies. To resolve dependencies from private repositories, the settings of the .npmrc file in the repository is considered.

Endor Labs surpasses mere manifest file analysis by expertly resolving JavaScript dependencies and identifies:

• Dependencies listed in the manifest file but not used by the application
• Dependencies used by the application but not listed in the manifest file
• Dependencies listed in the manifest as transitive but used directly by the application
• Dependencies categorized as test in the manifest, but used directly by the application

Developers can eliminate the false positives, false negatives, and easily identify test dependencies with this analysis. The dependencies used in source code but not declared in the package’s manifest files are tagged as Phantom.

Endor Labs also supports npm, Yarn, and pnpm workspaces out-of-the-box. If your JavaScript frameworks and packages use workspaces, Endor Labs will automatically take the dependencies from the workspace to ensure that the package successfully builds.

Scan speed is enhanced if the lock file exists in the repository. endorctl does not perform a build and uses the existing files in the repository for analysis.

Configure private npm package repositories

Endor Labs supports fetching and scanning dependencies from private npm package registries. Endor Labs will fetch resources from authenticated endpoints and perform the scan, allowing you to view the resolved dependencies and findings. See npm package manager integrations for more information on configuring private registries.

Known Limitations

• Endor Labs doesn’t currently support local package references
• If a dependency can not be resolved in the lock file, building that specific package may be unsuccessful. This package may have been removed from npm or the .npmrc file is not properly configured. Other packages in the workspace are scanned as usual.

Call graph limitations

• Functions that are passed in as arguments to call expressions might not be included in the call graph.
• Functions that are returned and then called might not be included in the call graph.
• Functions that are assigned to a variable based on a runtime value might not be included in the call graph.
• Functions that are assigned to an array element might not be included in the call graph.

Troubleshoot errors

• Unresolved dependency errors: The manifest file package.json is not buildable. Try running npm install, yarn install, or pnpm install in the root project to debug this error.
• Resolved dependency errors: A version of a dependency does not exist or it cannot be found. It may have been removed from the repository.

C and C++ are powerful, high-performance programming languages widely used for system programming, application development, and embedded systems. Endor Labs supports scanning and monitoring of C and C++ projects.

Using Endor Labs, application security engineers and developers can:

• Scan their software for potential security issues and violations of organizational policy.
• Prioritize vulnerabilities in the context of their applications.
• Understand the relationships between software components in their applications.

Run a scan

To scan your C and C++ repositories, run the following command.

endorctl scan --languages=c

Use the following flags to save the local results to a results.json file. The results and related analysis information are available on the Endor Labs user interface.

endorctl scan --languages=c -o json | tee /path/to/results.json

View scan results

You can sign in to the Endor Labs user interface, click the Projects on the left sidebar, and find your project to review its results.

Understand the scan process

Endor Labs detects vulnerabilities by testing your code against its proprietary database, which is regularly updated. Endor Labs does not build your code, so all dependencies and vendor code must be included within the source. If the build process pulls in additional packages, they must also be present in the scanned directory.

Endor Labs analyzes source code using a combination of code signatures and embeddings. The system extracts source code from various data sources and applies language-specific segmentation to break the code into functions and segments. This method facilitates efficient similarity searches, helping to detect duplicated code across repositories and supporting comprehensive software composition analysis.

By comparing file hashes, segment hashes, and embeddings, Endor Labs can query data to identify matches with code segments. This capability streamlines the detection of copied code and the dependency relationships between repositories, providing insights into code components from various sources, including Git repositories, online archives, and other package distributions. Headers and code files are scanned regardless of their file extension.

To optimize performance, Endor Labs caches embeddings and signatures, making subsequent scans faster than the first scan. This means only newly added or modified files require computation, significantly reducing scan times.

Enable code segment embeddings

Embeddings are disabled by default and require the Endor Labs AI license.

To enable embeddings go to Settings near the bottom of the left sidebar, navigate to Data Privacy under System Settings, check the box for Code Segment Embeddings and LLM Processing and click Save Data Privacy Settings.

To override the system-wide configuration for a specific scan, set ENDOR_SCAN_EMBEDDINGS to true to enable embeddings or false to disable them. This setting takes precedence over the system configuration.

export ENDOR_SCAN_EMBEDDINGS=false

Limitations

Scanning binary library files such as .so and .a files is not supported.

PHP is a popular server-side scripting language primarily used for web development. Endor Labs supports the scanning and monitoring of PHP projects.

Using Endor Labs, application security engineers and developers can:

• Scan their software for potential security issues and violations of organizational policy.
• Prioritize vulnerabilities in the context of their applications.
• Understand the relationships between software components in their applications.

Software prerequisites

• One of the following prerequisites must be fulfilled:
  • The PHP project must contain a composer.json file. If the project includes the composer.lock file it is beneficial, but this is not a mandatory requirement.
  • If the composer.lock file is not present in the repository, it is necessary to have PHP and Composer installed before running a scan on your local system.
• Make sure your repository includes one or more files with .php extension.
• The following versions are supported for PHP and Composer:
  • PHP 5.3.2 and higher versions
  • Composer 2.2.0 and higher versions

Build PHP projects

You can choose to build your PHP projects before running a scan. This will ensure that composer.lock is created.

Ensure your repository has composer.json and run the following command making sure it builds the project successfully.

composer install

If the project is not built, endorctl will build the project during the scan and generate composer.lock. If the repository includes a composer.lock, endorctl uses this file for dependency resolution and does not create it again.

Configure private Composer package repositories

Endor Labs supports fetching and scanning dependencies from private package registries. Endor Labs will fetch resources from authenticated endpoints and perform the scan, allowing you to view the resolved dependencies and findings. See package manager integrations for more information on configuring private registries.

Run a scan

Perform a scan to get visibility into your software composition and resolve dependencies.

endorctl scan

You can perform the scan from within the root directory of the Git project repository, and save the local results to a results.json file. The results and related analysis information are available on the Endor Labs user interface.

endorctl scan -o json | tee /path/to/results.json

You can sign into the Endor Labs user interface, click the Projects on the left sidebar, and find your project to review its results.

Understand the scan process

Endor Labs discovers all composer.json files in your PHP project and uses these files to resolve the dependencies of your packages. Composer is a PHP dependency management tool that enables you to specify the libraries your project relies on and manages the process of installing or updating them. The dependencies and findings are listed in the Endor Labs application individually for every composer.json file.

In Endor Labs’ dependency management, the resolution of dependencies is based on both composer.json and composer.lock files. The composer.lock file is generated by Composer and includes information such as resolved versions, package information, transitive dependencies, and other details. Using the composer.lock file ensures deterministic dependency installation by recording the exact versions of installed dependencies and their transitive dependencies. If the composer.lock file is not present in the repository, Endor Labs generates the composer.lock file, and uses it to analyze the operational and security risks associated with your package’s dependencies. Endor Labs fetches the dependency information and creates a comprehensive dependency graph.

Known Limitations

Call graphs are not supported for PHP projects.

Troubleshoot errors

• Unresolved dependency errors: The composer.json is not buildable. Try running composer install in the root project to debug this error.
• Resolved dependency errors: A version of a dependency does not exist or it cannot be found. It may have been removed from the repository.

Kotlin is a statically typed programming language that runs on the Java Virtual Machine (JVM), known for its concise syntax, null safety, and seamless integration with Java. Endor Labs supports scanning and monitoring of Kotlin projects.

Using Endor Labs, application security engineers and developers can:

• Scan their software for potential security issues and violations of organizational policy.
• Prioritize vulnerabilities in the context of their applications.
• Understand the relationships between software components in their applications.

System specifications for deep scan

Software Prerequisites

• Install JDK versions between 11 and 25.0.2.
  • For JDK 8, see Scan projects on JDK version 8.
• Make sure your repository includes one or more files with .kt extension.
• Install Maven version 3.6.1 and higher if your project uses Maven.
• Install Gradle build system version 6.0.0 and higher, if your project uses Gradle.
  • To support lower versions of Gradle, see Scan projects on older Gradle versions.
• Your repository must include the appropriate build manifest file:
  • pom.xml for Maven projects.
  • build.gradle or build.gradle.kts for Gradle projects.

Build Kotlin projects

Before initiating a scan with Endor Labs, ensure that your Kotlin projects are built successfully. Additionally, ensure that the packages are downloaded into local package caches and build artifacts are present in their standard locations. Follow the guidelines to use Gradle and Maven:

Use Gradle

To analyze your software built with Gradle, Endor Labs requires:

• The software must be successfully built with Gradle.
• For quick scans, dependencies must be located in the local package manager cache. The standard $GRADLE_USER_HOME/caches or /User/<<username>>/.gradle/caches cache must exist.
• For deep scans, the target artifact must be generated on the filesystem.

To build your project with Gradle, run the following commands:

1. Specify the Gradle configuration by setting an environment variable.

export endorGradleKotlinConfiguration="compileClasspath"

To override the default configuration, use the command:

export endorGradleKotlinConfiguration="<configuration>"

When no configuration is provided, runtimeClasspath is used by default.

If neither the user-specified nor the default configuration exists in the project, the system falls back to the following configurations, in order:

1. runtimeClasspath
2. runtime
3. compileClasspath
4. compile

If the listed configurations are not found in the project, the system selects the first available configuration in alphabetical order.

For Android projects, you can set the configuration using:

export endorGradleAndroidConfiguration="<configuration>"

The default configuration for an Android application or library follows the structure used by Android Studio.

Applications: All possible combinations of application variants are examined.

Libraries: All possible combinations of library variants are examined.

The first variant in the alphabetically sorted list is then suffixed with RuntimeClasspath. For example, if the first variant is configA, the default configuration will be configARuntimeClasspath.

If these methods don’t yield a value, the system defaults to releaseRuntimeClasspath.

2. Confirm an error-free dependency resolution for your project.

gradle dependencies

or, with a Gradle wrapper.

./gradlew dependencies

3. Generate the artifact for deep analysis.

gradle assemble

or, with a Gradle wrapper.

./gradlew assemble

Override sub project level configuration

In a multi-build project, if you set the environment variable endorGradleKotlinConfiguration=[GlobalConfiguration] and/or endorGradleAndroidConfiguration=[GlobalConfiguration], the specified configuration is used for dependency resolution across all projects and sub-projects in the hierarchy below.

    \--- Project ':samples'
         +--- Project ':samples:compare'
        +--- Project ':samples:crawler'
        +--- Project ':samples:guide'
        +--- Project ':samples:simple-client'
        +--- Project ':samples:slack'
        +--- Project ':samples:static-server'
        +--- Project ':samples:tlssurvey'
        \--- Project ':samples:unixdomainsockets'

To override the configuration only for the :samples:crawler and :samples:guide sub-projects, follow these steps:

1. Navigate to the root workspace, where you execute endorctl scan, and run ./gradlew projects to list all projects and their names.

2. Run the following command at the root of the workspace:

echo ":samples:crawler=testRuntimeClasspath,:samples:guide=macroBenchMarkClasspath" >> .endorproperties

This creates a new file named .endorproperties in your root directory. This enables different configurations for the specified sub-projects in the file.

3. Run endorctl scan as usual.

At this point, all other projects will adhere to the GlobalConfiguration. However, the :samples:crawler sub-project will use the testRuntimeClasspath configuration, and the :samples:guide sub-project will use the macroBenchMarkClasspath configuration.

Use Maven

To analyze your software built with Maven, Endor Labs requires:

• The software must be successfully built with Maven.
• For quick scans, dependencies must be located in the local package manager cache. The standard .m2 cache must exist.
• For deep scans, the target artifact must be generated on the filesystem.

To build your project with Maven, run the following commands:

1. Confirm an error-free dependency resolution for your project.

mvn dependency:tree

2. Run mvn install and ensure the build is successful.

mvn install -DskipTests

3. If you have multiple Kotlin modules not referenced in the root pom.xml file, ensure to run mvn install separately in each directory.

Configure Maven private registries

Endor Labs supports fetching and scanning dependencies from private Maven package registries. Endor Labs will fetch resources from authenticated endpoints and perform the scan, allowing you to view the resolved dependencies and findings. See Maven package manager integrations for more information on configuring private registries.

Run a scan

To scan your repositories with Endor Labs, you can use the following options after building your Kotlin projects.

Option 1 - Quick scan

To quickly gain insight into your software composition, initiate a quick scan using the following command:

endorctl scan --quick-scan

This scan offers a quick overview without performing reachability analysis, helping you prioritize vulnerabilities.

Save local results

To scan a Git project repository from the root directory and save the results locally in the results.json file, use the following command:

endorctl scan --quick-scan -o json | tee /path/to/results.json

This generates comprehensive results and analysis information, accessible from the Endor Labs user interface.

Access results

To access and review detailed results, sign in to the Endor Labs user interface. Navigate to Projects on the left sidebar, and locate your project for a thorough examination of the scan results.

Option 2 - Deep scan

To perform dependency resolution and reachability analysis, use deep scan with Endor Labs. This option is recommended only after successfully completion of quick scan.

endorctl scan

Save local scan results

To save the local results to a results.json file, use the following flag.

endorctl scan -o json | tee /path/to/results.json

This generates comprehensive results and analysis information, accessible from the Endor Labs user interface.

Analyze private packages

During deep analysis, Endor Labs thoroughly analyzes all private software dependencies that have not been previously scanned. While this initial operation may slow down scans, subsequent scans remain unaffected.

If your organization does not own specific software parts and related findings are non-actionable, you can choose to disable this analysis using the disable-private-package-analysis flag. Disabling private package analysis enhances scan performance but may result in a loss of insights into how applications interact with first-party libraries.

To disable private package analysis, use the following command flag:

endorctl scan --disable-private-package-analysis

Access scan results

To access and review detailed results, sign in to the Endor Labs user interface. Navigate to Projects on the left sidebar, and locate your project for a thorough examination of the scan results.

Scan the projects on JDK version 8

While Endor Labs primarily supports JDK versions between 11-25.0.2, you can still scan projects on JDK 8 by following these steps:

1. Build your Java project on JDK 8.
2. After successful build, switch your Java home to JDK 11 or higher versions.

export JAVA_HOME=/Library/Java/JavaVirtualMachines/openjdk-11.jdk/Contents/Home

3. Run a scan.

Understand the scan process

Endor Labs analyzes your Kotlin code and dependencies to identify known security issues, including open-source vulnerabilities.

How Endor Labs resolves dependencies for package versions

Endor Labs resolves Kotlin package dependencies by considering the following factors:

• For packages built with Maven, it leverages the Maven cache in the .m2 directory of your file system. This mirrors Maven’s build process for precise results.
• For packages built with Maven, it respects the configuration settings present in the settings.xml file. If the file is included in your repository, any additional configuration is not necessary.
• For packages built with Gradle, it leverages Gradle and Gradle wrapper files to build and resolve dependencies.
• Endor Labs supports AAR, EAR, JAR, RAR, and WAR files.

How Endor Labs performs static analysis on the code

Endor Labs performs static analysis on the code based on the following factors:

• Call graphs are created for your package. These are then combined with the call graphs of the dependencies in your dependency tree to form a comprehensive call graph for the entire project.
• Endor Labs performs an inside-out analysis of the software to determine the reachability of dependencies in your project.
• The static analysis time may vary depending on the number of dependencies in the package and the number of packages in the project.

Known limitations

• If a package can not be successfully built in the source control repository, static analysis will fail.
• Spring dependencies are analyzed based on spring public entry points to reduce the impact of Inversion of Control (IOC) frameworks. Dependencies and functions are identified as reachable and unreachable in the context of a spring version and its entry points.
• Annotation processing is limited only to the usage of the code they annotate.
• Static analysis of reflection and callbacks are not supported.
• If Endor Labs fails to resolve dependencies using default Kotlin configurations, the Kotlin configuration must be specified.
• Static analysis for Kotlin projects using Gradle is only supported when the Kotlin plugin for Gradle versions 1.5.30 to 1.9.x

Troubleshoot errors

Here are a few error scenarios that you can check for and attempt to resolve them.

• Host system check failure errors:
  • Java is not installed or not present in the PATH environment variable. Install Java and try again. See Java documentation for more information.
  • For android applications, $ANDROID_HOME must be specified as an environment variable.
  • The installed version of Java is lower than the required version. Install JDK versions between 11-25.0.2 and try again.
  • Java is installed but Maven or Gradle is not installed. In such cases, the dependency resolution may not be complete.
• Unresolved dependency errors: Maven is not installed properly or the system is unable to build root pom.xml. Run mvn dependency:tree in the root of the project and try again. In such cases, the dependency resolution may not be complete.
• Resolved dependency errors: A version of a dependency does not exist or it cannot be found. It may have been removed from the repository.
• Call graph errors:
  • If the project is not compiled, call graphs are not generated. Run gradlew compileKotlin or gradlew compileReleaseKotlin for android based projects before running the scan.
  • Sometimes, the project is not compiled, if a Kotlin version discrepancy exists between the required repository version and the version on the system running the scan. For example, the Kotlin required version is 1.4 but the system has lower version installed. Install the required version and try again.
• If you have a private registry and internal dependencies on other projects, you must configure the credentials of the registry. See Configure Maven private registries.
• If you use a remote repository configured to authenticate with a client-side certificate, you must add the certificate through an endorctl parameter. Export the ENDOR_SCAN_JVM_PARAMETERS parameter before performing a scan. See Maven documentation for details.

export ENDOR_SCAN_JVM_PARAMETERS="-Xmx16G,-Djavax.net.ssl.keyStorePassword=changeit,
-Djavax.net.ssl.keyStoreType=pkcs12,
-Djavax.net.ssl.keyStore=/Users/myuser/Documents/nexustls/client-cert1.p12"

Scala is a general-purpose and scalable programming language widely used by developers. Endor Labs supports the scanning and monitoring of Scala projects managed by either the interactive build tool sbt or Gradle.

Using Endor Labs, application security engineers and developers can:

• Scan their software for potential security issues and violations of organizational policy.
• Prioritize vulnerabilities in the context of their applications.
• Understand the relationships between software components in their applications.

System specifications for scan

Make sure that your system has a minimum 8-core processor with 32 GB RAM to successfully scan Scala projects.

Software prerequisites

• Install JDK versions between 11 and 25.0.2.
  • For JDK 8, see Scan projects on JDK version 8.
• Make sure your repository includes one or more files with .scala or .sc extension.
• Install sbt version 1.4 or higher if your project uses sbt.
  • For sbt versions lower than 1.4, install the sbt-dependency-graph plugin, which is included by default in sbt 1.4 and later.
  • Ensure that the project/build.properties file specifies the required sbt version.
• Install Gradle build system version 6.0.0 and higher, if your project uses Gradle.
  • To support lower versions of Gradle, see Scan projects on older Gradle versions.
• Your repository must include the appropriate build manifest file:
  • build.sbt for sbt projects.
  • build.gradle or build.gradle.kts for Gradle projects.

Build Scala projects

Before initiating a scan with Endor Labs, ensure that your Scala projects are built successfully. Additionally, ensure that the packages are downloaded into local package caches and build artifacts are present in their standard locations. Follow the guidelines to build projects using sbt or Gradle.

Use Gradle

To analyze your software built with Gradle, you must successfully build the software. To perform a quick scan, locate the dependencies in the local package manager cache. Ensure that the standard $GRADLE_USER_HOME/caches or /User/<username>/.gradle/caches exists and contains successfully downloaded dependencies. To perform a deep scan, generate the target artifact on the file system as well.

To build your project with Gradle, use the following procedure:

1. To run a scan against a custom configuration, specify the Gradle configuration by setting an environment variable.

      export endorGradleScalaConfiguration="<configuration>"
   

   When no configuration is provided, runtimeClasspath is used by default.

   If neither the user-specified nor the default configuration exists in the project, the system falls back to the following configurations, in order:

   1. runtimeClasspath
   2. runtime
   3. compileClasspath
   4. compile

   If the listed configurations are not found in the project, the system selects the first available configuration in alphabetical order.

2. Ensure that you can resolve the dependencies for your project without errors by running the following command:

   For Gradle wrapper:

      ./gradlew dependencies
   

   For Gradle:

      gradle dependencies
   

3. Run ./gradlew assemble or gradle assemble to resolve dependencies and to create an artifact that may be used for deep analysis.

Override subproject level configuration

In a multi-build project, if you set the environment variable endorGradleScalaConfiguration=[GlobalConfiguration], the specified configuration is used for dependency resolution across all projects and subprojects in the hierarchy below.

\--- Project ':samples'
     +--- Project ':samples:compare'
     +--- Project ':samples:crawler'
     +--- Project ':samples:guide'
     +--- Project ':samples:simple-client'
     +--- Project ':samples:slack'
     +--- Project ':samples:static-server'
     +--- Project ':samples:tlssurvey'
     \--- Project ':samples:unixdomainsockets'

To override the configuration only for the :samples:crawler and :samples:guide subprojects, follow these steps:

1. Navigate to the root workspace, where you execute endorctl scan, and run ./gradlew projects to list all projects and their names.

2. Run the following command at the root of the workspace:

   echo ":samples:crawler=testRuntimeClasspath,:samples:guide=macroBenchMarkClasspath" >> .endorproperties
   

   This creates a new file named .endorproperties in your root directory. This enables different configurations for the specified subprojects in the file.

3. Run endorctl scan.

At this point, all other projects will adhere to the GlobalConfiguration. However, the :samples:crawler subproject will use the testRuntimeClasspath configuration, and the :samples:guide subproject will use the macroBenchMarkClasspath configuration.

Configure private Gradle package repositories

Endor Labs supports fetching and scanning dependencies from private Gradle package registries. Endor Labs will fetch resources from authenticated endpoints and perform the scan, allowing you to view the resolved dependencies and findings. See Gradle package manager integrations for more information on configuring private registries.

Use sbt

To analyze your software built with sbt, you must successfully build the software.

• The standard .sbt cache must exist and contain all required dependencies for both quick and deep scans.
• For deep scans, the build artifact must exist on the filesystem.
• Make sure sbt dependencyTree runs successfully inside the project directory.

Quick scan

Run a quick scan to rapidly assess your dependencies using only the compiled code and cached packages.

1. Run the following commands to build the project successfully. Ensure your repository has a build.sbt file.

   sbt compile
   

   sbt projects
   

2. Run an endorctl scan.

Deep scan

Run a deep scan to enable advanced static analysis features by generating packaged artifacts.

1. Run the following commands to build the project successfully. Ensure your repository has a build.sbt file.

   sbt package
   

   sbt projects
   

2. Run an endorctl scan.

Run a scan

Run an endorctl scan to get visibility into your software composition and resolve dependencies.

endorctl scan

You can perform the scan from within the root directory of the Git project repository and save the local results to a results.json file. The results and related analysis information are available on the Endor Labs user interface.

endorctl scan -o json | tee /path/to/results.json

Sign in to the Endor Labs user interface, click Projects on the left sidebar, and find your project to review its results.

Understand the scan process

Endor Labs scans Scala projects by executing sbt plugins and inspecting the build.sbt file to retrieve information about direct and transitive dependencies.

• The build.sbt file is a configuration file used in Scala projects with sbt to define project settings, dependencies, and build tasks. This file provides the necessary configuration and instructions to sbt on resolving and managing project dependencies.
• The sbt dependency graph plugin visualizes the dependencies between modules in a Scala project.
• For packages built using Gradle, it uses Gradle and Gradle wrapper files to build packages and resolve dependencies.
• Endor Labs supports EAR, JAR, RAR, and WAR files.

Endor Labs analyzes information from both these methods to determine different components, binary files, manifest files, images, and more in the Scala codebase. It presents finding policy violations, identifies dependencies, and resolves them.

Using Endor Labs, users can gain significant insights into the structure and relationships of their Scala project’s dependencies. This aids in managing dependencies effectively, identifying potential issues, and ensuring a well-organized and maintainable codebase.

How Endor Labs performs static analysis on the code

Endor Labs performs static analysis based on the following factors:

• Call graphs are created for your package. These are then combined with the call graphs of the dependencies in your dependency tree to form a comprehensive call graph for the entire project.
• Endor Labs performs an inside-out analysis of the software to determine the reachability of dependencies in your project.
• The static analysis time may vary depending on the number of dependencies in the package and the number of packages in the project.

Known limitations

Endor Labs does not currently support software composition analysis for Scala on Microsoft Windows operating systems.

Troubleshoot errors

Here are a few error scenarios that you can check for and attempt to resolve them.

• Host system check failure errors: These errors occur if:
  • sbt is not installed or present in the path variable. Install sbt 1.4 or higher versions and try again.
  • The sbt version mentioned in the project or the build.properties file is lower than 1.4 and the sbt-dependency-graph plug-in is not installed. Install the sbt-dependency-graph plug-in and try again.
  • Java is not installed or not present in the PATH environment variable. Install Java and try again. See Java documentation for more information.
  • The installed version of Java is lower than the required version. Install JDK versions between 11 and 25.0.2 and try again.
  • Java is installed but sbt or Gradle is not installed. In such cases, the dependency resolution may not be complete.
• Dependency graph errors: Scala by default imports MiniDependencyTreePlugin, which is a mini version of the sbt-dependency-graph plugin and supports only the dependencyTree command. To get complete features of the sbt-dependency-graph plugin, add DependencyTreePlugin to your project/plugins.sbt file and run the scan again. See Scala documentation for details.

.NET is a free, cross-platform, open-source developer platform for building different types of applications. Endor Labs supports the scanning and monitoring of projects built on the .NET platform.

Using Endor Labs, application security engineers and developers can:

• Scan their software for potential security issues and violations of organizational policy.
• Prioritize vulnerabilities in the context of their applications.
• Understand the relationships between software components in their applications.

System specifications for deep scan

Software prerequisites

The following prerequisites must be fulfilled:

• Make sure your repository includes one or more files with .cs extension.
• Dependency resolution and reachability analysis is supported only for SDK-style .NET projects.
• One or more *.csproj files must be present in your repository.
• The .NET command or NuGet command must be installed and available on the host system.
• At least one .NET SDK installed on the system must be compatible with the project’s global.json file settings.

Run a scan

Use the following options to scan your repositories. Perform a scan after building the projects.

Option 1 - Quick scan

Perform a quick scan to get quick visibility into your software composition. This scan won’t perform reachability analysis to help you prioritize vulnerabilities.

You must restore your .NET projects before running a quick scan. Additionally, ensure that the packages are downloaded into the local package caches and that the build artifacts are present in the standard locations.

1. Run the following commands to resolve dependencies and create the necessary files to scan your .NET project.

   To ensure that the build artifacts project.assets.json file is generated and dependencies are resolved run:

   dotnet restore
   

   If you use NuGet instead run:

   nuget restore
   

   To create a packages.lock.json file if your project uses a lock file run:

   dotnet restore --use-lock-file
   

   If project.assets.json or packages.lock.json are not present and if the project is buildable, endorctl will restore the project and create a project.assets.json or a packages.lock.json file to resolve dependencies.

2. You can run a quick scan with the following commands:

   endorctl scan --quick-scan
   

   You can perform the scan from within the root directory of the Git project repository, and save the local results to a results.json file. The results and related analysis information are available on the Endor Labs user interface.

   endorctl scan --quick-scan -o json | tee /path/to/results.json
   

   You can sign in to the Endor Labs user interface and navigate to Projects from the left sidebar to review your project results.

Option 2 - Deep scan

Use the deep scan to perform dependency resolution, reachability analysis, and generate call graphs. You can do this after you complete the quick scan successfully.

You must restore and build your .NET projects before running a deep scan. Additionally, ensure that the packages are downloaded into the local package caches and that the build artifacts are present in the standard locations.

1. Run the following commands to restore and build your project. This may vary depending on your project’s configuration.

   dotnet restore
   dotnet build
   

2. You can run a deep scan with the following commands:

   endorctl scan
   

   Use the following flags to save the local results to a results.json file. The results and related analysis information are available on the Endor Labs user interface.

   endorctl scan -o json | tee /path/to/results.json
   

When a deep scan is performed all private software dependencies are completely analyzed by default if they have not been previously scanned. This is a one-time operation and will slow down initial scans, but won’t impact subsequent scans.

Organizations might not own some parts of the software internally and findings are actionable by another team. These organizations can choose to disable this analysis using the flag disable-private-package-analysis. By disabling private package analysis, teams can enhance scan performance but may lose insights into how applications interact with first-party libraries.

Use the following command flag to disable private package analysis:

endorctl scan --disable-private-package-analysis

You can sign into the Endor Labs user interface and select Projects from the left sidebar to review your project results.

Configure private NuGet package repositories

Endor Labs supports fetching and scanning dependencies from private NuGet package registries. Endor Labs will fetch resources from authenticated endpoints and perform the scan, allowing you to view the resolved dependencies and findings. See NuGet package manager integrations for more information on configuring private registries.

Understand the scan process

A *.csproj file is an XML-based C# project file that contains information about the project, such as its source code files, references, build settings, and other configuration details. The dependencies and findings are listed individually for every .csproj file. The scan discovers all *.csproj files and uses these files to resolve the appropriate dependency graph of your project.

(Beta) Endor Labs scans the .NET projects that are using the Central Package Management feature of NuGet for the packages declared as:

• Package references in Directory.Build.props or Directory.Packages.props files.
• Package references in any *.props file and the prop file is imported in the .csproj file.
• Package references in *.Targets file.

Endor Labs enriches your dependency graph to help you understand if your dependencies are secure, sustainable, and trustworthy. This includes Endor Labs risk analysis and scores, if a dependency is direct or transitive, and if the source code of the dependency is publicly auditable.

Software composition analysis for .NET is performed in the following ways:

• Using Project.assests.json
• Using package.lock.json

How does dependency resolution happen using Project.assets.json

The project.assets.json file is used in .NET projects to store metadata and information about the project’s dependencies and assets.

Endor Labs fetches resolved package versions, paths to the dependencies’ assets, such as assemblies and resources, and other related information from this file. If a project does not include a project.assets.json file, it is generated through the dotnet restore or the nuget restore command. This command uses all the configured sources to restore dependencies as well as project-specific tools that are specified in the project file.

How does dependency resolution happen using package.lock.json

The package.lock.json file is used in .NET projects to lock dependencies and their specific versions. It is a snapshot of the exact versions of packages installed in a project, including their dependencies and sub-dependencies, requested versions, resolved versions, and contenthash. The lock file provides a more dependable, uniform, and accurate representation of the dependency graph.

In Endor Labs’ dependency management, the resolution of dependencies is primarily based on package.lock.json, which takes precedence over projects.assets.json to resolve dependencies.

Endor Labs fetches the dependency information from package.lock.json and creates a comprehensive dependency graph. The vulnerabilities associated with the dependencies are listed on the Endor Labs’ user interface.

If the package.lock.json file is not present in the repository, Endor Labs triggers the restore process to generate the package.lock.json file and uses it to perform the dependency scans.

Resolving package names from props files

endorctl attempts to evaluate MSBuild property values when they are composed of variables, as long as the variables are defined within the same file for example, Directory.Build.props. This enables accurate resolution of package names and versions, even if they are not explicitly declared in the .csproj file.

For example, in a setup like

test.csproj

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>net8</TargetFrameworks>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" Version="13.0.3" />
  </ItemGroup>
</Project>

Directory.Build.props

<Project>
  <PropertyGroup>
    <CompanyName>via-build-prop</CompanyName>
    <AssemblyName>$(CompanyName).$(MSBuildProjectName)</AssemblyName>
  </PropertyGroup>
</Project>

When generating package names for .NET projects, the system evaluates the AssemblyName property defined in the project’s .props file. Instead of using a generic name like test, the system applies the evaluated value, for example, via-build-prop.test. This approach enables consistent and customizable package naming based on MSBuild properties.

How Endor Labs performs static analysis on the code

Endor Labs performs static analysis on the C# code based on the following factors:

• Call graphs are created for your package. These are then combined with the call graphs of the dependencies in your dependency tree to form a comprehensive call graph for the entire project.
• Endor Labs looks for the project’s .dll files typically located within the bin directory.
• Endor Labs performs an inside-out analysis of the software to determine the reachability of dependencies in your project.
• The static analysis time may vary depending on the number of dependencies in the package and the number of packages in the project.

Known Limitations

• When using the GitHub app, either resolve all the private and internal dependencies, or Configure private NuGet package repositories before running a scan.
• When working with old-style MSBuild projects, we recommend scanning them through Continuous Integration (CI) after building the project to ensure that the .NET build system generates the required obj/project.assets.json file. For monitoring scans, support for restoring dependencies in Windows projects is limited. This may lead to restore or build errors, potentially causing unexpected scan results.

Call graph limitations

• You must install .NET 7.0.1 (SDK 7.0.101) or later on the host system.
• The following .NET programming languages are not supported for dependency resolution or call graph generation:
  • Projects written in F#
  • Projects written in Visual Basic
• Endor Labs’ call graph support for .NET is based on Microsoft’s Common Intermediate Language (CIL). Artifacts such as .exe or .dll files must be available in the project’s standard workspace through a build and restore or a restored cache.

Troubleshoot errors

Here are a few error scenarios that you can check for and attempt to resolve them.

• Host system check failure errors: .NET or NuGet is not installed or not present in the PATH environment variable. Install NuGet and try again.
• Unresolved dependency errors: This error occurs when the .csproj file can not be parsed or if it has syntax errors.

CocoaPods and SwiftPM are widely adopted package managers for Swift and Objective-C. CocoaPods simplifies integration via Podfile declarations and automated installation, while SwiftPM manages dependencies through the Package.swift manifest. Endor Labs supports both systems to help secure your applications.

Using Endor Labs, application security engineers and developers can:

• Scan their software for potential security issues and violations of organizational policy.
• Prioritize vulnerabilities in the context of their applications.
• Understand the relationships between software components in their applications.

Software prerequisites

The following prerequisites must be fulfilled:

• All applications monitored by Endor Labs must be on CocoaPods versions 0.9.0 or higher, or Swift Package Manager versions 5.0.0 or higher.
• A Podfile and a Podfile.lock must be present in your CocoaPods project.
• A Package.swift must be present in your SwiftPM project.
• Make sure your repository includes one or more files with .swift, .h, or .m extension.
• The Swift toolchain must be installed on the system running the scan for SwiftPM projects. To verify the installation, run the swift --version command.

Build CocoaPods projects

If the Podfile.lock is not present in your repository, run the following command to create the Podfile.lock for your Podfile.

pod install

Run a scan

Perform a scan to get visibility into your software composition and resolve dependencies.

endorctl scan

You can perform the scan from within the root directory of the Git project repository, and save the local results to a results.json file. The results and related analysis information are available on the Endor Labs user interface.

endorctl scan -o json | tee /path/to/results.json

You can sign into the Endor Labs user interface, click the Projects on the left sidebar, and find your project to review its results.

Understand the scan process for CocoaPods projects

Endor Labs looks for the Podfile and Podfile.lock files to discover the dependencies used by an application.

• A Podfile is a configuration file used in CocoaPods projects to specify the required libraries or packages for the project’s dependencies.
• A Podfile.lock file is a CocoaPods specification file used to define the metadata and dependencies.

To successfully discover Swift and Objective-C dependencies, both Podfile and Podfile.lock files must be present in your project for each Podfile.

Understand the scan process for SwiftPM projects

Endor Labs scans SwiftPM projects by locating the Package.swift manifest file, which defines the Swift package’s dependencies, targets, and metadata. Version-specific manifest files using the format Package@swift-<version>.swift, for example Package@swift-5.7.swift, are also supported.

Configure private SwiftPM package repositories

Endor Labs supports fetching and scanning dependencies from private Swift package registries. Endor Labs will fetch resources from authenticated endpoints and perform the scan, allowing you to view the resolved dependencies and findings. See Swift package manager integrations for more information on configuring private registries.

Known limitations

• Call graphs are not supported for CocoaPods and SwiftPM projects.
• If a Podfile.lock file is not present, Endor Labs will skip analyzing the project and present a warning that the package was skipped.

Ruby is a widely used open-source programming language. Endor Labs supports scanning and monitoring of Ruby projects.

Using Endor Labs, application security engineers and developers can:

• Scan their software for potential security issues and violations of organizational policy.
• Prioritize vulnerabilities in the context of their applications.
• Understand the relationships between software components in their applications.

Software prerequisites

The following prerequisites must be fulfilled:

• All applications monitored by Endor Labs must be on Ruby versions 2.6 or higher.
• A Gemfile or a *.gemspec file must be present in your Ruby project.
• Make sure your repository includes one or more files with .rb extension.

Build Ruby projects

You can choose to build your Ruby projects before running a scan. This will ensure that gemfile.lock is created.

Ensure your repository has Gemfile and run the following command making sure it builds the project successfully.

bundler install

If the project is not built, endorctl will build the project during the scan and generate Gemfile.lock. If the repository includes a Gemfile.lock, endorctl uses this file for dependency resolution and does not create it again.

Configure private RubyGems package repositories

Endor Labs supports fetching and scanning dependencies from private RubyGems package registries. Endor Labs will fetch resources from authenticated endpoints and perform the scan, allowing you to view the resolved dependencies and findings. See RubyGems package manager integrations for more information on configuring private registries.

Run a scan

Perform a scan to get visibility into your software composition and resolve dependencies.

endorctl scan

You can perform the scan from within the root directory of the Git project repository, and save the local results to a results.json file. The results and related analysis information are available on the Endor Labs user interface.

endorctl scan -o json | tee /path/to/results.json

You can sign in to the Endor Labs user interface, click the Projects on the left sidebar, and find your project to review its results. Refer to Endor Labs user interface for more details.

Understand the scan process

Endor Labs looks for Gemfile, *.gemspec, and Gemfile.lock files to find and monitor the dependency activity.

• A Gemfile is a configuration file used in Ruby projects to specify the required RubyGems (libraries or packages) for the project’s dependencies.
• A *.gemspec file is a RubyGems specification file used to define the metadata and dependencies for a RubyGem.
• The Gemfile.lock file is automatically generated by Bundler. Refer to Bundler documentation for more information about getting started.

If the Gemfile.lock is not present in your project, Endor Labs generates this file and stores it in a temp directory. The file is deleted after extracting dependency information.

Endor Labs’ dependency resolution mechanism assesses multiple factors, including compatibility, stability, and availability, to determine the most suitable version for usage. The resolved dependency version is used during the build or execution of your Ruby project. By utilizing the dependency graph, you can access significant information regarding the dependencies. This includes determining whether a dependency is direct or transitive, checking its reachability, verifying source availability, and more. The dependency graph provides a visual representation that allows you to examine the graphical details of these dependencies.

Known limitations

• Call graphs are not supported for Ruby projects.
• If a dependency can not be resolved in the Gemfile, building that specific package may not be successful. This package may have been removed from the Gem package manager. Other packages in the workspace are scanned.

Troubleshoot errors

• Unresolved dependency errors: The Gemfile is not buildable. Try running bundler install in the root project to debug this error.
• Resolved dependency errors: A version of a dependency does not exist or it cannot be found. It may have been removed from the repository.

Rust is a software programming language widely used by developers. Endor Labs supports scanning and monitoring of Rust projects.

Using Endor Labs, application security engineers and developers can:

• Scan their software for potential security issues and violations of organizational policy.
• Prioritize vulnerabilities in the context of their applications.
• Understand the relationships between software components in their applications.

System specifications for scan

Make sure that you have a minimum system requirement specification of an 8-core processor with 32 GB RAM.

Use a system equipped with either Mac OS X or Linux operating systems to perform the scans.

Software prerequisites

• Make sure the following prerequisites are installed: - Package Manager Cargo - Any version - Rust - Any version,
• Make sure your repository includes one or more files with .rs extension.
• Install Rust using the latest rustup tool.

Build Rust projects

Ensure your repository has Cargo.toml file and run the following command making sure it builds the project successfully.

cargo build

If the project is not built, endorctl will build the project during the scan and generate the Cargo.lock file. If the repository includes a Cargo.lock file, endorctl uses this file for dependency resolution and does not create it again.

Run a scan

Perform a scan to get visibility into your software composition and resolve dependencies.

endorctl scan

You can perform the scan from within the root directory of the Git project repository, and save the local results to a results.json file. The results and related analysis information are available on the Endor Labs user interface.

endorctl scan -o json | tee /path/to/results.json

You can sign in to the Endor Labs user interface, click the Projects on the left sidebar, and find your project to review its results. Refer to Endor Labs user interface for more details.

Understand the scan process

Endor Labs resolves dependencies for the package version when it scans Rust projects.

Resolving Dependencies

Endor Labs leverages the Cargo.toml file in Rust and uses this file to build the package version using cargo. Endor Labs uses the output from cargo metadata to resolve dependencies specified in Cargo.toml files and construct the dependency graph.

Known Limitations

• Call graphs are not supported for Rust projects.
• Performing Endor Labs scans on the Microsoft Windows operating system is currently unsupported.

Troubleshoot errors

• Host system check failure errors: These errors occur when Rust is not installed or not present in the path variable. Install Rust and try again.

You can now perform endorctl scan on your binaries and artifacts without requiring access to source code or build systems. Scan Java and Python packages that are pre-built, bundled, or downloaded into your local system by specifying a file path to your artifact or binary package.

Endor Labs scans the specified package, producing vital scan artifacts such as details about resolved dependencies and transitive dependencies, along with comprehensive call graphs. It enables you to acquire valuable insights and improve the security and reliability of the software components.

System specifications for deep scan

File format specifications

When scanning archive formats such as .zip, tar, and .tar.gz, we support embedded package formats including .jar, .ear, .war, and .whl. We also support .tar.gz archives that contain Python package metadata such as egg-info.

You can scan JAR, WAR, and EAR package file formats built using Maven or Gradle with a pom.xml configuration file. To scan packages without a pom.xml configuration, see Scan Java packages without pom.xml.

Software prerequisites

If you have a private registry and internal dependencies on other projects, you must configure private registries for the Python and Java projects. See Configure package manager integrations for more information.

Understand the scan arguments

Use --package as an argument to scan artifacts or binaries. You must provide the path of your file using --path and specify a name for your project using --project-name.

endorctl scan --package --path --project-name

Run the scan

Use the following options to scan your repositories.

Option 1 - Quick scan

Perform a quick scan of the local packages to get quick visibility into your software composition. This scan won’t perform reachability analysis to help you prioritize vulnerabilities.

Syntax:

endorctl scan --quick-scan --package --path=<<specify-the-path-of-your-file>> --project-name=<<specify-a-name-for-the-project>>

Example:

endorctl scan --quick-scan --package --path=/Users/username/packages/logback-classic-1.4.10.jar --project-name=package-scan-for-java

Option 2 - Deep scan

Use the deep scan to perform dependency resolution, reachability analysis, and generate call graphs. You can do this after you complete the quick scan successfully.

Syntax:

endorctl scan --package --path=<<specify-the-path-of-your-file>> --project-name=<<specify-a-name-for-the-project>>

Example:

endorctl scan --package --path=/Users/username/packages/logback-classic-1.4.10.jar --project-name=java-package-scan

View results

You can sign into the Endor Labs user interface, click the Projects on the left sidebar, and find your project using the name you entered to review its results.

You can view the list of projects created for scanning packages using the parameter Project Platform Source matches PLATFORM_SOURCE_BINARY to search on Projects.

Endor Labs performs an approximate scan in situations where dependency resolution is impossible. This can happen due to build errors or incomplete dependency information. In such cases, an approximate scan estimates dependencies based on the available, unresolved dependency data.

Since an approximate scan relies on unresolved dependency information, it is not as accurate as a scan based on resolved dependency information. However, an approximate scan can still provide valuable insights and help you identify potential issues.

How an approximate scan works

The approximate scan looks at the unresolved dependency data and estimates the resolved version based on the information available.

For example, if the version is pinned then the approximate scan uses that version. If the version is not specified, then it uses the latest version. The scan generates the findings based on these approximations.

False positives can occur if the actual resolved version is different from the approximated version, or if the same dependency is included in multiple places.

Ignore findings from approximate scans

If you know the approximate scan is inaccurate and want to ignore the findings, add an exception policy.

See create an exception policy from a template for details on how to create an exception policy.

When you create the exception policy, choose the following options:

• Select Custom as the policy template when you Define Exception Criteria.
• Select Yes for the Approximate Dependency option.

You can refine the exception policy by adding more criteria like Source Code Ecosystem and Dependency Scope. See exception policy templates for more information on the fields you can use to refine the exception policy. Alternatively, you can create your own exception policy from scratch.

Static Application Security Testing (SAST) is an automated security analysis methodology that examines application code to identify potential security vulnerabilities.

SAST has the following characteristics:

• White-box Testing: Provides full visibility into application internals
• Non-runtime Analysis: Performs scans without code execution
• Early Detection: Identifies vulnerabilities during development phases
• Language Support: Analyzes multiple programming languages and frameworks

Endor Labs integrates Opengrep to provide SAST scan with endorctl.

Endor Labs enhances SAST scanning with AI analysis that evaluates each finding to determine whether it represents a genuine security vulnerability or a false positive. This automated classification streamlines your security workflow by eliminating the need for manual triage of every alert, allowing your team to prioritize and address real threats more efficiently. See AI analysis with SAST scan for more information.

Opengrep is an open-source, static analysis tool that finds bugs and vulnerabilities in the source code using pattern matching. Opengrep parses the source code, applies pattern matching based on rules, and reports matches based on the rule specifications. Opengrep rules are in the yaml format.

When you run a SAST scan, Endor Labs downloads Opengrep and works seamlessly. If you wish, you can use Semgrep instead of Opengrep with Endor Labs.

Endor Labs includes a set of curated rules. You can create your own rules or import rules with the rule designer.

When you scan with the SAST option enabled, Endor Labs uses Opengrep to scan for weaknesses in your source code based on the enabled rules and generates results based on the configured finding policies.

Login to Endor Labs to view the findings of a SAST scan. See SAST Findings for more information.

You can create exception policies to exclude results from the findings page. See create exception policy for more information.

You can create a finding policy using predefined templates to control which SAST results appear as findings. See SAST policies for more information.

SAST severity matrix

Endor Labs determines the severity of findings by combining two factors from the SAST rule: impact and confidence. Impact measures the potential consequences if a security issue were to be exploited. Confidence represents how certain the system is that a detected pattern indicates a genuine security issue rather than a false positive.

The following matrix shows how Endor Labs resolves severity by combining impact and confidence.

Language support

Endor Labs supports single-function analysis for the following languages through curated rules and custom user rules:

- Apex
- Bash
- C
- Cairo
- Circom
- Clojure
- C++
- C#
- Dart
- Dockerfile
- Elixir
- Generic
- Go
- Hack
- HTML
- Java
- JavaScript
- JSON
- Jsonnet
- Julia
- Kotlin
- Lisp
- Lua
- Move
- OCaml
- PHP
- PromQL
- Protobuf
- Python
- QL
- R
- Regex
- Ruby
- Rust
- Scala
- Scheme
- Solidity
- Swift
- Terraform
- TypeScript
- XML
- YAML

SAST scan in Endor Labs

Endor Labs offers several ways to run SAST scans based on your project setup.

1. AI-analyzed SAST scan with endorctl
2. SAST scan in monitoring scans
3. SAST scan in Endor Labs GitHub Action

AI-analyzed SAST scan with endorctl

You can run AI-analyzed SAST scans using endorctl by adding the --ai-sast-analysis=agent-fallback flag to your scan command. The AI agent automatically classifies findings as true positives or false positives, reducing manual triage effort. See Run a SAST scan for more information.

SAST scan in monitoring scans

You can enable SAST scans when you configure monitoring or supervisory scans using the Endor Labs GitHub App, Azure DevOps App, Bitbucket App, and GitLab App. See SCM Integrations for more information. To disable the storage of code snippet in SAST scans for monitoring scans, you need to create a scan profile for your monitoring scan with disable code snippet storage as enabled. This setting applies to all scans that you use this scan profile, not just the monitoring scans.

SAST scan in Endor Labs GitHub Action

You can also enable SAST scan in the Endor Labs GitHub Action. Set the scanning parameter, scan_sast as true. To disable code snippet storage for SAST scans, set disable_code_snippet_storage as true. See Scan with GitHub Actions for more information.

SAST incremental scans

You can use the --pr-incremental flag to perform an incremental scan on your pull requests or merge requests for SAST. In monitoring scans, incremental scans are done by default for PR scans. Endor Labs only scans the files that have changed since the last scan on the baseline branch. Endor Labs computes a diff between the target branch and the baseline branch to identify the changed files. Any modified file is sent through Opengrep to fully scan for SAST issues, and unchanged files are skipped. Endor Labs does not perform chunk-level or line-level code diff analysis for SAST. If there are more than 1000 modified files, Endor Labs performs a complete scan.

Endor Labs uses Semgrep-compatible rules for SAST scans. Endor Labs includes hundreds of rules for various languages, including rules created by Endor Labs and vetted third-party rules. To this end, Endor Labs reviews existing open source rules and complements them with Endor Labs rules to cover additional technologies or vulnerability types.

You can edit existing rules in your tenant to make modifications specific to your environment. You can also create new custom rules with the rule designer based on your requirements. You can also use the rule designer to add any Semgrep rule as a custom rule.

From the left sidebar, navigate to Policies & Rules and select SAST RULES to view all SAST rules in the system.

You can use the toggle against a rule to enable or disable the rule during the scan.

You can search for rules based on various parameters like rule name, languages, CWE, and tags.

Rule Permissions

You can create SAST rules in your tenants, and can edit, delete, or propagate them to child namespaces. But you cannot edit rules that are marked as Endor Labs or 3rd Party. You can choose to disable the rule to not apply them during scanning or clone them to modify the rules.

The following sections provide more information on the actions you can do with SAST rules.

• Create a SAST rule
• Edit a SAST rule
• Clone a SAST rule
• Import a SAST rule
• Add metadata to a SAST rule

Run a SAST scan with endorctl to identify security vulnerabilities and code quality issues in your source code.

Ensure that you install endorctl and configure your environment to run Endor Labs scan before you proceed to do a SAST scan.

SAST scan

You can run a SAST scan on a project with endorctl using the following command.

endorctl scan --sast --path=/path/to/code -n <namespace>

To view the findings generated by this scan in Endor Labs, see view SAST findings.

SAST scan with AI analysis

Endor Labs uses AI Agent analysis to perform intelligent triage of SAST findings when you run a scan. The AI agent leverages a large language model (LLM) to examine code context, trace data flows, and evaluate security controls, automatically classifying each finding as either a True Positive, indicating a genuine security vulnerability, or a False Positive. This automated classification eliminates the need for manual review of every alert, allowing you to focus on addressing real security threats.

AI analysis does not process findings from test files such as unit tests and integration tests, or findings with low severity ratings. See AI triage behaviour for more information.

AI analysis process

The AI analysis process uses a large language model (LLM) to systematically evaluate each finding through the following steps:

1. Identify SAST rule match location - The LLM locates the exact code line where the SAST rule was triggered and examines the matching code patterns.

2. Trace data flow from source to sink - The LLM follows the data flow from where it enters the application to where it is used in potentially vulnerable code to determine if user-controlled input reaches vulnerable paths.

3. Examine function calls and security controls - The LLM reviews function calls in the data flow path, including sanitizers, validators, and other security controls that may mitigate risks.

4. Analyze function context and application usage - The LLM understands the purpose of functions involved in the rule match, how they are used in the application, and the application context such as web application, test file, or code example.

5. Classify findings as true or false positive - The LLM evaluates all gathered information including whether inputs are user-controlled or hard-coded, presence of sanitization functions, application context, and existing security controls to classify the finding as a true positive or false positive.

AI analysis processes only new findings and existing un-analyzed findings. If some findings are not analyzed in one run, they will be analyzed in the next scan. The analysis process runs for up to 30 minutes by default.

To modify the analysis timeout duration, set the following environment variable:

export ENDOR_SCAN_AI_SAST_ANALYSIS_TIMEOUT=10m

AI-analyzed SAST scan

You can run an AI-analyzed SAST scan on a project with endorctl using the following command.

endorctl scan --sast --path=/path/to/code -n <namespace> --ai-sast-analysis=agent-fallback

AI analysis starts with the fast agent mode, but automatically falls back to deep analysis mode when a true positive is detected. This provides a balance between speed and accuracy by using detailed analysis only when needed.

To view the findings generated by this scan in Endor Labs, see AI-analyzed SAST findings.

AI triage behaviour

You can control which findings are analyzed by AI triage and manage re-analysis behavior. When running AI-analyzed SAST scans, use the --ai-sast-rescan option to ensure all findings are analyzed. This option removes all existing AI analyses and re-analyzes all findings from scratch. Without this option, SAST findings that have already undergone AI triage are skipped during subsequent scans.

endorctl scan --sast --path=/path/to/code -n <namespace> --ai-sast-analysis=agent-fallback --ai-sast-rescan

The following types of findings are automatically excluded from AI triage. To include them, set the corresponding environment variable to false:

You can use AI Analysis Status criteria in finding policies to filter findings by their such as true positives, false positives, or both, in your findings view. Similarly, action policies can trigger actions based on AI classification, such as send notifications only for true positives.

SAST scan options

You can run the endorctl scan --sast command with the following options.

Exception policies define the conditions for applying an exception to a finding. When an exception is applied to a finding, it is tracked as an exception and action policies do not apply to it. Findings with exceptions are filtered out from Endor Labs reports by default.

See Exception Policies for more information.

Instead of creating an exception policy, you can also use the following methods to avoid findings:

• Disable the rule under SAST Rules
• Use the include-path and exclude-path to scan parts of the project

You can create an exception policy so that you can mark a SAST finding as an exception.

For example, you want to mark findings with the description, Detected Potential Open Redirect Vulnerability in Angular Application, as exceptions.

1. Select Policies & Rules from the left sidebar.

2. Select EXCEPTION POLICIES.

3. Click Create Exception Policy to create a new exception policy.

4. Select Standard Exception Find Attributes as the POLICY TEMPLATE.

5. Enter Detected Potential Open Redirect Vulnerability in Angular Application in Finding Name Contains.

6. Select from the following reasons why you are applying this exception:

   • In Triage: The finding is still being triaged for more information.
   • False Positive: The finding is a false positive.
   • Risk Accepted: The risk associated with the finding is accepted.
   • Other: Another reason applies for this exception.

7. Select when the exception should expire.

   Options include 30, 60, 90 days, and Never.

8. Assign Scope for which this exception policy should apply. Scopes are defined by the tags assigned to a project.

   • In Inclusions, enter the tags of the projects that you want to apply an exception to.
   • In Exclusions, enter the tags of the projects that you do not want to apply an exception to. Exclusions take precedence over the inclusions, in case of a conflict.
   • Click the link to view the projects included in the finding policy.

   See Tagging projects for more information about creating project tags.

9. Enter a human-readable Name for your exception policy.

10. Enter a Description for your exception policy that explains its function.

11. Enter any Policy Tags that you want to associate with your policy. Tags can have a maximum of 63 characters and can contain letters, numbers, and characters = @ _ -

12. Click Create Exception Policy.

Create exceptions from the findings

You can also create exceptions directly from a finding.

1. Select Projects from the left sidebar.
2. Search for and select a project, and select Findings.
3. Search for findings using advanced or basic filters.
4. Select findings and click the vertical three dots.
5. Select Add Exception Policy.
6. Select a template or create the policy from scratch. The template parameters are automatically pre-filled based on the selected finding.
7. Click Create Exception Policy.

Use this feature to specifically apply exception to findings with a specific hash value. For example, Detected Potential time of check time of use vulnerability (open/fopen): ID #e81f27. This exception policy after creation only applies to the SAST findings with this hash ID and not any others.

You can view SAST findings in the Findings page.

1. Select Findings from the left sidebar.

2. Select SAST under First Party Code.

   

3. You can use the filters to further refine the SAST findings.

4. Select a row to view finding details.

   

5. Select Rule to view the rule that triggered the finding.

   

6. To export findings as a CSV file, select the findings, click the vertical three dots, and select Export Selected or Export All. See export findings to learn more.

   

AI-analyzed SAST findings

When you run a SAST scan with --ai-sast-analysis=agent-fallback, an AI agent analyzes the findings to determine if they are true security issues or false positives. The AI agent automatically tags verified true positives with True Positive and false positives with False Positive for easy filtering.

To view AI-analyzed SAST findings:

1. Select Findings from the left sidebar.

2. Select SAST under First Party Code.

3. Use the Attributes filter and select True Positive or False Positive to filter out whatever you want.

4. Select a finding to view the details.

   • AI Analysis: Indicates the AI agent’s classification and analysis of the finding.
     • Classification: Specifies if the finding is categorized as a true positive or false positive, including the associated confidence level.
     • Analysis Summary: A brief explanation of the security issue identified, including why the finding was triggered and what type of vulnerability it represents.
     • Security Impact: The risk level and potential consequences if the vulnerability is exploited.
     • Technical Details: Technical explanation of how the vulnerability can be exploited, including the source and sink points in the code.
     • Data Flow Analysis: Traces how untrusted data flows through your code from input to the vulnerable point.
     • Security Controls: Displays what security protections exist or are missing in the code.
     • Risk Assessment: Detailed reasoning for why the finding is classified as a true positive or false positive, with supporting evidence.
     • AI Remediation: Suggested code fix to address the vulnerability.
   • Info, Rule, Explanation, and Metadata: Displays the underlying SAST rule information, detailed explanations of the security issue, remediation guidance, and metadata such as CWE classifications and security tags.
     • Info: Contains key metadata for the finding, including confidence, impact, first detected time, project, and rule ID.
     • Rule: The specific SAST rule that detected the finding, including rule description and code examples.
     • Explanation: Analysis summary, security impact, and technical details about why this is a SAST finding.
     • Remediation: General remediation guidance for addressing this type of vulnerability.
     • References: Links to relevant security references such as CWE definitions.
     • Metadata: Contains classification details such as the CWE ID, affected languages, security tags applied to the finding, and detected rule version.

   

Secrets are access credentials that provide access to key resources and services, such as passwords, API keys, and personal access tokens. Attackers can target vulnerabilities in places where secret information is readily accessible to many users, with the goal of gaining unauthorized entry to the services that these secrets unlock.

The exploitation of secrets can lead to various detrimental outcomes, including:

• Data breaches through the theft of stolen secrets and credentials.
• Unauthorized access to data and resources.
• Financial losses due to fraudulent activities.
• Privacy violations due to compromised credentials.
• Legal implications and regulatory consequences.

Secret scanning helps organizations proactively identify and remediate potential security threats before they can be exploited. It is important to scan for secrets in code as developers can sometimes hard-code sensitive data such as personal access tokens or API keys directly into the code.

Key features

• Secret Rules: Create and manage secret rules to scan and detect secrets.
• Scan for Secrets: Scan your codebase for secrets.
• View secret findings: View your findings after running a secrets scan.

Benefits

Endor Labs scans your source code repositories for secrets so that your teams can proactively manage the potential exposure of secrets to a broader audience than their intended recipients.

Users can:

• View findings for secrets exposed in the code and take corrective action.
• Detect valid secrets in their code repositories so that teams can take immediate corrective action.
• Perform regular scans to audit and get visibility into secrets that may represent security exposures in their environment.
• Detect and view invalid secrets as a proactive security approach to audit your codebase and segregate findings that you do not need to focus on.
• Use Git pre-commit hooks to detect secrets before being committed.

Secrets deduplication

Duplicate secrets increase the attack surface and the risk of unauthorized access. Managing multiple duplicate secrets can be complex and error-prone. Endor Labs intelligently categorizes instances of identical secrets found within your application components and repositories, helping an organization achieve:

• Efficient prioritization: Simplifies the prioritization of widely dispersed secrets, as more occurrences signify increased exposure and risk.
• Comprehensive visibility: Ensures that you have a comprehensive view of all instances associated with a specific secret, facilitating effective management when the secret is discovered or undergoes changes.
• Optimize issue handling: Generate a single finding for multiple secrets with details, simplifying the task of managing and addressing multiple secret-related issues simultaneously.

You can use the following rules to scan your codebase and detect secrets:

• System rules: Endor Labs provides out-of-the-box rules for secret patterns for many public services like GitHub, GitLab, AWS, Bitbucket, Dropbox, and more.

• Custom rules: If you are using a service that is not included in the out-of-the-box list of secret patterns provided by Endor Labs, you can build your own custom rule to scan and detect the secrets for any service.

The following table lists the most important fields of the rule definition.

Create a secret rule

1. Select Policies & Rules from the left sidebar.

2. Select Secret Rules.

3. Click Create Secret Rules.

   

4. Enter the unique Rule Identifier and Rule Name.

5. Enter the Description of the secret rule.

6. Enter the regex for the secret rule in Detection Rule.

7. Enter keywords for pre-regex check filtering as comma separated values in Keywords.

8. Optionally, enter the minimum Shannon entropy a regex group must have to be considered in Entropy.

9. Optionally, add validation details to validate the secret:

   • Validation URL: Enter the URL for validation.
   • Validation Method: Choose between GET and POST methods.
   • Success Response Codes: Enter valid response codes (For example, 200 for HTTP Status OK)
   • Failure Response Codes: Enter invalid response codes (For example, 401 for HTTP Status Unauthorized)
   • Authorization Details: You can choose between Authorization Header, Bearer Token, and Basic Authentication.

10. Select Propagate this rule to all child namespaces to apply the secret rule to all child namespaces.

11. Click Add Rule.

Create secret rules from the command line

For example, consider a token “demo_value123” can be described using a regular expression. Here is an example of the rule specification:

"meta": {
    "name": "Demo Token"
},
"spec": {
    "disabled": false,
    "keywords": [
        "demo_"
    ],
    "regex": "demo_[0-9a-zA-Z]{20}",
    "rule_id": "demo-rule"
}

Use the following command from the CLI to create this custom rule.

$ endorctl api create -r SecretRule -n demo  \
> --data '{
> "meta": {
>     "name": "Demo Token"
> },
> "spec": {
>     "disabled": false,
>     "keywords": [
>         "demo_"
>     ],
>     "regex": "demo_[0-9a-zA-Z]{20}",
>     "rule_id": "demo-rule"
> }
> }'
INFO: Initiating host-check ...
INFO: Host-check complete
{
  "meta": {
    "create_time": "2023-09-27T17:08:18.436936Z",
    "kind": "SecretRule",
    "name": "Demo Token",
    "update_time": "2023-09-27T17:08:18.436936Z",
    "upsert_time": "2023-09-27T17:08:18.436936Z",
    "version": "v1"
  },
  "spec": {
    "disabled": false,
    "keywords": [
      "demo_"
    ],
    "regex": "demo_[0-9a-zA-Z]{20}",
    "rule_id": "demo-rule"
  },
  "tenant_meta": {
    "namespace": "demo"
  },
  "uuid": "65146182aaeeffbaf5b6b553"
}

After the rule is created, the system uses this rule to detect this category of secrets.

If you can validate the secret using an HTTP request, then you can also add validation to this rule. See the following example for creating a validation rule for a demo_test123 token.

curl -H "Authorization: Bearer "demo_test123" https://api.testserver.com/user

Then the validation specification can be:

"validation": {
    "name": "Demo secrets validator",
    "http_request": {
        "header": [
            {
                "key": "Bearer",
                "value": "{{.AuthzValue}}",
                "authz": true
            }
        ],
        "method": "GET",
        "uri": "https://api.testserver.com/user"
    },
    "http_response": {
        "failed_auth_codes": [
            401
        ],
        "successful_auth_codes": [
            200
        ]
    }
}

Validator

You can use a validator to check if a discovered secret is valid or not. The Endor Labs system rules for secrets include the necessary validator. When you validate a secret, the finding for that secret is categorized as critical, ensuring it receives higher priority compared to others.

When defining a custom rule, you can add your own validator from the command line or from the user interface. The system uses this information to send an HTTP request such as a GET or POST to the address specified by the public service for the detected secret.

For example, when a GitHub Personal Access Token named “ghp_endor123” is detected, the system sends the following HTTP request to GitHub’s address:

curl -H "Authorization: Token "ghp_endor123" https://api.github.com/user

The authentication codes defined by the service are used to mark the secrets as valid or invalid.

The validation portion of the secret rule contains the following fields:

HTTP request header

HTTP request header is a set of key-value pairs that should be added to the header.

{
    "key": "Content-Type",
    "value": "application/json"
}

There are cases where one needs to use a value on runtime and substitute a pattern. For example, the secret itself that needs to be substituted is one such case. This is achieved by declaring a value using the {{.Value}} pattern.

For the HTTP header section that includes the secret, the block looks like the following snippet.

{
    "key": "Token",
    "value": "{{.AuthzValue}}",
    "authz": true,
}

In this case, the scanner replaces the candidate secret that was detected and adds it to the HTTP request header in place of {{.AuthzValue}}.

The following table describes a special case where the key-value pair is marked with the authz flag and is used to craft the “Authorization” part of the header, where three options are supported.

Manage secret rules

1. Select Policies & Rules from the left sidebar.

2. Select Secret Rules.

   The list of all secret rules appears.

3. Select the rule for which you want to view the details.

   The rule details appear in the right sidebar.

   

Clone a secret rule

Click the three vertical dots on the right side of the rule and select Clone Rule.

The cloned rule appears in the list of secret rules and you can edit it.

Edit a secret rule

Click the three vertical dots on the right side of the rule and select Edit Rule.

You can only edit the custom rules that you created or the system rules that you cloned.

Fetch secret rules with endorctl

To fetch the Endor Labs secret scanning rules from the command line type the following commands:

endorctl api list -r SecretRule -n <your-namespace>

For example, to see the rule for the GitHub Personal Access Token, you could search by the name GitHub Personal Access Token or by the rule-id github-pat:

endorctl api get -r SecretRule -n <your-namespace> --name "GitHub Personal Access Token"
endorctl api list -r SecretRule -n <your-namespace> --filter=spec.rule_id==github-pat

Run endorctl scan --secrets to scan for leaked secrets in your source code. You can also scan for secrets with monitoring scans and CI scans. Ensure that you select Secrets as a scan type when you install the Endor Labs App for your SCM to scan for secrets during monitoring scans.

The following table lists the options available with endorctl for secrets scan.

Scan methods

You can perform the following types of scans to detect secrets:

• Scan a specific code reference - Scan for secrets only on a defined path in the context of a checked-out branch, commit SHA or tag to identify secrets and raise findings. This helps you to identify secrets that are leaked in the context of what you are working on right now.

• Scan complete history - Scan for secrets in all existing branches or tags to identify if a secret has ever been leaked in the history of the project and raise findings. This helps you to identify if any secret has ever been leaked even if it was not leaked in the context of what you are working on right now.

• Scan pre-commits - Scan for secrets in the code before committing the code to your repository during the automated pre-commit checks. This helps you identify and remove sensitive information from your code files early in the development life cycle.

Scan a specific code reference

When starting a secrets scan, this default choice utilizes specified rules to search for patterns on the files located in the path where the scan is initiated.

Run the following command in the directory of the code reference to scan for secrets.

endorctl scan --secrets

Specify the --dependencies option in the secrets scan to perform a regular scan that also scans the dependencies.

endorctl scan --secrets --dependencies

Scan complete history

You can scan the Git logs by using the complete history scan. The repository should be present in the scanned path. Endor Labs examines the entire repository history to search for secrets.

To perform a complete scan, include the --git-logs option in the command line.

endorctl scan --secrets --git-logs

Include the --dependencies option in the secrets scan to perform a regular dependency scan along with secret scanning.

endorctl scan --secrets --git-logs --dependencies

The --git-logs option scans the repository’s Git logs using the following logic:

• Perform a full scan if it is the first time the repository’s Git log history is scanned.
• Perform a full rescan if a change has been detected to any of the rules in the namespace.
• Perform an incremental scan based on the last time a scan was performed in all the other cases.

Run the following command to force a full rescan if any of the detected secrets are no longer valid, and you want to accurately reflect the state of the secrets.

endorctl scan --secrets --force-rescan

Specify the --dependencies option in the secrets scan to perform a regular scan that also scans the dependencies.

endorctl scan --secrets --force-rescan --dependencies

Scan pre-commits

You can check for secrets before committing the code to the repository as part of pre-commit hooks.

You must install and initialize endorctl before scanning the pre-commits.

1. Create a .git/hooks/pre-commit file at the root of your Git repository to configure the pre-commit hook. It runs automatically when you make a commit and looks for secrets in your commit.

   cd .git/hooks
   touch pre-commit
   

2. Edit the .git/hooks/pre-commit and include:

   #!/bin/bash
   #
   # Script invoked on git commit.
   #
   if ! endorctl scan --pre-commit-checks --secrets; then
      echo "Pre-commit checks failed"
      exit 1
   fi
   echo "No secrets found: Pre-commit checks succeeded"
   

   --pre-commit-checks performs a pre-commit scan and will scan only the current changes that you are committing to the repository.

3. Set the file permissions to make it executable.

   chmod +x .git/hooks/pre-commit
   

4. You can set up this hook on other systems in your organization by creating a script and running it on each system.

   sh setup-hooks.sh
   #!/bin/sh
   # Copy all hooks to .git/hooks
   cp hooks/* .git/hooks/
   chmod +x .git/hooks/*
   

Here’s an example output when no secrets are found.

Here’s an example when secrets are detected and the commit fails.

Exclude false positives from secret scan

There might be cases where certain lines of code or specific patterns are mistakenly flagged as potential secrets but are safe to include such as test values or non-sensitive information.

To handle such false positives, you can annotate the non-sensitive lines in your source code with endorctl:allow.

# These are test credentials, safe to commit
username = "test_user"  # endorctl:allow
password = "test_password"  # endorctl:allow

Scan for secrets using regular expression

Endor Labs scans for secrets based on regular expressions that are designed to detect the presence of a secret. It then validates the discovered secrets against external APIs to identify if they are valid. Valid secrets actively provide access to a service or an application and can be used to gain unauthorized access.

Regular expressions are customized to match specific types of secrets, such as GitHub personal access tokens, OAuth access tokens, AWS access tokens, OpenAPI keys, Client IDs, Client Secrets, and more.

For example, you can describe a GitHub Personal Access Token with the following regular expression.

github_pat_[0-9a-zA-Z_]{82}

You can view the findings generated out of secrets, prioritize them, and take corrective action.

1. Sign in to Endor Labs and select Projects from the left sidebar.

2. Select the project for which you want to view the secrets.

3. Select Secrets under First Party Code to view secret findings.

   

4. Select a finding to view the following details:

   • Project: The name of the project where the secret is found, finding policy, categories, and attributes of the project.
   • Risk Details:
     • Indicates if the identified secret is valid or invalid.
     • Explanation of the finding.
     • Remediation recommended.

5. Click View Details to explore additional information about the secrets findings.

Containers help developers create, test, and deploy applications in a consistent environment. Container images include standalone or executable files encompassing files, libraries, and dependencies needed to run a container. They include several open-source software, making them vulnerable to open-source risks.

Gaining visibility into container images is essential to identify and prioritize risks or maintain compliance obligations.

Endor Labs container scan detects and reports known vulnerabilities and other risks in:

• Operating system packages: Identifies packages installed through the container’s base operating system package manager.
• Programming language packages: Identifies packages installed through language-specific package managers.
• Libraries and dependencies: Identifies static and dynamic libraries, and runtime dependencies required by the application.

Additionally, it generates an SBOM (Software Bill of Materials) that details all components, their versions, and associated metadata, providing a complete inventory of the container’s contents.

Upgrade to endorctl version 1.6.734 or higher to ensure accurate container scan results. Sometimes, container scans performed with older endorctl versions may yield different or no results.

Verify access to container registries

If the container image is in a private Docker registry, you must authenticate the container client before the scan.

Here are a few commands to authenticate the container client.

docker login <host> -u <user_name> -p <password>

podman login -u <user_name> -p <password> <host>

Run the endorctl scan

Endor Labs supports the following methods of scanning container images:

• Scan container images in a Git repository: Use this approach to scan images built within your repository using a Dockerfile.

• Scan container images as a standalone project: Use this approach to scan base or golden images that are shared across multiple repositories or applications.

• Scan container image tarball: Use this to scan images saved as tar files, such as base images exported from Docker, to generate dependency, SBOM, and vulnerability reports.

Scan container images in a Git repository

endorctl container scan --image=<image_name:tag> --path=users/janedoe/endorlabs/npm/exampleproject

endorctl container scan --image=<image_name1:tag> --path=users/janedoe/endorlabs/npm/exampleproject
endorctl container scan --image=<image_name2:tag> --path=users/janedoe/endorlabs/npm/exampleproject
endorctl container scan --image=<image_name3:tag> --path=users/janedoe/endorlabs/npm/exampleproject

endorctl container scan --image=<image_name:tag> --path=users/janedoe/endorlabs/npm/exampleproject --finding-tags=<image_name:tag>

Scan container images as a standalone project

endorctl container scan --image=<image_name:tag> --project-name=<endor_project_name>

endorctl container scan --image=<image_name:tag> --project-name=<endor_project_name> --as-ref

endorctl container scan --project-name=<endor_project_name> --image=<image_name:tag> --as-ref --finding-tags=<image_name:tag>

Scan container image tarball

Run container scan in CI pipelines

You can integrate container scanning into CI pipelines to automatically detect vulnerabilities and ensure the security of container images during the build and deployment process.

To perform container scanning in CI pipelines using GitHub Actions, set the scan_container parameter to true in the GitHub Actions script. Additionally, you must provide the image parameter with the container image you want to scan.

See Performing scans in CI/CD pipelines for more information.

Understand container scan

Endor Labs fetches the container image from a container registry or loads it from a local file to scan containers. It then proceeds to extract the layers of the container image. It traverses the filesystem of each layer to identify files and directories. It looks for known package manager and metadata files to gather information about installed packages and their versions. It identifies various components and dependencies within the image and presents the findings in CLI and the Endor Labs user interface.

Discover base images of containers

A container image is often built upon a base image that is a foundational layer including an operating system and other essential components. It’s crucial to understand what’s in the base image for a thorough security assessment.

You can distinguish the base image related vulnerabilities from the application layer using any of the following methods:

• Scan Sequence - First, scan the base image. Then, scan any subsequent images built on that base image to distinguish vulnerabilities specific to the base image from those introduced by the other layers.
• Docker file label - Set the label directly in your Dockerfile with a command such as LABEL org.opencontainers.image.base.name="openjdk:17-slim".
• Build time label - Include the base image label during the build process with the --label flag, specifying both the base image and, optionally, its exact version via SHA256 hash. For example:

   docker build -t tictactoe:latest --label "org.opencontainers.image.base.name=openjdk@sha256:eddacbc7e24bf8799a4ed3cdcfa50d4b88a323695ad80f317b6629883b2c2a78" .

Create finding policies for containers

Container base images from untrusted sources may lack proper security audits or fail to comply with organizational standards, increasing the risk of vulnerabilities being exploited. To address this, you can configure a finding policy to detect unauthorised base images and raise a critical finding.

For example, to allow only base images that start with gcp or ghcr, use the Container policy template and Specify Base Image Name Regex as ^gcp, ^ghcr.

See also Create a finding policy from template.

Supported languages and package managers

The dependencies associated with the following list of components are identified in the endorctl scan.

Endor Labs recognizes only the installed dependencies. Declared but uninstalled dependencies in the container image are not recognized.

View container findings

To view findings from the container scan:

1. Select Projects from the left sidebar.

2. Select the project for which you want to view the container findings.

3. Select Containers from the preset filters.

4. To view and filter dependencies based on the container images, click Container Layers and select to view All Layers, Base Image Layers Only, or Application Layers Only.

   

How Endor Labs derives container findings

Endor Labs’ container scanning results rely on OVAL feeds from distributions, which provide accurate, vetted vulnerability data, excluding disputed or irrelevant entries. OS dependency results are based on data from distribution developers, while for language package dependencies, we complement published data with our proprietary research.

Endor Labs categorizes the severity of vulnerabilities detected in container scans as follows:

• Use the severity assigned by the distribution, if it exists.
• Use the NVD severity if the distribution does not provide the severity.
• Report the vulnerability as Medium if there is no severity assigned by the distribution, or the NVD severity is not known or can’t be matched.

Endor Labs doesn’t report the following vulnerabilities:

• Minor vulnerabilities in Debian and Ubuntu.
• Disputed vulnerabilities withdrawn from NVD.

Limitations of container findings

• Scanning Windows containers is not supported.
• Docker file scans are not currently supported.
• Container registry direct integrations are not currently supported.
• Support for scanning binary files inside a container is limited.
• Endor scores are not calculated for findings reported in the container scan.

Artifact signing

For securing your container images with cryptographic signatures, see Artifact Signing.

Endor Labs allows you to determine whether the OS packages present in a container image are actually used by your application at runtime. Use container reachability to distinguish dependencies that are merely installed from those that are actively exercised during execution, helping security teams prioritize the most critical security issues for remediation.

Prerequisites

To perform container reachability analysis, ensure you meet the following system requirements:

• The container must have sufficient CPU and memory resources to run successfully.

• The container must be runnable.

• The container must have network access if its startup process requires external communication.

• Docker daemon dockerd must be installed on the host, must be runnable and accessible to the current user without elevated privileges. For example, docker images should work without sudo.

• The negotiated Docker API version between the client and server must be 1.48 or higher.

• The scan must be run on either a Linux or macOS host machine. Container reachability is supported for both amd64 and arm64 architectures.

Determine container reachability

Endor Labs determines container reachability by extracting OS packages from the container image, profiling the container’s runtime behavior, and correlating the results to identify which dependencies are actually used during execution. The steps below describe how container reachability is determined.

1. Dependency extraction - Endor Labs extracts all packages and dependencies present in the container image by analyzing its file system to identify installed OS packages and their file path locations within the image.

2. Dynamic profiling - Endor Labs runs the container image in a controlled environment, monitoring which OS-level files and dependencies are accessed during execution. The profiling captures runtime behavior including system calls, process IDs, and file path access patterns. It also identifies the main process that starts the container as the entry point and uses it to determine which packages are reachable through their dependency relationships.

3. Path matching and reachability determination - Endor Labs correlates the results from both steps by comparing the extracted dependency file paths against the file access patterns captured during profiling, then assigns each dependency a reachability status based on whether it was accessed during execution.