Open-Source CI/CD Abuse Detector Helps Stop Stolen Credential Attacks

A new open-source security tool called CI/CD Abuse Detector has been released to help organizations identify malicious changes to continuous integration and continuous deployment (CI/CD) pipelines before they can be exploited.

The project uses a large language model (LLM) to analyze modifications made to CI/CD workflows, automation configurations, build pipelines, and deployment processes. It includes ready-to-use templates for GitHub Actions, GitLab CI, and Azure DevOps, making deployment straightforward for development teams.

Protecting Against Software Supply Chain Attacks

The detector is designed to address a common software supply chain attack scenario. In these attacks, cybercriminals obtain stolen developer credentials and use them to modify workflow files within a repository. Once the altered workflows execute, they can harvest secrets and sensitive credentials stored within the CI/CD environment.

By examining workflow changes during the code review stage, the tool aims to identify suspicious modifications before they are merged and executed.

How the Detection Process Works

The analysis workflow consists of six stages:

1. File Identification – Changed files in a pull request are scanned for CI/CD, build, release, packaging, and automation-related configurations.
2. Diff Analysis – Matching files are individually compared, with each diff limited to 10,000 characters to reduce attempts to conceal malicious code within large legitimate changes.
3. Pre-Screening – Regex patterns and metadata rules add contextual labels to each detected change.
4. LLM Evaluation – The labeled diff is sent to Claude through the Claude Code command-line interface for analysis against a credential-harvesting threat model.
5. Structured Verdicts – Results are returned in a predefined JSON format for consistent processing.
6. Alerting and Enforcement – Findings can trigger notifications or automated actions depending on severity levels.

Alerting and Response Options

Organizations can configure multiple output methods, including:

• GitHub Step Summary reports
• Repository issue creation
• Slack webhook notifications
• Elasticsearch verdict forwarding

The detector can also operate as a pull request gate. When enabled, it can block merges if the severity score exceeds a configured threshold. By default, however, the tool runs in alert-only mode.

Deployment Requirements

To deploy the detector, teams need to add three files to their repository:

• Workflow YAML configuration
• Prompt Markdown file
• JSON verdict schema

Authentication can be configured using either:

• An Anthropic API key
• A Foundry endpoint URL and API key for enterprise environments

These credentials must be stored securely as repository secrets.

Configuration Options

Several environment variables allow teams to customize behavior:

• CI_CD_ABUSE_ALERT_THRESHOLD – Defines the minimum severity required to generate alerts. The default setting is “high.”
• CI_CD_ABUSE_FAIL_ON_SEVERITY – Determines the severity level that will block pull requests. By default, this value is empty, meaning alerts are generated without blocking changes.
• CI_CD_ABUSE_INCLUDE_PUSHES – Controls whether direct pushes to main or master branches are analyzed. The default setting is enabled.

The workflow preprocessing stage relies on standard tools such as Bash, jq, and grep. The Claude Code CLI, installed through Node.js, is the only analysis dependency introduced into the CI environment. Python is used only for validation and build tooling and is not required during runtime.

Prototype Status and Research Background

The CI/CD Abuse Detector is currently a prototype and reference implementation developed as part of Elastic Security Labs research on detecting CI/CD pipeline abuse through LLM-assisted analysis.

Elastic notes that the project is not part of its official product portfolio, has limited support coverage, and does not currently have a fixed development roadmap.

Organizations interested in the methodology can review the project’s architecture documentation, threat model, scoring framework, and supporting research materials. Security vulnerabilities related to the project are handled through Elastic’s established disclosure process.