CI/CD pipelines have become the backbone of modern software delivery, ensuring faster deployments and automation. However, these pipelines rely on runners—build agents or execution environments—that often operate with high privileges but minimal security oversight.
Recent supply chain attacks, such as SolarWinds and Codecov, have exposed this security gap. Attackers injected malicious code into builds or exfiltrated secrets from CI jobs by exploiting unmonitored runners. Without proper monitoring, these attacks can go undetected for months.
This blog post will explore:
CI/CD runners are essentially servers with privileged access—making them attractive targets. Failing to monitor and secure these runners introduces several risks:
CI/CD runners often have unrestricted internet access to fetch dependencies. If an attacker compromises the build process, they can quietly send data out (exfiltrate) without notice.
For example, during the Codecov breach, threat actors modified the CI script (Codecov’s Bash Uploader) to exfiltrate environment variables (including keys and tokens) from thousands of CI/CD environments (Codecov hackers gained access to Monday.com source code). Because no network egress filtering or monitoring was in place, this malicious outbound traffic went undetected for months.
Unmonitored egress can lead to leakage of source code, credentials, or other sensitive artifacts.
Traditional EDR solutions often aren’t deployed on CI runners. Corporate EDR agents might cover laptops and servers, but your ephemeral GitHub Actions runners or GitLab CI runners might not have any equivalent protection.
This means malware or suspicious processes running in a build can slip by unnoticed. In fact, CI/CD-specific malware has been found operating without triggering standard security tools. The absence of runtime monitoring and alerting (characteristic of EDR) in CI environments creates a blind spot.
In short, if a CI runner is breached, you may not know until it’s too late.
CI/CD pipelines have emerged as a new attack vector in supply chain breaches. In the SolarWinds incident, attackers compromised a CI/CD runner and implanted malware (SUNSPOT) that subtly altered source code during the build process (SUNSPOT Malware: A Technical Analysis | CrowdStrike). The malware monitored build processes and replaced source files to insert a backdoor, all while evading detection. Without file integrity monitoring or process scrutiny on the runner, the tampering went undetected during the build.
These attacks demonstrate that build systems can be manipulated to distribute malicious code downstream. If the runner isn’t closely watched (for anomalous file changes, unexpected processes, or odd network connections), an attacker can poison your software supply chain right at the source.
Many organizations assume that because CI runners are short-lived, the risk is lower. However, ephemeral does not mean secure. An attacker only needs a few seconds of execution to exfiltrate data or alter an artifact. The transient nature of runners can actually make post-incident forensics harder if logs and telemetry aren’t retained.
It’s crucial to treat CI runners as high-value, short-lived endpoints that require the same security controls as long-lived servers.
In summary, an unmonitored CI/CD runner is a high-powered machine operating outside your usual security radar. It can connect anywhere, run anything, and handle secrets—all while flying under the compliance and monitoring radar. This combination of power and opacity is what makes CI/CD runners a security risk that we can no longer ignore.
Major security and privacy compliance frameworks already underscore the importance of system monitoring, logging, and network security. Although they may not mention “CI/CD” explicitly, their requirements clearly apply to any system handling sensitive data or critical processes—which includes CI/CD runners. Let’s look at a few examples:
The Payment Card Industry Data Security Standard has explicit requirements for logging and monitoring. Requirement 10 of PCI-DSS mandates to “track and monitor all access to network resources and cardholder data” (Security Logging and Monitoring (PCI DSS Requirement 10): Why all the Fuss?).
PCI emphasizes that logging mechanisms are critical for detecting and minimizing the impact of breaches. It also requires regular monitoring of networks (e.g., intrusion detection/prevention systems and egress monitoring) to catch suspicious communications.
In practice, if your CI/CD pipeline is involved in building or deploying software that touches cardholder data, those build environments should be monitored as well. Otherwise, you risk a compliance gap where an attacker could exfiltrate payment data or inject malicious code without any audit trail.
SOC 2’s Trust Services Criteria include sections on system operations and monitoring (particularly under the Security category). For example, CC7 (System Operations) requires organizations to monitor system components for anomalous activity and security events, and to analyze anomalies to determine if they represent actual incidents (SOC 2 Common Criteria 7.2 Security Event and Anomaly Detection).
In plain terms, to pass SOC 2, you need to have controls that catch things like unexpected processes spawning or unexpected outbound connections – exactly what could happen on a compromised CI runner.
The Health Insurance Portability and Accountability Act requires safeguards to protect electronic health data (ePHI). Under HIPAA’s Technical Safeguards, there’s a standard for Audit Controls (45 CFR §164.312(b)) which states organizations must “implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.” (45 CFR § 164.312 - Technical safeguards. | Electronic Code of Federal Regulations (e-CFR) | US Law | LII / Legal Information Institute).
This means every system that can access or manipulate ePHI should log events and be monitored for inappropriate access. If your CI/CD process builds/deploys healthcare applications or infrastructure as code for systems storing ePHI, the CI/CD runners are part of the “information systems” handling ePHI.
ISO 27001 (and the updated ISO 27002 controls) heavily emphasize logging and monitoring as well. For example, control A.12.4 in ISO 27001:2013 (now updated to A.8.15–A.8.16 in ISO 27001:2022) is about logging and monitoring. It advises that event logs should be produced and actively reviewed to record user activities, exceptions, faults, and information security events.
Additionally, ISO 27002 includes guidance on monitoring system use, detecting anomalies, and protecting log integrity. There are also controls around network security (e.g., A.13 Communications Security, which includes network segregation and monitoring). If your organization is ISO 27001 certified, you’re expected to monitor all relevant systems for security events – CI/CD infrastructure is no exception.
An attacker altering a build or transferring data from a runner is an “information security event” that should be logged and investigated per ISO 27001’s controls.
In summary, compliance frameworks universally call for vigilance – logging, auditing, and controlling systems and data flows. They expect organizations to have visibility into system activities and network traffic to quickly detect anomalies or breaches. If CI/CD runners are not included in that visibility, you essentially have an unmonitored server touching your crown jewels.
Integrating a security tool purpose-built for CI/CD runners, like StepSecurity Harden-Runner, can significantly ease the challenge of monitoring runners and meeting compliance requirements.
Harden-Runner acts as a runtime security agent for your CI/CD jobs. It essentially provides EDR-like and network monitoring capabilities within the pipeline, addressing the gaps we discussed. Here’s how Harden-Runner’s features help organizations satisfy compliance needs and bolster CI/CD security:
Harden-Runner can block or audit outbound connections from the CI runner using an allowlist of domains. This means you can strictly limit where your pipeline can send data. Any attempt to connect to an unapproved host is detected and can be blocked or logged. This aligns directly with compliance expectations around controlling network traffic.
In practice, teams use it to baseline normal outbound calls (to package registries, APIs, etc.) and then catch any deviation. This fulfills the spirit of PCI-DSS network monitoring and any data leakage prevention controls – you can demonstrate that even your CI/CD environment won’t send sensitive data to unauthorized external systems.
During a build, it’s unusual for source code files to be modified unless intentionally part of the build steps. Harden-Runner watches the file system and can detect if any file is unexpectedly altered. In other words, it will alert if malicious code injection is happening during the build (like the SolarWinds SUNSPOT scenario). Harden-Runner will flag unauthorized changes to source code or other files during the CI/CD pipeline.
Compliance-wise, this feature maps to requirements for integrity monitoring (for instance, PCI-DSS Requirement 11 used to mandate file-integrity monitoring for critical systems). It also provides evidence in logs whenever a file is changed, which contributes to audit trails. By catching tampering early, you not only improve security but can prove that your build process has controls to ensure the integrity of the software (important for frameworks concerned with software integrity and release integrity).
Harden-Runner records every process executed in the runner and can even tie those processes to network calls or file operations. Think of it as having an EDR agent that is “continuously surveilling the CI/CD environment” with context. It provides visibility into the commands and programs that run during your pipeline.
You can view the name and path of every file written…and monitor every process executed during the build, along with its arguments. This level of detail is exactly what auditors hope to see from an endpoint monitoring standpoint.
Harden-Runner feeds its detections and logs to a dashboard. It provides an “Insights page for CI/CD runs” with detailed reports of all security-relevant events. This becomes a treasure trove for compliance documentation. Security engineers can periodically review these logs and even generate reports of all outbound connections made across pipelines. For instance, StepSecurity provides an organization-level report of all external endpoints your workflows contacted. Such reports make it easy to spot any unusual destinations and demonstrate to auditors that you have tight control and oversight of your CI/CD network communications. The logs also serve as evidence of controls in action – e.g., if Harden-Runner blocked an unauthorized connection, you can show that as proof of your network egress control measure.
In short, Harden-Runner adds security controls to CI/CD runners, similar to what servers use—firewall rules, file and process monitoring, and activity logging. It helps organizations monitor CI pipelines, block unauthorized access, and detect threats. This makes audits easier and strengthens security by closing gaps attackers might exploit.
CI/CD runners can no longer be treated as the wild west of your infrastructure. They hold the keys to your code and deployment – and thus deserve the same attention in security monitoring and compliance as any production system. As we’ve discussed, the security risks of ignoring runners are too significant: from silent data exfiltration to undetected supply chain tampering. Meanwhile, the major compliance frameworks all require robust monitoring, logging, and control of systems and networks. By including CI/CD runner environments in your compliance scope, you ensure these requirements are truly met across the board, not just on your traditional servers.
The good news is that solutions like StepSecurity Harden-Runner make it feasible to achieve this. You can gain network egress control, file/process monitoring, and detailed audit logs in your pipelines with minimal friction. This layered approach transforms your CI/CD runners from a blind spot to a monitored, controlled part of your ecosystem.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。