ci-sentinel

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..outputs., needs..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 & analyzed); fork variable-GROUP / secret exposure on PR-triggered pipelines; and unpinned repository resources on moving refs. Bitbucket Pipelines (bitbucket-pipelines.yml): shell INJECTION from attacker-named variables ($BITBUCKET_BRANCH / $BITBUCKET_TAG / $BITBUCKET_PR_DESTINATION_BRANCH, or a crafted commit message) expanded unquoted into a script: line in a default/pull-requests pipeline; SECURED / deployment-variable fork exposure (a PR pipeline reachable from external contributors that reads repository/deployment secrets); UNPINNED PIPES (a pipe: on :latest / a floating tag = supply-chain, the pipe runs in your step with your secrets); and ungated DEPLOYMENTS (a deployment: step with no trigger: manual reachable from PR/branch). Travis CI (.travis.yml): shell INJECTION from attacker-named TRAVIS_* variables ($TRAVIS_BRANCH / $TRAVIS_PULL_REQUEST_BRANCH / $TRAVIS_TAG / $TRAVIS_COMMIT_MESSAGE) expanded unquoted into a lifecycle hook (before_script/script/after_*); secure-env PR exposure (encrypted secure: vars present on a PR-buildable config that can leak to same-repo branch PRs / opted-in forks); and ungated DEPLOYS (a deploy: with no on: branch/condition gate that fires on any ref). HARDCODED SECRETS (all seven ecosystems): credentials committed verbatim in any CI config — AWS access key ids (AKIA/ASIA), GitHub tokens (ghp_/gho_/ghs_/github_pat_), GitLab/npm/Slack/Google/Stripe keys, PEM private keys, and generic high-entropy secrets assigned to secret-shaped keys — while correctly suppressing the SAFE indirect references (${{ secrets.X }}, $VAR, << pipeline... >>, $(Var), credentials('id'), Key Vault / vault refs) so you get the real leaks with zero false positives; evidence is redacted so the report never re-leaks the credential. OIDC CLOUD-TRUST MISCONFIGURATION (cross-domain, IaC): include your Terraform / CloudFormation / GCP workload-identity / Azure federated-credential and ci-sentinel models the CLOUD side of OIDC — the trust policy of the IAM role / pool / app that backs CI — and flags the catastrophic-but-common misconfigurations: a sub condition with a broad wildcard (repo:org/, repo:), NO sub condition at all (any workflow on the issuer can assume the role), a repo pinned but ref/environment UNpinned (any branch can assume), the bare pull_request subject (fork-reachable), or an unpinned aud. It then CORRELATES the IaC trust condition 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 — a flow no single-file CI linter catches because it spans the CI claim and the cloud trust policy. JENKINS SHARED LIBRARIES (@Library, cross-file): provide the library's vars/.groovy bodies (sharedLibYmls) and ci-sentinel taints an untrusted pipeline value (a 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 — plus flags @Library imports pinned to a mutable ref (a branch / default version) as supply-chain risk. The deep tier returns every finding with file:line, the full taint path and a SARIF 2.1.0 report with codeFlows, uploadable to GitHub code scanning. Use it whenever reviewing, writing or accepting CI config. Heuristic static analysis, not a guarantee.

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.