Perform monitoring scans to gain fast and broad visibility over open source risks across the application portfolio without requiring integrations into application pipelines. These scans are conducted periodically.

graph TB
    subgraph Customer["Customer Environment"]
        REPOS[("Source Code Repositories")]
    end

    subgraph Endor[<label style='font-size: 17px'>Endor Labs Infrastructure</label>]
        APP["Endor Labs App"]
        CLOUD["Scan Environment<br/><small>Customer data destroyed after scans</small>"]
        PLATFORM["Endor Labs Platform<br/><small>Generate findings and alerts</small>"]
    end

    APP -->|<small>1. Continuous monitoring</small>| REPOS
    APP -->|<small>2. Trigger scan every 24h or on-demand</small>| CLOUD
    CLOUD <-->|<small>3. Clone and scan repositories</small>| REPOS
    CLOUD -->|<small>4. Send results</small>| PLATFORM

    style REPOS fill:#C4B5FD

Endor Labs monitoring scans are available for the following source code management (SCM) platforms:

• GitHub: You can use the Endor Labs GitHub App to scan your GitHub organizations. It provides broad visibility over your GitHub organizations. Once installed, the GitHub App will automatically clone and scan all the repositories every 24 hours, providing continuous monitoring for open source vulnerabilities. It performs RSPM scans for posture management of your repository weekly on Sundays. These repositories are temporarily cloned and retained only during the scan. See Scan using the GitHub App for more information. Endor Labs supports GitHub cloud. GitHub App supports pull request scans and pull request comments. See Scan pull requests using the GitHub App for more information.
• Azure DevOps: You can use the Endor Labs Azure DevOps App to scan your Azure projects organizations. It provides broad visibility over your Azure organizations. Once installed, the Azure DevOps App will automatically clone and scan all Azure repos every 24 hours, providing continuous monitoring for open source vulnerabilities. These repositories are temporarily cloned and retained only during the scan. See Deploy Endor Labs Azure DevOps App for more information. Endor Labs supports Azure DevOps cloud instances.
• GitLab: You can use the Endor Labs GitLab App to scan your GitLab organization. It provides broad visibility over your GitLab group and subgroups. Once installed, the GitLab App will automatically clone and scan all projects every 24 hours, providing continuous monitoring for open source vulnerabilities. These repositories are temporarily cloned and retained only during the scan. See Deploy Endor Labs GitLab App for more information. Endor Labs support both GitLab cloud and self-managed instances. GitLab App supports merge request scans. See Scan merge requests using the GitLab App for more information.
• GitHub Enterprise Server: You can use the Endor Labs GitHub App Enterprise to scan your self-hosted GitHub Enterprise Server (GHES) organizations and repositories. Once installed, the app will automatically clone and scan all repositories every 24 hours, providing continuous monitoring for open source vulnerabilities. It performs RSPM scans for posture management of your repository weekly on Sundays. These repositories are temporarily cloned and retained only during the scan. The app supports pull request scans and pull request comments as well. See Deploy Endor Labs GitHub App Enterprise for more information.
• Bitbucket Data Center: You can use the Endor Labs Bitbucket App to scan your Bitbucket Data Center. It provides broad visibility over your Bitbucket projects. Once installed, the Bitbucket App will automatically clone and scan all projects every 24 hours, continuously monitoring open source vulnerabilities. These repositories are temporarily cloned and retained only during the scan. See Deploy Endor Labs Bitbucket App for Data Center for more information.
• Bitbucket Cloud: You can use the Endor Labs Bitbucket App to scan your Bitbucket Cloud. It provides broad visibility over your Bitbucket Cloud projects. Once installed, the Bitbucket App will automatically clone and scan all projects every 24 hours, providing continuous monitoring for open source vulnerabilities. These repositories are temporarily cloned and retained only during the scan. See Deploy Endor Labs Bitbucket App for Bitbucket Cloud for more information.
• Local monitoring scan: Perform periodic scans in your local environment. You must provide the necessary computing resources to run the scans. These scans can support any type of Git repository. See Set up Jenkins pipeline for supervisory scans.

Monitoring scan setup wizard

You can use the following wizard to get a tailored plan for setting up monitoring scans for your SCM platform.

Support Matrix for monitoring scans

Endor Labs features available depends upon the type of scan and the SCM.

The following table lists the scan capabilities available for different types of SCM.

Remediation

The following table lists the types of remediation available for different types of SCM.

Default branch detection

Endor Labs provides a GitHub App that continuously monitors users’ projects for security and operational risk. You can use the GitHub App to selectively scan your repositories for SCA, secrets, RSPM, or GitHub Actions. GitHub App scans also establish baselines that are subsequently used during CI scans.

The Endor Labs GitHub App scans your repositories every 24 hours and reports new findings or changes to your code’s release versions. It also performs RSPM scans weekly on Sundays to manage your repository’s posture. See Scan with GitHub App for more information. You can also manually trigger scans for your repositories. See Re-scan projects for more information. After you install the GitHub App, you can make further changes to the settings. See Manage GitHub App for more information. You may need to review the technical limitations of the GitHub App so that you can use the GitHub App to its full potential. See Technical limitations of the Endor Labs GitHub App for more information.

If you want to use PR remediations as part of your monitoring scan or need to export your findings to GitHub Advanced Security, you need to use GitHub App (Pro).

If you are using GitHub Enterprise Server, you can use the GitHub Enterprise Server App to continuously monitor your environment.

Default branch detection

Prerequisites for GitHub App

Before installing and scanning projects with Endor Labs GitHub App, make sure you have:

• A GitHub cloud account and organization. If you don’t have one, create one at GitHub.
• Administrative permissions to your GitHub organization. Installing the Endor Labs GitHub App in your organization requires approval or permissions from your GitHub organizational administrator. If you don’t have the permissions, use the command line utility, endorctl, while you wait for the approval.
• Endor Labs GitHub App requires:
  • Read permissions to Dependabot alerts, actions, administration, code, commit statuses, issues, metadata, packages, repository hooks, and security events.
  • Write permissions to checks and pull requests to check the pull requests automatically and surface policy violations to developers as pull request comments.
  • Subscribe to check run, check suite, and pull request events.

Install the GitHub App

To automatically scan repositories using the GitHub App:

1. Sign in to Endor Labs.

2. Select Projects from the left sidebar and click Add Project.

3. From GitHub, choose GitHub App.

   

4. Click Install GitHub App.

   You will be redirected to GitHub to install the GitHub App.

   

5. Click Install.

6. Select a user to authorize the app.

7. Select the organization in which you want to install the app.

8. Select whether to install and authorize Endor Labs on all your repositories or select the specific repositories that you wish to scan.

   

9. Review the permissions required for Endor Labs and click Install and Authorize.

10. Choose a namespace and click Next.

    

11. Based on your license, select and enable the scanners.

    • SCA: Perform software composition analysis and discover AI models used in your repository.
    • RSPM: Scan the repository for misconfigurations. RSPM scans run every week on Sundays.
    • Secret: Scan the repository for exposed secrets.
    • GitHub Actions: Scan the repository and identify all the GitHub Actions workflows used in the repository.
    • SAST: Scan your source code for weakness and generate SAST findings.

12. Select Include Archived Repositories to scan your archived repositories. By default, the GitHub archived repositories aren’t scanned.

13. Select PULL REQUEST SCANS to set preferences for scanning pull requests submitted by users.

    

    • Select Pull Request Comments to enable GitHub Actions to comment on PRs for policy violations.

    • In Define Scanning Preferences, select either:

      • Quick Scan to gain rapid visibility into your software composition. It performs dependency resolution but does not conduct reachability analysis to prioritize vulnerabilities. The quick scan enables users to swiftly identify potential vulnerabilities in dependencies, ensuring a smoother and more secure merge into the main branch.

      • Full Scan to perform dependency resolution, reachability analysis, and generate call graphs for supported languages and ecosystems. This scan enables users to get complete visibility and identifies all issues dependencies, call graph generation before merging into the main branch. Full scans may take longer to complete, potentially delaying PR merges.

      See GitHub scan options for more information on the scans that you can do with the GitHub App.

14. Click Continue.

You have successfully installed the GitHub App.

Set up package repositories

You can improve your experience with the GitHub App by setting up package repositories. This will help you create a complete bill of materials and perform static analysis. Without setting package repositories, you may not be able to get an accurate bill of materials. See Set up package manager integration for more information.

Endor Labs provides an Azure DevOps App that continuously scans Azure repos in your projects for security risks. You can selectively scan your repositories for SCA, secrets, and SAST.

You can choose to configure the Azure DevOps App at the organization level or the project level. When you configure the Azure DevOps App at the organization level, Endor Labs adds all the projects under the organization and scans all the repos in the projects. When you add an Azure DevOps project, Endor Labs scans all repos within that project.

See Manage Azure App to learn how to manage your Azure App integration in Endor Labs.

Managed namespaces for Azure DevOps

You need to add an Azure organization or a project to an Endor Labs namespace. Organizations and projects in Azure DevOps are mapped as managed namespaces in Endor Labs.

Managed namespaces have the following restrictions:

• You cannot delete managed namespaces.
• You cannot delete repos present within managed namespaces.
• You cannot add projects or create namespaces within managed namespaces.
• You cannot create any new Endor Labs App installation within the managed namespaces.

Namespace structure when you add an Azure organization

When you add an Azure organization to an Endor Labs namespace, Endor Labs creates a child namespace for the organization and creates child namespaces for each project in the organization under the organization namespace. The organization namespace and project namespaces are managed namespaces. You can add multiple projects to the same Endor Labs namespace. Each project will have its own managed namespace.

If your organization name is deerinc and you have three projects, buck, doe, and fawn, Endor Labs creates four managed namespaces: deerinc, buck, doe, and fawn. The namespaces buck, doe, and fawn are child namespaces of the deerinc namespace.

The following image shows the namespace structure in Endor Labs.

graph TD

      %% Endor Labs namespace
      EN[endor-azure]

      %% Azure projects
      O1[deerinc]
      P1[buck]
      P2[doe]
      P3[fawn]


      %% connections
      EN --> O1
      O1 --> P1
      O1 --> P2
      O1 --> P3

      class EN,EN2 endor
      class O1,P1,P2,P3 managed
      classDef managed fill:#5EEAD4

Namespace structure when you add an Azure DevOps project

When you add an Azure DevOps project to an Endor Labs namespace, Endor Labs creates a child namespace for the Azure DevOps project and maps all repositories in that project to this namespace. The child namespace that maps to the Azure DevOps project is a managed namespace. The managed namespace has the name, <organization name>-<project name>. For example, if your organization name is deerinc and project name is doe, the managed namespace will have the name, deerinc-doe.

You can add multiple projects to the same Endor Labs namespace. Each project will have its own managed namespace. For example, your organization name is deerinc, which has three projects, buck,doe, andfawn. You add each project to the Endor Labs namespace, endor-azure.

The following image shows the namespace structure in Endor Labs.

graph TD

      %% Endor Labs namespace
      EN[endor-azure]

      %% Azure projects
      A1[deerinc-buck]
      A2[deerinc-doe]
      A3[deerinc-fawn]


      %% connections
      EN --> A1
      EN --> A2
      EN --> A3

      class EN,EN2 endor
      class A1,A2,A3 managed
      classDef managed fill:#5EEAD4

To run CLI scans for a repository that is already scanned by the Endor Labs Azure DevOps App, specify the correct managed child namespace using the -n argument to prevent creating duplicate projects.

Default branch detection

Prerequisites for Azure DevOps App

Ensure the following prerequisites are in place before you install the Endor Labs Azure DevOps App.

• An Azure DevOps cloud account and organization. If you don’t have one, create one at Azure DevOps.
• Endor Labs Azure DevOps App requires read permissions to in your projects. You can grant these permissions by providing read access to the Code category when you create an Azure DevOps personal access token for Endor Labs.

Install the Azure DevOps App

To automatically scan repositories using the Azure DevOps App:

1. Sign in to Endor Labs.

2. Select Projects from the left sidebar and click Add Project.

3. From AZURE, select Azure DevOps App.

   

4. Enter the host URL of your Azure project.

   The URL must be in the format, https://dev.azure.com/<ORG_NAME>/ when you add an Azure organization. When you add an Azure DevOps project, the URL must be in the format, https://dev.azure.com/<ORG_NAME>/<PROJECT_NAME>.

5. Enter your personal access token from Azure.

   You must have at least read permissions in the Code category for your Azure DevOps personal access token.

6. Click Scanners and select the scan types to enable.

   • SCA: Perform software composition analysis and discover AI models used in your repository.
   • Secret: Scan Azure repos for exposed secrets.
   • SAST: Scan your source code for weakness and generate SAST findings.

   The available scan types depend upon your license.

7. Select Include Disabled Repositories to scan your archived repositories. By default, the Azure archived repositories aren’t scanned.

8. Click Create.

Endor Labs Azure DevOps App scans your Azure repos every 24 hours and reports any new findings or changes to release versions of your code.

A CI scan may fail if triggered while monitoring scan from the Endor Labs Azure DevOps App is in progress. Complete the monitoring scans first to prevent conflicts.

Endor Labs provides a GitLab App that continuously monitors users’ projects for security and operational risk. You can use the GitLab App to selectively scan your repositories for SCA, secrets, SAST, and CI/CD tools. You can use the GitLab App with a GitLab cloud account or a self-hosted GitLab instance.

When you use Endor Labs GitLab App, Endor Labs creates namespaces based on your organization hierarchy in GitLab.

The namespaces created by the Endor Labs GitLab App are not like regular namespaces and are called managed namespaces. These namespaces are named after subgroup slugs in GitLab.

See Manage GitLab App to learn how to manage your GitLab App integration in Endor Labs.

You can also scan your merge requests using the GitLab App. You can enable MR scans during the installation of the GitLab App or by editing the GitLab App integration. See GitLab App MR scans for more information.

Limitations of GitLab groups in Endor Labs namespace

Ensure that you consider the following limitations when you use the GitLab monitoring scan.

• GitLab supports up to 20 levels of subgroup nesting, while Endor Labs currently supports a maximum of 10 levels, assuming the installation is created at the tenant level. If a GitLab installation is created within a nested namespace, such as tenant.namespace1.namespace2, the available nesting depth for subgroups in GitLab is reduced. In this case, Endor Labs can only support up to eight levels of nested subgroups.
• Endor Labs supports GitLab groups with a maximum of 64 characters.

Managed namespaces for GitLab

Managed namespaces are always reflective in terms of structure and content in GitLab.

Managed namespaces have the following restrictions:

• You cannot delete managed namespaces.

• You cannot delete projects present within managed namespaces.

• You cannot add projects or create namespaces within managed namespaces.

• You cannot create any new Endor Labs App installation within the managed namespaces.

  For example, you cannot create an Endor Labs GitHub App installation within a namespace that was created by the Endor Labs GitLab App.

Any modifications to the namespaces have to be in GitLab. The changes that you make to the namespaces and projects are reflected in Endor Labs after a rescan.

If your organization has the following hierarchy in GitLab:

graph TD
    GL((GitLab))
    HC[HappyCorp]

    %% Main divisions
    Web[Web]
    Mobile[Mobile]
    Desktop[Desktop]

    %% Web subgroups
    WA[Alpha]
    WB[Beta]
    WG[Gamma]

    %% Mobile subgroups
    MD[Delta]
    ME[Epsilon]
    MZ[Zeta]

    %% Desktop subgroups
    DP[Pi]
    DR[Rho]
    DS[Sigma]

    %% Main connections
    GL --> HC
    HC --> Web
    HC --> Mobile
    HC --> Desktop

    %% Web connections
    Web --> WA
    Web --> WB
    Web --> WG

    %% Mobile connections
    Mobile --> MD
    Mobile --> ME
    Mobile --> MZ

    %% Desktop connections
    Desktop --> DP
    Desktop --> DR
    Desktop --> DS

    class HC main
    class Web,Mobile,Desktop division
    classDef default fill:#777777
    classDef circle fill:#95A5A6
    class GL circle

Endor Labs creates managed namespaces that mirror your GitLab groups under an Endor Labs namespace (for example, happyendor). Endor Labs creates happycorp as the parent namespace with web, mobile, and desktop as the child namespaces. The namespace happycorp will be under the Endor Labs namespace.

Each of these child namespaces have further child namespaces as follows:

• web: alpha, beta, gamma
• mobile: delta, epsilon, zeta
• desktop: pi, rho, sigma

The following diagram shows the organization of namespaces in Endor Labs.

graph TD
    EN[happyendor]
    HC[happycorp]

    %% Main divisions
    Web[web]
    Mobile[mobile]
    Desktop[desktop]

    %% Web subgroups
    WA[alpha]
    WB[beta]
    WG[gamma]

    %% Mobile subgroups
    MD[delta]
    ME[epsilon]
    MZ[zeta]

    %% Desktop subgroups
    DP[pi]
    DR[rho]
    DS[sigma]

    %% Main connections
    EN --> HC
    HC --> Web
    HC --> Mobile
    HC --> Desktop

    %% Web connections
    Web --> WA
    Web --> WB
    Web --> WG

    %% Mobile connections
    Mobile --> MD
    Mobile --> ME
    Mobile --> MZ

    %% Desktop connections
    Desktop --> DP
    Desktop --> DR
    Desktop --> DS

    class HC main
    class EN endor
    class Web,Mobile,Desktop division
    class WA,WB,WG,MD,ME,MZ,DP,DR,DS group
    classDef main fill:#008B87
    classDef division fill:#008B87
    classDef group fill:#008B87

Manage multiple installations of GitLab App

You cannot create multiple GitLab installations with the same root group in the host URL within the same Endor Labs namespace.

For example, if a GitLab installation exists with a host URL like gitlab.com/group1/sg1, you cannot create another installation with a host URL like gitlab.com/group1/sg2 within the same Endor namespace. Instead, you must create the installation with a different root group in the host URL, such as gitlab.com/group2/sg2.

graph TD

      %% Endor Labs namespace
      EN[happyendor]

      %% GitLab groups
      G1[group1]
      G2[group2]
      SG1[sg1]
      SG2[sg2]

      %% connections
      EN --> G1
      EN --> G2
      G1 --> SG1
      G2 --> SG2

      class EN endor
      class G1,G2,SG1,SG2 managed
      classDef managed fill:#008B87

If you wish to create an installation with a host URL like gitlab.com/group1/sg2, it should be inside a different Endor Labs namespace.

graph TD

      %% Endor Labs namespace
      EN[happyendor]
      EN2[happyendor2]

      %% GitLab groups
      G1[group1]
      G2[group1]
      SG1[sg1]
      SG2[sg2]

      %% connections
      EN --> G1
      EN2 --> G2
      G1 --> SG1
      G2 --> SG2

      class EN,EN2 endor
      class G1,G2,SG1,SG2 managed
      classDef managed fill:#008B87

Default branch detection

Prerequisites for GitLab App

Before installing and scanning projects with Endor Labs GitLab App, make sure you have:

• A GitLab cloud account or a self-hosted GitLab instance.
• An organization in GitLab.
• Endor Labs GitLab App requires a GitLab personal access token with at least read_api permission. You need to provide the api permission if you want to scan your merge requests.

Install the GitLab App

1. Sign in to Endor Labs.

2. Select Projects from the left sidebar and click Add Project.

3. From GITLAB, select GitLab App.

   

4. Enter the GitLab organization URL in the format: https://gitlab.com/{group}/{subgroup1}/....

   You need to enter at least the root group. For example, https://gitlab.com/group1.

   You can provide the host URL up to any subgroup level. For example, https://gitlab.com/group1/subgroup1/subgroup2/subgroup3.

   Endor Labs creates namespaces for groups and subgroups and maps projects to these namespaces.

   If the GitLab installation is created at the tenant level, Endor Labs supports up to 10 levels of GitLab group nesting. If the installation is created within a nested namespace under the tenant, the supported nesting depth decreases by one level for each additional level of nesting.

5. Enter the GitLab personal access token.

6. Select the scan types to enable:

   • SCA: Perform software composition analysis and discover AI models used in your repository.
   • Secret: Scan GitLab projects for exposed secrets.
   • SAST: Scan GitLab projects to generate SAST findings.

   The available scan types depend upon your license.

7. Select Include Archived Repositories to scan your archived repositories. By default, the GitLab archived repositories aren’t scanned.

8. Click Create.

   Your GitLab App installation is created and has now started monitoring the projects in your groups. Endor Labs GitLab App scans your GitLab projects every 24 hours and reports any new findings.

9. Optionally, you can continue to Configure GitLab App MR scans to scan your merge requests.

   

   You can also choose to configure the webhook for MR scans and apply it to specific projects through a scan profile. See Scan profiles for more information. Thereby, you can ensure that MR scans are only for selected projects rather than for all the projects in the group.

10. Click Skip to if you don’t want to scan your merge requests.

    You can enable MR scans later in the GitLab App integration.

Endor Labs provides a Bitbucket App that continuously monitors users’ projects for security and operational risks in Bitbucket Data Center. You can use the Bitbucket App to selectively scan your repositories for SCA, secrets, and SAST.

When you use the Endor Labs Bitbucket App, it creates namespaces based on your projects in Bitbucket Data Center. The namespaces created by the Endor Labs Bitbucket App are not like regular namespaces and are called managed namespaces. You can either configure the URL to Bitbucket Data Center to import all the projects or configure the project key to import a specific project in Endor Labs.

See Manage Bitbucket Data Center App to learn how to manage your Bitbucket Data Center App integration in Endor Labs.

Managed namespaces for Bitbucket Data Center

You need to add the Bitbucket Data Center host or a project to an Endor Labs namespace. Bitbucket host and projects are mapped as managed namespaces in Endor Labs.

Managed namespaces have the following restrictions:

• You cannot delete managed namespaces.
• You cannot delete repositories within managed namespaces.
• You cannot add projects or create namespaces within managed namespaces.
• You cannot create new Endor Labs App installations within managed namespaces.

Namespace structure when you add a Bitbucket Data Center host

When you add a Bitbucket Data Center host to an Endor Labs namespace, Endor Labs creates a child namespace for the Bitbucket host and creates child namespaces for each project in the host under the host namespace. The namespaces of the host and projects are managed namespaces. If there are periods (.) in the Bitbucket Data Center hostname, it is converted to a hyphen (-). You can add multiple Bitbucket Data Center hosts to the same Endor Labs namespace. Each host will have its own managed namespace.

If your host name is bitbucket.deerinc.com and you have three projects, buck, doe, and fawn, Endor Labs creates four managed namespaces: bitbucket-deerinc-com, buck, doe, and fawn. The namespaces buck, doe, and fawn are child namespaces of the bitbucket-deerinc-com namespace.

The following image shows the namespace structure in Endor Labs.

graph TD

      %% Endor Labs namespace
      EN[endor-bitbucket]

      %% Bitbucket projects
      O1[bitbucket-deerinc-com]
      P1[buck]
      P2[doe]
      P3[fawn]


      %% connections
      EN --> O1
      O1 --> P1
      O1 --> P2
      O1 --> P3

      class EN,EN2 endor
      class O1,P1,P2,P3 managed
      classDef managed fill:#5EEAD4

Namespace structure when you add a Bitbucket Data Center project

When you add a Bitbucket Data Center project to an Endor Labs namespace, Endor Labs creates a child namespace for the Bitbucket Data Center project and maps all repositories in that project to this namespace. The child namespace that maps to the Bitbucket Data Center project is a managed namespace. The managed namespace has the name, <host name>_<project name>. For example, if your Bitbucket hostname is bitbucket.deerinc.com and project name is doe, the managed namespace will have the name, bitbucket-deerinc-com_doe.

You can add multiple projects to the same Endor Labs namespace. Each project will have its own managed namespace. For example, your hostname is bitbucket.deerinc.com, which has three projects, buck, doe, and fawn. You add each project to the Endor Labs namespace, endor-bitbucket.

The following image shows the namespace structure in Endor Labs.

graph TD

      %% Endor Labs namespace
      EN[endor-bitbucket]

      %% Bitbucket projects
      A1[bitbucket-deerinc-com_buck]
      A2[bitbucket-deerinc-com_doe]
      A3[bitbucket-deerinc-com_fawn]


      %% connections
      EN --> A1
      EN --> A2
      EN --> A3

      class EN,EN2 endor
      class A1,A2,A3 managed
      classDef managed fill:#5EEAD4

Default branch detection

Prerequisites for Bitbucket Data Center App

Ensure the following prerequisites are in place before you install the Endor Labs Bitbucket App.

• A publicly accessible Bitbucket Data Center host set up with HTTPS.

• A Bitbucket HTTP access token with at least Project read permission at the project level.

• If your Bitbucket Data Center instance is self-hosted behind a firewall with ingress restrictions, you must configure your firewall to allow inbound connections from Endor Labs. See Firewall & Proxy Rules for detailed guidance on configuring firewall access.

Install the Bitbucket Data Center App

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

2. Click Add Project.

3. Select Bitbucket on the Scan your repositories page.

4. Select Bitbucket Data Center.

   

5. Enter the Bitbucket hostname URL.

   • To import all the projects, provide the base Bitbucket Data Center URL in the format https://<hostname>.
   • To import a specific project, provide the project URL in the format https://<bitbucket-hostname>/projects/{project-key}. For example, https://bitbucket.company.com/projects/LAB.

   Endor Labs creates namespaces for all projects that are available in the Bitbucket Data Center host.

6. Enter the Bitbucket Data Center HTTP access token.

7. Select the scan types to enable.

   • SCA: Perform software composition analysis and discover AI models used in your repository.
   • Secret: Scan Bitbucket projects for exposed secrets.
   • SAST: Scan Bitbucket projects to generate SAST findings.

   The available scan types depend upon your license.

8. Select Include Archived Repositories to scan your archived repositories.

   By default, the Bitbucket archived repositories aren’t scanned.

9. Click Create.

10. Optionally, you can continue to Configure Bitbucket Data Center App PR scans to scan your pull requests.

You can choose to apply PR scans for specific repositories rather than all repositories in your Bitbucket project by configuring a scan profile. See Configure PR scans for specific repositories for more information.

You can also enable PR scans later in the Bitbucket Data Center App integration.

Endor Labs Bitbucket Data Center App scans your Bitbucket projects every 24 hours and reports any new findings or changes to release versions of your code.

Endor Labs provides a Bitbucket App that continuously monitors users’ projects for security and operational risks in Bitbucket Cloud. You can use the Bitbucket App to selectively scan your repositories for SCA, secrets, and SAST.

When you use the Endor Labs Bitbucket App, it creates namespaces based on your workspace and projects in Bitbucket Cloud. The namespaces created by the Endor Labs Bitbucket App are not like regular namespaces and are called managed namespaces. You can either configure the URL to Bitbucket Cloud to import all the projects or configure the project key to import a specific project in Endor Labs.

See Manage Bitbucket Cloud App to learn how to manage your Bitbucket Cloud App integration in Endor Labs.

Managed namespaces for Bitbucket Cloud

You need to add the Bitbucket Cloud workspace or a project to an Endor Labs namespace. Bitbucket Cloud workspace and projects are mapped as managed namespaces in Endor Labs.

Managed namespaces have the following restrictions:

• You cannot delete managed namespaces.
• You cannot delete repositories within managed namespaces.
• You cannot add projects or create namespaces within managed namespaces.
• You cannot create new Endor Labs App installations within managed namespaces.

Namespace structure when you add a Bitbucket Cloud workspace

When you add a Bitbucket Cloud workspace to an Endor Labs namespace, Endor Labs creates a child namespace for the Bitbucket Cloud workspace and creates child namespaces for each project in the workspace under the workspace namespace. The namespaces of the workspace and projects are managed namespaces. You can add multiple Bitbucket Cloud workspaces to the same Endor Labs namespace. Each workspace will have its own managed namespace.

If your workspace name is deerinc and you have three projects, buck, doe, and fawn, Endor Labs creates four managed namespaces: deerinc, buck, doe, and fawn. The namespaces buck, doe, and fawn are child namespaces of the deerinc namespace.

The following image shows the namespace structure in Endor Labs.

graph TD

      %% Endor Labs namespace
      EN[endor-bitbucket]

      %% Bitbucket projects
      O1[deerinc]
      P1[buck]
      P2[doe]
      P3[fawn]


      %% connections
      EN --> O1
      O1 --> P1
      O1 --> P2
      O1 --> P3

      class EN,EN2 endor
      class O1,P1,P2,P3 managed
      classDef managed fill:#5EEAD4

Namespace structure when you add a Bitbucket Cloud project

When you add a Bitbucket Cloud project to an Endor Labs namespace, Endor Labs creates a child namespace for the Bitbucket Cloud project and maps all repositories in that project to this namespace. The child namespace that maps to the Bitbucket Cloud project is a managed namespace. The managed namespace has the name, <workspace name>_<project name>. For example, if your Bitbucket Cloud workspace name is deerinc and project name is doe, the managed namespace will have the name, deerinc_doe.

You can add multiple projects to the same Endor Labs namespace. Each project will have its own managed namespace. For example, your workspace name is deerinc, which has three projects, buck,doe, andfawn. You add each project to the Endor Labs namespace, endor-bitbucket.

The following image shows the namespace structure in Endor Labs.

graph TD

      %% Endor Labs namespace
      EN[endor-bitbucket]

      %% Bitbucket projects
      A1[deerinc_buck]
      A2[deerinc_doe]
      A3[deerinc_fawn]


      %% connections
      EN --> A1
      EN --> A2
      EN --> A3

      class EN,EN2 endor
      class A1,A2,A3 managed
      classDef managed fill:#5EEAD4

Default branch detection

Prerequisites for Bitbucket App for Bitbucket Cloud

Ensure the following prerequisites are in place before you install the Endor Labs Bitbucket App.

• Bitbucket Cloud instance with workspace and projects
• A Bitbucket access token either at the workspace level to import a workspace, or the project level to import a project. The token must have at least Project read permission.

Install the Bitbucket Cloud App

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

2. Click Add Project.

3. Select Bitbucket on the Scan your repositories page.

4. Select Bitbucket Cloud.

   

5. Enter the Bitbucket Cloud workspace URL.

   • To import all the projects in the workspace, provide the workspace URL in the format https://bitbucket.org/{workspace}.
   • To import a specific project, provide the project URL in the format https://bitbucket.org/{workspace}/projects/{project-key}. For example, https://bitbucket.org/endor-labs/projects/lab.

   Endor Labs creates namespaces for all projects that are available in the Bitbucket Cloud workspace.

6. Enter the Bitbucket access token.

7. Select the scan types to enable in SCANNERS.

   • SCA: Perform software composition analysis and discover AI models used in your repository.
   • Secret: Scan Bitbucket projects for exposed secrets.
   • SAST: Scan Bitbucket projects to generate SAST findings.

   The available scan types depend upon your license.

8. Click Create.

9. Optionally, you can continue to Configure Bitbucket Cloud App PR scans to scan your pull requests.

   You can also choose to apply PR scans to specific projects rather than for all the projects in the workspace through a scan profile. See Scan profiles for more information.

   You can also enable PR scans later in the Bitbucket Cloud App integration.

Endor Labs Bitbucket Cloud App scans your Bitbucket projects every 24 hours and reports any new findings or changes to release versions of your code.

Use the Endor Labs Jenkins pipeline to scan all the repositories in your organization and view consolidated findings. This pipeline runs on your organization’s Jenkins infrastructure and enables administrators to run organization-level supervisory scans easily. It is designed to work in GitHub Cloud and GitHub enterprise server environments.

The Jenkins pipeline carries out the following actions.

• Pulls the Endor Labs Docker image required to perform the scan.
• Synchronizes GitHub organization repositories to a specified namespace on the Endor Labs platform.
• Retrieves the project list or the GitHub repositories for the given tenant’s namespace.
• Groups the projects into batches to optimize scan execution.
• Runs endorctl scans on each batch of projects simultaneously.

Scan the repositories in your organization

The Jenkins Pipeline script is available in the github-org-scan-docker.groovy file.

To scan the repositories in your organization:

1. Generate Endor Labs API credentials
2. Configure GitHub cloud or GitHub enterprise server credentials
3. Configure the Jenkins job

Configure GitHub credentials

Configure the required credentials needed to access GitHub and Endor Labs in the Jenkins pipeline script. You can configure these values from the Jenkins user interface.

• GITHUB_TOKEN- Enter the GitHub token that has permission to access all the repositories in the organization.
• ENDOR_LABS_API_KEY- Enter the Endor Labs API key that you generated.
• ENDOR_LABS_API_SECRET- Enter the Endor Labs API secret generated while creating the Endor Labs API key.

Configure GitHub cloud credentials

Configure the following GitHub cloud parameters in the Jenkins pipeline script.

Required Parameters for GitHub cloud

• AGENT_LABEL- This is a string parameter. Enter the label used to identify the Jenkins agents. The Jenkins job will run on the agents that have this label.
• GITHUB_ORG- This is a string parameter. Enter the organization name in GitHub.
• ENDOR_LABS_NAMESPACE- This is a string parameter. The namespace of your organization tenant in Endor Labs.

Optional Parameters for GitHub cloud

• ENDOR_LABS_API- This is a string parameter. This is only required if the tenant namespace is configured on the Endor Labs staging environment.
• ADDITIONAL_ARGS- This is a string parameter. Use this field to pass any additional parameter to the endorctl scan.
• NO_OF_THREADS- This is a string parameter. Enter the number of Jenkins agents that can be used in parallel for the endorctl scan. If you have 10 Jenkins agents configured with the given AGENT_LABEL, you can enter this value as 9, 1 agent is used for the main job. If not specified, this value defaults to 5.
• ENDORCTL_VERSION- This is a string parameter. Specify the version of the endorctl Docker container. Defaults to the latest version.
• SCAN_TYPE- This is a string parameter. Set this to git to scan commits or github to fetch info from the GitHub API. Defaults to [git, analytics].
• SCAN_SUMMARY_OUTPUT_TYPE- This is a string parameter. Use this field to set the desired output format. Supported formats: json, yaml’, table, summary. Defaults to table.
• LOG_LEVEL- This is a string parameter. Use this field to set the log level of the application. Defaults to info.
• LOG_VERBOSE- This is a string parameter. Use this field to make the log verbose.
• LANGUAGES- This is a string parameter. Use this field to set programming languages to scan. Supported languages: c#,go, java, javascript, php, python, ruby, rust, scala, typescript. Defaults to all supported languages.
• ADDITIONAL_ARGS- This is a string parameter. Use this field to pass any additional parameters to the endorctl scan.

Configure GitHub enterprise server credentials

Configure the following GitHub enterprise server parameters in the Jenkins pipeline script.

Required Parameters for GitHub enterprise server

• AGENT_LABEL - This is a string parameter. Enter the label used to identify the Jenkins agents. The Jenkins job will run on the agents that have this label.
• GITHUB_ORG - This is a string parameter. Enter the organization name in GitHub.
• ENDOR_LABS_NAMESPACE - This is a string parameter. The namespace of your organization tenant in Endor Labs.
• GITHUB_API_URL - This is a string parameter. Enter the API URL of the GitHub enterprise server. This is normally in the form of <FQDN of GitHub Enterprise Server>/api/v3. For example, https://ghe.endorlabs.in/api/v3.

Optional Parameters for GitHub enterprise server

• ENDOR_LABS_API - This is a string parameter. This is only required if the tenant namespace is configured on the Endor Labs staging environment.

• GITHUB_DISABLE_SSL_VERIFY - This is a boolean parameter. This should be used when you want to skip SSL Verification while cloning the repository.

• GITHUB_CA_CERT - This is a multi-line string parameter. This should be used to provide the content of the CA Certificate (PEM format) of the SSL Certificate used on the GitHub Enterprise Server.

• PROJECT_LIST - This is a multi-line string parameter. This should be used to provide a list of projects to scan.

• SCAN_TYPE - This is a string parameter. Set this to git to scan commits or github to fetch info from the GitHub API. Defaults to [git, analytics].

• SCAN_SUMMARY_OUTPUT_TYPE - This is a string parameter. Use this field to set the desired output format. Supported formats: json, yaml*, table, summary. Defaults to table.

• LOG_LEVEL - This is a string parameter. Use this field to set the log level of the application. Defaults to info.

• LOG_VERBOSE - This is a string parameter. Use this field to generate verbose logs.

• LANGUAGES - This is a string parameter. Use this field to set programming languages to scan. Supported languages: c#, go, java, javascript, php, python, ruby, rust, scala, typescript. Defaults to all supported languages.

• ADDITIONAL_ARGS - This is a string parameter. Use this field to pass any additional parameters to the endorctl scan.

• PROJECT_LIST - This is a multi-line string parameter. List of projects to scan. Even though all projects are synchronized, scans run only on the provided projects.

• SCAN_PROJECTS_BY_LAST_COMMIT - This is a string parameter. This parameter is used to filter projects based on the date of the last commit. Enter a number (integer) value for this parameter. The value of 0 means that projects won’t be filtered based on last commit date. Any positive integer is used to calculate the duration in which a commit will add the project for further scanning. If a project did not have a commit in that interval, it will be skipped. If a proper SSL Certificate (a certificate issued by a well-known CA) is not used for GitHub Enterprise, the sync-org command fails and Endor Labs cannot fetch the projects or repositories to scan from the GitHub enterprise server. You can use this field to provide the list of projects or repositories to scan one per line. For example:

          https://github-test.endorlabs.in/pse/vuln_rust_callgraph.git
          https://github-test.endorlabs.in/pse/vulnerable-golang.git
          https://github-test.endorlabs.in/pse/java-javascript-vulnerable-repo.git
          https://github-test.endorlabs.in/pse/multi-lang-repo.git
  

• EXCLUDE_PROJECTS - This is a multi-line string parameter. Use this parameter to list projects or repositories to exclude from the scan.

• NO_OF_THREADS - This is a string parameter. Enter the number of Jenkins agents that can be used in parallel for the endorctl scan. If you have 10 Jenkins agents configured with the given AGENT_LABEL, you can enter this value as 9. If not specified, this value defaults to 5.

Configure the Jenkins job

Use the following procedure to configure the Jenkins pipeline and scan the repositories in your organization.

1. Sign in to Jenkins
2. Configure an Endor Labs API Key and GitHub credentials correctly for your environment.
3. Click + New Item, to create a new Jenkins job.
4. Enter the name of the new pipeline
5. Select Pipeline and click OK.
6. Select This project is parameterised and add the parameters based on your requirements.
7. From the Pipeline section, for Definition, select Pipeline script from SCM
8. For SCM select Git
9. For the Repository URL, enter either git@github.com:endorlabs/jenkins-org-scan.git or https://github.com/endorlabs/jenkins-org-scan.git.
10. For Credentials, enter the credentials required for cloning the repository entered in the previous step.
11. In Branches to build, enter */main.
12. For Script Path, enter github-org-scan-docker.groovy.
13. Select Lightweight checkout.
14. Click Save.

The Jenkins pipeline is highly customizable and adaptable to various GitHub environments and scanning requirements. It streamlines the process of running endorctl scans on your repositories efficiently.

Endor Labs monitoring scan regularly scans your source code to discover vulnerabilities. The Endor Labs Apps clone and analyze all repositories every 24 hours, ensuring continuous monitoring for open source vulnerabilities and code weaknesses. See Monitoring scans for more information.

Endor Labs uses a Kubernetes cluster where your source code repositories and cloned, and the scans are conducted. Your policies may require that the source code repositories are not exposed to the public cloud. In such situations, you can use Outpost, which is a deployable on-prem instance of the Endor Labs scheduler that runs on your private Kubernetes cluster. After you deploy Outpost, Endor Labs uses your Kubernetes cluster to run the monitoring scans.

The scheduling of the scans and the scans themselves are run within your firewall. After the scans are completed, only the scan results are sent to Endor Labs.

Outpost provides full feature parity with regular cloud-based Endor Labs scans.

The following diagram shows how monitoring scans work when you configure Outpost.

graph TD
    A(["Endor Labs App"]) -->|<span style='font-size: 12px'>Continuous monitoring</span>| B["Source Code Repositories"]
    B <--> F["Private Artifact Registry"]
    A -->|<span style='font-size: 12px'>Initiates scans</span>| C["Private Kubernetes cluster
    <span style='font-size: 12px'>Runs Outpost and the scans inside your firewall</span>"]
    B -->|<span style='font-size: 12px'>Clones repositories</span>| C
    C -->|<span style='font-size: 12px'>Pass scan data</span>| D(["Endor Labs Platform
    <span style='font-size: 12px'>Generate findings from scan results</span>"])

    subgraph E["Firewall"]
    A
    B
    C
    F
    end

    class A,D endor
    class B,C,F customer
    class E firewall
    classDef customer fill:#5EEAD4
    classDef firewall fill:transparent,stroke-dasharray: 5 5,stroke:#FF4500,color:#FF4500

Outpost helps you in the following instances:

• Security and compliance requirements prevent you from exposing source code repositories to external services
• Firewall restrictions that prevent direct integration with external scan services and requires complex VPN configurations
• Integrating endorctl into multiple CI/CD pipelines can be complex and costly, and relying on manual scanning processes increases the risk of errors
• Need to scan against private artifact registries and internal services

You need to configure Outpost as an integration at your Endor Labs tenant namespace. You can only configure Outpost as an integration at your root namespace. After you configure the integration and complete the Kubernetes cluster configuration, all the monitoring scans in your Endor Labs tenant are run on your Kubernetes cluster.

The following sections describe how you can configure and deploy Outpost.

• Outpost requirements
• Outpost authentication
• Outpost configuration

You need a Kubernetes cluster with nodes that have at least 8 cores and 32 GB of RAM. Nodes should be running Linux.

You must create a namespace in your Kubernetes cluster to deploy Outpost. Use this namespace when you configure Outpost integration in Endor Labs.

Outpost currently supports the following Kubernetes distributions:

• Azure Kubernetes Service (AKS)
• Google Kubernetes Engine (GKE)
• Amazon Elastic Kubernetes Service (EKS)
• Self-hosted Kubernetes clusters

Kubernetes cluster requirements for Outpost

The total number of nodes in the cluster depends on the number of projects that you want to scan and the number of scans that you want to run in a day.

The total scans per node per day (24 hours) is calculated based on the following formula.

Total scans per node per day = (Node memory ÷ Pod memory request - 1) × (24 ÷ Average scan duration)

Pod memory request is the memory required for running endorctl. The Outpost scheduler sets the pod memory requests. Typically, the pod memory request is 8 GB. For demanding ecosystems with call graph enabled, the Outpost scheduler sets the pod memory request to 16 GB.

You can use the following formula to calculate the number of nodes required.

Number of nodes = Total projects ÷ Total scans per node per day

The following table shows the number of nodes required for different combinations of projects and scans.

Storage requirements for Outpost

Storage requirements for Outpost depend on the number of projects that you want to scan and the size of the repositories. Storage requirements increase in direct proportion to the number of concurrent scans.

You can use the following formula to calculate the storage requirements if you are running N number of concurrent scans.

Storage requirements = Sum of the largest N project sizes + extra space for other files

For example:

• Project sizes: 10 GB, 8 GB, 6 GB, 4 GB, 2 GB
• Concurrent scans: 3
• Storage calculation: 10 GB + 8 GB + 6 GB + extra space
• Total storage required: 24 GB + extra space for other files

We recommend that you allocate 500 GB of storage if you have several large projects and want to run several concurrent scans.

Network requirements for Outpost

Ensure the following network requirements are met for Outpost:

• Egress Access: Required. Allow outbound traffic to Endor Labs platform, toolchains, and package managers.
• DNS Resolution: Required. Allow list of necessary domains.
• Network Policies: Required. Allow outbound traffic to Endor Labs platform, toolchains, and package managers.

Outpost can use the following authentication mechanisms:

• API Key: You can generate an Endor Labs API key and secret and configure Outpost to use it.
• Azure Managed Identity: You can configure Outpost to use an Azure managed identity for authentication. Applicable if you use Azure Kubernetes Service (AKS). You must also configure a corresponding authorization policy in Endor Labs.
• GCP Service Account: You can configure Outpost to use a GCP service account for authentication. Applicable if you use Google Kubernetes Engine (GKE). You must also configure a corresponding authorization policy in Endor Labs.

API key authentication for Outpost

You can create an Endor Labs API key and secret to authenticate your Outpost configuration. See API keys for more information.

Ensure that you select On-prem Scheduler as the API key permissions.

Azure Managed Identity authentication for Outpost

Perform the following steps to configure Outpost to use an Azure managed identity for authentication.

1. Enable workload identity in the AKS cluster.

2. Enable OIDC provider in the AKS cluster.

3. Create an Azure managed identity.

   az identity create -g endor-group -n endor-identity
   

   The command creates a zero-permission managed identity. Store the clientId for later use.

4. Run the following command to retrieve the OIDC Issuer from AKS.

   OIDC_ISSUER=$(az aks show -g endor-group -n onprem-cluster --query "oidcIssuerProfile.issuerUrl" -o tsv)
   

   The command fetches the OIDC issuer URL for federated authentication. Ensure that you enable OIDC and Workload Identity in the AKS cluster.

5. Create federated credentials for workloads.

   Run the following command to create the scheduler federated credential.

   az identity federated-credential create \
    --name scheduler-federated-identity \
    --identity-name endor-identity \
    --resource-group endor-group \
    --issuer $OIDC_ISSUER \
    --subject system:serviceaccount:onprem-cluster:onprem-scheduler-account
   

   Run the following command to create the endorctl federated credential.

   az identity federated-credential create \
    --name endorctl-federated-identity \
    --identity-name endor-identity \
    --resource-group endor-group \
    --issuer $OIDC_ISSUER \
    --subject system:serviceaccount:onprem-cluster:onprem-scheduler-endorctl-account
   

The commands link the managed identity to Kubernetes service accounts and enable secure access without static credentials. 6. Configure an authorization policy in Endor Labs with configuration from Azure. 7. Configure the Outpost integration with Managed Identity Client ID.

See Outpost configuration for more information on how to configure the Outpost integration.

GCP Service Account authentication for Outpost

Perform the following steps to configure Outpost to use a GCP service account for authentication.

1. Enable workload identity in the GKE cluster.

2. Enable OIDC provider in the GKE cluster.

3. Create a new workload service account.

   gcloud iam service-accounts create endor-compute \
     --description="Endor Labs Compute Service Account" \
     --display-name="Endor Labs Compute Service Account"
   

4. Grant roles/iam.serviceAccountOpenIdTokenCreator to workload service account.

   gcloud projects add-iam-policy-binding endor-experiments \
    --member "serviceAccount:endor-compute@endor-experiments.iam.gserviceaccount.com" \
    --role "roles/iam.serviceAccountOpenIdTokenCreator"
   

5. Create a zero-permission service account for Endor Labs to perform federation.

   gcloud iam service-accounts create endor-federation \
    --description="Endor Labs Keyless Federation Service Account" \
    --display-name="Endor Labs Federation Service Account"
   

6. Allow the Kubernetes service accounts to impersonate the IAM workload service account.

   gcloud iam service-accounts add-iam-policy-binding endor-compute@endor-experiments.iam.gserviceaccount.com \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:endor-experiments.svc.id.goog[onprem-scheduler/onprem-scheduler-account]"
   

   gcloud iam service-accounts add-iam-policy-binding endor-compute@endor-experiments.iam.gserviceaccount.com \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:endor-experiments.svc.id.goog[onprem-scheduler/onprem-scheduler-endorctl-account]"
   

7. Configure an authorization policy in Endor Labs with configuration from Google Cloud.

8. Configure the Outpost integration with Service Account Name.

   See Outpost configuration for more information on how to configure the Outpost integration.

After you set up your Kubernetes cluster and set up authentication, you can configure the Outpost integration.

Configure Outpost integration

To set up Outpost in your environment, you need to configure the integration through the Endor Labs user interface and deploy it to your Kubernetes cluster.

Perform the following steps to configure Outpost:

1. Select Integrations from the left sidebar.

2. Click Configure under On-Prem Integration.

   

3. Choose from the following authentication methods:

   • API: Use the Endor Labs API key authentication for Outpost. You need to enter the API key and API secret. See API key authentication for Outpost for more information.
   • Azure: Use the Azure managed identity authentication for Outpost. You need to enter the Azure managed identity client ID. See Azure Managed Identity authentication for Outpost for more information.
   • Google: Use the GCP service account authentication for Outpost. You need to enter the GCP service account name. See GCP Service Account authentication for Outpost for more information.

4. Click Advanced to configure the following parameters:

   • Select Enable Build Tool Caching to enable build tool caching. Bazel remote cache is installed and the build tools are cached in the cluster.
   • Enter the number of concurrent scans that Outpost can run in Max Running Scans.
   • Enter the maximum duration of a scan in Max Duration.

5. Click Enable Scheduler to store the configuration and enable Outpost.

6. Click Download Helm Values to download the endor-outpost-values.yaml file.

   You can choose to customize the values before you deploy Outpost.

   You can also extract the chart from oci://endorcipublic.azurecr.io/charts/onprem-scheduler and refer the default values.yaml for all the available options. See Helm Chart Values for more information.

7. Run the following command to deploy Outpost in your Kubernetes cluster.

   helm install endorlabsscheduler oci://endorcipublic.azurecr.io/charts/onprem-scheduler \
   -n <your Kubernetes namespace> \
   -f endor-outpost-values.yaml
   

   The command installs the Outpost scheduler on your Kubernetes cluster.

scheduler:
 .
 .
  serviceAccount:
    create: true
    annotations:
      iam.gke.io/gcp-service-account: "endor-scanner-sa@project-name-123456.iam.gserviceaccount.com"
endorctl:
 .
 .
  serviceAccount:
    create: true
    annotations:
      iam.gke.io/gcp-service-account: "endor-scanner-sa@project-name-123456.iam.gserviceaccount.com"

--set scheduler.serviceAccount.annotations.iam.gke.io/gcp-service-account="<GCP_SERVICE_ACCOUNT_NAME>@<GCP_PROJECT_NAME>.iam.gserviceaccount.com"
--set endorctl.serviceAccount.annotations.iam.gke.io/gcp-service-account="<GCP_SERVICE_ACCOUNT_NAME>@<GCP_PROJECT_NAME>.iam.gserviceaccount.com"

helm install endorlabsscheduler oci://endorcipublic.azurecr.io/charts/onprem-scheduler \
    -n <k8s-ns> \
    --set endorAPI=https://api.staging.endorlabs.com \
    --set endorNamespace=nryn \
    --set auth.gcpServiceAccountName=endor-scanner-sa@project-name-123456.iam.gserviceaccount.com \
    --set scheduler.serviceAccount.annotations.iam.gke.io/gcp-service-account="endor-scanner-sa@project-name-123456.iam.gserviceaccount.com" \
    --set endorctl.serviceAccount.annotations.iam.gke.io/gcp-service-account="endor-scanner-sa@project-name-123456.iam.gserviceaccount.com" \
    --set bazelremote.install=false

8. If you do not want to customize the values, the Helm command with your configured values appears in the user interface. You can copy the command and run it on your Kubernetes cluster.

   For example, the following command appears on the user interface when you configure the integration on the endor Kubernetes namespace with the Azure managed identity authentication and build tool caching enabled. The root Endor Labs namespace is endor.

   helm install endorlabsscheduler oci://endorcipublic.azurecr.io/charts/onprem-scheduler \
        -n endor \
        --set endorAPI=https://api.endorlabs.com \
        --set endorNamespace=endor \
        --set auth.azureManagedIdentityClientID=12a34b56-7c89-0d1e-2f34-567g890h1234 \
        --set bazelremote.install=true
   

   You can copy the command and run it on your Kubernetes cluster to deploy Outpost.

Update Outpost configuration

To update the Outpost configuration, you need to uninstall the existing Helm chart and install a new one with the updated values.

Run the following command to uninstall the existing Helm chart.

helm uninstall endorlabsscheduler -n <your namespace>

You can update the configuration in the user interface to generate a new Helm chart or command, or you can manually update the values in the endor-outpost-values.yaml file. We recommend that you update the configuration in the user interface even if you manually update and install the Helm chart.

Perform the following steps to update the configuration in the user interface:

1. Select Integrations from the left sidebar.
2. Click Manage under On-Prem Integration.
3. Update the configuration and click Enable Scheduler to update the configuration.
4. Apply the updated values with the helm install command as described in Configure Outpost integration.

Generally, you need to update the configuration when the authentication expires. API keys have a maximum validity period of one year. The expiry of Azure managed identity and GCP service accounts depends on the expiry of the corresponding authorization policy.

View Outpost logs

You can view the Outpost logs in the Endor Labs platform.

Perform the following steps to view the Outpost logs:

1. Select Integrations from the left sidebar.

2. Click View Logs under On-Prem Integration.

   

   You can copy the logs to the clipboard or download the logs.

   By default, the logs are brief logs are displayed. You can select Show Verbose Logs to view the detailed logs.

   The log level is set as All by default. You can select Info to view the info logs and Debug to view the debug logs.

Helm Chart Values

Run the following command to extract the default values for the Outpost Helm chart.

helm pull oci://endorcipublic.azurecr.io/charts/onprem-scheduler --untar

The values.yaml file in the onprem-scheduler directory contains the default values for the Outpost Helm chart.

The following yaml file shows the default values in the values.yaml file.

# Default values for onprem-scheduler.
# This file is YAML-formatted.

# Base URL for the Endor Labs platform [Do not modify]
endorAPI: "https://api.endorlabs.com"

# Your organization's namespace in Endor Labs [Do not modify unless there is a change in your tenant]
endorNamespace: "required"

# Log level for scheduler and endorctl. Optional.
logLevel: "info"

# Log output format for scheduler. Optional.
logOutput: "json"

# Authentication configuration - use ONE of the following methods.
# NOTE: Only one authentication method (apiKey & apiSecret, gcpServiceAccountName,
# or azureManagedIdentityClientID) must be set.
auth:
  # Option 1: API Key authentication. Enter the Endor Labs API key and secret.
  # You can also create Kubernetes secrets for the API key and secret and provide the secret names instead of directly entering the values.
  apiKey: ""
  apiSecret: ""

  # Option 2: GCP Service Account authentication. Enter the GCP service account name.
  # NOTE: Ensure service accounts are created with workload identity annotations.
  gcpServiceAccountName: ""

  # Option 3: Azure Managed Identity authentication. Enter the Azure managed identity client ID.
  # NOTE: Ensure service accounts are created with workload identity annotations.
  azureManagedIdentityClientID: ""

scheduler:
  # Maximum number of scans that you want to run concurrently. Optional.
  maxRunningJobs: 20

  # Scheduler container image settings.
  image:
    # Container repository for the scheduler image [Do not modify]
    repository: "endorcipublic.azurecr.io/scheduler"

    # Image version to use [Do not modify]
    tag: "latest"

    # Image pull policy [Do not modify]
    pullPolicy: "Always"

  # Labels for the scheduler deployment. Optional.
  labels: {}

  # Annotations for the scheduler deployment. Optional.
  annotations: {}

  # Labels for the scheduler pod. Optional.
  podLabels: {}

  # Annotations for the scheduler pod. Optional.
  podAnnotations: {}

  serviceAccount:
    # Specifies whether a service account should be created. Optional.
    create: false

    # Name of the service account to use for scheduler. Optional.
    name: ""

    # Labels for the scheduler service account. Optional.
    labels: {}

    # Annotations for the scheduler service account. Optional.
    annotations: {}

  # Pod-level security context for the scheduler. Optional.
  podSecurityContext: {}

  # Container-level security context for the scheduler. Optional.
  securityContext: {}

  # Resource constraints for the scheduler pod. Optional.
  resources:
    requests:
      cpu: 512m
      memory: 512Mi

  healthProbes:
    # Port used to perform health checks. Optional.
    port: 8080

    # Readiness probe for the scheduler pod. Optional.
    readinessProbe:
      enabled: true
      failureThreshold: 2
      successThreshold: 1
      periodSeconds: 5
      timeoutSeconds: 1
      initialDelaySeconds: 10

    # Liveness probe for the scheduler pod. Optional.
    livenessProbe:
      enabled: true
      failureThreshold: 4
      periodSeconds: 10
      successThreshold: 1
      timeoutSeconds: 1
      initialDelaySeconds: 0

  # Node selector for the scheduler pod. Optional.
  nodeSelector: {}

  # Tolerations for the scheduler pod. Optional.
  tolerations: []

  # Affinity settings for the scheduler pod. Optional.
  affinity: {}

  # Volumes for the scheduler pod. Optional.
  volumes: []

  # Volume mounts for the scheduler pod. Optional.
  volumeMounts: []

  # Additional environment variables for the scheduler pod. Optional.
  additionalEnvs: []

endorctl:
  # Maximum runtime duration in minutes for a scan. Optional. Default value is 60.
  maxDuration: 1440

  bazelRemote:
    # Bazel remote cache service name.
    # Refer bazelremote values below. Optional.
    serviceName: "bazel-remote-cache"

    # Bazel remote cache GRPC service port.
    # Refer bazelremote values below. Optional.
    servicePort: 9092

  # Endorctl container image settings.
  image:
    # Container repository for the endorctl image [Do not modify]
    repository: "endorcipublic.azurecr.io/endorctl_bare"

    # Image version to use [Do not modify]
    tag: "latest"

    # Image pull policy [Do not modify]
    pullPolicy: "Always"

  # Labels for the endorctl job. Optional.
  labels: {}

  # Annotations for the endorctl job. Optional.
  annotations: {}

  # Labels for the endorctl pod. Optional.
  podLabels: {}

  # Annotations for the endorctl pod. Optional.
  podAnnotations: {}

  serviceAccount:
    # Specifies whether a service account should be created. Optional.
    create: false

    # Name of the service account to use for endorctl. Optional.
    name: ""

    # Labels for the endorctl service account. Optional.
    labels: {}

    # Annotations for the endorctl service account. Optional.
    annotations: {}

  # Pod-level security context for the endorctl. Optional.
  podSecurityContext: {}

  # Container-level security context for the endorctl. Optional.
  securityContext: {}

  # Resource constraints for the endorctl job. Optional.
  resources: {}

  # Node selector for the endorctl pod. Optional.
  nodeSelector: {}

  # Tolerations for the endorctl pod. Optional.
  tolerations: []

  # Affinity settings for the endorctl pod. Optional.
  affinity: {}

  # Volumes for the endorctl pod. Optional.
  volumes: []

  # Volume mounts for the endorctl pod. Optional.
  volumeMounts: []

  # Backoff limit for the endorctl job. Optional.
  backoffLimit: 0

  # TTL seconds after finished for the endorctl job. Optional.
  ttlSecondsAfterFinished: 100

  # Additional environment variables for the endorctl pod. Optional.
  additionalEnvs: []

#
# DEPENDENCIES
#

# Bazel remote cache configuration. Optional. Not enabled by default.
bazelremote:
  # Whether to install the Bazel remote cache component
  install: false

  image:
    # Container repository for the Bazel remote cache image [Do not modify]
    repository: "buchgr/bazel-remote-cache"

    # Specific version of the Bazel remote cache to use [Do not modify]
    tag: "v2.4.1"

    # Image pull policy [Do not modify]
    pullPolicy: "IfNotPresent"

  # Full name of the chart. Optional.
  fullnameOverride: "bazel-remote-cache"

  # Bazel-remote config to provision inside of the container. Optional.
  conf: |-
    # https://github.com/buchgr/bazel-remote#example-configuration-file
    dir: /data
    max_size: 500
    experimental_remote_asset_api: true
    access_log_level: all
    port: 8080
    grpc_port: 9092

  ## For advanced bazel-remote configuration options,
  ## Refer https://github.com/slamdev/helm-charts/tree/master/charts/bazel-remote#readme

Post-deployment configuration

After deploying Outpost to your Kubernetes cluster, you need to set up the appropriate Endor Labs app to integrate with your source code management system. This integration enables Outpost to scan your repositories.

You can install Endor Labs apps for the following source code managers:

• GitHub Cloud
• GitHub Enterprise
• GitLab Cloud and self-hosted
• Bitbucket Data Center
• Bitbucket Cloud
• Azure DevOps Cloud

Configure Outpost on GitLab self-hosted with self-signed certificates

When you configure Outpost on GitLab self-hosted with self-signed certificates, you need to add the self-signed certificate to the Outpost Helm chart values.

Perform the following steps to add the self-signed certificate to the Outpost Helm chart values and deploy Outpost with GitLab self-hosted.

1. Download the self-signed certificate from the GitLab self-hosted instance.

2. Create a kubectl configmap using the certificate in the Outpost cluster.

   kubectl create configmap gitlab-cert --from-file=<cert-name>=<path-of-the-certificate> -n <name-of-the-namespace>
   

   For example:

   kubectl create configmap gitlab-cert --from-file=gitlab-dev-CA.pem=/Users/doe/Downloads/gitlab-dev-CA.pem -n onprem-scheduler
   

3. Configure Outpost and download endor-outpost-values.yaml file.

4. Modify the values yaml file to volume mount the certificate in the scheduler and endorctl image.

   endorAPI: "https://api.endorlabs.com"
   endorNamespace: "<Endor Labs namespace>"
   auth:
     apiKey: "<apiKey>"
     apiSecret: "<apiSecret>"
   scheduler:
     image:
       repository: "endorcipublic.azurecr.io/scheduler"
       tag: "latest"
       pullPolicy: "Always"
     volumes:
       - name: gitlab-cert
         configMap:
           name: gitlab-cert
     volumeMounts:
       - name: gitlab-cert
         mountPath: /etc/ssl/certs/gitlab-dev-CA.pem
         subPath: gitlab-dev-CA.pem
   endorctl:
     image:
       repository: "endorcipublic.azurecr.io/endorctl_bare"
       tag: "latest"
       pullPolicy: "Always"
     volumes:
       - name: gitlab-cert
         configMap:
           name: gitlab-cert
     volumeMounts:
       - name: gitlab-cert
         mountPath: /etc/ssl/certs/gitlab-dev-CA.pem
         subPath: gitlab-dev-CA.pem
   

5. Run the following command to deploy Outpost in your Kubernetes cluster.

   helm install endorlabsscheduler oci://endorcipublic.azurecr.io/charts/onprem-scheduler \
   -n <your Kubernetes namespace> \
   -f endor-outpost-values.yaml
   

6. Install the GitLab App.

Configure Outpost on GitHub Enterprise Server with self-signed certificates

When you configure Outpost on GitHub Enterprise Server with self-signed certificates, you need to add the self-signed certificate to the Outpost Helm chart values.

Perform the following steps to add the self-signed certificate to the Outpost Helm chart values and deploy Outpost with GitHub Enterprise Server.

1. Download the self-signed certificate from the GitHub Enterprise Server instance.

2. Check if a ConfigMap for the GitHub certificate already exists.

   kubectl -n <namespace> get configmap github-cert -o yaml
   

3. If a previous certificate exists, delete it before creating a new one.

   kubectl -n <namespace> delete configmap github-cert
   

4. Create a new ConfigMap with the certificate in the Outpost cluster.

   kubectl create configmap github-cert --from-file=github-CA.pem=<path-of-the-certificate> -n <namespace>
   

   For example:

   kubectl create configmap github-cert --from-file=github-CA.pem=/Users/doe/Downloads/github-CA.pem -n onprem-scheduler
   

5. Verify that the ConfigMap has been created:

   kubectl -n <namespace> get configmap github-cert -o yaml
   

6. Modify the values yaml file to volume mount the certificate in the scheduler and endorctl image. Mount your cert file under /etc/ssl/certs directory.

   endorAPI: "https://api.endorlabs.com"
   endorNamespace: "<Endor Labs namespace>"
   auth:
     apiKey: "<apiKey>"
     apiSecret: "<apiSecret>"
   scheduler:
     image:
       repository: "endorcipublic.azurecr.io/scheduler"
       tag: "latest"
       pullPolicy: "Always"
     volumes:
       - name: github-cert
         configMap:
           name: github-cert
     volumeMounts:
       - name: github-cert
         mountPath: /etc/ssl/certs/github-CA.pem
         subPath: github-CA.pem
   endorctl:
     image:
       repository: "endorcipublic.azurecr.io/endorctl_bare"
       tag: "latest"
       pullPolicy: "Always"
     volumes:
       - name: github-cert
         configMap:
           name: github-cert
     volumeMounts:
       - name: github-cert
         mountPath: /etc/ssl/certs/github-CA.pem
         subPath: github-CA.pem
    additionalEnvs:
      - name: "GITHUB_USE_APP_TRANSPORT"
        value: "true"
   

7. Install Helm for outpost configuration.

   helm install endorlabsscheduler oci://endorcipublic.azurecr.io/charts/onprem-scheduler \
   -n <namespace> \
   -f endor-outpost-values.yaml
   

8. Verify certificate in Pod and Confirm that the certificate is correctly mounted in the pods:

   kubectl -n onpremschedulertest describe pod $POD | grep -A3 github-cert
   

9. Install the GitHub Enterprise Server App.

Endor Labs helps developers fix code at its origin phase and during the early stages of development. You can successfully perform early security reviews and mitigate the need for expensive fixes during later stages of development. It accelerates the process of creating, delivering, and shipping secure applications.

• Endor Labs Visual Studio Code extension: Endor Labs provides a plug-in for Visual Studio Code that developers can install from Visual Studio’s marketplace and get started with early vulnerability and dependency scanning.
• Endor Labs MCP server: Endor Labs MCP (Model Context Protocol) server enables secure deployment of Endor Labs capabilities within your IDE. You can run the Endor Labs MCP server in your IDE during the development process to ensure that your code is free from vulnerabilities.

The Endor Labs extension for Visual Studio Code scans your repositories and highlights issues that may exist in the open-source dependencies. You can use the extension with Endor Labs API credentials.

Prerequisites

The following prerequisites must be fulfilled to use the Endor Labs VS Code extension:

• The minimum supported version of Visual Studio Code is 1.71 and higher.
• See the following table for supported languages, package managers, and file extensions. The extension reads the manifest files to fetch the list of dependencies and displays the results in both manifest and source code files.

• Generate Endor Labs API keys and have them handy. You must enter these details in the VS Code extension. See Managing API keys for details.

Install the Endor Labs extension

Developers can install the extension from the Visual Studio marketplace and configure it with Endor Labs API keys.

1. Launch Visual Studio Code and click Extensions.
2. Look for the Endor Labs using the search bar and click Install. See Visual Studio Extension documentation for details on managing the extension.
3. Select the Endor Labs extension, click Settings, and choose Extension Settings.
4. Enter the API Key and API Secret of the Endor Labs application.

View scan results

The Endor Labs Visual Studio extension reads all the manifest files in your project and fetches the list of dependencies.

• Hover over a dependency to view the package version, released date, findings, and Endor Labs scores in a pop-up.
• For effective prioritization, issues with dependencies are classified into four severity levels: Critical, High, Medium, and Low.
• Click a specific version to view the same results in the Endor Labs user interface.
• The dependencies are color-coded in the following ways:
  • Red underline - Has critical findings and is also on an outdated version
  • Orange underline - Has critical findings and is on the latest version
  • Yellow underline - Has no critical findings but is an outdated version
  • No Underline - Has no critical findings and is on the latest version
• Use Update to latest version to update the package to its latest version.

MCP (Model Context Protocol) is an open standard that defines a consistent way for applications to share relevant context and information with Large Language Models (LLMs). MCP servers expose specific capabilities through the standardized Model Context Protocol. For more information on MCP, refer to the MCP documentation.

The Endor Labs MCP server integrates seamlessly into your development workflow, scanning your code as you write. You can catch issues long before they’re a problem in production. It plugs directly into your IDE, tightening the feedback loop for both human and AI-generated code. Thus, you can quickly secure your code from the start. With Endor Labs, you’re bringing security all the way left, getting real-time, proactive insights and automated fixes in your editor, while you build, minimizing last-minute security scrambles.

How Endor Labs MCP server helps your development workflow

How to use the Endor Labs MCP server

Choose your IDE or platform to get started

The Endor Labs MCP server integrates directly into Cursor to scan your code as you write, catching security issues before they reach production.

The following sections walk you through setting up the Endor Labs MCP server:

• Prerequisites for Endor Labs MCP server
• One-click installation
• Tools in the Endor Labs MCP server
• Choose your edition
• Developer Edition
• Enterprise Edition
• Manage MCP server tools
• Configure Cursor rules
• Troubleshooting

Prerequisites for Endor Labs MCP server

Ensure that the following prerequisites are met:

• Cursor
• Node.js version 18 or later (required if you don’t have endorctl installed)
• Windows users: See Prerequisites for Endor Labs MCP server on Windows for additional instructions

One-click installation

Select your edition, fill in any required fields, and click Install in Cursor to add the Endor Labs MCP server directly to Cursor.

Tools in the Endor Labs MCP server

Choose your edition

The Endor Labs MCP server has two editions:

• Developer Edition: A free edition that requires no configuration. A browser window opens on first use for authentication via GitHub, GitLab, or Google. The Developer Edition provides access to default security policies from Endor Labs.
• Enterprise Edition: A paid edition that enforces your organization’s specific security policies. Authenticate using GitHub, GitLab, Google, or SSO. You must specify your namespace to access your organization’s policies.

Additionally, if you already have Endor Labs configured locally (for example, from a previous endorctl init command), the MCP server can use your pre-existing configuration.

Developer Edition

You can use the one-click installation tool above or set up the MCP server manually.

Developer Edition: Set up manually

If you prefer to configure the MCP server manually, add the configuration to a .cursor/mcp.json file in the root of your repository (not your home directory).

1. Navigate to the root of your repository.

2. Create a .cursor directory if it doesn’t exist and create an mcp.json file in the .cursor directory.

   mkdir -p .cursor && touch .cursor/mcp.json
   

3. Add the following configuration to the .cursor/mcp.json file.

   {
     "mcpServers": {
       "endor-cli-tools": {
         "command": "npx",
         "args": [
           "-y",
           "endorctl",
           "ai-tools",
           "mcp-server"
         ]
       }
     }
   }
   

Developer Edition: Verify the installation

1. Navigate to Settings > Cursor Settings > Tools & MCP.

2. Confirm that endor-cli-tools appears in the list and is enabled.

Try a test prompt

After installing the MCP server, try the following prompt in your AI chat or CLI to verify that the tools are working.

Check if the npm package lodash version 4.17.20 has any vulnerabilities

The MCP server uses the check_dependency_for_vulnerabilities tool to check for known vulnerabilities and return the results. If you see a response with vulnerability details, the MCP server is working correctly.

Enterprise Edition

For Enterprise Edition, you need your organization’s Endor Labs namespace and an authentication method. Ensure that your developers have Read-Only permissions to Endor Labs. See Authorization policies for more details.

You can use the one-click installation tool above or set up the MCP server manually.

Enterprise Edition: Set up manually

Add the following configuration to a .cursor/mcp.json file in the root of your repository.

{
  "mcpServers": {
    "endor-cli-tools": {
      "command": "npx",
      "args": [
        "-y",
        "endorctl",
        "ai-tools",
        "mcp-server"
      ],
      "env": {
        "ENDOR_NAMESPACE": "<namespace>",
        "ENDOR_MCP_SERVER_AUTH_MODE": "<google|github|gitlab|sso>",
        "ENDOR_TOKEN": "automatic"
      }
    }
  }
}

Replace <namespace> with your Endor Labs namespace and choose your authentication mode. If you choose sso, you must also add ENDOR_MCP_SERVER_AUTH_TENANT to the env section.

Enterprise Edition: Verify the installation

1. Navigate to Settings > Cursor Settings > Tools & MCP.

2. Confirm that endor-cli-tools appears in the list and is enabled.

Try a test prompt

After installing the MCP server, try the following prompt in your AI chat or CLI to verify that the tools are working.

Check if the npm package lodash version 4.17.20 has any vulnerabilities

The MCP server uses the check_dependency_for_vulnerabilities tool to check for known vulnerabilities and return the results. If you see a response with vulnerability details, the MCP server is working correctly.

Manage MCP server tools

1. Navigate to Settings > Cursor Settings > Tools & MCP.

2. Click the tool that you want to disable under endor-cli-tools.

   Click on a disabled tool to enable it.

Configure Cursor rules

To enhance the MCP server integration, you can add custom rules for your project. These rules are custom prompts specific to your project.

1. Navigate to the root of your repository.

2. In the .cursor/rules directory, create an .mdc file to add specific instructions.

3. Add appropriate rules for your project in the .cursor/rules/endorlabs.mdc file. For example, you can add a rule to check if the code is free from vulnerabilities.

Example Cursor rules

You can use the following Cursor rules as a quick start for the Endor Labs MCP server. Modify the rules to meet your specific organization’s needs. We recommend that you store each cursor rule in a separate file. For more information, refer to the Cursor documentation.

• SCA Rule Example
• Secrets Rule Example
• SAST Rule Example

---
description: "Ensure newly added dependencies are checked for vulnerabilities and project stays clean"
globs: '**/package.json, **/package-lock.json, **/yarn.lock, **/pnpm-lock.yaml, **/requirements.txt, **/Pipfile, **/Pipfile.lock, **/pyproject.toml, **/poetry.lock, **/go.mod, **/go.sum, **/Cargo.toml, **/Cargo.lock, **/pom.xml, **/build.gradle, **/build.gradle.kts, **/gradle.lockfile, **/composer.json, **/composer.lock'
alwaysApply: true
---

# Software Composition Analysis (SCA) Rule (Endor Labs via MCP)
This project uses Endor Labs for automated dependency (SCA) scanning, integrated through the MCP server as configured in `.cursor/mcp.json`.

## Workflow

Every time a manifest or lockfile listed above is created or modified in any way immediately do the following prior to performing your next task.

**Important**: Do not proceed after creating or modifying a manifest file without running this first. Do not write any other code or continue with your existing prompt. This is top priority whenever a manifest file is created or updated.

- Run `endor-cli-tools` using the `check_dependency_for_vulnerabilities` tool via the MCP server.
- Provide the **ecosystem**, **dependency name**, and **version** always when making this tool call. Do not forget to provide a version.
- If a vulnerability or error is identified:
  - Upgrade to the suggested safe version, or
  - Replace the dependency with a non-vulnerable alternative.
  - The AI agent must attempt to automatically correct all detected errors and vulnerabilities before session completion.
- Re-run the check using `endor-cli-tools` to confirm the issue is resolved.
- If an error occurs in any MCP server tool call (such as missing required parameters like version, invalid arguments, or tool invocation failures):
  - The AI agent must review the error, determine the cause, and automatically correct the tool call or input parameters.
  - Re-attempt the tool call with the corrected parameters.
  - Continue this process until the tool call succeeds or it is determined that remediation is not possible, in which case the issue and reason must be reported.

## Notes
- All scans must be performed using the MCP server integration (`endor-cli-tools`) as configured in `.cursor/mcp.json`. Do not invoke `endorctl` directly.
- For troubleshooting, ensure the MCP server is running and `endorctl` is installed and accessible in your environment.

This rule ensures that all dependency changes are evaluated for risk at the time of introduction, and that the project remains clean and secure after each coding session. The scan may be performed at the end of an agent session, provided all modifications are checked and remediated before session completion.

---
description: "Scan for leaked secrets on file modification"
globs: '**/*'
alwaysApply: true
---

# Leaked Secrets Detection Rule (Endor Labs via MCP)
This project uses @Endor Labs for automated security scanning, integrated through the MCP server as configured in `.cursor/mcp.json`.

## Workflow
Whenever a file is modified in the repository, and before the end of an agent session:
- Run `endor-cli-tools` using the `scan` tool via the MCP server to check for leaked secrets.
- Ensure the scan includes all file types and respects `.gitignore` unless otherwise configured.
- If any secrets or errors are detected:
  - Remove the exposed secret or correct the error immediately.
  - The AI agent must attempt to automatically correct all detected secrets and errors before session completion.
  - Re-run the scan to verify the secret or error has been properly removed or resolved.
- If an error occurs in any MCP server tool call (such as missing required parameters like version, invalid arguments, or tool invocation failures):
  - The AI agent must review the error, determine the cause, and automatically correct the tool call or input parameters.
  - Re-attempt the tool call with the corrected parameters.
  - Continue this process until the tool call succeeds or it is determined that remediation is not possible, in which case the issue and reason must be reported.
- Save scan results and remediation steps in a security log or as comments for audit purposes.

## Notes
- All scans must be performed using the MCP server integration (`endor-cli-tools`) as configured in `.cursor/mcp.json`. Do not invoke `endorctl` directly.
- For troubleshooting, ensure the MCP server is running and `endorctl` is installed and accessible in your environment.
- **Important**: This scan must use the path of the directory from which the changed files are in. Do not attempt to set the path directly to a file as it must be a directory. Use absolute paths like /Users/username/mcp-server-demo/backend rather than relative paths like 'backend'

This rule ensures no accidental credentials, tokens, API keys, or secrets are committed or remain in the project history. The scan may be performed at the end of an agent session, provided all modifications are checked and remediated before session completion.

---
description: "Run SAST scan using endor-cli-tools on source code changes"
globs: '**/*.c, **/*.cpp, **/*.cc, **/*.cs, **/*.go, **/*.java, **/*.js, **/*.jsx, **/*.ts, **/*.tsx, **/*.py, **/*.php, **/*.rb, **/*.rs, **/*.kt, **/*.kts, **/*.scala, **/*.swift, **/*.dart, **/*.html, **/*.yaml, **/*.yml, **/*.json, **/*.xml, **/*.sh, **/*.bash, **/*.clj, **/*.cljs, **/*.ex, **/*.exs, **/*.lua'
alwaysApply: true
---

# Static Application Security Testing (SAST) Rule (Endor Labs via MCP)

This project uses @Endor Labs for automated SAST, integrated through the MCP server as configured in `.cursor/mcp.json`.

## Workflow

Whenever a file is modified in the repository, and before the end of an agent session perform the following workflow:

- Run `endor-cli-tools` using the `scan` tool via the MCP server to perform SAST scans as described above.
- If any vulnerabilities or errors are found:
  - Present the issues to the user.
  - The AI agent must attempt to automatically correct all errors and vulnerabilities, including code errors, security issues, and best practice violations, before session completion.
  - Recommend and apply appropriate fixes (e.g., input sanitization, validation, escaping, secure APIs).
  - Continue scanning and correcting until all critical issues have been resolved or no further automated remediation is possible.
- If an error occurs in any MCP server tool call (such as missing required parameters like version, invalid arguments, or tool invocation failures):
  - The AI agent must review the error, determine the cause, and automatically correct the tool call or input parameters.
  - Re-attempt the tool call with the corrected parameters.
  - Continue this process until the tool call succeeds or it is determined that remediation is not possible, in which case the issue and reason must be reported.
- Save scan results and remediation steps in a security log or as comments for audit purposes.

## Notes
- All scans must be performed using the MCP server integration (`endor-cli-tools`) as configured in `.cursor/mcp.json`. Do not invoke `endorctl` directly.
- For troubleshooting, ensure the MCP server is running and `endorctl` is installed and accessible in your environment.
- Do not invoke Opengrep directly.
- **Important**: This scan must use the path of the directory from which the changed files are in. Do not attempt to set the path directly to a file as it must be a directory. Use absolute paths like /Users/username/mcp-server-demo/backend rather than relative paths like 'backend'

This rule ensures all code changes are automatically reviewed and remediated for common security vulnerabilities and errors using `endor-cli-tools` and the MCP server, with Opengrep as the underlying engine.

Watch how to use Endor Labs with Cursor

Troubleshooting

"command": "endorctl",
"args": ["ai-tools", "mcp-server"]

Prerequisites for Endor Labs MCP server on Windows

npx --version

The Endor Labs MCP server integrates directly into Claude Code to scan your code as you write, catching security issues before they reach production.

The following sections walk you through setting up the Endor Labs MCP server:

• Prerequisites for Endor Labs MCP server
• Interactive setup
• Tools in the Endor Labs MCP server
• Choose your edition
• Developer Edition
• Enterprise Edition
• Scope options
• Manage MCP servers
• Configure CLAUDE.md
• Troubleshooting

Prerequisites for Endor Labs MCP server

Ensure that the following prerequisites are met:

• Claude Code
• Node.js version 18 or later (required if you don’t have endorctl installed)
• Windows users: See Prerequisites for Endor Labs MCP server on Windows for additional instructions

Interactive setup

Select your edition, fill in any required fields, and click Copy to get the command that adds the Endor Labs MCP server to Claude Code.

Tools in the Endor Labs MCP server

Choose your edition

The Endor Labs MCP server has two editions:

• Developer Edition: A free edition that requires no configuration. A browser window opens on first use for authentication via GitHub, GitLab, or Google. The Developer Edition provides access to default security policies from Endor Labs.
• Enterprise Edition: A paid edition that enforces your organization’s specific security policies. Authenticate using GitHub, GitLab, Google, or SSO. You must specify your namespace to access your organization’s policies.

Additionally, if you already have Endor Labs configured locally (for example, from a previous endorctl init command), the MCP server can use your pre-existing configuration.

Developer Edition

Developer Edition: Add the MCP server with a single command

Run the following command to add the MCP server to your project. This adds the server with --scope local (available only to you in the current project). See Scope options for other scopes.

claude mcp add endor-cli-tools -- npx -y endorctl ai-tools mcp-server

Developer Edition: Add the MCP server with .mcp.json configuration

Create an .mcp.json file in the root of your repository and add the following configuration. This uses project scope, which is shared with everyone working on the repository.

{
  "mcpServers": {
    "endor-cli-tools": {
      "command": "npx",
      "args": [
        "-y",
        "endorctl",
        "ai-tools",
        "mcp-server"
      ]
    }
  }
}

Developer Edition: Verify the installation

claude mcp list

Confirm that endor-cli-tools appears in the list. You can also use /mcp in Claude Code to view active MCP servers.

Try a test prompt

After installing the MCP server, try the following prompt in your AI chat or CLI to verify that the tools are working.

Check if the npm package lodash version 4.17.20 has any vulnerabilities

The MCP server uses the check_dependency_for_vulnerabilities tool to check for known vulnerabilities and return the results. If you see a response with vulnerability details, the MCP server is working correctly.

Enterprise Edition

For Enterprise Edition, you need your organization’s Endor Labs namespace and an authentication method. Ensure that your developers have Read-Only permissions to Endor Labs. See Authorization policies for more details.

Enterprise Edition: Add the MCP server with a single command

claude mcp add --transport stdio --scope user \
  --env ENDOR_NAMESPACE=<namespace> \
  --env ENDOR_MCP_SERVER_AUTH_MODE=<google|github|gitlab|sso> \
  --env ENDOR_TOKEN=automatic \
  endor-cli-tools -- npx -y endorctl ai-tools mcp-server

If you want to use SSO authentication, you must also add ENDOR_MCP_SERVER_AUTH_TENANT to the environment variables.

claude mcp add --transport stdio --scope user \
  --env ENDOR_NAMESPACE=my-org \
  --env ENDOR_MCP_SERVER_AUTH_MODE=sso \
  --env ENDOR_MCP_SERVER_AUTH_TENANT=my-tenant \
  --env ENDOR_TOKEN=automatic \
  endor-cli-tools -- npx -y endorctl ai-tools mcp-server

For example, if your Endor Labs namespace is my-org and you want to use Google authentication, run the following command:

claude mcp add --transport stdio --scope user \
  --env ENDOR_NAMESPACE=my-org \
  --env ENDOR_MCP_SERVER_AUTH_MODE=google \
  --env ENDOR_TOKEN=automatic \
  endor-cli-tools -- npx -y endorctl ai-tools mcp-server

Enterprise Edition: Add the MCP server with .mcp.json configuration

Create an .mcp.json file in the root of your repository and add the following configuration to add the MCP server to your project.

{
  "mcpServers": {
    "endor-cli-tools": {
      "command": "npx",
      "args": [
        "-y",
        "endorctl",
        "ai-tools",
        "mcp-server"
      ],
      "env": {
        "ENDOR_NAMESPACE": "<namespace>",
        "ENDOR_MCP_SERVER_AUTH_MODE": "<google|github|gitlab|sso>",
        "ENDOR_TOKEN": "automatic"
      }
    }
  }
}

If you want to use SSO authentication, you must also add ENDOR_MCP_SERVER_AUTH_TENANT to the env section.

{
  "mcpServers": {
    "endor-cli-tools": {
      "command": "npx",
      "args": [
        "-y",
        "endorctl",
        "ai-tools",
        "mcp-server"
      ],
      "env": {
        "ENDOR_NAMESPACE": "<namespace>",
        "ENDOR_MCP_SERVER_AUTH_MODE": "sso",
        "ENDOR_MCP_SERVER_AUTH_TENANT": "<tenant>",
        "ENDOR_TOKEN": "automatic"
      }
    }
  }
}

Replace <namespace> with your Endor Labs namespace and choose your authentication mode.

Enterprise Edition: Verify the installation

claude mcp list

Confirm that endor-cli-tools appears in the list. You can also use /mcp in Claude Code to view active MCP servers.

Try a test prompt

After installing the MCP server, try the following prompt in your AI chat or CLI to verify that the tools are working.

Check if the npm package lodash version 4.17.20 has any vulnerabilities

The MCP server uses the check_dependency_for_vulnerabilities tool to check for known vulnerabilities and return the results. If you see a response with vulnerability details, the MCP server is working correctly.

Scope options

Claude Code supports three MCP configuration scopes:

• --scope local: Available only to you in the current project (default).
• --scope project: Shared with everyone in the project via .mcp.json file.
• --scope user: Available to you across all projects.

Manage MCP servers

claude mcp list
claude mcp get endor-cli-tools
claude mcp remove endor-cli-tools

In Claude Code, use /mcp to view and manage your active MCP servers.

Configure CLAUDE.md

To enhance the MCP server integration, you can add instructions in CLAUDE.md at the root of your repository. Claude Code reads CLAUDE.md files to guide AI development with your project-specific instructions.

1. Navigate to the root of your repository.

2. Create or edit the CLAUDE.md file in the root of your repository.

3. Add appropriate rules for your project. For example, you can add a rule to check if the code is free from vulnerabilities.

Example CLAUDE.md instructions

You can use the following CLAUDE.md instructions as a quick start for the Endor Labs MCP server. Modify the instructions to meet your specific organization’s needs. For more information, refer to the Claude Code documentation.

• SCA Rule Example
• Secrets Rule Example
• SAST Rule Example

# Software Composition Analysis (SCA) Rule (Endor Labs via MCP)

This project uses Endor Labs for automated dependency (SCA) scanning, integrated through the MCP server.

## Workflow

Every time a manifest or lockfile (package.json, requirements.txt, go.mod, pom.xml, etc.) is created or modified in any way, immediately do the following prior to performing your next task.

**Important**: Do not proceed after creating or modifying a manifest file without running this first.

- Run `endor-cli-tools` using the `check_dependency_for_vulnerabilities` tool via the MCP server.
- Provide the **ecosystem**, **dependency name**, and **version** always when making this tool call.
- If a vulnerability or error is identified:
  - Upgrade to the suggested safe version, or
  - Replace the dependency with a non-vulnerable alternative.
- Re-run the check using `endor-cli-tools` to confirm the issue is resolved.

## Notes
- All scans must be performed using the MCP server integration (`endor-cli-tools`). Do not invoke `endorctl` directly.

# Leaked Secrets Detection Rule (Endor Labs via MCP)

This project uses [Endor Labs](https://docs.endorlabs.com/) for automated security scanning, integrated through the MCP server.

## Workflow

Whenever a file is modified in the repository, and before the end of an agent session:

- Run `endor-cli-tools` using the `scan` tool via the MCP server to check for leaked secrets.
- If any secrets or errors are detected:
  - Remove the exposed secret or correct the error immediately.
  - Re-run the scan to verify the secret has been properly removed.
- Save scan results and remediation steps in a security log or as comments for audit purposes.

## Notes
- All scans must be performed using the MCP server integration (`endor-cli-tools`). Do not invoke `endorctl` directly.
- This scan must use the path of the directory from which the changed files are in. Use absolute paths.

# Static Application Security Testing (SAST) Rule (Endor Labs via MCP)

This project uses [Endor Labs](https://docs.endorlabs.com/) for automated SAST, integrated through the MCP server.

## Workflow

Whenever a file is modified in the repository, and before the end of an agent session:

- Run `endor-cli-tools` using the `scan` tool via the MCP server to perform SAST scans.
- If any vulnerabilities or errors are found:
  - Present the issues to the user.
  - Recommend and apply appropriate fixes (e.g., input sanitization, validation, escaping, secure APIs).
- Save scan results and remediation steps in a security log or as comments for audit purposes.

## Notes
- All scans must be performed using the MCP server integration (`endor-cli-tools`). Do not invoke `endorctl` directly.
- Do not invoke Opengrep directly.
- This scan must use the path of the directory from which the changed files are in. Use absolute paths.

Watch how to use Endor Labs with Claude Code

Troubleshooting

"command": "endorctl",
"args": ["ai-tools", "mcp-server"]

Prerequisites for Endor Labs MCP server on Windows

npx --version

The Endor Labs MCP server integrates directly into OpenAI Codex to scan your code as you write, catching security issues before they reach production.

The following sections walk you through setting up the Endor Labs MCP server:

• Prerequisites for Endor Labs MCP server
• Interactive setup
• Tools in the Endor Labs MCP server
• Choose your edition
• Developer Edition
• Enterprise Edition
• Manage MCP server tools
• Configure AGENTS.md
• Troubleshooting

Prerequisites for Endor Labs MCP server

Ensure that the following prerequisites are met:

• OpenAI Codex CLI
• Node.js version 18 or later (required if you don’t have endorctl installed)
• Windows users: See Prerequisites for Endor Labs MCP server on Windows for additional instructions

Interactive setup

Select your edition, fill in any required fields, and click Copy to get the command that adds the Endor Labs MCP server to OpenAI Codex.

Tools in the Endor Labs MCP server

Choose your edition

The Endor Labs MCP server has two editions:

• Developer Edition: A free edition that requires no configuration. A browser window opens on first use for authentication via GitHub, GitLab, or Google. The Developer Edition provides access to default security policies from Endor Labs.
• Enterprise Edition: A paid edition that enforces your organization’s specific security policies. Authenticate using GitHub, GitLab, Google, or SSO. You must specify your namespace to access your organization’s policies.

Additionally, if you already have Endor Labs configured locally (for example, from a previous endorctl init command), the MCP server can use your pre-existing configuration.

Developer Edition

Developer Edition: Add the MCP server with a single command

Run the following command to add the MCP server to your project.

codex mcp add endor-cli-tools -- npx -y endorctl ai-tools mcp-server

Developer Edition: Add the MCP server with config.toml

Add the following to your ~/.codex/config.toml (or a project-scoped .codex/config.toml).

[mcp_servers.endor-cli-tools]
command = "npx"
args = ["-y", "endorctl", "ai-tools", "mcp-server"]

Developer Edition: Verify the installation

codex mcp list

Confirm that endor-cli-tools appears in the list. You can also use /mcp in the Codex TUI to view active MCP servers.

Try a test prompt

After installing the MCP server, try the following prompt in your AI chat or CLI to verify that the tools are working.

Check if the npm package lodash version 4.17.20 has any vulnerabilities

The MCP server uses the check_dependency_for_vulnerabilities tool to check for known vulnerabilities and return the results. If you see a response with vulnerability details, the MCP server is working correctly.

Enterprise Edition

For Enterprise Edition, you need your organization’s Endor Labs namespace and an authentication method. Ensure that your developers have Read-Only permissions to Endor Labs. See Authorization policies for more details.

Enterprise Edition: Add the MCP server with a single command

codex mcp add endor-cli-tools \
  --env ENDOR_NAMESPACE=<namespace> \
  --env ENDOR_MCP_SERVER_AUTH_MODE=<google|github|gitlab|sso> \
  --env ENDOR_TOKEN=automatic \
  -- npx -y endorctl ai-tools mcp-server

Replace <namespace> with your Endor Labs namespace and choose your authentication mode. If you choose sso, you must also add ENDOR_MCP_SERVER_AUTH_TENANT to the environment variables.

Enterprise Edition: Add the MCP server with config.toml

[mcp_servers.endor-cli-tools]
command = "npx"
args = ["-y", "endorctl", "ai-tools", "mcp-server"]

[mcp_servers.endor-cli-tools.env]
ENDOR_NAMESPACE = "<namespace>"
ENDOR_MCP_SERVER_AUTH_MODE = "<google|github|gitlab|sso>"
ENDOR_TOKEN = "automatic"

Replace <namespace> with your Endor Labs namespace and choose your authentication mode. If you choose sso, you must also add ENDOR_MCP_SERVER_AUTH_TENANT to the env section.

Enterprise Edition: Verify the installation

codex mcp list

Confirm that endor-cli-tools appears in the list.

Try a test prompt

After installing the MCP server, try the following prompt in your AI chat or CLI to verify that the tools are working.

Check if the npm package lodash version 4.17.20 has any vulnerabilities

The MCP server uses the check_dependency_for_vulnerabilities tool to check for known vulnerabilities and return the results. If you see a response with vulnerability details, the MCP server is working correctly.

Manage MCP server tools

In the Codex TUI, use /mcp to see your active MCP servers. You can also disable specific tools in the config.toml file:

[mcp_servers.endor-cli-tools]
command = "npx"
args = ["-y", "endorctl", "ai-tools", "mcp-server"]
enabled_tools = ["check_dependency_for_vulnerabilities", "scan"]

Configure AGENTS.md

To enhance the MCP server integration, you can add instructions in AGENTS.md at the root of your repository. Codex reads AGENTS.md files to guide AI development with your project-specific instructions.

1. Navigate to the root of your repository.

2. Create or edit the AGENTS.md file in the root of your repository.

3. Add appropriate rules for your project. For example, you can add a rule to check if the code is free from vulnerabilities.

Example AGENTS.md instructions

You can use the following AGENTS.md instructions as a quick start for the Endor Labs MCP server. Modify the instructions to meet your specific organization’s needs. For more information, refer to the OpenAI Codex AGENTS.md documentation.

• SCA Rule Example
• Secrets Rule Example
• SAST Rule Example

# Software Composition Analysis (SCA) Rule (Endor Labs via MCP)

This project uses Endor Labs for automated dependency (SCA) scanning, integrated through the MCP server.

## Workflow

Every time a manifest or lockfile (package.json, requirements.txt, go.mod, pom.xml, etc.) is created or modified in any way, immediately do the following prior to performing your next task.

**Important**: Do not proceed after creating or modifying a manifest file without running this first.

- Run `endor-cli-tools` using the `check_dependency_for_vulnerabilities` tool via the MCP server.
- Provide the **ecosystem**, **dependency name**, and **version** always when making this tool call.
- If a vulnerability or error is identified:
  - Upgrade to the suggested safe version, or
  - Replace the dependency with a non-vulnerable alternative.
- Re-run the check using `endor-cli-tools` to confirm the issue is resolved.

## Notes
- All scans must be performed using the MCP server integration (`endor-cli-tools`). Do not invoke `endorctl` directly.

# Leaked Secrets Detection Rule (Endor Labs via MCP)

This project uses [Endor Labs](https://docs.endorlabs.com/) for automated security scanning, integrated through the MCP server.

## Workflow

Whenever a file is modified in the repository, and before the end of an agent session:

- Run `endor-cli-tools` using the `scan` tool via the MCP server to check for leaked secrets.
- If any secrets or errors are detected:
  - Remove the exposed secret or correct the error immediately.
  - Re-run the scan to verify the secret has been properly removed.
- Save scan results and remediation steps in a security log or as comments for audit purposes.

## Notes
- All scans must be performed using the MCP server integration (`endor-cli-tools`). Do not invoke `endorctl` directly.
- This scan must use the path of the directory from which the changed files are in. Use absolute paths.

# Static Application Security Testing (SAST) Rule (Endor Labs via MCP)

This project uses [Endor Labs](https://docs.endorlabs.com/) for automated SAST, integrated through the MCP server.

## Workflow

Whenever a file is modified in the repository, and before the end of an agent session:

- Run `endor-cli-tools` using the `scan` tool via the MCP server to perform SAST scans.
- If any vulnerabilities or errors are found:
  - Present the issues to the user.
  - Recommend and apply appropriate fixes (e.g., input sanitization, validation, escaping, secure APIs).
- Save scan results and remediation steps in a security log or as comments for audit purposes.

## Notes
- All scans must be performed using the MCP server integration (`endor-cli-tools`). Do not invoke `endorctl` directly.
- Do not invoke Opengrep directly.
- This scan must use the path of the directory from which the changed files are in. Use absolute paths.

Troubleshooting

"command": "endorctl",
"args": ["ai-tools", "mcp-server"]

Prerequisites for Endor Labs MCP server on Windows

npx --version

The Endor Labs MCP server integrates directly into Visual Studio Code to scan your code as you write, catching security issues before they reach production.

The following sections walk you through setting up the Endor Labs MCP server:

• Prerequisites for Endor Labs MCP server
• One-click installation
• Tools in the Endor Labs MCP server
• Choose your edition
• Developer Edition
• Enterprise Edition
• Manage MCP server tools
• Use the MCP server with GitHub Copilot
• Example Copilot rules
• Troubleshooting

Prerequisites for Endor Labs MCP server

Ensure that the following prerequisites are met:

• Visual Studio Code version 1.99 or later
• MCP support enabled: set chat.mcp.enabled to true in your Visual Studio Code settings
• Node.js version 18 or later (required if you don’t have endorctl installed)
• Windows users: See Prerequisites for Endor Labs MCP server on Windows for additional instructions

One-click installation

Select your edition, fill in any required fields, and click Install in VS Code to add the Endor Labs MCP server directly to Visual Studio Code.

Tools in the Endor Labs MCP server

Choose your edition

The Endor Labs MCP server has two editions:

• Developer Edition: A free edition that requires no configuration. A browser window opens on first use for authentication via GitHub, GitLab, or Google. The Developer Edition provides access to default security policies from Endor Labs.
• Enterprise Edition: A paid edition that enforces your organization’s specific security policies. Authenticate using GitHub, GitLab, Google, or SSO. You must specify your namespace to access your organization’s policies.

Additionally, if you already have Endor Labs configured locally (for example, from a previous endorctl init command), the MCP server can use your pre-existing configuration.

Developer Edition

You can use the one-click installation tool above or set up the MCP server manually.

Developer Edition: Manual installation

If you prefer to configure the MCP server manually, add the configuration to a .vscode/mcp.json file in the root of your repository.

1. Navigate to the root of your repository.

2. Create a .vscode directory if it doesn’t exist and create an mcp.json file in the .vscode directory.

   mkdir -p .vscode && touch .vscode/mcp.json
   

3. Add the following configuration to the .vscode/mcp.json file.

   {
     "servers": {
       "endor-cli-tools": {
         "command": "npx",
         "args": [
           "-y",
           "endorctl",
           "ai-tools",
           "mcp-server"
         ]
       }
     }
   }
   

Developer Edition: Verify the installation

1. Open the Chat view by pressing Cmd+Option+I (macOS) or Ctrl+Alt+I (Windows/Linux).

2. Switch to Agent mode.

3. Click the Settings icon and confirm that MCP Server: endor-cli-tools appears and is enabled.

Try a test prompt

After installing the MCP server, try the following prompt in your AI chat or CLI to verify that the tools are working.

Check if the npm package lodash version 4.17.20 has any vulnerabilities

The MCP server uses the check_dependency_for_vulnerabilities tool to check for known vulnerabilities and return the results. If you see a response with vulnerability details, the MCP server is working correctly.

Enterprise Edition

For Enterprise Edition, you need your organization’s Endor Labs namespace and an authentication method. Ensure that your developers have Read-Only permissions to Endor Labs. See Authorization policies for more details.

You can use the one-click installation tool above or set up the MCP server manually.

Enterprise Edition: Manual installation

Add the following configuration to a .vscode/mcp.json file in the root of your repository.

{
  "servers": {
    "endor-cli-tools": {
      "command": "npx",
      "args": [
        "-y",
        "endorctl",
        "ai-tools",
        "mcp-server"
      ],
      "env": {
        "ENDOR_NAMESPACE": "<namespace>",
        "ENDOR_MCP_SERVER_AUTH_MODE": "<google|github|gitlab|sso>",
        "ENDOR_TOKEN": "automatic"
      }
    }
  }
}

Replace <namespace> with your Endor Labs namespace and choose your authentication mode. If you choose sso, you must also add ENDOR_MCP_SERVER_AUTH_TENANT to the env section.

Enterprise Edition: Verify the installation

1. Open the Chat view by pressing Cmd+Option+I (macOS) or Ctrl+Alt+I (Windows/Linux).

2. Switch to Agent mode.

3. Click the Settings icon and confirm that MCP Server: endor-cli-tools appears and is enabled.

Try a test prompt

After installing the MCP server, try the following prompt in your AI chat or CLI to verify that the tools are working.

Check if the npm package lodash version 4.17.20 has any vulnerabilities

The MCP server uses the check_dependency_for_vulnerabilities tool to check for known vulnerabilities and return the results. If you see a response with vulnerability details, the MCP server is working correctly.

Manage MCP server tools

1. Open the Chat view by pressing Cmd+Option+I.

2. Switch to the Agent mode.

3. Click the Settings icon.

4. Select the tools that you want to enable or disable under MCP Server: endor-cli-tools.

Use the MCP server with GitHub Copilot

To use the Endor Labs MCP server with GitHub Copilot in Visual Studio Code:

1. Open the Chat view by pressing Cmd+Option+I.

2. Switch to the Agent mode.

3. Click the Settings icon.

4. Select MCP Server: endor-cli-tools from the dropdown menu.

5. Set up Copilot rules in .github/instructions/*.md to use the Endor Labs MCP server throughout the development process. See Example Copilot rules for more information.

You can now use Endor Labs tools in your chat prompts to scan for vulnerabilities.

Example Copilot rules

Copilot instructions define the guidelines that Copilot should follow throughout the development process. The following examples demonstrate how to use the Endor Labs MCP server within Copilot rules.

• SCA Rule Example
• Secrets Rule Example
• SAST Rule Example

---
description: "Ensure newly added dependencies are checked for vulnerabilities and project stays clean"
applyTo: '**/package.json, **/package-lock.json, **/yarn.lock, **/pnpm-lock.yaml, **/requirements.txt, **/Pipfile, **/Pipfile.lock, **/pyproject.toml, **/poetry.lock, **/go.mod, **/go.sum, **/Cargo.toml, **/Cargo.lock, **/pom.xml, **/build.gradle, **/build.gradle.kts, **/gradle.lockfile, **/composer.json, **/composer.lock'
alwaysApply: true
---

# Software Composition Analysis (SCA) Rule (Endor Labs via MCP)
This project uses Endor Labs for automated dependency (SCA) scanning, integrated through the MCP server as configured in `.vscode/mcp.json`.

## Workflow

Every time a manifest or lockfile listed above is created or modified in any way immediately do the following prior to performing your next task.

**Important**: Do not proceed after creating or modifying a manifest file without running this first. Do not write any other code or continue with your existing prompt. This is top priority whenever a manifest file is created or updated.

- Run `endor-cli-tools` using the `check_dependency_for_vulnerabilities` tool via the MCP server.
- Provide the **ecosystem**, **dependency name**, and **version** always when making this tool call. Do not forget to provide a version.
- If a vulnerability or error is identified:
  - Upgrade to the suggested safe version, or
  - Replace the dependency with a non-vulnerable alternative.
  - The AI agent must attempt to automatically correct all detected errors and vulnerabilities before session completion.
- Re-run the check using `endor-cli-tools` to confirm the issue is resolved.
- If an error occurs in any MCP server tool call (such as missing required parameters like version, invalid arguments, or tool invocation failures):
  - The AI agent must review the error, determine the cause, and automatically correct the tool call or input parameters.
  - Re-attempt the tool call with the corrected parameters.
  - Continue this process until the tool call succeeds or it is determined that remediation is not possible, in which case the issue and reason must be reported.

## Notes
- All scans must be performed using the MCP server integration (`endor-cli-tools`) as configured in `.vscode/mcp.json`. Do not invoke `endorctl` directly.
- For troubleshooting, ensure the MCP server is running and `endorctl` is installed and accessible in your environment.

This rule ensures that all dependency changes are evaluated for risk at the time of introduction, and that the project remains clean and secure after each coding session. The scan may be performed at the end of an agent session, provided all modifications are checked and remediated before session completion.

---
description: "Scan for leaked secrets on file modification"
applyTo: '**/*'
alwaysApply: true
---

# Leaked Secrets Detection Rule (Endor Labs via MCP)
This project uses @Endor Labs for automated security scanning, integrated through the MCP server as configured in `.vscode/mcp.json`.

## Workflow
Whenever a file is modified in the repository, and before the end of an agent session:
- Run `endor-cli-tools` using the `scan` tool via the MCP server to check for leaked secrets.
- Ensure the scan includes all file types and respects `.gitignore` unless otherwise configured.
- If any secrets or errors are detected:
  - Remove the exposed secret or correct the error immediately.
  - The AI agent must attempt to automatically correct all detected secrets and errors before session completion.
  - Re-run the scan to verify the secret or error has been properly removed or resolved.
- If an error occurs in any MCP server tool call (such as missing required parameters like version, invalid arguments, or tool invocation failures):
  - The AI agent must review the error, determine the cause, and automatically correct the tool call or input parameters.
  - Re-attempt the tool call with the corrected parameters.
  - Continue this process until the tool call succeeds or it is determined that remediation is not possible, in which case the issue and reason must be reported.
- Save scan results and remediation steps in a security log or as comments for audit purposes.

## Notes
- All scans must be performed using the MCP server integration (`endor-cli-tools`) as configured in `.vscode/mcp.json`. Do not invoke `endorctl` directly.
- For troubleshooting, ensure the MCP server is running and `endorctl` is installed and accessible in your environment.
- **Important**: This scan must use the path of the directory from which the changed files are in. Do not attempt to set the path directly to a file as it must be a directory. Use absolute paths like /Users/username/mcp-server-demo/backend rather than relative paths like 'backend'

This rule ensures no accidental credentials, tokens, API keys, or secrets are committed or remain in the project history. The scan may be performed at the end of an agent session, provided all modifications are checked and remediated before session completion.

---
description: "Run SAST scan using endor-cli-tools on source code changes"
applyTo: '**/*.c, **/*.cpp, **/*.cc, **/*.cs, **/*.go, **/*.java, **/*.js, **/*.jsx, **/*.ts, **/*.tsx, **/*.py, **/*.php, **/*.rb, **/*.rs, **/*.kt, **/*.kts, **/*.scala, **/*.swift, **/*.dart, **/*.html, **/*.yaml, **/*.yml, **/*.json, **/*.xml, **/*.sh, **/*.bash, **/*.clj, **/*.cljs, **/*.ex, **/*.exs, **/*.lua'
alwaysApply: true
---

# Static Application Security Testing (SAST) Rule (Endor Labs via MCP)

This project uses @Endor Labs for automated SAST, integrated through the MCP server as configured in `.vscode/mcp.json`.

## Workflow

Whenever a file is modified in the repository, and before the end of an agent session perform the following workflow:

- Run `endor-cli-tools` using the `scan` tool via the MCP server to perform SAST scans as described above.
- If any vulnerabilities or errors are found:
  - Present the issues to the user.
  - The AI agent must attempt to automatically correct all errors and vulnerabilities, including code errors, security issues, and best practice violations, before session completion.
  - Recommend and apply appropriate fixes (e.g., input sanitization, validation, escaping, secure APIs).
  - Continue scanning and correcting until all critical issues have been resolved or no further automated remediation is possible.
- If an error occurs in any MCP server tool call (such as missing required parameters like version, invalid arguments, or tool invocation failures):
  - The AI agent must review the error, determine the cause, and automatically correct the tool call or input parameters.
  - Re-attempt the tool call with the corrected parameters.
  - Continue this process until the tool call succeeds or it is determined that remediation is not possible, in which case the issue and reason must be reported.
- Save scan results and remediation steps in a security log or as comments for audit purposes.

## Notes
- All scans must be performed using the MCP server integration (`endor-cli-tools`) as configured in `.vscode/mcp.json`. Do not invoke `endorctl` directly.
- For troubleshooting, ensure the MCP server is running and `endorctl` is installed and accessible in your environment.
- Do not invoke Opengrep directly.
- **Important**: This scan must use the path of the directory from which the changed files are in. Do not attempt to set the path directly to a file as it must be a directory. Use absolute paths like /Users/username/mcp-server-demo/backend rather than relative paths like 'backend'

This rule ensures all code changes are automatically reviewed and remediated for common security vulnerabilities and errors using `endor-cli-tools` and the MCP server, with Opengrep as the underlying engine.