GitHub

Connect GitHub to Team Server, place the Sensor on the runner, and bracket each protected GitHub Actions job with Endura commands.

Object Mapping

One repository is one pipeline. Every workflow in it shares one policy, so the policy must permit the valid behavior of all workflows. Team Server must discover the repository before Sensor-reported runs can attach to it.

Prerequisites

• Operator or Administrator access to Team Server
• GitHub organization access that can create an integration token
• Permission to edit protected workflows
• For self-hosted runners, root access to every runner host
• For GitHub-hosted runners, an Endura license and Sensor token stored as Actions secrets

Configure the Integration

Create a Token

Use a dedicated service account with read-only repository and organization access.

For a fine-grained personal access token, grant access to the required organizations and repositories with Actions: Read-only and Metadata: Read-only. For a classic token, use repo for private repositories and read:org.

Set an expiration and rotation owner, then copy the token into your secrets manager.

Add GitHub to Team Server

1. Open Integrations, then GitHub under Discover.
2. Select Get Started or Create.
3. Enter https://github.com or the base URL of GitHub Enterprise Server.
4. Paste the token and select Test.
5. Select the organizations to discover.
6. Select Save.

Repositories from the selected organizations appear under Pipelines. Create a separate integration for each GitHub Enterprise Server or credential boundary.

For a private GitHub Enterprise Server address or internal CA, configure Team Server outbound HTTP policy.

Schedule Discovery

Add these jobs to Team Server’s scheduler.jobs:

discover_github_pipelines:
  run: "discover_github_pipelines"
  schedule: "0 2 * * * * *"
discover_github_builds:
  run: "discover_github_builds"
  schedule: "0 3,18,33,48 * * * * *"

Keep the required calculate_statistics and update_status jobs enabled. Restart Team Server after changing its configuration; see Scheduler.

Choose the Runner Pattern

Self-hosted Runners

Install the Sensor once on every host that can run a protected workflow. Include installation in images or provisioning for ephemeral self-hosted runners. See Runtime Sensor deployment.

Instrument every protected job:

jobs:
  build:
    runs-on: [self-hosted, linux]
    steps:
      - name: Start Endura Job
        run: endura job start

      - uses: actions/checkout@v6
      - name: Build
        run: make build

      - name: Stop Endura Job
        if: always()
        run: endura job stop

The start step must run before build work. if: always() ensures cleanup after failure or cancellation.

GitHub-hosted Runners

GitHub-hosted runners are ephemeral, so install and start the Sensor within the job. Store ENDURA_LICENSE_KEY and ENDURA_SENSOR_TOKEN as repository or organization secrets.

name: CI
on:
  push:
  workflow_dispatch:

env:
  ENDURA_TEAM_SERVER: https://team-server.example.com
  ENDURA_BATCHER_AUTOFLUSH: true

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - name: Start Sensor and Endura Job
        env:
          ENDURA_LICENSE_KEY: ${{ secrets.ENDURA_LICENSE_KEY }}
          ENDURA_SENSOR_TOKEN: ${{ secrets.ENDURA_SENSOR_TOKEN }}
        run: |
          curl -sSf https://repo.endurasecurity.com/install/endura-sensor/testing.sh | sudo -E sh
          sudo -E endura sensor start -d
          endura job start

      - uses: actions/checkout@v6
      - name: Build
        run: make build

      - name: Stop Endura Job and Sensor
        if: always()
        run: |
          endura job stop --exit-zero
          sudo -E endura sensor stop --exit-zero

ENDURA_BATCHER_AUTOFLUSH=true submits telemetry before the runner is destroyed. Give GITHUB_TOKEN only the permissions the build needs.

Container Jobs on Self-hosted Runners

The Sensor remains on the runner host. Mount its socket and install the CLI inside the job container:

jobs:
  build:
    runs-on: [self-hosted, linux]
    container:
      image: node:22
      options: --volume /run/endura/sensor.sock:/run/endura/sensor.sock
    steps:
      - name: Start Endura Job
        run: |
          curl -sSf https://repo.endurasecurity.com/install/endura-sensor/testing.sh | sh
          endura job start

      - uses: actions/checkout@v6
      - run: npm test

      - name: Stop Endura Job
        if: always()
        run: endura job stop

Without the socket mount, the CLI cannot reach the host Sensor.

Multi-job Workflows

Instrument each job that performs protected work. Jobs run in separate runner contexts, but all instrumented jobs in one workflow run report to the same Team Server build. Every job and workflow in the repository shares the repository policy.

Run all jobs and workflow variants while deriving the policy.

Standardize Instrumentation

• Put start and stop logic in centrally maintained composite actions.
• Wrap common build behavior in reusable workflows.
• Publish workflow templates to simplify adoption in new repositories.

Pin reused actions to a full commit SHA. These mechanisms reduce duplication but still require repositories or workflows to adopt the Endura wrapper. GitHub ruleset workflows gate pull-request merges; they do not transparently wrap every job in a repository and are not presented as universal Sensor instrumentation.

Verify

1. Run an instrumented workflow.
2. Open the repository under Pipelines in Team Server.
3. Open Builds and confirm the workflow run appears.
4. If it does not, confirm repository discovery, runner Sensor status, and the start-step log.

Create and Assign a Policy

1. Run representative workflows without an assigned policy to derive behavior.
2. Copy the policy printed by endura job stop.
3. Create a Team Server policy in observe mode.
4. Assign it to the repository pipeline.
5. Refine unexpected violations across several runs, then change it to enforce.

See Security Policies for refinement and enforcement guidance. Configure Slack after violations are reaching Team Server.