[SUP] Trivy Supply Chain Attack Credential Compromise and Release Channel Poisoning

Report Type

Threat Intelligence Assessment

Threat Category

Supply Chain Compromise

CI/CD Pipeline Compromise

Credential Theft and Identity Abuse

Assessment Date

March 26, 2020

Primary Impact Domain

Software Supply Chain Integrity (CI/CD Ecosystems)

Identity and Access Management (Service Accounts, Tokens, Secrets)

Cloud and Build Infrastructure Security (AWS, Azure, GCP)

BLUF

 Organizations using Trivy within CI/CD pipelines face material business risk from a supply chain attack in which compromised publishing credentials were used to inject malicious code into official release channels, GitHub Actions, and container images, causing trusted pipeline components to execute attacker-controlled payloads. The technical cause is a failure in upstream trust controls, where authenticated access to release infrastructure enabled modification of version tags, binaries, and images that downstream systems implicitly trust and execute. The threat posture is elevated because the attack requires no victim-side vulnerability exploitation, leverages legitimate distribution mechanisms, and involves a vulnerability now confirmed exploited in the wild through CISA KEV, allowing malicious components to propagate silently through automated pipelines at scale. Executive action is required to assume credential exposure, rotate all pipeline secrets, validate all consumed artifacts, and enforce controls that eliminate implicit trust in upstream-managed or mutable components.

Executive Risk Translation

This attack converts trusted software supply chain components into execution paths for credential theft and downstream system compromise without requiring exploitation of target environments.

S3 Why This Matters Now

·        Confirmed compromise of multiple upstream distribution channels:

o   GitHub releases

o   GitHub Actions (trivy-action, setup-trivy)

o   Docker Hub images

·        CVE-2026-33634 is a confirmed exploited vulnerability in CISA KEV, which elevates this from high-priority to immediate remediation priority under standard vulnerability management practice.

·        Attack targets distribution trust and dependency consumption, not runtime vulnerabilities

·        CI/CD pipelines commonly:

o   Pull and execute external components automatically

o   Trust version tags and upstream sources without verification

·        Multi-channel compromise increases:

o   Exposure likelihood

o   Complexity of incident scoping

·        Exposure may be silent and retroactive, requiring historical pipeline and artifact analysis

·        Aqua’s advisory confirms compromised credentials were used to publish a malicious Trivy v0.69.4 release, hijack trivy-action tags, replace setup-trivy tags, and later publish malicious Docker Hub images.

S4 Key Judgments

·        This is a release-channel supply chain compromise enabled by valid credentials, not a traditional victim-side vulnerability exploitation chain

·        The attack required no victim-side exploitation, only consumption of trusted upstream components

·        CVE-2026-33634 is confirmed exploited and should be treated as an immediate remediation and response priority, not a watchlist item.

·        Malicious components were:

o   Distributed through official sources

o   Executed within normal CI/CD workflows

·        Highest-risk environments:

o   Pipelines using mutable tags or unpinned dependencies

o   Environments exposing secrets during pipeline execution

·        The attack enables:

o   Credential theft

o   Downstream system access

o   Lateral movement via pipeline permissions

·        Aqua’s incident details confirm the actor used compromised credentials and targeted release assets, action tags, and container images across multiple channels.

S5 Executive Risk Summary

Primary Risk

o   Execution of attacker-controlled code within CI/CD pipelines via compromised trusted components

Secondary Risk

o   Exposure and theft of pipeline credentials, tokens, and secrets

Operational Impact

o   Unauthorized access to source code, registries, and deployment environments

o   Mandatory credential rotation and pipeline-wide validation

Strategic Impact

o   Loss of trust in software supply chain dependencies

o   Governance failure in third-party component validation

S6 Executive Cost Summary (Improved Presentation)

This cost analysis was developed by the CyberDax team using expert judgment and assisted analytical tools to support clarity and consistency.

Low Impact — $50K–$250K

Limited exposure requiring targeted credential rotation, artifact validation, and verification of affected pipeline components

Moderate Impact — $250K–$2M

Confirmed execution of compromised components requiring full credential rotation, pipeline audit, artifact revalidation, and investigation of historical exposure windows

High Impact — $2M–$10M+

Broad credential compromise and downstream system access requiring enterprise-wide secret rotation, full CI/CD pipeline rebuild, cache and dependency purge, retrospective exposure analysis, and regulatory response

S6A Key Cost Drivers

·        Emergency credential rotation across CI/CD, cloud, and registry environments

·        Retrospective exposure scoping across pipeline executions and logs

·        Artifact validation, recall, and cache purging

·        Pipeline integrity re-establishment and dependency governance enforcement

·        Incident response, forensic investigation, and operational disruption

S6B Compliance and Risk Context

Compliance Exposure Indicator

·        Violations of:

o   NIST SSDF supply chain and dependency controls

o   SOC 2 control integrity and access management

o   ISO 27001 supplier security and application integrity controls

Risk Register Entry

·        Risk Title

o   Supply Chain Compromise via Trivy Release Channel Poisoning

·        Risk Category

o   Supply Chain Security / Identity and Access Risk

·        Likelihood

o   Moderate to High in automated CI/CD environments

·        Impact

o   High due to credential exposure and control bypass

Annualized Risk Exposure

·        Estimated range: $750K–$8M annually depending on pipeline scale and credential scope

S8 Bottom Line for Executives

This is a credential-driven supply chain attack targeting trusted distribution channels

CVE-2026-33634 is confirmed exploited and should be treated as an immediate remediation priority within vulnerability and incident response workflows.

The core failure is implicit trust in upstream components and mutable references

Immediate priorities:

·        Rotate all credentials

·        Validate all artifacts

·        Enforce immutable and verified dependencies

·        Review historical pipeline executions during the exposure windows identified by Aqua

S9 Board-Level Takeaway

This incident demonstrates that authenticated access to release infrastructure can bypass downstream security controls entirely

Because CVE-2026-33634 is in the KEV catalog, this issue should be treated as a confirmed active exploitation risk with immediate governance and remediation significance, not merely an emerging threat.

Organizational risk stems from:

·        Trust assumptions

·        Lack of dependency validation

·        Overreliance on upstream integrity without independent verification

Board oversight should ensure:

·        Supply chain trust verification mechanisms

·        Dependency governance enforcement

·        Continuous validation of control effectiveness

S10 Supply Chain Attack Overview

The Trivy incident represents a supply chain attack in which an adversary used compromised credentials to modify trusted upstream distribution channels, including GitHub releases, GitHub Actions, and Docker Hub images, causing downstream systems to retrieve and execute malicious components. The attack bypasses traditional exploitation by targeting the trust relationship between software publishers and consumers, allowing poisoned artifacts to be delivered through legitimate update and dependency mechanisms. Once integrated into CI/CD pipelines, these components execute as part of normal workflows, enabling credential theft and downstream access without triggering conventional exploit detection mechanisms.

S11 Affected Product / Trust Dependency Overview

Primary Product

Trivy vulnerability scanner and associated ecosystem components

Affected Components

• Trivy binary releases

• GitHub Action: trivy-action

• GitHub Action: setup-trivy

• Docker Hub Trivy images

Trust Dependency Role

• Used within CI/CD pipelines to:

  • Perform vulnerability scanning

  • Prepare runtime environments

  • Enforce security validation

Critical Trust Assumption

• Upstream releases and version tags are authentic and safe

Trust Boundary Location

• Between:

  • Upstream distribution channels

  • CI/CD execution environments

Failure Condition

• Compromised upstream artifacts are executed as trusted components

S12 Enabling Vulnerability and Exposure Context

Enabling Condition

Compromised credentials allowing modification of upstream release and distribution infrastructure

CVE Context

CVE-2026-33634 is associated with the broader Trivy ecosystem but is not a primary driver of this incident and does not represent the core attack mechanism

Attack Mechanism

·        Publishing malicious releases

·        Overwriting version tags

·        Replacing GitHub Action references

·        Distributing compromised container images

Security Impact

·        Execution of attacker-controlled code within CI/CD pipelines

·        Credential harvesting from pipeline execution environments

Exposure Conditions

Use of:

·        Mutable tags

·        Unpinned dependencies

·        Automated dependency retrieval

S13 Exploitability, Patch, and Exposure Management Status

Exploitability

High in environments consuming affected artifacts through automated or trusted dependency mechanisms

Attack Preconditions

·        No direct compromise of target systems required

·        Only dependency consumption within CI/CD workflows

KEV Status

Confirmed in the CISA Known Exploited Vulnerabilities catalog

KEV Prioritization Implication

Immediate remediation priority. KEV inclusion means the vulnerability should be treated as confirmed exploited in the wild and prioritized accordingly within vulnerability management and incident response workflows.

EEP Statement

EEP is a forward-looking analytic measure of operational exploitation potential, not a statement of confirmed exploitation, KEV inclusion, or incident activity.

Patch / Remediation Status

·        Malicious artifacts removed from upstream sources

·        Safe versions and tags restored by the vendor

·        Organizations must:

o   Rotate credentials

o   Validate artifact usage

o   Rebuild trust in pipeline components

o   Hunt for lingering exposure through intermediary caches
Aqua’s advisory identifies patched or safe references including setup-trivy 0.2.6, trivy-action 0.35.0, and unaffected Trivy usage such as v0.69.3 or earlier, pinned digests, and source builds.

Exposure Management Risk

High due to:

·        Confirmed exploitation

·        Multi-channel trusted-distribution compromise

·        Potential persistence in cached or mirrored artifacts after upstream cleanup. Aqua explicitly warns removed malicious artifacts may linger in intermediary caches.

S14 Sectors / Countries Affected

·       Technology and SaaS providers

·       Financial services

·       Healthcare

·       Government and defense

·       Any organization using Trivy within CI/CD pipelines

Geographic Scope

·       Global

S15 Adversary Capability Profiling

Skill Level

Moderate

Technique Requirements

·       Access to publishing credentials

·       Ability to modify release assets and distribution channels

Operational Maturity

High impact achieved through low-complexity access abuse

Scalability

Very high due to widespread dependency consumption

Operational Objectives

·       Credential theft

·       Pipeline compromise

·       Downstream system access

S16 Targeting Probability Assessment

Highest Probability Targets

·       CI/CD-intensive organizations using Trivy

Moderate Probability Targets

·       Organizations using third-party GitHub Actions without validation

Lower Probability Targets

·       Environments enforcing dependency pinning and verification

Targeting Drivers

·       Pipeline automation

·       Credential exposure potential

·       Dependency trust model

S17 MITRE ATT&CK Chain Flow Mapping

Initial Access

·       T1078 – Valid Accounts

·       Use of compromised credentials to access release infrastructure

Initial Access

·       T1195 – Supply Chain Compromise

·       Injection of malicious artifacts into trusted distribution channels

Execution

·       T1059 – Command and Scripting Interpreter

·       Malicious components executed within CI/CD workflows

Credential Access

·       T1552 – Unsecured Credentials

·       Extraction of pipeline secrets during execution

Defense Evasion

·       T1036 – Masquerading

·       Malicious artifacts presented as legitimate versions

Persistence

·       T1574 – Hijack Execution Flow

·       Continued execution via trusted pipelines

Impact

·       Not observed in currently available reporting; may occur during post-exploitation depending on attacker objectives and target environment

S18 Attack Path Narrative

The attack begins with adversary access to credentials capable of modifying Trivy release and distribution infrastructure, enabling direct manipulation of upstream assets without requiring exploitation of target environments. Using these credentials, the attacker publishes malicious Trivy binaries, force-modifies GitHub Action tags (trivy-action, setup-trivy), and distributes compromised container images through Docker Hub, poisoning multiple trusted acquisition channels.

Downstream CI/CD pipelines ingest these artifacts through standard dependency retrieval mechanisms, including version tags, mutable references, and automated pulls from upstream repositories. Because pipelines commonly trust these sources and do not enforce immutability or verification, the malicious components are treated as legitimate and executed during build, scan, or deployment stages.

Execution occurs within trusted automation contexts where environment variables, API tokens, cloud credentials, and repository access secrets are accessible. The malicious payload leverages this execution context to access and extract these credentials, enabling exfiltration to attacker-controlled infrastructure.

The attacker can then use harvested credentials to access additional systems, including source repositories, container registries, and cloud environments, extending the compromise beyond the initial pipeline. Because the attack leverages trusted execution paths, compromised artifacts may propagate across multiple environments and persist through repeated pipeline executions.

Exposure may extend retroactively due to cached artifacts and previously executed pipelines, requiring organizations to analyze historical usage to determine the full scope of compromise.

S19 Attack Chain Risk Amplification Summary

Upstream Trust Inheritance

Compromised artifacts inherit legitimacy from official distribution channels, allowing malicious components to bypass downstream validation controls

Automated Execution Scaling

CI/CD pipelines automatically retrieve and execute dependencies, enabling rapid and repeated propagation across environments

Credential Exposure Amplification

Pipeline execution contexts expose sensitive credentials, enabling attacker access beyond the initial compromised component

Multi-Channel Distribution

Simultaneous compromise of GitHub releases, GitHub Actions, and Docker images increases likelihood and scale of exposure

Cache Persistence Risk

Malicious artifacts may remain in local caches, intermediate registries, and mirrored repositories, extending exposure beyond initial remediation

Silent Execution Risk

Attack operates within expected pipeline behavior, reducing detection likelihood

Retroactive Exposure Window

Organizations must assess historical pipeline executions to determine full compromise scope

S20 Tactics, Techniques, and Procedures

T1078 – Valid Accounts

Adversary uses compromised credentials to access and modify release infrastructure

T1195 – Supply Chain Compromise

Malicious artifacts are introduced into trusted distribution channels

T1036 – Masquerading

Malicious components are presented as legitimate versions or tags

T1059 – Command and Scripting Interpreter

Malicious code executes within CI/CD workflows

T1528 – Steal Application Access Token

Pipeline tokens and access credentials are extracted during execution

T1071 – Application Layer Protocol

Exfiltration of credentials and data to attacker-controlled infrastructure

Conditional Post-Exploitation Behaviors

Not observed in currently available reporting; may occur during post-exploitation depending on attacker objectives and target environment

S20A Adversary Tradecraft Summary

Tradecraft Theme

Credential-enabled compromise of trusted software distribution channels

Operational Approach

Use of authenticated access to modify upstream release assets rather than exploiting downstream systems

Core Tradecraft Insight

Abuse of centralized trust within CI/CD ecosystems, where a single upstream compromise propagates across dependent environments

Stealth Characteristics

Delivery through legitimate channels and execution within normal pipeline workflows reduces detection likelihood

Scalability

High
One upstream compromise impacts multiple downstream environments

Primary Objective

Credential theft from pipeline execution contexts

Secondary Objectives

Persistence and expansion of access using stolen credentials

Adversary Efficiency Assessment

High
Converts trusted automation into a scalable compromise mechanism

S21 Detection Strategy Overview

Detection of this supply chain attack requires correlation across upstream artifact integrity, CI/CD pipeline execution behavior, and credential access patterns. Because the attack leverages trusted distribution channels and executes within legitimate workflows, signature-based detection is insufficient.

Effective detection must correlate signals across three primary telemetry pillars:

·        Source control and CI/CD telemetry to identify unauthorized modification of release assets, tags, and dependency references

·        Endpoint and execution telemetry to detect anomalous process behavior within pipeline runners

·        Network telemetry to identify outbound communication associated with credential exfiltration

The strategy focuses on detecting trust-boundary violations, anomalous dependency ingestion, and credential access patterns inconsistent with expected pipeline execution.

S22 Primary Detection Signals

Release and Dependency Integrity Signals

·        Force-push or modification events on version tags associated with trivy-action or setup-trivy

·        Changes in referenced GitHub Action versions without corresponding repository release activity

·        Pipeline retrieval of newly published or previously unused artifact versions

Pipeline Execution Signals

·        Execution of pipeline steps invoking binaries or scripts not previously observed in baseline workflows

·        Changes in job execution sequences within CI/CD workflows

·        Invocation of external scripts or commands during scanning or setup phases not present in prior pipeline runs

Credential Access Signals

·        Access to environment variables or secrets outside defined pipeline stages

·        Token usage by processes not mapped to expected CI/CD execution components

·        Access to repository, registry, or cloud credentials during non-authentication phases

Network Communication Signals

·        Outbound connections from pipeline runners to domains or IPs not previously associated with build or scan processes

·        DNS queries initiated during pipeline execution that deviate from established baselines

·        Data transfer patterns inconsistent with standard dependency retrieval or build operations

S23 Telemetry Requirements

Source Control and CI/CD Telemetry

·        GitHub audit logs capturing:

o   tag modification and force-push events

o   release publishing activity

·        GitHub Actions workflow and runner logs capturing:

o   execution steps

o   job sequence changes

o   command invocation patterns

Endpoint and Execution Telemetry

·        EDR telemetry from build agents and runners capturing:

o   process execution

o   command-line arguments

o   script invocation patterns

Network Telemetry

·        DNS logs capturing:

o   domain lookups originating from pipeline runners

·        Web proxy or firewall logs capturing:

o   outbound connections

o   data transfer behavior

Credential and Identity Telemetry

·        Access logs capturing:

o   API token usage

o   cloud credential access

o   repository and registry authentication events

S24 Detection Opportunities and Gaps

Detection Opportunities

·        Identification of unauthorized tag or release modification activity in upstream repositories

·        Detection of pipeline execution deviations through baseline comparison

·        Monitoring for abnormal credential access patterns during CI/CD runs

·        Correlation of execution anomalies with outbound network activity

Detection Gaps

·        Limited visibility into execution behavior of third-party GitHub Actions

·        Reduced telemetry fidelity in ephemeral pipeline environments

·        Lack of artifact integrity validation for externally sourced dependencies

·        Insufficient correlation across CI/CD, endpoint, and network telemetry layers

S25 Ultra-Tuned Detection Engineering Rules

Suricata

Rule Name

CI/CD Runner HTTP POST to Non-Allowlisted External Destination

Purpose

Detect outbound HTTP POST requests from CI/CD runner infrastructure to non-allowlisted external destinations. In this campaign, compromised Trivy artifacts and related GitHub Actions can execute inside trusted pipeline workflows and attempt outbound communication to attacker-controlled infrastructure for credential theft follow-on activity.

ATT&CK Technique

T1071.001 – Application Layer Protocol: Web Protocols

Telemetry Dependency

Suricata HTTP visibility for CI/CD runner traffic
Accurate identification of CI/CD runner subnets, hosts, or VLANs
Environment-specific allowlist covering approved source-control, package, artifact, and business workflow destinations
Best results where outbound web traffic is proxied or decrypted; fidelity drops significantly where HTTPS inspection is unavailable

Tuning Explanation

This rule must be restricted to CI/CD runner assets and used with a mature allowlist. It is intended to catch unexpected outbound POST behavior from runner infrastructure after execution of poisoned dependencies, not general web traffic. Approved destinations such as GitHub, package registries, artifact repositories, internal APIs, and sanctioned cloud services should be suppressed through pass rules or upstream filtering.

Detection Logic

Alert on outbound HTTP POST traffic from CI/CD runner infrastructure to the external network.

Operational Context

This rule is an early-warning network anomaly detector for pipeline environments where runners normally retrieve dependencies but do not routinely POST data to varied internet destinations. It is most valuable when correlated with:

·        unexpected Trivy-related dependency pulls

·        anomalous GitHub Actions execution

·        suspicious process activity on build agents

Logical Notes

This rule does not prove credential theft by itself. Its value is in identifying suspicious outbound web behavior from trusted automation infrastructure that should have narrow and predictable communication patterns.

Rule Regret Check

Deployment caution

Do not deploy broadly across enterprise networks. Restrict to CI/CD runner infrastructure and maintain an allowlist or the rule will generate noise.

Confidence caution

Confidence decreases sharply where HTTPS traffic is not decrypted or proxied because destination context may be limited.

Coverage value

High as an early-warning signal for suspicious outbound communication from poisoned pipeline execution paths.

Execution Validity Status

Conditional production-ready

System-Ready Code

alert http $CI_CD_NET any -> $EXTERNAL_NET any (
    msg:"CYBERDAX CI/CD runner HTTP POST to non-allowlisted external destination";
    flow:established,to_server;
    http.method;
    content:"POST";
    classtype:policy-violation;
    sid:2100001;
    rev:3;
)

Rule Name

CI/CD Runner Large Outbound HTTP POST Payload

Purpose

Detect probable outbound data transfer from CI/CD runner infrastructure by identifying large HTTP POST payloads sent to external destinations. In this campaign, malicious Trivy ecosystem components executed inside pipelines can access tokens, API keys, and environment secrets, then transmit them externally.

ATT&CK Technique

T1041 – Exfiltration Over C2 Channel

Telemetry Dependency

Suricata HTTP inspection with payload-size visibility
CI/CD runner network scoping
Destination allowlisting for legitimate artifact uploads or external business integrations
Strongly benefits from SSL interception, web proxy visibility, or plaintext HTTP inspection

Tuning Explanation

This rule is intended to be a higher-confidence exfiltration detector than Rule 1 by requiring materially sized outbound POST bodies. The payload threshold should be tuned to the environment. If CI/CD jobs legitimately upload artifacts externally, those destinations must be excluded or handled separately.

Detection Logic

Alert on outbound HTTP POST requests from CI/CD runner infrastructure when the payload size exceeds expected baseline thresholds.

Operational Context

This rule is best deployed in environments where pipeline runners normally pull dependencies but do not perform frequent large outbound uploads to the public internet. It is particularly useful during incident triage when validating whether suspicious pipeline execution led to probable exfiltration behavior.

Logical Notes

This rule is intentionally narrower than Rule 1. Rule 1 identifies suspicious outbound POST behavior. Rule 2 is designed to raise confidence when that behavior also includes likely outbound transfer volume.

Rule Regret Check

Deployment caution

Requires careful exclusion of legitimate artifact upload paths, software publishing workflows, and approved cloud destinations.

Confidence caution

Even with size thresholds, this rule indicates suspicious outbound transfer behavior rather than proving the exact content of exfiltrated material.

Coverage value

High for practical identification of likely outbound data transfer from compromised runner infrastructure.

Execution Validity Status

Conditional production-ready

System-Ready Code

alert http $CI_CD_NET any -> $EXTERNAL_NET any (
    msg:"CYBERDAX CI/CD runner large outbound HTTP POST payload";
    flow:established,to_server;
    http.method;
    content:"POST";
    dsize:>1000;
    classtype:exfiltration;
    sid:2100002;
    rev:3;
)

Rule 3

Rule Name

CI/CD Runner Suspicious High-Entropy DNS Query

Purpose

Detect suspicious high-entropy DNS queries originating from CI/CD runner infrastructure that may indicate malware callback, dynamically generated infrastructure, or exfiltration support traffic after execution of compromised Trivy-related dependencies.

ATT&CK Technique

T1071.004 – Application Layer Protocol: DNS

Telemetry Dependency

Suricata DNS visibility from CI/CD runner infrastructure
Accurate identification of runner hosts or subnets
DNS logging sufficient to inspect query strings
Environment-specific suppression for known enterprise tooling, CDNs, telemetry platforms, and approved package ecosystems

Tuning Explanation

This rule must be treated as a corroborating or hunt-support rule, not a primary production alert. High-entropy DNS can be noisy in modern environments. It should be used to strengthen investigations where other indicators already exist, such as anomalous runner execution or suspicious outbound POST traffic.

Detection Logic

Alert on DNS queries from CI/CD runner infrastructure containing unusually long or random-looking labels.

Operational Context

This rule is most useful when pipeline runners normally communicate with a stable and predictable set of package, artifact, and source-control domains. In mature environments, it should be correlated with:

·        unexpected pipeline execution behavior

·        outbound HTTP POST anomalies

·        suspicious credential-access events from endpoint or SIEM tooling

Logical Notes

This rule is intentionally not positioned as a primary detection for this campaign. It is a supporting signal that helps identify suspicious communications from runner infrastructure when combined with stronger execution or exfiltration indicators.

Rule Regret Check

Deployment caution

Will produce false positives without aggressive allowlisting and runner-only scoping.

Confidence caution

Do not escalate this as a standalone high-confidence alert. Use it as corroborating evidence or hunt support.

Coverage value

Medium as a practical corroborating signal for suspicious outbound communications from CI/CD runner infrastructure.

Execution Validity Status

Conditional production-ready / correlation-required

System-Ready Code

alert dns $CI_CD_NET any -> any any (
    msg:"CYBERDAX CI/CD runner suspicious high-entropy DNS query";
    dns.query;
    pcre:"/([a-z0-9]{20,})/i";
    classtype:bad-unknown;
    sid:2100003;
    rev:3;
)

SentinelOne

Rule Name

CI/CD Runner Unexpected Executable Launch

Purpose

Detect execution of non-baseline binaries inside CI/CD runner environments where poisoned Trivy-related components may introduce attacker-controlled executables into otherwise deterministic workflows.

ATT&CK Technique

T1059 – Command and Scripting Interpreter

Telemetry Dependency

SentinelOne Deep Visibility process creation telemetry
Reliable identification of CI/CD runner assets through site, group, tag, or hostname convention
Local baseline of expected executable names used in build, scan, and dependency setup workflows

Tuning Explanation

This rule should be limited to CI/CD runner systems and tuned with an allowlist of expected executables used by:

·        runner services

·        Trivy execution

·        container tooling

·        approved setup actions

The rule is intended to identify newly introduced or unexpected executables during pipeline activity, not to detect all binary launches on build systems.

Detection Logic

Detect process launches on CI/CD runner systems where the executable name falls outside the approved baseline for runner workflows.

Operational Context

This is a primary execution-anomaly rule for the campaign. It is strongest where pipelines are stable and tooling is predictable.

Logical Notes

This rule is designed to catch malicious executable introduction. It does not require network visibility and does not depend on known IOCs.

Rule Regret Check

Deployment caution

Requires a maintained executable baseline for CI/CD runners or the alert volume will increase during legitimate pipeline changes.

Confidence caution

Confidence decreases in highly dynamic engineering environments where runner tooling changes frequently.

Coverage value
Very High for detecting malicious execution introduced by poisoned dependencies.

Execution Validity Status
Production-ready with baseline

System-Ready Code

event.type = "Process Creation"
AND agent.group.name = "CI-CD-Runners"
AND tgt.process.image.path NOT CONTAINS ANY ("\\runner\\", "\\docker\\", "\\trivy\\")
AND tgt.process.name NOT IN ("trivy.exe","trivy","bash","sh","python","python3","node","docker","containerd","git","curl","tar","gzip")

Rule Name
CI/CD Runner Suspicious Interpreter Spawn from Trivy or Setup Workflow

Purpose

Detect unexpected interpreter execution spawned from Trivy-related setup or runner workflow lineage, which may indicate malicious script execution introduced through compromised GitHub Actions or poisoned dependencies.

ATT&CK Technique
T1059 – Command and Scripting Interpreter

Telemetry Dependency

SentinelOne Deep Visibility process ancestry telemetry
Command-line visibility
Reliable parent-child process tracking on runner hosts

Tuning Explanation
This rule should focus on interpreters launched from:

·        Trivy execution context

·        setup-trivy style workflow context

·        runner orchestration processes

Suppress known-good interpreter usage where CI/CD jobs intentionally run approved scripts.

Detection Logic

Detect shell or scripting interpreter launches where the parent or grandparent process belongs to Trivy-related setup, runner orchestration, or dependency execution lineage, but the behavior is not part of the approved workflow baseline.

Operational Context

This is a behavioral rule intended to detect malicious script staging and execution after compromised dependency ingestion.

Logical Notes

This rule is narrower than Rule 1. Rule 1 detects unexpected executables broadly. Rule 2 specifically targets interpreter-driven malicious behavior in workflow lineage.

Rule Regret Check

Deployment caution
Requires understanding of legitimate interpreter use in build jobs and setup actions.

Confidence caution

Can alert on legitimate custom automation if scripting behavior is not well baselined.

Coverage value
High for post-ingestion script execution associated with poisoned runner workflows.

Execution Validity Status
Production-ready with tuning

System-Ready Code

event.type = "Process Creation"
AND agent.group.name = "CI-CD-Runners"
AND tgt.process.name IN ("bash","sh","python","python3","node","pwsh","powershell")
AND src.process.name IN ("trivy","runner","docker","node","bash","sh")
AND tgt.process.cmdline NOT CONTAINS ANY ("approved-script","known-good-workflow")

Rule Name
CI/CD Runner Suspicious Secret Harvesting Command Behavior

Purpose

Detect command execution patterns consistent with secret harvesting inside CI/CD runner environments, including attempts to enumerate environment variables, read credential-bearing files, or access token material during workflow execution.

ATT&CK Technique

T1528 – Steal Application Access Token

Telemetry Dependency

SentinelOne Deep Visibility process creation telemetry
Command-line visibility
Process ancestry visibility
Local knowledge of expected credential-handling utilities in pipeline jobs

Tuning Explanation

This rule should focus on suspicious secret-access commands that are atypical for normal runner workflows, including:

·        broad environment enumeration

·        direct reads of token-bearing paths

·        shell usage patterns associated with dumping secrets for exfiltration or reuse

Known-good secret initialization scripts and approved credential brokers should be excluded.

Detection Logic

Detect shell or utility execution on CI/CD runner systems where command lines indicate broad environment enumeration, token-file access, or direct reads of credential-bearing paths outside expected credential-handling processes.

Operational Context

This rule targets the campaign’s primary operational objective: theft of usable CI/CD secrets and access tokens.

Logical Notes
This rule is stronger than generic keyword search because it is restricted to runner systems and intended for suspicious credential-harvesting patterns, not all secret use.

Rule Regret Check

Deployment caution
Requires exclusions for approved secret bootstrap scripts, vault clients, and normal token initialization behavior.

Confidence caution
Some debugging or troubleshooting workflows may resemble secret enumeration if not excluded.

Coverage value
Very High for detecting the campaign’s central attacker objective.

Execution Validity Status

Conditional production-ready

System-Ready Code

event.type = "Process Creation"
AND agent.group.name = "CI-CD-Runners"
AND tgt.process.name IN ("bash","sh","cat","grep","find","env","printenv","python","python3")
AND tgt.process.cmdline CONTAINS ANY ("/proc/self/environ","/proc/*/environ",".npmrc",".docker/config.json","GITHUB_TOKEN","AWS_ACCESS_KEY_ID","AZURE_CLIENT_SECRET","GOOGLE_APPLICATION_CREDENTIALS","printenv","env")
AND src.process.name NOT IN ("approved-vault-client","approved-bootstrap")

Rule Name
CI/CD Runner Suspicious Process Followed by External Network Connection

Purpose

Detect suspicious process execution on CI/CD runner systems followed by outbound network communication to external destinations, consistent with secret exfiltration or attacker-controlled callback behavior after poisoned dependency execution.

ATT&CK Technique

T1071.001 – Application Layer Protocol: Web Protocols

Telemetry Dependency

SentinelOne Deep Visibility process telemetry
SentinelOne network connection telemetry
Ability to correlate process and outbound connection activity on runner systems
Runner scoping and local destination baseline

Tuning Explanation
This rule should prioritize suspicious processes launched during:

·        Trivy execution

·        setup workflow execution

·        dependency ingestion steps

Known-good destinations such as GitHub, approved registries, artifact repositories, and sanctioned internal APIs should be excluded where possible.

Detection Logic

Detect processes on CI/CD runner systems that initiate outbound external network connections after suspicious or non-baseline process execution.

Operational Context
This is a high-value correlation rule bridging endpoint behavior with likely exfiltration or callback activity. It is strongest when paired with Rule 1 or Rule 3 hits.

Logical Notes

This rule does not prove successful exfiltration. It identifies suspicious process-linked outbound communication that should be escalated quickly in runner environments.

Rule Regret Check

Deployment caution
Requires destination tuning and may generate noise where pipelines call many external services.

Confidence caution
Confidence increases substantially when correlated with suspicious executable or secret-harvesting activity.

Coverage value
High for detecting active follow-on communication from compromised runner processes.

Execution Validity Status
Production-ready with tuning

System-Ready Code

event.type = "Network Connection"
AND agent.group.name = "CI-CD-Runners"
AND network.direction = "OUTGOING"
AND tgt.process.name NOT IN ("trivy","docker","git","curl","node","bash","sh")
AND dst.ip.is_private = false

Splunk

Rule Name

Trivy Reference Drift Outside Approved Change Window

Purpose

Detect unexpected changes in Trivy-related versions, tags, commit SHAs, or GitHub Action references used by CI/CD workflows outside approved deployment or maintenance windows. In this campaign, poisoned Trivy ecosystem components were introduced through trusted release channels and action references, making unauthorized reference drift a high-value ingestion-stage signal.

ATT&CK Technique

T1195 – Supply Chain Compromise

Telemetry Dependency

GitHub Actions workflow logs
CI/CD pipeline execution logs
Normalized extraction of Trivy-related action references, tags, versions, or commit SHAs
Change-management window data or approved rollout metadata

Tuning Explanation

This rule should compare observed Trivy references against an approved baseline or allowlist rather than relying only on first-seen values. It should alert when:

·        a workflow uses a non-approved Trivy reference

·        a mutable tag appears where pinned references are expected

·        a Trivy-related reference changes outside an approved rollout window

Suppress known change windows, approved maintenance events, and authorized migration periods.

Detection Logic

Identify CI/CD workflow executions that invoke Trivy-related versions, tags, or action references not present in the approved baseline or occurring outside approved change windows.

Operational Context

This is an ingestion-stage control detection. It is strongest in environments that standardize Trivy usage and maintain a controlled set of approved action references or digests.

Logical Notes

This rule is intentionally baseline-driven rather than novelty-driven. Its purpose is to catch unauthorized dependency drift, not simply any newly seen value.

Rule Regret Check

Deployment caution

Requires a maintained reference baseline or allowlist and access to approved rollout context.

Confidence caution

Confidence drops if engineering teams frequently change Trivy references without structured change controls.

Coverage value

High for detecting downstream consumption of poisoned or unauthorized Trivy-related dependencies.

Execution Validity Status

Conditional production-ready

System-Ready Code

index=ci_cd OR index=github_actions OR index=devops
("trivy-action" OR "setup-trivy" OR "aquasecurity/trivy" OR "trivy:")
| rex field=_raw "(?<trivy_ref>(trivy-action[:@][^ \"\r\n\t]+|setup-trivy[:@][^ \"\r\n\t]+|aquasecurity\/trivy[:@][^ \"\r\n\t]+|trivy:[^ \"\r\n\t]+))"
| search trivy_ref=*
| lookup approved_trivy_references trivy_ref OUTPUT trivy_ref as approved_ref
| eval approved_status=if(isnull(approved_ref),"unapproved","approved")
| where approved_status="unapproved"
| table time repo pipelinename host user trivy_ref approved_status

Rule Name

CI/CD Runner Suspicious Process Chain After Trivy or Setup Execution

Purpose

Detect suspicious process execution chains on CI/CD runner systems following Trivy-related execution or setup activity. This supports detection of malicious runner-side behavior introduced by poisoned Trivy binaries or compromised GitHub Actions.

ATT&CK Technique

T1059 – Command and Scripting Interpreter

Telemetry Dependency

Splunk ingestion of endpoint process telemetry from EDR, Sysmon, or equivalent sources
Runner asset identification through host tagging, asset inventory, or lookup
Parent-child process telemetry with command-line visibility

Tuning Explanation

Focus on shells, interpreters, and utility execution spawned from:

·        Trivy execution context

·        setup-trivy workflow context

·        runner orchestration processes

Exclude approved bootstrap scripts, sanctioned helper utilities, and known pipeline automation.

Detection Logic

Detect shell, interpreter, or utility execution on runner systems where parent or grandparent context indicates Trivy-related setup, scan, or runner lineage, but the execution is outside the approved baseline.

Operational Context

This is one of the strongest Splunk detections for the campaign because it combines runner context, lineage, and behavioral deviation rather than relying on static indicators.

Logical Notes

This rule complements endpoint-native detections by providing SIEM-level correlation across multiple process telemetry sources.

Rule Regret Check

Deployment caution

Requires reliable parent-child process normalization and accurate runner asset scoping.

Confidence caution

Noise will increase in environments with extensive custom scripting unless pipeline-specific exclusions are maintained.

Coverage value

Very High for malicious execution following poisoned dependency ingestion.

Execution Validity Status

Production-ready with baseline

System-Ready Code

(index=edr OR index=sysmon OR index=endpoint)
(host_category="ci_cd_runner" OR asset_role="ci_cd_runner")
(
    parent_process_name IN ("trivy","runner","docker","bash","sh","node")
    OR parent_process_cmdline="*trivy*"
    OR process_parent_path="*setup-trivy*"
)
process_name IN ("bash","sh","python","python3","pwsh","powershell","curl","wget","nc","tar")
| lookup approved_runner_process_chains parent_process_name process_name OUTPUT process_name as approved_chain_match
| where isnull(approved_chain_match)
| stats count min(_time) as firstTime max(_time) as lastTime by host user process_name process_cmdline parent_process_name parent_process_cmdline
| convert ctime(firstTime) ctime(lastTime)

Rule Name

Runner Secret Harvesting Followed by External Network Activity

Purpose

Detect likely secret-harvesting activity on CI/CD runner systems followed by near-term outbound communication to external destinations. This aligns directly to the campaign objective of stealing tokens and credentials from poisoned pipeline execution.

ATT&CK Technique

T1528 – Steal Application Access Token
T1071.001 – Application Layer Protocol: Web Protocols

Telemetry Dependency

Process telemetry with command-line visibility
Network telemetry with host identity preserved across data sources
Time-synchronized endpoint and network logs
Reliable runner asset scoping
Destination enrichment or a workable definition of external communication

Tuning Explanation

This rule should correlate:

·        suspicious secret-enumeration or token-access commands

·        with outbound network activity from the same runner within a short time window

Use exclusions for approved vault clients, sanctioned publishing workflows, known external APIs, and expected package or artifact interactions.

Detection Logic

Detect suspicious credential-access commands on CI/CD runners followed within a short window by outbound communication to non-approved external destinations.

Operational Context

This is a high-value sequence correlation rule. It is stronger than isolated secret-access or isolated outbound network detections because it models the likely attacker workflow.

Logical Notes

This rule depends on endpoint and network telemetry joining cleanly on host identity and time. Where that normalization is weak, use it as a hunt or high-value correlation search rather than a fully automated alert.

Rule Regret Check

Deployment caution

Requires synchronized endpoint and network telemetry plus reliable host identity normalization across sources.

Confidence caution

Do not overtrust this rule in environments where outbound network logs are incomplete or runner identity is inconsistent across telemetry sets.

Coverage value

Very High where cross-source correlation is mature; Medium where telemetry joining is inconsistent.

Execution Validity Status

Conditional production-ready

System-Ready Code

(
    search index=edr (host_category="ci_cd_runner" OR asset_role="ci_cd_runner")
    process_name IN ("bash","sh","cat","grep","find","env","printenv","python","python3")
    (process_cmdline="*/proc/*/environ*" OR process_cmdline="*printenv*" OR process_cmdline="* env " OR process_cmdline="GITHUB_TOKEN*" OR process_cmdline="*AWS_ACCESS_KEY_ID*" OR process_cmdline="*AZURE_CLIENT_SECRET*" OR process_cmdline="*GOOGLE_APPLICATION_CREDENTIALS*" OR process_cmdline="*.docker/config.json*" OR process_cmdline="*.npmrc*")
    | eval phase="secret_access"
    | table time host processname process_cmdline phase
)
| append [
    search index=network (host_category="ci_cd_runner" OR asset_role="ci_cd_runner")
    (direction=outbound OR network_direction=outbound)
    | eval external_dest=if(cidrmatch("10.0.0.0/8",dest_ip) OR cidrmatch("172.16.0.0/12",dest_ip) OR cidrmatch("192.168.0.0/16",dest_ip),0,1)
    | where external_dest=1
    | eval phase="outbound_net"
    | table time host destip dest_domain bytes_out phase
]
| sort 0 host time
| streamstats current=f last(phase) as prevphase last(_time) as prev_time by host
| where phase="outbound_net" AND prev_phase="secret_access" AND (_time - prev_time) <= 300
| table host prev_time time destip dest_domain bytes_out

Rule Name

Unauthorized Trivy-Related Tag or Release Modification

Purpose

Detect suspicious tag modification, force-push, or release publication activity affecting Trivy-related repositories or mirrored internal repositories. This supports upstream integrity monitoring where GitHub or source-control audit telemetry is available.

ATT&CK Technique

T1078 – Valid Accounts
T1195 – Supply Chain Compromise

Telemetry Dependency

GitHub audit logs or equivalent repository activity logs ingested into Splunk
Normalized fields for actor, action, repo, tag, release, and push events
Coverage for Trivy-related repositories, actions, or organizational mirrors
Optional enrichment for approved release bots and authorized maintainers

Tuning Explanation

Focus on:

·        tag deletion or recreation

·        force-push behavior

·        unexpected release publication or update

·        actor activity outside known release engineering workflows

Suppress approved release bots, authorized maintainers, and known release windows.

Detection Logic

Detect suspicious tag or release modification activity affecting Trivy-related repositories, especially force-push, tag recreation, or release publication by unexpected actors.

Operational Context

This rule is highly valuable when upstream audit coverage exists. In environments without GitHub audit normalization, it should be treated as a conditional SIEM analytic rather than a guaranteed production alert.

Logical Notes

This rule’s value depends heavily on the quality of source-control audit logging. It is strongest in enterprises that ingest GitHub Enterprise Cloud audit data or equivalent mirrored-source telemetry.

Rule Regret Check

Deployment caution

Action names and field names vary by GitHub ingestion method and normalization pipeline; local adaptation is likely required.

Confidence caution

Without release-bot suppression and actor allowlisting, legitimate engineering operations may resemble suspicious tag activity.

Coverage value

High where repository audit telemetry is mature; Partial where audit detail is limited.

Execution Validity Status

Conditional production-ready / local adaptation required

System-Ready Code

index=github_audit (repo="*trivy*" OR repo="*trivy-action*" OR repo="*setup-trivy*")
(action IN ("git.tag.create","git.tag.delete","repo.release.create","repo.release.update","git.push","git.force_push") OR operation IN ("tag.create","tag.delete","release.create","release.update","force_push"))
| eval suspicious_action=if(match(action,"force_push|git.tag.delete|git.tag.create|repo.release.create|repo.release.update") OR match(operation,"force_push|tag.create|tag.delete|release.create|release.update"),1,0)
| where suspicious_action=1
| lookup approved_release_actors actor OUTPUT actor as approved_actor
| where isnull(approved_actor)
| stats count min(_time) as firstTime max(_time) as lastTime by actor repo action operation src_ip user_agent
| convert ctime(firstTime) ctime(lastTime)

Elastic

Rule Name

CI/CD Workflow Unapproved Trivy Reference Usage

Purpose

Detect CI/CD workflow executions invoking Trivy-related actions, images, or binaries that are not part of an approved reference baseline. In this campaign, poisoned Trivy components were distributed through trusted release and action channels, making unauthorized reference usage a high-value ingestion-stage detection.

ATT&CK Technique

T1195 – Supply Chain Compromise

Telemetry Dependency

Elastic ingestion of CI/CD workflow logs, GitHub Actions logs, or build-system logs
Parsed workflow or message fields containing action references, image tags, or Trivy command invocation
Approved-reference enrichment through lookup, enrich policy, or equivalent local normalization
Pipeline, workflow, or runner identification through metadata enrichment

Tuning Explanation

This rule must rely on a maintained allowlist of approved:

·        Trivy action references

·        container image tags

·        pinned commit SHAs

·        immutable digests

It should alert only when Trivy-related references are outside the approved baseline or outside an authorized rollout window. It should not be used as a generic first-seen detector.

Detection Logic

Identify CI/CD workflow or build execution events containing Trivy-related references that are not present in the approved reference baseline.

Operational Context

This is an ingestion-stage detection for downstream use of poisoned dependencies. It is strongest in environments where dependency usage is standardized and approved references are centrally managed.

Logical Notes

This detects consumption of unauthorized Trivy-related components. It does not detect the upstream compromise directly.

Rule Regret Check

Deployment caution

Requires reliable parsing of workflow references and a maintained approved-reference enrichment source.

Confidence caution

Legitimate upgrades and emergency pin changes will alert unless rollout windows and approved exceptions are tracked.

Coverage value

High for detecting unauthorized dependency consumption.

Execution Validity Status

Conditional production-ready / enrichment required

System-Ready Code

any where
  event.dataset in ("github.actions", "ci_cd.workflow", "build.pipeline")
  and (
    stringContains(message, "trivy-action") or
    stringContains(message, "setup-trivy") or
    stringContains(message, "aquasecurity/trivy") or
    stringContains(message, "trivy:")
  )
  and not labels.approved_trivy_reference == true

Rule Name

CI/CD Runner Suspicious Interpreter Spawn from Trivy or Setup Context

Purpose

Detect shell or interpreter execution on CI/CD runner systems where the parent process or lineage indicates Trivy execution, setup-trivy workflow activity, or runner orchestration context. This supports detection of malicious runner-side script execution introduced by poisoned Trivy components.

ATT&CK Technique

T1059 – Command and Scripting Interpreter

Telemetry Dependency

Elastic Defend, Sysmon, or equivalent endpoint process telemetry
Reliable CI/CD runner identification through host tags, asset enrichment, or index scoping
Parent-child process ancestry and command-line visibility

Tuning Explanation

Focus on shell and interpreter execution launched from:

·        Trivy execution context

·        setup-trivy workflow context

·        runner orchestration processes

Exclude approved bootstrap scripts, sanctioned helper utilities, and known custom workflow automation.

Detection Logic

Detect interpreter execution on CI/CD runner systems where parent or lineage context indicates Trivy-related setup or runner workflow activity and the behavior is outside the approved baseline.

Operational Context

This is one of the strongest endpoint detections for the campaign because it captures malicious script execution after dependency ingestion.

Logical Notes

This is intentionally behavior-driven and does not depend on static indicators or known malicious hashes.

Rule Regret Check

Deployment caution

Requires accurate runner scoping and reliable process ancestry telemetry.

Confidence caution

Noise will increase where engineering teams use dynamic scripting in runner workflows without maintained exclusions.

Coverage value

Very High for malicious script execution following poisoned dependency ingestion.

Execution Validity Status

Production-ready with baseline

System-Ready Code

process where
  host.roles == "ci_cd_runner"
  and process.name in ("bash","sh","python","python3","pwsh","powershell")
  and (
process.parent.name in ("trivy","runner","docker","bash","sh","node") or
    stringContains(process.parent.command_line, "trivy") or
    stringContains(process.parent.executable, "setup-trivy")
  )
  and not process.command_line like~ ("*approved-script*", "*known-good-workflow*", "*approved-bootstrap*")

Rule Name

CI/CD Runner Suspicious Secret Enumeration or Token Material Access

Purpose

Detect command execution on CI/CD runner systems consistent with secret harvesting, including environment enumeration, token discovery, or direct access to credential-bearing paths during workflow execution.

ATT&CK Technique

T1528 – Steal Application Access Token

Telemetry Dependency

Elastic endpoint process telemetry with command-line visibility
Reliable CI/CD runner identification through host tags, asset enrichment, or index scoping
Optional file-access telemetry for higher fidelity
Approved secret-bootstrap and vault-client exclusions

Tuning Explanation

This rule should target suspicious commands that enumerate or read:

·        environment variables

·        token material

·        credential-bearing files

·        cloud credential references

Exclude approved vault clients, sanctioned token bootstrap routines, and normal secret-initialization logic.

Detection Logic

Detect suspicious environment enumeration or credential-material access commands on CI/CD runner systems outside approved workflow processes.

Operational Context

This rule addresses the campaign’s primary objective: theft of usable CI/CD tokens and secrets.

Logical Notes

This rule is stronger when correlated with suspicious execution lineage or outbound communication, but it retains standalone value when runner scoping and exclusions are mature.

Rule Regret Check

Deployment caution

Requires exclusions for approved secret-bootstrap, vault-client, and credential-broker workflows.

Confidence caution

Debugging or troubleshooting jobs may resemble secret enumeration if exclusions are incomplete.

Coverage value

Very High for detecting runner-side credential-harvesting behavior.

Execution Validity Status

Conditional production-ready

System-Ready Code

process where
  host.roles == "ci_cd_runner"
  and process.name in ("bash","sh","cat","grep","find","env","printenv","python","python3")
  and (
    process.command_line like~ ("*/proc/*/environ*") or
    process.command_line like~ ("*printenv*") or
    process.command_line like~ ("*GITHUB_TOKEN*") or
    process.command_line like~ ("*AWS_ACCESS_KEY_ID*") or
    process.command_line like~ ("*AZURE_CLIENT_SECRET*") or
    process.command_line like~ ("*GOOGLE_APPLICATION_CREDENTIALS*") or
    process.command_line like~ ("*.docker/config.json*") or
    process.command_line like~ ("*.npmrc*")
  )
  and not process.parent.name in ("approved-vault-client","approved-bootstrap")

Rule Name

CI/CD Runner Suspicious Interpreter or Utility Followed by External Network Connection

Purpose

Detect suspicious interpreter or utility execution on CI/CD runner systems followed by outbound communication to external destinations. This supports detection of exfiltration or callback behavior after malicious Trivy-related execution.

ATT&CK Technique

T1071.001 – Application Layer Protocol: Web Protocols

Telemetry Dependency

Elastic endpoint process telemetry
Elastic network connection telemetry
Common host identity across process and network events
Reliable CI/CD runner scoping
Destination enrichment or allowlisting for approved external services

Tuning Explanation

Focus on suspicious interpreters or utilities launched during:

·        Trivy execution

·        setup workflow execution

·        dependency ingestion steps

Exclude approved destinations such as GitHub, artifact registries, sanctioned APIs, and expected cloud endpoints where possible.

Detection Logic

Detect suspicious interpreter or utility execution on CI/CD runner systems followed within a short window by outbound communication to an external destination.

Operational Context

This is a high-value endpoint-plus-network correlation rule. It is narrower and higher-confidence than generic process-plus-network sequencing because it starts from suspicious runner-side execution classes.

Logical Notes

This rule is intended to complement Rule 2 and Rule 3, not replace them. It models likely attacker progression from execution to outbound communication.

Rule Regret Check

Deployment caution

Requires destination allowlisting and process baseline tuning to avoid alerts on legitimate automation.

Confidence caution

Confidence increases substantially when the process also matches suspicious lineage or secret-access behavior.

Coverage value

High for detecting active follow-on communication from compromised runner processes.

Execution Validity Status

Production-ready with tuning

System-Ready Code

sequence by host.id with maxspan=5m
  [process where
      host.roles == "ci_cd_runner"
      and process.name in ("bash","sh","python","python3","pwsh","powershell","curl","wget","nc")
      and not process.command_line like~ ("*approved-script*", "*known-good-workflow*", "*approved-bootstrap*")
  ]
  [network where
      host.roles == "ci_cd_runner"
      and network.direction == "outgoing"
      and destination.ip != null
      and not cidrmatch(destination.ip, "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16")
  ]

Rule Name

Unauthorized Trivy-Related Tag or Release Modification

Purpose

Detect suspicious tag modification, force-push, or release publication activity affecting Trivy-related repositories or mirrored internal repositories where source-control audit telemetry is available in Elastic.

ATT&CK Technique

T1078 – Valid Accounts
T1195 – Supply Chain Compromise

Telemetry Dependency

GitHub audit logs, GitHub Enterprise logs, or equivalent repository activity logs ingested into Elastic
Normalized fields for actor, repository, action, release, tag, and push activity
Optional enrichment for approved release bots and authorized maintainers
Local understanding of audit field and action-name normalization

Tuning Explanation

Focus on:

·        tag deletion or recreation

·        force-push activity

·        release publication or update outside normal release engineering workflows

·        unexpected actors modifying Trivy-related repositories

Suppress approved bots, known maintainers, and approved release windows.

Detection Logic

Detect suspicious tag or release modification activity affecting Trivy-related repositories, especially force-push or tag recreation by unexpected actors.

Operational Context

This is an upstream integrity rule. It is highly valuable where repository audit data exists, but should be treated as locally adapted where audit normalization is incomplete.

Logical Notes

This rule can detect the upstream side of the campaign before downstream runner execution occurs, but only where source-control audit visibility is mature.

Rule Regret Check

Deployment caution

Field names and action values vary significantly by GitHub ingestion method and local normalization pipeline.

Confidence caution

Without actor allowlisting and release-bot suppression, legitimate release engineering can resemble suspicious activity.

Coverage value

High where repository audit telemetry is mature; Partial where telemetry is incomplete.

Execution Validity Status

Conditional production-ready / local adaptation required

System-Ready Code

event.dataset:(github.audit OR github.enterprise.audit) and
repository.name:(*trivy* OR trivy-action OR setup-trivy) and
(event.action:(git.tag.create OR git.tag.delete OR git.force_push OR repo.release.create OR repo.release.update) or
 github.action:(tag.create OR tag.delete OR force_push OR release.create OR release.update)) and
not labels.approved_release_actor:true

QRadar

Rule Name

CI/CD Workflow Unapproved Trivy Reference Usage

Purpose

Detect CI/CD workflow or build execution events invoking Trivy-related actions, images, binaries, or references that are not part of the approved dependency baseline. In this campaign, poisoned Trivy components were distributed through trusted release and action channels, making unauthorized reference usage a high-value ingestion-stage signal.

ATT&CK Technique

T1195 – Supply Chain Compromise

Telemetry Dependency

QRadar ingestion of CI/CD workflow logs, GitHub Actions logs, or build-system logs
Custom property extraction for Trivy-related references from workflow content, action metadata, image tags, or command lines
Reference set or enrichment source containing approved Trivy references
Reliable workflow, runner, or pipeline identification

Tuning Explanation

This rule should alert only when a Trivy-related reference falls outside the approved baseline or appears outside an authorized rollout window. It should rely on a maintained reference set containing approved:

·        trivy-action references

·        setup-trivy references

·        Trivy image tags

·        pinned commit SHAs

·        immutable digests

This rule is not suitable as a raw “first seen” detector.

Detection Logic

Detect CI/CD execution events containing Trivy-related references not present in the approved reference baseline.

Operational Context

This is an ingestion-stage detection for downstream use of poisoned dependencies. It is strongest where dependency usage is standardized and approved references are centrally managed.

Logical Notes

This rule does not detect the upstream compromise directly. It detects downstream workflow consumption of unauthorized Trivy-related references.

Rule Regret Check

Deployment caution

Requires stable custom-property extraction and disciplined maintenance of approved reference sets.

Confidence caution

Legitimate upgrades, emergency pin changes, or workflow migrations will alert unless rollout windows and approved exceptions are incorporated.

Coverage value

High for detecting unauthorized or poisoned dependency consumption.

Execution Validity Status

Conditional production-ready / local enrichment and parsing required

System-Ready Code

when events match ALL of the following:
  Log Source Type in ("GitHub Actions", "CI/CD", "Build Pipeline")
  AND Event Name contains any of ("trivy-action","setup-trivy","aquasecurity/trivy","trivy:")
  AND Custom Property("Trivy_Reference") is not null
  AND NOT Reference Set Contains("Approved_Trivy_References", Custom Property("Trivy_Reference"))

Rule Name

CI/CD Runner Suspicious Interpreter Spawn from Trivy or Setup Context

Purpose

Detect suspicious shell or interpreter execution on CI/CD runner systems where parent process context indicates Trivy execution, setup workflow activity, or runner orchestration. This supports detection of malicious runner-side script execution introduced by poisoned Trivy components.

ATT&CK Technique

T1059 – Command and Scripting Interpreter

Telemetry Dependency

QRadar ingestion of endpoint process telemetry from EDR, Sysmon, or equivalent sources
Custom properties for process name, parent process name, parent command line, and command line
Reliable CI/CD runner identification through asset model, building blocks, asset tags, or reference sets

Tuning Explanation

Focus on interpreter processes launched from:

·        Trivy execution context

·        setup workflow context

·        runner orchestration processes

Exclude:

·        approved bootstrap scripts

·        sanctioned helper utilities

·        known custom pipeline automation

Because parser fidelity varies by source, this rule should be deployed only where process ancestry normalization is reliable.

Detection Logic

Detect interpreter execution on CI/CD runner assets where parent or lineage context indicates Trivy-related or setup-related activity and the process is outside the approved baseline.

Operational Context

This is one of the strongest runner-side detections for the campaign because it captures malicious script execution after poisoned dependency ingestion.

Logical Notes

This is a behavior-driven execution rule. It does not depend on known malicious hashes or static indicators.

Rule Regret Check

Deployment caution

Requires normalized process ancestry and dependable runner asset scoping.

Confidence caution

Noise increases in environments with dynamic scripting or poorly maintained workflow exclusions.

Coverage value

Very High for malicious script execution following poisoned dependency ingestion.

Execution Validity Status

Production-ready with baseline and parser validation

System-Ready Code

when events match ALL of the following:
  Log Source Type in ("Sysmon","EDR","Endpoint")
  AND Asset Category equals "CI/CD Runner"
  AND Process Name in ("bash","sh","python","python3","pwsh","powershell")
  AND (
    Parent Process Name in ("trivy","runner","docker","bash","sh","node")
    OR Parent Command Line contains "trivy"
    OR Parent Command Line contains "setup-trivy"
  )
  AND Command Line does not contain any of ("approved-script","known-good-workflow","approved-bootstrap")

Rule Name

CI/CD Runner Suspicious Secret Enumeration or Token Material Access

Purpose

Detect runner-scoped command execution consistent with secret harvesting, including environment enumeration, token discovery, or direct reads of credential-bearing paths during workflow execution.

ATT&CK Technique

T1528 – Steal Application Access Token

Telemetry Dependency

QRadar ingestion of endpoint process telemetry with command-line visibility
Reliable CI/CD runner identification through asset model, asset tags, or reference sets
Optional file-access telemetry for stronger fidelity
Exclusions for approved vault clients, credential brokers, and secret bootstrap workflows

Tuning Explanation

Focus on suspicious commands that:

·        enumerate environment variables

·        read /proc/*/environ

·        access token-bearing files

·        reference cloud credential variables or runner credential stores

This rule should be tightly scoped to runner assets and supported by exclusions for approved bootstrap and credential-broker activity.

Detection Logic

Detect suspicious environment enumeration or credential-material access commands on CI/CD runner systems outside approved workflow processes.

Operational Context

This rule targets the campaign’s primary objective: theft of usable CI/CD tokens and secrets.

Logical Notes

This rule is strongest when correlated with suspicious execution lineage or outbound communication, but it still has standalone value when runner scoping and exclusions are mature.

Rule Regret Check

Deployment caution

Requires exclusions for approved secret-bootstrap, vault-client, and credential-broker workflows.

Confidence caution

Debugging, troubleshooting, or ad hoc engineering jobs may resemble secret enumeration if exclusions are incomplete.

Coverage value

Very High for detecting runner-side credential harvesting behavior.

Execution Validity Status

Conditional production-ready

System-Ready Code

when events match ALL of the following:
  Log Source Type in ("Sysmon","EDR","Endpoint")
  AND Asset Category equals "CI/CD Runner"
  AND Process Name in ("bash","sh","cat","grep","find","env","printenv","python","python3")
  AND Command Line contains any of ("/proc/", "printenv", "GITHUB_TOKEN", "AWS_ACCESS_KEY_ID", "AZURE_CLIENT_SECRET", "GOOGLE_APPLICATION_CREDENTIALS", ".docker/config.json", ".npmrc")
  AND Parent Process Name not in ("approved-vault-client","approved-bootstrap")

Rule Name

CI/CD Runner Suspicious Interpreter or Utility Execution Followed by External Network Communication

Purpose

Detect suspicious interpreter or utility execution on CI/CD runner systems followed by outbound communication to a non-approved external destination. This supports detection of callback or exfiltration behavior after malicious Trivy-related execution.

ATT&CK Technique

T1071.001 – Application Layer Protocol: Web Protocols

Telemetry Dependency

QRadar correlation across endpoint process telemetry and network telemetry
Common host identity across data sources
Reliable CI/CD runner scoping
Reference sets or categorization for approved external destinations

Tuning Explanation

This rule should begin from suspicious execution classes rather than generic process activity. Focus on interpreters and utilities commonly abused after malicious dependency execution, then correlate them with outbound communication to non-approved external destinations.

Exclude:

·        approved external registries

·        sanctioned APIs

·        known artifact systems

·        expected cloud service destinations

Detection Logic

Detect suspicious interpreter or utility execution on CI/CD runner systems followed within a short time window by outbound communication to non-approved external destinations.

Operational Context

This is a high-value execution-to-communication correlation rule. It is stronger and narrower than generic outbound monitoring because it begins with suspicious runner-side execution behavior.

Logical Notes

This rule complements Rule 2 and Rule 3. It is intended to model likely attacker progression from execution to external communication, not replace standalone execution detections.

Rule Regret Check

Deployment caution

Requires good host correlation between endpoint and network events and disciplined destination allowlisting.

Confidence caution

Confidence rises significantly when the preceding process also matches suspicious lineage or secret-access behavior.

Coverage value

High for detecting active follow-on communication from compromised runner processes.

Execution Validity Status

Production-ready with tuning

System-Ready Code

when event A followed by event B within 5 minutes on same source IP or hostname:
  Event A:
    Log Source Type in ("Sysmon","EDR","Endpoint")
    AND Asset Category equals "CI/CD Runner"
    AND Process Name in ("bash","sh","python","python3","pwsh","powershell","curl","wget","nc")
    AND Command Line does not contain any of ("approved-script","known-good-workflow","approved-bootstrap")
  Event B:
    Log Source Type in ("Firewall","Proxy","EDR Network","Zeek")
    AND Asset Category equals "CI/CD Runner"
    AND Direction equals "Outbound"
    AND Destination Category not in ("Internal","Approved External")

Rule Name

Unauthorized Trivy-Related Tag or Release Modification

Purpose

Detect suspicious tag modification, force-push, or release publication activity affecting Trivy-related repositories or mirrored internal repositories where source-control audit telemetry is available.

ATT&CK Technique

T1078 – Valid Accounts
T1195 – Supply Chain Compromise

Telemetry Dependency

QRadar ingestion of GitHub audit logs, GitHub Enterprise logs, or equivalent repository activity logs

Normalized properties for actor, repository, event action, tag, release, and push activity
Reference sets for approved release bots and authorized maintainers
Local understanding of audit field and action normalization

Tuning Explanation

Focus on:

·        tag deletion or recreation

·        force-push activity

·        release publication or update outside normal release engineering workflows

·        unexpected actors modifying Trivy-related repositories

Suppress approved bots, known maintainers, and approved release windows. This rule should be deployed only after validating how the local GitHub ingestion normalizes repository actions and actor identity.

Detection Logic

Detect suspicious tag or release modification activity affecting Trivy-related repositories, especially force-push or tag recreation by unexpected actors.

Operational Context

This is an upstream integrity rule. It is highly valuable where repository audit telemetry exists, but should be treated as locally adapted where audit normalization is incomplete.

Logical Notes

This rule can identify the upstream side of the campaign before downstream execution occurs, but only where source-control audit visibility is mature.

Rule Regret Check

Deployment caution

Field names and action values vary significantly by GitHub ingestion method and local normalization pipeline.

Confidence caution

Without actor allowlisting and release-bot suppression, legitimate release engineering may resemble suspicious activity.

Coverage value

High where repository audit telemetry is mature; Partial where telemetry is incomplete.

Execution Validity Status

Conditional production-ready / local adaptation required

System-Ready Code

when events match ALL of the following:
  Log Source Type in ("GitHub Audit","GitHub Enterprise Audit")
  AND Repository Name contains any of ("trivy","trivy-action","setup-trivy")
  AND Event Action in ("tag_create","tag_delete","force_push","release_create","release_update","git.tag.create","git.tag.delete","git.force_push","repo.release.create","repo.release.update")
  AND NOT Reference Set Contains("Approved_Release_Actors", Username)

QRadar Coverage Validation

Detected Behaviors
Unauthorized or non-approved Trivy reference usage in CI/CD workflows
Suspicious interpreter execution on runner systems following Trivy-related activity
Secret enumeration or credential-material access behavior on CI/CD runners
Suspicious outbound communication following suspicious runner-side execution
Unauthorized upstream tag or release modification where repository audit telemetry exists

Partially Detected Behaviors
Credential theft where endpoint visibility or event correlation is incomplete
Upstream compromise where source-control audit coverage is limited or inconsistently normalized

Not Covered
Artifact poisoning that produces no observable workflow, endpoint, or audit signal
Credential access occurring entirely inside opaque third-party infrastructure outside available telemetry

Sigma

Rule Name

CI/CD Workflow Trivy Reference Usage (Baseline Comparison Required)

Purpose

Identify CI/CD workflow executions invoking Trivy-related actions, images, or binaries. In this campaign, poisoned Trivy components were distributed through trusted release channels, making reference usage a critical detection point when compared against approved baselines.

ATT&CK Technique

T1195 – Supply Chain Compromise

Telemetry Dependency

CI/CD or GitHub Actions logs
Message or command-line fields containing Trivy references
External baseline comparison capability (required)

Tuning Explanation

This rule must be paired with:

·        approved reference allowlist

·        change window awareness

Sigma alone cannot enforce baseline comparison; backend enrichment is required.

Detection Logic

Identify workflow events containing Trivy-related references for comparison against approved baseline.

Operational Context

Used as a signal generator, not a standalone alert, unless backend enrichment is implemented.

Logical Notes

This rule is intentionally incomplete without backend validation. Treat as ingestion signal, not final detection.

Rule Regret Check

Deployment caution

Requires backend enrichment for baseline comparison

Confidence caution

High false positives if used without baseline enforcement

Coverage value

High when paired with enrichment

Execution Validity Status

Conditional / translation-required analytic

System-Ready Code

title: CI/CD Workflow Trivy Reference Usage
id: 91c3a9a2-3a52-4a9e-b1e2-5e1b3c7a9d11
status: experimental
logsource:
  product: ci_cd
  category: pipeline
detection:
  selection:
    Message|contains:
      - 'trivy-action'
      - 'setup-trivy'
      - 'aquasecurity/trivy'
      - 'trivy:'
  condition: selection
falsepositives:
  - Legitimate Trivy usage
level: low
tags:
  - attack.t1195

Rule Name
CI/CD Runner Suspicious Interpreter Execution from Trivy Context

Purpose

Detect interpreter execution on CI/CD runners where parent process context indicates Trivy execution or workflow setup activity, consistent with malicious script execution introduced by poisoned dependencies.

ATT&CK Technique

T1059 – Command and Scripting Interpreter

Telemetry Dependency
Process creation logs
Parent-child process telemetry
Runner scoping via backend

Tuning Explanation

Focus on:

·        interpreter execution

·        Trivy-related parent lineage

Requires backend scoping to CI/CD runners.

Detection Logic

Detect interpreter processes spawned from Trivy-related or runner-related parent processes.

Operational Context

Captures malicious execution behavior following dependency ingestion.

Logical Notes

Parent process matching must be validated against local telemetry normalization.

Rule Regret Check

Deployment caution

Requires normalized parent process fields and runner scoping

Confidence caution

Custom automation may trigger alerts without exclusions

Coverage value

Very High

Execution Validity Status

Production-ready with backend tuning

System-Ready Code

title: CI/CD Runner Suspicious Interpreter from Trivy Context
id: 7b4f8a52-1e7b-4b9a-9f4c-0c2d7f8a521e
status: stable
logsource:
  product: linux
  category: process_creation
detection:
  selection_proc:
    Image|endswith:
      - '/bash'
      - '/sh'
      - '/python'
      - '/python3'
  selection_parent:
    ParentImage|contains:
      - 'trivy'
      - 'setup-trivy'
      - 'runner'
  filter_known:
    CommandLine|contains:
      - 'approved-script'
      - 'known-good-workflow'
  condition: selection_proc and selection_parent and not filter_known
falsepositives:
  - CI/CD automation scripts
level: high
tags:
  - attack.t1059

Rule Name

CI/CD Runner Credential Material Access Behavior

Purpose

Detect process activity on CI/CD runners consistent with access to credential-bearing data, including environment variables and token storage locations.

ATT&CK Technique

T1528 – Steal Application Access Token

Telemetry Dependency

Process command-line telemetry
Runner scoping
Optional file-access telemetry

Tuning Explanation

Focus on:

·        direct credential material access

·        token references

·        environment extraction

Requires exclusion of approved secret-handling workflows.

Detection Logic

Detect process execution referencing credential-bearing paths or token variables.

Operational Context

Targets credential harvesting behavior following malicious dependency execution.

Logical Notes

This rule is most effective when combined with execution lineage or network activity.

Rule Regret Check

Deployment caution
Requires careful exclusion tuning

Confidence caution

Debugging workflows may trigger

Coverage value

Very High

Execution Validity Status

Conditional production-ready

System-Ready Code

title: CI/CD Runner Credential Material Access Behavior
id: 2e9b1d4f-8a3c-4f2e-b7a9-3c1e9b2d4f8a
status: stable
logsource:
  product: linux
  category: process_creation
detection:
  selection_cmd:
    CommandLine|contains:
      - '/proc/'
      - 'printenv'
      - 'GITHUB_TOKEN'
      - 'AWS_ACCESS_KEY_ID'
      - '.docker/config.json'
      - '.npmrc'
  condition: selection_cmd
falsepositives:
  - Debugging activity
  - Approved secret initialization
level: high
tags:
  - attack.t1528

Rule Name

CI/CD Runner Suspicious Execution (Correlation Required for Network Follow-On)

Purpose

Identify suspicious interpreter or utility execution on CI/CD runners that should be correlated with outbound network activity in the backend to detect potential exfiltration or callback behavior.

ATT&CK Technique

T1071.001 – Application Layer Protocol: Web Protocols
Telemetry Dependency

Process telemetry
Backend correlation capability with network telemetry

Tuning Explanation

Sigma cannot express full correlation. This rule must be translated into:

·        SIEM correlation

·        EDR correlation

Detection Logic

Identify suspicious interpreter or utility execution as precursor signal.
Operational Context

Serves as the execution anchor for correlation with outbound communication.

Logical Notes

This is a correlation precursor, not a complete detection.

Rule Regret Check

Deployment caution

Requires backend correlation
Confidence caution
Standalone use is low-confidence
Coverage value
High when correlated

Execution Validity Status

Translation-required analytic
System-Ready Code

title: CI/CD Runner Suspicious Execution Precursor
id: 4d1c2e7b-9a5f-4c3e-b2d7-1c4e2f7b9a5f
status: experimental
logsource:
  product: linux
  category: process_creation
detection:
  selection:
    Image|endswith:
      - '/bash'
      - '/sh'
      - '/python'
      - '/curl'
      - '/wget'
  condition: selection
falsepositives:
  - Automation scripts
level: medium
tags:
  - attack.t1071.001

Rule Name

Trivy Repository Suspicious Tag or Release Activity

Purpose

Detect repository activity consistent with tag manipulation, force-push, or release modification affecting Trivy-related repositories.

ATT&CK Technique

T1078 – Valid Accounts

T1195 – Supply Chain Compromise

Telemetry Dependency

GitHub audit logs
Normalized repository and action fields
Backend allowlisting for actors

Tuning Explanation

Focus on:

·        tag modification

·        force push

·        release activity

Requires backend normalization and actor allowlisting.

Detection Logic

Detect repository activity involving Trivy-related repositories and sensitive actions.

Operational Context

Supports upstream compromise detection where audit logs are available.

Logical Notes

Field names and values vary significantly by ingestion pipeline.

Rule Regret Check

Deployment caution

Requires local field mapping

Confidence caution

Legitimate release activity may trigger

Coverage value

High with proper normalization

Execution Validity Status

Conditional / local adaptation required

System-Ready Code

title: Trivy Repository Suspicious Tag or Release Activity
id: 6a9d1c3e-5f7b-4c2d-8e1a-3f7b6a9d1c3e
status: experimental
logsource:
  product: github
  category: audit
detection:
  selection_repo:
    Repository|contains:
      - 'trivy'
  selection_action:
    Action|contains:
      - 'tag'
      - 'force_push'
      - 'release'
  condition: selection_repo and selection_action
falsepositives:
  - Release engineering
level: high
tags:
  - attack.t1195
  - attack.t1078

AWS

Rule Name

CI/CD Role Secret Retrieval from Unapproved Secret Path or Context

Purpose

Detect AWS Secrets Manager or Systems Manager Parameter Store retrieval activity by CI/CD-associated roles where the secret path, calling context, or source characteristics are not consistent with approved pipeline behavior. In this campaign, compromised CI/CD execution may attempt to retrieve additional secrets for theft or follow-on access.

ATT&CK Technique

T1528 – Steal Application Access Token

Telemetry Dependency

AWS CloudTrail management events
AWS EventBridge
Optional CloudWatch Logs Insights for historical baselining
IAM role inventory for CI/CD role identification
Approved secret-path inventory

Tuning Explanation

This is a CloudWatch / EventBridge style rule. The EventBridge pattern is used to collect candidate secret-access events, while high-confidence alerting depends on allowlists or baseline comparison outside the pattern itself. Recommended tuning dimensions are:

·        approved CI/CD role ARNs

·        approved secret name prefixes

·        approved source IP ranges or VPC egress points

·        expected execution windows for deployment pipelines

This rule should not alert on every GetSecretValue or GetParameter event. It should alert only when the role or target secret falls outside approved CI/CD patterns.

Detection Logic

Detect secret retrieval by CI/CD-associated identities where the target secret path or access context is not approved.

Operational Context

This is one of the highest-value AWS detections for this campaign because it directly targets the attacker objective of secret harvesting after pipeline compromise.

Logical Notes

EventBridge provides the candidate event capture. Baseline comparison is typically implemented via Lambda enrichment, SIEM correlation, or CloudWatch Logs Insights scheduled analysis.

Rule Regret Check

Deployment caution

Requires maintained CI/CD role inventory and approved secret-path mapping.

Confidence caution

Legitimate deployments may retrieve secrets dynamically if governance is weak.

Coverage value

Very High for detecting secret retrieval abuse in AWS-native CI/CD environments.

Execution Validity Status

Production-ready with enrichment and baseline control

System-Ready Code

{
  "source": ["aws.secretsmanager", "aws.ssm"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["secretsmanager.amazonaws.com", "ssm.amazonaws.com"],
    "eventName": ["GetSecretValue", "GetParameter", "GetParameters"],
    "userIdentity": {
      "type": ["AssumedRole", "IAMUser"]
    }
  }
}

CloudWatch Logs Insights Companion Query

fields @timestamp, userIdentity.arn, eventSource, eventName, sourceIPAddress, awsRegion, requestParameters.secretId, requestParameters.name
| filter eventSource in ["secretsmanager.amazonaws.com","ssm.amazonaws.com"]
| filter eventName in ["GetSecretValue","GetParameter","GetParameters"]
| filter userIdentity.arn like /ci|pipeline|runner|build|deploy/i
| stats count as access_count, values(sourceIPAddress) as src_ips, values(awsRegion) as regions by userIdentity.arn, requestParameters.secretId, requestParameters.name
| sort access_count desc

Rule Name

CI/CD Role Anomalous AssumeRole or Identity Usage

Purpose

Detect anomalous IAM role usage associated with CI/CD systems, including suspicious AssumeRole activity, unusual caller identity patterns, or role use from unexpected network or service contexts.

ATT&CK Technique

T1078 – Valid Accounts

Telemetry Dependency

AWS CloudTrail
AWS EventBridge
Optional CloudWatch Logs Insights for historical comparison
IAM role inventory and trust-policy understanding

Tuning Explanation

This is a CloudWatch / EventBridge style rule. The native pattern captures high-risk identity-use events, but meaningful detection requires comparing the observed role usage against known-good CI/CD patterns such as:

·        expected source IPs

·        expected user agents

·        expected role chains

·        expected AWS accounts and regions

·        expected invocation timing

This rule should be tuned around CI/CD roles specifically, not all IAM role activity.

Detection Logic

Detect IAM role usage by CI/CD-associated principals where the role chain, source, or service context deviates from baseline.

Operational Context

This rule is high value for detecting identity abuse after CI/CD compromise, especially where attackers use valid roles to expand access.

Logical Notes

The event pattern is candidate-event capture. The anomaly decision usually requires enrichment or SIEM-style comparison logic.

Rule Regret Check

Deployment caution

Requires role classification and baseline identity-use modeling.

Confidence caution

Shared automation roles reduce precision unless role purpose is well separated.

Coverage value

High for detecting identity abuse through AWS-native role usage.

Execution Validity Status

Production-ready with enrichment and baseline control

System-Ready Code

{
  "source": ["aws.sts"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["sts.amazonaws.com"],
    "eventName": ["AssumeRole", "GetCallerIdentity"]
  }
}

CloudWatch Logs Insights Companion Query

fields @timestamp, userIdentity.arn, sourceIPAddress, userAgent, awsRegion, requestParameters.roleArn, eventName
| filter eventSource="sts.amazonaws.com"
| filter eventName in ["AssumeRole","GetCallerIdentity"]
| filter userIdentity.arn like /ci|pipeline|runner|build|deploy/i
| stats count as role_events, values(sourceIPAddress) as src_ips, values(userAgent) as user_agents, values(awsRegion) as regions by userIdentity.arn, requestParameters.roleArn, eventName
| sort role_events desc

Rule Name

CI/CD Compute Suspicious External Network Communication

Purpose

Detect suspicious outbound communication from AWS compute resources associated with CI/CD activity, especially traffic to external destinations not required for approved build, source-control, artifact, or registry workflows.

ATT&CK Technique

T1071.001 – Application Layer Protocol: Web Protocols

Telemetry Dependency

VPC Flow Logs
Optional GuardDuty findings
Optional Route 53 Resolver logs
Resource tagging or subnet classification for CI/CD compute

Tuning Explanation

This is a CloudWatch / GuardDuty style rule. There are two valid operating modes:

CloudWatch / VPC Flow mode

Use flow logs plus allowlisting of approved destinations such as GitHub, package registries, artifact repositories, and sanctioned APIs.

GuardDuty mode

Use GuardDuty findings as a higher-confidence overlay for suspicious outbound activity, command-and-control behavior, or credential exfiltration-related anomalies.

GuardDuty does not support user-authored detection rules in the same way a SIEM does, so GuardDuty coverage here should be treated as finding-driven enrichment, not custom rule logic.

Detection Logic

Detect outbound communication from CI/CD-associated compute resources to non-approved external destinations or consume related GuardDuty findings affecting CI/CD-tagged resources.

Operational Context

This rule captures likely callback or exfiltration behavior after poisoned dependency execution.

Logical Notes

Destination allowlisting is critical. Without it, this rule becomes noisy in internet-dependent build environments.

Rule Regret Check

Deployment caution

Requires CI/CD compute scoping and approved destination allowlisting.

Confidence caution

Noise increases sharply in dynamic environments with broad external integrations.

Coverage value

High for detecting callback or exfiltration behavior from compromised AWS build infrastructure.

Execution Validity Status

Production-ready with destination tuning; GuardDuty component is finding-driven

System-Ready Code — EventBridge for GuardDuty Findings

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "severity": [4, 5, 6, 7, 8, 9],
    "type": [
      { "prefix": "Backdoor:" },
      { "prefix": "Trojan:" },
      { "prefix": "UnauthorizedAccess:" },
      { "prefix": "CredentialAccess:" },
      { "prefix": "Exfiltration:" }
    ]
  }
}

CloudWatch Logs Insights Companion Query for VPC Flow Logs

fields @timestamp, srcAddr, dstAddr, dstPort, action, bytes
| filter action="ACCEPT"
| filter isIpv4InSubnet(srcAddr, "10.0.0.0/8") or isIpv4InSubnet(srcAddr, "172.16.0.0/12") or isIpv4InSubnet(srcAddr, "192.168.0.0/16")
| stats sum(bytes) as total_bytes, count(*) as connections by srcAddr, dstAddr, dstPort
| sort total_bytes desc

Rule Name

CI/CD Compute Process Execution Deviation

Purpose

Detect execution of suspicious or non-baseline commands on AWS compute resources used for CI/CD, especially interpreters or utilities commonly used for staging, secret access, or outbound transfer after malicious dependency execution.

ATT&CK Technique

T1059 – Command and Scripting Interpreter

Telemetry Dependency

CloudWatch Logs from runner hosts or build containers
SSM Run Command logs where applicable
EDR telemetry if deployed on EC2 or worker nodes
Resource tagging or host grouping for CI/CD compute

Tuning Explanation

This is a CloudWatch style rule and should be used only where process or command telemetry is actually collected. It is not appropriate for accounts with CloudTrail-only visibility.

Focus on deviations from baseline execution, such as:

·        unexpected bash, sh, python, curl, wget

·        unusual command-line arguments

·        commands executed outside normal build stage patterns

This rule should be explicitly treated as telemetry-dependent.

Detection Logic

Detect suspicious command or process execution on CI/CD compute resources where the command line or executable deviates from the approved workflow baseline.

Operational Context

This mirrors endpoint execution detection logic for AWS-hosted build systems.

Logical Notes

Without process-level logging or EDR on the compute resource, this rule cannot operate reliably.

Rule Regret Check

Deployment caution

Do not deploy this rule where process telemetry is absent or incomplete.

Confidence caution

Baseline drift in build jobs can reduce fidelity if workflow changes are frequent.

Coverage value

Medium to High depending on process telemetry quality.

Execution Validity Status

Conditional production-ready / CloudWatch or EDR process telemetry required

System-Ready Code — CloudWatch Logs Metric Filter Pattern

"?bash ?sh ?python ?python3 ?curl ?wget"

CloudWatch Logs Insights Companion Query

fields @timestamp, @message
| filter @message like /bash|sh|python|python3|curl|wget/
| stats count(*) as executions by @logStream
| sort executions desc

Rule Name

CI/CD Artifact Bucket Modification Anomaly

Purpose

Detect anomalous object modification activity in S3 buckets used for CI/CD artifacts, dependencies, or build outputs, indicating possible artifact tampering or supply chain manipulation.

ATT&CK Technique

T1195 – Supply Chain Compromise

Telemetry Dependency

CloudTrail S3 data events
S3 bucket classification for CI/CD relevance
Optional EventBridge event routing
Approved principal inventory for artifact-writing workflows

Tuning Explanation

This is a CloudWatch / EventBridge style rule. The event pattern captures artifact modification events, but high-confidence detection requires anomaly conditions such as:

·        writes outside normal pipeline execution windows

·        unexpected principals modifying artifact objects

·        unusual object paths or prefixes

·        cross-account modification attempts

Do not alert on every PutObject or DeleteObject event in CI/CD buckets.

Detection Logic

Detect object modification events in CI/CD artifact buckets where the modifying principal, time, or object path deviates from expected artifact management behavior.

Operational Context

This rule targets supply chain manipulation inside AWS storage paths used by CI/CD systems.

Logical Notes

Bucket classification and approved-writer baselining are essential for fidelity.

Rule Regret Check

Deployment caution

Requires S3 data event logging, artifact-bucket classification, and approved-writer baselining.

Confidence caution

Noise can be high in heavily used artifact buckets without path and principal baselines.

Coverage value

High for detecting artifact tampering in AWS-based CI/CD storage paths.

Execution Validity Status

Production-ready with S3 data events and baseline control

System-Ready Code

{
  "source": ["aws.s3"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["s3.amazonaws.com"],
    "eventName": ["PutObject", "DeleteObject", "CopyObject"]
  }
}

CloudWatch Logs Insights Companion Query

fields @timestamp, userIdentity.arn, requestParameters.bucketName, requestParameters.key, sourceIPAddress, awsRegion, eventName
| filter eventSource="s3.amazonaws.com"
| filter eventName in ["PutObject","DeleteObject","CopyObject"]
| filter requestParameters.bucketName like /artifact|build|ci|pipeline/i
| stats count(*) as object_events, values(userIdentity.arn) as actors, values(sourceIPAddress) as src_ips by requestParameters.bucketName, requestParameters.key, eventName
| sort object_events desc

Azure

Rule Name

CI/CD Identity Key Vault Secret Access Deviation

Purpose

Detect Azure Key Vault secret access by CI/CD-associated service principals or managed identities when the accessed secret, source IP, or access timing deviates from established pipeline behavior.

ATT&CK Technique

T1528 – Steal Application Access Token

Telemetry Dependency

Azure Key Vault diagnostic logs
Microsoft Sentinel
Approved CI/CD identity inventory
Approved secret-path inventory
Approved source IP or egress inventory

Tuning Explanation

This is a Microsoft Sentinel KQL rule using Key Vault diagnostics.

For production use, tune it by:

·        limiting identities to a maintained watchlist of CI/CD service principals and managed identities

·        excluding approved secret prefixes used by normal build and deploy workflows

·        excluding expected egress IPs or private pipeline subnets

·        suppressing known deployment windows if your environment uses predictable schedules

Do not run this broadly against all Key Vault reads. Scope it to:

·        CI/CD identities

·        sensitive secret paths

·        new identity-to-secret relationships

·        new IP-to-identity combinations

Detection Logic

Detect Key Vault secret access by CI/CD identities where the identity-secret-IP combination is newly observed relative to baseline.

Operational Context

This is a primary Azure-native credential-harvesting detection for compromised pipeline identities.

Logical Notes

This rule works best when the CI/CD identity set is small, stable, and governed.

Rule Regret Check

Deployment caution

Requires Key Vault diagnostics and curated CI/CD identity watchlists.

Confidence caution

New deployments, migrations, or pipeline onboarding can trigger alerts until the baseline stabilizes.

Coverage value

Very High for detecting off-pattern secret retrieval.

Execution Validity Status

Production-ready with baseline enrichment

System-Ready Code (Microsoft Sentinel KQL)

let baselineWindow = 14d;
let recentWindow = 1d;
let ci_cd_identities = GetWatchlist('cicd_identities') | project SearchKey;
let approved_ips = GetWatchlist('cicd_approved_ips') | project SearchKey;
let baseline =
AzureDiagnostics
| where TimeGenerated between (ago(baselineWindow) .. ago(recentWindow))
| where ResourceType == "VAULTS"
| where OperationName in ("SecretGet","SecretList")
| where identity_s in (ci_cd_identities)
| extend SecretName = tostring(coalesce(parse_json(Properties_s).id, ResourceId))
| summarize by identity_s, CallerIPAddress, SecretName;
AzureDiagnostics
| where TimeGenerated >= ago(recentWindow)
| where ResourceType == "VAULTS"
| where OperationName in ("SecretGet","SecretList")
| where identity_s in (ci_cd_identities)
| where CallerIPAddress !in (approved_ips)
| extend SecretName = tostring(coalesce(parse_json(Properties_s).id, ResourceId))
| join kind=leftanti baseline on identity_s, CallerIPAddress, SecretName
| project TimeGenerated, identity_s, CallerIPAddress, SecretName, ResourceId, OperationName

Rule Name

CI/CD Service Principal or Managed Identity Authentication Deviation

Purpose

Detect abnormal authentication or token-usage patterns by CI/CD-associated service principals or managed identities, including new IP addresses, new locations, or new user-agent characteristics inconsistent with normal pipeline execution.

ATT&CK Technique

T1078 – Valid Accounts

Telemetry Dependency

Microsoft Entra ID service principal sign-in logs
Microsoft Sentinel
CI/CD identity watchlist
Optional approved IP / country watchlists

Tuning Explanation

This is a Microsoft Sentinel KQL rule using Entra ID logs.

For production use, tune it by:

·        restricting detection to a known watchlist of CI/CD applications and service principals

·        suppressing expected build-region countries

·        suppressing expected Microsoft-owned user-agent patterns used by automation

·        alerting only on new IP + new location combinations, not raw volume

Do not use simple count thresholds. Favor:

·        first-time IP

·        first-time country

·        first-time user-agent family

Detection Logic

Detect CI/CD identity authentication events from new IP, new location, or new user-agent combinations relative to historical baseline.

Operational Context

This is one of the strongest Azure detections for identity misuse after CI/CD compromise.

Logical Notes

Shared service principals reduce fidelity and should be split where possible.

Rule Regret Check

Deployment caution

Requires Entra service principal logs and maintained CI/CD identity classification.

Confidence caution

Over-broad service principal reuse across workloads will increase noise.

Coverage value

High for detecting off-pattern CI/CD identity usage.

Execution Validity Status

Production-ready with baseline enrichment

System-Ready Code (KQL)

let baselineWindow = 14d;
let recentWindow = 1d;
let ci_cd_apps = GetWatchlist('cicd_service_principals') | project SearchKey;
let baseline =
AADServicePrincipalSignInLogs
| where TimeGenerated between (ago(baselineWindow) .. ago(recentWindow))
| where AppDisplayName in (ci_cd_apps)
| summarize by AppId, AppDisplayName, IPAddress, Location, UserAgent;
AADServicePrincipalSignInLogs
| where TimeGenerated >= ago(recentWindow)
| where AppDisplayName in (ci_cd_apps)
| join kind=leftanti baseline on AppId, AppDisplayName, IPAddress, Location, UserAgent
| project TimeGenerated, AppDisplayName, AppId, IPAddress, Location, UserAgent, ResourceDisplayName

Rule Name

CI/CD Compute External Destination Deviation

Purpose

Detect outbound communication from Azure compute resources associated with CI/CD workflows to external destinations not present in the approved destination baseline.

ATT&CK Technique

T1071.001 – Application Layer Protocol: Web Protocols

Telemetry Dependency

Azure NSG Flow Logs or Azure Firewall logs
Microsoft Sentinel
Optional Defender for Cloud findings
CI/CD subnet, host, or runner inventory
Approved destination baseline

Tuning Explanation

This is a Sentinel plus Defender for Cloud hybrid rule.

For production use:

·        scope only to CI/CD runner subnets, VMSS instances, build VMs, or AKS worker pools used for builds

·        exclude GitHub, Azure DevOps, package registries, artifact systems, and approved external APIs

·        alert on new destination + new port or new destination + elevated bytes

·        use Defender findings as confidence enrichment, not as the primary detector

Do not alert on high volume alone.

Detection Logic

Detect outbound communication from CI/CD compute resources to previously unseen external destination and port combinations, excluding approved destinations.

Operational Context

This captures likely callback or exfiltration behavior from compromised build resources.

Logical Notes

Destination normalization is the most important tuning factor for this rule.

Rule Regret Check

Deployment caution

Requires CI/CD subnet/host classification and approved-destination baseline maintenance.

Confidence caution

Dynamic internet-dependent build jobs will create noise if destination governance is weak.

Coverage value

High for detecting suspicious outbound communication from CI/CD compute.

Execution Validity Status

Production-ready with destination baseline tuning

System-Ready Code (KQL)

let baselineWindow = 14d;
let recentWindow = 1d;
let approved_destinations = GetWatchlist('azureci_cd_approved_destinations') | project SearchKey;
let baseline =
AzureNetworkAnalytics_CL
| where FlowDirection_s == "O"
| where SubType_s in ("FlowLog", "NSGFlowLog")
| where TimeGenerated between (ago(baselineWindow) .. ago(recentWindow))
| summarize by SrcIp_s, DestIp_s, DestPort_d;
AzureNetworkAnalytics_CL
| where FlowDirection_s == "O"
| where SubType_s in ("FlowLog", "NSGFlowLog")
| where TimeGenerated >= ago(recentWindow)
| where DestIp_s !in (approved_destinations)
| join kind=leftanti baseline on SrcIp_s, DestIp_s, DestPort_d
| summarize total_bytes=sum(toint(Bytes_s)), connections=count() by SrcIp_s, DestIp_s, DestPort_d
| where total_bytes > 100000
Defender for Cloud Finding Enrichment

SecurityAlert
| where ProductName has "Microsoft Defender"
| where AlertName has_any ("Suspicious connection", "C2", "Exfiltration", "Credential")
| project TimeGenerated, AlertName, CompromisedEntity, Severity, ExtendedProperties

Rule Name

CI/CD Compute Suspicious Process Lineage Deviation

Purpose

Detect suspicious process execution on Azure compute resources used for CI/CD workflows where interpreter or utility execution deviates from approved parent-child lineage or expected command behavior.

ATT&CK Technique

T1059 – Command and Scripting Interpreter

Telemetry Dependency

Microsoft Defender for Endpoint DeviceProcessEvents
Microsoft Sentinel
CI/CD compute asset watchlist
Approved parent-process inventory

Tuning Explanation

This is a Defender for Endpoint plus Sentinel KQL rule.

For production use:

·        scope only to CI/CD-tagged or watchlisted runner devices

·        use a watchlist of approved parent processes for build tools and runner services

·        filter on suspicious interpreters and transfer utilities

·        suppress known bootstrap scripts and approved workflow strings

Do not run this as a generic “bash exists” rule.

Detection Logic

Detect suspicious interpreter or utility execution on CI/CD compute where parent process lineage or command-line pattern deviates from approved workflow behavior.

Operational Context

This captures malicious execution introduced by poisoned dependencies in Azure-hosted build environments.

Logical Notes

This rule is only viable where Defender process telemetry exists on the CI/CD compute assets.

Rule Regret Check

Deployment caution

Requires Defender for Endpoint plus maintained CI/CD host and approved-parent watchlists.

Confidence caution

Rapidly changing build jobs can create drift if parent-process baselines are not updated.

Coverage value

High where Defender telemetry is present.

Execution Validity Status

Production-ready with baseline and Defender telemetry

System-Ready Code (KQL)

let ci_cd_hosts = GetWatchlist('azureci_cd_hosts') | project SearchKey;
let approved_parents = GetWatchlist('azureci_cd_approved_parents') | project SearchKey;
DeviceProcessEvents
| where DeviceName in (ci_cd_hosts)
| where FileName in~ ("bash","sh","python","python3","curl","wget")
| where InitiatingProcessFileName !in (approved_parents)
      or ProcessCommandLine !has_any ("approved-script","known-good-workflow","approved-bootstrap")
| project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

Rule Name

CI/CD Artifact Container Modification Deviation

Purpose

Detect anomalous modification of Azure Blob Storage containers used for CI/CD artifacts, dependencies, or build outputs, indicating possible artifact tampering or supply chain manipulation.

ATT&CK Technique

T1195 – Supply Chain Compromise

Telemetry Dependency

StorageBlobLogs or AzureDiagnostics for Storage
Microsoft Sentinel
Artifact container inventory
Approved writer identity inventory
Approved path/prefix inventory

Tuning Explanation

This is a Sentinel KQL rule using Azure Storage logs.

For production use:

·        scope only to containers classified as CI/CD artifact containers

·        exclude known pipeline writer identities

·        alert on:

o   new writer + container combination

o   new blob path or prefix

o   writes outside approved build windows

o   unusual source IP for artifact writes

Do not alert on all blob writes or deletes.

Detection Logic

Detect blob modification events in CI/CD artifact containers where the actor, path, or source context is newly observed relative to baseline.

Operational Context

This targets supply chain manipulation inside Azure storage paths used by CI/CD systems.

Logical Notes

Container classification and approved-writer baselining are essential for fidelity.

Rule Regret Check

Deployment caution
Requires storage diagnostics, artifact-container watchlists, and approved-writer baselines.

Confidence caution
Noise rises quickly in shared artifact containers with poor path hygiene.

Coverage value
High for detecting artifact tampering in Azure-based CI/CD storage.

Execution Validity Status

Production-ready with baseline control

System-Ready Code (KQL)

let baselineWindow = 14d;
let recentWindow = 1d;
let artifact_containers = GetWatchlist('azureci_cd_artifact_containers') | project SearchKey;
let baseline =
StorageBlobLogs
| where TimeGenerated between (ago(baselineWindow) .. ago(recentWindow))
| where OperationName in ("PutBlob","DeleteBlob","CopyBlob")
| where ContainerName in (artifact_containers)
| summarize by AccountName, ContainerName, Uri, CallerIpAddress, AuthenticationType;
StorageBlobLogs
| where TimeGenerated >= ago(recentWindow)
| where OperationName in ("PutBlob","DeleteBlob","CopyBlob")
| where ContainerName in (artifact_containers)
| join kind=leftanti baseline on AccountName, ContainerName, Uri, CallerIpAddress, AuthenticationType
| project TimeGenerated, AccountName, ContainerName, Uri, CallerIpAddress, AuthenticationType, OperationName

GCP

Rule Name

CI/CD Service Account Secret Access Deviation

Purpose

Detect Secret Manager access by CI/CD service accounts where the accessed secret or access context deviates from established pipeline behavior.

ATT&CK Technique

T1528 – Steal Application Access Token

Telemetry Dependency

Cloud Audit Logs (Data Access)
Cloud Logging / Log Analytics
CI/CD service account inventory
Approved secret mapping

Tuning Explanation

This is a Cloud Logging + Log Analytics rule.

Production tuning requires:

·        explicit CI/CD service account allowlist (not regex)

·        baseline of serviceAccount → secret relationships

·        optional approved project or workload context

Alert only on:

·        new serviceAccount → secret combinations

·        new access context

Detection Logic

Detect Secret Manager access where the service account and secret relationship is newly observed.

Execution Validity Status

Production-ready with baseline

System-Ready Code (Log Analytics SQL-style)

WITH baseline AS (
  SELECT
    protopayload_auditlog.authenticationInfo.principalEmail AS principal,
    protopayload_auditlog.resourceName AS secret_name
  FROM `PROJECT_ID.global._Default._AllLogs`
  WHERE logName LIKE '%cloudaudit.googleapis.com%'
    AND protopayload_auditlog.serviceName = 'secretmanager.googleapis.com'
    AND timestamp BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 14 DAY)
                        AND TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  GROUP BY principal, secret_name
)

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail AS principal,
  protopayload_auditlog.resourceName AS secret_name,
  protopayload_auditlog.methodName AS method
FROM `PROJECT_ID.global._Default._AllLogs` current
LEFT JOIN baseline
ON current.protopayload_auditlog.authenticationInfo.principalEmail = baseline.principal
AND current.protopayload_auditlog.resourceName = baseline.secret_name
WHERE logName LIKE '%cloudaudit.googleapis.com%'
  AND protopayload_auditlog.serviceName = 'secretmanager.googleapis.com'
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  AND baseline.principal IS NULL

Rule Name

CI/CD Service Account Identity Usage Deviation

Purpose

Detect anomalous usage of CI/CD service accounts including new delegation patterns, new services accessed, or new execution contexts.

ATT&CK Technique

T1078 – Valid Accounts

Telemetry Dependency

Cloud Audit Logs
Cloud Logging / Log Analytics
Service account inventory
Optional delegation baseline

Tuning Explanation

This is a Cloud Logging / Log Analytics rule.

Production tuning:

·        use explicit service account allowlist

·        baseline:

o   service usage

o   delegation chains

·        detect:

o   new service usage

o   new delegation patterns

Detection Logic

Detect service account usage where serviceName or delegation pattern is newly observed.

Execution Validity Status

Production-ready with baseline

System-Ready Code

WITH baseline AS (
  SELECT
    protopayload_auditlog.authenticationInfo.principalEmail AS principal,
    protopayload_auditlog.serviceName AS service
  FROM `PROJECT_ID.global._Default._AllLogs`
  WHERE logName LIKE '%cloudaudit.googleapis.com%'
    AND timestamp BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 14 DAY)
                        AND TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  GROUP BY principal, service
)

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail AS principal,
  protopayload_auditlog.serviceName AS service,
  protopayload_auditlog.methodName
FROM `PROJECT_ID.global._Default._AllLogs` current
LEFT JOIN baseline
ON current.protopayload_auditlog.authenticationInfo.principalEmail = baseline.principal
AND current.protopayload_auditlog.serviceName = baseline.service
WHERE logName LIKE '%cloudaudit.googleapis.com%'
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  AND baseline.principal IS NULL

Rule Name

CI/CD Compute External Destination Deviation

Purpose

Detect outbound communication from CI/CD compute resources to previously unseen external destinations.

ATT&CK Technique
T1071.001 – Application Layer Protocol: Web Protocols

Telemetry Dependency

VPC Flow Logs
Cloud Logging / Log Analytics
CI/CD subnet or instance inventory
Approved destination list

Tuning Explanation

This is a Cloud Logging + SCC hybrid rule.

Production tuning:

·        restrict to CI/CD subnets or instance labels

·        exclude approved destinations

·        baseline destination + port combinations

Detection Logic

Detect new destination IP + port combinations not previously observed.

Execution Validity Status

Production-ready with tuning

System-Ready Code

WITH baseline AS (
  SELECT
    jsonPayload.connection.src_ip AS src_ip,
    jsonPayload.connection.dest_ip AS dest_ip,
    jsonPayload.connection.dest_port AS dest_port
  FROM `PROJECT_ID.global._Default._AllLogs`
  WHERE logName LIKE '%vpc_flows%'
    AND timestamp BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 14 DAY)
                        AND TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  GROUP BY src_ip, dest_ip, dest_port
)

SELECT
  jsonPayload.connection.src_ip AS src_ip,
  jsonPayload.connection.dest_ip AS dest_ip,
  jsonPayload.connection.dest_port AS dest_port,
  SUM(CAST(jsonPayload.bytes_sent AS INT64)) AS total_bytes
FROM `PROJECT_ID.global._Default._AllLogs` current
LEFT JOIN baseline
ON current.jsonPayload.connection.src_ip = baseline.src_ip
AND current.jsonPayload.connection.dest_ip = baseline.dest_ip
AND current.jsonPayload.connection.dest_port = baseline.dest_port
WHERE logName LIKE '%vpc_flows%'
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  AND baseline.src_ip IS NULL
GROUP BY src_ip, dest_ip, dest_port
HAVING total_bytes > 100000

SCC Finding Enrichment

resource.type="security_center_finding"

Rule Name

CI/CD Compute Process Execution Deviation

Purpose

Detect suspicious command execution on CI/CD compute where execution deviates from baseline behavior.

ATT&CK Technique

T1059 – Command and Scripting Interpreter

Telemetry Dependency

Cloud Logging (Ops Agent / custom logs)
Optional EDR
CI/CD compute inventory

Tuning Explanation

This is conditional — only valid with process telemetry.

Production tuning:

·        restrict to CI/CD hosts

·        baseline command patterns

·        detect new command-line patterns

Detection Logic

Detect previously unseen command-line execution patterns.

Execution Validity Status

Conditional production-ready

System-Ready Code

WITH baseline AS (
  SELECT
    text_payload AS cmd
  FROM `PROJECT_ID.global._Default._AllLogs`
  WHERE timestamp BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 14 DAY)
                        AND TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  GROUP BY cmd
)

SELECT
  timestamp,
  text_payload
FROM `PROJECT_ID.global._Default._AllLogs` current
LEFT JOIN baseline
ON current.text_payload = baseline.cmd
WHERE timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  AND REGEXP_CONTAINS(text_payload, r'bash|sh|python|curl|wget')
  AND baseline.cmd IS NULL

Rule Name

CI/CD Artifact Bucket Modification Deviation

Purpose

Detect anomalous modification of GCS buckets used for CI/CD artifacts.

ATT&CK Technique

T1195 – Supply Chain Compromise

Telemetry Dependency

Cloud Audit Logs
Cloud Logging / Log Analytics
Artifact bucket inventory
Approved writers

Tuning Explanation

This is a Cloud Logging / Log Analytics rule.

Production tuning:

·        restrict to artifact buckets

·        baseline writer + object path

·        detect new writer or path

Detection Logic

Detect new principal → object path combinations.

Execution Validity Status

Production-ready with baseline

System-Ready Code

WITH baseline AS (
  SELECT
    protopayload_auditlog.authenticationInfo.principalEmail AS principal,
    protopayload_auditlog.resourceName AS object_name
  FROM `PROJECT_ID.global._Default._AllLogs`
  WHERE logName LIKE '%cloudaudit.googleapis.com%'
    AND protopayload_auditlog.methodName IN ('storage.objects.create','storage.objects.delete','storage.objects.update')
    AND timestamp BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 14 DAY)
                        AND TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  GROUP BY principal, object_name
)

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail AS principal,
  protopayload_auditlog.resourceName AS object_name,
  protopayload_auditlog.methodName
FROM `PROJECT_ID.global._Default._AllLogs` current
LEFT JOIN baseline
ON current.protopayload_auditlog.authenticationInfo.principalEmail = baseline.principal
AND current.protopayload_auditlog.resourceName = baseline.object_name
WHERE logName LIKE '%cloudaudit.googleapis.com%'
  AND protopayload_auditlog.methodName IN ('storage.objects.create','storage.objects.delete','storage.objects.update')
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  AND baseline.principal IS NULL

S26 Threat-to-Rule Traceability Matrix

S26 Threat-to-Rule Traceability Matrix

Behavior 1 — Poisoned Dependency Consumption (Trivy / CI/CD Ingestion)

MITRE Technique
T1195 – Supply Chain Compromise

Behavior Description
CI/CD pipelines ingest compromised Trivy components or dependencies, enabling downstream malicious execution.

Detection Coverage

·        Splunk Rule 1

·        Elastic Rule 1

·        QRadar Rule 1

·        Sigma Rule 1

Telemetry Dependency

·        CI/CD workflow logs

·        GitHub Actions logs

·        Build pipeline logs

·        Dependency reference parsing and baseline enforcement

Coverage Disposition
Partially Detected

Rationale
Detection depends on:

·        approved reference baselines

·        dependency governance

·        parsing quality

Cannot guarantee detection without strict dependency control.

Behavior 2 — Malicious Execution on CI/CD Compute (Multi-Cloud)

MITRE Technique
T1059 – Command and Scripting Interpreter

Behavior Description
Execution of malicious scripts or commands triggered by poisoned dependencies within CI/CD runners or build environments across AWS, Azure, and GCP.

Detection Coverage

·        SentinelOne Rules

·        Splunk Rule 2

·        Elastic Rule 2

·        QRadar Rule 2

·        Sigma Rule 2

·        AWS Rule 4

·        Azure Rule 4

·        GCP Rule 4

Telemetry Dependency

·        Endpoint / EDR process telemetry

·        Cloud compute process telemetry (Defender, Ops Agent, EDR)

·        Parent-child process relationships

·        CI/CD compute classification

Coverage Disposition
Detected

Rationale
Strong behavioral detection across:

·        endpoint telemetry

·        cloud-hosted compute

Conditional only where process telemetry is absent.

Behavior 3 — Credential / Token Harvesting (Secrets Access Across Cloud)

MITRE Technique
T1528 – Steal Application Access Token

Behavior Description
Access to secrets and credentials from:

·        AWS Secrets Manager / SSM

·        Azure Key Vault

·        GCP Secret Manager

using compromised CI/CD identities.

Detection Coverage

·        SentinelOne Rules

·        Splunk Rule 3

·        Elastic Rule 3

·        QRadar Rule 3

·        Sigma Rule 3

·        AWS Rule 1

·        Azure Rule 1

·        GCP Rule 1

Telemetry Dependency

·        Cloud audit logs (CloudTrail, AzureDiagnostics, GCP Audit Logs)

·        Process command-line telemetry

·        CI/CD identity mapping

·        Secret access baselines

Coverage Disposition
Detected

Rationale
Baseline deviation detection is implemented across all cloud providers and endpoint telemetry.

Behavior 4 — Identity Abuse / Role or Service Account Misuse

MITRE Technique
T1078 – Valid Accounts

Behavior Description
Abuse of valid identities including:

·        AWS IAM roles

·        Azure service principals / managed identities

·        GCP service accounts

to expand access or perform unauthorized actions.

Detection Coverage

·        Splunk Rule 2

·        Elastic Rule 2

·        QRadar Rule 2

·        Sigma Rule 2

·        AWS Rule 2

·        Azure Rule 2

·        GCP Rule 2

Telemetry Dependency

·        Identity logs (CloudTrail, Entra ID, GCP Audit Logs)

·        Role / service account baseline modeling

·        IP, geo, and user-agent context

Coverage Disposition
Detected

Rationale
Baseline deviation logic implemented across all identity systems.

Behavior 5 — Command and Control / Data Exfiltration

MITRE Technique
T1071.001 – Application Layer Protocol: Web Protocols

Behavior Description
Outbound communication from compromised CI/CD compute to attacker-controlled infrastructure.

Detection Coverage

·        Splunk Rule 4

·        Elastic Rule 4

·        QRadar Rule 4

·        Sigma Rule 4 (precursor)

·        AWS Rule 3

·        Azure Rule 3

·        GCP Rule 3

Telemetry Dependency

·        Network telemetry (VPC Flow Logs, NSG Flow Logs)

·        SIEM correlation capability

·        Destination allowlisting

·        Defender / GuardDuty / SCC findings

Coverage Disposition
Detected (Correlation Required)

Rationale
Strong detection where:

·        network + compute correlation exists

·        destination baselines are maintained

Sigma contributes precursor-only coverage.

Behavior 6 — Artifact / Supply Chain Storage Tampering

MITRE Technique
T1195 – Supply Chain Compromise

Behavior Description
Modification of build artifacts or dependencies in:

·        AWS S3

·        Azure Blob Storage

·        GCP Cloud Storage

to introduce malicious payloads.

Detection Coverage

·        Splunk Rule 5

·        Elastic Rule 5

·        QRadar Rule 5

·        Sigma Rule 5

·        AWS Rule 5

·        Azure Rule 5

·        GCP Rule 5

Telemetry Dependency

·        Cloud storage audit logs

·        Object-level logging

·        Artifact container/bucket classification

·        Approved writer baselines

Coverage Disposition
Detected

Rationale
Baseline deviation detection implemented across all storage platforms.

Behavior 7 — Silent Execution Within Normal Workflow Context

MITRE Technique
T1059 – Command and Scripting Interpreter

Behavior Description
Malicious execution embedded within normal CI/CD workflow steps without generating distinct anomalies in logs, network traffic, or identity behavior.

Detection Coverage
None

Telemetry Dependency
N/A

Coverage Disposition
Not Covered

Rationale
If execution:

·        perfectly mimics normal workflow behavior

·        does not access new secrets

·        does not generate new network patterns

·        does not alter identity behavior

then detection is not guaranteed.

Coverage Summary

Detected Behaviors

·        Malicious execution across endpoint and cloud compute

·        Credential harvesting across all cloud secret stores

·        Identity abuse across IAM, Entra, and GCP service accounts

·        Outbound communication and exfiltration (with correlation)

·        Artifact tampering across all storage platforms

Partially Detected

·        Dependency poisoning at ingestion stage

Not Covered

·        Fully stealth execution within normal workflow behavior

S27 Behavior and Log Artifacts

Behavioral Indicators

·        Modification of release tags or upstream distribution assets

·        Retrieval of previously unseen dependency versions within CI/CD pipelines

·        Execution of non-baseline binaries or scripts within pipeline runners

·        Access to credentials outside defined pipeline stages

Log Artifacts

·        GitHub audit logs showing:

o   tag modification events

o   release changes

·        GitHub Actions logs showing:

o   workflow execution changes

o   unexpected job steps

·        CI/CD pipeline logs showing:

o   invocation of unrecognized commands

o   deviations in job execution sequences

·        EDR logs showing:

o   anomalous process execution within build agents

o   unexpected command-line activity

·        Network logs showing:

o   outbound connections to unknown domains

o   DNS queries inconsistent with normal pipeline activity

S28 Detection Strategy and SOC Implementation Guidance

Detection should be implemented through correlation across:

·        Source control monitoring for upstream integrity violations

·        CI/CD pipeline monitoring for execution deviations

·        Endpoint telemetry for process-level visibility within runners

·        Network monitoring for exfiltration patterns

SOC workflows should prioritize:

·        Identification of compromised dependencies and release artifacts

·        Investigation of anomalous pipeline executions

·        Correlation of credential access events with execution anomalies

·        Historical analysis of pipeline activity during exposure windows

S29 Detection Coverage Summary

Detected Behaviors

·        Unauthorized modification of release artifacts and tags

·        Pipeline execution deviations from established baselines

·        Abnormal credential access during CI/CD execution

·        Suspicious outbound network communication

Conditional Post-Exploitation Behaviors
Not observed in currently available reporting; may occur during post-exploitation depending on attacker objectives and target environment

S30 Intelligence Maturity Assessment

Current Detection Maturity
Moderate in organizations with:

·        CI/CD logging and monitoring

·        Endpoint visibility on build agents

Low in organizations lacking:

·        pipeline execution monitoring

·        artifact validation controls

Maturity Gaps

·        Lack of correlation across telemetry sources

·        Limited visibility into third-party dependency execution

·        Absence of upstream artifact integrity validation

Improvement Priorities

·        Implement artifact verification and dependency integrity controls

·        Expand CI/CD telemetry collection and behavioral analysis

·        Integrate endpoint and network telemetry into detection workflows

·        Establish cross-layer correlation for early detection of supply chain anomalies

S31 Mitigation and Remediation

Mitigation must immediately eliminate exposure to compromised Trivy artifacts, revoke any potentially exposed credentials, and re-establish trust in CI/CD execution pipelines. Because the attack leveraged authenticated modification of upstream distribution channels, remediation must address both ingestion of malicious dependencies and execution of those dependencies within pipeline environments.

Immediate actions:

·        Rotate all credentials accessible to CI/CD pipelines, including repository tokens, cloud credentials, and registry access keys

·        Remove all references to compromised Trivy releases, GitHub Actions (trivy-action, setup-trivy), and affected container images

·        Replace dependencies with verified versions or cryptographically validated digests

·        Review CI/CD execution logs during the exposure window to identify unauthorized execution or credential access

·        Purge cached artifacts, build layers, and mirrored repositories that may retain compromised components

These actions are required to terminate active exposure and prevent continued execution of poisoned dependencies.

S32 Security Control Recommendations

Artifact Integrity Controls

·       Validate signatures of Trivy binaries, container images, and GitHub Action sources prior to execution

·       Require digest-based image pulls instead of tag-based retrieval

·       Block pipeline execution of artifacts lacking verifiable provenance

Dependency Governance Controls

·       Pin trivy-action and setup-trivy to immutable versions or commit hashes

·       Restrict pipeline use of external GitHub Actions to approved repositories

·       Prevent automatic ingestion of newly published upstream dependencies without validation

CI/CD Execution Controls

·       Restrict pipeline runners from executing non-baseline binaries or scripts

·       Enforce execution allowlists aligned to known pipeline workflows

·       Block pipeline jobs that introduce unapproved execution steps or command sequences

Credential Security Controls

·       Limit exposure of environment variables to the minimum required execution scope

·       Replace long-lived credentials with short-lived, scoped tokens

·       Restrict credential access to explicitly defined pipeline stages and processes

Access and Release Infrastructure Controls

·       Require multi-factor authentication for all release publishing and repository modification actions

·       Monitor and alert on credential use associated with tag modification and release publication

·       Separate responsibilities for release creation, approval, and publication to reduce misuse of credentials

S33 Strategic Defensive Improvements

Control Impact Mapping

·       Artifact provenance validation disrupts T1195 – Supply Chain Compromise by preventing ingestion of poisoned dependencies

·       Credential scoping and rotation reduce impact of T1528 – Steal Application Access Token by limiting usable secrets

·       Access control enforcement constrains T1078 – Valid Accounts by reducing the effectiveness of compromised credentials

Strategic Improvements

·       Implement end-to-end dependency provenance validation across all CI/CD workflows

·       Establish centralized approval and governance for third-party dependency usage

·       Continuously validate integrity of GitHub Action references and release artifacts

·       Deploy monitoring for unauthorized modification of upstream dependencies and distribution channels

S34 Defensive Architecture Overview

The defensive architecture must enforce trust validation at ingestion, control execution within pipelines, and correlate activity for rapid detection and response.

Upstream Integrity Layer

·       Validate artifact signatures and enforce dependency provenance before ingestion

Pipeline Execution Layer

·       Restrict CI/CD runner behavior to approved execution patterns

·       Enforce allowlists for binaries, scripts, and external dependencies

·       Isolate credential access within defined pipeline stages

Monitoring and Response Layer

·       Correlate pipeline execution anomalies with credential access and network activity

·       Detect unauthorized changes to upstream dependencies

·       Enable rapid containment of compromised pipeline executions

This layered architecture ensures that compromise of a single trust boundary does not propagate uncontrolled through pipeline environments.

S35 Security Hardening Guidance

Harden CI/CD pipelines by enforcing strict validation of all externally sourced components and preventing execution of dependencies that cannot be verified. Configure pipelines to reject untrusted artifacts and block execution paths that deviate from established workflows.

Strengthen release infrastructure by restricting credential usage, monitoring for anomalous modification activity, and enforcing authentication controls on all publishing operations. Ensure that release processes cannot be modified without detection and approval.

Reduce attack surface by minimizing credential exposure, enforcing least privilege access, and segmenting pipeline environments to prevent credential reuse and lateral movement following compromise.

S36 Security Program Maturity Assessment

Current Maturity State

·       Low maturity environments ingest dependencies without validation and expose credentials broadly within CI/CD workflows.

·       Moderate maturity environments monitor pipeline execution but lack enforcement of artifact integrity and dependency governance.

·       High maturity environments validate artifact provenance, enforce dependency policies, and correlate telemetry across CI/CD, endpoint, and network layers.

Risk Alignment

Risk is driven by two primary factors: execution of unverified upstream artifacts and exposure of credentials during pipeline execution. Financial impact aligns directly with S6 scenarios, where credential compromise leads to downstream system access, incident response, and pipeline rebuild costs.

Maturity Improvement Priorities

·       Enforce artifact integrity validation at all dependency ingestion points

·       Expand telemetry coverage across CI/CD runners, endpoint processes, and network activity

·       Implement automated enforcement of dependency governance policies

·       Continuously test and validate supply chain controls against real-world attack scenarios

S37 Residual Risk and Forward Outlook

Residual risk persists where organizations continue to execute externally sourced dependencies without validation or maintain credentials with excessive scope or lifetime. Even after remediation, exposure may remain due to cached artifacts, incomplete credential rotation, or undetected historical execution of compromised components.

Future risk will increase as reliance on CI/CD automation and third-party dependencies expands. Adversaries are likely to continue targeting release infrastructure and distribution channels due to the scalability and low operational cost of supply chain attacks.

Organizations must adopt continuous validation of dependency trust, enforce strict control over pipeline execution, and monitor for deviations from expected behavior. Without these controls, similar attacks will continue to bypass traditional defenses by exploiting trusted systems rather than vulnerable endpoints.

S38 Intelligence Confidence Assessment

Overall Confidence Level

High

Source Reliability

High

Primary intelligence is derived from authoritative sources, including the Aqua Security advisory confirming compromise of Trivy release artifacts, GitHub Actions, and Docker images, the CVE record for CVE-2026-33634, and CISA KEV inclusion confirming active exploitation.

Analytical Confidence Drivers
Direct vendor confirmation of compromised release infrastructure and artifact distribution across multiple channels
Consistency between observed attack behavior and established supply chain compromise patterns (T1195 – Supply Chain Compromise)
Alignment between attack execution, detection signals, and defensive control requirements
Confirmed KEV status indicating real-world exploitation

Confidence Limitations
Limited publicly available detail regarding the initial credential compromise vector
Incomplete visibility into attacker infrastructure and operational tooling
Potential undisclosed secondary payload behavior beyond credential theft

Intelligence Gaps

Full scope of affected downstream environments and organizations
Precise duration of the compromise window
Extent of credential reuse or secondary access obtained by the adversary

S39 Analytical Notes and Limitations

This analysis is based on publicly available vendor disclosures, vulnerability records, and confirmed exploitation data at the time of reporting. While the attack mechanics and distribution-channel compromise are well established, certain elements of adversary activity remain partially observable.

The method used to obtain credentials capable of modifying release infrastructure has not been publicly confirmed, limiting precision in initial access attribution beyond T1078 – Valid Accounts. Downstream impact varies significantly depending on CI/CD configuration, credential exposure, and dependency management practices.

This report assumes standard CI/CD pipeline behavior and typical usage patterns of Trivy and associated GitHub Actions. Environments with additional controls, restricted execution policies, or enforced dependency validation may experience reduced exposure or different risk outcomes.

Not observed in currently available reporting; may occur during post-exploitation depending on attacker objectives and target environment, including lateral movement, persistence mechanisms, or secondary supply chain compromise.

S40 References

Vendor Advisory

·        Aqua Security — Security advisory detailing compromised Trivy releases, GitHub Actions tags, and Docker images

·        hxxps://github[.]com/aquasecurity/trivy/security/advisories/GHSA-69fq-xp46-6x23

Vulnerability Records

·        CVE-2026-33634 — Vulnerability record associated with the Trivy ecosystem

·        hxxps://www.cve[.]org/CVERecord?id=CVE-2026-33634

Known Exploited Vulnerabilities (KEV)

·        CISA Known Exploited Vulnerabilities Catalog — Entry confirming active exploitation of CVE-2026-33634

·        hxxps://www.cisa[.]gov/known-exploited-vulnerabilities-catalog

Analytical Framework

·        MITRE ATT&CK Framework — Adversary behavior classification and technique mapping

·        hxxps://attack[.]mitre[.]org