cicd-sensor: eBPF Runtime Security for CI/CD Pipelines
cicd-sensor is an open-source, eBPF-powered runtime security sensor ("EDR for CI/CD") for GitHub Actions and GitLab CI/CD that detects supply-chain attacks in-flight by watching process ancestry (e.g. credential access spawned from an npm install) and correlating signals across a job. It emits per-run logs, graphical reports, and build attestations routed to a self-hosted Manager and cloud sinks (S3, GCS, Azure Blob, Pub/Sub), positioning itself as the vendor-neutral open counterpart to commercial offerings like StepSecurity's Harden-Runner and GMO Flatt Security's Takumi Runner. Created by Hiroki Suezawa (@rung), author of the Common Threat Matrix for CI/CD Pipeline and an OWASP Top 10 CI/CD Security Risks contributor.
What it is
cicd-sensor is an open-source, eBPF-powered runtime security sensor for GitHub Actions and GitLab CI/CD, created and maintained by Hiroki Suezawa (@rung), author of the Common Threat Matrix for CI/CD Pipeline. It is pre-release and under active development — the key fact the summary omits, and the one that decides whether you deploy it in production now or only trial it.
How it works
Detection rules watch process ancestry (e.g. credential access from a process descended from npm install) and correlate signals across a job (e.g. multiple credential categories read in one run). It ships with baseline rules that are opt-out — you can disable them and keep only the collected logs and evidence, or write your own. Rule definitions live in rules/. Logs are routed through a separate cicd-sensor Manager component to cloud sinks (S3, GCS, Pub/Sub); the action can also emit a graphical report and a build attestation per run.
Preconditions / Affected
- Linux kernel 5.15+ on amd64, 6.1+ on arm64.
- Works on public and private repositories, no third-party SaaS dependency.
- Self-hosted GitHub Actions or GitLab CI/CD require following the User Guide (the one-line install below is GitHub-hosted only).
What to do
On GitHub-hosted runners, add the action as the first step in the workflow:
jobs:
build:
runs-on: ubuntu-24.04
steps:
- uses: cicd-sensor/cicd-sensor-action@6511eb44c91d71b2b93d71193b1bf2cb18352f66 # v0.0.38Caveats
The project itself never sends data to servers it operates — but the trust boundary shifts if you point it at a third-party hosted manager. Takumi Runner by GMO Flatt Security is one such commercial hosted Manager; when configured, your logs and events go to that vendor.
flowchart TD
A[cicd-sensor in job] --> B{Manager destination?}
B -->|self-run S3/GCS/Pub-Sub| C[Data stays under your control]
B -->|third-party hosted e.g. Takumi Runner| D[Logs sent to vendor service]The Harden-Runner comparison on the page covers only StepSecurity's free tier; their paid platform adds private-repo/self-hosted support, dashboards, and policy management, so it is not a like-for-like feature comparison. Comparison data is stated as accurate "as of May 2026."
Organisations named here
- Common Threat Matrix for CI/CD Pipeline
- GMO Flatt Security
- Hiroki Suezawa
Technologies named here
- cicd-sensor
- GitHub Actions
- cicd-sensor-action
- GitLab CI/CD
- Linux kernel
- cicd-sensor Manager
- Falco
- Tetragon
- Tracee
- Wazuh
- osquery
- Sigstore
- Harden-Runner
- StepSecurity
- Takumi Runner
- GitLab CI
- eBPF
- OWASP Top 10 CI/CD Security Risks
Techniques named here
- Detection via process ancestry analysis
- Detection via correlation across signals
Related in DevSecOps
JFrog: The Governance Gap Between Your Policy and Your Pipeline

Dev Machine Guard Now Supports Windows - StepSecurity

Socket: TanStack npm Packages Compromised
