New: Major version 1.0 officially released
New: Major version 1.0 officially released
New: Major version 1.0 officially released
New: Major version 1.0 officially released
New: Major version 1.0 officially released
Connect your CI/CD environment, deploy Runtime Sensor, discover your pipeline in Team Server, and establish the baseline needed to move from visibility to enforcement.
September 9, 2026
8 Min Reads
Endura Security
Connect your CI/CD environment, deploy Runtime Sensor, discover your pipeline in Team Server, and establish the baseline needed to move from visibility to enforcement.
Modern CI/CD pipelines execute a surprising amount of code.
A single build may download dependencies, run package lifecycle scripts, invoke compilers, execute tests, create artifacts, access credentials, modify files, and connect to external services. Much of that activity comes from dependencies and tooling your team did not write.
That is where Endura starts.
Rather than asking you to define every permitted action before deployment, Endura can first observe a real build and show you what actually happens while it runs.
For your first deployment, the goal is simple:
We will use GitHub Actions throughout this walkthrough, but the same model applies to other supported CI/CD platforms.
You do not need to roll Endura out across your entire CI/CD environment on day one.
Start with one repository.
Choose something active enough to produce a representative build and important enough that protecting it matters. A production application, internal service, or frequently released package is usually a better candidate than a simple test repository.
Your first deployment should answer a few basic questions:
Once those pieces are working, the same pattern can be repeated across additional repositories and teams.
Before connecting GitHub, it helps to understand how Endura represents CI/CD activity.
For GitHub Actions:
Repository = Pipeline
Workflow Run = Build
If a repository contains several workflows, they still belong to the same Endura pipeline. Individual workflow runs appear as builds associated with that pipeline.
This distinction matters because pipeline discovery and runtime observation happen through different parts of Endura. Team Server discovers the repository through the GitHub integration. Runtime Sensor observes the workflow while it executes. Team Server then brings those two pieces together.
Because of that, the cleanest setup order is:
Team Server is the central management layer for Endura.
It gives you one place to work with pipelines, builds, Runtime Sensors, policies, violations, integrations, and user access.
Start by adding GitHub as a discovery integration.
For production use, we recommend using a dedicated service account rather than an individual administrator account. Grant only the permissions needed for the repositories and organizations you want Endura to discover.
In Team Server:
Once connected, Team Server can discover repositories from the organizations you selected. Those repositories appear in the Pipelines view. At this point, Endura knows what exists in your CI/CD environment. The next step is to see what those pipelines actually do.
Runtime Sensor provides the runtime visibility behind Endura. It runs on Linux and observes security-relevant activity from the kernel while your build executes. The deployment approach depends on the type of GitHub runner you use.
For self-hosted runners, install Runtime Sensor on each runner host you want to protect. The Sensor remains available on the runner and waits for an instrumented build to begin. Configure the Sensor with the information required to connect to Team Server, including the appropriate Endura license and Sensor credentials. If you operate an autoscaling runner environment, include Runtime Sensor installation and configuration in your runner provisioning process. The goal is straightforward: any runner that can execute a protected build should have Runtime Sensor available.
GitHub-hosted runners are temporary, so Runtime Sensor must be installed as part of the workflow. The workflow installs and starts Runtime Sensor before the protected build steps execute, then shuts it down before the runner is destroyed. Keep Endura credentials in GitHub Actions secrets rather than embedding them directly in workflow files.
Once Runtime Sensor is available, tell Endura when the protected portion of the workflow begins and ends.
For a self-hosted runner, the basic structure looks like this:
jobs:
build:
runs-on: [self-hosted, linux]
steps:
- name: Start Endura Job
run: endura job start
- uses: actions/checkout@v4
- name: Build
run: make build
- name: Stop Endura Job
if: always()
run: endura job stop
Your existing build logic does not need to change.
The Endura commands simply establish the boundary around the work Runtime Sensor should associate with that build. There are two important details here.
First, start the Endura job before the build activity you want to observe.
Second, make sure the stop step uses:
if: always()
Builds fail. Tests fail. Workflows get cancelled.
The Endura stop step should still run so the observed build can be completed properly. For GitHub-hosted runners, the workflow follows the same basic pattern, but also includes the steps required to install and start Runtime Sensor.
Now run the pipeline normally. Avoid creating a special workflow that exists only to demonstrate Endura. The most useful baseline comes from a real build executing the same steps your software normally requires.
That may include:
If your workflow contains multiple jobs that perform meaningful build activity, instrument the jobs that you want Endura to observe. The goal is to capture representative behavior, not artificial behavior designed around the security tool.
After the workflow finishes, return to Team Server. Open Pipelines, locate the repository you connected, and view its builds. The workflow run should now appear as a build associated with that pipeline. At this point, you have confirmed the complete flow:
This is the first major milestone. You are no longer looking only at repository metadata or workflow configuration. You now have visibility into what happened while the build actually ran.
With the build visible in Team Server, Endura can begin establishing a baseline from its actual runtime behavior. When Runtime Sensor observes a build in derive mode, Endura records the activity it sees and uses that behavior as the starting point for a security policy.
That activity may include:
This is an important part of the Endura model. You do not have to sit down before deployment and manually guess every file, process, host, and resource a complex build might need. You can start with evidence. Run the software. Observe what it does. Use that behavior as the foundation for the security boundary.
A few choices can make the first deployment much more useful.
Team Server discovers pipelines through the GitHub integration. Runtime Sensor reports builds. Connect the integration first so Team Server already knows which pipeline the build belongs to.
A tiny demonstration repository can prove connectivity, but it will not tell you much about your real software delivery environment. Choose a pipeline with meaningful build activity.
Make sure the execution includes the build, test, packaging, or other stages that represent normal pipeline behavior. If those stages behave differently, the baseline should include them.
Treat Endura license information and Sensor credentials like any other CI/CD secret. Store them in GitHub Actions secrets or your existing secrets-management system. Do not commit them to the repository.
Use if: always() on the stop step so Endura can complete the build even when earlier workflow steps fail.
Once the first pipeline is working, the process becomes repeatable. For larger GitHub environments, you do not need to manually copy Endura configuration into every repository forever. GitHub features such as reusable workflows, composite actions, starter workflows, and organization-level standards can help centralize the integration pattern. That lets teams adopt Endura without turning each repository into a separate implementation project. Start with one pipeline, validate the workflow, standardize the pattern, then expand coverage.
At this point, Endura has shown you what the build did. That is not quite the same as deciding what the build should be allowed to do. A derived baseline may contain behavior that happened only once. It may be missing legitimate activity that was not exercised during the initial build. It may also include activity that occurred during the build but does not belong in the final security policy. The next step is to review that behavior, refine the policy, validate it safely, and prepare the pipeline for enforcement.
That is the focus of our next article: From Runtime Behavior to Enforced Policy
We will take the baseline produced by Runtime Sensor and walk through the process of turning observed behavior into a practical least-privilege policy. Because visibility is only the beginning. The goal is to define what your build is allowed to do, then stop everything outside that boundary.
Ready to put this into practice?
