[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 Assessment

Exploitability is high for environments that executed affected Trivy releases, Trivy GitHub Actions, setup-trivy actions, container images, or other compromised Trivy distribution artifacts within developer, CI/CD, build, release, or automation workflows. The attack path is operationally significant because trusted security tooling may execute with access to repository credentials, CI/CD secrets, cloud credentials, package-publishing authority, container-registry credentials, deployment tokens, and other sensitive material without requiring direct compromise of the downstream target environment.

The Trivy compromise is confirmed exploited in the wild and is represented in the CISA Known Exploited Vulnerabilities catalog as CVE-2026-33634. Compromised Trivy components contained credential-stealing behavior and were distributed through legitimate project and release mechanisms, including GitHub Actions, release artifacts, and container-image channels.

New downstream reporting materially expands the confirmed exposure state. LiteLLM was compromised through exposure associated with a Trivy security scan operating within a GitHub workflow. Malicious LiteLLM versions 1.82.7 and 1.82.8 were subsequently uploaded to PyPI and contained credential- and secret-exfiltration functionality.

This establishes confirmed secondary supply-chain propagation rather than only theoretical downstream risk. Execution of compromised Trivy components can expose credentials or release authority associated with another software project, allowing the original trusted-tool compromise to propagate into an additional package ecosystem and create a new downstream consumer population.

The LiteLLM activity remains within the report's upstream trust compromise, CI/CD execution, credential theft, release-channel poisoning, downstream access, and propagation behavior family. The new evidence changes the known incident state by confirming that the Trivy compromise successfully propagated into a separate project's software-distribution chain.

Exploitability Drivers

·        Trivy is commonly executed as trusted security tooling within CI/CD, build, container, repository, and software-release workflows.

·        Compromised Trivy GitHub Actions or associated components may execute automatically as part of routine workflow activity.

·        CI/CD runners may expose repository tokens, GitHub credentials, cloud credentials, deployment secrets, container-registry credentials, package-publishing material, and other automation secrets to executing workflow components.

·        Compromised security tooling may operate with elevated trust because execution originates from an expected vulnerability-scanning or software-assurance workflow.

·        Mutable GitHub Action tags, release references, container tags, and other trusted distribution references can increase exposure when an attacker gains authority to alter upstream content.

·        Compromise of credentials accessible to a Trivy-enabled workflow can create access beyond the original affected repository or build environment.

·        Downstream propagation can occur when exposed credentials or workflow authority provide access to another project's repository, build, release, or package-publication process.

·        The LiteLLM compromise confirms that the Trivy incident was capable of propagating into a separate software project and legitimate package-distribution channel.

·        Malicious LiteLLM versions 1.82.7 and 1.82.8 were distributed through PyPI under the legitimate LiteLLM package identity.

·        Downstream consumers may therefore be exposed without having directly executed the originally compromised Trivy artifact if they later consume software produced or published through a propagated compromise.

·        Dependency automation, unpinned package resolution, build caches, container layers, internal mirrors, and artifact repositories can complicate exposure determination after malicious upstream content is removed.

·        Credential theft occurring inside ephemeral CI/CD runners may leave limited local forensic evidence while enabling persistent access through stolen tokens, keys, or other reusable authentication material.

·        Previously generated artifacts, cached dependencies, mirrored images, or package versions may preserve malicious content after upstream remediation.

Patch and Remediation Status

Aqua removed or replaced identified malicious Trivy artifacts and documented known-safe references following discovery of the compromise. Known-safe references include Trivy binary versions 0.69.2 and 0.69.3, trivy-action 0.35.0, and setup-trivy 0.2.6.

Remediation cannot rely solely on replacing affected Trivy versions. Because the compromise executed credential-stealing behavior within trusted automation environments, organizations that may have executed affected components must treat secrets accessible to those workflows as potentially exposed and perform credential rotation, repository review, CI/CD validation, cloud and registry review, release-path validation, and artifact assurance.

The confirmed LiteLLM propagation further expands the required remediation model. Organizations must assess whether compromised Trivy execution exposed credentials or authority associated with downstream repositories, package registries, software-release workflows, or other trusted publishing systems. Absence of continuing malicious Trivy artifacts does not establish that credentials stolen during the exposure window were unused.

Malicious LiteLLM versions 1.82.7 and 1.82.8 must be removed or superseded wherever they remain referenced or retained in Python environments, dependency manifests, lockfiles, container images, build caches, internal PyPI mirrors, artifact repositories, deployment images, or previously generated software outputs.

Organizations that executed the malicious LiteLLM packages must treat credentials, API keys, cloud tokens, SSH material, Kubernetes secrets, environment variables, and other sensitive information accessible to the affected process as potentially compromised.

Required Exposure Management Actions

·        Identify repositories, endpoints, build systems, CI/CD runners, container workflows, and automation jobs that executed affected Trivy releases, trivy-action references, setup-trivy references, or compromised container images.

·        Replace affected Trivy components with known-safe vendor references.

·        Identify workflows that executed compromised Trivy components during the exposure window and determine what secrets, repository permissions, registry credentials, cloud identities, deployment credentials, or package-publishing authority were available to those workflows.

·        Rotate or revoke credentials and secrets potentially exposed to compromised Trivy execution.

·        Review GitHub repositories, workflow files, Actions activity, secrets, deploy keys, personal access tokens, GitHub App permissions, branch protections, release activity, tag modifications, and repository access changes associated with affected workflows.

·        Review CI/CD systems for unexpected workflow modification, credential access, secret retrieval, artifact generation, release activity, or authentication originating from exposed automation identities.

·        Review package registries, container registries, artifact repositories, and software-distribution systems for unauthorized publication, tag modification, package replacement, release creation, or credential use following Trivy exposure.

·        Identify whether Trivy-enabled workflows had access to credentials or authority associated with other software projects or release environments.

·        Investigate potential secondary propagation where exposed credentials could permit modification or publication of downstream software.

·        Identify systems, repositories, containers, build environments, and deployment workflows that installed or executed LiteLLM 1.82.7 or 1.82.8.

·        Remove or supersede malicious LiteLLM 1.82.7 and 1.82.8 packages from dependency manifests, lockfiles, virtual environments, containers, build images, internal PyPI mirrors, caches, artifact repositories, and deployment outputs.

·        Treat secrets accessible to systems that executed malicious LiteLLM versions as potentially exposed and rotate affected credentials accordingly.

·        Review cloud, Kubernetes, repository, CI/CD, package-registry, and identity telemetry associated with LiteLLM-exposed systems for subsequent misuse of harvested credentials.

·        Review Python execution and outbound communication associated with affected LiteLLM installations for evidence of credential harvesting, secret access, or communication with attacker-controlled infrastructure.

·        Validate internal mirrors, dependency caches, container layers, software repositories, and artifact stores for retained compromised Trivy or LiteLLM content.

·        Review artifacts, containers, software bills of materials, release outputs, and deployment packages generated by affected workflows during the exposure window.

·        Rebuild affected software artifacts from verified source and trusted dependencies after credential assurance and CI/CD environment validation.

·        Prefer immutable commit, digest, or equivalent cryptographic references for security-critical automation components where operationally supported.

·        Restrict CI/CD secrets and publishing credentials according to least privilege and prevent vulnerability-scanning or build workflows from inheriting release authority that is not required for their function.

·        Monitor for subsequent use of credentials exposed through the original Trivy compromise because upstream artifact cleanup does not invalidate previously stolen authentication material.

Exploitability and Exposure Management Disposition

Exploitability remains high where compromised Trivy components executed within trusted developer, CI/CD, build, release, container, or automation environments with access to sensitive credentials or downstream software-delivery authority.

CVE-2026-33634 remains confirmed in the CISA Known Exploited Vulnerabilities catalog, and affected Trivy execution should be managed as a confirmed exploited software-supply-chain compromise involving credential exposure rather than solely as vulnerable-component remediation.

The LiteLLM compromise materially changes the report's established propagation state. Secondary supply-chain compromise is now confirmed. The Trivy compromise propagated into LiteLLM through exposure associated with a Trivy security scan operating within a GitHub workflow. Malicious LiteLLM versions 1.82.7 and 1.82.8 were subsequently uploaded to PyPI and contained credential- and secret-exfiltration functionality.

This activity remains directly aligned with the report's existing upstream trust compromise, CI/CD execution, credential theft, package publication, downstream access, and propagation model. It does not require a new S25 detection architecture, but it changes the operational assessment from potential secondary propagation to observed downstream propagation through a separate trusted software project and package ecosystem.

Exposure management must therefore combine Trivy remediation with credential assurance, CI/CD review, repository and release-path validation, downstream-project access review, package-registry review, cache and mirror cleanup, artifact integrity validation, LiteLLM exposure assessment, downstream credential rotation, and continued monitoring for additional propagation originating from credentials compromised during the Trivy incident.

S14 — Sectors / Countries Affected

Sectors Affected

Likely exposed sectors include organizations that use Trivy within developer workstations, CI/CD pipelines, container-security workflows, source-code repositories, build environments, release automation, internal artifact repositories, cloud-connected software-delivery workflows, or other environments where trusted security tooling can access credentials, secrets, repositories, registries, or downstream publishing authority.

The exposure is not limited to organizations using Trivy as a standalone vulnerability scanner. The confirmed propagation into LiteLLM demonstrates that compromise of trusted security tooling within a CI/CD workflow can expose credentials or software-delivery authority associated with another project and create a secondary downstream package-consumer population. Sector exposure is therefore driven primarily by Trivy execution, CI/CD integration, credential accessibility, software-release authority, and downstream artifact consumption rather than by a particular industry.

Most Likely Exposed Sectors

·        Technology and software development.

·        SaaS and cloud-service providers.

·        DevSecOps, application-security, container-security, and platform-engineering teams using Trivy within automated software-delivery workflows.

·        AI application development, AI SaaS, LLM infrastructure, and organizations consuming or integrating LiteLLM.

·        Software vendors and open-source projects that use Trivy within GitHub Actions, CI/CD pipelines, container scanning, build validation, or release workflows.

·        Managed service providers and systems integrators supporting cloud, container, DevSecOps, application-security, or software-development environments.

·        Financial services.

·        Healthcare and life sciences.

·        Manufacturing.

·        Retail and e-commerce.

·        Professional services.

·        Education and research.

·        Government, defense, and government-adjacent environments using external software dependencies, CI/CD automation, container tooling, or open-source security components.

·        Regulated and critical-infrastructure organizations whose software-development or operational-technology support environments depend on external software, container, or package ecosystems.

Sector exposure should be treated as broad unless incident-specific evidence establishes a narrower affected population. Risk is highest where compromised Trivy components executed within workflows containing privileged repository access, CI/CD secrets, cloud credentials, container-registry credentials, package-publishing authority, deployment credentials, artifact-signing authority, production access, or other reusable authentication material.

The confirmed LiteLLM propagation further increases exposure for organizations that may not have executed compromised Trivy components directly but consumed malicious software produced or published following secondary compromise. Organizations using LiteLLM versions 1.82.7 or 1.82.8 therefore represent a distinct downstream exposure population within the broader Trivy supply-chain incident.

Countries Affected

Global

Geographic exposure should be treated as global because Trivy, GitHub Actions, container registries, CI/CD platforms, PyPI, cloud development environments, and software-supply-chain dependencies are distributed internationally and are not restricted to a specific country or region.

The primary exposure boundary is trusted software execution and downstream dependency consumption rather than geography. Unless incident-specific evidence limits activity to a particular country, language group, hosting region, customer base, or victim population, any organization that executed affected Trivy components, retained compromised artifacts in caches or mirrors, exposed credentials to affected workflows, consumed downstream software produced through propagated compromise, or installed malicious LiteLLM 1.82.7 or 1.82.8 packages may be affected.

S15 — Adversary Capability Profiling

Adversary Capability Overview

The activity reflects a capable software supply-chain operator with practical knowledge of GitHub credential abuse, mutable GitHub Action references, release infrastructure, CI/CD secret exposure, container and binary distribution, software-publishing authority, credential harvesting, exfiltration, and downstream software-release compromise. The tradecraft is consistent with a developer-ecosystem and CI/CD control-plane intrusion model rather than commodity endpoint-only malware.

The Trivy compromise demonstrates the ability to obtain or retain valid access to trusted software-release infrastructure, replace legitimate project artifacts with credential-stealing content, and exploit routine execution of trusted security tooling inside downstream CI/CD environments.

The confirmed LiteLLM propagation materially expands the demonstrated capability. Exposure associated with a compromised Trivy security scan in a GitHub workflow resulted in API-token exposure and was followed by malicious LiteLLM versions 1.82.7 and 1.82.8 being uploaded through the legitimate PyPI package-distribution channel. The malicious LiteLLM packages then harvested sensitive credentials and files from downstream consumers, demonstrating a second-order supply-chain propagation model in which one compromised software project can facilitate compromise of another trusted package ecosystem.

Observed or Reported Capability Indicators

·        Ability to obtain or reuse valid credentials associated with software-release infrastructure.

·        Ability to publish a malicious Trivy release through legitimate project distribution mechanisms.

·        Ability to replace or force-update mutable GitHub Action references with credential-stealing content.

·        Ability to compromise setup-trivy references used by automated workflows.

·        Ability to distribute malicious software through trusted GitHub Actions, release artifacts, and container-related software-delivery paths.

·        Ability to execute malicious functionality inside routine CI/CD and vulnerability-scanning workflows.

·        Targeting of credentials and secrets accessible to developer and CI/CD environments.

·        Ability to retain or regain access where credential rotation is incomplete or non-atomic.

·        Ability to use compromised workflow access to reach credentials or publishing authority associated with another software project.

·        Confirmed downstream propagation from Trivy-related exposure into LiteLLM.

·        Ability to upload malicious LiteLLM versions 1.82.7 and 1.82.8 through the legitimate PyPI distribution channel.

·        Ability to embed automatically activated credential- and secret-harvesting functionality inside downstream Python packages.

·        Ability to create a new victim population consisting of organizations that never executed the original compromised Trivy artifact but later consumed malicious downstream software.

Adversary Strengths

·        Exploits trust in security tooling that is expected to execute inside privileged CI/CD and software-delivery workflows.

·        Uses legitimate software-distribution infrastructure to reach developers, build systems, and automation environments.

·        Benefits from mutable version tags and Action references where organizations do not pin trusted components to immutable commits or digests.

·        Targets environments where high-value repository, registry, cloud, deployment, and package-publishing credentials are commonly present.

·        Can convert a short-lived CI/CD execution event into longer-lived compromise through stolen reusable credentials or tokens.

·        Benefits from ephemeral runner infrastructure where local forensic evidence may be limited after workflow completion.

·        Can abuse legitimate authentication material in ways that may resemble expected developer or automation activity without sufficient identity and workflow context.

·        Can propagate compromise from one trusted software project into another where stolen credentials or publishing authority permit downstream access.

·        Can create additional downstream exposure through legitimate package ecosystems after the initial malicious upstream artifact has been removed.

·        Can produce business impact even when the original malicious component is no longer available because previously stolen credentials, cached artifacts, mirrored content, and downstream malicious packages may remain valid or accessible.

Adversary Constraints

·        Initial downstream execution requires an affected Trivy component to be executed or consumed within a developer, CI/CD, build, release, container, or automation environment.

·        Credential harvesting value depends on what secrets, tokens, repository permissions, cloud identities, registry credentials, or publishing authority are exposed to the affected workflow.

·        Secondary propagation depends on the scope and usability of credentials or access obtained from the initially compromised environment.

·        Downstream LiteLLM exposure requires installation or execution of malicious LiteLLM 1.82.7 or 1.82.8.

·        Immutable Action pinning, digest pinning, least-privilege workflow permissions, isolated build environments, restricted secret availability, and narrowly scoped publishing identities reduce propagation potential.

·        Rapid credential revocation and atomic rotation reduce the opportunity to retain access through previously exposed authentication material.

·        Detection likelihood increases where GitHub, CI/CD, endpoint, cloud, registry, package-publishing, identity, artifact, and network telemetry are retained and correlated.

·        Workflow logs, dependency manifests, build records, internal mirrors, caches, software bills of materials, container layers, and artifact repositories may preserve evidence after malicious upstream references are removed.

Adversary Capability Disposition

The adversary capability should be assessed as high for software supply-chain and CI/CD compromise. The attacker does not require direct access to every downstream organization because trusted Trivy execution can place malicious code inside developer and automation environments that already possess valuable credentials and software-delivery authority.

The confirmed LiteLLM propagation demonstrates that the threat is capable of extending beyond first-order credential theft. Compromise originating through trusted Trivy execution can expose credentials associated with another project, enable malicious publication through a separate legitimate package ecosystem, and create an additional downstream population exposed to credential-harvesting software.

This capability materially elevates the operational significance of the incident from malicious upstream artifact distribution to demonstrated multi-stage software-supply-chain propagation.

S16 — Targeting Probability Assessment

Targeting Probability

High for organizations that executed affected Trivy releases, Trivy GitHub Actions, setup-trivy references, or related compromised artifacts within CI/CD, build, release, container, repository, or automation environments containing reusable credentials or software-delivery authority.

High also for organizations that installed or executed malicious LiteLLM 1.82.7 or 1.82.8 because these packages represent confirmed downstream propagation from the broader Trivy supply-chain compromise.

Targeting Logic

This incident is primarily exposure-driven rather than individually targeted in every downstream environment. Organizations become exposed when compromised Trivy components execute inside trusted automation environments or when malicious downstream artifacts created through propagated compromise are subsequently consumed.

The probability of meaningful impact rises where affected workflows expose repository write access, GitHub credentials, cloud identities, container-registry credentials, package-publishing authority, deployment access, signing authority, or other reusable secrets.

The confirmed LiteLLM activity adds a second exposure path. An organization may be affected without having executed compromised Trivy directly if it subsequently installs malicious software published through a downstream project compromised as a consequence of Trivy-related credential exposure.

High Probability Exposure Conditions

·        Trivy v0.69.4 or another identified compromised Trivy artifact was pulled or executed during the affected exposure window.

·        Affected trivy-action or setup-trivy references were executed in GitHub Actions or other automation workflows.

·        Mutable Trivy Action tags or release references were used instead of immutable commit or digest pinning.

·        Compromised Trivy execution occurred on CI/CD runners or automation systems containing GitHub tokens, repository secrets, cloud credentials, registry credentials, deployment credentials, or package-publishing authority.

·        Affected workflows had write access to repositories, release infrastructure, package registries, or software-distribution systems.

·        Credential rotation following exposure was delayed, incomplete, non-atomic, or cannot be independently validated.

·        GitHub, CI/CD, cloud, registry, package-publishing, identity, endpoint, or network telemetry is incomplete or not centrally correlated.

·        Internal mirrors, caches, container layers, build images, or artifact repositories retained compromised Trivy content after upstream remediation.

·        LiteLLM 1.82.7 or 1.82.8 appears in dependency manifests, lockfiles, Python environments, build images, containers, internal PyPI mirrors, deployment artifacts, or software bills of materials.

·        LiteLLM 1.82.7 or 1.82.8 was installed or executed in an environment containing cloud credentials, API keys, repository credentials, SSH material, Kubernetes secrets, environment variables, or other sensitive information.

·        Downstream software built or released during the Trivy or LiteLLM exposure window was promoted or distributed before credential assurance and artifact-integrity review were completed.

Moderate Probability Exposure Conditions

·        Affected Trivy references appear in workflow definitions or build records, but execution during the compromise window cannot be confirmed.

·        Compromised Trivy artifacts were cached, mirrored, or retained internally, but execution has not been established.

·        Affected workflows executed Trivy but exposed only narrowly scoped or low-value credentials.

·        Relevant credentials were rotated after exposure, but audit evidence is insufficient to determine whether they were accessed or reused beforehand.

·        LiteLLM 1.82.7 or 1.82.8 appears in dependency records or caches, but installation or execution has not been confirmed.

·        Malicious LiteLLM versions executed in isolated development or test environments with limited secret access.

·        Build or release systems were exposed but had limited repository, registry, cloud, deployment, or package-publication permissions.

·        Telemetry is sufficient to establish component exposure but insufficient to prove or disprove credential access, exfiltration, or subsequent reuse.

Lower Probability Exposure Conditions

·        Affected Trivy versions or references were not present in workflow definitions, runner logs, caches, mirrors, container layers, artifacts, or build records.

·        Trivy Actions were pinned to verified immutable commits that were not affected by the compromise.

·        Affected Trivy artifacts were blocked or removed before execution.

·        Exposed workflows did not contain reusable credentials, repository write authority, package-publishing rights, cloud permissions, or outbound access useful to the attacker.

·        Credential rotation and audit review confirm no suspicious post-exposure use.

·        LiteLLM 1.82.7 and 1.82.8 were never installed, executed, cached, mirrored, or incorporated into generated artifacts.

·        Malicious LiteLLM versions were blocked before execution in environments containing sensitive credentials.

·        Build artifacts produced during the exposure window were not promoted, deployed, published, or distributed.

·        GitHub, CI/CD, cloud, registry, package-publishing, identity, endpoint, and network review is sufficiently complete to exclude post-exposure credential misuse or downstream propagation.

Targeting Probability Disposition

Targeting probability is high for organizations that executed compromised Trivy components in privileged developer or CI/CD contexts and for organizations that installed or executed malicious LiteLLM 1.82.7 or 1.82.8 in environments containing reusable credentials or sensitive data.

Probability is lower where immutable Trivy references were used, affected components never executed, exposed workflows lacked valuable credentials or software-delivery authority, LiteLLM malicious versions were never consumed, and post-exposure identity, repository, CI/CD, cloud, registry, network, and artifact review is complete and clean.

The confirmed Trivy-to-LiteLLM propagation means exposure assessment should not be restricted to direct Trivy consumers. Organizations must also consider whether software produced or published by projects exposed through the original compromise created additional downstream dependency exposure.

S17 — MITRE ATT&CK Chain Flow Mapping

Stage 1 — Valid Credential Access to Trusted Release Infrastructure

Function in this threat

·        The Trivy supply-chain compromise involved use of compromised credentials to obtain or retain access to trusted software-release infrastructure.

·        Valid access allowed malicious changes to occur through legitimate project and distribution mechanisms rather than through direct compromise of every downstream consumer.

·        This stage establishes the control-plane access needed to manipulate trusted software-distribution paths.

Technique IDs

·        MITRE ATT&CK: T1078 — Valid Accounts.

Stage 2 — Trivy Software Supply-Chain Compromise

Function in this threat

·        The attacker introduced credential-stealing content into trusted Trivy software-distribution mechanisms.

·        Reported activity included malicious Trivy release content, altered Trivy GitHub Action references, and compromised setup-trivy references.

·        Legitimate project names, repositories, release mechanisms, and automation references provided the trust path used to reach downstream environments.

Technique IDs

·        MITRE ATT&CK: T1195.002 — Supply Chain Compromise: Compromise Software Supply Chain.

Stage 3 — Trusted CI/CD or Security-Tool Execution

Function in this threat

·        A developer environment, CI/CD runner, build system, container workflow, or automation process executes the compromised Trivy component as part of expected security-scanning or software-delivery activity.

·        The execution appears operationally legitimate because Trivy is expected to run within vulnerability-scanning and DevSecOps workflows.

·        This stage moves the attack from upstream package manipulation into the downstream organization's trusted execution environment.

Technique IDs

·        MITRE ATT&CK: T1059 — Command and Scripting Interpreter, where malicious workflow components invoke shell or scripting behavior.

·        MITRE ATT&CK: T1195.002 — Supply Chain Compromise: Compromise Software Supply Chain.

Stage 4 — CI/CD Credential and Secret Discovery

Function in this threat

·        Malicious Trivy execution targets credentials and secrets accessible to the affected workflow or runner.

·        Exposed material may include GitHub tokens, repository secrets, cloud credentials, deployment credentials, container-registry credentials, package-publishing material, API tokens, private keys, and environment variables.

·        This is the primary transition from trusted tool execution to reusable enterprise and software-delivery access.

Technique IDs

·        MITRE ATT&CK: T1552.001 — Unsecured Credentials: Credentials In Files.

·        MITRE ATT&CK: T1552.004 — Unsecured Credentials: Private Keys.

·        MITRE ATT&CK: T1528 — Steal Application Access Token.

·        MITRE ATT&CK: T1083 — File and Directory Discovery, where local paths are searched for credential-bearing files or configuration.

·        MITRE ATT&CK: T1005 — Data from Local System.

Stage 5 — Credential Collection and Exfiltration

Function in this threat

·        Harvested credentials and secret material are collected and transmitted from the affected runner or workflow environment.

·        Successful exfiltration converts temporary malicious execution into reusable access that may persist after the original compromised artifact has been removed.

·        Exfiltration should be validated through runner, process, network, repository, and workflow telemetry where available.

Technique IDs

·        MITRE ATT&CK: T1567.001 — Exfiltration Over Web Service: Exfiltration to Code Repository, for the reported Trivy credential-exfiltration path using GitHub repository or release infrastructure.

Stage 6 — Credential Reuse and Software-Delivery Control-Plane Access

Function in this threat

·        Stolen GitHub, API, cloud, registry, or publishing credentials may be reused to access repositories, release workflows, package registries, cloud environments, or other software-delivery systems.

·        This stage shifts the incident from local CI/CD credential theft into broader control-plane compromise.

·        Credential reuse should be validated through audit logs rather than assumed solely from execution of an affected Trivy component.

Technique IDs

·        MITRE ATT&CK: T1078 — Valid Accounts.

·        MITRE ATT&CK: T1528 — Steal Application Access Token.

Stage 7 — Secondary Supply-Chain Propagation Into LiteLLM

Function in this threat

·        The LiteLLM incident confirms that Trivy-related exposure propagated into another software project rather than remaining a theoretical downstream risk.

·        Public reporting identifies API-token exposure associated with an exploited Trivy dependency and subsequent unauthorized publication of malicious LiteLLM versions.

·        This stage represents a second software-supply-chain compromise in which access originating from the first trusted software compromise contributes to poisoning of another legitimate package-distribution path.

Technique IDs

·        MITRE ATT&CK: T1195.002 — Supply Chain Compromise: Compromise Software Supply Chain.

·        MITRE ATT&CK: T1078 — Valid Accounts, where compromised publishing credentials are used to access legitimate package-publication infrastructure.

Stage 8 — Malicious LiteLLM Publication Through PyPI

Function in this threat

·        Malicious LiteLLM versions 1.82.7 and 1.82.8 were uploaded through the legitimate PyPI distribution channel.

·        Publication under the legitimate LiteLLM package identity created a trusted dependency path to downstream Python environments.

·        The attacker therefore gained reach into organizations that may never have executed the originally compromised Trivy components.

Technique IDs

·        MITRE ATT&CK: T1195.002 — Supply Chain Compromise: Compromise Software Supply Chain.

Stage 9 — Downstream Package Execution and Credential Harvesting

Function in this threat

·        Downstream systems that installed and executed malicious LiteLLM versions were exposed to automatically activated malicious functionality.

·        The malicious packages harvested sensitive credentials and files available to the LiteLLM execution environment.

·        This stage creates a second generation of credential exposure originating from the propagated software-supply-chain compromise.

Technique IDs

·        MITRE ATT&CK: T1059 — Command and Scripting Interpreter, where malicious package logic invokes command or scripting execution.

·        MITRE ATT&CK: T1552.001 — Unsecured Credentials: Credentials In Files.

·        MITRE ATT&CK: T1552.004 — Unsecured Credentials: Private Keys.

·        MITRE ATT&CK: T1083 — File and Directory Discovery.

·        MITRE ATT&CK: T1005 — Data from Local System.

Stage 10 — Downstream Secret Exfiltration

Function in this threat

·        Malicious LiteLLM functionality exfiltrates harvested secrets and sensitive material to attacker-controlled infrastructure.

·        Credentials exposed during this stage may enable additional access beyond the LiteLLM host or application environment.

·        Package removal alone does not invalidate credentials already transferred to the attacker.

Technique IDs

·        Exfiltration technique should be mapped to the confirmed transport where telemetry is available. Public reporting confirms exfiltration to a remote API but does not establish a sufficiently specific ATT&CK exfiltration transport for direct technique assignment.

Stage 11 — Continued Credential Reuse and Additional Propagation Risk

Function in this threat

·        Credentials harvested from Trivy- or LiteLLM-exposed environments may provide access to additional repositories, cloud environments, package registries, build systems, deployment workflows, or software-publishing infrastructure.

·        Further propagation beyond the confirmed LiteLLM compromise should remain conditional unless supported by incident-specific evidence.

·        This stage represents the continuing operational risk created by reusable credentials after removal of malicious upstream or downstream packages.

Technique IDs

·        MITRE ATT&CK: T1078 — Valid Accounts.

·        MITRE ATT&CK: T1195.002 — Supply Chain Compromise: Compromise Software Supply Chain, where additional downstream repository, workflow, or package propagation is confirmed.

Stage 12 — Downstream Software Integrity and Enterprise Exposure

Function in this threat

·        The final business-impact stage occurs when compromised credentials, poisoned dependencies, malicious workflow outputs, affected containers, modified repositories, or exposed build environments create uncertainty around internal software, packages, containers, software bills of materials, release artifacts, deployment artifacts, or customer-facing services.

·        Confirmed propagation into LiteLLM demonstrates that software-integrity exposure can extend beyond the original Trivy consumer population.

·        This stage is primarily a risk and assurance outcome rather than a separate ATT&CK technique unless additional malicious activity is confirmed.

Technique IDs

·        MITRE ATT&CK: T1195.002 — Supply Chain Compromise: Compromise Software Supply Chain.

Observed / Reported ATT&CK Coverage

·        T1078 — Valid Accounts.

·        T1195.002 — Compromise Software Supply Chain.

·        T1552.001 — Credentials In Files.

·        T1552.004 — Private Keys.

·        T1528 — Steal Application Access Token.

·        T1083 — File and Directory Discovery.

·        T1005 — Data from Local System.

·        T1567.001 — Exfiltration to Code Repository, for the reported Trivy credential-exfiltration path using GitHub repository or release infrastructure.

Conditional ATT&CK Coverage

·        T1059 — Command and Scripting Interpreter, where telemetry confirms shell, script, or runtime execution associated with the malicious Trivy or LiteLLM components.

·        T1078 — Valid Accounts, for additional post-exposure use of stolen credentials against GitHub, cloud, registry, CI/CD, repository, or publishing systems beyond activity already established in public reporting.

·        T1195.002 — Compromise Software Supply Chain, for additional downstream repository, workflow, package, or release-channel propagation beyond the confirmed LiteLLM compromise.

·        T1074 — Data Staged, where telemetry confirms local preparation or aggregation of harvested material prior to exfiltration.

MITRE ATT&CK Chain Flow Disposition

The attack chain progresses from valid credential access to trusted Trivy release infrastructure, software-supply-chain manipulation, execution of compromised security tooling within trusted CI/CD environments, credential and secret harvesting, exfiltration, credential reuse, and downstream software-delivery access.

The confirmed LiteLLM compromise extends that chain into a second supply-chain cycle: Trivy-related credential exposure, access affecting LiteLLM publishing authority, malicious publication of LiteLLM 1.82.7 and 1.82.8 through PyPI, downstream package execution, additional credential harvesting, and secret exfiltration from a new consumer population.

The most important defensive conclusion is that exposure review must not stop at identifying whether compromised Trivy components executed. It must extend into credential assurance, GitHub and CI/CD audit review, cloud and registry validation, package-publishing review, downstream dependency assessment, LiteLLM exposure review, artifact integrity validation, and monitoring for additional credential-driven propagation.

The LiteLLM activity does not require replacement of the report's existing S25 detection model because it preserves the same core behaviors: trusted software-supply-chain compromise, CI/CD execution, credential access, credential reuse, software-publication abuse, downstream execution, secret exfiltration, and propagation.

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 — Economic Impact & Organizational Exposure

The Trivy supply-chain compromise creates organizational exposure by introducing uncertainty over whether trusted vulnerability-scanning components, GitHub Actions, setup-trivy references, release artifacts, container images, CI/CD workflows, credentials, repositories, registries, build systems, downstream packages, developer extensions, and software-release paths remained trustworthy during the affected exposure window.

The governing risk is not limited to Trivy v0.69.4, one compromised GitHub Action tag, one setup-trivy reference, one container image, one credential, one repository, one malicious artifact, one actor, or one distribution channel. The material question is whether compromise of trusted Trivy release infrastructure was converted into downstream CI/CD execution, credential theft, repository or publishing access, release-channel manipulation, secondary software-supply-chain compromise, malicious downstream package publication, additional credential exposure, cloud or source-code access, persistence, artifact tampering, or broader software-integrity uncertainty before containment.

The confirmed compromise of LiteLLM materially changes the report's known propagation state. Public reporting establishes that an API token exposed through the Trivy compromise was subsequently used to publish malicious LiteLLM versions 1.82.7 and 1.82.8 through PyPI. Secondary software-supply-chain propagation must therefore be treated as confirmed rather than merely possible.

Broader TeamPCP activity substantially expands the relevant exposure model beyond the original March Trivy incident. Current reporting identifies subsequent or related compromise involving CanisterWorm npm propagation, Checkmarx KICS and OpenVSX assets, LiteLLM and Telnyx PyPI releases, stolen-credential operationalization against GitHub and cloud environments, Xinference, a later Checkmarx KICS and Bitwarden CLI incident, SAP-related npm packages and the associated Lightning and Intercom wave, the Checkmarx Jenkins AST plugin, TanStack and other trusted-publishing workflows, the @antv / actions-cool / nrwl.angular-console multi-ecosystem wave, Aqua or GitHub repository compromise, Miasma and its later binding.gyp-based propagation wave, and multiple Microsoft-linked GitHub projects.

These incidents demonstrate that the governing risk extends beyond one package ecosystem or execution mechanism. TeamPCP has repeatedly moved between GitHub Actions, npm, PyPI, developer extensions, CI/CD plugins, trusted-publishing workflows, repository access, cloud credentials, and downstream software execution. The current S25 rules retain substantial behavioral relevance across that activity, but later campaign stages introduce ecosystem-, runtime-, publishing-, persistence-, extension-, and repository-specific requirements that prevent those incidents from being classified universally as Direct Coverage.

Economic exposure increases when affected Trivy, npm, PyPI, GitHub Actions, developer-extension, Jenkins, developer, or CI/CD environments support centralized software delivery, package publication, cloud deployment, artifact signing, container registries, AI services, customer-facing applications, proprietary source code, privileged identities, regulated workloads, or broadly connected enterprise infrastructure. Exposure is highest when defenders cannot connect the initiating workflow, runner, package, repository, identity, credential, extension, plugin, or publishing event to subsequent execution, credential access, persistence, outbound communication, package publication, cloud use, artifact creation, downstream dependency execution, or additional credential reuse.

Estimated Economic Exposure

Estimated economic exposure should remain scenario-based and preserve the validated S6 cost ranges for this report.

Low Impact Scenario

Estimated $50K–$250K

This scenario applies where rapid investigation confirms that exposure was limited to affected-component presence, blocked or non-privileged execution, cache or mirror retention, dependency-reference exposure, or a small number of environments without evidence of credential theft, repository abuse, unauthorized package publication, cloud access, suspicious outbound communication, persistence, artifact impact, or downstream compromise.

Available evidence supports a prevented, contained, or non-impacting event. Response remains limited to affected-component scoping, package, Action, plugin, or extension removal, cache and mirror cleanup, focused CI/CD and developer-system review, narrow credential validation, workflow comparison, short-term monitoring, and executive assurance that privileged software-delivery environments were not materially compromised.

Moderate Impact Scenario

Estimated $250K–$2M

This scenario applies where confirmed or strongly suspected activity includes execution of compromised Trivy components or related downstream software, developer or CI/CD credential exposure, repository access, workflow abuse, cloud-secret exposure, malicious package, plugin, or extension execution, constrained package-publication abuse, persistence, internal artifact exposure, or limited downstream reach.

Response may require broad credential rotation, CI/CD investigation, developer-endpoint review, repository and workflow analysis, package-registry investigation, plugin and extension review, dependency and cache remediation, internal mirror analysis, build-image validation, cloud audit review, artifact provenance analysis, enterprise hunting, legal or compliance assessment, customer-assurance preparation, executive reporting, and extended monitoring.

High Impact Scenario

Estimated $2M–$10M+

This scenario applies where credential-driven software-supply-chain compromise becomes an enterprise-impact event involving durable repository access, compromise of multiple trusted projects, broad credential misuse, unauthorized package publication, cloud or deployment access, persistent developer or CI/CD compromise, artifact-signing exposure, poisoned build outputs, customer-facing release impact, regulated-data exposure, widespread credential rotation, prolonged software-release disruption, or cascading compromise across multiple software-development ecosystems.

The confirmed Trivy-to-LiteLLM propagation establishes that multi-hop software-supply-chain compromise is not theoretical. Subsequent TeamPCP activity demonstrates continued use of package registries, GitHub Actions, developer extensions, CI/CD plugins, valid publishing identities, trusted-publishing workflows, and downstream execution as interchangeable trust paths.

Response may require suspension of affected software publication and release processes, enterprise credential and session invalidation, CI/CD and developer-system isolation, repository and workflow reconstruction, cloud containment, package, plugin, and extension remediation, artifact rebuilding, internal mirror and cache purging, provenance and signing validation, downstream customer or partner assessment, legal and regulatory escalation, communications planning, cyber-insurance engagement, and executive or board reporting.

Annualized Risk Exposure

Estimated annualized exposure is $750K–$8M for materially exposed enterprise environments, depending on pipeline scale, credential scope, software-delivery centralization, downstream dependency reach, cloud access, package-publishing authority, developer-tool exposure, and the organization's ability to restore software and identity trust.

Annualized exposure increases where one CI/CD runner, repository credential, GitHub identity, cloud role, package-publishing credential, developer extension, CI/CD plugin, container-registry credential, or release workflow can affect multiple repositories, packages, environments, products, customers, or business units.

Exposure should trend toward the upper end of the validated range where organizations cannot prove that credentials exposed during the Trivy or related downstream compromise window were revoked before reuse, package-publication authority remained trustworthy, malicious persistence was absent, downstream artifacts remained clean, or additional software-supply-chain propagation did not occur.

Operational Dependency

Operational dependency is high where Trivy or related external development components are embedded in vulnerability scanning, CI/CD, container security, build validation, release engineering, repository automation, package restoration, developer tooling, Jenkins or other CI/CD plugins, cloud deployment, AI services, or software-assurance workflows.

One compromised security component, GitHub Action, package, developer extension, CI/CD plugin, runner, repository token, cloud credential, package-publishing identity, container-registry credential, or release workflow can create broad investigation and recovery requirements when multiple products, repositories, packages, environments, customers, or business units rely on the same software-delivery trust path.

Operational dependency extends beyond direct Trivy consumers. The confirmed LiteLLM compromise demonstrates that downstream projects and package consumers can become exposed through credentials or publishing authority compromised through an upstream workflow. Later TeamPCP activity demonstrates that the same governing risk can traverse npm, PyPI, GitHub Actions, developer extensions, Jenkins plugins, repository identities, and trusted-publishing mechanisms.

Dependency increases when affected scanning, development, build, package, extension, plugin, release, AI, cloud, or deployment environments cannot be suspended, isolated, rebuilt, rotated, or disconnected without disrupting essential software-delivery functions.

Control Trust

Control trust is reduced when the organization cannot prove that Trivy execution, GitHub Action resolution, package installation, extension or plugin execution, release retrieval, container use, CI/CD secret access, repository activity, identity use, package publication, cloud access, artifact creation, and downstream software consumption remained authorized during the exposure window.

Trust is further reduced when malicious activity occurs through expected GitHub identities, legitimate repositories, approved workflow systems, normal vulnerability-scanning activity, valid package-publishing credentials, legitimate package identities, trusted-publishing workflows, valid provenance attestations, approved developer extensions, legitimate CI/CD plugins, trusted registries, or normal CI/CD runners because attacker activity may resemble legitimate software-delivery behavior without sufficient identity, workflow, package, provenance, and timing context.

Removal of malicious Trivy artifacts, restoration of safe references, rotation of one credential, replacement of one runner, removal of a malicious package, or removal of a compromised extension or plugin reduces future exposure but does not independently prove that credentials were not stolen, reused, or propagated before remediation.

The LiteLLM compromise specifically demonstrates why restoration of the original upstream project does not establish downstream containment. Later trusted-publishing activity further demonstrates that valid provenance, signing, or authorized publication infrastructure does not independently establish that source content or a resulting package was trustworthy.

Visibility Confidence

Visibility confidence is highest when complete GitHub audit events, CI/CD job history, workflow logs, runner telemetry, developer-endpoint telemetry, process lineage, file-access telemetry, credential and secret-access evidence, repository changes, GitHub Actions history, npm and PyPI publication records, package-manager telemetry, extension and plugin installation or execution records, cloud audit logs, identity events, DNS and proxy logs, process-attributed network telemetry, container-registry records, caches, mirrors, SBOMs, build metadata, artifact provenance, release records, incident-response actions, and remediation evidence can be correlated through stable identities, repositories, workflows, runners, tokens, packages, versions, extensions, plugins, artifacts, destinations, and timestamps.

Visibility confidence is reduced when CI/CD runners are ephemeral, developer endpoints are unmonitored, process or file telemetry is unavailable, workflow history is incomplete, GitHub token use lacks attribution, secret access is not logged, package publication lacks source or workflow identity, dependency histories are unavailable, extension or plugin execution is not monitored, caches or mirrors lack historical records, egress is encrypted, or downstream consumers cannot establish whether affected software executed.

S25 provides strong independent coverage for runner-side execution, credential and token harvesting, identity abuse, outbound communication, and artifact or storage tampering. S26 classifies poisoned dependency ingestion as partially detected because reliable detection depends on approved reference baselines, dependency governance, and parsing quality. It also explicitly identifies fully stealth execution within normal workflow behavior as non-covered where activity produces no distinct execution, secret-access, network, identity, repository, or artifact anomaly.

Change-Control Confidence

Change-control confidence is high when repository identities, permissions, Action references, workflow changes, secret access, release publication, package-publishing identities, OIDC trusted-publishing relationships, provenance, plugin or extension updates, container-image publication, registry activity, cloud changes, emergency remediation, and incident-response actions are recorded with validated actors, systems, approvals, timestamps, expected objects, and post-change verification.

Confidence is reduced when mutable Action tags are used without immutable pinning, long-lived credentials remain exposed to CI/CD workflows, package-publishing authority is broadly scoped, OIDC publishing relationships are not restricted to expected workflows and refs, workflow permissions exceed operational requirements, secret access is not logged, repository metadata changes lack review, extensions or CI/CD plugins update without governance, or defender remediation cannot be distinguished from attacker-driven repository, workflow, tag, release, token, registry, package, extension, or plugin activity.

Downstream Dependency

Downstream dependency is high when affected workflows, repositories, credentials, CI/CD runners, developer workstations, package registries, internal mirrors, developer extensions, CI/CD plugins, container registries, artifact repositories, build images, AI services, customer-facing software, or release workflows depend on identities and automation paths that may have been exposed.

The organization must distinguish suspicious package installation, GitHub authentication, repository access, workflow execution, token use, package publication, extension or plugin execution, cloud access, artifact creation, outbound communication, dependency installation, persistence, and credential reuse from confirmed downstream compromise. Such activity becomes materially relevant when evidence ties it to an affected workflow, runner, developer endpoint, identity, repository, credential, package, version, extension, plugin, artifact, source, destination, or bounded investigation window.

Internal caches, container layers, build images, lockfiles, dependency caches, artifact repositories, internal package mirrors, extension caches, plugin stores, or generated software may preserve compromised content after public remediation. Upstream cleanup therefore does not independently establish downstream containment.

Confirmed LiteLLM and Telnyx compromise demonstrates that downstream dependency extends beyond organizations that executed compromised Trivy components directly. Later TeamPCP-linked campaigns reinforce that affected consumers may inherit risk through legitimate npm or PyPI packages, trusted GitHub Actions, developer extensions, CI/CD plugins, compromised repositories, or authorized trusted-publishing workflows without any direct relationship to the original Trivy project.

Customer and Regulatory Exposure

Customer, partner, workforce, and regulatory exposure increases when trusted-software or package-publishing compromise affects proprietary source code, customer-facing applications, AI services, release artifacts, credentials, cloud environments, production deployment paths, regulated information, financial systems, healthcare systems, government environments, critical infrastructure, or systems subject to notification, contractual, privacy, audit, litigation, or sector-specific obligations.

Exposure also increases when telemetry gaps prevent timely confirmation of whether credentials were harvested, repositories were accessed, package-publishing authority was abused, malicious downstream packages, extensions, or plugins executed, persistence was established, cloud resources were reached, customer-facing artifacts were affected, or additional propagation occurred.

Download counts, package inventories, registry statistics, extension or plugin installation counts, affected-version findings, or public exposure estimates should be treated as exposure-scoping evidence rather than proof that every retrieval resulted in installation, execution, credential theft, persistence, exfiltration, or customer impact. Notification and reporting decisions must be based on validated local evidence and applicable obligations.

Residual Economic Risk

Residual economic risk remains after malicious Trivy artifacts are removed, Action references are restored, credentials are rotated, runners or developer systems are rebuilt, affected downstream packages, extensions, or plugins are removed, caches are cleared, mirrors are corrected, and incident response is closed when the pre-remediation activity window cannot be reconstructed.

Removing an affected Trivy component does not prove that secrets available to the workflow were not harvested before remediation. Removing a malicious downstream package, extension, or plugin does not prove that credentials accessible to the component were not already collected, transmitted, or reused.

Residual risk should remain elevated until historical GitHub, CI/CD, developer-endpoint, runner, repository, credential, package-registry, extension, plugin, cloud, network, cache, mirror, artifact, release, identity, incident-response, and remediation evidence has been assessed and the organization can demonstrate that software-delivery, credential, repository, registry, cloud, developer-tool, artifact, and downstream trust have been restored.

Supply-Chain Behavioral Coverage Assessment

The current report directly covers the governing Trivy behavior family of trusted software-supply-chain compromise, malicious CI/CD execution, developer and CI/CD credential discovery, application-token exposure, valid-identity abuse, suspicious outbound communication, artifact or storage tampering, and downstream access.

The current OSINT-to-S25 comparison identifies fourteen additional named tradecraft patterns requiring adaptation:

·        CanisterWorm npm token-driven propagation

·        Checkmarx KICS GitHub Action and OpenVSX compromise

·        Trivy-to-LiteLLM PyPI propagation

·        Telnyx PyPI compromise

·        Post-compromise GitHub and cloud credential operationalization

·        Xinference supply-chain compromise

·        Later Checkmarx KICS and Bitwarden CLI supply-chain compromise

·        SAP-related npm / Lightning / Intercom Mini Shai-Hulud wave

·        Checkmarx Jenkins AST plugin compromise

·        TanStack and related npm/PyPI OIDC trusted-publishing compromise

·        @antv / actions-cool / nrwl.angular-console multi-ecosystem compromise

·        Aqua/GitHub repository and source-code compromise following developer-extension exposure

·        Miasma / Red Hat npm compromise including the later binding.gyp propagation wave

·        Multiple Microsoft-linked GitHub project compromises associated with TeamPCP activity

Direct coverage applies where material observable behavior is already represented by existing S25 execution, credential-access, identity, network, repository-integrity, or artifact-storage rules without substantive modification.

Coverage With Adaptation applies where S25 provides substantial upstream or downstream visibility but reliable detection requires additional package-ecosystem, repository, Action, IDE-extension, CI/CD-plugin, Python-runtime, Bun-runtime, npm-runtime, package-publication, OIDC trusted-publishing, provenance, persistence, Kubernetes, cloud-data-access, import-time execution, binding.gyp, source-code access, or other telemetry mappings.

The previous report statement that secondary supply-chain compromise had not been observed is superseded. Secondary software-supply-chain compromise is now confirmed.

CVE-2026-33634 remains the governing CVE for the original Trivy compromise. Direct coverage is based on the existing S25 behavior model rather than CVE presence alone.

CVE and KEV status remain urgency, remediation, and prioritization signals. They do not independently establish behavioral detection coverage.

The coverage ledger intentionally consolidates closely related campaign waves rather than counting every affected package, repository, Action, extension, plugin, namespace, or malicious version separately. For example, the SAP, Lightning, and Intercom activity is represented as one Mini Shai-Hulud campaign pattern, while the later binding.gyp activity is represented as an additional execution and propagation mechanism within the Miasma pattern.

Activity is not incorporated solely because it resembles TeamPCP or software-supply-chain tradecraft. Unrelated or insufficiently linked campaigns remain outside the current count.

Detection Engineering Coverage Interpretation

The existing S25 detection content provides direct behavioral coverage when activity produces one or more of these implemented outcomes:

·        Malicious or non-baseline execution on CI/CD compute following compromised Trivy or trusted-component ingestion

·        Suspicious credential or token discovery from CI/CD runners, environment variables, cloud secret stores, repository configuration, private-key locations, or other automation credential sources

·        Off-pattern valid-identity, IAM role, managed-identity, or service-account use following CI/CD compromise

·        Suspicious outbound communication or likely exfiltration from compromised CI/CD compute where process, host, identity, and network context can be correlated

·        Unauthorized Trivy-related tag, release, or repository activity where GitHub or equivalent source-control audit telemetry is available

·        Artifact or dependency storage modification in AWS S3, Azure Blob Storage, GCP Cloud Storage, or equivalent CI/CD artifact paths

·        Multi-source sequencing across CI/CD, endpoint, identity, GitHub, cloud, network, and artifact telemetry

S25 does not provide universal direct coverage for every package ecosystem or every downstream TeamPCP behavior. Its Trivy-specific ingestion rules depend on Trivy-related reference identification and approved baselines, while later campaign stages involve npm and PyPI publication, OpenVSX and VS Code extensions, non-Trivy GitHub Actions, Jenkins plugins, Python and Bun runtime behavior, package installation hooks, import-time execution, binding.gyp execution, persistent backdoors, Kubernetes activity, OIDC trusted publishing, provenance-valid malicious releases, generalized repository modification, source-code access, and broader post-compromise cloud data access.

Direct Coverage

Direct coverage applies where documented activity produces material behavior already represented by existing S25 rules without substantive changes to rule logic.

·        Original Trivy ecosystem compromise involving malicious Trivy releases, altered trivy-action references, compromised setup-trivy references, malicious CI/CD execution, runner credential harvesting, token exposure, suspicious outbound communication, unauthorized tag or release activity, cloud identity abuse, and artifact or storage tampering

The original Trivy behavior family remains Direct Coverage because S25 was specifically engineered around Trivy-related ingestion, runner execution, credential harvesting, identity abuse, external communication, repository integrity, and artifact manipulation.

Coverage With Adaptation

Coverage With Adaptation applies where S25 contains substantial relevant coverage but reliable detection of the complete documented chain requires additional mappings or logic.

·        CanisterWorm npm propagation involving stolen package-publishing tokens, enumeration of publishable packages, malicious publication, credential harvesting, and automated downstream propagation. Existing S25 credential, identity, execution, egress, and supply-chain behavior is relevant, but reliable detection requires npm registry, publishing-token, namespace, package-enumeration, publication, and propagation mappings.

·        Checkmarx KICS GitHub Action and OpenVSX compromise involving hijacked Action tags, CI/CD execution, credential theft, external transfer, malicious developer extensions, Kubernetes-focused activity, and persistence. Existing S25 Trivy Action and CI/CD behavior provides substantial visibility, but reliable implementation requires KICS, Checkmarx, OpenVSX, extension, repository, Action, Kubernetes, and persistence mappings.

·        Trivy-to-LiteLLM propagated PyPI compromise involving API-token exposure associated with the Trivy incident, unauthorized publication of LiteLLM 1.82.7 and 1.82.8, Python package execution, credential and file harvesting, outbound exfiltration, and downstream environment exposure. Existing S25 credential, identity, network, and propagation coverage is relevant, but reliable full-chain detection requires PyPI, Python-package, runtime, persistence, and downstream-execution mappings.

·        Telnyx PyPI supply-chain compromise involving malicious Telnyx releases, downstream Python execution, credential harvesting, external communication, and additional consumer exposure. Existing S25 execution, credential, identity, and egress behavior is relevant, but reliable detection requires Telnyx/PyPI, Python-runtime, package-import, payload-retrieval, and downstream-execution mappings.

·        TeamPCP post-compromise GitHub and cloud credential operationalization involving validation and use of stolen credentials for repository access, cloud reconnaissance, secret access, storage access, and additional data exposure. Existing S25 identity, cloud-secret, and outbound-communication rules provide meaningful coverage, but reliable detection of the complete chain requires broader repository-cloning, cloud object-read, data-access, service, resource, and post-compromise correlation mappings.

·        Xinference supply-chain compromise involving trojanized package publication and TeamPCP-linked package-hijacking behavior. Existing S25 supply-chain, execution, credential, and network behavior is relevant, but reliable detection requires Xinference, package-registry, Python-runtime, affected-version, and downstream-execution mappings.

·        Later Checkmarx KICS and Bitwarden CLI supply-chain compromise involving additional legitimate software-distribution abuse, package installation behavior, developer and CI/CD credential harvesting, and external transfer. Existing S25 credential, execution, identity, and network behavior is relevant, but reliable detection requires Bitwarden CLI, npm installation, package-specific, repository, and publication mappings.

·        SAP-related npm / Lightning / Intercom Mini Shai-Hulud activity involving npm preinstall execution, Python package compromise, developer and CI/CD credential harvesting, GitHub-based and dedicated exfiltration infrastructure, Kubernetes and HashiCorp Vault secret collection, and propagation using stolen credentials. Existing S25 execution, credential, cloud, identity, and egress behavior provides substantial visibility, but reliable detection requires npm/PyPI lifecycle, package-specific, Kubernetes, Vault, propagation, and exfiltration mappings.

·        Checkmarx Jenkins AST plugin compromise involving unauthorized modification and publication of a CI/CD security plugin through the Jenkins Marketplace. Existing S25 CI/CD execution, credential, identity, and external-communication coverage provides relevant downstream visibility, but reliable detection requires Jenkins plugin inventory, marketplace versioning, plugin installation, Jenkins execution lineage, and associated Checkmarx mappings.

·        TanStack and related trusted-publishing compromise involving trojanized npm and PyPI packages published through legitimate GitHub Actions OIDC trusted-publishing workflows using valid publishing identities and valid provenance context. Existing S25 identity, CI/CD, and supply-chain coverage provides relevant visibility, but reliable detection requires repository-to-workflow-to-OIDC-subject correlation, package-publication mapping, trusted-publishing relationships, provenance or build context, and preceding repository or workflow-change mappings.

·        TeamPCP @antv / actions-cool / nrwl.angular-console multi-ecosystem compromise involving npm packages, GitHub Actions, a VS Code extension, GitHub-hosted payload retrieval, Bun-based secondary execution, developer and cloud credential harvesting, external transfer, and persistent Python access. Existing S25 execution, credential, identity, and network coverage provides meaningful behavioral visibility, but reliable implementation requires npm, GitHub Action, VS Code extension, Bun runtime, developer-endpoint, payload-retrieval, persistence, and associated package or extension mappings.

·        Aqua/GitHub repository compromise following developer-tool or credential exposure involving unauthorized repository access, broad source-code exposure, and repository modification or metadata abuse. Existing S25 identity and repository-integrity coverage provides relevant signals, but reliable detection requires developer-endpoint linkage, organization-wide repository access, clone, metadata-change, source-code-access, actor, and administrative-baseline mappings.

·        Miasma / Red Hat Cloud Services npm compromise and later binding.gyp propagation wave involving unauthorized package modification, preinstall execution, obfuscated JavaScript, OIDC-backed trusted publication, credential harvesting, cloud-identity collection, and later binding.gyp-driven installation-time execution and worm-like propagation. Existing S25 execution, credential, identity, cloud, and supply-chain behavior is relevant, but reliable detection requires Red Hat/npm, OIDC subject, workflow, provenance, package-publication, JavaScript runtime, binding.gyp execution, cloud-identity, and propagation mappings.

·        TeamPCP compromise of multiple Microsoft-linked GitHub projects involving malicious modification of legitimate software-development repositories or projects and distribution of trojanized software through trusted development channels. Existing S25 repository, identity, execution, and supply-chain behavior provides relevant visibility, but reliable detection requires the affected Microsoft-linked repositories, project-specific build and release context, repository-change telemetry, publishing lineage, and downstream-execution mappings.

These fourteen patterns remain Coverage With Adaptation because reliable implementation requires ecosystem- or behavior-specific mappings beyond the current Trivy-focused S25 rules. This classification does not require rewriting S25 as part of the current amendment.

Non-Coverage Conditions

Non-coverage applies where activity does not produce observable CI/CD execution deviation, credential access, identity abuse, repository or release activity, suspicious outbound communication, cloud activity, artifact modification, or other behavior aligned with the existing detection model.

Non-coverage applies when activity remains limited to:

·        Trivy, LiteLLM, Telnyx, Xinference, npm, PyPI, OpenVSX, VS Code, Jenkins, package, repository, Action, workflow, plugin, version, lockfile, SBOM, cache, mirror, container-image, extension, or artifact presence without aligned execution or compromise evidence

·        Download counts, registry statistics, package statistics, extension or plugin installation statistics, public exposure estimates, affected-version records, version removal, tag restoration, or clean-version publication without evidence of local execution or credential exposure

·        Package names, versions, workflow names, filenames, hashes, domains, IP addresses, source addresses, actor names, campaign names, or other static indicators without aligned local behavior

·        GitHub authentication, repository access, tag modification, release activity, workflow changes, OIDC use, or trusted-publishing events that cannot be distinguished from authorized development, release engineering, security testing, package recovery, or incident response

·        Package publication with valid provenance or trusted-publishing metadata when no evidence establishes unauthorized source, workflow, identity, or package modification

·        Package, plugin, or extension installation without evidence of execution, credential access, suspicious outbound communication, persistence, identity abuse, cloud activity, or downstream impact

·        Internal cache, mirror, container, build-image, extension-cache, plugin store, or artifact presence without evidence of execution, modification, promotion, deployment, or affected release output

·        Cloud or identity anomalies that cannot be tied to an affected workflow, runner, developer endpoint, identity, credential, repository, package, extension, plugin, source, destination, or bounded incident window

·        Unrelated package compromise, unrelated credential theft, unrelated endpoint malware, unrelated SaaS abuse, unrelated vulnerability exploitation, or unrelated package-reputation findings

·        Later supply-chain incidents that resemble TeamPCP tradecraft but lack sufficient evidence of campaign linkage or relevant behavior-family continuity

·        Customer impact, cloud compromise, credential theft, package publication, actor attribution, campaign attribution, or downstream compromise inferred solely from affected-version or static-indicator presence

·        Fully stealth malicious execution that remains indistinguishable from authorized workflow behavior and produces no detectable execution deviation, new secret access, network anomaly, identity deviation, repository change, or artifact behavior

·        Environments where required CI/CD, endpoint, GitHub, identity, package-registry, extension, plugin, cloud, network, artifact, timestamp, retention, approved-workflow, or incident-response context is unavailable

Current Coverage Count

The current coverage disposition is:

Directly Covered CVEs

1

CVE-2026-33634

CVEs Covered With Adaptation

0

Current CVE Coverage Count

1

CVE-2026-33634 is directly covered because existing S25 rules represent the material Trivy behavior family of poisoned trusted-component ingestion, malicious CI/CD execution, credential and token harvesting, valid-identity abuse, suspicious outbound communication, repository or release manipulation, and artifact or storage tampering.

Current KEV Count

1

CVE-2026-33634 is represented in the current coverage set and is confirmed in the CISA Known Exploited Vulnerabilities catalog.

Directly Covered Named Malware / Tooling / Tradecraft Patterns

1

·        Original Trivy ecosystem release, GitHub Action, setup-trivy, CI/CD credential-harvesting, identity-abuse, exfiltration, and artifact-manipulation behavior

Named Malware / Tooling / Tradecraft Patterns Covered With Adaptation

14

·        CanisterWorm npm token-driven propagation

·        Checkmarx KICS GitHub Action and OpenVSX compromise

·        Trivy-to-LiteLLM propagated PyPI compromise

·        Telnyx PyPI compromise

·        TeamPCP post-compromise GitHub and cloud credential operationalization

·        Xinference supply-chain compromise

·        Later Checkmarx KICS and Bitwarden CLI supply-chain compromise

·        SAP-related npm / Lightning / Intercom Mini Shai-Hulud campaign wave

·        Checkmarx Jenkins AST plugin compromise

·        TanStack and related OIDC trusted-publishing compromise

·        @antv / actions-cool / nrwl.angular-console multi-ecosystem compromise

·        Aqua/GitHub repository and source-code compromise

·        Miasma / Red Hat npm and binding.gyp propagation campaign

·        TeamPCP compromise of multiple Microsoft-linked GitHub projects

Total Named Malware / Tooling / Tradecraft Patterns Represented

15

APT / Actor / Campaign Activity Names Covered With Adaptation

1

TeamPCP

Mini Shai-Hulud, CanisterWorm, and Miasma are retained as malware, tooling, or tradecraft names within the named-pattern accounting and are not independently counted as additional actor identities.

Directly Covered Core Behavior Classes

5 core behavior classes:

·        Malicious execution on CI/CD compute

·        Credential and application-token harvesting

·        Valid-identity, IAM role, managed-identity, or service-account abuse

·        Outbound communication and exfiltration with correlation

·        Artifact or supply-chain storage tampering

Core Behavior Classes Covered With Adaptation / Partial Coverage

1 core behavior class:

·        Poisoned dependency ingestion or unauthorized upstream reference consumption

S26 classifies poisoned dependency ingestion as Partially Detected because reliable detection depends on approved dependency or reference baselines, dependency governance, and parsing quality.

Explicit Non-Coverage Core Behavior Classes

1 core behavior class:

·        Fully stealth execution within normal workflow context where malicious activity produces no distinguishable execution, credential-access, network, identity, repository, or artifact anomaly

The updated coverage disposition therefore contains 1 directly covered CVE, 0 CVEs covered with adaptation, 1 KEV, 1 directly covered named tradecraft pattern, 14 named tradecraft patterns covered with adaptation, 15 total named patterns represented, 1 actor or campaign identity represented with adaptation, 5 directly covered core behavior classes, 1 partially covered or adaptation core behavior class, and 1 explicit non-coverage behavior class.

Coverage Qualification

Coverage is strongest where affected Trivy or related supply-chain activity can be joined with runner and process telemetry, credential or secret access, GitHub identity and repository activity, token use, workflow or package-publication events, cloud actions, suspicious outbound communication, artifact modification, affected downstream package, extension, or plugin execution, persistence, or bounded post-compromise activity.

Direct coverage is strongest for the original Trivy behavior family because the current S25 rules explicitly model Trivy references, Trivy and setup-trivy execution context, runner secret harvesting, unauthorized Trivy tag or release activity, cloud identity misuse, suspicious external communication, and artifact or storage modification.

Coverage for later TeamPCP stages is weaker where the material execution or publication boundary moves into npm, PyPI, OpenVSX, VS Code, Jenkins, non-Trivy GitHub Actions, Python or Bun runtime execution, package lifecycle hooks, import-time execution, binding.gyp execution, persistent backdoors, Kubernetes, OIDC trusted publishing, provenance-valid malicious releases, generalized repository manipulation, source-code access, or broad post-compromise cloud data access. These behaviors retain substantial upstream or downstream coverage but require adaptation for reliable end-to-end detection.

Coverage is also weaker where CI/CD runners are ephemeral, developer endpoints are unmonitored, workflow history is incomplete, secret access is not logged, package-publication events lack source identity, OIDC subject and workflow relationships are unavailable, dependency histories are incomplete, extension or plugin execution is not monitored, network egress is encrypted, internal caches or mirrors lack historical records, identity lineage is incomplete, or downstream artifacts cannot be mapped to the exposure window.

The report does not claim universal software-supply-chain compromise detection, universal package-publishing detection, universal CI/CD credential-theft detection, universal GitHub compromise detection, universal npm, PyPI, OpenVSX, VS Code, or Jenkins coverage, universal trusted-publishing abuse detection, universal cloud detection, complete visibility across every repository, package ecosystem, build system, CI/CD engine, developer tool, registry, cloud platform, or downstream consumer environment, or standalone actor, campaign, malware, vulnerability, or impact attribution.

Detection confidence depends on telemetry completeness, asset and identity validation, repository and workflow mapping, CI/CD job retention, runner and developer-endpoint visibility, secret-access evidence, GitHub audit retention, token attribution, OIDC publishing identity and subject mapping, package and version inventories, package-registry visibility, extension and plugin telemetry, process and file telemetry, process-to-network attribution, cloud audit retention, cache and mirror history, artifact provenance, approved-reference and approved-publishing baselines, timestamp alignment, rule validation, performance testing, false-positive testing, and SOC triage readiness.

Executive Exposure Statement

The organization's economic exposure is highest when compromise of trusted Trivy software or related software-delivery workflows creates uncertainty over whether developer credentials, GitHub identities, source-code repositories, CI/CD workflows, package-publishing credentials, trusted-publishing identities, cloud identities, container registries, developer extensions, CI/CD plugins, AI services, release artifacts, downstream packages, and customer-facing software remained trustworthy.

The strategic risk is no longer limited to the possibility that a malicious Trivy artifact could steal credentials from one downstream environment. Confirmed propagation into LiteLLM and subsequent TeamPCP activity demonstrate that one trusted software-supply-chain compromise can expose another project's software-delivery authority, poison additional legitimate distribution ecosystems, abuse valid publishing and provenance mechanisms, create new downstream consumer populations, establish persistence, compromise source repositories, and repeat credential theft or access abuse before containment.

Secondary software-supply-chain compromise is therefore confirmed. The material risk is that one compromised release credential, trusted security component, CI/CD runner, repository token, package-publishing identity, trusted-publishing workflow, developer extension, CI/CD plugin, cloud identity, or downstream package can become the bridge between an upstream software compromise and cascading enterprise, cloud, source-code, customer, or software-integrity exposure.

S40 — References

The following references support the Trivy compromise, CVE and KEV status, confirmed downstream propagation, broader TeamPCP campaign evolution, current coverage classifications, coverage counts, and detection-engineering interpretation in this report.

Vendor / Primary Trivy Advisory

Aqua Security / Trivy GitHub Security Advisory — Trivy Ecosystem Supply Chain Temporarily Compromised — GHSA-69fq-xp46-6x23

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

Vulnerability Record

NVD — CVE-2026-33634

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-33634

Incident Records — Original Trivy and March Propagation

Wiz — Trivy Compromised: Everything You Need to Know about the Latest Supply Chain Attack

hxxps://www[.]wiz[.]io/blog/trivy-compromised-teampcp-supply-chain-attack

Wiz — KICS GitHub Action Compromised: TeamPCP Strikes Again in Supply Chain Attack

hxxps://www[.]wiz[.]io/blog/teampcp-attack-kics-github-action

Wiz — Three's a Crowd: TeamPCP Trojanizes LiteLLM in Continuation of Campaign

hxxps://www[.]wiz[.]io/blog/threes-a-crowd-teampcp-trojanizes-litellm-in-continuation-of-campaign

Wiz — Tracking TeamPCP: Investigating Post-Compromise Attacks Seen in the Wild

hxxps://www[.]wiz[.]io/blog/tracking-teampcp-investigating-post-compromise-attacks-seen-in-the-wild

Datadog Security Labs — LiteLLM and Telnyx Compromised on PyPI: Tracing the TeamPCP Supply Chain Campaign

hxxps://securitylabs[.]datadoghq[.]com/articles/litellm-compromised-pypi-teampcp-supply-chain-campaign/

Incident Records — April TeamPCP Expansion

Wiz Threat Research — Xinference Compromised in Supply Chain Attack

hxxps://threats[.]wiz[.]io/all-incidents/xinference-compromised-in-supply-chain-attack

Wiz Threat Research — Checkmarx KICS and Bitwarden CLI Compromised in Fresh Supply Chain Attack

hxxps://threats[.]wiz[.]io/all-incidents/checkmarx-kics-and-bitwarden-cli-compromised-in-fresh-supply-chain-attack

Wiz — Supply Chain Campaign Targets SAP npm Packages with Credential-Stealing Malware

hxxps://www[.]wiz[.]io/blog/mini-shai-hulud-supply-chain-sap-npm

Incident Records — May TeamPCP Expansion

Checkmarx — Ongoing Security Updates

hxxps://checkmarx[.]com/blog/ongoing-security-updates/

Wiz — Mini Shai-Hulud Strikes Again: TanStack + More npm Packages Compromised

hxxps://www[.]wiz[.]io/blog/mini-shai-hulud-strikes-again-tanstack-more-npm-packages-compromised

Wiz — The Worm That Keeps on Digging: TeamPCP Hits @antv in Latest Wave

hxxps://www[.]wiz[.]io/blog/mini-shai-hulud-teampcp-hits-antv-supply-chain

Wiz Threat Research — TeamPCP Claims Breach of Internal GitHub Repositories

hxxps://threats[.]wiz[.]io/all-actors/teampcp

Incident Records — June TeamPCP and Related Tradecraft

Wiz — Miasma: Supply Chain Attack Targeting Red Hat npm Packages

hxxps://www[.]wiz[.]io/blog/miasma-supply-chain-attack-targeting-redhat-npm-packages

Wiz Threat Research — Binding.gyp Supply Chain Attack Enables CI/CD Worm Propagation Across npm Packages

hxxps://threats[.]wiz[.]io/all-actors/teampcp

Wiz Threat Research — TeamPCP Adds Malware to Multiple Microsoft-Linked GitHub Projects

hxxps://threats[.]wiz[.]io/all-actors/teampcp

Actor / Campaign Context

Wiz Threat Research — TeamPCP

hxxps://threats[.]wiz[.]io/all-actors/teampcp

Known Exploited Vulnerabilities

CISA Known Exploited Vulnerabilities Catalog

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

Threat Tradecraft and Analytical Framework

MITRE ATT&CK Framework — Enterprise Matrix

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