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 datacenter 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, 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[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 App for Bitbucket Data Center

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 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 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 Data Center host.

6. Enter the Bitbucket Data Center HTTP access token.

   The HTTP access token must have at least the Project read permission at the project level.

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.

   

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

Tools in the Endor Labs MCP server

The Endor Labs MCP server provides the following tools:

• check_dependency_for_vulnerabilities: Check if the dependencies in your project are vulnerable.
• get_endor_vulnerability: Get the details of a specific vulnerability from the Endor Labs vulnerability database.
• get_resource: Add additional context from commonly used Endor Labs resources about your software such as findings, vulnerabilities, and projects.
• scan: Run an Endor Labs security scan to detect risks in your open source dependencies, find common security issues, and spot any credentials accidentally exposed in your Git repository.

After you set up the MCP server, you can choose to disable the tools that you do not want to use.

Choose your IDE or platform to get started

The Endor Labs Model Context Protocol (MCP) server integrates seamlessly into your AI-native development workflows to help you keep your code secure and fix security risks faster. You can catch issues long before they’re a problem in production and fix them faster when they already are.

This guide details how to integrate Endor Labs security capabilities directly into your Cursor development workflows using MCP.

How Endor Labs MCP server helps your Cursor workflow

How to use the Endor Labs MCP server

Integrate Endor Labs MCP server into Cursor

Complete the following tasks to integrate Endor Labs MCP Server into Cursor.

• Configure the MCP server: Configure the MCP server in Cursor. You can use the interactive configuration tool or manually configure the MCP server. See Configure the MCP server in Cursor for more details. No configuration is required to get started with the Developer Edition.

• Configure permissions for your developers (optional): If you’re using the Enterprise Edition with a specific namespace, ensure that your developers have Read-Only permissions to Endor Labs. See Endor Lab’s Authorization policies for more details.

• Configure Cursor rules (optional): Configure Cursor rules to guide AI development with Endor Labs. See Configure Cursor rules for more details.

Configure the MCP server in Cursor

Cursor allows you to set MCP configurations at the project and the user level.

You can manually configure the MCP server or use the interactive configuration tool to generate a one-click installation link for Cursor.

Set up Endor Labs MCP server on Windows

npx --version

Developer Edition

Add the following configuration to the .cursor/mcp.json file to use the Endor Labs MCP server with the Developer Edition.

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

Interactive MCP server configuration

Use our interactive configuration tool to generate a one-click installation link for Cursor. You can configure all the necessary parameters and generate a Cursor link that you can click to automatically install the MCP server.

After you click Add Endor Labs MCP server, MCP Settings opens in Cursor.

You can verify the configuration and click Install to complete the installation.

Manual MCP server configuration at the repository level

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.

   Developer Edition

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

   Use pre-existing configuration

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

   Your local configuration already contains the namespace information, so you don’t need to specify ENDOR_NAMESPACE separately.

   Enterprise Edition

   {
     "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"
         }
       }
     }
   }
   

   For Enterprise Edition, specify your namespace and choose an authentication mode. If you choose sso, you must also add ENDOR_MCP_SERVER_AUTH_TENANT to the env section.

   The following parameters are used to configure the MCP server. All parameters are optional. If no parameters are provided, the MCP server defaults to the Developer Edition with browser authentication.

   • ENDOR_MCP_SERVER_AUTH_MODE: (Optional) The authentication mode to use for the MCP server. You can use the following authentication modes: github, gitlab, google, sso. If you choose sso, you must add ENDOR_MCP_SERVER_AUTH_TENANT as an additional parameter. If not specified, the MCP server defaults to browser authentication for the Developer Edition.
   • ENDOR_NAMESPACE: (Optional) The namespace to use for the MCP server. Required for Enterprise Edition to access your organization’s specific policies. Not needed for Developer Edition.
   • ENDOR_TOKEN: (Optional) The token to use for the MCP server. Do not set this value manually. It will be set automatically by the MCP server during authentication.
   • ENDOR_MCP_SERVER_AUTH_TENANT: (Optional) The tenant name for SSO authentication. Required when ENDOR_MCP_SERVER_AUTH_MODE is set to sso for Enterprise Edition access.

Manage Endor Labs MCP server tools in Cursor

1. Navigate to the 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 recommended 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.

The Endor Labs Model Context Protocol (MCP) server integrates seamlessly into your AI-native development workflows to help you keep your code secure and fix security risks faster. You can catch issues long before they’re a problem in production and fix them faster when they already are.

This guide details how to integrate Endor Labs security capabilities directly into your Visual Studio Code development workflows using MCP.

How Endor Labs MCP server helps your Visual Studio Code workflow

How to use the Endor Labs MCP server

Integrate Endor Labs MCP server into Visual Studio Code

Complete the following tasks to integrate Endor Labs MCP Server into Visual Studio Code.

• Configure the MCP server: Configure the MCP server in Visual Studio Code. You can use the interactive configuration tool or manually configure the MCP server. See Configure the MCP server in Visual Studio Code for more details. No configuration is required to get started with the Developer Edition.

• Configure permissions for your developers (optional): If you’re using the Enterprise Edition with a specific namespace, ensure that your developers have Read-Only permissions to Endor Labs. See Endor Lab’s Authorization policies for more details.

Configure the MCP server in Visual Studio Code

Visual Studio Code allows you to set MCP configurations at the project and the user level.

You can manually configure the MCP server or use the interactive configuration tool to generate a one-click installation link for Visual Studio Code.

Set up Endor Labs MCP server on Windows

npx --version

Developer Edition

Add the following configuration to the .vscode/mcp.json file to use the Endor Labs MCP server with the Developer Edition.

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

Interactive MCP server configuration

Use our interactive configuration tool to generate a one-click installation link for Visual Studio Code. You can configure all the necessary parameters and generate a Visual Studio Code link that you can click to automatically install the MCP server.

Manual MCP server configuration at the repository level

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.

   Developer Edition

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

   Use pre-existing configuration

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

   Your local configuration already contains the namespace information, so you don’t need to specify ENDOR_NAMESPACE separately.

   Enterprise Edition

   {
     "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"
         }
       }
     }
   }
   

   For Enterprise Edition, specify your namespace and choose an authentication mode. If you choose sso, you must also add ENDOR_MCP_SERVER_AUTH_TENANT to the env section.

   The following parameters are used to configure the MCP server. All parameters are optional. If no parameters are provided, the MCP server defaults to the Developer Edition with browser authentication.

   • ENDOR_MCP_SERVER_AUTH_MODE: (Optional) The authentication mode to use for the MCP server. You can use the following authentication modes: github, gitlab, google, sso. If you choose sso, you must add ENDOR_MCP_SERVER_AUTH_TENANT as an additional parameter. If not specified, the MCP server defaults to browser authentication for the Developer Edition.
   • ENDOR_NAMESPACE: (Optional) The namespace to use for the MCP server. Required for Enterprise Edition to access your organization’s specific policies. Not needed for Developer Edition.
   • ENDOR_TOKEN: (Optional) The token to use for the MCP server. Do not set this value manually. It will be set automatically by the MCP server during authentication.
   • ENDOR_MCP_SERVER_AUTH_TENANT: (Optional) The tenant name for SSO authentication. Required when ENDOR_MCP_SERVER_AUTH_MODE is set to sso for Enterprise Edition access.

Manage Endor Labs MCP server tools 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 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 Copilot rules examples to learn more.

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.

The Endor Labs Model Context Protocol (MCP) server integrates seamlessly into your AI-native development workflows to help you keep your code secure and fix security risks faster. You can catch issues long before they’re a problem in production and fix them faster when they already are.

Endor Labs MCP server is available as a Gemini extension. After you install the extension, you can use natural language commands to interact with the MCP server. You can find the extension on GitHub.

This guide details how to integrate Endor Labs security capabilities directly into your Gemini development workflows using MCP.

How Endor Labs MCP server helps your Gemini workflow

How to use the Endor Labs MCP server

Integrate Endor Labs MCP server into Gemini

Complete the following tasks to integrate Endor Labs MCP Server into Gemini.

• Install the Endor Labs MCP server as a Gemini extension. See Install the Endor Labs MCP server as a Gemini extension for more details. No configuration is required to get started with the Developer Edition.

• Configure permissions for your developers (optional): If you’re using the Enterprise Edition with a specific namespace, ensure that your developers have Read-Only permissions to Endor Labs. See Endor Lab’s Authorization policies for more details.

Set up Endor Labs MCP server on Windows

npx --version

Tools in the Endor Labs MCP server

The Endor Labs MCP server provides the following tools:

• check_dependency_for_vulnerabilities: Check if the dependencies in your project are vulnerable.
• get_endor_vulnerability: Get the details of a specific vulnerability from the Endor Labs vulnerability database.
• get_resource: Add additional context from commonly used Endor Labs resources about your software such as findings, vulnerabilities, and projects.
• scan: Run an Endor Labs security scan to detect risks in your open source dependencies, find common security issues, and spot any credentials accidentally exposed in your Git repository.

After you set up the MCP server, you can choose to disable the tools that you do not want to use.

Install the Endor Labs MCP server as a Gemini extension

Run the following command to install the Endor Labs MCP server as a Gemini extension.

gemini extensions install https://github.com/endorlabs/gemini-extension.git

Verify the Endor Labs MCP server installation

Run the following command in the Gemini CLI to verify the Endor Labs MCP server installation.

gemini> /mcp list

The following output appears if the Endor Labs MCP server is installed.

Initialize the Endor Labs MCP server in Gemini CLI

After you install the Endor Labs MCP server as a Gemini extension, you can optionally initialize the MCP server in Gemini CLI.

Developer Edition

You can use the MCP server without initialization. When you first use a tool, a browser window will open allowing you to authenticate with GitHub, GitLab, or Google. The MCP server will automatically use the Developer Edition with default security policies.

Use pre-existing configuration

If you already have Endor Labs configured locally (from a previous endorctl initialization), the MCP server uses your local configuration. The configuration already contains the namespace information, so you don’t need to specify it separately.

Enterprise Edition

If you want to use the Enterprise Edition with your organization’s specific policies, you can use natural language commands to initiate an authentication flow.

gemini> Initialize Endor Labs with Google authentication using the command `endorctl init --auth-mode=google`

You can use any supported authentication mode: google, github, gitlab, or sso. If you choose sso, you must also provide your tenant name. Existing users with read-only permissions on a namespace can authenticate to their namespace through the browser.

Use Endor Labs MCP server in Gemini CLI

After you initialize the MCP server, you can converse with the MCP server using natural language commands to get information about your projects, vulnerabilities, and dependencies.

The following examples show how to use the Endor Labs MCP server in Gemini CLI. Always navigate to the project directory before using the MCP server.

Example: Scan for security vulnerabilities in your project

gemini> Scan my project for security vulnerabilities

Example: Check dependencies for known CVEs

gemini> Check dependencies for known CVEs

Example: Generate a security report for this repository

gemini> Generate a security report for this repository

Gemini context file

The Endor Labs MCP server provides a context file that you can use to add additional context to the MCP server. The context file,ENDORLABS_CONTEXT.md is located in the ~/.gemini/extensions/endorlabs/gemini-extension/ directory.

You can use the context file to add additional context to the MCP server. For example, you can add additional rules and context for your project in the context file.

The Endor Labs Model Context Protocol (MCP) server integrates seamlessly into your AI-native development workflows to help you keep your code secure and fix security risks faster. You can catch issues long before they’re a problem in production and fix them faster when they already are.

How Endor Labs MCP server helps your IntelliJ IDEA workflow

How to use the Endor Labs MCP server

Integrate Endor Labs MCP server into IntelliJ IDEA

Complete the following tasks to integrate Endor Labs MCP Server into IntelliJ IDEA.

• Configure the MCP server: Configure the MCP server in IntelliJ IDEA with GitHub Copilot. You can use the interactive configuration tool or manually configure the MCP server. See Configure the MCP server in IntelliJ IDEA with GitHub Copilot for more details. No configuration is required to get started with the Developer Edition.

• Configure permissions for your developers (optional): If you’re using the Enterprise Edition with a specific namespace, ensure that your developers have Read-Only permissions to Endor Labs. See Endor Lab’s Authorization policies for more details.

• Configure Copilot rules (optional): Set up Copilot rules to guide AI development with Endor Labs. See Example Copilot rules for more details.

Configure the MCP server in IntelliJ IDEA with GitHub Copilot

IntelliJ IDEA allows you to set MCP configurations at the project and the user level.

You can manually configure the MCP server or use the interactive configuration tool to generate a one-click installation link for IntelliJ IDEA.

Set up Endor Labs MCP server on Windows

npx --version

Developer Edition

Add the following configuration to the mcp.json file to use the Endor Labs MCP server with the Developer Edition.

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

Interactive MCP server configuration

Use our interactive configuration tool to generate a one-click installation link for IntelliJ IDEA. You can configure all the necessary parameters and generate an IntelliJ IDEA link that you can click to automatically install the MCP server.

Manual MCP server configuration at the repository level

1. Open the GitHub Copilot Chat from the right sidebar.

2. Switch to Agent mode.

3. Click Configure Tools.

4. Select + Add More Tools… from the bottom left corner to open the mcp.json and configure the Copilot rules.

5. Add the following configuration to the mcp.json file.

   Developer Edition

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

   Use pre-existing configuration

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

   Your local configuration already contains the namespace information, so you don’t need to specify ENDOR_NAMESPACE separately.

   Enterprise Edition

   {
     "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"
         }
       }
     }
   }
   

   For Enterprise Edition, specify your namespace and choose an authentication mode. If you choose sso, you must also add ENDOR_MCP_SERVER_AUTH_TENANT to the env section.

   The following parameters are used to configure the MCP server. All parameters are optional. If no parameters are provided, the MCP server defaults to the Developer Edition with browser authentication.

   • ENDOR_MCP_SERVER_AUTH_MODE: (Optional) The authentication mode to use for the MCP server. You can use the following authentication modes: github, gitlab, google, sso. If you choose sso, you must add ENDOR_MCP_SERVER_AUTH_TENANT as an additional parameter. If not specified, the MCP server defaults to browser authentication for the Developer Edition.
   • ENDOR_NAMESPACE: (Optional) The namespace to use for the MCP server. Required for Enterprise Edition to access your organization’s specific policies. Not needed for Developer Edition.
   • ENDOR_TOKEN: (Optional) The token to use for the MCP server. Do not set this value manually. It will be set automatically by the MCP server during authentication.
   • ENDOR_MCP_SERVER_AUTH_TENANT: (Optional) The tenant name for SSO authentication. Required when ENDOR_MCP_SERVER_AUTH_MODE is set to sso for Enterprise Edition access.

6. Save and close the mcp.json.

7. Switch from Agent to Ask mode in the chat and then back to Agent mode to access the Endor Labs MCP server.

8. Click Configure Tools and select endor-cli-tools.

9. Set up Copilot rules in .github/instructions/*.md to use the Endor Labs MCP server throughout the development process. See Add repository custom instructions for GitHub Copilot and Copilot example rules to learn more.

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: "Dependency vulnerability scanning using Endor Labs via MCP server integration"
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'

---

# 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 `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 `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 using Endor Labs via MCP server integration"
applyTo: '**/*'

---

# 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 as configured in `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 `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: "Static Application Security Testing (SAST) using Endor Labs via MCP server integration"
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'

---

# 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 as configured in `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 `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.

Perform software composition analysis, dependency management, or detect secrets in your code using Endor Labs.

Download and install endorctl

Use one of the following methods to download and install endorctl on your local system. After you install endorctl, you must authenticate. Then you can start scanning your code.

Install endorctl with Homebrew

Use Homebrew to efficiently install endorctl on macOS and Linux operating systems making it easy to manage dependencies, and track installed packages with their versions.

Install endorctl from the Endor Labs tap with Homebrew by running the following commands. The tap is updated regularly with the latest endorctl release.

brew tap endorlabs/tap
brew install endorctl

Install endorctl with npm

Use npm to efficiently install endorctl on macOS, Linux, and Windows operating systems making it easy to manage dependencies, track and update installed packages and their versions.

1. Make sure that you have npm installed in your local environment and use the following command to install endorctl.

   npm install -g endorctl
   

2. Run the following command to get the npm global bin directory.

   npm config get prefix
   

3. Edit your shell configuration file and insert the path you obtained from the previous command.

   export PATH="/path/to/npm/global/bin:$PATH"
   

4. Reload your shell configuration and verify endorctl is installed.

   endorctl --version
   

5. To update your version of endorctl, run the following command.

   npm update -g endorctl
   

endorctl is available as an npm package and is updated regularly with the latest endorctl release.

Download and install the endorctl binary directly

To download the endorctl binary directly use the following commands:

• Linux
• Mac OS
• Windows

## Download the latest CLI for Linux amd64
curl https://api.endorlabs.com/download/latest/endorctl_linux_amd64 -o endorctl

## Verify the checksum of the binary
echo "$(curl -s https://api.endorlabs.com/sha/latest/endorctl_linux_amd64)  endorctl" | sha256sum -c

## Modify the permissions of the binary to ensure it is executable
chmod +x ./endorctl

## Create an alias endorctl of the binary to ensure it is available in other directory
alias endorctl="$PWD/endorctl"

### Download the latest CLI for MacOS ARM64
curl https://api.endorlabs.com/download/latest/endorctl_macos_arm64 -o endorctl

### Verify the checksum of the binary
echo "$(curl -s https://api.endorlabs.com/sha/latest/endorctl_macos_arm64)  endorctl" | shasum -a 256 -c

### Modify the permissions of the binary to ensure it is executable
chmod +x ./endorctl

### Create an alias endorctl of the binary to ensure it is available in other directory
alias endorctl="$PWD/endorctl"

## Download the latest CLI for Windows amd64
curl -O https://api.endorlabs.com/download/latest/endorctl_windows_amd64.exe

## Check the expected checksum of the binary file
curl https://api.endorlabs.com/sha/latest/endorctl_windows_amd64.exe

## Verify the expected checksum and the actual checksum of the binary match
certutil -hashfile .\endorctl_windows_amd64.exe SHA256

## Rename the binary file
ren endorctl_windows_amd64.exe endorctl.exe

You can also view these instructions via the Endor Labs application user interface:

1. Sign in to Endor Labs.
2. Select Projects from the left sidebar.
3. Click Add Project.
4. Choose CLI.
5. Follow the on-screen instructions to download and install the appropriate version and architecture of endorctl for your system.

Authenticate to Endor Labs

Users can authenticate to Endor Labs several ways:

1. Using the init command
2. With an API token

Login with the init command

To log in with your supported authentication provider:

• Google
• GitHub
• GitLab
• Email
• SSO

endorctl init --auth-mode=google

endorctl init --auth-mode=github

endorctl init --auth-mode=gitlab

endorctl init --auth-email=<insert_email_address>

endorctl init --auth-mode=sso --auth-tenant=<insert-your-tenant>

To log in with your supported authentication provider in environments without a browser you can use headless mode:

• Google
• GitHub
• GitLab
• Email
• SSO

endorctl init --auth-mode=google --headless-mode

endorctl init --auth-mode=github --headless-mode

endorctl init --auth-mode=gitlab --headless-mode

endorctl init --auth-email=<insert_email_address> --headless-mode

endorctl init --auth-mode=sso --auth-tenant=<insert-your-tenant> --headless-mode

Login with an API Key

To log in with an API key you’ll need to set the following environment variables:

• ENDOR_API_CREDENTIALS_KEY - The API key used to authenticate against the Endor Labs API.
• ENDOR_API_CREDENTIALS_SECRET - The API key secret used to authenticate against the Endor Labs API.
• ENDOR_NAMESPACE - The Endor Labs namespace you would like to scan against. You can locate the namespace from the top left hand corner of the screen under the Endor Labs logo on the Endor Labs application.

To get an API Key and secret for use with endorctl, see Managing API Keys.

To set your environment variables run the following commands and replace each example with the appropriate value.

export ENDOR_API_CREDENTIALS_KEY=<example-api-key>
export ENDOR_API_CREDENTIALS_SECRET=<example-api-key-secret>
export ENDOR_NAMESPACE=<example-tenant-namespace>

Once you’ve exported your environment variables you can test successful authentication by running the following command to list projects in your namespace.

endorctl api list -r Project --page-size=1

Print your access token

Once you have successfully initialized endorctl, you can print your access token with the following command.

endorctl auth --print-access-token

The token has an expiration time of 4 hours.

Persistently set environment variables for endorctl

To persistently set an environment variable, append the environment variable and the value to ~/.endorctl/config.yaml. This configuration file is for CLI usage.

For example, if your GitHub Enterprise Server URL was https://api.github.com you can set the variable to persist in your configuration using the following command.

echo "ENDOR_SCAN_SOURCE_GITHUB_API_URL: https://api.github.com" >> ~/.endorctl/config.yaml

See endorctl commands for all supported commands and environment variables.

CI Scans are used to focus team’s attention and establish development workflows on the most actionable issues, prioritizing the development team’s time. CI Scans can be triggered directly from automated CI/CD pipelines, looking for new vulnerabilities relative to the baseline established for the target branch. These CI Scans provide immediate feedback to developers in the form of PR comments and can also enforce policies to break builds, block PRs, send notifications, open tickets, and more. CI scans are the most actionable method to prevent vulnerabilities from entering your repositories.

Perform CI scans using:

• endorctl CLI
• Scan with GitLab pipeline
• Scan with GitHub Actions
• Scan with Circle CI
• Scan with Jenkins
• Scan with Azure DevOps
• Scan with Bitbucket
• Scan with Google Cloud Build

See scanning strategies to learn techniques for effectively scanning and monitoring different versions of your projects with Endor Labs.

endorctl is a command line utility designed to bring the functionality of Endor Labs into your software delivery workflows. endorctl has several command flags to help you facilitate operational and security risk monitoring. Developers can integrate Endor Labs into Continuous Integration Workflows using the endorctl scan.

• endorctl scan - You can use endorctl scan to monitor your projects using Endor Labs, and you can update the scan information each time to keep monitoring the project for new findings. The endorctl scan command will scan a specific version of your repository, such as the default branch, a tagged release version, or a commit SHA.
• endorctl scan --pr - You can use the endorctl scan --pr command to scan a specific version of your source code for security and operational risks as part of your continuous integration workflows or CI runs. The endorctl scan --pr command performs a one-time evaluation of your project, focusing on security and operational risks, rather than providing continuous monitoring. CI runs are shown in the Scan History section of each project and are stored for three weeks so that you can analyze and review them on the Endor Labs user interface. See PR scans for more information.

Any continuous integration workflows generally run using the endorctl scan --pr command unless a scan is run on a created tag release, a push to the default or specific branch, or a commit SHA that will be deployed to production.

Authenticating in CI with Keyless Authentication

Keyless Authentication enhances security and minimizes the expenses associated with secret rotation. Keyless authentication is Endor Labs recommended path to scan your projects in the CI workflows. See Keyless Authentication for more information.

At Endor Labs, we believe that the most secure secret is one that doesn’t exist. That’s why in CI/CD environments we recommend using keyless authentication for machine authentication. Keyless Authentication uses OAuth for API authentication and removes the need to maintain and rotate an API key to Endor Labs.

Keyless Authentication is more secure and reduces the cost of secret rotation.

Configure keyless authentication using:

• Google Cloud
• GitHub OIDC
• AWS Cloud
• Azure

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can use GitHub Actions to include Endor Labs into your CI pipeline seamlessly.

Using this pipeline, developers can view and detect:

• Policy violations in the source code
• Secrets inadvertently included in the source code

The Endor Labs verifications are conducted as automated checks and help you discover violations before pushing code to the repository. Information about the violations can be included as comments on the corresponding pull request (PR). This enables developers to easily identify issues and take remedial measures early in the development life cycle.

• For policy violations, the workflow is designed to either emit a warning or return an error based on your action policy configurations.
• For secrets discovered in the commits, developers can view the PR comments and take necessary remedial measures.

Install Software Prerequisites

To ensure the successful execution of the Endor Labs GitHub action, the following prerequisites must be met:

• The GitHub action must be able to authenticate with the Endor Labs API.
• You must have the value of the Endor Labs namespace handy for authentication.
• You must have access to the Endor Labs API.
• If you use keyless authentication, you must set an authorization policy in Endor Labs. See Authorization policies for details.

Example GitHub Action Workflow

Endor Labs scanning workflow using GitHub Actions that accomplishes the following tasks in your CI environment:

• Tests PRs to the default branch and monitors the most recent push to the default branch.
• Builds a Java project and sets up the Java build tools. If your project is not on Java, then configure this workflow with your project-specific steps and build tools.
• Authenticates to Endor Labs with GitHub Actions keyless authentication.
• Scan with Endor Labs.
• Comments on PRs if any policy violations occur.
• Generates findings and uploads results to GitHub in SARIF format.

The following example workflow shows how to scan with Endor Labs for a Java application using the recommended keyless authentication for GitHub Actions.

name: Endor Labs Dependency and Secrets Scan
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
jobs:
  scan:
    permissions:
      security-events: write # Used to upload Sarif artifact to GitHub
      contents: read # Used to check out a private repository
      actions: read # Required for private repositories to upload Sarif files. GitHub Advanced Security licenses are required.
      id-token: write # Used for keyless authentication with Endor Labs
      pull-requests: write # Required to automatically comment on PRs for new policy violations
    runs-on: ubuntu-latest
    steps:
    - name: Checkout Repository
      uses: actions/checkout@v3
    - name: Setup Java
      uses: actions/setup-java@v3
      with:
        distribution: 'microsoft'
        java-version: '17'
    - name: Build Package
      run: mvn clean install
    - name: Endor Labs Scan Pull Request
      if: github.event_name == 'pull_request'
      uses: endorlabs/github-action@v1 # Replace v1 with the commit SHA of the latest version of the GitHub Action for enhanced security
      with:
        namespace: 'example' # Replace with your Endor Labs tenant namespace
        scan_dependencies: true
        scan_secrets: true
        pr: true
        enable_pr_comments: true # Required to automatically comment on PRs for new policy violations
        github_token: ${{ secrets.GITHUB_TOKEN }} # Required for PR comments on new policy violations

  scan-main:
    permissions:
      id-token: write
      repository-projects: read
      pull-requests: read
      contents: read
    name: endorctl-scan
    runs-on: ubuntu-latest
    steps:
    - name: Checkout Repository
      uses: actions/checkout@v3
    - name: Setup Java
      uses: actions/setup-java@v3
      with:
        distribution: 'microsoft'
        java-version: '17'
    - name: Build Package
      run: mvn clean install
    - name: 'Endor Labs Scan Push to main'
      if: ${{ github.event_name == 'push' }}
      uses: endorlabs/github-action@v1 # Replace v1 with the commit SHA of the latest version of the GitHub Action for enhanced security
      with:
        namespace: 'example' # Replace with your Endor Labs tenant namespace
        scan_dependencies: true
        scan_secrets: true
        pr: false
        scan_summary_output_type: 'table'
        sarif_file: 'findings.sarif'
    - name: Upload findings to github
      uses: github/codeql-action/upload-sarif@v3
      with:
        sarif_file: 'findings.sarif'