🚧 Pre-release: Active development. cicd-sensor is currently in pre-release and under active development. Feedback is very welcome.

cicd-sensor logo

cicd-sensor

Think EDR, but for CI/CD Pipelines.
Open-source eBPF-powered runtime security sensor for GitHub Actions and GitLab CI/CD.
→ Full documentation

Demo

_{Example: cicd-sensor added to a GitHub Actions workflow. The resulting reports are viewable in the GitHub job summary.}

What cicd-sensor does

When a compromised dependency in a CI/CD job steals your cloud credentials and leaks them, would you catch it? Would you have the logs to investigate afterward? cicd-sensor is an open-source sensor that lets every team answer both.

Detection: Detects supply-chain attacks at runtime using process ancestry (e.g. credential access from a process descended from npm install) and correlation across signals (e.g. multiple credential categories read in one job). Baseline rules target patterns seen in real CI/CD attacks, and are opt-out: turn them off if you only want the logs and evidence below.

Logs and evidence: Per run, cicd-sensor can emit logs for review, alerting, and forensics, routed through cicd-sensor Manager to cloud sinks like S3, GCS, and Pub/Sub. The cicd-sensor-action can also produce a graphical report and a build attestation per run. Your data stays under your control. cicd-sensor never sends anything to servers operated by the cicd-sensor project.

Quick start

On GitHub-hosted runners, add the cicd-sensor action as the first step in your workflow.

jobs:
  build:
    runs-on: ubuntu-24.04
    steps:
      - uses: cicd-sensor/cicd-sensor-action@6511eb44c91d71b2b93d71193b1bf2cb18352f66 # v0.0.38

For self-hosted GitHub Actions or GitLab CI/CD, see the User Guide.

Why CI/CD runtime needs this

CI/CD pipelines build, release, deploy, and manage cloud infrastructure, and they hold the cloud credentials, signing keys, and registry tokens to do it. Supply-chain attackers run inside those jobs and disappear with the evidence when the job ends.

Most other runtimes have their open-source defenders: Falco, Tetragon, Tracee, Wazuh, OSQuery. Open-source coverage for CI/CD runtime has lagged behind. Sigstore proved where and how artifacts were built; cicd-sensor preserves what actually ran so teams can detect, respond, and audit.

Feature comparison

Capability	cicd-sensor	Harden-Runner (Free)	Comment
Licensing & deployment
Open source	✅ Yes	✅ Yes
Data privacy	✅ Self-hosted	SaaS backend	cicd-sensor runs entirely in your infrastructure, so logs and events stay in your environment.
Platform coverage
Private repos	✅ Yes	❌ No
Self-hosted runners	✅ Yes	❌ No	Enforcing self-hosted runners enables organization-wide log collection across every job.
GitHub Actions support	✅ Yes	✅ Yes
GitLab CI/CD support	✅ Yes	❌ No
Capabilities
Detection rules	✅ Yes	✅ Yes
Flexible custom rules	✅ Yes	🔶 Limited	cicd-sensor rules cover process ancestry, file access, and correlation across signals; Harden-Runner is mainly a network egress allowlist.
Network blocking	🔶 Partial	✅ Yes	cicd-sensor kills the process and stops the job on detection instead of filtering traffic like a firewall.
Log export	✅ Yes	❌ No

_{This table compares the free version of Harden-Runner. StepSecurity's paid platform adds more, such as private repository and self-hosted runner support, dashboards, and policy management.}

_{Based on public information as of May 2026. Corrections welcome.}

Third-party services

Takumi Runner by GMO Flatt Security acts as a hosted cicd-sensor Manager and adds its own threat detection and trace analysis on top of the collected logs. See their integration guide (English / Japanese) for setup. It is a separate commercial product, and cicd-sensor works without it.

_{cicd-sensor is a vendor-neutral open-source project: it works on its own, and any manager it talks to is one you choose to run. Other vendors and services are equally welcome to integrate with cicd-sensor.}

_{When cicd-sensor is pointed at a third-party hosted manager, the logs and events it collects are sent to that vendor's service.}

Supported CI/CD pipelines

Platform	Environment	Status
GitHub Actions	GitHub-hosted runner	✅ Supported
GitHub Actions	Self-hosted runner on a machine	✅ Supported
GitHub Actions	Actions Runner Controller on Kubernetes	🧪 Preview support
GitLab CI/CD	GitLab Runner Docker executor	✅ Supported
GitLab CI/CD	GitLab Runner Kubernetes executor	🧪 Preview support
GitLab CI/CD	GitLab-hosted runner	❌ Not supported (technical constraints)

Works on both public and private repositories, with no third-party SaaS dependency.

Linux kernel: 5.15 or later on amd64, 6.1 or later on arm64.

Rules

cicd-sensor ships with a set of baseline rules. See the Baseline Rules guide for how they work; the rule definitions themselves live in rules/. You can also write your own rules, or turn the baseline off entirely.

Documentation

Getting Started: what cicd-sensor is and how to start.
User Guide: deployment paths for GitHub Actions and GitLab CI/CD.
Rules: write detection, collection, and correlation rules.
Logging: log format delivered by the manager.
Attestation predicate: runtime-trace predicate for CI/CD runtime evidence.
Developer Guide: agent, eBPF runtime, manager, and rule engine internals.

About the project

[!NOTE] About the creator: cicd-sensor is a vendor-neutral open-source project, created and maintained by Hiroki Suezawa (@rung), author of the Common Threat Matrix for CI/CD Pipeline, contributor to the OWASP Top 10 CI/CD Security Risks, and early contributor to OSC&R / pbom.dev. cicd-sensor was started as an individual project to stay close to the open-source community that is on the receiving end of supply-chain attacks.

A read-only official mirror is published at gitlab.com/cicd-sensor/cicd-sensor. GitHub is the canonical source; the GitLab mirror is synced periodically.

License

Apache License 2.0 (LICENSE). BPF source under internal/agent/bpf/ is dual-licensed GPL-2.0-only OR BSD-2-Clause (details).

cicd-sensor vrules/v20260714-002

Categories