CICD Pipeline Surface

Your Build Pipeline Is a Target

Every modern software organization runs code through a CI/CD pipeline — automated systems that build, test, and deploy software on every code change. These pipelines have access to your most sensitive assets: production deployment credentials, code signing keys, cloud provider tokens, and the ability to push code directly to customers.

A single misconfigured workflow can give an anonymous contributor the ability to exfiltrate every secret in your organization. A compromised third-party action can inject code into every pipeline that references it. And unlike application vulnerabilities that require exploitation at runtime, CI/CD attacks execute in your own infrastructure, with your own permissions, on your own schedule.

Guard continuously scans your CI/CD pipeline configurations across GitHub Actions, GitLab CI, Azure DevOps, Jenkins, and more — identifying the misconfigurations, injection vectors, and supply chain risks that attackers exploit before they can be used against you.

Why Pipelines Are Exposed

Pipelines have overprivileged access by default

CI/CD systems are designed for convenience, not security. GitHub Actions grants automatic write tokens to workflows. Self-hosted runners retain state between jobs. Pipeline secrets are available to any step in a workflow unless explicitly restricted. The default configuration of most CI/CD platforms creates exactly the conditions attackers need.

The attack patterns are well-understood but hard to spot manually

The vulnerability types that enable these attacks are specific to CI/CD:

• Workflow injection — Attacker-controlled input (PR titles, branch names, commit messages) interpolated into shell commands via expression syntax, enabling arbitrary code execution
• Poisoned pipeline execution (PPE) — Attacker modifies build configuration or referenced scripts via pull request, causing the pipeline to execute malicious code with elevated privileges
• pull_request_target abuse — Workflows triggered by pull_request_target run with the base repository's secrets but can check out attacker-controlled fork code
• Artifact and cache poisoning — GitHub does not segregate caches by trust level, allowing a low-privilege job to poison a cache restored by a privileged release job
• Self-hosted runner persistence — Non-ephemeral runners retain state between jobs, enabling backdoor installation, credential theft, and internal network access
• Dependency confusion — Publishing a malicious public package with the same name as an internal private dependency, exploiting package manager resolution order

These patterns exist in YAML configuration files that change with every pull request. No human reviewer can consistently catch them across every repository. Guard automates this analysis.

What Guard Discovers and Tests

Multi-Platform Pipeline Scanning

Guard scans CI/CD configurations across six major platforms:

32 detection plugins identify vulnerabilities. 24 attack plugins validate exploitability. This isn't just static analysis — Guard can confirm whether a detected vulnerability is actually reachable and exploitable.

Vulnerability Categories Detected

Guard's CI/CD scanner uses graph-based analysis with taint tracking to detect vulnerabilities that static linting tools miss. It builds a dependency graph of your workflows, tracks how untrusted input flows through jobs and steps, identifies security gates that block exploitation, and determines actual exploitability.

Pipeline Injection Attacks:

Supply Chain Risks:

Permission and Configuration Issues:

AI-Specific CI/CD Risks:

Graph-Based Analysis

Guard doesn't just pattern-match YAML files. It builds a full dependency graph of your CI/CD pipeline:

1. Parse — Normalize workflow YAML across all supported platforms into a unified graph representation
2. Build — Create workflow → job → step graphs with dependency relationships, trigger conditions, and data flow edges
3. Taint — Track how untrusted input (attacker-controlled PR fields, fork code, external artifacts) flows through the graph
4. Gate — Identify security controls (required reviews, branch protection, environment approvals) that block exploitation paths
5. Detect — Execute detection plugins against the tainted graph, filtering for actually-reachable vulnerabilities
6. Validate — Optionally run attack plugins to confirm exploitability with real API calls

This approach eliminates the false positives that plague simpler tools. A workflow injection that's gated behind a required review from a CODEOWNERS team is a different finding than one that's exploitable by any anonymous contributor — and Guard distinguishes between them.

Repository Security Monitoring

Beyond pipeline configuration, Guard monitors your source code management posture:

How It All Connects

Source Code Management Integration
  │
  ├─→ Repository Enumeration ─→ All repos discovered across platforms
  │     │
  │     ├─→ CI/CD Pipeline Scanning ─→ Workflow configs analyzed
  │     │     ├─→ Graph construction ─→ Dependency and data flow mapped
  │     │     ├─→ Taint tracking ─→ Untrusted input flows identified
  │     │     ├─→ Gate detection ─→ Security controls evaluated
  │     │     └─→ Vulnerability detection ─→ Exploitable misconfigs found
  │     │           ├─→ Injection vectors (workflow, include, review)
  │     │           ├─→ Supply chain risks (unpinned, vulnerable, poisoned)
  │     │           ├─→ Permission issues (excessive, exposed secrets)
  │     │           └─→ AI-specific risks (token exfil, code injection)
  │     │
  │     ├─→ Secret Scanning ─→ Full commit history analyzed
  │     │     └─→ Live validation ─→ Active credentials confirmed
  │     │
  │     └─→ Public Exposure Detection ─→ Newly-public repos flagged
  │
  └─→ Dependency Confusion Scanning ─→ Shadowed packages identified

Every finding feeds into Guard's unified risk model alongside external and internal findings — giving security teams a complete picture of their exposure across all attack surfaces.

What Users See in the Platform

Pipeline Vulnerability Findings

Each CI/CD finding includes:

• Vulnerability type — Injection, pwn request, artifact poisoning, etc.
• Severity and confidence — Based on exploitability analysis and gate detection
• Attack complexity — Zero-click (no user interaction) through high complexity
• Affected workflow — Exact file path, job name, and step with line numbers
• Trigger type — Which event triggers the vulnerable workflow
• Gate analysis — Whether security controls (required reviews, branch protection) reduce exploitability
• Evidence — The specific expression, action reference, or configuration that creates the vulnerability

Repository Inventory

All discovered repositories appear as assets with:

• Platform (GitHub, GitLab, Azure DevOps, Bitbucket)
• Visibility (public, private, internal)
• Pipeline status (which CI/CD platform is configured)
• Secret scanning results
• Pipeline vulnerability count by severity

Capability Summary

Guard's CI/CD attack surface scanning provides:

The CI/CD attack surface is where software supply chain risk lives. Every workflow that runs on a pull request, every action that's referenced by tag, every secret that's available to a pipeline step — these are the decisions that determine whether an attacker who submits a pull request gets a build log or gets your production credentials.

Guard finds those decisions and tells you which ones to change.