The problem

A manifest lists packages. It does not show what they run.

A CI runner holds registry credentials, cloud roles and signing keys, often more privilege than the production workloads it builds. A lockfile or an SBOM records which packages and versions the build uses, not what those packages do once the build runs them. These attacks only show up in what the build executes:

Install-time payloads

An npm package can look clean and still run anything at install or build time. Protet sees the command a postinstall script ran: the download, the pipe into a shell, the write to a cron file.

Hijacked runners

A stolen CI credential is an attacker running commands as your build. There is no dependency to scan and no manifest entry. The only signal is what runs.

Dependency confusion

A public npm package that resolves ahead of your internal one looks like a normal dependency in an SBOM. What it does once installed is where the attack becomes visible.

Protet Intel lists the npm packages Protet has confirmed as malicious. What Protet collects and keeps is on the security page.

Getting started

Three steps

1

Add the Action or the API

Add one step to a GitHub Actions workflow, or send process events from any CI system to the ingest API.

2

Run your build

Your build steps stay as they are. Protet records each command the job starts, with its arguments.

3

Get a result

Every analysed build returns a result, benign or malicious, as an OCSF finding. A build that behaves like a supply-chain attack is flagged as malicious.

The GitHub Action and the cloud path from a build to a verdict are in preview. The Action page states what works today.

Example

A flagged build

The verdict an analyst reads, and the OCSF finding your SIEM receives at the same time. Illustrative and abridged.

ci-build-7f3a · build-runners

malicious

The result

Verdict: malicious. The build behaved like a supply-chain attack.
Build: the job's pod or session name and its namespace.
Delivery: one OCSF finding per analysed build, benign builds included.

OCSF Detection Finding

{
  "class_uid": 2004,
  "class_name": "Detection Finding",
  "category_uid": 2,
  "metadata": { "version": "1.1.0", "product": { "name": "protet" } },
  "finding_info": { "uid": "3f8a1c2e-..." },
  "container": { "pod_name": "ci-build-7f3a" },
  "cloud": { "region": "build-runners" },
  "enrichments": [
    { "name": "finding_kind", "value": "pod" },
    { "name": "verdict", "value": "malicious" },
    { "name": "pod_uid", "value": "3f8a1c2e-..." }
  ]
}

Every field is documented in Integrations.

The product

Collect, detect, deliver, deploy

Collect

Protet records every process a build starts: the executable and its arguments. There are three ways to send them.

GitHub Action. One workflow step. It installs auditd on the runner and records every execve in the job. See the GitHub Action.
Kubernetes sensor. eBPF through Tetragon records process execution at the kernel level, with nothing to add inside the build image.
Ingest API. GitLab, Jenkins, Buildkite or any other system that can send an HTTP request posts the same events. See Integrations.

Source code, build artifacts and build output are not collected.

Detect

Protet checks every build session and flags the ones whose commands behave like a supply-chain attack, for example fetching and running a remote script, reading credentials, or adding persistence. Every analysed build gets a verdict, benign or malicious. Every detection update is regression-tested before release.

Deliver

Each build's result is an OCSF Detection Finding with its verdict, benign or malicious, in an open schema that most SIEMs read. In the cloud, findings stream to your collector, CI job or SIEM relay as they are produced. A self-hosted deployment writes them to a webhook or a log file. The schema is in Integrations.

Deploy

Protet is free and cloud-hosted. The Free plan runs on the hosted service, on Swiss infrastructure. Build activity is held for at most 24 hours and never archived; each build's result is kept for up to 6 hours, then deleted. Details are on the security page.

On-prem and air-gapped deployments are available on request: hello@protet.io.

Start with the free plan

Sign up, mint a token and add the Action to a workflow. No card needed.

Start free Read the quickstart

npm supply-chain attack detection in CI/CD