io.github.Baneado98/ci-sentinel

Official2 tools

by Baneado98

Multi-CI security scanner with a live threat-intel feed of compromised CI components

Multi-CI security scanner with live threat intelligence on compromised components.

Captured live from the server via tools/list.

audit_ci_security

Audit GitHub Actions, GitLab CI/CD, Jenkins, CircleCI, Azure Pipelines, Bitbucket Pipelines AND Travis CI for security flaws BEFORE you merge or trust them — SEVEN CI ecosystems in one tool. Give it your CI config — the contents of .github/workflows/*.yml, your .gitlab-ci.yml, your Jenkinsfile, your .circleci/config.yml, your azure-pipelines.yml, your bitbucket-pipelines.yml and/or your .travis.yml (it auto-detects which CI system each file is) — and it returns a CRITICAL / VULNERABLE / RISKY / HARDENED verdict. GitHub Actions: script/expression INJECTION (attacker-controlled ${{ github.event.* }} — issue/PR title, body, comment, branch name, commit message, label name, fork repo identity — into run: or actions/github-script), following taint ACROSS steps.<id>.outputs.*, needs.<job>.outputs.*, env vars, matrix values, reusable-workflow inputs.* and composite-action interiors; pull_request_target / workflow_run 'pwn requests'; reusable-workflow misuse (untrusted data over workflow_call, 'secrets: inherit'); excessive GITHUB_TOKEN permissions; unpinned third-party actions incl. transitive supply chain (tj-actions/CVE-2025-30066 class); self-hosted-runner RCE; OIDC/id-token misuse; broken if: gates. GitLab CI/CD: injection from untrusted CI variables (CI_COMMIT_REF_NAME/BRANCH/TAG, CI_MERGE_REQUEST_TITLE/DESCRIPTION/SOURCE_BRANCH_NAME, commit message/author) interpolated into script:, following taint through variables: and extends: templates AND through remote/project include: files (cross-file, the included file's sinks are resolved & analyzed); secrets / broad CI_JOB_TOKEN / id_tokens (OIDC) exposed to fork merge-request pipelines; include: from untrusted remote/foreign-project sources not pinned to a SHA; rules/only/except that let a fork MR run privileged jobs without a manual gate; and artifact/cache POISONING where an untrusted job feeds bytes a privileged downstream job executes (cross-job & cross-pipeline). Jenkins (declarative + scripted Jenkinsfile): command INJECTION from untrusted input (build params.*, multibranch env.CHANGE_*/BRANCH_NAME, the GitHub PR-builder ghprb* vars like ghprbCommentBody, SCM commit data) interpolated into a sh/bat/powershell GString — following taint through pipeline/stage environment{} bindings; credential exposure (a credentials()/withCredentials secret printed with echo or baked into a shell GString, defeating log masking); Groovy evaluate()/Eval/load over untrusted input (sandbox bypass / RCE); approval-bypass (a privileged deploy/publish step reachable from a PR/comment build with no input() gate); and unsafe 'agent any' running untrusted PR code on a privileged executor. CircleCI (.circleci/config.yml): shell INJECTION from untrusted pipeline values (<< pipeline.git.branch >> / << pipeline.git.tag >> the attacker names, or a pipeline parameter set by an API/PR trigger) interpolated into a run: command; UNPINNED ORBS on a mutable version (@volatile / a bare major / dev: tag = supply-chain, the orb runs in your pipeline with your contexts); CROSS-FILE ORB INJECTION — an untrusted value passed to an orb-command parameter that the published orb's OWN source pipes into an internal run: sink (the orb's interior is resolved & analyzed, a flow a single-file scan can't see); fork-PR CONTEXT SECRET exposure (a job attaching an org context reachable from forked-PR builds without a type: approval gate); and missing approval gate before a privileged deploy job. Azure Pipelines (azure-pipelines.yml): macro INJECTION from untrusted predefined variables ($(Build.SourceBranch)/$(Build.SourceBranchName) the attacker names, $(System.PullRequest.SourceBranch) on fork PRs, $(Build.SourceVersionMessage) commit message) substituted into script:/bash:/pwsh: text, following taint through variables: bindings; UNTRUSTED TEMPLATES pulled from a foreign repository resource (runs in your pipeline with your secrets); CROSS-FILE TEMPLATE INJECTION — an untrusted value passed as a template parameter that the foreign template's OWN body pipes into an internal script:/bash: sink (the template interior is resolved &

Parameters (4)

filesobject
Map of filename -> content, e.g. { ".github/workflows/ci.yml": "name: CI\non: ...", ".gitlab-ci.yml": "stages: ...", "Jenkinsfile": "pipeline { ... }", ".circleci/config.yml": "version: 2.1\n...", "azure-pipelines.yml": "pool: ...", "bitbucket-pipelines.yml": "pipelines: ...", ".travis.yml": "language: ..." }. Mix GitHub Actions, GitLab CI, Jenkins, CircleCI, Azure Pipelines, Bitbucket Pipelines and Travis CI files freely — each is routed to the right analyzer by its name/shape. Audit a whole repo's CI at once.
sourcestring
A single CI file's content (a GitHub Actions workflow, a .gitlab-ci.yml, a Jenkinsfile, a .circleci/config.yml, an azure-pipelines.yml, a bitbucket-pipelines.yml, a .travis.yml, or an IaC OIDC trust policy .tf/.json; auto-detected). Use instead of 'files' for one file.
sharedLibYmlsobject
OPTIONAL (Jenkins): bodies of shared-library global vars keyed by the var NAME (the vars/<name>.groovy basename), e.g. { "deployTo": "def call(Map config){ sh \"... ${config.target}\" }" }. Lets the deep audit taint an untrusted pipeline value THROUGH a @Library step into the library's internal sh sink (cross-file). There is no public registry for shared libs, so supply the bodies here.
deepboolean
When true, runs the PREMIUM deep audit: every finding with file:line, the full injection taint path, the transitive action supply-chain graph and concrete remediation. Requires an API key (set CI_SENTINEL_KEY in your MCP env); without one you'll get unlock instructions. The free quick verdict needs no key.

diff_ci_security

DIFFERENTIAL CI/CD security check for a workflow/pipeline CHANGE — the tool a PR gate needs. Give it the BEFORE and AFTER state of your CI config (e.g. a pull request that edits .github/workflows/*.yml, .gitlab-ci.yml, a Jenkinsfile, .circleci/config.yml, azure-pipelines.yml, bitbucket-pipelines.yml, .travis.yml or an IaC OIDC trust policy) and it reports exactly which security findings the change INTRODUCES, REMOVES or AGGRAVATES, plus a single verdict: INTRODUCES_RISK (block the change), REDUCES_RISK (the change hardens CI) or NEUTRAL. It runs the full 7-ecosystem deep engine on both states and reconciles the two finding sets by a LINE-INDEPENDENT identity, so an edit that merely shifts line numbers does NOT look like it introduced/removed a flaw — only a REAL security change shows up. For every introduced finding you get the file:line, the taint path and the concrete fix to undo the risk; for removed ones you see what the change fixed. This is the answer your own agent can't compute by reading the after-state alone: it has no principled BEFORE→AFTER security delta. Use it on every PR that touches CI config — wire INTRODUCES_RISK to a failing status check. Provide each side as { files: {name: yaml} } (or { source } for one file). Premium: requires an API key (set CI_SENTINEL_KEY) or pays per call via x402. Heuristic static analysis, not a guarantee.

Parameters (2)

beforeobjectrequired
The BEFORE state of the CI config (the base / target branch). Same shape as audit input: { files: {filename: yaml}, ... } or { source: "..." }. May also carry actionYmls/includeYmls/orbYmls/templateYmls/sharedLibYmls for cross-file resolution.
afterobjectrequired
The AFTER state of the CI config (the PR / head branch). Same shape as 'before'.

README.md15 KBView on GitHub

ci-sentinel 🛡️

Security auditor for SEVEN CI ecosystems — GitHub Actions, GitLab CI/CD, Jenkins, CircleCI, Azure Pipelines, Bitbucket Pipelines and Travis CI — finds the supply-chain and injection flaws a YAML linter can't see, before an attacker's pull/merge request runs code with your repository secrets.

Available as an MCP server (for Claude / Cursor / any agent) and a pay-per-call HTTP API (x402 USDC or a prepaid card key).

Give it your .github/workflows/*.yml, .gitlab-ci.yml, Jenkinsfile, .circleci/config.yml, azure-pipelines.yml, bitbucket-pipelines.yml and/or .travis.yml (each file is auto-routed to the right analyzer) and get a CRITICAL / VULNERABLE / RISKY / HARDENED verdict with the exact flaws.

What it catches that a linter can't

Class	What ci-sentinel does
💉 Expression injection (inter-step / inter-job taint)	Taints untrusted `${{ github.event.* }}` (issue/PR title, body, comment, review, branch name, commit message, label name, fork repo identity, edited-from values) to a `run:` shell or `actions/github-script` sink — and *follows it across `steps.<id>.outputs.`, `needs.<job>.outputs.`, `env:` vars, `matrix` values and reusable-workflow `inputs.`**. An attacker who hides the untrusted value behind an intermediate output is still caught; a per-file grep is not.
🎭 Pwn requests	`pull_request_target` / `workflow_run` that check out untrusted fork code in the privileged, secret-bearing context = arbitrary code execution with your secrets.
🔑 Token permissions	Excessive `GITHUB_TOKEN` scopes (`write-all`, `contents:write`, `id-token:write`), missing `permissions:` blocks, and secrets exposed to untrusted triggers.
🔁 Reusable workflows	`workflow_call` callers passing untrusted data across the boundary as `inputs.`, and `secrets: inherit`* handing the full secret set to a reusable workflow on an untrusted trigger.
📌 Action pinning	Third-party actions (and reusable-workflow `uses:`) on mutable tags/branches instead of a commit SHA (the `tj-actions/changed-files`-style hijack), resolved through the transitive action graph.
🖥️ Self-hosted RCE	Self-hosted runners reachable from public-repo PRs (RCE on your own infra), and OIDC `id-token` trust misuse.

…and the same depth for GitLab CI/CD (`.gitlab-ci.yml`)

Class	What ci-sentinel does
💉 CI-variable injection	Taints untrusted GitLab variables (`CI_COMMIT_REF_NAME/BRANCH/TAG`, `CI_MERGE_REQUEST_TITLE/DESCRIPTION/SOURCE_BRANCH_NAME`, commit message/author, triggering-user fields) interpolated into `script:` — following the taint through `variables:` and `extends:` templates. Knows the SAFE vars (`CI_COMMIT_SHA`, `CI_MERGE_REQUEST_IID`, `CI_PROJECT_ID`, …) so it doesn't flag every `$CI_`.
🎭 Fork merge-request pwn	Jobs reachable from fork MR pipelines (`merge_request_event`, `only: merge_requests`) that carry secrets / a broad `CI_JOB_TOKEN` / `id_tokens` (OIDC), or that run privileged work (deploy/publish/`kubectl`/`terraform`) with no `when: manual` gate.
📦 `include:` supply-chain	`include:` from a remote URL or another project/component on a moving (non-SHA) ref — foreign pipeline code merged into yours.
☣️ Artifact / cache poisoning	An untrusted job writes an artifact/cache that a privileged downstream job consumes and executes (`needs:`/`dependencies:` or a shared cache path) — a cross-job and cross-pipeline escalation.

…and five more CI systems, same taint model

Ecosystem	What ci-sentinel catches
🔧 Jenkins (`Jenkinsfile`)	Command injection from `params.` / `env.CHANGE_` / `ghprb*` / SCM data into `sh`/`bat`/`powershell` (through `environment{}` bindings); credential-leak (`credentials()`/`withCredentials` printed or baked into a GString); Groovy `evaluate()`/`load` RCE; missing `input()` approval gate; unsafe `agent any`.
⭕ CircleCI (`.circleci/config.yml`)	Shell injection from `<< pipeline.git.branch/tag >>` / pipeline parameters into `run:`; unpinned orbs (`@volatile` / bare major); fork-PR context secret exposure with no `type: approval` gate; privileged deploy with no approval.
🟦 Azure Pipelines (`azure-pipelines.yml`)	Macro injection from `$(Build.SourceBranch)` / `$(System.PullRequest.SourceBranch)` / commit message into `script:`/`bash:`/`pwsh:`; untrusted templates from a foreign repo resource; fork variable-group secret exposure; unpinned repository resources.
🪣 Bitbucket Pipelines (`bitbucket-pipelines.yml`)	Shell injection from `$BITBUCKET_BRANCH` / `$BITBUCKET_TAG` / `$BITBUCKET_PR_DESTINATION_BRANCH` / commit message expanded unquoted into `script:`; secured/deployment-variable exposure on externally-triggerable PR pipelines; unpinned pipes (`:latest`); deployments with no `trigger: manual` gate.
🚦 Travis CI (`.travis.yml`)	Shell injection from `$TRAVIS_BRANCH` / `$TRAVIS_PULL_REQUEST_BRANCH` / `$TRAVIS_COMMIT_MESSAGE` expanded unquoted into a lifecycle hook; secure-env PR/fork secret exposure; `deploy:` stages with no `on:` branch/condition gate.

…plus two deep cross-domain detectors a one-shot agent can't replicate

Detector What ci-sentinel catches

☁️ OIDC cloud-trust misconfiguration (Terraform / CloudFormation / GCP workload-identity / Azure federated-credential) Models the cloud half of CI OIDC: the trust policy of the IAM role / WIF pool / federated app. Flags a sub condition with a broad wildcard (repo:org/*, repo:*), no sub condition at all (any workflow on the issuer assumes the role), a repo pinned but ref/environment unpinned (any branch assumes), the bare pull_request subject (fork-reachable), or an unpinned aud. Then correlates the IaC trust with the CI side (a workflow that mints id-token reachable from an untrusted trigger) and escalates to critical when the chain is reachable end-to-end. No single-file linter catches this — it spans the CI claim and the cloud trust policy.

🔧 Jenkins shared libraries (@Library → vars/*.groovy) Taints an untrusted pipeline value (PR title / branch / build parameter) passed to a shared-library global-var step through the library's call() interior to an internal sh/bat sink — the Jenkins parity of orb/template/composite-action cross-file taint, invisible when reading only the Jenkinsfile. Also flags @Library imports on a mutable ref (a branch / default version) as supply-chain risk.

Each analyzer knows the SAFE variables (SHAs, numeric ids, trusted slugs — BITBUCKET_COMMIT, TRAVIS_PULL_REQUEST, pipeline.git.revision, …) and the SAFE OIDC trusts (sub pinned to repo:org/repo:ref:refs/heads/main / :environment:prod with aud set) so it doesn't flag every $VAR or every trust. Zero false positives on hardened configs.

It is a real static analyzer: a line-aware workflow YAML parser → a model of triggers/jobs/steps/permissions/actions/outputs/needs → an inter-step/inter-job taint resolver + permission + supply-chain detectors → a scored verdict with per-finding file:line, the full taint path, concrete remediation, and a SARIF 2.1.0 report (with codeFlows) you can upload to GitHub code scanning.

…and it doesn't just flag — it FIXES, and it GRADES

Premium	What you get
🔧 Auto-remediation (the exact fix)	For each finding ci-sentinel produces the concrete change: the corrected YAML/Groovy snippet and a unified diff you can apply — pin the action/orb/pipe to an immutable SHA/version, env-bind + quote the injected expression, drop write-all to least privilege, insert the manual/approval gate, pin the OIDC `sub`/`aud`, move the hardcoded secret to the store (and rotate it). Not "you have a bug" but "change THIS to THIS", with a confidence label (`exact` / `template` / `guided`) so you know what's drop-in vs. what needs a value filled. Findings carry a stable `fingerprint` for de-duplication, and the SARIF results carry inline `fixes`.
📋 Compliance scorecard (A–F)	A CIS-like CI security benchmark scored A–F with a PASS / FAIL / WARN / N/A breakdown per control (least privilege, component pinning, no secrets to forks, no self-hosted on public PRs, OIDC pinned, no hardcoded secrets, no pwn checkout, gated deploys, no injection, no cross-job poisoning). Each control lists the finding ids that drove its verdict — defensible to a security team. A directly-exploitable critical flaw caps the grade (one open RCE/secret-exfil path dominates the posture).
🛰️ Live threat-intelligence feed (the data moat)	Every `uses:` / orb / pipe in your config is checked against a live, server-side feed of KNOWN-compromised CI components, ingested on a cron from public sources — OSV.dev and the GitHub Security Advisory database (`ecosystem=actions`) — and merged onto a curated seed of the flagship incidents (`tj-actions/changed-files` CVE-2025-30066, `reviewdog/action-setup` CVE-2025-30154 and its transitive dependents, the `aquasecurity/trivy-action` tag force-push, Ultralytics). It knows that `tj-actions/changed-files@v45` is poison and that the same action SHA-pinned to a clean commit or upgraded to `@v46` is safe — a distinction a static YAML scan or a local linter cannot make, because it has no feed. The feed lives only on the hosted server (the thin client never carries it); `GET /feed/status` surfaces its freshness. A live reputation signal (stars / last-commit / archived / does-the-repo-still-resolve) additionally flags archived/abandoned components and dangling references that are takeover-bait. This is the access-moat that justifies the hosted, paid model: the value is the live DATA, not the compute.
🪤 Tag-rewrite & imposter detection (live ref→commit)	Give ci-sentinel the commit SHA you expected a mutable ref to be (from your lockfile/SBOM) and it resolves what the tag currently points at upstream — flagging a tag-rewrite / force-push (`@v2` now runs a different commit than you reviewed — the exact tj-actions attack), a deleted/dangling ref, or a suspiciously recent move. It also pairs typosquat detection with the live reputation signal to confirm impersonation — `actons/checkout` (a near-miss of `actions`) whose repo is a freshly-stood-up, low-star or dangling imposter — vs. a legitimately-named small fork (no false positive). And because the feed is keyed by component identity, a compromised action is caught no matter which CI system references it (cross-CI) — the piece a mono-CI scanner structurally can't have.

MCP server (free)

json

{
  "mcpServers": {
    "ci-sentinel": { "command": "npx", "args": ["-y", "ci-sentinel-mcp"] }
  }
}

Tool: audit_ci_security. Pass files (a map of workflow filename → YAML) or source (one workflow). The free tier returns the verdict and how many issues of each kind were found.

Deep audit (`deep: true`) — two ways to pay

The deep audit returns every finding with file:line, the full inter-step/ inter-job injection taint path, the transitive action supply-chain graph, a concrete fix (corrected snippet + unified diff) per finding, an A–F compliance scorecard with a per-control breakdown, and a SARIF 2.1.0 document with inline fixes (uploadable to GitHub code scanning via github/codeql-action/upload-sarif).

💳 Card (Stripe) — buy a prepaid key at https://ci-sentinel.vercel.app/pro/checkout, then set "env": { "CI_SENTINEL_KEY": "<key>" } in your MCP config.
🪙 x402 (USDC) — AI agents pay per call automatically (USDC on Base), no signup.

HTTP API

code

POST /audit          # free, rate-limited — verdict + per-severity counts
POST /pro/audit      # deep — pay-per-call (x402) or Authorization: Bearer <key>
POST /mcp            # MCP-over-HTTP (free)
GET  /presence       # live active sessions (last 5 min)
GET  /                # this landing page

bash

curl -X POST https://ci-sentinel.vercel.app/audit \
  -H 'Content-Type: application/json' \
  -d '{"files":{".github/workflows/ci.yml":"name: CI\non: pull_request_target\n..."}}'

Why hosted? (the moat)

The npm package is a thin client: it runs no analysis locally. The parser, taint engine, action-graph resolver and detector knowledge base run server-side only, behind the paywall — so the premium material (findings, evidence, taint paths, remediation) never lands on the caller's machine. A npm pack ships only dist/mcp.js, dist/mcpServer.js and dist/types.js; the engine is never in the tarball (verified automatically by npm run test:moat).

How the live feed stays live (the update pipeline)

The threat-intelligence feed is ingested, not hard-coded. A periodic job runs server-side:

Fetch advisories from two public sources (no paid keys):
- GitHub Security Advisory DB — GET /advisories?ecosystem=actions (public; GITHUB_TOKEN only raises the rate limit, it is not required).
- OSV.dev — the GitHub Actions ecosystem, queried for the components we already track plus everything GHSA just surfaced (so OSV enriches them).
Normalize each advisory into a ThreatRecord — owner/name split, incident class inferred from the advisory text (tag-rewrite / maintainer-compromise / malicious / CVE…), severity bucketed, the affected version range parsed into a selector, the fixed version captured (so an upgraded pin does not fire).
Merge the rows onto the curated seed (ingestFeed: union refs, keep the worst severity, widen the affected range, de-dup by identity).
Store the snapshot in Cloudflare KV. Every /pro/audit reads it back via kvFeedProvider, falling back to the compiled seed if KV is cold — so the detector is never blocked and never worse than the static baseline.

bash

# run the refresh once (live: hits the real public APIs)
node scripts/refreshFeed.mjs
# dry run with no network (produces the seed-only snapshot)
CI_SENTINEL_NO_NET=1 node scripts/refreshFeed.mjs

Schedule it with Vercel Cron ({ "path": "/internal/refresh-feed", "schedule": "0 */6 * * *" }, guarded by FEED_REFRESH_TOKEN) or a scheduled GitHub Action that runs node scripts/refreshFeed.mjs. GET /feed/status reports the live snapshot's version, generatedAt and record count — the public freshness proof. None of this ships in the npm client.

Development

bash

npm install
npm run build          # tsc
npm test               # engine + parser + taint + SARIF + autofix + compliance + corpus tests (851 checks)
npm run test:moat      # lock-proof: tarball ships no engine, deep degrades w/o pay
npm run dev:http       # local HTTP server (FORCE_LISTEN)

Heuristic static analysis of the workflow YAML you provide — it cannot see repo-level default token permissions, branch protections or org policy, and does not execute the pipeline. Treat findings as leads to verify.

Source & docs: https://github.com/Baneado98/ci-sentinel · MIT

Install

claude_desktop_config.json

{
  "mcpServers": {
    "ci-sentinel": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://ci-sentinel.vercel.app/mcp"
      ]
    }
  }
}

Desktop config is stdio-only; this bridges via mcp-remote. Native remote: Settings > Connectors.

audit_ci_security

diff_ci_security

ci-sentinel 🛡️

What it catches that a linter can't

…and the same depth for GitLab CI/CD (.gitlab-ci.yml)

…and five more CI systems, same taint model

…plus two deep cross-domain detectors a one-shot agent can't replicate

…and it doesn't just flag — it FIXES, and it GRADES

MCP server (free)

Deep audit (deep: true) — two ways to pay

HTTP API

Why hosted? (the moat)

How the live feed stays live (the update pipeline)

Development

Install

…and the same depth for GitLab CI/CD (`.gitlab-ci.yml`)

Deep audit (`deep: true`) — two ways to pay