Skip to main content
Glama
Baneado98

ci-sentinel

by Baneado98

audit_ci_security

Audit CI/CD configuration files for security flaws before merging. Detects injection, credential leaks, and supply-chain risks across seven CI platforms.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
deepNoWhen 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.
filesNoMap 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.
sourceNoA 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.
sharedLibYmlsNoOPTIONAL (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.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully discloses behavioral traits: it performs heuristic static analysis, requires an API key for deep audit, redacts secrets, returns a verdict and SARIF report, and lists many categories of issues. It also mentions limitations ('not a guarantee').

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is excessively long (wall of text). While it has structure (ecosystem-by-ecosystem), it contains unnecessary details that could be shortened or placed in schema descriptions. The verbosity reduces clarity for an AI agent trying to parse key points quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (7 ecosystems, deep audit modes, API key requirement, return format), the description is comprehensive. It explains inputs, operations, outputs (verdict and SARIF report), and even covers edge cases like cross-file analysis and secret redaction.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, yet the description adds significant value beyond the schema. For 'deep,' it explains the need for an API key. For 'files' and 'source,' it adds details about auto-detection and mixing ecosystems. For 'sharedLibYmls,' it explains cross-file taint analysis, which is not in schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool audits CI configs for security flaws, listing seven specific CI ecosystems. The verb 'Audit' and resource 'CI config' are explicit, and the tool is distinguished from its sibling 'diff_ci_security' by focusing on auditing rather than diffing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises using the tool 'whenever reviewing, writing or accepting CI config,' providing clear context for its use. However, it does not explicitly state when not to use it or mention the sibling 'diff_ci_security' as an alternative for diffing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Baneado98/ci-sentinel'

If you have feedback or need assistance with the MCP directory API, please join our Discord server