Why HailBytes ASM Now Scans Your CI/CD Pipelines

Attack surface management has a well-understood job: enumerate the subdomains, ports, and web endpoints an attacker can reach, and tell you which ones are exposed. But there is a category of internet-facing infrastructure that almost every ASM tool ignores entirely — the pipeline that builds and deploys your applications. A misconfigured GitHub Actions workflow can leak a cloud credential, be triggered by an untrusted pull request, or hand a compromised dependency maintainer write access to production. None of that shows up in a port scan. As of the May 2026 release, HailBytes ASM scans it directly.

The Blind Spot Most ASM Tools Share

Attack-surface tools enumerate what is deployed. They rarely look at what does the deploying. That is a problem, because CI/CD pipelines have become one of the most reliably productive targets in real-world breaches. A workflow that checks out untrusted code and runs it with a privileged token is a remote code execution primitive sitting in a public repository. A secret printed into a build log is a credential leak that no amount of network hardening will catch. And because pipeline configuration lives in YAML that most security teams never review with the same rigor as production code, these misconfigurations accumulate quietly.

The CI/CD pipeline is part of your attack surface whether or not your tooling measures it. HailBytes ASM’s new cicd_scan phase brings it into the same model as every other finding.

The Two Tools and What They Find

The phase runs two complementary scanners against the GitHub Actions workflows in a configured organization:

Gato enumerates GitHub Actions configuration for the misconfigurations that lead to compromise: overly-permissive GITHUB_TOKEN scopes, pull_request_target trigger abuse vectors, self-hosted runner poisoning risk, and OIDC token-abuse paths that let a workflow assume cloud roles it should never reach. These are the issues that turn a routine CI job into a foothold.

zizmor (v1.25.2) performs static analysis of the workflow YAML itself: command injection through unsanitized ${{ github.event.* }} interpolation, unpinned third-party actions that can be retagged out from under you, and environment-variable leakage between steps. Where Gato reasons about the organization’s configuration and permissions, zizmor reasons about the syntax of each workflow file — together they cover both the policy and the code.

How It Fits Into the Scan Pipeline

The cicd_scan phase runs alongside the rest of the recon pipeline. It is off by default and enabled per scan engine; you supply a GitHub Personal Access Token, stored encrypted per-Organization as GitHubAPIKey, that scopes which organization the scanners can read. Once enabled, findings land in exactly the same place as nuclei, dalfox, and the other scanners’ output: as Vulnerability rows, classified Critical or High, that flow into the exposure graph, SIEM forwarding, ticketing dispatchers, and per-framework compliance reports. There is no separate console and no second triage queue — a workflow-injection finding sits next to an exposed admin panel in the same prioritized list.

What a Real Finding Looks Like

Consider a pull_request_target workflow in a public-facing repository that checks out the contributor’s branch and runs its build scripts — with the elevated token that pull_request_target grants. An attacker opens a pull request containing a malicious build step; the workflow runs it with write access to the repository and any secrets in scope. HailBytes ASM surfaces this as a Critical finding in the scan detail view, with the workflow file path, the offending trigger, and remediation guidance (move untrusted checkout to pull_request, gate privileged jobs behind an environment approval). It reads like any other Critical — because operationally, it is one.

The Compliance Angle

CI/CD pipeline security is not just a hardening nicety; it maps to controls auditors increasingly ask about. Change-management and pipeline integrity sit under SOC 2 CC8.1, continuous monitoring under NIST CSF DE.CM, and configuration-change control under FedRAMP CM-3. Because CI/CD findings are ordinary Vulnerability rows, they export through the same per-framework compliance reports as the rest of your attack surface — so “we monitor our build pipeline for misconfiguration” becomes an evidence artifact rather than an assertion.