In March 2026, attackers turned trusted GitHub Actions into credential stealing weapons. The second Trivy compromise (CVE-2026-33634, CVSS 9.4) saw the threat actor TeamPCP inject a credential stealer into 76 of 77 version tags of aquasecurity/trivy-action. Days later, the Checkmarx KICS GitHub Action was compromised with malware injected into all its Git tags. Both attacks followed the same playbook: compromise a popular action, harvest environment variables and secrets from /proc/pid/mem of the Runner.Worker process, and exfiltrate everything to an attacker controlled domain.
These were not isolated events. In the same window, the CanisterWorm npm worm spread backdoors across the JavaScript ecosystem, while credential stealers were planted in PyPI packages targeting litellm and telnyx (TeamPCP, the same threat actor behind the Trivy compromise). The pattern is unmistakable: attackers are targeting GitHub Actions because they run with elevated privileges, access production secrets, and are rarely monitored at runtime.
No single security control stops every variant of these attacks. But the StepSecurity platform is built around the principle of defense in depth: multiple independent security layers, each covering a different phase of the attack lifecycle, that together ensure attackers have nowhere to operate undetected. This post walks through each layer of the StepSecurity platform and how it applies to TeamPCP's Trivy attack and similar compromises.
The Full Defense Walkthrough
The video below walks through each of the ten StepSecurity platform security layers and how they map to the Trivy attack lifecycle: from preventive controls that were already in place, to runtime detections that catch anomalies, to response capabilities that protect your entire organization.
Preventive Controls: What StepSecurity Has in Place Before an Attack
The most valuable security controls are those that are already active when an attack happens. The StepSecurity platform deploys several preventive layers that reduce the GitHub Actions attack surface, so that even if a compromised action executes in your workflows, it cannot achieve its objective of exfiltrating credentials.
Harden Runner: Network Egress Block Mode
Harden Runner is the StepSecurity platform's runtime security agent for GitHub Actions runners. It functions as an EDR (Endpoint Detection and Response) specifically built for GitHub Actions environments and supports GitHub hosted runners, self hosted VMs, bare metal runners, and Actions Runner Controller (ARC) clusters.
In block mode, Harden Runner enforces a network egress policy: only explicitly authorized network destinations (defined in the Policy Store) can receive outbound traffic from the GitHub Actions job. All other egress is dropped.
In the Trivy attack, the malware attempted to POST stolen credentials to scan.aquasecurtiy.org (a typosquat of aquasecurity.com, resolving to 45.148.10.212). With Harden Runner's network block mode enabled, this connection would be dropped before any data leaves the runner. The secrets remain safe regardless of what the compromised action attempts to execute. The same applies to the KICS compromise, where any exfiltration endpoint not on the allowlist would be blocked.
To set up network egress policies, you add Harden Runner to your GitHub Actions workflow and configure the allowed endpoints in the StepSecurity dashboard. The Policy Store supports both manual endpoint allowlisting and automatic importing of observed endpoints from baseline runs.
Harden Runner: Process Lockdown Mode
Beyond network controls, Harden Runner monitors process behavior on the runner in real time. When suspicious activity is detected, lockdown mode is triggered automatically, isolating the runner and terminating the job.
In the Trivy attack, the malware spawned a Python process that read /proc/pid/mem of the GitHub Actions Runner.Worker process to extract marked secrets from memory. This is the exact behavior that Harden Runner's process monitoring detects. On ARC clusters, lockdown mode provides real time threat detection with automatic job termination, ensuring that even if a compromised action begins executing its payload, it is stopped before secrets can be collected.
StepSecurity Maintained Actions
Many GitHub Actions supply chain attacks succeed because the targeted actions don't follow best practices such as immutable releases, branch protection, and GitHub Actions secret hygiene. The Trivy compromise is a direct example: a popular action with broad trust was weaponized because attackers gained the ability to manipulate its tags.
StepSecurity Maintained Actions directly address this risk by providing secure, StepSecurity maintained alternatives to third party actions that have elevated security concerns. StepSecurity onboards actions that have been abandoned by their original developers, rely on a single maintainer, score poorly on OpenSSF Scorecard assessments, or require privileged credential access.
Every maintained action undergoes a thorough manual secure code review before onboarding. All repositories live within the StepSecurity organization with strict write access limited to the StepSecurity engineering team, directly preventing unauthorized modifications like the ones seen in the Trivy and KICS attacks. Branch protection rules require cryptographically signed commits and peer review enforcement. Automated security checks including CodeQL, Dependency Review, OpenSSF Scorecard, and GuardDog run on every change.
Release safeguards include environment based approval gates, ephemeral tokens replacing persistent credentials (eliminating the attack vector used in the tj-actions/changed-files compromise), and Node actions rebuilt from scratch with validation. Docker images are rebuilt and pushed to StepSecurity registries. All maintained actions execute with Harden Runner for runtime anomaly detection and network traffic analysis.
Defined vulnerability management SLAs ensure timely response: critical vulnerabilities (CVSS 9.0+) are addressed within 2 days, while lower severity issues follow proportional timelines. Organizations using StepSecurity Maintained Actions eliminate the single point of failure that makes third party actions vulnerable to supply chain attacks.
Policy Driven Pull Requests
The Trivy attack worked because attackers force pushed malicious code to 76 existing version tags (v0.0.1 through v0.34.2) in the trivy-action repository. Any workflow referencing these tags by name, for example aquasecurity/trivy-action@v0.30.0, would silently start running the attacker's code. The same technique was used in the KICS compromise.
The StepSecurity platform addresses this proactively with Policy Driven Pull Requests, an automated feature that continuously monitors your organization's repositories and creates pull requests to enforce security best practices. Policy Driven PRs automatically pin GitHub Actions to immutable full length commit SHAs instead of mutable version tags. A pinned reference like aquasecurity/trivy-action@7b7aa264d83dc58691451798b4d117d47fc3ab44 cannot be changed by an attacker, because commit SHAs are cryptographic hashes of the content itself. Organizations that had pinned their actions to commit SHAs before the Trivy incident were not affected by the tag manipulation.
Beyond action pinning, Policy Driven PRs also auto create pull requests for: installing Harden Runner in your workflows, restricting GITHUB_TOKEN permissions to least privilege, pinning Docker container images to immutable digests, and replacing known risky third party actions with StepSecurity maintained alternatives. Results appear within 24 hours of enabling the feature. This is an Enterprise Tier capability that ensures your security posture improves continuously without manual effort.
Runtime Detection: How StepSecurity Catches What Prevention Misses
Not every GitHub Actions workflow has every preventive control fully deployed from day one. Some organizations are still rolling out Harden Runner in audit mode before switching to block mode. Detection controls in the StepSecurity platform provide visibility into what is happening during GitHub Actions execution, enabling rapid response even when prevention is not yet in enforcement mode.
Network Monitoring and Anomaly Detection
Even in audit mode (rather than block mode), Harden Runner logs every outbound network connection made during a GitHub Actions workflow run. These connections are analyzed against the baseline of normal network behavior for each workflow.
When the compromised Trivy action ran in open source projects monitored by StepSecurity, the anomalous connection to scan.aquasecurtiy.org was immediately flagged as a new, never before seen endpoint.
The Workflow Runs dashboard in the StepSecurity platform provides a complete view of network activity, file modifications, and security detections for every GitHub Actions run. It classifies detections across nine categories including blocked endpoints, anomalous activity, and secret exposures. The Harden Runner Detections page can be used to discover all workflow runs across your organization that have raised these detections, providing a centralized view of security events. In addition, enterprises can use the organization baseline to discover all workflow runs that made calls to a malicious domain, making it straightforward to identify every affected run during an incident like the Trivy compromise.
Process Monitoring
Harden Runner tracks all processes that execute on the GitHub Actions runner during a workflow run. In the Trivy attack, the /proc/pid/mem read operation targeting the Runner.Worker process was detected and flagged as anomalous. This behavior has no legitimate use case in standard GitHub Actions workflows, and is a strong signal of credential theft. The Detections view in the StepSecurity dashboard surfaces these events, categorizing them with clear severity labels and supporting both suppression (for known false positives) and resolution workflows.
Workflow Log Analysis: Imposter Commit Scanning
Both the Trivy and KICS attacks used a technique known as imposter commits: commits that exist in a repository (reachable by SHA) but do not belong to any branch. The attacker forks a repository, pushes malicious commits to the fork, then updates the original repository's tags to point at those fork commits. Since GitHub stores forked commits in the parent repository's object store, the SHA resolves, but the commit does not appear on any branch of the source repository.
The StepSecurity platform's workflow log analysis automatically detects when a GitHub Action resolves to a commit SHA that is not on any branch of the source repository, flagging it as a potential supply chain indicator. This check works for all repositories that have the StepSecurity app installed and does not require any other platform features such as Harden Runner. This means organizations get imposter commit detection as soon as they install the StepSecurity app, with zero additional configuration.
The Detections page lists all workflow runs with imposter commit detections in one place, making it easy to identify affected repositories across your entire organization at a glance.
Threat Intelligence: StepSecurity's Ecosystem Wide Monitoring
Detection at the individual workflow level is valuable, but supply chain attacks like Trivy and KICS require ecosystem wide awareness. The StepSecurity platform operates an AI powered threat intelligence pipeline that continuously monitors GitHub Actions repositories, package registries, and community channels for indicators of supply chain compromise.
StepSecurity is one of the first companies to report these GitHub Actions supply chain attacks and provides in depth technical analysis with detailed recovery steps, helping the broader community respond quickly and effectively.
Here is how the StepSecurity threat intelligence pipeline responded to the Trivy compromise:
Step 1: AI Agent Detection. StepSecurity's AI agent monitors the GitHub Actions ecosystem around the clock, looking for signals of compromised actions, including unusual tag activity, suspicious commit patterns, and community reports.
Step 2: Triage and Validation. When a potential compromise is identified, the StepSecurity threat intelligence team validates the threat, reverse engineers the malware, and collects indicators of compromise. For Trivy, this included the C2 domain (scan.aquasecurtiy.org), attacker IP (45.148.10.212), all 76 compromised commit SHAs, and the full malware behavior chain.
Step 3: Threat Center Advisory. The StepSecurity platform publishes a Threat Center advisory with IOCs and remediation guidance. Customers with SIEM integrations (Splunk, Sentinel, etc.) receive these alerts in real time. The StepSecurity team also released an open source trivy-compromise-scanner to help the broader community identify affected workflows.
Workflow Run Policies: The Pre Execution Gate
Workflow Run Policies act as a pre execution gate that evaluates every GitHub Actions workflow run before any code executes. When a workflow is triggered in any repository across your organization, the StepSecurity platform checks the workflow against your configured policies. If any policy is violated, the run is automatically cancelled before any steps execute, ensuring no secrets are exposed and no compromised code runs.
For supply chain attacks like Trivy, the most critical policy is the Known Compromised Actions Policy. Once StepSecurity added the compromised trivy-action tags to the known compromised actions list, every new workflow run across all customer organizations that referenced those tags would be automatically cancelled. This is particularly important for the window between when a compromise is discovered and when individual teams update their workflow files, providing organization wide protection without requiring every repository to be individually patched.
The StepSecurity platform supports several additional policy types beyond compromised action detection. You can explore all available policies and their configuration options in the Workflow Run Policies documentation.
Incident Response: Mapping the Blast Radius with Actions Inventory
When a GitHub Actions supply chain compromise is confirmed, the first question every security team asks is: which of our repositories are affected?
The StepSecurity platform's Actions Inventory provides a complete, queryable map of every GitHub Action in use across your entire organization. When the Trivy compromise was announced, security teams using StepSecurity could instantly answer:
Which repositories use trivy-action? The inventory lists every repository that references aquasecurity/trivy-action in any workflow file.
Are they pinned or mutable? For each usage, the inventory shows whether the action is referenced by a mutable tag (vulnerable) or a pinned commit SHA (safe). This is the Pinned vs Mutable Analysis that immediately reveals pinning gaps.
Which runs executed during the compromise window? Combined with the Workflow Runs dashboard, teams can identify exactly which jobs ran between the compromise timestamp (March 19, 17:43 UTC) and the remediation.
This turns an incident response process that normally takes hours of manual grep across hundreds of repositories into a query that completes in seconds.
The Broader Threat Landscape
The Trivy and KICS compromises were not isolated events. In the same period:
The CanisterWorm npm worm demonstrated self propagating supply chain attacks across the JavaScript ecosystem. Credential stealers were hidden in PyPI packages targeting litellm using wheel file injection and telnyx using WAV steganography. The threat actor behind the telnyx attack (TeamPCP) is the same group responsible for the Trivy compromise.
Each of these attacks exploits a different vector, but they all converge on the same target: the GitHub Actions pipeline. The credentials, cloud tokens, and deployment keys that flow through these environments make them the highest value target in the software supply chain.
Key Takeaway: Defense in Depth Works
An attacker executing a GitHub Actions supply chain attack like Trivy or KICS needs to succeed at every step of the kill chain: inject malicious code into a trusted action, establish a C2 connection from the runner, read secrets from memory, and exfiltrate the data. The StepSecurity platform is designed so that a defender only needs to catch them at one step.
Network block mode stops the exfiltration. Process lockdown stops the memory read. StepSecurity Maintained Actions eliminate the single point of failure that makes third party actions vulnerable. Pinned SHAs prevent the malicious code from running in the first place. Imposter commit scanning flags the attack technique. Threat intelligence catches the compromise at the ecosystem level. Workflow Run Policies cancel runs across your entire organization. And Actions Inventory tells you exactly where you are exposed.
No single control is a silver bullet. But together, these layers make it significantly harder for attackers to succeed at any step, and significantly easier for defenders to detect, contain, and respond when a GitHub Actions supply chain attack is announced.
Explore the StepSecurity platform, read the documentation, or check out our detailed analysis of the Trivy compromise and the KICS compromise.
.png)
