[EXP] Self-Hosted Git Platform Compromise Through Repository Workflow Abuse

Report Type: EXP

Threat Category: Repository workflow abuse and CI/CD supply-chain compromise

Assessment Date: June 2, 2026

Primary Impact Domain: Software supply chain and trusted automation integrity

Secondary Impact Domains: Cloud identity and control-plane exposure; Kubernetes and deployment infrastructure exposure; package, artifact, and container registry integrity; credential and secret exposure

Affected Asset Class: Self-hosted Git platforms, source-code repositories, CI/CD workflows, runners, automation credentials, registries, package pipelines, deployment pipelines, and connected cloud or Kubernetes environments

Threat Objective Classification: Repository-to-CI/CD compromise enabling trusted automation misuse, credential access, downstream registry or package manipulation, cloud-control-plane access, Kubernetes exposure, and deployment-path compromise

BLUF

‍  Self-hosted Git platform compromise through repository workflow abuse creates material enterprise risk because successful abuse can turn trusted source-code, CI/CD, runner, registry, artifact, package, container, and deployment infrastructure into a path for unauthorized execution, credential exposure, build manipulation, cloud-control-plane activity, Kubernetes activity, or downstream production impact. The core risk is not limited to whether a repository or workflow was changed; it is whether an attacker can use trusted software-delivery infrastructure to alter release behavior, expose secrets, abuse automation identities, manipulate artifacts or images, or create uncertainty around the integrity of systems that build, package, deploy, and maintain business-critical software. Suspicious workflow, runner, token, webhook, deploy-key, registry, artifact, or cloud activity becomes materially significant when it forms a lineage chain from repository control into CI/CD execution, credential access, external transfer, registry activity, package or image manipulation, deployment action, or cloud and Kubernetes control-plane use. Immediate executive action is required to validate sensitive repository exposure, harden CI/CD and runner control paths, confirm telemetry completeness, map automation identity lineage, and ensure suspected software-delivery compromise is treated as a control-plane incident rather than an isolated development-platform event.

Executive Risk Translation

Self-hosted Git platform compromise through repository workflow abuse shifts the business risk from ordinary source-code management exposure to loss of confidence in the software-delivery control plane. If repository workflow integrity, CI/CD runner execution, automation credentials, registry outputs, deployment paths, or cloud-linked identities cannot be validated, leadership may need to assume that trusted build and release systems could have exposed secrets, altered artifacts, modified packages or container images, changed deployment behavior, or enabled downstream cloud and Kubernetes access. That response can expand quickly into repository and workflow review, runner containment, token and secret rotation, package and image validation, artifact integrity review, cloud and Kubernetes scoping, deployment rollback analysis, customer-impact assessment, legal and executive reporting, and broader assurance work across systems that depend on trusted software delivery.

S3 — Why This Matters Now

·        Self-hosted Git platforms and CI/CD systems are software-delivery control points that can influence source code, secrets, package publication, container images, deployment automation, infrastructure-as-code, and production release paths.

·        Repository workflow abuse can carry greater business impact than ordinary source-code access because trusted automation may execute attacker-controlled logic under approved runner, token, service-account, or deployment identity context.

·        Suspicious workflow changes can force the organization to validate whether CI/CD jobs exposed protected variables, accessed secret stores, manipulated artifacts, altered package or image outputs, or used automation credentials outside expected scope.

·        The highest-risk condition occurs when repository-control activity is followed by CI/CD execution, runner-host process activity, credential access, outbound transfer, registry access, package publication, image push, deployment activity, cloud API use, or Kubernetes API use.

·        Legitimate release engineering, workflow refactoring, runner migration, package publication, container builds, infrastructure deployment, vulnerability scanning, and incident-response activity can resemble suspicious behavior and increase triage burden.

·        Missing Git audit logs, incomplete CI/CD job logs, weak runner telemetry, limited command-line visibility, incomplete registry logs, poor cloud identity mapping, or short retention can force broader investigation because software-delivery lineage cannot be proven quickly.

·        Downstream dependency on cloud environments, Kubernetes clusters, deployment systems, package registries, container registries, artifact stores, customer-facing applications, or business-critical production systems can expand the incident beyond the Git platform layer.

S4 — Key Judgments

·        Self-hosted Git platform compromise through repository workflow abuse should be treated as a software-delivery control-plane risk, not only a repository security or DevOps hygiene issue.

·        The primary enterprise risk is unauthorized or suspicious use of trusted repository automation, CI/CD runners, deploy keys, access tokens, webhooks, service accounts, workload identities, registry credentials, or deployment identities.

·        Suspicious workflow modification followed by CI/CD execution, credential inspection, artifact access, package or image activity, runner egress, cloud API use, Kubernetes API use, or deployment action is the strongest executive risk signal.

·        Workflow edits, runner changes, token creation, webhook changes, registry access, or isolated pipeline failures should not be treated as confirmed compromise without supporting repository, CI/CD, runner, identity, endpoint, network, registry, cloud, Kubernetes, or incident-response evidence.

·        Business exposure increases sharply when suspicious activity involves sensitive repositories, production deployment workflows, signing workflows, package-publishing workflows, image-publishing workflows, infrastructure-as-code repositories, privileged runners, or automation identities with downstream access.

·        Incomplete telemetry increases cost because the organization may need to prove software-delivery integrity through expanded repository, CI/CD, runner, endpoint, network, registry, package, artifact, cloud, Kubernetes, deployment, and change-management review.

·        The most damaging outcome occurs when repository workflow abuse enables credential theft, malicious build execution, package or image manipulation, artifact replacement, deployment compromise, cloud or Kubernetes control-plane abuse, customer-facing release impact, data exposure, extortion, or loss of confidence in the organization’s software-delivery process.

S5 — Executive Risk Summary

Business Risk

Self-hosted Git platform compromise through repository workflow abuse can undermine confidence in the organization’s ability to build, package, release, and deploy trusted software. Risk increases when suspicious activity involves sensitive repositories, privileged workflows, CI/CD runners, protected variables, deploy keys, tokens, webhooks, registry credentials, package-publishing systems, container image pipelines, signing workflows, infrastructure-as-code repositories, deployment systems, cloud accounts, Kubernetes clusters, customer-facing applications, or business-critical production environments.

Technical Cause

The risk is driven by suspicious or unauthorized interaction with repository workflow, CI/CD, runner, token, webhook, deploy-key, automation identity, registry, package, artifact, cloud, Kubernetes, or deployment paths that may precede or enable malicious workflow execution, credential exposure, protected-variable access, artifact staging, package or image manipulation, registry abuse, external transfer, service-principal use, workload-identity use, infrastructure changes, or downstream deployment activity.

Threat Posture

The threat posture is elevated because suspected or confirmed repository workflow abuse can affect trusted software-delivery systems while downstream platforms may continue accepting build outputs, artifacts, packages, images, deployment actions, and automation identities as legitimate. The posture becomes critical when suspicious repository or CI/CD activity is followed by credential access, runner-host execution, unusual outbound communication, registry or package activity, image push, release artifact modification, deployment execution, cloud-control-plane activity, Kubernetes-control-plane activity, production workload modification, data access, extortion, or broad loss of confidence in software-delivery integrity.

Executive Decision Requirement

Executives must require measurable assurance that sensitive repositories are inventoried, workflow changes are governed, CI/CD runners are segmented and monitored, automation identities are mapped, protected variables and secrets are constrained, registry and package activity is auditable, cloud and Kubernetes activity can be tied back to CI/CD lineage, and response teams can rapidly validate, contain, scope, and recover from suspected software-delivery control-plane compromise.

S6 — Executive Cost Summary

Self-hosted Git platform compromise through repository workflow abuse creates scenario-based financial exposure when an organization must prove or disprove whether repository integrity, CI/CD execution, runner trust, protected variables, automation credentials, package outputs, container images, artifacts, deployment paths, cloud identities, Kubernetes access, and production release behavior remained intact. The estimated impact is driven by repository and workflow review, runner containment, token and secret rotation, CI/CD job reconstruction, protected-variable validation, artifact and cache review, package and image integrity validation, registry audit, deployment rollback analysis, cloud and Kubernetes scoping, endpoint and network investigation, legal and executive reporting, customer-impact assessment, and potential business restoration if untrusted build outputs or deployment activity reached production.

Low Impact Scenario

Rapid detection confirms attempted workflow abuse, suspicious repository activity, isolated runner execution, limited token or webhook activity, unusual pipeline behavior, or a small number of suspicious CI/CD events. No confirmed credential theft is identified, no protected variables are exposed, no malicious package or image publication occurs, no release artifact is modified, no downstream cloud or Kubernetes activity is observed, no production deployment is affected, and telemetry is sufficient to validate the repository-to-runner activity path quickly; estimated impact $750K – $3.5M.

Moderate Impact Scenario

Confirmed or strongly suspected repository workflow abuse, runner misuse, protected-variable exposure, automation credential misuse, registry access, artifact access, package activity, image activity, or deployment uncertainty requires the organization to treat the event as a software-delivery control-plane incident even without confirmed customer impact, confirmed data theft, confirmed ransomware, or full production compromise. Response requires repository and workflow review, CI/CD pipeline reconstruction, runner isolation, token and secret rotation, deploy-key and webhook validation, package and container registry review, artifact integrity validation, cloud and Kubernetes identity scoping, deployment review, SOC surge activity, change-management validation, legal and executive reporting, and downstream validation of production, cloud, Kubernetes, source-code, package, image, artifact, and release environments; estimated impact $6M – $25M.

High Impact Scenario

Repository workflow abuse becomes an enterprise-impact pathway when it leads to or must be treated as malicious build execution, credential theft, trusted package or image manipulation, release artifact replacement, production deployment compromise, cloud or Kubernetes control-plane abuse, customer-facing software impact, data theft, extortion, ransomware staging, or broad loss of confidence in software-delivery integrity. The upper end of this range applies only when the organization must halt or roll back releases, validate or rebuild CI/CD infrastructure, rotate high-risk automation credentials at scale, verify package and image integrity, review customer-consumed artifacts, contain cloud or Kubernetes changes, restore production systems affected through the compromised software-delivery path, or support customer, regulatory, legal, cyber-insurance, and board-level response; estimated impact $30M – $125M+.

S6A — Key Cost Drivers

·        Number and criticality of affected repositories, projects, groups, workflows, branches, runners, registries, packages, images, artifacts, deployment systems, cloud accounts, Kubernetes clusters, and production environments.

·        Whether suspicious activity involves production deployment workflows, signing workflows, package-publishing workflows, image-publishing workflows, infrastructure-as-code repositories, privileged runners, shared runners, persistent runners, or runners with Docker socket access or internal network reach.

·        Ability to reconstruct the activity path across Git audit logs, CI/CD job logs, runner telemetry, process telemetry, command-line telemetry, identity logs, deploy-key records, token lifecycle events, webhook logs, registry logs, package-service logs, artifact logs, cloud logs, Kubernetes logs, deployment logs, network telemetry, and change-management records.

·        Scope of repository review, workflow review, merge request review, commit validation, runner containment, CI/CD job reconstruction, artifact review, cache review, package validation, image validation, release validation, and downstream deployment analysis.

·        Scope of token revocation, protected-variable review, secret rotation, deploy-key removal, webhook removal, service-account validation, workload-identity validation, signing-material review, registry credential rotation, cloud credential rotation, and Kubernetes credential review.

·        Whether suspicious activity is followed by credential access, protected-variable exposure, external transfer, artifact staging, package publication, image push, release artifact modification, deployment action, cloud API use, Kubernetes API use, infrastructure changes, data access, ransomware staging, or extortion behavior.

·        Extent of downstream access to cloud environments, Kubernetes clusters, deployment platforms, package registries, container registries, artifact stores, source-code systems, customer-facing applications, developer systems, identity providers, secret stores, databases, file stores, or sensitive business applications.

·        Completeness and reliability of Git audit logs, CI/CD pipeline logs, runner telemetry, endpoint telemetry, NDR telemetry, DNS logs, proxy logs, firewall logs, registry logs, package logs, cloud logs, Kubernetes logs, deployment logs, identity logs, and SIEM correlation.

·        Strength of repository inventory, runner inventory, automation identity mapping, service-account mapping, workload-identity mapping, package and image ownership records, artifact lineage, deployment ownership, approved workflow baselines, release windows, and change-control documentation.

·        Need for external incident response, forensic support, DevOps engineering surge support, cloud response support, Kubernetes response support, legal review, cyber-insurance coordination, customer notification, regulatory analysis, executive reporting, board-level governance, release rollback, or business restoration when software-delivery integrity cannot be validated quickly.

S6B — Compliance and Risk Context

Figure 1

Compliance Exposure Indicator

High

Risk Register Entry

Risk Title

Self-Hosted Git Platform Workflow Abuse and Software-Delivery Control-Plane Exposure

Risk Description

Adversaries may compromise or abuse self-hosted Git platform workflow, CI/CD, runner, token, deploy-key, webhook, registry, package, artifact, cloud, Kubernetes, or deployment paths to execute unauthorized logic, expose secrets, manipulate build outputs, alter packages or container images, modify release artifacts, abuse automation identities, or move downstream into production-adjacent systems. This may reduce confidence in software-delivery integrity, source-code trust, build provenance, deployment control, cloud and Kubernetes governance, customer-facing release assurance, and business-critical application integrity.

Likelihood

High

Impact

Severe

Risk Rating

Critical

Annualized Risk Exposure

Estimated $6M – $30M+ for materially exposed enterprise environments with self-hosted Git dependency, broad CI/CD runner access, sensitive repository exposure, incomplete Git or CI/CD telemetry, privileged automation identity exposure, weak runner segmentation, limited package or image lineage, incomplete change-management validation, or high downstream dependency on automated deployment paths. Exposure may exceed $50M – $125M+ where confirmed software-delivery compromise requires enterprise-scale credential rotation, CI/CD rebuild, package or image integrity validation, customer-facing release review, production rollback, cloud or Kubernetes containment, regulatory response, customer notification, extortion response, or restoration of business-critical systems affected through the compromised software-delivery path.

S7 — Risk Drivers

·        Self-hosted Git platforms and CI/CD systems are central to source-code control, workflow execution, build automation, package publication, image publication, artifact generation, and deployment automation.

·        Repository workflow abuse can create uncertainty about whether trusted automation executed unauthorized logic or exposed protected variables, tokens, credentials, signing material, package credentials, registry credentials, cloud credentials, or Kubernetes credentials.

·        Suspicious activity involving workflow changes, runner execution, token creation, deploy-key changes, webhook modification, service-account use, workload-identity use, or registry access materially increases business exposure.

·        Privileged maintainers, automation identities, bot accounts, service accounts, deployment identities, package-publishing identities, image-publishing identities, cloud identities, Kubernetes identities, dormant accounts, newly privileged accounts, or low-frequency high-privilege accounts can materially increase downstream risk.

·        Broad runner access to internal services, secret stores, registries, package mirrors, artifact stores, cloud endpoints, Kubernetes APIs, deployment controllers, or production networks can expand the impact of suspicious CI/CD execution.

·        Missing Git audit logs, incomplete CI/CD job logs, weak endpoint telemetry on runners, metadata-only network visibility, incomplete registry logs, weak package or image lineage, or stale repository and runner inventory can force broader investigation and assurance work.

·        Incomplete change-management records, weak workflow baselines, unclear runner ownership, incomplete automation identity mapping, undocumented package publication workflows, and weak deployment records can increase false positives and response cost.

·        Downstream access to cloud environments, Kubernetes clusters, deployment systems, secret stores, package registries, container registries, artifact stores, source-code systems, customer-facing applications, databases, file stores, or sensitive business applications increases operational and financial impact.

·        Security-control disruption, audit-log gaps, runner tampering, monitoring blind spots, suspicious outbound communication, or incomplete retention near suspicious repository and CI/CD activity increase concern that the organization may not be seeing the full incident.

·        Malicious package publication, container image manipulation, artifact replacement, credential theft, production deployment compromise, cloud or Kubernetes control-plane activity, data access, ransomware staging, customer-facing release impact, or extortion behavior can expand the incident from development infrastructure into enterprise-wide business disruption.

S8 — Bottom Line for Executives

Self-hosted Git platform compromise through repository workflow abuse should be treated as a high-priority software-delivery control-plane risk because it can affect the systems that determine what code is built, what secrets are exposed, what packages or images are published, what artifacts are trusted, and what deployments reach production. The executive question is not only whether a repository workflow was changed; it is whether the organization can prove that repository integrity, runner execution, automation credentials, protected variables, packages, images, artifacts, deployment paths, cloud identities, Kubernetes access, and production release behavior remained trustworthy. Response must focus on validating software-delivery lineage, hardening workflow and runner control paths, scoping automation credential exposure, confirming telemetry completeness, and ensuring suspected repository workflow abuse can be contained before it becomes trusted build, release, cloud, Kubernetes, or production compromise.

S9 — Board-Level Takeaway

Self-hosted Git platform workflow abuse turns software delivery into a board-level resilience and trust issue. The risk is not limited to source-code management or DevOps tooling; it is the possibility that attackers can use trusted automation to expose secrets, alter build outputs, manipulate packages or images, abuse deployment identities, or cast doubt on the integrity of systems that deliver business-critical software. Leadership should require measurable assurance that sensitive repositories are governed, CI/CD runners are segmented and monitored, automation identities are mapped and constrained, protected variables and secrets are controlled, package and image lineage is auditable, cloud and Kubernetes activity can be tied back to CI/CD context, suspicious software-delivery activity is escalated rapidly, and downstream production, customer-facing, cloud, Kubernetes, registry, artifact, and deployment exposure can be scoped with confidence.

S10 — Threat Overview

Self-hosted Git platform compromise through repository workflow abuse describes adversary behavior intended to exploit or abuse trusted repository, workflow, CI/CD, runner, registry, artifact, package, container, and deployment paths in a way that can place software-delivery integrity, automation identity trust, protected variables, build outputs, release artifacts, and downstream production access in question. The behavior is most relevant when suspicious repository-control activity, workflow modification, deploy-key creation, token creation, webhook modification, OAuth application activity, runner registration, or CI/CD execution is followed by credential access, protected-variable exposure, outbound runner communication, artifact access, package or image activity, registry abuse, deployment activity, cloud API use, Kubernetes API use, or infrastructure-as-code execution.

·        This is not only a single-CVE, single-repository, single-workflow, or vulnerability-state model.

·        The core threat behavior is abuse of a software-delivery control path where trusted automation may execute attacker-controlled logic or expose sensitive credentials after suspicious repository or workflow activity.

·        The primary risk is loss of confidence in the systems used to build code, publish packages, push container images, generate artifacts, trigger deployments, and manage cloud or Kubernetes-adjacent automation.

·        Git audit, CI/CD, runner, endpoint, identity, network, registry, package, artifact, cloud, Kubernetes, and deployment evidence may be incomplete or difficult to reconcile while downstream systems continue trusting build outputs and automation identities.

·        The behavior can allow attackers to affect or create uncertainty around repository integrity, workflow integrity, protected variables, secrets, deploy keys, access tokens, service accounts, workload identities, package outputs, container images, release artifacts, deployment automation, cloud access, Kubernetes access, and production-adjacent systems.

·        Current proof-point activity should support the relevance of the behavior class but should not narrow the report into a single-CVE, single-platform, single-tool, single-workflow-file, or single-proof-of-concept analysis.

S11 — Threat Classification and Type

Threat Type

Software-delivery control-plane compromise and self-hosted Git workflow abuse exposure

Threat Sub-Type

Repository workflow abuse, CI/CD runner misuse, automation credential exposure, deploy-key abuse, access-token abuse, webhook abuse, OAuth application abuse, protected-variable exposure, registry or package activity, artifact manipulation, container image activity, and downstream cloud, Kubernetes, or deployment-control exposure.

Operational Classification

Intrusion-enabling software-delivery control-plane compromise pathway

Primary Function

Exploit or abuse trusted repository workflow, CI/CD runner, automation credential, registry, package, artifact, container image, and deployment paths to execute unauthorized logic, expose secrets, manipulate build or release outputs, preserve access through automation mechanisms, or move from source-code control into downstream cloud, Kubernetes, deployment, or production-adjacent environments.

S12 — Campaign or Activity Overview

Figure 2

This report assesses self-hosted Git platform compromise through repository workflow abuse as a durable behavior class rather than a single campaign. The activity pattern involves adversaries attempting to exploit or abuse repository workflow and CI/CD execution paths where successful or suspected activity can affect protected variables, automation credentials, runner trust, build outputs, package publication, image publication, release artifacts, deployment systems, cloud identities, Kubernetes identities, or production-adjacent access.

·        The activity is best understood as a software-delivery control-plane trust failure rather than a simple repository change, source-code access event, or isolated CI/CD misconfiguration.

·        Adversaries may target workflow files, CI/CD configuration, merge requests, protected branches, runner registration, runner tags, deploy keys, project tokens, group tokens, personal access tokens, OAuth applications, webhooks, service accounts, workload identities, protected variables, registry credentials, package credentials, or deployment credentials.

·        The behavior may involve direct repository modification, abuse of a compromised maintainer account, use of an external contributor path, suspicious automation identity activity, malicious workflow execution, unauthorized runner use, secret inspection, build artifact staging, package or image transfer, or downstream deployment activity.

·        The activity may remain limited to suspicious repository or workflow interaction, or it may progress into credential exposure, registry access, package publication, image push, artifact replacement, deployment modification, cloud-control-plane activity, Kubernetes-control-plane activity, infrastructure-as-code execution, production workload impact, data exposure, ransomware staging, or extortion.

·        The activity becomes highest risk when suspicious repository or CI/CD behavior involves sensitive repositories, protected branches, privileged workflows, signing workflows, package-publishing workflows, image-publishing workflows, infrastructure-as-code repositories, production deployment workflows, privileged runners, shared runners, persistent runners, or automation identities with downstream access.

·        The report should remain focused on durable software-delivery compromise behavior and control-plane exposure rather than one exploit string, one CVE, one repository, one workflow file, one runner host, one package name, one image tag, one domain, one IP address, or one event ID.

S13 — Targets and Exposure Surface

The exposure surface includes self-hosted Git platforms, repositories, workflow files, CI/CD pipelines, runners, deploy keys, tokens, webhooks, OAuth applications, service accounts, workload identities, protected variables, package registries, container registries, artifact stores, deployment systems, cloud environments, Kubernetes clusters, and downstream systems that depend on trusted software delivery.

·        Self-hosted Git platforms, repository groups, projects, namespaces, protected branches, merge request paths, release branches, and workflow configuration files.

·        CI/CD pipelines, CI/CD job definitions, build scripts, release scripts, deployment scripts, infrastructure-as-code workflows, package-publishing workflows, image-publishing workflows, and signing workflows.

·        Self-hosted runners, shared runners, persistent runners, privileged runners, runner managers, runner tags, runner scopes, runner service accounts, runner workspaces, runner caches, and runner hosts with Docker socket access or internal network reach.

·        Deploy keys, project access tokens, group access tokens, personal access tokens, OAuth applications, webhooks, bot accounts, service accounts, workload identities, deployment identities, package credentials, registry credentials, cloud credentials, Kubernetes credentials, and signing material.

·        Protected variables, environment variables, secret stores, credential files, build logs, artifacts, caches, package outputs, container images, release assets, deployment manifests, and infrastructure templates.

·        Package registries, container registries, artifact stores, build-cache systems, release systems, image repositories, object-storage locations, package mirrors, and internal dependency sources.

·        Cloud accounts, cloud APIs, Kubernetes clusters, Kubernetes APIs, deployment controllers, infrastructure-as-code systems, production deployment platforms, secret-management systems, identity providers, and privileged administration paths tied to CI/CD automation.

·        Customer-facing applications, internal business applications, databases, file stores, SaaS integrations, developer platforms, source-code mirrors, build systems, and production environments that depend on trusted build and deployment pipelines.

·        Environments with incomplete Git audit logs, incomplete CI/CD job logs, weak runner telemetry, limited command-line visibility, incomplete registry or package logs, metadata-only network telemetry, short retention, weak repository inventory, unclear runner ownership, poor automation identity mapping, or missing change-control records.

·        Environments that permit broad runner access to internal services, secret stores, registries, package mirrors, artifact stores, Kubernetes APIs, cloud endpoints, deployment controllers, or production networks.

S14 — Sectors / Countries Affected

Sectors Affected

·        Technology and software development.

·        SaaS providers and cloud-native service providers.

·        Financial services.

·        Healthcare and life sciences.

·        Manufacturing and industrial operations.

·        Energy and utilities.

·        Retail and e-commerce.

·        Telecommunications and managed infrastructure providers.

·        Education and research institutions.

·        Government and public-sector organizations.

·        Legal, consulting, and professional services organizations with high-value software-delivery dependencies.

·        Organizations with self-hosted Git platforms, CI/CD infrastructure, sensitive repositories, package or container publication workflows, deployment automation, cloud or Kubernetes dependencies, regulated data environments, customer-facing software, or business-critical systems tied to automated release pipelines.

Countries Affected

·        Global.

·        Exposure is not limited to a single country or region because self-hosted Git platforms, CI/CD systems, package registries, container registries, cloud services, Kubernetes environments, and deployment automation are broadly deployed across enterprise environments.

·        Countries with large software-development ecosystems, regulated industries, cloud-native operations, critical infrastructure, technology services, SaaS providers, financial systems, or high-value business-service environments may face elevated operational exposure.

·        Country-specific impact should be assessed by self-hosted Git exposure, sensitive repository footprint, CI/CD architecture, runner segmentation, automation credential governance, package and image lineage, cloud and Kubernetes dependency, telemetry quality, change-management maturity, and incident-response readiness rather than geography alone.

S15 — Adversary Capability Profiling

Capability Level

Moderate to High

Technical Sophistication

Adversaries require enough technical capability to understand repository permissions, workflow execution, CI/CD job behavior, runner assignment, protected variables, deploy keys, access tokens, webhooks, OAuth applications, service accounts, workload identities, package registries, container registries, artifact handling, deployment automation, cloud APIs, Kubernetes APIs, and infrastructure-as-code workflows. The behavior can be attempted through compromised maintainer accounts, abused automation identities, malicious workflow changes, external contributor pathways, token misuse, runner misuse, or post-access software-delivery manipulation, but effective use requires operational judgment and awareness of how repository, CI/CD, runner, identity, registry, cloud, Kubernetes, and deployment activity is logged and correlated.

Infrastructure Maturity

Moderate

Infrastructure maturity varies by activity pattern. Lower-maturity activity may involve noisy workflow edits, obvious secret-printing commands, unfamiliar runner execution, raw-file retrieval, suspicious outbound transfer, or commodity tooling from unmanaged systems. Higher-maturity activity involves staging through plausible maintainer activity, using expected workflow names, abusing trusted runners, pacing token or webhook changes, blending with release engineering, using approved package or registry paths, delaying follow-on cloud or Kubernetes activity, or moving through automation identities into deployment systems and production-adjacent environments.

Operational Scale

Single-repository to enterprise-scale

Operational scale ranges from suspicious activity against one repository or runner to broader enterprise impact when attackers affect multiple repositories, shared runners, privileged workflows, protected variables, package registries, container registries, release artifacts, deployment automation, cloud accounts, Kubernetes clusters, or production environments.

Escalation Likelihood

High

Escalation likelihood is high when suspicious repository or CI/CD activity involves sensitive repositories, privileged maintainers, protected branches, privileged runners, shared runners, persistent runners, package-publishing workflows, image-publishing workflows, signing workflows, infrastructure-as-code repositories, production deployment workflows, deploy keys, broad-scope tokens, webhooks, OAuth applications, service accounts, workload identities, or automation credentials with downstream access. Escalation likelihood increases further when suspicious workflow activity is followed by credential access, protected-variable exposure, artifact staging, outbound runner communication, registry access, package publication, image push, release artifact modification, deployment action, cloud API use, Kubernetes API use, infrastructure changes, ransomware staging, data access, or extortion behavior.

S16 — Targeting Probability Assessment

Overall Targeting Probability

High

Targeting Drivers

·        Self-hosted Git platforms and CI/CD systems are high-value targets because they support source-code control, workflow execution, protected-variable access, build automation, package publication, image publication, artifact generation, and deployment activity.

·        Attackers benefit directly from compromising or creating uncertainty around software-delivery integrity because downstream systems may continue treating build outputs, packages, images, artifacts, deployments, and automation identities as legitimate.

·        Repository workflow files, CI/CD configuration, runner assignment, deploy keys, access tokens, webhooks, OAuth applications, protected variables, package credentials, registry credentials, cloud credentials, and Kubernetes credentials provide valuable opportunities when governance, segmentation, or telemetry are weak.

·        Sensitive repositories, privileged branches, release workflows, package-publishing workflows, image-publishing workflows, signing workflows, infrastructure-as-code repositories, production deployment workflows, privileged runners, shared runners, and persistent runners create high-value access opportunities.

·        Broad runner access to secret stores, identity providers, internal registries, package mirrors, artifact stores, Kubernetes APIs, cloud endpoints, deployment controllers, or production networks can increase attacker opportunity and make malicious CI/CD behavior harder to separate from normal release activity.

·        Incomplete Git audit logs, CI/CD logs, runner telemetry, endpoint telemetry, NDR telemetry, registry logs, package logs, artifact logs, identity logs, cloud logs, Kubernetes logs, deployment logs, or SIEM correlation increases attacker opportunity and response uncertainty.

·        Internal systems reachable through trusted software-delivery paths may include source-code systems, build systems, package registries, container registries, artifact stores, secret stores, cloud accounts, Kubernetes clusters, deployment platforms, databases, file stores, and sensitive business applications.

·        Cloud, Kubernetes, package, image, artifact, release, and production deployment dependencies increase the value of self-hosted Git and CI/CD compromise beyond the repository layer.

Most Likely Targets

·        Self-hosted Git platforms, repository groups, projects, protected branches, merge request paths, release branches, and workflow files.

·        Organizations with exposed, poorly segmented, or difficult-to-monitor self-hosted Git and CI/CD infrastructure.

·        Sensitive repositories supporting production deployment, package publication, image publication, signing, infrastructure-as-code, cloud deployment, Kubernetes deployment, or business-critical applications.

·        CI/CD runners, shared runners, persistent runners, privileged runners, runner managers, runner tags, runner scopes, runner workspaces, build hosts, and deployment automation systems.

·        Privileged maintainers, repository administrators, CI/CD administrators, DevOps engineers, release engineers, automation accounts, bot accounts, service accounts, workload identities, deployment identities, and low-frequency high-privilege accounts.

·        Deploy keys, project access tokens, group access tokens, personal access tokens, OAuth applications, webhooks, protected variables, package credentials, registry credentials, cloud credentials, Kubernetes credentials, signing keys, and service-account credentials.

·        Package registries, container registries, artifact stores, build caches, image repositories, release systems, package mirrors, object-storage locations, and internal dependency sources.

·        Cloud consoles, cloud APIs, Kubernetes APIs, deployment controllers, infrastructure-as-code systems, secret stores, identity providers, developer platforms, source-code mirrors, customer-facing applications, databases, file stores, and sensitive internal applications tied to CI/CD automation.

·        Environments with incomplete Git telemetry, weak runner inventory, incomplete asset-role enrichment, broad runner network access, unclear workflow ownership, weak automation identity mapping, missing change-management records, or limited incident-response readiness.

S17 — MITRE ATT&CK Chain Flow Mapping

Stage 1: Repository Workflow or CI/CD Configuration Modification

The adversary modifies repository workflow logic, CI/CD configuration, build scripts, release scripts, deployment scripts, or related automation paths to influence trusted execution. This mapping should be used when workflow or CI/CD configuration modification is observed or strongly supported.

·        T1565.001 — Data Manipulation: Stored Data Manipulation.

Stage 2: Trusted CI/CD Runner Execution

The adversary causes attacker-controlled or unauthorized logic to execute through a trusted CI/CD runner, build host, or deployment automation path. This mapping should be used when suspicious workflow execution, runner job execution, or automation-driven command execution is observed.

·        T1059 — Command and Scripting Interpreter.

Stage 3: Automation Credential or Protected Variable Access

The adversary attempts to access protected variables, environment variables, token material, deploy credentials, registry credentials, package credentials, cloud credentials, Kubernetes credentials, signing material, or service-account credentials exposed to the workflow or runner context. This mapping should be used only when credential or secret access behavior is observed or strongly supported.

·        T1552 — Unsecured Credentials.

Stage 4: External Transfer or Staging From Runner Context

The adversary stages, transfers, or attempts to move credentials, build logs, artifacts, caches, source bundles, package material, image-related content, or other sensitive workflow outputs from the runner or build environment. This mapping should be used when outbound transfer, staging behavior, or suspicious external communication is observed.

·        T1048 — Exfiltration Over Alternative Protocol.

Stage 5: Package, Image, Artifact, or Deployment Path Manipulation

The adversary uses the trusted software-delivery path to modify or publish packages, push container images, alter release artifacts, manipulate build outputs, or influence deployment behavior. This mapping should be used when package, image, artifact, release, or deployment manipulation is observed or strongly supported.

·        T1195.002 — Supply Chain Compromise: Compromise Software Supply Chain.

Stage 6: Downstream Cloud, Kubernetes, or Deployment Control-Plane Activity

The adversary uses CI/CD-linked credentials, service principals, workload identities, deployment identities, or runner-derived access to interact with cloud APIs, Kubernetes APIs, deployment systems, or infrastructure-as-code environments. This mapping should be used only when downstream control-plane activity can be tied to CI/CD identity, runner, repository, workflow, or pipeline lineage.

·        T1078 — Valid Accounts.

S18 — Attack Path Narrative (Signal-Aligned Execution Flow)

Self-hosted Git platform compromise through repository workflow abuse begins when an adversary gains a path to influence repository-control, workflow, or CI/CD automation behavior. The attacker’s objective is to use trusted software-delivery infrastructure to execute unauthorized logic, expose secrets, manipulate build or release outputs, abuse automation identities, or move from source-code control into registry, cloud, Kubernetes, deployment, or production-adjacent environments. The attack path is defined by repository-control activity, workflow or automation modification, trusted runner execution, credential or build-output exposure, registry or deployment interaction, and downstream control-plane activity tied to CI/CD lineage.

Stage 1: Repository-Control or Workflow Access

The adversary gains access to a repository, project, group, workflow path, merge request path, automation account, deploy key, access token, webhook, OAuth application, or CI/CD configuration surface. This access may come from a compromised maintainer account, abused automation identity, overly broad token, external contributor path, stale account, misconfigured integration, or exposed administrative pathway. Access to a repository or workflow path is not compromise by itself, but it becomes material when paired with unusual actor context, sensitive repository scope, protected branch activity, automation credential changes, or follow-on CI/CD execution.

Stage 2: Workflow or Automation Logic Modification

The adversary modifies workflow files, CI/CD configuration, build scripts, release scripts, package-publishing logic, container-build definitions, infrastructure-as-code workflows, deployment scripts, or related automation paths. This stage changes the incident from ordinary repository access into potential software-delivery control-plane abuse. The key signal is not any workflow edit by itself; it is workflow or automation modification that does not align with expected maintainer behavior, approved change records, branch protections, release windows, repository sensitivity, or known engineering activity.

Stage 3: Trusted CI/CD Runner Execution

The adversary triggers or waits for trusted CI/CD execution through self-hosted runners, shared runners, persistent runners, privileged runners, build hosts, release automation systems, or deployment automation systems. This stage allows attacker-controlled or unauthorized logic to run inside a trusted build context. Risk increases when execution occurs on sensitive runners, privileged runner tags, production deployment workflows, package-publishing workflows, image-publishing workflows, signing workflows, infrastructure-as-code workflows, or runners with internal network reach, Docker socket access, persistent workspaces, or access to protected variables.

Stage 4: Credential, Secret, Artifact, or Build-Output Exposure

After runner execution, the adversary may inspect protected variables, enumerate environment variables, access credential files, query secret stores, read build logs, stage artifacts, access caches, collect source bundles, retrieve registry tokens, inspect package credentials, access cloud credentials, or access Kubernetes credentials. This stage materially increases risk because trusted CI/CD systems often hold credentials and build outputs that connect repositories to downstream systems. The organization must determine whether protected variables, deploy credentials, registry credentials, package credentials, signing material, service-account credentials, cloud credentials, Kubernetes credentials, artifacts, caches, or build outputs remained intact.

Stage 5: Registry, Package, Image, Artifact, or Deployment Abuse

The adversary may use exposed credentials or trusted workflow context to access package registries, container registries, artifact stores, build caches, image repositories, release systems, object storage, or deployment platforms. This stage may include package publication, image push, image overwrite, release artifact modification, artifact download, cache exposure, build-output staging, registry authentication, or deployment manipulation. The incident expands beyond the repository layer when build outputs, packages, images, artifacts, or release paths can no longer be trusted without validation.

Stage 6: Downstream Cloud, Kubernetes, or Production-Adjacent Expansion

If the activity is not contained, the adversary may use CI/CD-linked credentials, service principals, workload identities, deployment identities, registry credentials, package credentials, or runner-derived access to interact with cloud APIs, Kubernetes APIs, deployment systems, infrastructure-as-code workflows, secret managers, production environments, or business-critical applications. This stage should be tied to repository, runner, workflow, identity, credential, timing, or pipeline lineage before being attributed to the Git platform compromise path. Business impact increases when suspicious CI/CD-linked activity affects production deployment, cloud resources, Kubernetes clusters, customer-facing applications, regulated data, or recovery-critical systems.

Stage 7: Software-Delivery Trust and Business Impact Expansion

When repository workflow integrity, runner trust, automation credential scope, package lineage, image integrity, artifact integrity, or deployment behavior cannot be validated quickly, the organization may need to treat the event as a broader software-delivery control-plane incident. Response can expand into repository review, workflow review, runner quarantine, token revocation, secret rotation, deploy-key removal, webhook removal, package and image validation, release artifact review, cloud and Kubernetes scoping, deployment rollback analysis, customer-impact assessment, legal review, executive reporting, and business restoration. Business impact increases because responders must prove both what the adversary did and whether trusted software-delivery systems remained reliable during the activity window.

S19 — Attack Chain Risk Amplification Summary

Self-hosted Git platform compromise through repository workflow abuse amplifies risk because it targets systems that downstream build, release, deployment, cloud, Kubernetes, and production environments already trust. The chain becomes materially more dangerous when suspicious repository-control activity is followed by workflow execution, credential exposure, runner abuse, outbound transfer, registry activity, package or image manipulation, artifact modification, deployment action, or cloud and Kubernetes control-plane use.

·        Repository-control access creates a high-value pathway because self-hosted Git platforms govern source code, workflow logic, CI/CD configuration, release branches, protected branches, and automation paths.

·        Workflow or CI/CD configuration modification increases risk when it affects sensitive repositories, protected branches, production deployment workflows, package-publishing workflows, image-publishing workflows, signing workflows, or infrastructure-as-code workflows.

·        Trusted runner execution increases concern because CI/CD runners may hold protected variables, secrets, credentials, build artifacts, caches, deployment access, internal network reach, Docker socket access, or cloud and Kubernetes tooling.

·        Deploy-key creation, token creation, webhook modification, OAuth application activity, service-account use, or workload-identity use turns the activity into an automation identity and software-delivery trust event.

·        Credential access, protected-variable exposure, secret-store interaction, environment-variable inspection, or credential-file access after suspicious workflow activity increases concern that the adversary may be moving from workflow abuse into downstream access.

·        Outbound runner communication to unusual infrastructure increases risk when it aligns with workflow modification, suspicious job execution, credential access, artifact staging, archive creation, or transfer tooling.

·        Registry, package, image, artifact, cache, or release-system activity expands the incident beyond source-code control because trusted build outputs may need validation before continued use.

·        Cloud API activity, Kubernetes API activity, infrastructure-as-code execution, or deployment action using CI/CD-linked credentials can turn repository workflow abuse into production-adjacent or enterprise-impact activity.

·        Incomplete Git audit logs, CI/CD logs, runner telemetry, command-line capture, registry logs, package logs, artifact logs, identity logs, cloud logs, Kubernetes logs, deployment logs, or change records can force broader validation because the organization cannot quickly prove software-delivery integrity.

·        Response burden increases because teams must validate both adversary activity and the trustworthiness of repositories, workflows, runners, credentials, packages, images, artifacts, deployments, cloud identities, Kubernetes identities, and production release paths.

S20 — Tactics, Techniques, and Procedures

Figure 3

Repository and Workflow Control

Adversaries may target repository permissions, workflow files, CI/CD configuration, merge request paths, protected branches, release branches, automation accounts, deploy keys, tokens, webhooks, OAuth applications, or service accounts to influence trusted software-delivery behavior. This behavior becomes risk-relevant when actor context, repository sensitivity, branch scope, timing, change history, or approval context does not match expected engineering activity.

Trusted Runner Execution

Adversaries may cause unauthorized logic to execute through self-hosted runners, shared runners, persistent runners, privileged runners, build hosts, release automation systems, or deployment automation systems. Relevant activity includes unusual job execution, unexpected runner selection, sensitive runner tag use, execution from recently modified workflows, or runner activity outside approved repository, branch, project, or workflow scope.

Credential and Secret Exposure

Adversaries may attempt to access protected variables, environment variables, secret files, deploy credentials, registry credentials, package credentials, signing material, cloud credentials, Kubernetes credentials, service-account credentials, or workload identity artifacts from the workflow or runner context. This behavior should be evaluated against workflow purpose, repository sensitivity, runner scope, secret access policy, command context, and follow-on use.

Artifact, Package, Image, and Registry Abuse

Adversaries may access, stage, publish, overwrite, or manipulate build artifacts, caches, packages, container images, release assets, package registries, container registries, artifact stores, image repositories, or object-storage locations. This behavior becomes high risk when it follows suspicious workflow activity, credential exposure, unusual runner execution, or automation identity changes.

Outbound Transfer and External Staging

Adversaries may use runner or build-host connectivity to retrieve payloads, stage data, move source bundles, transfer build logs, upload artifacts, expose caches, or communicate with unusual external infrastructure. This activity should not be inferred from external connectivity alone; it becomes material when destination novelty, transfer pattern, command context, repository sensitivity, and CI/CD timing align.

Downstream Control-Plane Abuse

Adversaries may use CI/CD-linked credentials, service principals, workload identities, deployment identities, registry tokens, package tokens, or runner-derived access to interact with cloud APIs, Kubernetes APIs, deployment systems, infrastructure-as-code workflows, secret managers, or production-adjacent environments. This behavior should be attributed to the repository workflow abuse path only when identity, runner, workflow, repository, credential, timing, or pipeline lineage supports the connection.

Persistence Through Software-Delivery Mechanisms

Adversaries may preserve access by creating or modifying deploy keys, access tokens, webhooks, OAuth applications, service accounts, workload identities, runner registrations, runner tags, protected-branch settings, approval rules, workflow schedules, recurring pipelines, package versions, container image tags, or release artifacts. This activity should be treated as conditional until tied to suspicious repository, CI/CD, identity, runner, registry, package, cloud, Kubernetes, or incident-response evidence.

S20A — Adversary Tradecraft Summary

Self-hosted Git platform compromise through repository workflow abuse targets software-delivery trust rather than source-code access alone. The adversary objective is to use trusted repository, workflow, CI/CD, runner, automation identity, registry, artifact, package, image, or deployment paths to execute unauthorized logic, expose secrets, manipulate build outputs, or move downstream into cloud, Kubernetes, production, or business-critical systems. The tradecraft is effective because it can emerge from legitimate-looking repository activity, blend with release engineering, inherit trusted runner permissions, and force responders to validate whether the software-delivery foundation remained trustworthy.

·        The core tradecraft pattern is suspicious repository-control or workflow activity followed by trusted CI/CD execution and potential downstream impact.

·        The behavior is not dependent on a single CVE, exploit string, repository name, workflow filename, runner host, package name, image tag, domain, IP address, event ID, or malware artifact.

·        Adversaries may use compromised maintainers, abused automation identities, malicious workflow changes, external contributor pathways, overly broad tokens, deploy keys, webhooks, OAuth applications, runner misuse, protected-variable access, registry access, or cloud and Kubernetes-linked automation.

·        The strongest operational risk occurs when suspicious workflow activity is followed by credential exposure, protected-variable access, outbound runner communication, artifact staging, package publication, image push, release artifact modification, deployment activity, cloud API use, Kubernetes API use, production workload impact, data access, ransomware staging, or extortion.

·        Detection requires visibility into both the repository and workflow activity that initiates the chain and the runner, credential, registry, package, artifact, cloud, Kubernetes, deployment, or production evidence that should follow or disprove compromise.

·        Response requires treating suspected repository workflow abuse as a software-delivery control-plane incident, not a routine source-code or CI/CD alert.

·        The behavior remains durable because the adversary objective is control over trusted software-delivery relationships, regardless of the specific platform, workflow syntax, runner host, token type, destination, timing, or tooling used.

S21 — Detection Strategy Overview

Detection Philosophy

Self-hosted Git platform compromise through repository workflow abuse should be detected as a software-delivery control-plane compromise, not as a single repository, endpoint, or vulnerability event. The detection model must correlate repository workflow changes, CI/CD runner behavior, automation credential activity, deploy-key changes, webhook modification, package or container registry access, and downstream cloud or deployment behavior.

The primary detection objective is to identify when an attacker uses trusted development infrastructure to execute unauthorized logic, expose secrets, alter build or release behavior, abuse automation identity, or pivot from source-code control into production-adjacent systems.

Detection should prioritize chained behavior over isolated events. A workflow file change, runner execution, deploy-key creation, token creation, or registry action may be benign when observed alone. Detection value increases when those events occur together, originate from unusual identity or network context, affect sensitive repositories, or are followed by secret access, outbound communication, artifact manipulation, registry access, or cloud-control-plane activity.

Primary Detection Anchors

·        Repository workflow file creation, modification, deletion, or permission changes affecting CI/CD execution paths.

·        Workflow changes made by newly privileged users, inactive users, compromised maintainer accounts, external contributors, unfamiliar bot accounts, or accounts operating from unusual source infrastructure.

·        New, modified, or unexpectedly reused CI/CD runners, especially self-hosted runners with privileged execution, persistent workspace access, shared project scope, Docker socket access, sensitive runner tags, or internal network reach.

·        Creation or modification of deploy keys, project access tokens, group access tokens, personal access tokens, OAuth applications, webhooks, service accounts, or automation identities.

·        CI/CD job execution that attempts to read environment variables, secret stores, build logs, artifacts, cache directories, package tokens, registry tokens, signing material, or cloud credentials.

·        CI/CD job execution that initiates outbound communication to unusual domains, raw-file hosts, object-storage endpoints, paste services, tunneling infrastructure, unfamiliar IP addresses, or newly observed destinations.

·        Unexpected package registry, container registry, release artifact, or build artifact access following repository workflow changes.

·        Downstream cloud, Kubernetes, deployment-platform, or infrastructure-as-code activity using credentials associated with CI/CD, Git automation, runners, service principals, workload identities, or deploy accounts.

Detection Prioritization Model

Detection should prioritize activity involving sensitive repositories, privileged workflows, production deployment paths, signing or release automation, private package publishing, container image publishing, infrastructure-as-code repositories, and repositories that store or trigger access to cloud, Kubernetes, identity, or deployment environments.

Highest-priority detections should require a correlation chain showing repository-control activity followed by workflow execution, credential exposure behavior, runner abuse, artifact or registry access, or downstream deployment activity.

High-priority detection conditions include:

·        Workflow modification followed by CI/CD execution from the modified workflow.

·        Workflow modification followed by outbound communication from a runner to an unusual destination.

·        New deploy key, token, webhook, runner, or automation identity followed by repository cloning, artifact access, registry access, or deployment activity.

·        CI/CD job activity that attempts to enumerate or expose secrets, environment variables, tokens, credential files, build caches, or protected artifacts.

·        Runner execution from unusual host, network, project, branch, merge request, user, or token context.

·        Sensitive registry or artifact access following suspicious repository or workflow activity.

·        Cloud, Kubernetes, or deployment-platform activity using CI/CD credentials after suspicious Git, workflow, or runner behavior.

Medium-priority detections should identify suspicious but incomplete chains requiring analyst review, enrichment, or additional telemetry.

Medium-priority detection conditions include:

·        Workflow-file changes by unfamiliar or newly privileged users without immediate suspicious execution.

·        Runner registration or runner tag modification outside expected administrative windows.

·        New project token, deploy key, webhook, OAuth application, service account, or automation identity created for a sensitive repository.

·        CI/CD jobs with unusual command patterns, dependency retrieval, encoded commands, shell download execution, environment inspection, or credential-location probing.

·        Unusual artifact, package, or container registry activity without confirmed exfiltration or deployment abuse.

Low-priority detections should remain hunting-only unless correlated with additional signals.

Low-priority detection conditions include:

·        Repository clone, pull, or branch activity from unusual locations without workflow, token, runner, registry, or downstream-control-plane anomalies.

·        Benign workflow maintenance performed by known maintainers during expected change windows.

·        Normal runner scaling, runner replacement, or CI/CD migration activity with approved change-control context.

Correlation Strategy (Strict Enforcement)

Detection logic must avoid treating a single Git, CI/CD, runner, or registry event as confirmed compromise. The required model is multi-signal correlation across repository control, workflow execution, runner behavior, credential exposure, artifact or registry access, and downstream deployment or cloud activity.

A high-confidence detection should include at least two signal categories. Confidence increases when three or more categories appear in sequence.

Required correlation categories include:

·        Repository-control signal, such as workflow-file modification, protected-branch bypass, suspicious merge request, privileged permission change, deploy-key creation, token creation, webhook creation, OAuth application creation, or runner registration.

·        Workflow-execution signal, such as CI/CD job execution from a recently modified workflow, unusual branch, unfamiliar actor, new runner, sensitive runner tag, unexpected pipeline source, or unexpected project scope.

·        Credential-access signal, such as environment-variable enumeration, secret-store access, credential-file inspection, token exposure in logs, build-cache access, artifact access, package-token access, or registry-token use.

·        Network-behavior signal, such as outbound runner communication to unusual infrastructure, raw-code hosting, file-sharing services, object storage, paste services, tunneling endpoints, or newly observed destinations.

·        Registry or artifact signal, such as private package access, container image pull or push, release artifact download, build artifact download, package publication, or registry authentication following suspicious workflow activity.

·        Downstream-control-plane signal, such as cloud API activity, Kubernetes API activity, deployment-platform activity, infrastructure-as-code execution, service-principal use, workload-identity use, or production deployment action tied to CI/CD credentials.

Correlation must preserve identity lineage. Analyst review should connect the initiating account, token, deploy key, webhook, runner, repository, workflow, pipeline, artifact, registry action, and downstream credential use wherever telemetry permits.

Correlation must also preserve timing. The highest-value chains are those where repository or workflow changes are followed by runner execution, secret access, outbound communication, registry access, deployment activity, or cloud activity within a plausible operational window.

Telemetry Prioritization

Telemetry collection should prioritize control-plane and execution-path visibility before attempting broad endpoint or network-only detection.

Priority telemetry sources include:

·        Self-hosted Git audit logs for repository changes, user activity, group or project permissions, protected-branch changes, deploy-key activity, token creation, webhook changes, OAuth application changes, runner registration, pipeline triggers, merge requests, and administrative actions.

·        CI/CD pipeline logs for job execution, runner selection, workflow source, branch or merge request context, job variables, artifact use, cache access, command execution, and pipeline-triggering identity.

·        Runner host telemetry for process execution, shell activity, container execution, Docker socket access, workspace access, credential-file access, environment-variable inspection, outbound connections, file writes, persistence attempts, and lateral movement indicators.

·        Network telemetry for outbound runner communication, unusual destinations, new domains, object-storage access, raw-file retrieval, tunneling services, DNS anomalies, and high-risk egress paths.

·        Package and container registry telemetry for private image access, unusual pull or push activity, artifact download, package publication, token use, and access from unfamiliar runner or user context.

·        Cloud and Kubernetes audit logs for service-principal use, workload identity use, access-key use, deployment actions, secret-manager access, infrastructure changes, container registry access, and actions performed by CI/CD-associated identities.

·        Identity telemetry for new privileges, group membership changes, multi-factor anomalies, unusual authentication source, impossible travel, stale-account use, bot-account misuse, and token lifecycle events.

Endpoint telemetry should focus first on runner hosts, Git platform hosts, registry hosts, build servers, release automation systems, and deployment automation nodes before expanding to broader enterprise endpoints.

Detection Design Constraints

Detection content must distinguish suspicious software-delivery behavior from routine development and release activity. Self-hosted Git and CI/CD environments are high-change systems, so detections must account for normal merge activity, workflow maintenance, runner scaling, release engineering work, package publication, container builds, and infrastructure deployment.

The detection model should not assume that every workflow edit is malicious. It should require supporting context such as unusual actor, sensitive repository, unexpected runner, suspicious command pattern, secret-access behavior, abnormal outbound communication, registry abuse, or downstream cloud action.

The detection model should not assume that every CI/CD job failure, runner error, or pipeline retry indicates compromise. Instability signals are useful only when they align with suspicious repository changes, workflow execution, credential access, or outbound communication.

The detection model should not attribute cloud activity to repository compromise unless cloud actions can be tied to CI/CD credentials, workload identities, service principals, deployment accounts, runner hosts, pipeline timing, or related repository events.

The detection model should avoid IOC-led logic as the primary approach. Domains, IP addresses, hashes, package names, image names, file paths, and repository names may support enrichment and retrospective scoping, but the durable detection model must remain behavior-led.

Baseline and Deployment Requirements

Organizations should baseline normal repository, workflow, runner, token, webhook, registry, and deployment behavior before enabling high-severity alerting.

Required baselines include:

·        Normal workflow-file change frequency by repository, maintainer, group, project, and release cycle.

·        Expected CI/CD runner inventory, runner tags, runner scope, runner privilege level, runner network access, and runner ownership.

·        Approved deploy keys, project tokens, group tokens, personal access tokens, service accounts, OAuth applications, webhooks, and automation identities.

·        Expected pipeline trigger sources, branch patterns, merge request patterns, bot-account usage, release windows, and package-publishing workflows.

·        Normal artifact access, package registry activity, container registry access, image push and pull behavior, and build-cache usage.

·        Expected outbound network destinations for runners, including package mirrors, container registries, cloud services, artifact repositories, and internal deployment systems.

·        Expected cloud, Kubernetes, and deployment actions performed by CI/CD credentials and automation identities.

Deployment should begin in hunt or medium-severity alert mode until local schema mapping, field validation, exception handling, and false-positive review are complete.

High-severity alerting should require confirmed correlation across repository-control activity, workflow execution, runner behavior, credential exposure, registry activity, or downstream deployment activity.

Variant Resilience Requirements

Detection must remain resilient across different self-hosted Git platforms, CI/CD implementations, runner types, registry models, and deployment architectures. The detection model should not depend on a single product-specific event name, repository path, workflow filename, CVE identifier, or malicious infrastructure indicator.

Variant-resilient detection should focus on recurring attacker objectives:

·        Gain or abuse repository control.

·        Modify workflow or automation logic.

·        Trigger trusted CI/CD execution.

·        Access secrets, tokens, credentials, artifacts, packages, images, or registries.

·        Use runners as execution, collection, staging, or egress points.

·        Abuse automation identity to reach cloud, Kubernetes, deployment, package, or container environments.

·        Preserve or expand access through tokens, deploy keys, webhooks, service accounts, OAuth applications, or privileged runners.

Detection should support platform-specific field mapping for GitLab, Gitea, Forgejo, self-hosted runners, internal Git mirrors, package registries, container registries, Kubernetes, AWS, Azure, and GCP without changing the underlying behavior model.

Operational Detection Model

The operational model should use tiered escalation based on the number, sequence, and sensitivity of correlated signals.

Initial hunting should identify repositories, runners, tokens, webhooks, OAuth applications, deploy keys, and automation identities with unusual behavior. Medium-confidence detections should alert when suspicious repository-control or workflow-execution events occur in sensitive repositories or privileged automation paths. High-confidence detections should alert when suspicious repository or workflow activity is followed by runner execution, credential exposure behavior, registry access, outbound communication, deployment activity, or cloud activity.

Operational triage should answer the following questions:

·        Which account, token, deploy key, webhook, runner, OAuth application, or automation identity initiated the suspicious activity?

·        Which repository, branch, workflow, merge request, pipeline, job, artifact, package, image, or deployment path was affected?

·        Was the workflow or runner behavior expected under an approved change or release process?

·        Did the job attempt to inspect, expose, print, stage, or transmit secrets, tokens, environment variables, credential files, artifacts, packages, images, or registry credentials?

·        Did the runner communicate with unusual external infrastructure?

·        Did the event result in package publication, container image push, release artifact modification, deployment activity, cloud API use, Kubernetes API use, or infrastructure changes?

·        Was any downstream credential used outside its expected repository, runner, branch, project, time window, geography, device, or network context?

The detection model should support both real-time alerting and retrospective threat hunting. Retrospective hunting is especially important when audit logs, CI/CD logs, runner telemetry, registry logs, and cloud logs are retained separately or when workflow abuse is discovered after credentials have already been exposed

S22 — Primary Detection Signals

Primary Detection Signals

Primary detection should focus on repository-control activity, workflow execution, CI/CD runner behavior, automation credential activity, registry access, and downstream deployment or cloud-control-plane actions. These signals provide the strongest foundation for identifying repository workflow abuse because they show whether trusted software-delivery infrastructure was changed, triggered, or used outside expected development and release patterns.

High-value primary signals include:

·        Repository workflow file creation, modification, deletion, or permission changes affecting CI/CD execution paths.

·        Workflow changes involving sensitive repositories, privileged branches, protected release paths, infrastructure-as-code repositories, package-publishing repositories, container-build repositories, or deployment automation repositories.

·        Workflow changes made by newly privileged users, inactive users, unfamiliar maintainers, compromised accounts, external contributors, unfamiliar bot accounts, or accounts authenticating from unusual source infrastructure.

·        CI/CD pipeline execution from a recently modified workflow, unfamiliar branch, unusual merge request, unexpected fork, newly created token, unfamiliar runner, or sensitive runner tag.

·        New, modified, or unexpectedly reused self-hosted runners, especially runners with privileged execution, persistent workspace access, shared project scope, Docker socket access, sensitive tags, internal network reach, or access to deployment credentials.

·        Creation or modification of deploy keys, project access tokens, group access tokens, personal access tokens, OAuth applications, webhooks, service accounts, workload identities, or automation identities tied to sensitive repositories.

·        CI/CD jobs that attempt to enumerate, print, stage, access, or transmit secrets, environment variables, credential files, secret-store values, package tokens, registry tokens, signing material, deployment credentials, cloud credentials, or Kubernetes credentials.

·        CI/CD jobs that initiate outbound communication to unusual domains, raw-file hosts, unfamiliar object-storage locations, paste services, tunneling infrastructure, newly observed destinations, unfamiliar IP addresses, or destinations inconsistent with approved build and release behavior.

·        Unexpected private package registry, container registry, release artifact, build artifact, or cache access following repository workflow changes.

·        Cloud, Kubernetes, deployment-platform, or infrastructure-as-code activity using credentials associated with CI/CD, Git automation, runners, deploy accounts, service principals, or workload identities after suspicious repository or workflow activity.

Supporting Detection Signals

Supporting signals should strengthen confidence, add context, and help distinguish malicious workflow abuse from authorized engineering activity. These signals should not usually alert independently unless the environment has exceptionally strict controls or the event affects a highly sensitive repository, workflow, runner, registry, or deployment path.

Supporting signals include:

·        Repository access from unfamiliar geographies, autonomous systems, devices, user agents, source IP ranges, VPN paths, or time windows.

·        Sudden increases in repository cloning, branch enumeration, commit access, merge request activity, artifact download, package access, or registry authentication by a single user, token, runner, or automation identity.

·        Protected-branch setting changes, approval-rule changes, required-review bypasses, branch protection weakening, or merge controls disabled before workflow execution.

·        New or modified webhook destinations, especially those pointing to unfamiliar external domains, object storage, automation endpoints, or unapproved integration services.

·        Creation or use of access tokens with unusually broad scope, long expiration, privileged project access, group-level reach, registry access, API access, or write permissions.

·        Use of stale, dormant, disabled-then-reenabled, newly invited, or recently privilege-elevated accounts in sensitive repository or CI/CD activity.

·        CI/CD jobs that use encoded commands, shell download execution, unusual dependency retrieval, suspicious command chaining, environment inspection, credential-location probing, or unexpected archive behavior.

·        Runner process activity involving shell interpreters, scripting engines, package managers, archive tools, cloud CLIs, Kubernetes CLIs, container tooling, credential helpers, or network utilities in unusual combinations.

·        Build logs, job logs, or runner logs showing secret masking failures, credential exposure attempts, suspicious variable expansion, or unexpected access to protected variables.

·        Unusual artifact retention, artifact download, cache restore, cache upload, image tag creation, image overwrite, package publication, release asset modification, or build output manipulation.

·        Identity events showing multi-factor anomalies, impossible travel, token lifecycle anomalies, bot-account misuse, or authentication from unfamiliar devices or networks before repository-control activity.

Exploit Attempt and Instability Signals

Exploit attempt and instability signals are useful when they appear near repository-control, workflow-execution, runner, credential, registry, or downstream-control-plane activity. These signals should not be treated as compromise evidence by themselves because self-hosted Git and CI/CD platforms can produce normal operational errors during upgrades, deployments, runner scaling, migration work, dependency failures, and release activity.

Relevant exploit attempt and instability signals include:

·        Repeated authentication failures followed by successful access to a self-hosted Git platform, runner manager, registry, package service, administrative console, or deployment system.

·        Failed attempts to create or modify deploy keys, tokens, webhooks, OAuth applications, runner registrations, project permissions, group permissions, protected branches, or workflow files followed by successful changes.

·        Pipeline failures involving permission errors, protected-variable access failures, secret-store access failures, artifact access failures, registry authentication failures, cloud API authorization failures, or deployment credential failures.

·        Runner errors involving unexpected privilege escalation attempts, Docker socket access failures, container breakout indicators, unauthorized file access, workspace permission changes, or blocked outbound communication.

·        Git platform errors involving unauthorized API requests, unusual administrative actions, suspicious project export attempts, failed repository archive access, failed registry access, or repeated webhook delivery failures.

·        Registry or package-service errors involving failed private image pulls, unauthorized image pushes, failed package publication, failed artifact access, or access from unfamiliar tokens, users, runners, or source networks.

·        Cloud or Kubernetes API errors involving denied secret access, denied role assumption, denied service-principal use, denied workload-identity use, denied deployment actions, or failed infrastructure changes following suspicious CI/CD activity.

Instability signals should be elevated only when they align with unusual actor context, recently modified workflow logic, sensitive repositories, newly created automation credentials, unfamiliar runner activity, or downstream credential use.

Outbound Communication Signals

Outbound communication from CI/CD runners, Git platform hosts, registry hosts, build servers, and deployment automation systems is a high-value signal when it deviates from approved build, package, registry, and deployment destinations. These systems often require legitimate external connectivity, so detection must focus on unusual destinations, unusual timing, unusual initiating jobs, unusual users, or suspicious command context.

High-value outbound communication signals include:

·        Runner or build-host communication to newly observed domains, unfamiliar IP addresses, raw-file hosting, paste services, object-storage endpoints, file-sharing services, tunneling services, temporary infrastructure, or domains inconsistent with approved build workflows.

·        Outbound communication immediately following workflow modification, new runner registration, deploy-key creation, token creation, webhook modification, or suspicious pipeline execution.

·        CI/CD job traffic to external destinations from sensitive repositories, protected branches, release workflows, package-publishing workflows, container-build workflows, or infrastructure-as-code pipelines.

·        Outbound transfer patterns consistent with artifact staging, compressed data transfer, source-code archive movement, credential-file transmission, build-log exfiltration, cache exfiltration, package-token exposure, or container-layer extraction.

·        DNS queries from runner hosts to newly registered domains, unusual subdomains, high-entropy domains, dynamic DNS, tunneling infrastructure, or domains not normally contacted by build and release systems.

·        Use of command-line download or upload utilities by CI/CD jobs, runner shells, build containers, or deployment jobs where those utilities are not expected for the repository or workflow.

·        Webhook delivery to unfamiliar destinations or destinations created shortly before suspicious workflow execution.

·        Cloud storage, external container registry, or package registry communication that is not part of approved dependency retrieval, image build, artifact storage, or deployment workflows.

Outbound communication should be correlated with repository, workflow, runner, identity, and credential activity before escalation to high-confidence compromise.

Persistence and Post-Exploitation Signals (Conditional)

Persistence and post-exploitation signals should be treated as conditional because not every repository workflow abuse event results in durable access. These signals become high value when they follow suspicious repository-control activity, workflow execution, credential exposure, registry access, or downstream deployment activity.

Relevant persistence and post-exploitation signals include:

·        New or modified deploy keys, project access tokens, group access tokens, personal access tokens, OAuth applications, service accounts, webhooks, workload identities, or automation credentials after suspicious workflow activity.

·        Runner registration, runner replacement, runner tag changes, runner scope expansion, or runner configuration changes after suspicious repository activity.

·        Protected-branch weakening, approval-rule changes, required-review bypasses, CODEOWNERS changes, merge-control changes, or release-policy changes after suspicious account or token activity.

·        Creation of hidden, misleading, similarly named, or low-visibility repositories, branches, tags, packages, images, release artifacts, or automation jobs.

·        Scheduled pipeline creation, recurring workflow changes, persistent webhook delivery, long-lived token creation, or automation identity changes that preserve access to repository or deployment paths.

·        Runner host persistence attempts, including new scheduled tasks, service creation, shell-profile modification, unauthorized SSH key placement, startup-script modification, container persistence, or suspicious credential-helper changes.

·        Cloud or Kubernetes persistence using CI/CD-linked credentials, including new access keys, role bindings, service accounts, workload identity bindings, secrets, deployment controllers, image-pull secrets, or infrastructure-as-code modifications.

·        Package, container, release, or artifact manipulation intended to preserve malicious code execution through future builds, deployments, updates, or dependency consumption.

These signals should be evaluated against change-control records, release schedules, administrative approvals, and known platform maintenance before being treated as confirmed malicious activity.

Lateral Movement and Expansion Signals (Conditional)

Lateral movement and expansion signals are conditional because repository workflow abuse may stop at credential exposure, artifact manipulation, or registry access. These signals become higher confidence when they appear after suspicious workflow changes, runner execution, credential access, or automation identity abuse.

Relevant lateral movement and expansion signals include:

·        Use of CI/CD credentials, deployment tokens, service principals, workload identities, cloud access keys, registry tokens, package tokens, or Kubernetes credentials from unfamiliar hosts, geographies, devices, runners, jobs, or source networks.

·        Cloud API activity, Kubernetes API activity, deployment-platform activity, infrastructure-as-code execution, or production deployment actions occurring after suspicious repository or CI/CD activity.

·        Access from runner hosts to internal services, source repositories, package mirrors, container registries, artifact stores, secret stores, identity providers, orchestration platforms, or deployment systems outside expected workflow scope.

·        Repository-to-repository expansion, including unusual cloning, mirroring, forking, branch access, project export, group enumeration, or cross-project token use.

·        Registry-to-environment expansion, including private image pulls, image pushes, image overwrites, image tag changes, package publication, release artifact replacement, or deployment of newly modified artifacts.

·        Use of automation identities to modify identity roles, access policies, security groups, cloud storage permissions, Kubernetes role bindings, deployment manifests, infrastructure templates, or environment variables.

·        Internal network scanning, service discovery, credential testing, lateral authentication attempts, or remote execution attempts originating from runner hosts, build servers, Git platform hosts, or deployment automation systems.

·        Downstream production, staging, or build-environment activity that aligns with the timing of suspicious workflow execution or credential exposure.

Expansion should not be attributed to Git platform compromise unless identity, timing, credential, runner, repository, or workflow lineage supports the connection.

Signal Usage Constraints

Signals in this section should be used as correlation inputs, not as standalone proof of compromise. Self-hosted Git platforms, CI/CD systems, runners, registries, and deployment automation environments are high-change systems with frequent legitimate administrative and engineering activity.

Signal interpretation should follow these constraints:

·        Do not treat workflow-file changes as malicious without actor, repository, timing, runner, command, credential, registry, outbound, or downstream-control-plane context.

·        Do not treat runner registration, runner replacement, or runner tag changes as malicious without sensitivity, timing, privilege, actor, or execution context.

·        Do not treat token, deploy-key, webhook, OAuth application, or service-account creation as compromise without scope, actor, sensitivity, timing, and follow-on activity.

·        Do not treat CI/CD job failure, runner instability, registry errors, or cloud authorization failures as compromise without supporting repository, workflow, identity, or execution signals.

·        Do not attribute cloud, Kubernetes, or deployment activity to repository compromise unless the activity can be linked to CI/CD credentials, automation identities, runner hosts, pipeline timing, or related repository events.

·        Do not use IOCs as the primary detection model. Domains, IPs, hashes, package names, image names, repository names, and file paths should support enrichment, scoping, and retrospective hunting.

·        Do not enable high-severity alerting until local baselines, field mappings, schema validation, known-good exceptions, false-positive review, and SOC triage procedures are complete.

·        Treat confirmed multi-signal chains involving repository-control activity, workflow execution, credential exposure, registry activity, outbound communication, or downstream deployment behavior as the strongest detection path.

S23 — Telemetry Requirements

Endpoint and Process Execution Telemetry

Endpoint and process execution telemetry should prioritize systems that participate directly in self-hosted Git operations, CI/CD execution, package or container publishing, artifact handling, and deployment automation. The highest-value endpoint coverage is on runner hosts, Git platform hosts, build servers, registry hosts, release automation systems, deployment nodes, and administrative workstations used by privileged Git or CI/CD operators.

Required endpoint and process telemetry includes:

·        Process creation events from CI/CD runners, build hosts, Git platform hosts, registry hosts, and deployment automation systems.

·        Parent-child process relationships showing shell execution, script execution, package-manager activity, container tooling, cloud CLI usage, Kubernetes CLI usage, archive creation, file-transfer utilities, and credential-helper execution.

·        Command-line telemetry for runner jobs, build scripts, deployment scripts, package-publishing workflows, container-build workflows, and infrastructure-as-code execution.

·        User, service account, token, runner, job, pipeline, repository, branch, and workflow context where available.

·        Process execution involving shell interpreters, scripting engines, package managers, archive tools, compression tools, download utilities, upload utilities, cloud CLIs, Kubernetes CLIs, container runtimes, registry clients, Git clients, and credential helpers.

·        Process activity that attempts to enumerate environment variables, inspect credential paths, access secret files, print masked variables, stage artifacts, compress repository content, or transmit data externally.

·        Execution from temporary directories, runner workspaces, build caches, job-specific directories, container-mounted workspaces, or unexpected service-account contexts.

·        Runner-host process activity associated with unusual repositories, unfamiliar workflows, newly created runners, unexpected runner tags, sensitive branches, protected workflows, or recently modified workflow files.

Endpoint telemetry must preserve process lineage. Detection and triage should be able to connect a job, runner, workflow, repository, initiating identity, process tree, file access pattern, and outbound connection whenever local logging permits.

Memory and Execution Telemetry

Memory and execution telemetry is useful when runner hosts, build systems, Git platform hosts, or deployment automation systems show signs of malicious script execution, credential harvesting, unauthorized tooling, or post-exploitation behavior. This telemetry is not required for every detection but materially improves confidence when workflow abuse produces host-level execution artifacts.

Relevant memory and execution telemetry includes:

·        EDR observations of suspicious shell behavior, encoded command execution, in-memory script execution, reflective loading, suspicious interpreter behavior, or abnormal child-process chains from runner jobs.

·        Runtime detections involving credential dumping, token harvesting, environment-variable scraping, unauthorized secret access, or credential-helper abuse.

·        Script execution telemetry from Bash, sh, PowerShell, Python, Ruby, Node.js, Perl, Go, Java, or other interpreters used by build and release jobs.

·        Container runtime telemetry showing privileged containers, host mounts, Docker socket use, namespace interaction, unexpected image execution, or container escape indicators.

·        Execution of cloud, Kubernetes, registry, package-manager, artifact, or deployment tooling from unusual runner, repository, branch, pipeline, or user context.

·        Suspicious memory-resident tooling, unauthorized agent execution, unexpected binary execution, or malicious payload behavior on runner hosts or build systems.

·        EDR detections that align with recently modified workflow files, suspicious CI/CD jobs, new runner registration, credential exposure, registry access, outbound communication, or downstream deployment behavior.

Memory and execution telemetry should support correlation, not replace control-plane evidence. Host-level detections are strongest when tied back to repository, workflow, runner, pipeline, identity, or token lineage.

Crash and Fault Telemetry

Crash and fault telemetry should be collected from self-hosted Git platforms, CI/CD runners, runner managers, registry services, package services, build hosts, deployment systems, and related cloud or Kubernetes integrations. These signals help identify failed exploitation, blocked credential access, unstable malicious workflow execution, misused automation identity, or unauthorized access attempts.

Required crash and fault telemetry includes:

·        Authentication failures followed by successful access to Git platforms, CI/CD systems, runner managers, registries, package services, deployment systems, cloud consoles, or Kubernetes APIs.

·        Authorization failures involving protected variables, secrets, deploy keys, tokens, webhook creation, OAuth applications, service accounts, project permissions, group permissions, runner registration, registry access, or package publication.

·        Pipeline failures involving secret-store access, protected-variable access, credential-file access, artifact retrieval, cache access, registry authentication, cloud API calls, Kubernetes API calls, or deployment actions.

·        Runner errors involving Docker socket access, privileged container execution, unauthorized file access, workspace permission changes, blocked outbound communication, unexpected interpreter execution, or denied access to mounted paths.

·        Git platform faults involving failed project export, failed repository archive access, failed protected-branch modification, failed approval-rule changes, failed deploy-key creation, failed token creation, failed webhook delivery, or unusual administrative errors.

·        Registry or package-service faults involving failed private image pulls, unauthorized image pushes, failed package publication, failed artifact download, failed token use, or access attempts from unfamiliar runners, users, jobs, or networks.

·        Cloud or Kubernetes errors involving denied role assumption, denied service-principal use, denied workload-identity use, denied secret access, denied deployment action, denied infrastructure modification, or failed use of CI/CD-linked credentials.

Crash and fault telemetry should be interpreted conservatively. These events should increase detection confidence only when they align with suspicious repository, workflow, runner, credential, registry, outbound, or downstream-control-plane activity.

File and Persistence Telemetry

File and persistence telemetry should focus on runner workspaces, Git platform directories, CI/CD configuration paths, build caches, artifact directories, package-publishing directories, registry paths, deployment workspaces, credential locations, and service configuration locations. This telemetry helps identify malicious workflow edits, credential staging, artifact manipulation, runner persistence, and post-exploitation access preservation.

Required file and persistence telemetry includes:

·        Creation, modification, or deletion of workflow files, CI/CD configuration files, build scripts, release scripts, deployment scripts, package-publishing scripts, container-build definitions, infrastructure-as-code files, and automation configuration files.

·        File access to environment files, secret files, credential stores, SSH keys, deploy keys, cloud credential files, Kubernetes configuration files, registry credential files, package-manager credential files, signing keys, and runner configuration files.

·        Creation or modification of archives, compressed files, staged source-code bundles, build-log bundles, artifact bundles, cache archives, registry-layer exports, or credential collections from runner workspaces or build systems.

·        Unexpected writes to release artifacts, package outputs, container image build contexts, deployment manifests, infrastructure templates, version tags, or build outputs following suspicious workflow activity.

·        Runner persistence indicators, including new scheduled tasks, new services, shell-profile changes, unauthorized SSH keys, startup scripts, credential-helper changes, modified runner configuration, or unauthorized runner registration files.

·        Git platform persistence indicators, including unauthorized deploy keys, long-lived tokens, webhooks, OAuth applications, service accounts, branch-protection changes, approval-rule changes, CODEOWNERS changes, or project/group permission changes.

·        Package, registry, or artifact persistence indicators, including image overwrites, malicious tags, unexpected package versions, altered release assets, unusual artifact retention, hidden packages, or low-visibility publishing behavior.

·        Cloud or Kubernetes persistence artifacts tied to CI/CD credentials, including access keys, role bindings, service accounts, workload identity bindings, secrets, deployment controllers, image-pull secrets, or infrastructure-as-code changes.

File telemetry should preserve path, user, process, runner, repository, pipeline, job, and timestamp context. The detection value depends on linking file activity back to repository-control or workflow-execution events.

Network and Outbound Communication Telemetry

Network and outbound communication telemetry is required for identifying exfiltration, payload retrieval, external staging, unauthorized webhook delivery, suspicious package retrieval, unusual registry use, and downstream control-plane abuse. This telemetry is especially important because CI/CD jobs and runners often have legitimate external connectivity.

Required network and outbound communication telemetry includes:

·        DNS, HTTP, TLS, proxy, firewall, NDR, and cloud egress logs for runner hosts, build systems, Git platform hosts, registry hosts, package services, deployment automation systems, and release systems.

·        Destination domain, destination IP, autonomous system, URL path, user agent, TLS metadata, request method, byte count, timing, source host, source process, and repository or job context where available.

·        Runner or build-host communication to newly observed domains, unfamiliar IPs, raw-file hosts, paste services, object-storage endpoints, file-sharing services, tunneling services, dynamic DNS, newly registered domains, or temporary infrastructure.

·        Outbound communication immediately following workflow modification, new runner registration, token creation, deploy-key creation, webhook modification, suspicious pipeline execution, credential access, or artifact staging.

·        Upload, download, archive-transfer, cache-transfer, artifact-transfer, image-transfer, package-transfer, or build-log-transfer patterns inconsistent with approved workflows.

·        Webhook delivery to unfamiliar destinations, newly created destinations, unauthorized automation endpoints, external object storage, or integrations not approved for the repository or group.

·        Cloud storage, package registry, container registry, or artifact repository communication outside approved dependency retrieval, image build, artifact storage, package publication, or deployment workflows.

·        East-west network activity from runner hosts or build systems to internal services, secret stores, identity providers, source repositories, package mirrors, container registries, deployment systems, orchestration platforms, or administrative endpoints outside expected workflow scope.

Network telemetry should be correlated with identity, repository, workflow, runner, process, registry, and cloud activity before being treated as high-confidence compromise.

Web and Application Telemetry (Conditional Availability)

Web and application telemetry is conditionally required when the self-hosted Git platform, CI/CD platform, registry, package service, or deployment system exposes application-level logs. These logs often provide the clearest view of actor behavior, repository changes, permission changes, workflow edits, token creation, webhook changes, and administrative activity.

Relevant web and application telemetry includes:

·        Git platform audit logs for user authentication, repository access, project access, group access, permission changes, protected-branch changes, approval-rule changes, workflow-file changes, deploy-key changes, token creation, webhook creation, OAuth application changes, runner registration, merge request activity, project export, repository archive access, and administrative actions.

·        CI/CD application logs for pipeline creation, pipeline trigger source, job execution, workflow source, runner assignment, variable access, protected variable use, artifact access, cache access, environment deployment, and job-token behavior.

·        Runner manager logs for runner registration, runner deregistration, runner tag changes, runner scope changes, runner authentication, runner assignment, runner failures, and runner configuration changes.

·        Registry and package-service logs for package publication, package download, image pull, image push, image overwrite, tag creation, tag modification, artifact download, token use, authentication failures, and unauthorized access attempts.

·        Webhook logs for destination creation, destination modification, delivery attempts, delivery failures, payload type, triggering repository event, response status, destination ownership, and timing.

·        Administrative console logs for settings changes, user invitations, group membership changes, project transfers, repository visibility changes, package or registry configuration changes, integration changes, and platform security setting changes.

·        Deployment application logs for environment creation, deployment approval, deployment trigger, rollback, infrastructure execution, cloud credential use, Kubernetes deployment activity, and production release changes.

Web and application telemetry should be retained long enough to support retrospective investigation because workflow abuse may be discovered only after tokens, packages, images, artifacts, or deployment paths have already been affected.

Telemetry Availability Requirements

Minimum viable detection requires telemetry from the self-hosted Git platform, CI/CD pipeline system, runner layer, identity provider, and at least one downstream environment such as registry, package service, cloud, Kubernetes, or deployment platform.

Required availability conditions include:

·        Git audit logs must identify actor, action, repository, project or group, source IP, timestamp, authentication context, and affected object where available.

·        CI/CD logs must identify workflow, pipeline, job, runner, branch, merge request, trigger source, initiating actor, command context, artifact use, cache use, and protected-variable behavior where available.

·        Runner telemetry must identify process execution, command line, parent process, user or service account, working directory, network connection, file access, container execution, and job context where available.

·        Identity logs must identify authentication source, user, device, MFA context, token lifecycle, privilege changes, group membership changes, service-account activity, and bot-account behavior.

·        Registry and package logs must identify image, package, tag, artifact, action, actor, token, source IP, runner, repository, timestamp, and result where available.

·        Cloud and Kubernetes logs must identify API action, identity, role, credential source, source IP, service principal, workload identity, resource, region, namespace, deployment target, and result where available.

·        Network logs must identify source host, destination domain, destination IP, protocol, byte count, timing, user agent, proxy action, and process or workload context where available.

Telemetry must support time-based correlation across systems. Where timestamps, time zones, clock synchronization, or log ingestion delays are inconsistent, detection confidence should be reduced until timing can be normalized.

Telemetry Limitations and Gaps

Telemetry gaps can materially reduce confidence because repository workflow abuse often crosses Git, CI/CD, runner, registry, identity, cloud, and deployment boundaries. Missing telemetry may prevent analysts from proving whether suspicious workflow activity resulted in credential exposure, artifact manipulation, package or image abuse, or downstream environment access.

Common telemetry limitations include:

·        Git audit logs that do not retain enough detail about workflow-file changes, deploy-key creation, token creation, webhook changes, runner registration, protected-branch changes, or administrative activity.

·        CI/CD logs that omit command-line detail, protected-variable behavior, job-token context, runner assignment, artifact access, cache use, or pipeline-triggering identity.

·        Runner hosts without EDR, process telemetry, command-line capture, network telemetry, file telemetry, or container runtime visibility.

·        Shared or persistent runners that make it difficult to separate benign build activity from suspicious execution or cross-project exposure.

·        Registry or package logs that do not preserve token identity, source IP, runner context, package version, image tag, artifact lineage, or repository association.

·        Network logs that capture only destination IPs without process, user, repository, runner, job, domain, or URL context.

·        Cloud or Kubernetes logs that do not clearly link API activity to CI/CD credentials, workload identities, service principals, pipeline timing, or runner hosts.

·        Identity logs that do not capture token lifecycle events, service-account activity, bot-account usage, MFA context, device context, or privilege changes.

·        Short retention windows that prevent retrospective analysis after delayed discovery of workflow abuse, credential exposure, package manipulation, or deployment compromise.

·        Inconsistent naming conventions across repositories, runners, tokens, service accounts, registries, images, packages, cloud identities, and deployment environments.

When telemetry gaps exist, detections should remain hunting-oriented or medium-confidence until sufficient lineage can be established. High-confidence alerting should require validated identity, repository, workflow, runner, credential, registry, network, or downstream-control-plane correlation.

Figure 4

S24 — Detection Opportunities and Gaps

Detection Opportunities

Self-hosted Git platform compromise through repository workflow abuse creates strong detection opportunities because the attack path crosses multiple observable control points. The highest-value detection opportunities occur where repository-control activity, workflow execution, runner behavior, credential access, registry activity, outbound communication, and downstream deployment or cloud activity can be correlated into a single chain.

Primary detection opportunities include:

·        Repository workflow changes followed by CI/CD pipeline execution from the modified workflow.

·        Workflow changes in sensitive repositories, privileged branches, release workflows, package-publishing workflows, container-build workflows, infrastructure-as-code repositories, or deployment automation repositories.

·        Suspicious workflow changes made by newly privileged users, inactive users, unfamiliar maintainers, external contributors, unfamiliar bot accounts, or accounts authenticating from unusual source infrastructure.

·        New or modified deploy keys, project access tokens, group access tokens, personal access tokens, OAuth applications, webhooks, service accounts, workload identities, or automation identities tied to sensitive repositories.

·        New runner registration, runner tag changes, runner scope expansion, runner reuse, or runner assignment changes involving sensitive repositories or privileged workflows.

·        CI/CD job execution that attempts to inspect, print, stage, compress, access, or transmit secrets, environment variables, credential files, protected variables, package tokens, registry tokens, signing material, cloud credentials, or Kubernetes credentials.

·        CI/CD job execution that uses suspicious command patterns, encoded commands, shell download execution, unexpected archive behavior, credential-location probing, or unusual dependency retrieval.

·        Runner or build-host communication to newly observed domains, raw-file hosts, unfamiliar object-storage endpoints, paste services, tunneling infrastructure, dynamic DNS, temporary infrastructure, or destinations inconsistent with approved build workflows.

·        Unexpected private package registry, container registry, release artifact, build artifact, cache, package, or image activity following repository workflow changes.

·        Downstream cloud, Kubernetes, deployment-platform, or infrastructure-as-code activity using credentials associated with CI/CD, Git automation, runners, service principals, workload identities, deploy accounts, or automation identities after suspicious repository or workflow activity.

High-Value Correlation Opportunities

High-value correlation should focus on multi-signal chains rather than isolated administrative or engineering events. The best detection opportunities are those that show an attacker moving from repository control into trusted automation execution and then into credential, artifact, registry, deployment, or cloud abuse.

High-value correlation chains include:

·        Workflow modification followed by CI/CD execution, credential inspection, and outbound communication from the runner.

·        Workflow modification followed by private artifact, cache, package, image, or registry access from the modified job.

·        New deploy key, token, webhook, OAuth application, service account, or automation identity followed by repository cloning, pipeline execution, registry access, or deployment activity.

·        New runner registration or runner tag modification followed by execution of a sensitive workflow, access to protected variables, or outbound communication to unusual infrastructure.

·        Protected-branch weakening, approval-rule changes, CODEOWNERS changes, or required-review bypass followed by workflow execution or release activity.

·        CI/CD job execution involving credential-location probing followed by cloud API activity, Kubernetes API activity, package publication, container image push, release artifact modification, or deployment action.

·        Runner-host process execution involving cloud CLIs, Kubernetes CLIs, registry clients, package managers, archive utilities, or network utilities followed by external transfer or downstream control-plane activity.

·        Webhook creation or modification followed by delivery to unfamiliar infrastructure and subsequent repository, registry, artifact, or deployment activity.

·        Package or container registry authentication from unfamiliar runners, tokens, source networks, or automation identities following suspicious repository-control activity.

·        CI/CD-linked service-principal, workload-identity, or deployment-account activity occurring outside expected repository, branch, pipeline, runner, time window, geography, or network context.

Detection Engineering Opportunities

Detection engineering should convert durable behavior into platform-specific logic while preserving correlation discipline. The strongest engineering opportunities are those that can be expressed across multiple systems without depending on a single product, CVE, IOC, repository name, workflow filename, or infrastructure indicator.

Detection engineering opportunities include:

·        Correlating workflow-file changes with CI/CD execution from the same repository, branch, actor, workflow, or pipeline.

·        Correlating token, deploy-key, webhook, OAuth application, or service-account creation with sensitive repository access, runner execution, registry activity, or downstream deployment actions.

·        Correlating runner registration, runner tag changes, runner scope changes, or runner assignment anomalies with sensitive pipeline execution.

·        Detecting CI/CD job commands associated with credential enumeration, environment-variable inspection, protected-variable exposure, archive creation, external transfer, cloud credential access, Kubernetes credential access, or registry credential use.

·        Detecting outbound runner communication to unusual destinations when preceded by workflow modification, sensitive pipeline execution, token creation, or credential-access behavior.

·        Detecting suspicious package, image, artifact, cache, or release activity following workflow modification or automation credential changes.

·        Detecting cloud, Kubernetes, deployment-platform, or infrastructure-as-code actions using CI/CD-linked credentials after suspicious Git, workflow, runner, registry, or credential behavior.

·        Detecting protected-branch weakening, approval-rule changes, CODEOWNERS changes, required-review bypasses, or release-control changes preceding workflow execution.

·        Detecting stale, dormant, newly privileged, newly invited, or unfamiliar accounts performing sensitive repository, workflow, runner, token, webhook, or registry activity.

·        Detecting suspicious cross-project or cross-repository expansion using tokens, runners, automation identities, repository exports, package access, registry access, or artifact downloads.

SOC Triage Opportunities

SOC triage should focus on proving or disproving lineage across identity, repository, workflow, runner, credential, registry, network, and downstream-control-plane activity. This approach helps analysts avoid overreacting to normal development behavior while still escalating credible software-delivery compromise chains.

High-value triage questions include:

·        Which account, token, deploy key, webhook, OAuth application, runner, service account, workload identity, or automation identity initiated the activity?

·        Which repository, group, project, branch, workflow, merge request, pipeline, job, artifact, cache, package, image, registry, or deployment path was affected?

·        Was the workflow, token, webhook, runner, branch, or deployment change expected under an approved change, release, migration, or administrative process?

·        Did the CI/CD job attempt to inspect, print, stage, compress, access, or transmit secrets, environment variables, credential files, protected variables, tokens, artifacts, packages, images, or registry credentials?

·        Did the runner or build host communicate with newly observed, unfamiliar, unauthorized, or suspicious external infrastructure?

·        Did the activity result in package publication, image push, image overwrite, release artifact modification, artifact download, deployment activity, cloud API use, Kubernetes API use, or infrastructure changes?

·        Was any downstream credential used outside its expected repository, runner, branch, project, time window, geography, device, host, or network context?

·        Is the same actor, token, runner, webhook, package, image, artifact, or automation identity visible across multiple repositories, groups, projects, registries, environments, or cloud accounts?

·        Is there evidence of persistence through deploy keys, tokens, webhooks, OAuth applications, runner configuration, service accounts, workload identities, protected-branch changes, approval-rule changes, or package and image manipulation?

Detection Gaps

Detection gaps are most likely where Git, CI/CD, runner, registry, package, identity, cloud, Kubernetes, and deployment telemetry are collected separately or retained for different periods. The attack path can move quickly from workflow modification to credential exposure or downstream deployment activity, so missing lineage can significantly reduce confidence.

Common detection gaps include:

·        Limited Git audit logs that do not preserve workflow-file changes, token creation, deploy-key changes, webhook changes, OAuth application changes, runner registration, protected-branch changes, approval-rule changes, or administrative actions.

·        CI/CD logs that omit command-line detail, protected-variable behavior, artifact access, cache use, job-token context, runner assignment, or pipeline-triggering identity.

·        Runner hosts without EDR, process telemetry, command-line capture, file telemetry, container runtime telemetry, Docker socket visibility, or outbound network visibility.

·        Shared or persistent runners that create noisy execution histories and make it difficult to distinguish normal build behavior from malicious workflow execution.

·        Registry and package logs that omit token identity, runner context, source IP, package version, image tag, artifact lineage, repository association, or authentication details.

·        Network logs that do not link outbound communication to process, runner, repository, job, workflow, user, token, domain, URL path, or pipeline context.

·        Cloud and Kubernetes logs that do not clearly connect API activity to CI/CD credentials, service principals, workload identities, deployment accounts, runner hosts, repository events, or pipeline timing.

·        Identity logs that do not capture token lifecycle events, service-account usage, bot-account activity, MFA context, device context, privilege changes, source network, or authentication anomalies.

·        Short retention windows that prevent retrospective investigation after delayed discovery of workflow abuse, credential exposure, package manipulation, image manipulation, artifact access, or deployment compromise.

·        Weak naming conventions across repositories, workflows, runners, tokens, service accounts, package registries, container registries, cloud identities, Kubernetes namespaces, and deployment environments.

·        Incomplete change-control records that make it difficult to distinguish authorized release engineering, runner migration, CI/CD refactoring, registry maintenance, or deployment work from suspicious activity.

Operational Gaps

Operational gaps can prevent technically available signals from becoming effective detections. These gaps often appear when security teams lack ownership clarity across development, platform engineering, DevOps, cloud, identity, SOC, and application teams.

Common operational gaps include:

·        No authoritative inventory of self-hosted Git platforms, repositories, groups, projects, runners, runner tags, deploy keys, tokens, webhooks, OAuth applications, package registries, container registries, and automation identities.

·        No clear mapping between sensitive repositories and downstream environments, including package publication, image publication, deployment automation, cloud accounts, Kubernetes clusters, and production systems.

·        No approved baseline for workflow-file changes, runner registration, runner tag changes, token creation, webhook changes, package publication, image pushes, artifact access, or deployment actions.

·        Limited SOC access to Git audit logs, CI/CD logs, runner telemetry, registry logs, package-service logs, cloud logs, Kubernetes logs, and identity logs.

·        Limited ability to rapidly revoke tokens, rotate CI/CD secrets, disable deploy keys, remove webhooks, quarantine runners, invalidate package or registry credentials, and suspend suspicious automation identities.

·        Limited ability to trace a suspicious workflow from repository change to pipeline execution, runner host activity, artifact access, registry activity, credential use, cloud action, or deployment action.

·        Limited runbooks for repository workflow abuse, runner compromise, automation credential exposure, registry abuse, package manipulation, image manipulation, and deployment compromise.

·        Limited collaboration between SOC, DevOps, platform engineering, application owners, cloud teams, and identity teams during suspected software-delivery compromise.

·        Limited ability to verify whether build outputs, packages, container images, release artifacts, infrastructure templates, or deployment manifests were modified or consumed downstream.

Residual Detection Risk

Residual detection risk remains even with strong telemetry because self-hosted Git and CI/CD environments generate frequent legitimate changes, complex automation, and high volumes of build activity. Attackers can blend into normal release engineering activity by using valid accounts, approved runners, expected workflow files, trusted package registries, and legitimate cloud or deployment credentials.

Residual risk is highest when:

·        The attacker uses valid maintainer credentials or automation tokens.

·        Workflow changes are small, temporary, or hidden inside normal release activity.

·        The malicious job runs once and is deleted or reverted quickly.

·        The runner is shared, persistent, privileged, or poorly instrumented.

·        Protected variables, credentials, artifacts, caches, packages, images, or logs are accessible to broad workflow contexts.

·        Registry, package, artifact, and cloud activity is not linked back to repository and pipeline lineage.

·        Detection depends on IOC matching rather than behavior correlation.

·        Retention is too short to support delayed investigation.

·        Cloud, Kubernetes, or deployment activity cannot be tied back to CI/CD identity or runner context.

·        Change-control processes do not clearly distinguish authorized engineering activity from suspicious workflow modification.

Residual risk should be reduced through stronger lineage, tighter runner segmentation, stricter workflow governance, protected-variable controls, token minimization, registry monitoring, cloud identity mapping, and integrated SOC-DevOps response processes.

Priority Gap Closure Actions

Priority gap closure should focus on improving visibility, lineage, control ownership, and response speed before enabling broad high-severity alerting. The goal is to make repository workflow abuse observable across the full chain from Git control-plane activity to downstream deployment or cloud impact.

Priority gap closure actions include:

·        Establish an authoritative inventory of self-hosted Git platforms, repositories, groups, projects, runners, runner tags, deploy keys, tokens, webhooks, OAuth applications, service accounts, workload identities, package registries, container registries, and deployment automation paths.

·        Classify sensitive repositories based on production deployment access, package-publishing authority, image-publishing authority, infrastructure-as-code control, signing authority, secret access, cloud access, Kubernetes access, and business-critical application ownership.

·        Enable and retain Git audit logs, CI/CD pipeline logs, runner telemetry, registry logs, package-service logs, identity logs, cloud logs, Kubernetes logs, deployment logs, and network egress logs long enough for retrospective investigation.

·        Map repository, workflow, runner, token, webhook, package, image, artifact, cloud, Kubernetes, and deployment identities into a common lineage model.

·        Baseline normal workflow changes, runner usage, token creation, webhook creation, package publication, image pushes, artifact access, outbound destinations, and deployment behavior.

·        Restrict protected variables, deployment credentials, signing material, registry credentials, cloud credentials, and Kubernetes credentials to approved repositories, branches, workflows, environments, and runner scopes.

·        Segment runners by sensitivity, repository class, environment, network access, and credential exposure.

·        Prefer ephemeral runners for sensitive workflows where operationally feasible.

·        Monitor for unusual runner registration, runner reuse, runner tag changes, runner scope expansion, privileged container use, Docker socket access, and sensitive workflow execution.

·        Build response procedures for token revocation, secret rotation, deploy-key removal, webhook removal, runner quarantine, artifact validation, package or image rollback, release review, and downstream cloud or Kubernetes containment.

·        Validate detection logic in hunt mode before promotion to alert mode.

·        Require multi-signal correlation before high-severity alerting.

S25 Ultra-Tuned Detection Engineering Rules

NDR / Network Behavioral Analytics

Detection Viability Assessment

NDR / Network Behavioral Analytics has three rules for this EXP report.

·        NDR / Network Behavioral Analytics is viable for detecting suspicious network behavior associated with self-hosted Git platform compromise, repository workflow abuse, CI/CD runner misuse, build-host egress, registry or artifact transfer anomalies, internal service access, and downstream deployment or cloud-adjacent expansion.

·        NDR / Network Behavioral Analytics is strongest where network-flow telemetry, DNS telemetry, proxy telemetry, firewall logs, secure web gateway logs, CI/CD runner inventory, build-host inventory, Git platform inventory, package registry inventory, container registry inventory, artifact-store inventory, deployment-system inventory, identity context, repository sensitivity context, and SIEM correlation can be combined.

·        NDR / Network Behavioral Analytics can identify suspicious sequencing between CI/CD runner execution, abnormal outbound communication, artifact or cache movement, package or image transfer, internal service access, secret-store access, registry access, and downstream environment interaction where correlated telemetry exists.

·        NDR / Network Behavioral Analytics is not a standalone source for confirming repository workflow modification, Git platform compromise, credential theft, token theft, malicious package publication, container image compromise, cloud compromise, Kubernetes compromise, or actor attribution because network telemetry may not fully observe workflow content, Git audit state, CI/CD variable access, token scope, registry object identity, or endpoint process execution.

·        NDR / Network Behavioral Analytics rules must be correlated with Git audit logs, CI/CD pipeline logs, runner telemetry, endpoint telemetry, identity logs, registry logs, package-service logs, cloud logs, Kubernetes logs, deployment logs, asset inventory, repository sensitivity context, change-control records, and incident-response evidence before classifying activity as probable compromise.

·        NDR / Network Behavioral Analytics detection content should be treated as high-value behavioral coverage for suspicious runner activity, artifact movement, unusual registry access, internal service access, credential-exposure investigation, and downstream expansion scoping, not direct proof of repository workflow compromise.

·        NDR / Network Behavioral Analytics rules should not generate high-confidence alerting from unfamiliar outbound communication alone, high-volume transfer alone, runner traffic alone, registry access alone, package access alone, source-code access alone, internal DNS activity alone, or cloud access alone without supporting repository, CI/CD, runner, identity, endpoint, registry, or incident-response context.

Rule

CI/CD Runner or Build Host Outbound Transfer to Unusual External Infrastructure

Rule Format

NDR behavioral runner-egress correlation rule suitable for network-flow telemetry, DNS telemetry, proxy telemetry, firewall logs, secure web gateway logs, runner inventory, build-host inventory, Git platform inventory, destination enrichment, repository sensitivity enrichment, CI/CD job timing enrichment, identity enrichment, change-control records, and SIEM correlation after source-role validation, destination-baseline validation, transfer-pattern validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious outbound communication from CI/CD runners, build hosts, Git platform hosts, registry hosts, package services, or deployment automation systems to unusual external infrastructure after suspected workflow execution or build activity.

·        Identify network-visible behavior that may indicate credential exposure, artifact staging, source-code archive movement, build-log exfiltration, cache exposure, or attacker-controlled payload retrieval associated with repository workflow abuse.

·        Prioritize outbound activity involving sensitive repositories, protected branches, package-publishing workflows, container-build workflows, signing workflows, infrastructure-as-code workflows, cloud deployment workflows, Kubernetes deployment workflows, or production deployment workflows.

·        Support escalation when unusual runner or build-host egress aligns with workflow modification, runner changes, token creation, deploy-key creation, webhook modification, suspicious pipeline execution, endpoint process telemetry, registry activity, or downstream control-plane activity.

·        Preserve separation between suspicious runner egress and confirmed compromise by requiring supporting Git, CI/CD, endpoint, identity, registry, package, cloud, Kubernetes, or incident-response evidence before classifying activity as probable compromise.

·        This rule does not prove repository compromise, workflow abuse, credential theft, token theft, registry compromise, package compromise, cloud compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify outbound communication from known CI/CD runners, build hosts, Git platform hosts, registry hosts, package services, or deployment automation systems.

·        Prioritize destinations that are newly observed for the source asset, rare for the runner group, rare for the repository class, rare for the workflow type, or inconsistent with approved build and release destinations.

·        Prioritize destination categories associated with raw-file hosting, paste services, tunneling infrastructure, dynamic DNS, temporary infrastructure, unmanaged object storage, file-sharing services, unknown external infrastructure, or destinations not approved for the relevant workflow.

·        Prioritize traffic occurring near CI/CD job execution, release workflow execution, package-publishing workflow execution, container-build workflow execution, infrastructure-as-code workflow execution, or deployment workflow execution.

·        Prioritize transfer patterns showing archive transfer, build-log transfer, artifact transfer, cache transfer, repository bundle movement, high-volume outbound transfer, unusual upload-to-download ratio, unusual POST or PUT behavior, or external staging behavior.

·        Increase confidence when the source asset is associated with sensitive repository classes, production deployment workflows, signing workflows, package publication, image publication, cloud deployment, Kubernetes deployment, or infrastructure-as-code execution.

·        Increase confidence when outbound communication follows suspicious workflow modification, unusual runner selection, runner tag changes, new runner registration, token creation, deploy-key creation, webhook modification, protected-branch control changes, or other CI/CD anomaly visible to integrated telemetry.

·        Increase confidence when endpoint telemetry from the runner or build host shows shell execution, archive creation, credential-location probing, environment-variable inspection, cloud CLI execution, Kubernetes CLI execution, registry client use, or network transfer tooling.

·        Reduce severity when the destination is a known approved dependency source, package mirror, container registry, artifact store, cloud service, update service, release endpoint, enterprise-managed integration, or documented vendor service used by the relevant workflow.

·        Do not classify unusual runner egress as repository compromise without workflow, runner, identity, endpoint, registry, cloud, Kubernetes, or incident-response linkage.

·        Do not treat destination novelty, transfer volume, external object-storage access, or raw-file retrieval as compromise evidence by itself.

Required Telemetry

·        Network-flow telemetry.

·        DNS telemetry.

·        HTTP telemetry where available.

·        TLS metadata where available.

·        Proxy logs where available.

·        Firewall logs.

·        Secure web gateway logs where available.

·        NDR metadata.

·        Source host.

·        Destination domain.

·        Destination IP.

·        Destination port.

·        Protocol.

·        Request method where available.

·        Byte count.

·        Upload and download directionality.

·        Connection timing.

·        Connection result.

·        Destination category.

·        Destination first-seen timestamp where available.

·        CI/CD runner inventory.

·        Build-host inventory.

·        Git platform host inventory.

·        Registry host inventory.

·        Package-service inventory.

·        Deployment automation inventory.

·        Repository sensitivity inventory where available.

·        Runner group context where available.

·        Workflow class context where available.

·        CI/CD job timing where available.

·        Runner tag context where available.

·        Branch, repository, project, or group context where available.

·        Token, deploy-key, webhook, or runner-change enrichment where available.

·        Endpoint telemetry from runners or build hosts where available.

·        Identity telemetry where available.

·        Approved external destination baselines.

·        Approved package mirror records.

·        Approved registry records.

·        Approved artifact-store records.

·        Approved cloud endpoint records.

·        Approved release endpoint records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build source asset groups covering CI/CD runners, build hosts, Git platform hosts, registry hosts, package services, release automation systems, deployment automation systems, and self-hosted Git infrastructure.

·        Build destination groups covering approved package mirrors, approved package registries, approved container registries, approved artifact stores, approved source-code hosts, approved cloud services, approved deployment endpoints, approved update services, and approved enterprise integrations.

·        Build suspicious destination groups covering raw-file hosting, paste services, tunneling services, dynamic DNS, file-sharing services, unmanaged object storage, newly observed domains, temporary infrastructure, unknown external destinations, and destinations not approved for build or release workflows.

·        Build sensitive workflow groups covering production deployment, signing, package publication, image publication, infrastructure-as-code, cloud deployment, Kubernetes deployment, release automation, and high-value repository classes.

·        Build transfer-anomaly groups covering high-volume upload, abnormal upload-to-download ratio, archive transfer, build-log transfer, artifact transfer, cache transfer, repository bundle movement, unusual POST or PUT behavior, and external staging behavior.

·        Build CI/CD context enrichment using job timing, runner tags, repository sensitivity, workflow name, branch, pipeline identity, initiating user, token context, and recent workflow or runner changes where available.

·        Validate whether NDR, DNS, proxy, firewall, secure web gateway, CI/CD, Git audit, endpoint, identity, registry, package, cloud, Kubernetes, and SIEM telemetry can reliably join on source host, runner identity, repository, workflow, pipeline, timestamp, destination, user, and environment context.

·        Use short correlation windows for outbound communication that occurs during or immediately after CI/CD job execution.

·        Use moderate correlation windows when runner egress follows workflow modification, runner registration, token creation, deploy-key creation, webhook modification, or suspicious pipeline execution.

·        Use longer correlation windows only when incident-response evidence, endpoint evidence, CI/CD lineage, or repeated source-to-destination behavior supports delayed linkage.

·        Add severity weighting for sensitive repository class, production deployment access, signing authority, package publication authority, image publication authority, cloud deployment authority, Kubernetes deployment authority, destination novelty, transfer anomaly, and supporting endpoint process behavior.

·        Treat unusual outbound runner communication as a confidence amplifier, not standalone proof of repository workflow compromise.

·        Use approved dependency-source records, release engineering records, package mirror records, artifact-store records, vendor integration records, cloud endpoint records, change-control records, and incident-response records as triage evidence.

·        Validate all source groups, destination groups, destination categories, transfer thresholds, timing windows, enrichment fields, exception logic, parser behavior, join logic, and local schema mappings before production deployment.

·        Do not enable alert mode until asset inventory, destination baselines, field availability, transfer-pattern baselines, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.2 / 10

·        The rule is behaviorally anchored to durable runner and build-host egress behavior rather than static domains, IP addresses, package names, image names, repository names, CVE identifiers, or one-off indicators.

·        The rule remains useful if an adversary changes payload source, staging destination, object-storage provider, transfer utility, command syntax, repository path, workflow filename, runner host, or timing.

·        The score is supported by the durability of unusual runner egress, external staging behavior, archive movement, artifact transfer, cache exposure, source-code bundle movement, and outbound transfer following suspicious CI/CD activity.

·        The score is constrained by shared NAT, ephemeral runners, proxy aggregation, encrypted traffic, weak asset inventory, incomplete CI/CD enrichment, and legitimate release engineering activity.

·        The rule is durable as an egress and staging detector but should not be treated as standalone proof of repository workflow abuse, credential theft, registry compromise, cloud compromise, or actor attribution.

TCR Assessment

Operational TCR

7.4 / 10

Full-Telemetry TCR

8.6 / 10

·        Operational confidence depends on accurate runner inventory, build-host inventory, destination baselines, DNS or proxy visibility, transfer metadata, destination classification, and SIEM correlation quality.

·        Operational confidence is reduced where outbound traffic is aggregated through shared NAT, ephemeral runners lack stable identity, destination categorization is weak, or approved build destinations are not well baselined.

·        Operational confidence is reduced during legitimate dependency changes, release engineering work, new integration onboarding, package mirror changes, runner migration, build-system modernization, or artifact-store migration.

·        Full-telemetry confidence improves when NDR data is enriched with Git audit logs, CI/CD job timing, workflow changes, runner identity, endpoint process telemetry, registry logs, package logs, identity context, cloud logs, Kubernetes logs, and change-control records.

·        Even under full telemetry conditions, this rule should support escalation and scoping rather than standalone confirmation of compromise.

Limitations

·        NDR does not directly observe workflow-file content unless integrated with Git or CI/CD telemetry.

·        NDR may not identify the exact credential, package, image, artifact, or repository involved without CI/CD, registry, or package-service enrichment.

·        Shared NAT, ephemeral runners, proxy aggregation, and weak asset inventory can reduce source attribution.

·        Encrypted traffic may limit content visibility.

·        Legitimate build, release, integration, and package-publication activity may create new or unusual external destinations.

·        The rule may miss activity that uses approved destinations, expected artifact stores, sanctioned cloud storage, or low-volume transfer patterns.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

NDR CI/CD runner and build-host unusual egress query pattern requiring platform syntax validation, source asset validation, destination category validation, transfer baseline validation, CI/CD timing enrichment validation, repository sensitivity enrichment validation, approved destination allowlisting, timing-window tuning, and environment-specific false-positive testing before production deployment.

NetworkEvent AS RunnerOutboundTransfer

WHERE RunnerOutboundTransfer.SourceAsset IN ASSET_GROUP (
"CI/CD Runners",
"Build Hosts",
"Git Platform Hosts",
"Registry Hosts",
"Package Services",
"Release Automation Systems",
"Deployment Automation Systems"
)

AND RunnerOutboundTransfer.Direction IN ANY (
"OUTBOUND",
"EGRESS",
"INTERNAL_TO_EXTERNAL"
)

AND RunnerOutboundTransfer.Destination NOT IN ASSET_GROUP (
"Approved Package Mirrors",
"Approved Package Registries",
"Approved Container Registries",
"Approved Artifact Stores",
"Approved Source Code Hosts",
"Approved Cloud Services",
"Approved Deployment Endpoints",
"Approved Enterprise Integrations"
)

AND (
RunnerOutboundTransfer.DestinationContext IN ANY (
"newly_observed_destination",
"rare_destination_for_source",
"rare_destination_for_runner_group",
"rare_destination_for_workflow",
"destination_not_in_build_baseline",
"unknown_external_destination"
)

OR RunnerOutboundTransfer.DestinationCategory IN ANY (
"raw_file_hosting",
"paste_service",
"tunnel_service",
"dynamic_dns",
"file_sharing",
"unmanaged_object_storage",
"temporary_infrastructure",
"unknown_external"
)

OR RunnerOutboundTransfer.TransferPattern IN ANY (
"high_volume_upload",
"unusual_upload_download_ratio",
"archive_transfer",
"artifact_transfer",
"cache_transfer",
"build_log_transfer",
"repository_bundle_transfer",
"unusual_post_or_put_behavior",
"external_staging_behavior"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_CICD_JOB_WINDOW (
CICDEvent AS RelatedPipelineContext
WHERE RelatedPipelineContext.Runner IN SAME_ASSET(RunnerOutboundTransfer.SourceAsset)
AND RelatedPipelineContext.EventType IN ANY (
"Pipeline Executed",
"Job Executed",
"Workflow Executed",
"Release Workflow Executed",
"Package Publishing Workflow Executed",
"Container Build Workflow Executed",
"Infrastructure As Code Workflow Executed",
"Deployment Workflow Executed"
)
AND RelatedPipelineContext.RepositorySensitivity IN ANY (
"production_deployment",
"package_publishing",
"image_publishing",
"signing",
"infrastructure_as_code",
"cloud_deployment",
"kubernetes_deployment",
"high_value_repository"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_CICD_CHANGE_WINDOW (
CICDOrGitEvent AS SuspiciousAutomationContext
WHERE SuspiciousAutomationContext.RepositoryOrRunner IN SAME_REPOSITORY_OR_RUNNER(RelatedPipelineContext.RepositoryOrRunner)
AND SuspiciousAutomationContext.EventPattern IN ANY (
"recent_workflow_change",
"recent_runner_registration",
"recent_runner_tag_change",
"recent_token_creation",
"recent_deploy_key_creation",
"recent_webhook_change",
"recent_protected_branch_change",
"suspicious_pipeline_execution"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_ENDPOINT_CONTEXT_WINDOW (
EndpointEvent AS RunnerHostProcessContext
WHERE RunnerHostProcessContext.Asset IN SAME_ASSET(RunnerOutboundTransfer.SourceAsset)
AND RunnerHostProcessContext.EventPattern IN ANY (
"archive_creation",
"credential_location_probing",
"environment_variable_inspection",
"cloud_cli_execution",
"kubernetes_cli_execution",
"registry_client_execution",
"network_transfer_tool_execution",
"suspicious_shell_execution"
)
)

AND NOT ChangeContext IN ANY (
"approved_release_engineering",
"approved_dependency_change",
"approved_package_mirror_change",
"approved_registry_migration",
"approved_artifact_store_change",
"approved_cloud_endpoint_change",
"approved_runner_migration",
"approved_build_system_modernization",
"approved_security_testing",
"approved_incident_response"
)

Rule

CI/CD Runner East-West Access Outside Expected Workflow Scope

Rule Format

NDR behavioral east-west runner-access correlation rule suitable for internal network-flow telemetry, firewall logs, segmentation telemetry, DNS telemetry, NDR metadata, runner inventory, build-host inventory, internal service inventory, repository sensitivity enrichment, CI/CD job timing enrichment, identity enrichment, asset criticality enrichment, and SIEM correlation after source-role validation, internal service validation, workflow-scope validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect CI/CD runners, build hosts, Git platform hosts, or deployment automation systems accessing internal services outside expected workflow scope.

·        Identify potential abuse of trusted build infrastructure to reach secret stores, identity providers, internal registries, package mirrors, artifact stores, Kubernetes APIs, deployment systems, administrative services, sensitive internal applications, or cloud integration endpoints.

·        Prioritize access from sensitive runners or build hosts associated with production deployment, package publishing, image publishing, signing workflows, infrastructure-as-code workflows, cloud deployment workflows, or Kubernetes deployment workflows.

·        Support escalation when unexpected internal access follows workflow modification, suspicious pipeline execution, runner registration, runner tag modification, token creation, deploy-key creation, webhook modification, or protected-branch control changes.

·        Preserve separation between suspicious runner east-west access and confirmed compromise by requiring supporting Git, CI/CD, identity, endpoint, registry, cloud, Kubernetes, deployment, or incident-response evidence before classifying activity as probable compromise.

·        This rule does not prove repository compromise, credential theft, token theft, lateral movement, cloud compromise, Kubernetes compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify internal network communication from known CI/CD runners, build hosts, Git platform hosts, or deployment automation systems.

·        Prioritize destination service categories that include secret stores, identity providers, internal registries, package mirrors, artifact stores, Kubernetes APIs, deployment controllers, cloud integration endpoints, administrative interfaces, or sensitive application services.

·        Prioritize source-to-destination relationships that are newly observed, rare for the source asset, rare for the runner group, rare for the workflow type, or outside the approved service set for that repository or deployment path.

·        Prioritize access occurring near suspicious CI/CD execution, workflow modification, runner registration, runner tag modification, token creation, deploy-key creation, webhook modification, protected-branch control changes, or automation identity changes.

·        Prioritize traffic patterns indicating service discovery, authentication probing, unusual API access, credential validation, registry enumeration, artifact enumeration, package enumeration, secret-store interaction, or deployment-environment discovery.

·        Increase confidence when the source host attempts access to multiple sensitive internal service categories during a single job window or short operational interval.

·        Increase confidence when the source host is associated with sensitive repositories, protected branches, package-publishing workflows, container-build workflows, production deployment workflows, infrastructure-as-code workflows, cloud deployment workflows, or Kubernetes deployment workflows.

·        Increase confidence when endpoint telemetry shows cloud CLI execution, Kubernetes CLI execution, registry client execution, secret-management tooling, network scanning utilities, authentication tooling, or unusual shell behavior from the runner or build host.

·        Reduce severity when the communication matches approved deployment flows, dependency retrieval paths, artifact retrieval paths, registry access paths, monitoring integrations, vulnerability scanning, backup operations, or known release automation.

·        Do not attribute internal service access to repository workflow compromise without workflow, runner, identity, endpoint, change-control, or incident-response linkage.

·        Do not treat internal DNS, identity-service access, registry access, or Kubernetes API access as compromise evidence by itself.

Required Telemetry

·        East-west network telemetry.

·        Internal firewall logs.

·        Segmentation telemetry where available.

·        Internal DNS logs.

·        NDR metadata.

·        Source asset.

·        Destination asset.

·        Source asset role.

·        Destination service role.

·        Protocol.

·        Port.

·        Byte count.

·        Connection timing.

·        Connection result.

·        Direction.

·        Source-to-destination first-seen timestamp where available.

·        CI/CD runner inventory.

·        Build-host inventory.

·        Git platform host inventory.

·        Deployment automation inventory.

·        Secret-store inventory.

·        Identity-provider inventory.

·        Internal registry inventory.

·        Package mirror inventory.

·        Artifact-store inventory.

·        Kubernetes API inventory.

·        Deployment-controller inventory.

·        Administrative service inventory.

·        Sensitive application inventory.

·        Asset criticality inventory.

·        Repository sensitivity inventory where available.

·        Runner group context where available.

·        Workflow class context where available.

·        CI/CD job timing where available.

·        Runner tag context where available.

·        Token, deploy-key, webhook, or runner-change enrichment where available.

·        Endpoint telemetry from runners or build hosts where available.

·        Identity telemetry where available.

·        Approved runner-to-service baselines.

·        Approved deployment-flow records.

·        Approved vulnerability scanning records.

·        Approved monitoring records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build source asset groups covering CI/CD runners, build hosts, Git platform hosts, deployment automation systems, registry hosts, and package services.

·        Build destination service groups covering secret stores, identity providers, internal registries, package mirrors, artifact stores, Kubernetes APIs, deployment controllers, cloud integration endpoints, administrative interfaces, sensitive application services, and high-value internal systems.

·        Build sensitive workflow groups covering production deployment, package publishing, image publishing, signing, infrastructure-as-code, cloud deployment, Kubernetes deployment, and high-value repository classes.

·        Build unexpected internal access groups covering first-seen source-to-destination pairs, rare destination service roles, service categories outside workflow scope, cross-segment access, authentication probing, denied-then-successful connections, and access to multiple sensitive service categories during a short window.

·        Build endpoint enrichment groups for runner or build-host execution involving cloud CLIs, Kubernetes CLIs, registry clients, package managers, secret-management tools, network utilities, authentication utilities, archive tools, and shell interpreters.

·        Validate whether NDR, internal firewall, segmentation, DNS, Git audit, CI/CD, endpoint, identity, registry, package, Kubernetes, cloud, deployment, and SIEM telemetry can reliably join on source host, runner identity, workflow, repository, timestamp, destination service, user, token, and environment context.

·        Use short correlation windows for internal access occurring during or immediately after CI/CD job execution.

·        Use moderate correlation windows when internal access follows workflow modification, runner registration, runner tag change, token creation, deploy-key creation, webhook modification, or suspicious pipeline execution.

·        Use longer correlation windows only when incident-response evidence, endpoint evidence, repeated runner behavior, or CI/CD lineage supports delayed linkage.

·        Add severity weighting for secret-store access, identity-service access, Kubernetes API access, deployment-controller access, internal registry access, administrative interface access, sensitive application access, source-to-destination novelty, account sensitivity, and sensitive workflow context.

·        Treat runner east-west anomalies as confidence amplifiers, not standalone proof of repository workflow compromise or lateral movement.

·        Use approved deployment records, dependency retrieval records, monitoring records, vulnerability scanning records, backup records, release engineering records, change-control records, and incident-response records as triage evidence.

·        Validate all source groups, destination service groups, service-role mappings, workflow-scope baselines, timing windows, enrichment fields, exception logic, parser behavior, join logic, and local schema mappings before production deployment.

·        Do not enable alert mode until internal service inventory, runner-to-service baselines, field availability, segmentation visibility, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.0 / 10

·        The rule is behaviorally anchored to durable runner east-west access outside expected workflow scope rather than static indicators, fixed destinations, package names, repository names, CVE identifiers, or one-off tooling artifacts.

·        The rule remains useful if an adversary changes workflow content, runner host, internal destination order, service discovery pattern, credential validation method, registry access sequence, or timing.

·        The score is supported by the durability of unexpected access from trusted build infrastructure to secret stores, identity providers, registries, artifact stores, Kubernetes APIs, deployment systems, administrative services, and sensitive applications.

·        The score is constrained by incomplete east-west visibility, weak internal service inventory, shared runners, broad runner network permissions, cloud-native networking abstraction, and legitimate deployment workflows.

·        The rule is durable as an internal access and environment-expansion detector but should not be treated as standalone proof of repository compromise, credential theft, lateral movement, or actor attribution.

TCR Assessment

Operational TCR

7.2 / 10

Full-Telemetry TCR

8.4 / 10

·        Operational confidence depends on reliable east-west visibility, runner inventory, internal service inventory, destination service classification, repository sensitivity mapping, runner-to-service baselines, and SIEM correlation quality.

·        Operational confidence is reduced where internal network telemetry is limited, internal services are poorly classified, runners have broad expected access, or build infrastructure shares networks with administrative systems.

·        Operational confidence is reduced during new deployments, platform migrations, dependency changes, vulnerability scanning, backup operations, monitoring changes, incident response, or approved release engineering changes.

·        Full-telemetry confidence improves when NDR data is enriched with CI/CD job timing, Git audit events, workflow changes, runner identity, endpoint process telemetry, identity anomalies, registry logs, package logs, cloud logs, Kubernetes logs, and deployment logs.

·        Even under full telemetry conditions, this rule should support escalation and scoping rather than standalone confirmation of compromise.

Limitations

·        East-west traffic may be invisible in flat networks, cloud-native environments, or environments without internal flow logging.

·        NDR may not determine whether internal access was authorized without CI/CD, identity, endpoint, and change-control context.

·        Internal service inventories may be incomplete, stale, or inconsistently labeled.

·        Legitimate deployment workflows may access sensitive internal services.

·        Shared runners and broad runner network permissions can increase noise.

·        The rule may miss activity that occurs through expected service paths, approved deployment systems, or trusted network segments.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

NDR CI/CD runner east-west access query pattern requiring platform syntax validation, internal service inventory validation, source asset validation, destination service validation, workflow-scope validation, runner-to-service baseline validation, timing-window tuning, and environment-specific allowlisting before production deployment.

NetworkEvent AS RunnerEastWestAccess

WHERE RunnerEastWestAccess.SourceAsset IN ASSET_GROUP (
"CI/CD Runners",
"Build Hosts",
"Git Platform Hosts",
"Deployment Automation Systems",
"Registry Hosts",
"Package Services"
)

AND RunnerEastWestAccess.Direction IN ANY (
"INTERNAL",
"EAST_WEST",
"INTERNAL_TO_INTERNAL"
)

AND RunnerEastWestAccess.DestinationServiceRole IN ANY (
"Secret Store",
"Identity Provider",
"Internal Registry",
"Package Mirror",
"Artifact Store",
"Kubernetes API",
"Deployment Controller",
"Cloud Integration Endpoint",
"Administrative Interface",
"Sensitive Application",
"High Value Internal Service"
)

AND (
RunnerEastWestAccess.AccessContext IN ANY (
"first_seen_source_destination_pair",
"rare_destination_for_source",
"rare_destination_for_runner_group",
"service_outside_expected_workflow_scope",
"cross_segment_access",
"access_to_multiple_sensitive_service_categories",
"denied_then_successful_access"
)

OR RunnerEastWestAccess.ActivityPattern IN ANY (
"service_discovery",
"authentication_probing",
"unusual_api_access",
"credential_validation",
"registry_enumeration",
"artifact_enumeration",
"package_enumeration",
"secret_store_interaction",
"deployment_environment_discovery"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_CICD_JOB_WINDOW (
CICDEvent AS RelatedPipelineContext
WHERE RelatedPipelineContext.Runner IN SAME_ASSET(RunnerEastWestAccess.SourceAsset)
AND RelatedPipelineContext.RepositorySensitivity IN ANY (
"production_deployment",
"package_publishing",
"image_publishing",
"signing",
"infrastructure_as_code",
"cloud_deployment",
"kubernetes_deployment",
"high_value_repository"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_CICD_CHANGE_WINDOW (
CICDOrGitEvent AS SuspiciousAutomationContext
WHERE SuspiciousAutomationContext.RepositoryOrRunner IN SAME_REPOSITORY_OR_RUNNER(RelatedPipelineContext.RepositoryOrRunner)
AND SuspiciousAutomationContext.EventPattern IN ANY (
"recent_workflow_change",
"recent_runner_registration",
"recent_runner_tag_change",
"recent_token_creation",
"recent_deploy_key_creation",
"recent_webhook_change",
"recent_protected_branch_change",
"suspicious_pipeline_execution"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_ENDPOINT_CONTEXT_WINDOW (
EndpointEvent AS RunnerHostProcessContext
WHERE RunnerHostProcessContext.Asset IN SAME_ASSET(RunnerEastWestAccess.SourceAsset)
AND RunnerHostProcessContext.EventPattern IN ANY (
"cloud_cli_execution",
"kubernetes_cli_execution",
"registry_client_execution",
"secret_management_tool_execution",
"network_utility_execution",
"authentication_tool_execution",
"suspicious_shell_execution"
)
)

AND NOT ChangeContext IN ANY (
"approved_deployment_flow",
"approved_dependency_retrieval",
"approved_artifact_retrieval",
"approved_registry_access",
"approved_monitoring_integration",
"approved_vulnerability_scanning",
"approved_backup_operation",
"approved_release_automation",
"approved_security_testing",
"approved_incident_response"
)

Rule

Unusual Registry, Package, Artifact, or Image Transfer From CI/CD Infrastructure

Rule Format

NDR behavioral registry and artifact-transfer correlation rule suitable for network-flow telemetry, DNS telemetry, proxy telemetry, firewall logs, NDR metadata, registry inventory, package-service inventory, artifact-store inventory, build-cache inventory, release-system inventory, runner inventory, build-host inventory, repository sensitivity enrichment, CI/CD job timing enrichment, registry enrichment, package enrichment, cloud enrichment, and SIEM correlation after source-role validation, destination-service validation, transfer-baseline validation, repository-lineage validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect unusual network transfer behavior involving package registries, container registries, artifact stores, release systems, build caches, image repositories, or object-storage locations from CI/CD runners, build hosts, Git platform hosts, registry hosts, package services, or deployment automation systems.

·        Identify possible package manipulation, image abuse, artifact exfiltration, cache exposure, build-output staging, release asset modification, or registry credential misuse following repository workflow abuse.

·        Prioritize transfer behavior involving sensitive repositories, production release workflows, private packages, private images, signing workflows, infrastructure-as-code outputs, deployment artifacts, or high-value build outputs.

·        Support escalation when unusual registry, package, artifact, cache, image, or release-system activity follows workflow modification, suspicious pipeline execution, runner changes, token creation, deploy-key creation, webhook modification, OAuth application creation, or protected-branch control changes.

·        Preserve separation between suspicious transfer behavior and confirmed package, image, artifact, or registry compromise by requiring supporting Git, CI/CD, registry, package, endpoint, identity, deployment, cloud, Kubernetes, or incident-response evidence before classifying activity as probable compromise.

·        This rule does not prove malicious package publication, image compromise, artifact tampering, credential theft, token theft, deployment compromise, cloud compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify access from CI/CD infrastructure to internal or external package registries, container registries, artifact stores, release systems, build caches, image repositories, or object-storage locations associated with build outputs.

·        Prioritize source-to-destination pairs that are newly observed, rare for the source, rare for the runner group, rare for the repository class, rare for the workflow type, or inconsistent with approved package, image, artifact, cache, or release behavior.

·        Prioritize transfer volume, transfer direction, transfer frequency, request pattern, timing, or destination diversity that differs from normal behavior for the relevant package, image, artifact, cache, release, or deployment workflow.

·        Prioritize activity occurring after workflow modification, suspicious pipeline execution, runner change, token creation, deploy-key creation, webhook modification, OAuth application creation, protected-branch control change, or release-control change.

·        Prioritize activity involving private packages, private images, production release artifacts, signing workflows, infrastructure-as-code outputs, deployment artifacts, or sensitive build outputs.

·        Prioritize traffic patterns suggesting image-layer extraction, artifact staging, package publication, release asset overwrite, build-cache exposure, unusual upload behavior, unauthorized build-output retrieval, or registry credential misuse.

·        Increase confidence when the source accesses multiple registries, package services, artifact stores, release systems, cache locations, image repositories, or object-storage endpoints during a short interval.

·        Increase confidence when endpoint telemetry shows registry client use, package manager execution, archive creation, credential-location probing, cloud storage tooling, container tooling, or unusual shell behavior from the runner or build host.

·        Reduce severity when the activity matches known release windows, approved package publication, expected container image builds, approved artifact retention, dependency retrieval, vulnerability scanning, backup jobs, registry migration, or documented registry maintenance.

·        Do not attribute unusual registry, package, artifact, or image transfer to repository workflow compromise without Git, CI/CD, registry, package, endpoint, identity, deployment, cloud, Kubernetes, or incident-response linkage.

·        Do not treat registry access, package access, artifact access, cache access, image pull, image push, or object-storage transfer as compromise evidence by itself.

Required Telemetry

·        Network-flow telemetry.

·        DNS telemetry.

·        Proxy logs where available.

·        Firewall logs.

·        NDR metadata.

·        Source host.

·        Destination domain.

·        Destination IP.

·        Destination service role.

·        Protocol.

·        Request method where available.

·        Byte count.

·        Transfer direction.

·        Connection timing.

·        Connection result.

·        Destination category.

·        CI/CD runner inventory.

·        Build-host inventory.

·        Git platform host inventory.

·        Registry host inventory.

·        Package-service inventory.

·        Artifact-store inventory.

·        Build-cache inventory.

·        Release-system inventory.

·        Object-storage inventory where available.

·        Image repository inventory.

·        Repository sensitivity inventory where available.

·        Runner group context where available.

·        Workflow class context where available.

·        CI/CD job timing where available.

·        Registry logs where available.

·        Package-service logs where available.

·        Artifact-store logs where available.

·        Release-system logs where available.

·        Endpoint telemetry from runners or build hosts where available.

·        Identity telemetry where available.

·        Token, deploy-key, webhook, runner-change, or release-control enrichment where available.

·        Approved package workflow baselines.

·        Approved image workflow baselines.

·        Approved artifact workflow baselines.

·        Approved cache workflow baselines.

·        Approved release workflow baselines.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build source groups covering CI/CD runners, build hosts, Git platform hosts, registry hosts, package services, release automation systems, and deployment automation systems.

·        Build destination groups covering package registries, container registries, artifact stores, build caches, release systems, object-storage endpoints, image repositories, and approved dependency sources.

·        Build sensitive build-output groups covering private packages, private images, production release artifacts, signing outputs, infrastructure-as-code outputs, deployment artifacts, high-value build artifacts, and sensitive cache locations.

·        Build transfer-anomaly groups covering first-seen registry access, rare package-service access, rare artifact-store access, rare image-repository access, abnormal upload volume, abnormal download volume, unexpected transfer direction, image-layer extraction pattern, release asset overwrite pattern, artifact staging pattern, build-cache exposure pattern, and multiple destination service categories during a short interval.

·        Build CI/CD enrichment groups using job timing, workflow name, repository sensitivity, branch, runner tag, pipeline identity, initiating user, token context, and recent workflow, runner, token, deploy-key, webhook, OAuth application, or release-control changes where available.

·        Build endpoint enrichment groups for registry client execution, package manager execution, container tooling, archive creation, credential-location probing, cloud storage tooling, network transfer tooling, and suspicious shell execution from runners or build hosts.

·        Validate whether NDR, DNS, proxy, firewall, CI/CD, Git audit, registry, package-service, artifact-store, endpoint, identity, cloud, Kubernetes, deployment, and SIEM telemetry can reliably join on source host, runner identity, repository, workflow, pipeline, timestamp, destination service, package, image, artifact, token, and environment context.

·        Use short correlation windows for registry, package, artifact, cache, image, or release-system transfer during or immediately after CI/CD job execution.

·        Use moderate correlation windows when transfer follows workflow modification, runner registration, runner tag change, token creation, deploy-key creation, webhook modification, OAuth application creation, or suspicious pipeline execution.

·        Use longer correlation windows only when incident-response evidence, registry evidence, package evidence, endpoint evidence, repeated transfer behavior, or CI/CD lineage supports delayed linkage.

·        Add severity weighting for private package access, private image access, release artifact modification, signing workflow involvement, production deployment workflow involvement, image publication authority, package publication authority, unusual transfer direction, destination novelty, transfer volume, and supporting endpoint process behavior.

·        Treat unusual registry, package, artifact, cache, image, or release transfer as a confidence amplifier, not standalone proof of repository workflow compromise or package compromise.

·        Use approved release records, package publication records, image publication records, artifact retention records, registry maintenance records, vulnerability scanning records, backup records, change-control records, and incident-response records as triage evidence.

·        Validate all source groups, destination groups, transfer thresholds, workflow baselines, package and image context, timing windows, enrichment fields, exception logic, parser behavior, join logic, and local schema mappings before production deployment.

·        Do not enable alert mode until registry destination validation, package and artifact baselines, field availability, transfer-pattern validation, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.1 / 10

·        The rule is behaviorally anchored to durable registry, package, artifact, cache, image, and release-transfer behavior rather than static package names, image names, artifact names, repository names, IP addresses, domains, hashes, or CVE identifiers.

·        The rule remains useful if an adversary changes package name, image tag, artifact name, registry endpoint, object-storage provider, workflow filename, runner host, transfer timing, or publication sequence.

·        The score is supported by the durability of suspicious package access, image transfer, artifact staging, build-cache exposure, release asset modification, and unusual build-output movement from CI/CD infrastructure.

·        The score is constrained by encrypted registry traffic, shared registries, shared runners, weak repository-to-artifact lineage, limited package logs, limited registry logs, and legitimate release engineering activity.

·        The rule is durable as a registry and build-output movement detector but should not be treated as standalone proof of package compromise, image compromise, artifact tampering, credential theft, or actor attribution.

TCR Assessment

Operational TCR

7.3 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on registry destination classification, package-service visibility, artifact-store visibility, runner inventory, transfer baselines, CI/CD context, repository sensitivity mapping, and SIEM correlation quality.

·        Operational confidence is reduced where registry traffic is encrypted and aggregated, package names are not visible, image tags are not visible, artifact lineage is unavailable, or repository-to-registry mapping is weak.

·        Operational confidence is reduced during release surges, registry migrations, new package publication, build-system refactoring, vulnerability scanning, backup operations, artifact-retention changes, or image-publishing workflow changes.

·        Full-telemetry confidence improves when NDR data is enriched with Git audit logs, CI/CD job timing, runner identity, registry logs, package-service logs, endpoint process telemetry, identity events, deployment logs, cloud logs, Kubernetes logs, and change-control records.

·        Even under full telemetry conditions, this rule should support escalation and exposure scoping rather than standalone confirmation of package, image, artifact, or registry compromise.

Limitations

·        NDR may not identify package names, image tags, artifact names, repository lineage, or token identity without registry, package-service, or CI/CD enrichment.

·        Encrypted registry, package, artifact, or object-storage traffic may limit content inspection.

·        Normal release engineering activity can produce large, unusual, or bursty transfer patterns.

·        Shared runners, shared registries, and shared package services can reduce attribution quality.

·        Cloud object storage may be legitimate for builds, artifacts, logs, releases, and deployment workflows.

·        The rule may miss abuse that uses expected registries, approved package services, sanctioned object storage, or normal transfer volumes.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

NDR CI/CD registry, package, artifact, cache, image, and release-transfer query pattern requiring platform syntax validation, source asset validation, destination service validation, transfer baseline validation, package and registry enrichment validation, CI/CD timing validation, repository-lineage validation, approved workflow allowlisting, timing-window tuning, and environment-specific false-positive testing before production deployment.

NetworkEvent AS BuildOutputTransfer

WHERE BuildOutputTransfer.SourceAsset IN ASSET_GROUP (
"CI/CD Runners",
"Build Hosts",
"Git Platform Hosts",
"Registry Hosts",
"Package Services",
"Release Automation Systems",
"Deployment Automation Systems"
)

AND BuildOutputTransfer.DestinationServiceRole IN ANY (
"Package Registry",
"Container Registry",
"Artifact Store",
"Build Cache",
"Release System",
"Object Storage",
"Image Repository",
"Package Service"
)

AND BuildOutputTransfer.Direction IN ANY (
"OUTBOUND",
"INTERNAL",
"EAST_WEST",
"UPLOAD",
"DOWNLOAD"
)

AND (
BuildOutputTransfer.TransferContext IN ANY (
"first_seen_source_destination_pair",
"rare_registry_for_source",
"rare_package_service_for_source",
"rare_artifact_store_for_source",
"rare_image_repository_for_source",
"destination_not_in_workflow_baseline",
"unexpected_transfer_direction",
"multiple_registry_or_artifact_destinations"
)

OR BuildOutputTransfer.TransferPattern IN ANY (
"abnormal_upload_volume",
"abnormal_download_volume",
"image_layer_extraction_pattern",
"artifact_staging_pattern",
"release_asset_overwrite_pattern",
"build_cache_exposure_pattern",
"unauthorized_build_output_retrieval",
"registry_credential_misuse_pattern"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_CICD_JOB_WINDOW (
CICDEvent AS RelatedPipelineContext
WHERE RelatedPipelineContext.Runner IN SAME_ASSET(BuildOutputTransfer.SourceAsset)
AND RelatedPipelineContext.RepositorySensitivity IN ANY (
"production_release",
"package_publishing",
"image_publishing",
"signing",
"infrastructure_as_code",
"cloud_deployment",
"kubernetes_deployment",
"high_value_repository"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_CICD_CHANGE_WINDOW (
CICDOrGitEvent AS SuspiciousAutomationContext
WHERE SuspiciousAutomationContext.RepositoryOrRunner IN SAME_REPOSITORY_OR_RUNNER(RelatedPipelineContext.RepositoryOrRunner)
AND SuspiciousAutomationContext.EventPattern IN ANY (
"recent_workflow_change",
"recent_runner_registration",
"recent_runner_tag_change",
"recent_token_creation",
"recent_deploy_key_creation",
"recent_webhook_change",
"recent_oauth_application_creation",
"recent_release_control_change",
"suspicious_pipeline_execution"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_ENDPOINT_CONTEXT_WINDOW (
EndpointEvent AS RunnerHostProcessContext
WHERE RunnerHostProcessContext.Asset IN SAME_ASSET(BuildOutputTransfer.SourceAsset)
AND RunnerHostProcessContext.EventPattern IN ANY (
"registry_client_execution",
"package_manager_execution",
"container_tooling_execution",
"archive_creation",
"credential_location_probing",
"cloud_storage_tool_execution",
"network_transfer_tool_execution",
"suspicious_shell_execution"
)
)

AND NOT ChangeContext IN ANY (
"approved_release_window",
"approved_package_publication",
"approved_container_image_build",
"approved_artifact_retention",
"approved_dependency_retrieval",
"approved_vulnerability_scanning",
"approved_backup_job",
"approved_registry_migration",
"approved_registry_maintenance",
"approved_security_testing",
"approved_incident_response"
)

SentinelOne

Detection Viability Assessment

SentinelOne has three rules for this EXP report.

·        SentinelOne is viable for detecting endpoint-side behavior associated with self-hosted Git platform compromise through repository workflow abuse, including suspicious CI/CD runner execution, build-host process activity, credential and token access behavior, artifact staging, registry tooling, container tooling, cloud or Kubernetes CLI use, persistence attempts, and activity on systems supporting software delivery.

·        SentinelOne is strongest where Deep Visibility telemetry, process telemetry, command-line telemetry, parent-child process relationships, Storyline context, file telemetry, network telemetry, DNS enrichment, identity enrichment, runner host inventory, build-host inventory, Git platform inventory, registry host inventory, and SIEM correlation can be combined.

·        SentinelOne can identify suspicious runner-host and build-host execution even when the repository workflow change, token creation, webhook modification, runner registration, package registry access, or downstream cloud activity is observed through Git audit logs, CI/CD logs, registry logs, NDR telemetry, cloud logs, Kubernetes logs, or SIEM correlation rather than directly inside SentinelOne.

·        SentinelOne is not a standalone source for confirming repository workflow compromise, Git platform compromise, malicious package publication, container image compromise, cloud compromise, Kubernetes compromise, or actor attribution because endpoint telemetry may not fully observe repository-control activity, CI/CD control-plane state, token scope, registry object identity, or downstream deployment lineage.

·        SentinelOne detections must be correlated with Git audit logs, CI/CD pipeline logs, runner metadata, identity logs, NDR telemetry, DNS logs, proxy logs, registry logs, package-service logs, artifact-store logs, cloud logs, Kubernetes logs, deployment logs, change-control records, and incident-response evidence before classifying endpoint behavior as probable repository workflow compromise.

·        SentinelOne should be treated as endpoint confirmation, runner-host triage, build-host triage, and post-execution behavior coverage for suspected repository workflow abuse, not standalone proof of the Git platform exploit path.

·        SentinelOne rules should not generate high-confidence alerting from shell execution alone, PowerShell execution alone, package-manager execution alone, cloud CLI execution alone, registry client execution alone, archive creation alone, network transfer tooling alone, or SentinelOne behavioral alerts alone without suspicious CI/CD, repository, runner, identity, registry, cloud, Kubernetes, or incident-response context.

Rule

CI/CD Runner or Build Host Suspicious Execution After Repository Workflow Activity

Rule Format

SentinelOne endpoint behavioral runner-execution correlation rule suitable for Deep Visibility telemetry, process telemetry, command-line telemetry, parent-child process relationships, Storyline context, file telemetry, network telemetry, DNS enrichment, runner inventory, build-host inventory, repository sensitivity enrichment, suspicious workflow enrichment, CI/CD job timing enrichment, identity enrichment, and SIEM correlation after endpoint field validation, runner-host mapping, workflow-context validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious process execution, script execution, archive creation, file staging, network transfer tooling, or living-off-the-land behavior on CI/CD runners, build hosts, Git platform hosts, registry hosts, or deployment automation systems after suspicious repository workflow activity or CI/CD job execution.

·        Identify endpoint behavior that may indicate repository workflow abuse, malicious CI/CD job execution, credential staging, artifact staging, source-code bundling, build-log collection, payload retrieval, or post-execution preparation.

·        Prioritize suspicious execution involving shell interpreters, scripting engines, package managers, archive utilities, cloud CLIs, Kubernetes CLIs, registry clients, container tooling, credential helpers, and network transfer utilities.

·        Support escalation when suspicious runner or build-host execution aligns with workflow modification, runner registration, runner tag changes, token creation, deploy-key creation, webhook modification, protected-branch control changes, unusual outbound communication, registry activity, or downstream control-plane activity.

·        Preserve separation between suspicious endpoint execution and confirmed compromise by requiring supporting Git, CI/CD, runner, identity, network, registry, package, cloud, Kubernetes, or incident-response evidence before classifying the activity as probable compromise.

·        This rule does not prove repository compromise, workflow abuse, credential theft, token theft, registry compromise, cloud compromise, Kubernetes compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify process execution on CI/CD runners, build hosts, Git platform hosts, registry hosts, package services, release automation systems, or deployment automation systems.

·        Prioritize execution occurring during or shortly after CI/CD job execution, workflow execution, release workflow execution, package-publishing workflow execution, container-build workflow execution, infrastructure-as-code workflow execution, or deployment workflow execution.

·        Prioritize endpoint activity enriched with suspicious Git or CI/CD context, including recent workflow modification, new runner registration, runner tag change, token creation, deploy-key creation, webhook modification, OAuth application creation, protected-branch control change, or unusual pipeline execution.

·        Detect suspicious process chains involving Bash, sh, PowerShell, Python, Node.js, Ruby, Perl, Go, Java, command shell, package managers, archive utilities, cloud CLIs, Kubernetes CLIs, registry clients, container tooling, credential helpers, or network transfer utilities.

·        Prioritize command lines involving environment-variable inspection, credential-location probing, secret-file access, protected-variable exposure, archive creation, recursive repository collection, direct IP access, remote retrieval, encoded execution, suspicious command chaining, or external transfer.

·        Prioritize file writes, archive creation, script creation, executable creation, tool staging, or credential collection in runner workspaces, build directories, temporary paths, cache directories, artifact directories, user-writable paths, mounted container workspaces, or service-account directories.

·        Increase confidence when SentinelOne Storyline context links suspicious execution to network transfer, file staging, credential access, registry client use, cloud CLI use, Kubernetes CLI use, or suspicious child-process behavior.

·        Increase confidence when the affected host is associated with sensitive repositories, production deployment, package publication, image publication, signing workflows, infrastructure-as-code, cloud deployment, Kubernetes deployment, or high-value build paths.

·        Reduce severity when execution matches approved build scripts, release automation, package publication, container builds, infrastructure deployment, vulnerability scanning, software deployment, security testing, incident response, or documented change-control activity.

·        Do not classify runner or build-host execution as repository workflow compromise without suspicious repository, CI/CD, runner, identity, network, registry, cloud, Kubernetes, or incident-response linkage.

·        Do not treat shell execution, package-manager activity, archive creation, cloud CLI use, Kubernetes CLI use, or registry client execution as compromise evidence by itself.

Required Telemetry

·        SentinelOne Deep Visibility telemetry.

·        Process creation events.

·        Process termination events where available.

·        Command-line telemetry.

·        Parent process and grandparent process.

·        Process path.

·        Process hash.

·        Process signer and certificate metadata.

·        User identity.

·        Service-account identity where available.

·        Device identity.

·        Hostname.

·        Working directory.

·        Integrity level where available.

·        Process start time.

·        SentinelOne Storyline context.

·        File creation telemetry.

·        File modification telemetry.

·        File execution telemetry.

·        Archive creation telemetry where available.

·        Script execution telemetry.

·        Network connection telemetry.

·        DNS enrichment where available.

·        Proxy enrichment where available.

·        Cloud CLI execution visibility where available.

·        Kubernetes CLI execution visibility where available.

·        Registry client execution visibility where available.

·        Container runtime telemetry where available.

·        CI/CD runner inventory.

·        Build-host inventory.

·        Git platform host inventory.

·        Registry host inventory.

·        Deployment automation inventory.

·        Repository sensitivity enrichment where available.

·        CI/CD job timing enrichment where available.

·        Suspicious workflow enrichment where available.

·        Token, deploy-key, webhook, runner-change, or protected-branch enrichment where available.

·        Approved build workflow baselines.

·        Approved release workflow baselines.

·        Approved package publication baselines.

·        Approved container build baselines.

·        Approved infrastructure deployment baselines.

·        Approved security testing records.

·        Approved incident-response records.

·        Change-control records.

Engineering Implementation Instructions

·        Build host groups covering CI/CD runners, build hosts, Git platform hosts, registry hosts, package services, release automation systems, deployment automation systems, and self-hosted Git support infrastructure.

·        Build suspicious execution groups covering shell interpreters, scripting engines, package managers, archive utilities, compression tools, cloud CLIs, Kubernetes CLIs, registry clients, container tooling, credential helpers, network transfer utilities, and locally relevant living-off-the-land binaries.

·        Build suspicious command-line groups for environment-variable inspection, credential-location probing, secret-file access, protected-variable exposure, archive creation, recursive file collection, repository bundling, direct IP access, remote retrieval, encoded execution, suspicious command chaining, and external transfer.

·        Build file-staging groups for runner workspaces, build directories, temporary paths, cache directories, artifact directories, mounted container workspaces, service-account directories, user-writable paths, and locally observed staging locations.

·        Build suspicious CI/CD enrichment groups using Git audit logs, CI/CD logs, runner metadata, identity logs, NDR telemetry, registry logs, package logs, cloud logs, Kubernetes logs, and SIEM context that identifies workflow modification, suspicious pipeline execution, new runner registration, runner tag change, token creation, deploy-key creation, webhook modification, OAuth application creation, protected-branch change, or release-control change.

·        Build post-execution groups for credential access, token access, archive creation, suspicious outbound communication, registry access, package access, cloud CLI activity, Kubernetes CLI activity, container tooling, and SentinelOne behavioral indicators.

·        Validate SentinelOne field availability for process ancestry, command line, file path, user identity, service-account identity, device identity, Storyline ID, network connections, DNS enrichment, file writes, script execution, and behavioral indicators.

·        Validate SIEM joins between SentinelOne telemetry, Git audit logs, CI/CD logs, runner metadata, NDR telemetry, identity logs, registry logs, package-service logs, cloud logs, Kubernetes logs, and deployment logs.

·        Use short correlation windows when suspicious execution occurs during or immediately after CI/CD job execution.

·        Use moderate correlation windows when execution follows workflow modification, runner registration, runner tag change, token creation, deploy-key creation, webhook modification, OAuth application creation, or suspicious pipeline execution.

·        Use longer correlation windows only when SentinelOne Storyline continuity, CI/CD lineage, identity evidence, endpoint evidence, or incident-response evidence supports delayed linkage.

·        Add severity weighting for suspicious workflow context, sensitive repository class, privileged runner context, production deployment access, signing authority, package publication authority, image publication authority, credential access, token access, file staging, and suspicious outbound communication.

·        Treat suspicious endpoint execution as a confidence amplifier, not standalone proof of repository workflow compromise.

·        Build allowlists for approved build scripts, release automation, package publication, container builds, infrastructure deployment, vulnerability scanning, security testing, incident response, developer workflows, and known automation.

·        Do not enable alert mode until process grouping, command-line parsing, CI/CD context enrichment, Storyline correlation, field availability, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and endpoint-response workflow requirements are validated.

DRI Assessment

DRI

8.1 / 10

·        The rule is behaviorally anchored to suspicious runner and build-host execution after repository workflow or CI/CD activity rather than static file hashes, domains, IP addresses, package names, image names, repository names, or CVE identifiers.

·        The rule remains useful if an adversary changes workflow filename, command syntax, staging path, interpreter, transfer utility, package manager, cloud CLI, registry client, runner host, or timing.

·        The score is supported by the durability of environment-variable inspection, credential-location probing, archive creation, network transfer tooling, registry tooling, cloud CLI use, Kubernetes CLI use, and suspicious process chains on runner or build hosts.

·        The score is constrained by legitimate build scripts, release engineering activity, developer tooling, incomplete command-line telemetry, missing CI/CD enrichment, shared runners, and noisy build-host behavior.

·        The rule is durable as endpoint execution coverage but should not be treated as standalone proof of repository workflow abuse, credential theft, registry compromise, cloud compromise, or actor attribution.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

8.6 / 10

·        Operational confidence depends on SentinelOne process telemetry, command-line visibility, Storyline continuity, runner inventory, CI/CD job timing, suspicious workflow enrichment, file telemetry, network telemetry, and SIEM correlation quality.

·        Operational confidence is reduced where command lines are truncated, process ancestry is incomplete, runner identities are unstable, build scripts are highly variable, or SentinelOne telemetry cannot be joined to Git and CI/CD context.

·        Operational confidence is reduced in build, release, developer, DevOps, vulnerability management, security testing, and incident-response environments where similar execution may be legitimate.

·        Full-telemetry confidence improves when SentinelOne telemetry is enriched with Git audit logs, CI/CD pipeline logs, runner metadata, NDR telemetry, identity logs, registry logs, package-service logs, cloud logs, Kubernetes logs, and change-control records.

·        Even under full telemetry conditions, this rule should support endpoint triage and escalation rather than standalone confirmation of compromise.

Limitations

·        SentinelOne cannot independently confirm repository workflow modification, token creation, deploy-key creation, webhook modification, runner registration, or Git platform compromise without external enrichment.

·        Shell execution, package-manager activity, registry client execution, cloud CLI use, Kubernetes CLI use, and archive creation may be normal in CI/CD environments.

·        Missing command-line telemetry, incomplete process ancestry, weak Storyline continuity, or missing CI/CD enrichment can reduce confidence.

·        Shared runners and high-change build systems can increase false positives.

·        This rule may miss activity that uses approved build tooling, expected scripts, low-noise commands, or normal workflow paths.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

SentinelOne Deep Visibility CI/CD runner suspicious execution query pattern requiring tenant syntax validation, endpoint field validation, runner-host validation, CI/CD context validation, suspicious workflow enrichment validation, command-line parsing validation, Storyline validation, approved workflow allowlisting, timing-window tuning, and environment-specific false-positive testing before production deployment.

SentinelOneEndpointEvent AS RunnerSuspiciousExecution

WHERE RunnerSuspiciousExecution.AgentComputerName IN ASSET_GROUP (
"CI/CD Runners",
"Build Hosts",
"Git Platform Hosts",
"Registry Hosts",
"Package Services",
"Release Automation Systems",
"Deployment Automation Systems"
)

AND RunnerSuspiciousExecution.EventType IN ANY (
"Process Creation",
"Process Execution",
"File Creation",
"File Modification",
"File Execution",
"Script Execution",
"Network Connection",
"Behavioral Indicator",
"Storyline Process Event"
)

AND (
RunnerSuspiciousExecution.TgtProcName IN ANY (
"bash",
"sh",
"zsh",
"powershell.exe",
"pwsh.exe",
"cmd.exe",
"python.exe",
"python3",
"node",
"node.exe",
"ruby",
"perl",
"go",
"java",
"curl",
"wget",
"tar",
"zip",
"7z",
"gzip",
"docker",
"kubectl",
"helm",
"aws",
"az",
"gcloud",
"git",
"npm",
"pip",
"yarn",
"pnpm",
"docker-compose"
)

OR RunnerSuspiciousExecution.TgtProcCmdLine CONTAINS ANY (
"env",
"printenv",
"cat /proc/self/environ",
"credential",
"token",
"secret",
"password",
"private_key",
"id_rsa",
"kubeconfig",
".aws/credentials",
".docker/config.json",
"archive",
"tar ",
"zip ",
"curl ",
"wget ",
"base64",
"upload",
"artifact",
"cache",
"registry",
"docker login",
"kubectl config",
"aws sts",
"az account",
"gcloud auth"
)

OR RunnerSuspiciousExecution.BehavioralIndicator IN ANY (
"Suspicious Process Execution",
"Credential Access Behavior",
"Token Access",
"Tool Staging",
"Archive Creation",
"Suspicious Network Transfer",
"Suspicious Child Process",
"Cloud CLI Execution",
"Kubernetes CLI Execution",
"Registry Client Execution"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_CICD_JOB_WINDOW (
CICDEvent AS RelatedPipelineContext
WHERE RelatedPipelineContext.Runner IN SAME_ASSET(RunnerSuspiciousExecution.AgentComputerName)
AND RelatedPipelineContext.EventType IN ANY (
"Pipeline Executed",
"Job Executed",
"Workflow Executed",
"Release Workflow Executed",
"Package Publishing Workflow Executed",
"Container Build Workflow Executed",
"Infrastructure As Code Workflow Executed",
"Deployment Workflow Executed"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_CICD_CHANGE_WINDOW (
CICDOrGitEvent AS SuspiciousAutomationContext
WHERE SuspiciousAutomationContext.RepositoryOrRunner IN SAME_REPOSITORY_OR_RUNNER(RelatedPipelineContext.RepositoryOrRunner)
AND SuspiciousAutomationContext.EventPattern IN ANY (
"recent_workflow_change",
"recent_runner_registration",
"recent_runner_tag_change",
"recent_token_creation",
"recent_deploy_key_creation",
"recent_webhook_change",
"recent_oauth_application_creation",
"recent_protected_branch_change",
"suspicious_pipeline_execution"
)
)

AND NOT RunnerSuspiciousExecution.TgtProcCmdLine CONTAINS ANY (
"approved_build_script",
"approved_release_automation",
"approved_package_publication",
"approved_container_build",
"approved_iac_deployment",
"approved_security_testing",
"approved_incident_response"
)

Rule

CI/CD Runner Credential, Token, or Secret Access Followed by Registry or Cloud Tooling

Rule Format

SentinelOne endpoint credential-to-control-plane correlation rule suitable for Deep Visibility telemetry, process telemetry, command-line telemetry, Storyline context, file telemetry, registry client execution telemetry, cloud CLI execution telemetry, Kubernetes CLI execution telemetry, network telemetry, DNS enrichment, runner inventory, build-host inventory, suspicious workflow enrichment, identity enrichment, cloud enrichment, registry enrichment, and SIEM correlation after credential-access validation, token-access validation, runner-host validation, downstream-tool validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect credential, token, secret, environment-variable, cloud credential, registry credential, package credential, Kubernetes credential, or signing-material access on CI/CD runners or build hosts followed by registry tooling, cloud tooling, Kubernetes tooling, package tooling, or external transfer behavior.

·        Identify a post-workflow path where trusted CI/CD execution may expose secrets and then use them for registry access, package access, cloud API activity, Kubernetes API activity, deployment activity, or downstream environment interaction.

·        Prioritize behavior involving protected variables, CI/CD secrets, deploy credentials, registry tokens, package tokens, signing keys, cloud credentials, Kubernetes configuration files, SSH keys, or service-account credentials.

·        Support escalation when credential or token access aligns with workflow modification, suspicious pipeline execution, runner registration, runner tag changes, token creation, deploy-key creation, webhook modification, protected-branch changes, or unusual outbound communication.

·        Preserve separation between suspicious credential access and confirmed credential theft by requiring supporting endpoint, Git, CI/CD, identity, registry, network, cloud, Kubernetes, or incident-response evidence before classifying compromise as confirmed.

·        This rule does not prove repository compromise, credential theft, token theft, cloud compromise, registry compromise, Kubernetes compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify endpoint behavior on CI/CD runners, build hosts, Git platform hosts, or deployment automation systems involving credential access, token access, secret access, environment-variable inspection, protected-variable exposure, credential-file access, secret-store access, or signing-material access.

·        Prioritize access to cloud credential files, Docker credential files, Kubernetes configuration files, package-manager credential files, SSH private keys, signing keys, service-account credentials, CI/CD environment variables, protected variables, secret files, or locally relevant credential stores.

·        Detect follow-on execution involving registry clients, package managers, cloud CLIs, Kubernetes CLIs, deployment tools, secret-management tools, source-code tools, container tooling, network transfer utilities, or API tooling.

·        Correlate credential or token access with suspicious workflow context, including recent workflow modification, suspicious pipeline execution, runner registration, runner tag change, token creation, deploy-key creation, webhook modification, OAuth application creation, or protected-branch control change.

·        Increase confidence when credential or token access and downstream tooling occur in the same SentinelOne Storyline, same process tree, same user context, same runner workspace, same CI/CD job window, or same incident timeline.

·        Increase confidence when follow-on activity includes registry authentication, image push, package publication, cloud role discovery, cloud API calls, Kubernetes API interaction, secret-manager access, artifact access, deployment execution, or outbound transfer.

·        Increase confidence when the affected runner or build host is associated with sensitive repositories, production deployment, package publication, image publication, signing workflows, infrastructure-as-code, cloud deployment, Kubernetes deployment, or high-value build paths.

·        Reduce severity when activity matches approved build scripts, expected deployment workflows, package-publication workflows, container-build workflows, infrastructure deployment, secret-manager integration, incident response, vulnerability scanning, or documented change-control activity.

·        Do not classify credential or token access as theft without follow-on use, staging, exfiltration, unauthorized access, or incident-response validation.

·        Do not treat environment-variable inspection, cloud CLI use, Kubernetes CLI use, registry client use, or package-manager activity as compromise evidence by itself.

Required Telemetry

·        SentinelOne Deep Visibility telemetry.

·        Process creation telemetry.

·        Command-line telemetry.

·        Parent process and grandparent process.

·        SentinelOne Storyline context.

·        File creation telemetry.

·        File modification telemetry.

·        File access telemetry where available.

·        Network connection telemetry.

·        DNS enrichment where available.

·        User identity.

·        Service-account identity where available.

·        Device identity.

·        Hostname.

·        Process path.

·        Process hash.

·        Process signer and certificate metadata.

·        Working directory.

·        Timestamp.

·        Credential-access behavior indicators.

·        Token-access behavior indicators.

·        Secret-file access telemetry where available.

·        Environment-variable inspection telemetry where available.

·        Cloud CLI execution telemetry.

·        Kubernetes CLI execution telemetry.

·        Registry client execution telemetry.

·        Package-manager execution telemetry.

·        Container tooling telemetry.

·        Secret-management tooling telemetry where available.

·        CI/CD runner inventory.

·        Build-host inventory.

·        Repository sensitivity enrichment where available.

·        Suspicious workflow enrichment where available.

·        CI/CD job timing enrichment where available.

·        Registry enrichment where available.

·        Cloud enrichment where available.

·        Kubernetes enrichment where available.

·        Identity-provider enrichment where available.

·        Approved build workflow records.

·        Approved deployment workflow records.

·        Approved package publication records.

·        Approved container build records.

·        Approved secret-management integration records.

·        Approved incident-response records.

·        Change-control records.

Engineering Implementation Instructions

·        Build credential-access groups covering environment-variable inspection, protected-variable exposure, secret-file access, cloud credential file access, Docker credential file access, Kubernetes configuration file access, package-manager credential file access, SSH private-key access, signing-key access, service-account credential access, token access, secret-store access, and locally relevant credential-store access.

·        Build downstream tooling groups covering registry clients, package managers, cloud CLIs, Kubernetes CLIs, deployment tools, secret-management tools, source-code tools, container tooling, network transfer utilities, and API tools.

·        Build sensitive credential groups for deploy credentials, registry tokens, package tokens, signing material, cloud credentials, Kubernetes credentials, CI/CD variables, protected variables, SSH keys, service-account credentials, and workload identity artifacts.

·        Build suspicious workflow context groups using Git audit logs, CI/CD logs, runner metadata, identity logs, NDR telemetry, registry logs, package logs, cloud logs, Kubernetes logs, and SIEM context that identifies workflow modification, suspicious pipeline execution, new runner registration, runner tag change, token creation, deploy-key creation, webhook modification, OAuth application creation, protected-branch change, or release-control change.

·        Build follow-on behavior groups for registry authentication, image push, package publication, cloud role discovery, cloud API activity, Kubernetes API interaction, secret-manager access, artifact access, deployment execution, outbound transfer, and SentinelOne behavioral indicators.

·        Validate SentinelOne field availability for process ancestry, command line, Storyline ID, file access, file writes, network connections, user identity, service-account identity, device identity, and timestamp.

·        Validate SIEM joins between SentinelOne telemetry, Git audit logs, CI/CD logs, NDR telemetry, identity logs, registry logs, package logs, cloud logs, Kubernetes logs, deployment logs, and incident-response evidence.

·        Use short correlation windows when credential access and downstream tooling occur in the same CI/CD job window or SentinelOne Storyline.

·        Use moderate correlation windows when credential access follows workflow modification, runner changes, token creation, deploy-key creation, webhook modification, or suspicious pipeline execution.

·        Use longer correlation windows only when Storyline continuity, CI/CD lineage, identity evidence, endpoint evidence, cloud evidence, registry evidence, or incident-response evidence supports delayed linkage.

·        Add severity weighting for sensitive credential type, production deployment access, signing authority, package publication authority, image publication authority, cloud deployment authority, Kubernetes deployment authority, registry authentication, package publication, image push, cloud API use, Kubernetes API use, and secret-manager access.

·        Treat credential or token access as a confidence amplifier unless it is linked to follow-on use, staging, exfiltration, unauthorized access, or incident-response validation.

·        Build allowlists for approved build scripts, secret-manager integrations, package publication, container builds, infrastructure deployment, cloud operations, Kubernetes operations, vulnerability scanning, security testing, incident response, and known automation.

·        Do not enable alert mode until credential-access validation, token-access validation, downstream-tool validation, CI/CD context enrichment, Storyline correlation, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and endpoint-response workflow requirements are validated.

DRI Assessment

DRI

8.3 / 10

·        The rule is behaviorally anchored to durable credential, token, secret, and downstream-tooling behavior rather than static hashes, domains, IP addresses, package names, image names, repository names, or CVE identifiers.

·        The rule remains useful if an adversary changes credential target, token source, file path, command syntax, runner host, registry client, cloud CLI, Kubernetes CLI, package manager, transfer utility, or timing.

·        The score is supported by the durability of credential access followed by registry authentication, package publication, image push, cloud API use, Kubernetes API use, secret-manager access, deployment tooling, or outbound transfer.

·        The score is constrained by legitimate secret-manager integrations, expected deployment workflows, approved package-publication jobs, incomplete file-access telemetry, incomplete token telemetry, noisy CI/CD variables, and shared runner environments.

·        The rule is durable as endpoint credential-use coverage but should not be treated as standalone proof of credential theft, token theft, cloud compromise, registry compromise, or actor attribution.

TCR Assessment

Operational TCR

7.6 / 10

Full-Telemetry TCR

8.8 / 10

·        Operational confidence depends on SentinelOne process telemetry, command-line visibility, Storyline continuity, file-access telemetry, CI/CD job timing, suspicious workflow enrichment, runner identity, registry enrichment, cloud enrichment, and SIEM correlation quality.

·        Operational confidence is reduced where environment-variable inspection is normal, secret-manager integrations are noisy, command lines are truncated, file-access telemetry is limited, or downstream registry and cloud events cannot be joined.

·        Operational confidence is reduced in deployment, package-publication, cloud operations, Kubernetes operations, DevOps, security testing, and incident-response workflows where credential and tooling behavior may be legitimate.

·        Full-telemetry confidence improves when SentinelOne telemetry is enriched with Git audit logs, CI/CD logs, NDR telemetry, registry logs, package logs, cloud logs, Kubernetes logs, identity logs, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support endpoint-to-control-plane triage and exposure scoping rather than standalone confirmation of compromise.

Limitations

·        SentinelOne cannot independently confirm that accessed credentials were successfully exfiltrated or abused without downstream registry, cloud, Kubernetes, network, identity, or incident-response evidence.

·        Credential access, environment-variable inspection, registry client use, cloud CLI use, Kubernetes CLI use, and package-manager activity may be normal in CI/CD environments.

·        Missing file-access telemetry, incomplete command-line telemetry, weak Storyline continuity, or missing downstream enrichment can reduce confidence.

·        Shared runners, broad CI/CD variables, and approved deployment jobs can increase noise.

·        The rule may miss credential theft that occurs through platform-native variable exposure without observable host-level file or process artifacts.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

SentinelOne Deep Visibility CI/CD credential and downstream-tooling query pattern requiring tenant syntax validation, credential-access validation, token-access validation, runner-host validation, downstream-tool validation, CI/CD context validation, suspicious workflow enrichment validation, Storyline validation, approved workflow allowlisting, timing-window tuning, and environment-specific false-positive testing before production deployment.

SentinelOneEndpointEvent AS RunnerCredentialOrTokenActivity

WHERE RunnerCredentialOrTokenActivity.AgentComputerName IN ASSET_GROUP (
"CI/CD Runners",
"Build Hosts",
"Git Platform Hosts",
"Release Automation Systems",
"Deployment Automation Systems"
)

AND RunnerCredentialOrTokenActivity.EventType IN ANY (
"Process Creation",
"Process Execution",
"File Access",
"File Creation",
"File Modification",
"Script Execution",
"Network Connection",
"Behavioral Indicator",
"Storyline Process Event"
)

AND (
RunnerCredentialOrTokenActivity.TgtProcCmdLine CONTAINS ANY (
"printenv",
"env",
"cat /proc/self/environ",
"credential",
"token",
"secret",
"password",
"private_key",
"id_rsa",
"kubeconfig",
".aws/credentials",
".azure",
"gcloud",
".docker/config.json",
".npmrc",
".pypirc",
"settings.xml",
"signing",
"deploy_key",
"service_account"
)

OR RunnerCredentialOrTokenActivity.TgtFilePath CONTAINS ANY (
".aws/credentials",
".docker/config.json",
".npmrc",
".pypirc",
"kubeconfig",
"id_rsa",
"id_ed25519",
"service_account",
"credentials",
"secrets",
"tokens",
"signing"
)

OR RunnerCredentialOrTokenActivity.BehavioralIndicator IN ANY (
"Credential Access Behavior",
"Token Access",
"Secret Access",
"Environment Variable Inspection",
"Protected Variable Exposure",
"Cloud Credential Access",
"Kubernetes Credential Access",
"Registry Credential Access"
)
)

AND EVENT_NEAR WITHIN ENV_DOWNSTREAM_TOOL_WINDOW (
SentinelOneEndpointEvent AS DownstreamToolUse
WHERE DownstreamToolUse.AgentComputerName IN SAME_DEVICE(RunnerCredentialOrTokenActivity.AgentComputerName)
AND DownstreamToolUse.StorylineId IN SAME_STORYLINE_OR_TIME_WINDOW(RunnerCredentialOrTokenActivity.StorylineId)
AND (
DownstreamToolUse.TgtProcName IN ANY (
"docker",
"kubectl",
"helm",
"aws",
"az",
"gcloud",
"npm",
"yarn",
"pnpm",
"pip",
"twine",
"git",
"curl",
"wget"
)

OR DownstreamToolUse.TgtProcCmdLine CONTAINS ANY (
"docker login",
"docker push",
"kubectl",
"helm",
"aws sts",
"aws secretsmanager",
"aws ecr",
"az acr",
"az keyvault",
"gcloud auth",
"gcloud secrets",
"artifact registry",
"npm publish",
"twine upload",
"git clone",
"curl",
"wget"
)
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_CICD_CHANGE_WINDOW (
CICDOrGitEvent AS SuspiciousAutomationContext
WHERE SuspiciousAutomationContext.RepositoryOrRunner IN SAME_REPOSITORY_OR_RUNNER(RunnerCredentialOrTokenActivity.AgentComputerName)
AND SuspiciousAutomationContext.EventPattern IN ANY (
"recent_workflow_change",
"recent_runner_registration",
"recent_runner_tag_change",
"recent_token_creation",
"recent_deploy_key_creation",
"recent_webhook_change",
"recent_oauth_application_creation",
"recent_protected_branch_change",
"suspicious_pipeline_execution"
)
)

AND NOT RunnerCredentialOrTokenActivity.TgtProcCmdLine CONTAINS ANY (
"approved_secret_manager_integration",
"approved_deployment_workflow",
"approved_package_publication",
"approved_container_build",
"approved_cloud_operation",
"approved_kubernetes_operation",
"approved_security_testing",
"approved_incident_response"
)

Rule

Runner Host Persistence or Unauthorized Configuration Change After Suspicious CI/CD Activity

Rule Format

SentinelOne endpoint runner-persistence correlation rule suitable for Deep Visibility telemetry, process telemetry, command-line telemetry, Storyline context, file telemetry, service telemetry, scheduled task telemetry, startup modification telemetry, SSH key telemetry, runner configuration telemetry, network telemetry, runner inventory, build-host inventory, suspicious workflow enrichment, identity enrichment, and SIEM correlation after persistence validation, runner-configuration validation, CI/CD context validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect persistence attempts, unauthorized configuration changes, runner tampering, service creation, scheduled task creation, startup modification, unauthorized SSH key placement, suspicious credential-helper modification, or runner configuration changes on CI/CD runners or build hosts after suspicious repository or CI/CD activity.

·        Identify behavior that may preserve attacker access to trusted software-delivery infrastructure after workflow abuse, credential exposure, malicious job execution, or runner compromise.

·        Prioritize persistence behavior on self-hosted runners, shared runners, persistent runners, privileged runners, deployment automation systems, Git platform hosts, and build systems associated with sensitive repositories or production workflows.

·        Support escalation when persistence or configuration activity follows workflow modification, suspicious pipeline execution, runner registration, runner tag changes, token creation, deploy-key creation, webhook modification, credential access, unusual outbound communication, or registry activity.

·        Preserve separation between suspicious persistence and confirmed compromise by requiring supporting endpoint, Git, CI/CD, runner, identity, network, registry, cloud, Kubernetes, or incident-response evidence before classifying compromise as confirmed.

·        This rule does not prove repository compromise, credential theft, token theft, runner compromise, cloud compromise, Kubernetes compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify persistence or configuration activity on CI/CD runners, build hosts, Git platform hosts, registry hosts, package services, release automation systems, or deployment automation systems.

·        Detect scheduled task creation, new service creation, service modification, startup script modification, shell-profile modification, unauthorized SSH key placement, runner configuration modification, credential-helper modification, new agent installation, or suspicious executable persistence.

·        Prioritize persistence activity occurring after suspicious CI/CD execution, workflow modification, runner registration, runner tag change, token creation, deploy-key creation, webhook modification, credential access, unusual outbound communication, registry access, or package activity.

·        Prioritize changes involving runner service accounts, runner configuration directories, CI/CD workspace paths, deployment automation paths, Git platform service paths, registry service paths, SSH directories, startup locations, system service directories, or scheduled task locations.

·        Increase confidence when SentinelOne Storyline context links persistence activity to suspicious shell execution, credential access, file staging, network transfer, registry client use, cloud CLI use, Kubernetes CLI use, or unusual child-process behavior.

·        Increase confidence when the affected host is associated with sensitive repositories, shared runner scope, privileged execution, persistent workspaces, Docker socket access, internal network reach, production deployment, package publication, image publication, signing workflows, or infrastructure-as-code workflows.

·        Increase confidence when the persistence behavior is followed by recurring outbound communication, repeated runner activity, suspicious job execution, unauthorized access to internal services, or downstream registry, cloud, or Kubernetes activity.

·        Reduce severity when activity matches approved runner installation, runner upgrade, runner migration, configuration management, patching, endpoint-management activity, release engineering, incident response, or documented change-control activity.

·        Do not classify runner persistence or configuration change as compromise without suspicious CI/CD, identity, endpoint, network, registry, cloud, Kubernetes, or incident-response linkage.

·        Do not treat runner configuration changes, service creation, scheduled tasks, or SSH key changes as compromise evidence by themselves.

Required Telemetry

·        SentinelOne Deep Visibility telemetry.

·        Process creation telemetry.

·        Command-line telemetry.

·        Parent process and grandparent process.

·        SentinelOne Storyline context.

·        File creation telemetry.

·        File modification telemetry.

·        File execution telemetry.

·        Service creation telemetry where available.

·        Service modification telemetry where available.

·        Scheduled task telemetry where available.

·        Startup modification telemetry where available.

·        Shell-profile modification telemetry where available.

·        SSH key placement telemetry where available.

·        Runner configuration file telemetry where available.

·        Credential-helper modification telemetry where available.

·        Network connection telemetry.

·        DNS enrichment where available.

·        User identity.

·        Service-account identity where available.

·        Device identity.

·        Hostname.

·        Process path.

·        Process hash.

·        Process signer and certificate metadata.

·        Working directory.

·        Timestamp.

·        CI/CD runner inventory.

·        Build-host inventory.

·        Git platform host inventory.

·        Registry host inventory.

·        Deployment automation inventory.

·        Runner configuration path inventory where available.

·        Runner service account inventory where available.

·        Repository sensitivity enrichment where available.

·        Suspicious workflow enrichment where available.

·        CI/CD job timing enrichment where available.

·        Runner registration or runner tag enrichment where available.

·        Token, deploy-key, webhook, credential-access, or registry enrichment where available.

·        Approved runner installation records.

·        Approved runner migration records.

·        Approved runner upgrade records.

·        Approved configuration management records.

·        Approved patching records.

·        Approved endpoint-management records.

·        Approved incident-response records.

·        Change-control records.

Engineering Implementation Instructions

·        Build host groups covering self-hosted runners, shared runners, persistent runners, privileged runners, build hosts, Git platform hosts, registry hosts, package services, release automation systems, and deployment automation systems.

·        Build persistence groups covering scheduled task creation, service creation, service modification, startup script modification, shell-profile modification, SSH key placement, unauthorized agent installation, suspicious executable persistence, credential-helper modification, and local account or service-account modification where visible.

·        Build runner-configuration groups covering runner configuration files, runner service directories, runner workspace paths, CI/CD cache paths, artifact directories, deployment automation paths, Git platform service paths, registry service paths, and locally observed runner-control paths.

·        Build suspicious CI/CD context groups using Git audit logs, CI/CD logs, runner metadata, identity logs, NDR telemetry, registry logs, package logs, cloud logs, Kubernetes logs, and SIEM context that identifies workflow modification, suspicious pipeline execution, runner registration, runner tag change, token creation, deploy-key creation, webhook modification, credential access, registry activity, or unusual outbound communication.

·        Build follow-on behavior groups for recurring outbound communication, repeated runner execution, unauthorized internal service access, registry access, package access, cloud API use, Kubernetes API use, deployment activity, and SentinelOne behavioral indicators.

·        Validate SentinelOne field availability for process ancestry, command line, Storyline ID, file activity, service creation, scheduled tasks, startup modifications, SSH key writes, runner configuration file changes, network connections, user identity, service-account identity, device identity, and timestamp.

·        Validate SIEM joins between SentinelOne telemetry, Git audit logs, CI/CD logs, runner metadata, NDR telemetry, identity logs, registry logs, package-service logs, cloud logs, Kubernetes logs, deployment logs, and incident-response evidence.

·        Use short correlation windows when persistence activity occurs during or immediately after suspicious CI/CD execution.

·        Use moderate correlation windows when persistence activity follows workflow modification, runner registration, runner tag change, token creation, deploy-key creation, webhook modification, credential access, or unusual outbound communication.

·        Use longer correlation windows only when SentinelOne Storyline continuity, CI/CD lineage, identity evidence, endpoint evidence, repeated runner activity, or incident-response evidence supports delayed linkage.

·        Add severity weighting for privileged runner context, shared runner scope, persistent workspace access, Docker socket access, internal network reach, sensitive repository association, production deployment access, package publication authority, signing authority, recurring outbound communication, and follow-on registry or cloud activity.

·        Treat persistence or configuration changes as confidence amplifiers unless linked to suspicious CI/CD, endpoint, identity, network, registry, cloud, Kubernetes, or incident-response evidence.

·        Build allowlists for approved runner installation, runner upgrades, runner migration, configuration management, patching, endpoint management, release engineering, vulnerability management, incident response, and known automation.

·        Do not enable alert mode until persistence validation, runner configuration validation, CI/CD context enrichment, Storyline correlation, field availability, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and endpoint-response workflow requirements are validated.

DRI Assessment

DRI

7.9 / 10

·        The rule is behaviorally anchored to durable persistence and runner-configuration behavior rather than static hashes, domains, IP addresses, package names, repository names, CVE identifiers, or one-off indicators.

·        The rule remains useful if an adversary changes persistence mechanism, service name, scheduled task name, runner path, startup location, SSH key name, staging directory, runner host, or timing.

·        The score is supported by the durability of scheduled task creation, service creation, startup modification, SSH key placement, credential-helper modification, runner configuration changes, and unauthorized agent behavior on runner or build infrastructure.

·        The score is constrained by legitimate runner installation, runner migration, runner upgrade, configuration management, patching, endpoint-management activity, and incomplete service or file telemetry.

·        The rule is durable as runner persistence coverage but should not be treated as standalone proof of repository workflow compromise, runner compromise, credential theft, or actor attribution.

TCR Assessment

Operational TCR

7.2 / 10

Full-Telemetry TCR

8.4 / 10

·        Operational confidence depends on SentinelOne process telemetry, Storyline continuity, file telemetry, service telemetry, scheduled task telemetry, runner configuration visibility, runner inventory, CI/CD context, and SIEM correlation quality.

·        Operational confidence is reduced where runner configuration changes are common, runner upgrades are frequent, configuration management tools modify runner hosts, or service and scheduled task telemetry is incomplete.

·        Operational confidence is reduced during runner migration, runner installation, platform modernization, patching, endpoint management, incident response, and release engineering activity.

·        Full-telemetry confidence improves when SentinelOne telemetry is enriched with Git audit logs, CI/CD logs, runner metadata, NDR telemetry, identity logs, registry logs, cloud logs, Kubernetes logs, deployment logs, and change-control records.

·        Even under full telemetry conditions, this rule should support endpoint triage and runner-containment decisions rather than standalone confirmation of compromise.

Limitations

·        SentinelOne cannot independently confirm that runner persistence was caused by repository workflow abuse without Git, CI/CD, identity, network, registry, cloud, Kubernetes, or incident-response context.

·        Runner installation, runner upgrade, runner migration, configuration management, and patching can create similar file, service, and scheduled task changes.

·        Missing file telemetry, missing service telemetry, incomplete process ancestry, weak Storyline continuity, or missing CI/CD enrichment can reduce confidence.

·        The rule may miss persistence implemented entirely through Git or CI/CD platform configuration rather than runner-host changes.

·        The rule may miss low-noise persistence that uses approved service names, approved automation paths, or expected configuration-management tooling.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

SentinelOne Deep Visibility runner persistence and unauthorized configuration query pattern requiring tenant syntax validation, endpoint field validation, runner-host validation, persistence validation, runner-configuration validation, CI/CD context validation, suspicious workflow enrichment validation, Storyline validation, approved operations allowlisting, timing-window tuning, and environment-specific false-positive testing before production deployment.

SentinelOneEndpointEvent AS RunnerPersistenceOrConfigChange

WHERE RunnerPersistenceOrConfigChange.AgentComputerName IN ASSET_GROUP (
"CI/CD Runners",
"Build Hosts",
"Git Platform Hosts",
"Registry Hosts",
"Package Services",
"Release Automation Systems",
"Deployment Automation Systems"
)

AND RunnerPersistenceOrConfigChange.EventType IN ANY (
"Process Creation",
"Process Execution",
"File Creation",
"File Modification",
"Service Created",
"Service Modified",
"Scheduled Task Created",
"Startup Modified",
"SSH Key Written",
"Configuration File Modified",
"Network Connection",
"Behavioral Indicator",
"Storyline Process Event"
)

AND (
RunnerPersistenceOrConfigChange.FilePath CONTAINS ANY (
"runner",
"gitlab-runner",
"actions-runner",
"gitea-runner",
"forgejo-runner",
".ssh",
"authorized_keys",
"systemd",
"init.d",
"cron",
"crontab",
"startup",
"profile",
"bashrc",
"zshrc",
"credential",
"config"
)

OR RunnerPersistenceOrConfigChange.TgtProcCmdLine CONTAINS ANY (
"systemctl enable",
"systemctl start",
"service ",
"crontab",
"scheduled task",
"schtasks",
"authorized_keys",
"ssh-rsa",
"ssh-ed25519",
"startup",
"profile",
"bashrc",
"zshrc",
"runner register",
"runner configure",
"credential helper",
"install service"
)

OR RunnerPersistenceOrConfigChange.BehavioralIndicator IN ANY (
"Persistence Attempt",
"Service Creation",
"Scheduled Task Creation",
"Startup Modification",
"SSH Key Placement",
"Configuration Change",
"Unauthorized Agent Deployment",
"Suspicious Child Process"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_CICD_CHANGE_WINDOW (
CICDOrGitEvent AS SuspiciousAutomationContext
WHERE SuspiciousAutomationContext.RepositoryOrRunner IN SAME_REPOSITORY_OR_RUNNER(RunnerPersistenceOrConfigChange.AgentComputerName)
AND SuspiciousAutomationContext.EventPattern IN ANY (
"recent_workflow_change",
"recent_runner_registration",
"recent_runner_tag_change",
"recent_token_creation",
"recent_deploy_key_creation",
"recent_webhook_change",
"recent_oauth_application_creation",
"recent_protected_branch_change",
"suspicious_pipeline_execution",
"credential_access_behavior",
"unusual_runner_egress"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_ENDPOINT_CONTEXT_WINDOW (
SentinelOneEndpointEvent AS RelatedSuspiciousExecution
WHERE RelatedSuspiciousExecution.AgentComputerName IN SAME_DEVICE(RunnerPersistenceOrConfigChange.AgentComputerName)
AND RelatedSuspiciousExecution.StorylineId IN SAME_STORYLINE_OR_TIME_WINDOW(RunnerPersistenceOrConfigChange.StorylineId)
AND RelatedSuspiciousExecution.BehavioralIndicator IN ANY (
"Credential Access Behavior",
"Token Access",
"Tool Staging",
"Archive Creation",
"Suspicious Network Transfer",
"Registry Client Execution",
"Cloud CLI Execution",
"Kubernetes CLI Execution"
)
)

AND NOT RunnerPersistenceOrConfigChange.TgtProcCmdLine CONTAINS ANY (
"approved_runner_installation",
"approved_runner_upgrade",
"approved_runner_migration",
"approved_configuration_management",
"approved_patching",
"approved_endpoint_management",
"approved_release_engineering",
"approved_incident_response"
)

Splunk

Detection Viability Assessment

Splunk has three rules for this EXP report.

·        Splunk is highly viable for detecting self-hosted Git platform compromise through repository workflow abuse because it can correlate Git audit logs, CI/CD pipeline logs, runner telemetry, endpoint telemetry, identity logs, NDR telemetry, DNS logs, proxy logs, registry logs, package-service logs, artifact-store logs, cloud logs, Kubernetes logs, and deployment logs.

·        Splunk is strongest where repository-control activity, workflow execution, runner behavior, credential or token activity, registry access, package access, artifact movement, endpoint process telemetry, network egress, and downstream cloud or Kubernetes activity are normalized into searchable fields and joined through repository, runner, user, host, token, workflow, pipeline, and timestamp context.

·        Splunk can identify multi-stage activity that begins with workflow modification, runner registration, token creation, deploy-key creation, webhook modification, OAuth application creation, protected-branch change, or suspicious pipeline execution and continues into runner execution, credential exposure, registry activity, outbound communication, deployment activity, or cloud-control-plane behavior.

·        Splunk is not a standalone source for confirming compromise unless the required data sources are present and joined reliably. Correlation quality depends on field mapping, sourcetypes, index coverage, parser quality, timestamp consistency, asset inventory, identity enrichment, repository sensitivity mapping, and change-control context.

·        Splunk detections must avoid treating single events as confirmed compromise. Workflow changes, runner events, token creation, registry access, outbound communication, cloud API activity, or endpoint execution should be treated as correlation anchors and confidence amplifiers unless multiple stages of the attack chain are visible.

·        Splunk detection content should support SOC triage, exposure scoping, lineage reconstruction, and high-confidence escalation where repository, CI/CD, runner, credential, registry, endpoint, network, and downstream-control-plane telemetry align.

·        Splunk rules should not generate high-confidence alerting from a workflow change alone, token creation alone, runner execution alone, registry access alone, cloud API activity alone, endpoint process activity alone, or unusual outbound communication alone without supporting lineage and context.

Rule

Repository Workflow Modification Followed by Suspicious CI/CD Runner Execution

Rule Format

Splunk multi-source correlation rule suitable for Git audit logs, CI/CD pipeline logs, runner telemetry, endpoint process telemetry, identity logs, NDR telemetry, DNS logs, proxy logs, repository sensitivity enrichment, runner inventory, workflow metadata, and change-control context after sourcetype validation, field mapping, timing-window tuning, repository sensitivity mapping, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious repository workflow modification followed by CI/CD pipeline execution and runner-host behavior consistent with workflow abuse.

·        Identify cases where trusted repository automation may be modified to execute unauthorized logic, inspect secrets, stage artifacts, retrieve payloads, run network transfer utilities, or trigger downstream build and deployment activity.

·        Prioritize workflow changes involving sensitive repositories, protected branches, production deployment workflows, package-publishing workflows, container-build workflows, signing workflows, infrastructure-as-code workflows, cloud deployment workflows, or Kubernetes deployment workflows.

·        Support escalation when a workflow change is followed by suspicious runner execution, credential inspection, environment-variable access, archive creation, outbound communication, registry access, package access, or cloud and Kubernetes tooling.

·        Preserve separation between suspicious workflow activity and confirmed compromise by requiring supporting CI/CD, runner, endpoint, network, registry, identity, cloud, Kubernetes, or incident-response evidence before classifying activity as probable compromise.

·        This rule does not prove repository compromise, credential theft, malicious package publication, image compromise, cloud compromise, Kubernetes compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify creation, modification, deletion, or permission changes affecting repository workflow files, CI/CD configuration files, build scripts, deployment scripts, release scripts, package-publishing scripts, container-build definitions, or infrastructure-as-code workflow paths.

·        Prioritize workflow changes made by newly privileged users, inactive users, unfamiliar maintainers, external contributors, unfamiliar bot accounts, service accounts, or accounts authenticating from unusual source infrastructure.

·        Correlate workflow changes with CI/CD pipeline execution, job execution, runner assignment, workflow execution, release execution, package-publishing execution, container-build execution, infrastructure-as-code execution, or deployment execution from the same repository, branch, merge request, project, group, runner, or workflow.

·        Detect suspicious runner or build-host execution involving shell interpreters, scripting engines, package managers, archive utilities, network transfer utilities, cloud CLIs, Kubernetes CLIs, registry clients, container tooling, credential helpers, or secret-management tooling.

·        Prioritize command lines involving environment-variable inspection, protected-variable exposure, credential-location probing, secret-file access, direct IP access, remote retrieval, encoded execution, archive creation, recursive repository collection, artifact staging, cache access, or external transfer.

·        Increase confidence when the workflow activity involves sensitive repositories, protected branches, production release workflows, signing workflows, package publication, image publication, infrastructure-as-code, cloud deployment, Kubernetes deployment, or high-value build paths.

·        Increase confidence when runner execution is followed by outbound communication, registry access, package access, artifact access, cloud API activity, Kubernetes API activity, deployment activity, or unusual internal service access.

·        Reduce severity when activity matches approved release engineering, planned workflow refactoring, CI/CD migration, authorized runner migration, approved package-publication changes, infrastructure deployment, vulnerability scanning, security testing, incident response, or documented change-control activity.

·        Do not classify workflow modification as compromise without suspicious execution, credential behavior, registry behavior, network behavior, downstream control-plane behavior, or incident-response validation.

·        Do not treat workflow modification, job execution, runner assignment, or shell execution as compromise evidence by itself.

Required Telemetry

·        Git audit logs.

·        Repository activity logs.

·        Commit metadata.

·        Merge request or pull request metadata.

·        Protected-branch logs.

·        Approval-rule logs where available.

·        CODEOWNERS or review-control change logs where available.

·        CI/CD pipeline logs.

·        CI/CD job logs.

·        Runner assignment logs.

·        Runner tag logs.

·        Runner registration logs where available.

·        Workflow execution logs.

·        Build script execution context.

·        Endpoint process telemetry from runners and build hosts.

·        Command-line telemetry from runners and build hosts.

·        Parent process and process lineage where available.

·        File creation and file modification telemetry where available.

·        NDR telemetry.

·        DNS logs.

·        Proxy logs where available.

·        Firewall logs where available.

·        Registry logs where available.

·        Package-service logs where available.

·        Artifact-store logs where available.

·        Cloud audit logs where available.

·        Kubernetes audit logs where available.

·        Identity logs.

·        User identity.

·        Service-account identity where available.

·        Source IP.

·        Source ASN and source geography where available.

·        Repository name.

·        Project or group.

·        Branch.

·        Workflow file path.

·        Pipeline ID.

·        Job ID.

·        Runner ID.

·        Runner host.

·        Runner tag.

·        Commit hash where available.

·        Timestamp.

·        Repository sensitivity enrichment.

·        Runner inventory.

·        Approved workflow-change baselines.

·        Approved release records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build Git workflow-change event groups covering workflow file modification, CI/CD configuration changes, build-script changes, deployment-script changes, release-script changes, package-publishing workflow changes, container-build workflow changes, protected-branch changes, approval-rule changes, and review-control changes.

·        Build CI/CD execution groups covering pipeline execution, job execution, workflow execution, runner assignment, runner tag use, release workflow execution, package-publishing workflow execution, container-build workflow execution, infrastructure-as-code workflow execution, and deployment workflow execution.

·        Build runner execution groups using endpoint telemetry for shell interpreters, scripting engines, package managers, archive utilities, transfer utilities, registry clients, container tooling, cloud CLIs, Kubernetes CLIs, credential helpers, and secret-management tools.

·        Build suspicious command groups for environment-variable inspection, protected-variable exposure, credential-location probing, secret-file access, archive creation, recursive collection, remote retrieval, direct IP use, encoded execution, suspicious command chaining, and external transfer.

·        Build repository sensitivity groups covering production deployment repositories, package-publishing repositories, image-publishing repositories, signing repositories, infrastructure-as-code repositories, cloud deployment repositories, Kubernetes deployment repositories, and high-value application repositories.

·        Build actor-risk groups for newly privileged users, inactive users, unfamiliar maintainers, external contributors, unfamiliar bot accounts, service accounts, unusual source infrastructure, rare geographies, and rare ASNs.

·        Validate Splunk index coverage, sourcetypes, field extractions, event timestamps, timezone normalization, user normalization, runner identity mapping, repository naming, pipeline ID mapping, job ID mapping, and host identity mapping.

·        Validate joins between Git audit logs, CI/CD logs, runner endpoint telemetry, identity logs, NDR telemetry, DNS logs, proxy logs, registry logs, cloud logs, Kubernetes logs, and deployment logs.

·        Use short correlation windows when workflow modification is followed immediately by pipeline execution or runner execution.

·        Use moderate correlation windows when workflow modification is followed by delayed runner execution, artifact movement, registry access, or outbound communication.

·        Use longer correlation windows only when CI/CD lineage, repeated runner behavior, identity evidence, registry evidence, cloud evidence, or incident-response evidence supports delayed linkage.

·        Add severity weighting for sensitive repository class, privileged actor, protected branch, suspicious runner command, credential inspection, external transfer, registry activity, cloud activity, Kubernetes activity, and change-control absence.

·        Treat workflow modification as a confidence anchor, not standalone proof of compromise.

·        Build allowlists for approved workflow refactoring, release engineering, runner migration, package-publication changes, infrastructure deployment, vulnerability scanning, security testing, incident response, and known automation.

·        Do not enable alert mode until sourcetype validation, field mapping, repository sensitivity enrichment, runner identity mapping, correlation reliability, false-positive rate, query performance, SOC triage workflow, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.6 / 10

·        The rule is behaviorally anchored to workflow modification followed by suspicious CI/CD execution rather than static indicators, CVE identifiers, package names, image names, repository names, domains, IP addresses, or hashes.

·        The rule remains useful if an adversary changes workflow filename, repository path, command syntax, runner host, package manager, cloud CLI, registry client, transfer utility, or timing.

·        The score is supported by the durability of repository-control activity followed by trusted automation execution, suspicious runner commands, credential inspection, artifact staging, registry access, and outbound communication.

·        The score is constrained by incomplete Git audit logs, missing CI/CD job detail, weak runner identity mapping, noisy workflow maintenance, incomplete endpoint telemetry, and inconsistent field normalization.

·        The rule is durable as a repository-to-runner correlation detector but should not be treated as standalone proof of credential theft, package compromise, cloud compromise, or actor attribution.

TCR Assessment

Operational TCR

7.8 / 10

Full-Telemetry TCR

9.0 / 10

·        Operational confidence depends on Git audit coverage, CI/CD log coverage, runner identity mapping, command-line visibility, repository sensitivity enrichment, identity enrichment, and Splunk join quality.

·        Operational confidence is reduced where workflow changes are frequent, CI/CD logs lack command detail, runner hosts are ephemeral, source data uses inconsistent field names, or change-control records are incomplete.

·        Operational confidence is reduced during release engineering, CI/CD refactoring, runner migration, repository migration, package-publication changes, and infrastructure deployment activity.

·        Full-telemetry confidence improves when Splunk correlates Git audit logs, CI/CD logs, runner endpoint telemetry, NDR telemetry, DNS logs, proxy logs, registry logs, package logs, cloud logs, Kubernetes logs, identity logs, and change-control records.

·        Even under full telemetry conditions, this rule should support escalation and scoping rather than standalone confirmation of compromise.

Limitations

·        Splunk cannot correlate this behavior unless Git, CI/CD, runner, endpoint, identity, and network data are ingested and mapped consistently.

·        Workflow changes may be legitimate during normal release engineering, CI/CD refactoring, repository migration, or infrastructure updates.

·        Runner execution may be noisy in high-change build environments.

·        Missing command-line telemetry, weak runner identity mapping, or inconsistent repository naming can reduce confidence.

·        The rule may miss workflow abuse that uses approved workflows, expected runner commands, low-noise credential access, or normal release paths.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Splunk repository workflow modification to suspicious runner execution query pattern requiring index validation, sourcetype validation, field extraction validation, repository identity mapping, runner identity mapping, timestamp normalization, CI/CD timing validation, approved workflow allowlisting, timing-window tuning, and environment-specific false-positive testing before production deployment.

GitAuditEvent AS WorkflowChange

WHERE WorkflowChange.action IN (
"workflow_file_created",
"workflow_file_modified",
"workflow_file_deleted",
"ci_config_modified",
"build_script_modified",
"deployment_script_modified",
"release_script_modified",
"protected_branch_changed",
"approval_rule_changed"
)

AND WorkflowChange.repository_sensitivity IN (
"production_deployment",
"package_publishing",
"image_publishing",
"signing",
"infrastructure_as_code",
"cloud_deployment",
"kubernetes_deployment",
"high_value_repository"
)

AND (
WorkflowChange.actor_context IN (
"newly_privileged_user",
"inactive_user",
"unfamiliar_maintainer",
"external_contributor",
"unfamiliar_bot_account",
"service_account",
"unusual_source_infrastructure"
)

OR WorkflowChange.source_context IN (
"rare_asn",
"unusual_geography",
"new_source_for_actor",
"source_not_in_actor_baseline"
)
)

AND EVENT_NEAR WITHIN ENV_WORKFLOW_TO_PIPELINE_WINDOW (
CICDEvent AS PipelineExecution
WHERE PipelineExecution.repository IN SAME_REPOSITORY(WorkflowChange.repository)
AND PipelineExecution.branch IN SAME_BRANCH_OR_RELATED_BRANCH(WorkflowChange.branch)
AND PipelineExecution.event_type IN (
"pipeline_executed",
"job_executed",
"workflow_executed",
"release_workflow_executed",
"package_publishing_workflow_executed",
"container_build_workflow_executed",
"iac_workflow_executed",
"deployment_workflow_executed"
)
)

AND EVENT_NEAR WITHIN ENV_PIPELINE_TO_RUNNER_WINDOW (
EndpointEvent AS RunnerExecution
WHERE RunnerExecution.host IN SAME_RUNNER(PipelineExecution.runner)
AND RunnerExecution.event_type IN (
"process_creation",
"script_execution",
"file_creation",
"network_connection",
"behavioral_indicator"
)
AND (
RunnerExecution.process_name IN (
"bash",
"sh",
"powershell.exe",
"pwsh.exe",
"cmd.exe",
"python",
"python3",
"node",
"ruby",
"perl",
"curl",
"wget",
"tar",
"zip",
"docker",
"kubectl",
"helm",
"aws",
"az",
"gcloud",
"git",
"npm",
"pip"
)

OR RunnerExecution.command_line CONTAINS ANY (
"printenv",
"cat /proc/self/environ",
"credential",
"token",
"secret",
"private_key",
"id_rsa",
"kubeconfig",
".aws/credentials",
".docker/config.json",
"archive",
"upload",
"artifact",
"cache",
"registry",
"docker login",
"kubectl config",
"aws sts",
"az account",
"gcloud auth"
)
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_RUNNER_FOLLOWON_WINDOW (
NetworkOrRegistryOrCloudEvent AS FollowOnActivity
WHERE FollowOnActivity.host IN SAME_HOST(RunnerExecution.host)
AND FollowOnActivity.event_pattern IN (
"unusual_outbound_communication",
"registry_authentication",
"package_access",
"artifact_access",
"image_push",
"cloud_api_activity",
"kubernetes_api_activity",
"deployment_activity"
)
)

AND NOT ChangeContext IN (
"approved_workflow_refactor",
"approved_release_engineering",
"approved_runner_migration",
"approved_package_publication_change",
"approved_iac_deployment",
"approved_security_testing",
"approved_incident_response"
)

Rule

Automation Credential Change Followed by Registry, Artifact, Deployment, or Cloud Activity

Rule Format

Splunk multi-source automation-credential correlation rule suitable for Git audit logs, CI/CD logs, identity logs, token lifecycle logs, deploy-key logs, webhook logs, OAuth application logs, service-account logs, runner logs, registry logs, package-service logs, artifact-store logs, deployment logs, cloud audit logs, Kubernetes audit logs, NDR telemetry, and SIEM correlation after sourcetype validation, field mapping, credential lineage validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect creation or modification of automation credentials followed by suspicious registry, artifact, deployment, cloud, Kubernetes, package, or repository activity.

·        Identify potential abuse of deploy keys, project access tokens, group access tokens, personal access tokens, OAuth applications, webhooks, service accounts, workload identities, runner tokens, or automation identities tied to sensitive repositories.

·        Prioritize automation credential changes involving sensitive repositories, production deployment paths, package-publishing authority, image-publishing authority, signing authority, infrastructure-as-code control, cloud deployment, Kubernetes deployment, or high-value build systems.

·        Support escalation when automation credential changes are followed by repository cloning, pipeline execution, artifact access, package access, image push, registry authentication, release modification, deployment activity, cloud API use, Kubernetes API use, or secret-manager access.

·        Preserve separation between suspicious automation credential activity and confirmed compromise by requiring supporting repository, CI/CD, identity, runner, registry, package, endpoint, cloud, Kubernetes, deployment, or incident-response evidence before classifying compromise as confirmed.

·        This rule does not prove credential theft, token theft, registry compromise, package compromise, cloud compromise, Kubernetes compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify creation, modification, scope expansion, permission change, or unusual use of deploy keys, project access tokens, group access tokens, personal access tokens, OAuth applications, webhooks, service accounts, workload identities, runner tokens, or automation identities.

·        Prioritize credential activity affecting sensitive repositories, protected branches, production deployment workflows, package-publishing workflows, image-publishing workflows, signing workflows, infrastructure-as-code workflows, cloud deployment workflows, Kubernetes deployment workflows, or release automation.

·        Prioritize credential activity performed by newly privileged users, inactive users, unfamiliar maintainers, unfamiliar bot accounts, service accounts, external contributors, or accounts authenticating from unusual source infrastructure.

·        Correlate automation credential changes with follow-on repository cloning, project export, pipeline execution, runner execution, artifact access, package access, image pull, image push, registry authentication, release modification, deployment activity, cloud API activity, Kubernetes API activity, or secret-manager access.

·        Increase confidence when follow-on activity occurs outside expected repository, runner, branch, project, group, time window, geography, source network, device, or deployment path.

·        Increase confidence when multiple automation credentials are created or modified in a short period or when credential scope is broader than expected for the repository or workflow.

·        Increase confidence when downstream activity is performed using the new or modified credential, a related automation identity, a related service account, or a source host associated with CI/CD infrastructure.

·        Reduce severity when the activity matches approved integration onboarding, token rotation, deploy-key maintenance, webhook maintenance, runner migration, service-account rotation, release engineering, cloud operations, security testing, incident response, or documented change-control activity.

·        Do not classify automation credential creation or modification as compromise without follow-on use, suspicious scope, actor-risk context, downstream activity, or incident-response validation.

·        Do not treat token creation, deploy-key creation, webhook creation, service-account changes, or OAuth application creation as compromise evidence by itself.

Required Telemetry

·        Git audit logs.

·        Repository access logs.

·        Deploy-key logs.

·        Token lifecycle logs.

·        Project access token logs.

·        Group access token logs.

·        Personal access token logs where available.

·        OAuth application logs.

·        Webhook logs.

·        Service-account logs.

·        Workload identity logs where available.

·        Runner registration logs.

·        Runner token logs where available.

·        CI/CD pipeline logs.

·        CI/CD job logs.

·        Runner telemetry.

·        Identity logs.

·        Registry logs.

·        Package-service logs.

·        Artifact-store logs.

·        Release-system logs.

·        Deployment logs.

·        Cloud audit logs where available.

·        Kubernetes audit logs where available.

·        NDR telemetry where available.

·        Endpoint telemetry where available.

·        Actor identity.

·        Token or credential identifier where available.

·        Credential scope.

·        Credential permission level.

·        Repository.

·        Project or group.

·        Branch.

·        Workflow.

·        Pipeline ID.

·        Runner ID.

·        Source IP.

·        Source ASN and source geography where available.

·        Destination service.

·        Action.

·        Result.

·        Timestamp.

·        Repository sensitivity enrichment.

·        Automation identity inventory.

·        Service-account inventory.

·        Approved token inventory.

·        Approved webhook inventory.

·        Approved deploy-key inventory.

·        Approved integration records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build automation credential event groups covering deploy-key creation, deploy-key modification, token creation, token scope change, token permission change, OAuth application creation, webhook creation, webhook modification, service-account creation, workload identity change, runner token activity, and automation identity changes.

·        Build sensitive repository and workflow groups covering production deployment, package publishing, image publishing, signing, infrastructure-as-code, cloud deployment, Kubernetes deployment, release automation, and high-value application repositories.

·        Build actor-risk groups covering newly privileged users, inactive users, unfamiliar maintainers, unfamiliar bot accounts, service accounts, external contributors, rare source geographies, rare ASNs, and unusual source networks.

·        Build follow-on activity groups covering repository cloning, project export, pipeline execution, runner execution, artifact access, package access, image pull, image push, registry authentication, release modification, deployment activity, cloud API activity, Kubernetes API activity, secret-manager access, and infrastructure changes.

·        Build credential-lineage groups that map credential identifier, automation identity, service account, runner token, project, group, repository, branch, pipeline, runner, source host, and downstream action where telemetry permits.

·        Validate Splunk index coverage, sourcetypes, field extraction, credential identifiers, token scope fields, webhook destination fields, service-account identifiers, repository names, project or group identifiers, timestamps, and join reliability.

·        Validate joins between Git audit logs, identity logs, CI/CD logs, registry logs, package logs, artifact logs, deployment logs, cloud logs, Kubernetes logs, NDR telemetry, endpoint telemetry, and incident-response evidence.

·        Use short correlation windows when credential creation or modification is followed immediately by pipeline execution, registry activity, repository access, or deployment activity.

·        Use moderate correlation windows for delayed package access, image activity, artifact access, cloud activity, Kubernetes activity, or deployment activity after credential changes.

·        Use longer correlation windows only when credential lineage, identity evidence, CI/CD evidence, cloud evidence, registry evidence, or incident-response evidence supports delayed linkage.

·        Add severity weighting for sensitive repository scope, broad credential permissions, privileged actor, unusual source infrastructure, new webhook destination, package publication authority, image publication authority, production deployment authority, cloud deployment authority, Kubernetes deployment authority, and follow-on use.

·        Treat automation credential changes as confidence anchors, not standalone proof of compromise.

·        Build allowlists for approved token rotation, deploy-key maintenance, webhook onboarding, integration onboarding, runner migration, service-account rotation, release engineering, cloud operations, security testing, incident response, and known automation.

·        Do not enable alert mode until credential lineage, token scope mapping, webhook validation, field availability, repository sensitivity enrichment, false-positive rate, query performance, SOC triage workflow, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.4 / 10

·        The rule is behaviorally anchored to automation credential changes followed by downstream use rather than static indicators, fixed token names, repository names, domains, IP addresses, package names, image names, or CVE identifiers.

·        The rule remains useful if an adversary changes credential type, token name, webhook destination, service account, repository path, runner host, registry endpoint, package, image, cloud service, or timing.

·        The score is supported by the durability of credential creation, scope expansion, webhook creation, OAuth application creation, service-account changes, and follow-on repository, registry, artifact, deployment, cloud, or Kubernetes activity.

·        The score is constrained by incomplete token lifecycle logging, missing credential identifiers, poor webhook visibility, weak service-account mapping, and legitimate integration onboarding or token rotation.

·        The rule is durable as automation credential lineage coverage but should not be treated as standalone proof of credential theft, cloud compromise, registry compromise, or actor attribution.

TCR Assessment

Operational TCR

7.7 / 10

Full-Telemetry TCR

8.9 / 10

·        Operational confidence depends on Git audit coverage, token lifecycle logging, deploy-key visibility, webhook visibility, service-account mapping, identity enrichment, downstream registry or cloud visibility, and Splunk join quality.

·        Operational confidence is reduced where token identifiers are masked, credential scope is unavailable, webhook destination logging is incomplete, service-account ownership is unclear, or downstream activity cannot be tied to the credential.

·        Operational confidence is reduced during integration onboarding, token rotation, deploy-key maintenance, service-account rotation, runner migration, release engineering, cloud operations, and incident-response activity.

·        Full-telemetry confidence improves when Splunk correlates credential lifecycle events with CI/CD logs, registry logs, package logs, artifact logs, endpoint telemetry, NDR telemetry, cloud logs, Kubernetes logs, identity logs, and change-control records.

·        Even under full telemetry conditions, this rule should support escalation and lineage reconstruction rather than standalone confirmation of compromise.

Limitations

·        Splunk cannot prove credential theft unless credential access, follow-on use, unauthorized activity, or incident-response evidence supports that conclusion.

·        Some Git and CI/CD platforms may mask token identifiers, reduce token lifecycle visibility, or omit webhook payload details.

·        Legitimate integration onboarding, token rotation, service-account rotation, and runner migration can resemble suspicious automation credential activity.

·        Weak credential lineage, inconsistent repository naming, incomplete service-account mapping, or missing downstream logs can reduce confidence.

·        The rule may miss abuse of existing long-lived credentials if no recent creation, modification, or scope change is visible.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Splunk automation credential change to downstream activity query pattern requiring index validation, sourcetype validation, credential identifier validation, token scope validation, webhook field validation, service-account mapping, downstream lineage validation, approved integration allowlisting, timing-window tuning, and environment-specific false-positive testing before production deployment.

GitOrIdentityEvent AS AutomationCredentialChange

WHERE AutomationCredentialChange.action IN (
"deploy_key_created",
"deploy_key_modified",
"project_token_created",
"group_token_created",
"personal_access_token_created",
"token_scope_changed",
"token_permission_changed",
"oauth_application_created",
"webhook_created",
"webhook_modified",
"service_account_created",
"service_account_modified",
"workload_identity_changed",
"runner_token_created",
"automation_identity_changed"
)

AND AutomationCredentialChange.repository_sensitivity IN (
"production_deployment",
"package_publishing",
"image_publishing",
"signing",
"infrastructure_as_code",
"cloud_deployment",
"kubernetes_deployment",
"high_value_repository"
)

AND (
AutomationCredentialChange.actor_context IN (
"newly_privileged_user",
"inactive_user",
"unfamiliar_maintainer",
"unfamiliar_bot_account",
"service_account",
"external_contributor",
"unusual_source_infrastructure"
)

OR AutomationCredentialChange.credential_context IN (
"broad_scope",
"long_expiration",
"privileged_scope",
"registry_scope",
"api_scope",
"write_scope",
"deployment_scope"
)
)

AND EVENT_NEAR WITHIN ENV_CREDENTIAL_TO_USE_WINDOW (
DownstreamEvent AS FollowOnCredentialUse
WHERE (
FollowOnCredentialUse.credential_id IN SAME_CREDENTIAL_OR_RELATED_IDENTITY(AutomationCredentialChange.credential_id)
OR FollowOnCredentialUse.actor IN SAME_AUTOMATION_IDENTITY(AutomationCredentialChange.actor)
OR FollowOnCredentialUse.repository IN SAME_REPOSITORY_OR_GROUP(AutomationCredentialChange.repository)
)
AND FollowOnCredentialUse.action IN (
"repository_cloned",
"project_exported",
"pipeline_executed",
"runner_executed",
"artifact_accessed",
"package_accessed",
"image_pulled",
"image_pushed",
"registry_authenticated",
"release_modified",
"deployment_executed",
"cloud_api_called",
"kubernetes_api_called",
"secret_manager_accessed",
"infrastructure_modified"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_DOWNSTREAM_ANOMALY_WINDOW (
SecurityEvent AS DownstreamAnomaly
WHERE DownstreamAnomaly.actor IN SAME_ACTOR_OR_AUTOMATION_IDENTITY(FollowOnCredentialUse.actor)
AND DownstreamAnomaly.event_pattern IN (
"outside_expected_repository",
"outside_expected_runner",
"outside_expected_branch",
"outside_expected_time_window",
"outside_expected_source_network",
"outside_expected_geography",
"outside_expected_deployment_path",
"multiple_credential_changes",
"multiple_sensitive_repositories_accessed"
)
)

AND NOT ChangeContext IN (
"approved_token_rotation",
"approved_deploy_key_maintenance",
"approved_webhook_onboarding",
"approved_integration_onboarding",
"approved_runner_migration",
"approved_service_account_rotation",
"approved_release_engineering",
"approved_cloud_operations",
"approved_security_testing",
"approved_incident_response"
)

Rule

Suspicious CI/CD Credential Use Followed by Cloud, Kubernetes, or Deployment Activity

Rule Format

Splunk multi-source CI/CD-to-control-plane correlation rule suitable for CI/CD logs, Git audit logs, identity logs, runner logs, endpoint telemetry, registry logs, cloud audit logs, Kubernetes audit logs, deployment logs, secret-manager logs, NDR telemetry, DNS logs, proxy logs, and SIEM correlation after identity mapping, credential lineage validation, source-network validation, control-plane action validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious use of CI/CD-linked credentials, automation identities, service accounts, workload identities, deploy accounts, cloud roles, or Kubernetes identities followed by cloud, Kubernetes, deployment, registry, secret-manager, or infrastructure activity.

·        Identify potential downstream expansion after repository workflow abuse, credential exposure, token exposure, runner compromise, malicious pipeline execution, or automation identity misuse.

·        Prioritize cloud, Kubernetes, deployment, and infrastructure actions that occur outside expected repository, branch, workflow, runner, source network, geography, project, namespace, region, account, subscription, tenant, or time window.

·        Support escalation when suspicious CI/CD credential use follows workflow modification, token creation, deploy-key creation, webhook modification, runner changes, suspicious runner execution, credential access, registry activity, or unusual outbound communication.

·        Preserve separation between suspicious downstream control-plane activity and confirmed compromise by requiring repository, CI/CD, identity, endpoint, network, registry, cloud, Kubernetes, deployment, or incident-response evidence before classifying compromise as confirmed.

·        This rule does not prove repository compromise, credential theft, cloud compromise, Kubernetes compromise, deployment compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify use of CI/CD-linked credentials, automation identities, service accounts, workload identities, deploy accounts, cloud roles, Kubernetes identities, package-publishing identities, image-publishing identities, or deployment identities.

·        Prioritize use outside expected repository, branch, workflow, runner, source network, geography, project, namespace, region, account, subscription, tenant, environment, deployment path, or approved time window.

·        Detect follow-on activity involving cloud API calls, IAM changes, role assignment, access-key creation, secret-manager access, container registry access, artifact access, Kubernetes API activity, deployment execution, infrastructure-as-code execution, storage access, function changes, workload changes, or release activity.

·        Correlate downstream activity with suspicious upstream context, including workflow modification, suspicious pipeline execution, new runner registration, runner tag change, token creation, deploy-key creation, webhook modification, OAuth application creation, protected-branch change, credential access, unusual outbound communication, or registry activity.

·        Increase confidence when the same identity, token, runner host, service account, workload identity, source IP, pipeline, repository, deployment account, or incident timeline connects upstream CI/CD activity to downstream control-plane activity.

·        Increase confidence when downstream actions modify identity, privileges, secrets, networking, storage, container images, deployment manifests, infrastructure templates, Kubernetes role bindings, image-pull secrets, or production workloads.

·        Increase confidence when control-plane activity is rare for the identity, new for the environment, outside the expected region or namespace, or inconsistent with the account’s normal role.

·        Reduce severity when activity matches approved deployment workflows, infrastructure deployment, cloud operations, Kubernetes operations, release engineering, package publication, image publication, vulnerability scanning, security testing, incident response, or documented change-control activity.

·        Do not attribute cloud, Kubernetes, or deployment activity to repository workflow compromise without identity, timing, runner, repository, credential, source-network, or incident-response linkage.

·        Do not treat cloud API activity, Kubernetes API activity, deployment activity, or registry activity as compromise evidence by itself.

Required Telemetry

·        CI/CD pipeline logs.

·        CI/CD job logs.

·        Runner logs.

·        Git audit logs.

·        Identity logs.

·        Service-account logs.

·        Workload identity logs where available.

·        Token lifecycle logs where available.

·        Endpoint telemetry from runners where available.

·        NDR telemetry where available.

·        DNS logs where available.

·        Proxy logs where available.

·        Registry logs.

·        Package-service logs where available.

·        Artifact-store logs where available.

·        Cloud audit logs.

·        Kubernetes audit logs.

·        Deployment platform logs.

·        Secret-manager logs where available.

·        Infrastructure-as-code execution logs where available.

·        User identity.

·        Automation identity.

·        Service-account identity.

·        Workload identity.

·        Credential identifier where available.

·        Runner ID.

·        Runner host.

·        Repository.

·        Branch.

·        Workflow.

·        Pipeline ID.

·        Job ID.

·        Source IP.

·        Source ASN and source geography where available.

·        Cloud account, project, subscription, tenant, or region.

·        Kubernetes cluster, namespace, service account, and role binding where available.

·        Deployment environment.

·        Resource action.

·        Result.

·        Timestamp.

·        Repository sensitivity enrichment.

·        CI/CD credential inventory.

·        Cloud identity inventory.

·        Kubernetes identity inventory.

·        Deployment account inventory.

·        Approved deployment records.

·        Approved cloud operation records.

·        Approved Kubernetes operation records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build CI/CD credential groups covering automation identities, service accounts, workload identities, deploy accounts, cloud roles, Kubernetes identities, package-publishing identities, image-publishing identities, and deployment identities.

·        Build downstream control-plane action groups covering cloud API calls, IAM changes, role assignment, access-key creation, secret-manager access, registry access, artifact access, Kubernetes API activity, deployment execution, infrastructure-as-code execution, storage access, function changes, workload changes, and release activity.

·        Build expected-use baselines by repository, branch, workflow, runner, source network, geography, project, namespace, region, account, subscription, tenant, environment, and deployment path.

·        Build upstream suspicious context groups using Git audit logs, CI/CD logs, runner metadata, endpoint telemetry, NDR telemetry, identity logs, registry logs, package logs, cloud logs, Kubernetes logs, and SIEM context that identifies workflow modification, suspicious pipeline execution, runner changes, token creation, deploy-key creation, webhook modification, credential access, unusual egress, or registry activity.

·        Build lineage logic mapping identity, credential, token, runner host, source IP, pipeline, repository, deployment account, service account, workload identity, and incident timeline.

·        Validate Splunk index coverage, sourcetypes, field extraction, identity normalization, service-account mapping, workload identity mapping, credential identifiers, source IP preservation, cloud project or subscription fields, Kubernetes namespace fields, deployment fields, and timestamp consistency.

·        Validate joins between CI/CD logs, Git audit logs, identity logs, endpoint telemetry, NDR telemetry, registry logs, package logs, cloud logs, Kubernetes logs, deployment logs, and incident-response evidence.

·        Use short correlation windows when downstream control-plane activity occurs during or immediately after suspicious CI/CD execution.

·        Use moderate correlation windows when downstream activity follows workflow modification, runner changes, token creation, credential access, unusual egress, or registry activity.

·        Use longer correlation windows only when identity lineage, cloud evidence, Kubernetes evidence, endpoint evidence, CI/CD lineage, or incident-response evidence supports delayed linkage.

·        Add severity weighting for privileged identity use, production deployment access, secret-manager access, IAM changes, role assignments, access-key creation, Kubernetes role binding changes, image-pull secret changes, production workload changes, sensitive storage access, and source-network mismatch.

·        Treat downstream control-plane activity as a confidence amplifier unless linked to suspicious CI/CD, credential, runner, identity, source-network, or incident-response evidence.

·        Build allowlists for approved deployment workflows, infrastructure deployment, cloud operations, Kubernetes operations, release engineering, package publication, image publication, vulnerability scanning, security testing, incident response, and known automation.

·        Do not enable alert mode until identity mapping, credential lineage, source-network validation, expected-use baselines, field availability, correlation reliability, false-positive rate, query performance, SOC triage workflow, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.5 / 10

·        The rule is behaviorally anchored to CI/CD credential use followed by cloud, Kubernetes, or deployment activity rather than static domains, IP addresses, hashes, repository names, package names, image names, or CVE identifiers.

·        The rule remains useful if an adversary changes workflow content, runner host, cloud service, Kubernetes namespace, deployment target, source infrastructure, credential type, tool sequence, or timing.

·        The score is supported by the durability of automation identity use, cloud API activity, Kubernetes API activity, deployment execution, secret-manager access, registry access, IAM changes, role assignments, and source-network mismatch.

·        The score is constrained by identity federation complexity, weak credential lineage, incomplete source IP preservation, noisy deployment activity, inconsistent cloud and Kubernetes logging, and legitimate automation workflows.

·        The rule is durable as CI/CD-to-control-plane correlation coverage but should not be treated as standalone proof of repository workflow compromise, credential theft, cloud compromise, Kubernetes compromise, or actor attribution.

TCR Assessment

Operational TCR

7.6 / 10

Full-Telemetry TCR

8.9 / 10

·        Operational confidence depends on CI/CD logs, identity logs, cloud audit logs, Kubernetes audit logs, deployment logs, credential lineage, source-network preservation, repository sensitivity mapping, and Splunk join quality.

·        Operational confidence is reduced where identity federation obscures the initiating repository, source IPs are transformed, cloud sessions are reused, workload identities are shared, or deployment logs lack pipeline context.

·        Operational confidence is reduced during normal infrastructure deployment, release engineering, cloud operations, Kubernetes operations, image publication, package publication, and incident-response activity.

·        Full-telemetry confidence improves when Splunk correlates CI/CD logs, Git audit logs, runner endpoint telemetry, NDR telemetry, registry logs, package logs, cloud logs, Kubernetes logs, identity logs, deployment logs, and change-control records.

·        Even under full telemetry conditions, this rule should support downstream exposure scoping and containment prioritization rather than standalone confirmation of compromise.

Limitations

·        Splunk cannot attribute cloud, Kubernetes, or deployment activity to repository workflow compromise without reliable identity, runner, repository, credential, source-network, or timing linkage.

·        Federated identity, workload identity, shared service accounts, NAT, proxying, cloud session reuse, and token reuse can obscure lineage.

·        Legitimate deployment workflows and cloud operations can closely resemble suspicious downstream activity.

·        Missing cloud logs, missing Kubernetes logs, weak source IP preservation, incomplete deployment logs, or inconsistent identity mapping can reduce confidence.

·        The rule may miss downstream abuse that uses expected deployment paths, approved identities, normal source networks, or delayed execution outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Splunk suspicious CI/CD credential use to cloud, Kubernetes, or deployment activity query pattern requiring index validation, sourcetype validation, identity mapping, credential lineage validation, source-network validation, cloud action validation, Kubernetes action validation, deployment lineage validation, approved workflow allowlisting, timing-window tuning, and environment-specific false-positive testing before production deployment.

CICDOrIdentityEvent AS SuspiciousCICDCredentialUse

WHERE SuspiciousCICDCredentialUse.identity_type IN (
"automation_identity",
"service_account",
"workload_identity",
"deploy_account",
"cloud_role",
"kubernetes_identity",
"package_publishing_identity",
"image_publishing_identity",
"deployment_identity"
)

AND (
SuspiciousCICDCredentialUse.use_context IN (
"outside_expected_repository",
"outside_expected_branch",
"outside_expected_workflow",
"outside_expected_runner",
"outside_expected_source_network",
"outside_expected_geography",
"outside_expected_time_window",
"outside_expected_deployment_path",
"rare_use_for_identity"
)

OR SuspiciousCICDCredentialUse.repository_sensitivity IN (
"production_deployment",
"package_publishing",
"image_publishing",
"signing",
"infrastructure_as_code",
"cloud_deployment",
"kubernetes_deployment",
"high_value_repository"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_CICD_UPSTREAM_CONTEXT_WINDOW (
CICDOrGitOrEndpointEvent AS UpstreamSuspiciousContext
WHERE UpstreamSuspiciousContext.repository IN SAME_REPOSITORY_OR_WORKFLOW(SuspiciousCICDCredentialUse.repository)
AND UpstreamSuspiciousContext.event_pattern IN (
"recent_workflow_change",
"suspicious_pipeline_execution",
"recent_runner_registration",
"recent_runner_tag_change",
"recent_token_creation",
"recent_deploy_key_creation",
"recent_webhook_change",
"credential_access_behavior",
"unusual_runner_egress",
"registry_activity"
)
)

AND EVENT_NEAR WITHIN ENV_CICD_TO_CONTROL_PLANE_WINDOW (
CloudKubernetesOrDeploymentEvent AS DownstreamControlPlaneActivity
WHERE DownstreamControlPlaneActivity.identity IN SAME_IDENTITY_OR_RELATED_WORKLOAD(SuspiciousCICDCredentialUse.identity)
AND DownstreamControlPlaneActivity.action IN (
"cloud_api_called",
"iam_changed",
"role_assigned",
"access_key_created",
"secret_manager_accessed",
"container_registry_accessed",
"artifact_accessed",
"kubernetes_api_called",
"deployment_executed",
"infrastructure_as_code_executed",
"storage_accessed",
"function_modified",
"workload_modified",
"release_modified"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_DOWNSTREAM_ANOMALY_WINDOW (
SecurityEvent AS DownstreamAnomaly
WHERE DownstreamAnomaly.identity IN SAME_IDENTITY(DownstreamControlPlaneActivity.identity)
AND DownstreamAnomaly.event_pattern IN (
"privileged_identity_use",
"production_environment_access",
"source_network_mismatch",
"region_mismatch",
"namespace_mismatch",
"secret_access",
"iam_privilege_change",
"kubernetes_role_binding_change",
"image_pull_secret_change",
"production_workload_change"
)
)

AND NOT ChangeContext IN (
"approved_deployment_workflow",
"approved_iac_deployment",
"approved_cloud_operations",
"approved_kubernetes_operations",
"approved_release_engineering",
"approved_package_publication",
"approved_image_publication",
"approved_security_testing",
"approved_incident_response"
)

Elastic

Detection Viability Assessment

Elastic has three rules for this EXP report.

·        Elastic is viable for detecting self-hosted Git platform compromise through repository workflow abuse where Git audit logs, CI/CD pipeline logs, runner host telemetry, endpoint process telemetry, identity logs, registry logs, package-service logs, network telemetry, cloud logs, Kubernetes logs, and deployment logs are ingested into Elastic or mapped into Elastic-compatible field structures.

·        Elastic is strongest where endpoint activity from CI/CD runners and build hosts can be correlated with repository workflow changes, runner assignment, token or deploy-key activity, webhook changes, registry access, outbound network behavior, cloud activity, Kubernetes activity, and deployment activity.

·        Elastic can support endpoint-centered detections and multi-source correlation across Git, CI/CD, runner, identity, registry, network, cloud, Kubernetes, and deployment telemetry when event sequencing, entity mapping, and timestamp normalization are reliable.

·        Elastic is not a standalone source for confirming repository workflow compromise unless the necessary Git, CI/CD, runner, endpoint, identity, registry, network, cloud, Kubernetes, and deployment data sources are present and mapped consistently.

·        Elastic detection content should avoid treating process execution, workflow change, token creation, registry activity, cloud activity, or network egress as confirmed compromise by itself. These events should be treated as correlation anchors and confidence amplifiers.

·        Elastic detections must be locally mapped to the organization’s ECS fields, custom fields, index patterns, data streams, agent coverage, Git source fields, CI/CD source fields, registry fields, cloud fields, Kubernetes fields, and enrichment sources before production deployment.

·        Elastic rules should not generate high-confidence alerting from a single endpoint event, Git event, CI/CD event, registry event, cloud event, or network event without supporting identity, repository, runner, workflow, credential, registry, or downstream-control-plane context.

Rule

Workflow Modification Followed by Suspicious Runner Host Process Activity

Rule Format

Elastic event-correlation rule suitable for Git audit logs, CI/CD pipeline logs, Elastic Defend endpoint telemetry, process telemetry, command-line telemetry, file telemetry, network telemetry, identity logs, registry logs, repository sensitivity enrichment, runner inventory, and SIEM correlation after ECS field validation, index-pattern validation, event-sequence validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect repository workflow modification followed by suspicious process activity on CI/CD runners, build hosts, Git platform hosts, registry hosts, or deployment automation systems.

·        Identify behavior consistent with repository workflow abuse, malicious CI/CD execution, credential inspection, artifact staging, source-code bundling, payload retrieval, registry tooling, cloud tooling, Kubernetes tooling, or downstream deployment preparation.

·        Prioritize sensitive repositories, protected branches, production deployment workflows, package-publishing workflows, container-build workflows, signing workflows, infrastructure-as-code workflows, cloud deployment workflows, Kubernetes deployment workflows, and high-value build paths.

·        Support escalation when workflow modification is followed by runner execution involving shell interpreters, scripting engines, package managers, archive utilities, network transfer tools, registry clients, cloud CLIs, Kubernetes CLIs, or container tooling.

·        Preserve separation between suspicious runner process activity and confirmed compromise by requiring supporting Git, CI/CD, runner, endpoint, network, identity, registry, cloud, Kubernetes, or incident-response evidence before classifying compromise as confirmed.

·        This rule does not prove repository compromise, credential theft, token theft, malicious package publication, image compromise, cloud compromise, Kubernetes compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify repository workflow file creation, modification, deletion, permission change, CI/CD configuration modification, build-script modification, deployment-script modification, release-script modification, package-publishing workflow change, container-build workflow change, or infrastructure-as-code workflow change.

·        Prioritize workflow changes made by newly privileged users, inactive users, unfamiliar maintainers, external contributors, unfamiliar bot accounts, service accounts, or accounts authenticating from unusual source infrastructure.

·        Correlate workflow changes with CI/CD pipeline execution, job execution, runner assignment, workflow execution, release execution, package-publishing execution, container-build execution, infrastructure-as-code execution, or deployment execution from the same repository, project, group, branch, workflow, runner, or job.

·        Detect suspicious runner-host process activity involving shell interpreters, scripting engines, package managers, archive utilities, compression tools, network transfer tools, registry clients, container tooling, cloud CLIs, Kubernetes CLIs, credential helpers, or secret-management tools.

·        Prioritize command lines involving environment-variable inspection, protected-variable exposure, credential-location probing, secret-file access, recursive file collection, repository bundling, archive creation, remote retrieval, direct IP access, encoded execution, suspicious command chaining, artifact staging, cache access, registry authentication, cloud role discovery, or external transfer.

·        Increase confidence when the affected runner or build host is associated with sensitive repositories, production deployment, package publication, image publication, signing workflows, infrastructure-as-code, cloud deployment, Kubernetes deployment, or high-value build paths.

·        Increase confidence when process activity is followed by outbound communication, registry authentication, package access, image activity, artifact access, cloud API activity, Kubernetes API activity, deployment activity, or unusual internal service access.

·        Reduce severity when activity matches approved workflow maintenance, release engineering, CI/CD refactoring, runner migration, package publication, container builds, infrastructure deployment, vulnerability scanning, security testing, incident response, or documented change-control activity.

·        Do not classify workflow modification or runner process activity as compromise without suspicious execution, credential behavior, registry behavior, network behavior, downstream control-plane behavior, or incident-response validation.

·        Do not treat workflow modification, shell execution, package-manager activity, archive creation, registry client execution, cloud CLI execution, or Kubernetes CLI execution as compromise evidence by itself.

Required Telemetry

·        Git audit logs.

·        Repository activity logs.

·        Workflow file change events.

·        CI/CD configuration change events.

·        Commit metadata.

·        Merge request or pull request metadata.

·        Protected-branch logs where available.

·        CI/CD pipeline logs.

·        CI/CD job logs.

·        Runner assignment logs.

·        Runner tag logs.

·        Runner registration logs where available.

·        Elastic Defend endpoint telemetry.

·        Process creation telemetry.

·        Command-line telemetry.

·        Parent process and process lineage.

·        File creation telemetry.

·        File modification telemetry.

·        Network connection telemetry.

·        DNS telemetry where available.

·        Proxy or firewall telemetry where available.

·        Registry logs where available.

·        Package-service logs where available.

·        Artifact-store logs where available.

·        Cloud audit logs where available.

·        Kubernetes audit logs where available.

·        Identity logs.

·        User identity.

·        Service-account identity where available.

·        Hostname.

·        Agent ID.

·        Runner ID.

·        Runner host.

·        Runner tag.

·        Repository.

·        Project or group.

·        Branch.

·        Workflow file path.

·        Pipeline ID.

·        Job ID.

·        Commit hash where available.

·        Source IP.

·        Source ASN and source geography where available.

·        Timestamp.

·        Repository sensitivity enrichment.

·        Runner inventory.

·        Approved workflow-change baselines.

·        Approved release records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build Elastic index patterns or data views for Git audit logs, CI/CD logs, Elastic Defend endpoint telemetry, network telemetry, identity logs, registry logs, package logs, cloud logs, Kubernetes logs, and deployment logs.

·        Build Git workflow-change event groups covering workflow file modification, CI/CD configuration changes, build-script changes, deployment-script changes, release-script changes, package-publishing workflow changes, container-build workflow changes, protected-branch changes, approval-rule changes, and review-control changes.

·        Build CI/CD execution groups covering pipeline execution, job execution, workflow execution, runner assignment, runner tag use, release workflow execution, package-publishing workflow execution, container-build workflow execution, infrastructure-as-code workflow execution, and deployment workflow execution.

·        Build runner process groups for shell interpreters, scripting engines, package managers, archive utilities, transfer utilities, registry clients, container tooling, cloud CLIs, Kubernetes CLIs, credential helpers, and secret-management tools.

·        Build suspicious command-line groups for environment-variable inspection, protected-variable exposure, credential-location probing, secret-file access, archive creation, recursive collection, repository bundling, direct IP use, remote retrieval, encoded execution, suspicious command chaining, and external transfer.

·        Build repository sensitivity enrichment for production deployment repositories, package-publishing repositories, image-publishing repositories, signing repositories, infrastructure-as-code repositories, cloud deployment repositories, Kubernetes deployment repositories, and high-value application repositories.

·        Validate Elastic ECS mappings for user.name, user.id, host.name, agent.id, process.name, process.command_line, process.parent.name, file.path, event.action, event.category, event.dataset, source.ip, destination.ip, destination.domain, url.domain, cloud.account.id, kubernetes.namespace, and custom Git or CI/CD fields.

·        Validate joins or event sequences between Git audit events, CI/CD execution events, endpoint process telemetry, identity events, network telemetry, registry events, cloud events, Kubernetes events, and deployment events.

·        Use short correlation windows when workflow modification is followed immediately by pipeline execution or runner process activity.

·        Use moderate correlation windows when workflow modification is followed by delayed runner execution, artifact movement, registry activity, outbound communication, cloud activity, or Kubernetes activity.

·        Use longer correlation windows only when CI/CD lineage, repeated runner behavior, identity evidence, registry evidence, cloud evidence, Kubernetes evidence, or incident-response evidence supports delayed linkage.

·        Add severity weighting for sensitive repository class, privileged actor, protected branch, suspicious runner command, credential inspection, external transfer, registry activity, cloud activity, Kubernetes activity, and absence of approved change context.

·        Treat workflow modification as a confidence anchor, not standalone proof of compromise.

·        Build exceptions for approved workflow refactoring, release engineering, runner migration, package-publication changes, infrastructure deployment, vulnerability scanning, security testing, incident response, and known automation.

·        Do not enable alert mode until ECS field mapping, custom field mapping, index-pattern validation, event-sequence validation, repository sensitivity enrichment, runner identity mapping, false-positive rate, query performance, SOC triage workflow, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.5 / 10

·        The rule is behaviorally anchored to workflow modification followed by suspicious runner-host process activity rather than static indicators, CVE identifiers, domains, IP addresses, hashes, package names, image names, or repository names.

·        The rule remains useful if an adversary changes workflow filename, repository path, command syntax, runner host, interpreter, transfer utility, registry client, cloud CLI, Kubernetes CLI, or timing.

·        The score is supported by the durability of repository-control activity followed by trusted automation execution, credential inspection, archive creation, artifact staging, registry access, cloud tooling, Kubernetes tooling, and outbound communication.

·        The score is constrained by incomplete Git audit logs, missing CI/CD job detail, weak runner identity mapping, noisy build activity, incomplete command-line telemetry, and inconsistent ECS or custom-field mapping.

·        The rule is durable as a repository-to-runner correlation detector but should not be treated as standalone proof of credential theft, package compromise, cloud compromise, Kubernetes compromise, or actor attribution.

TCR Assessment

Operational TCR

7.7 / 10

Full-Telemetry TCR

8.9 / 10

·        Operational confidence depends on Git audit coverage, CI/CD log coverage, Elastic Defend coverage, command-line visibility, runner identity mapping, repository sensitivity enrichment, identity enrichment, and Elastic event-sequence quality.

·        Operational confidence is reduced where workflow changes are frequent, CI/CD logs lack command detail, runner hosts are ephemeral, source data uses inconsistent fields, or change-control records are incomplete.

·        Operational confidence is reduced during release engineering, CI/CD refactoring, runner migration, repository migration, package-publication changes, infrastructure deployment, vulnerability scanning, and incident-response activity.

·        Full-telemetry confidence improves when Elastic correlates Git audit logs, CI/CD logs, endpoint telemetry, DNS logs, proxy logs, registry logs, package logs, cloud logs, Kubernetes logs, identity logs, and change-control records.

·        Even under full telemetry conditions, this rule should support escalation and scoping rather than standalone confirmation of compromise.

Limitations

·        Elastic cannot correlate this behavior unless Git, CI/CD, endpoint, runner, identity, network, registry, cloud, and Kubernetes data are ingested and mapped consistently.

·        Workflow changes may be legitimate during normal release engineering, CI/CD refactoring, runner migration, repository migration, or infrastructure updates.

·        Runner execution may be noisy in high-change build environments.

·        Missing command-line telemetry, weak runner identity mapping, inconsistent repository naming, or incomplete ECS mapping can reduce confidence.

·        The rule may miss workflow abuse that uses approved workflows, expected runner commands, low-noise credential access, or normal release paths.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Elastic workflow modification to suspicious runner execution query pattern requiring index-pattern validation, ECS field validation, custom Git and CI/CD field validation, repository identity mapping, runner identity mapping, timestamp normalization, event-sequence validation, approved workflow allowlisting, timing-window tuning, and environment-specific false-positive testing before production deployment.

ElasticSequence AS WorkflowToRunnerExecution

WHERE GitAuditEvent.event.action IN (
"workflow_file_created",
"workflow_file_modified",
"workflow_file_deleted",
"ci_config_modified",
"build_script_modified",
"deployment_script_modified",
"release_script_modified",
"protected_branch_changed",
"approval_rule_changed"
)

AND GitAuditEvent.repository.sensitivity IN (
"production_deployment",
"package_publishing",
"image_publishing",
"signing",
"infrastructure_as_code",
"cloud_deployment",
"kubernetes_deployment",
"high_value_repository"
)

AND (
GitAuditEvent.actor.context IN (
"newly_privileged_user",
"inactive_user",
"unfamiliar_maintainer",
"external_contributor",
"unfamiliar_bot_account",
"service_account",
"unusual_source_infrastructure"
)

OR GitAuditEvent.source.context IN (
"rare_asn",
"unusual_geography",
"new_source_for_actor",
"source_not_in_actor_baseline"
)
)

FOLLOWED_BY WITHIN ENV_WORKFLOW_TO_PIPELINE_WINDOW

CICDEvent.event.action IN (
"pipeline_executed",
"job_executed",
"workflow_executed",
"release_workflow_executed",
"package_publishing_workflow_executed",
"container_build_workflow_executed",
"iac_workflow_executed",
"deployment_workflow_executed"
)

WHERE CICDEvent.repository.name IN SAME_REPOSITORY(GitAuditEvent.repository.name)

FOLLOWED_BY WITHIN ENV_PIPELINE_TO_RUNNER_WINDOW

EndpointEvent.event.category IN (
"process",
"file",
"network"
)

WHERE EndpointEvent.host.name IN SAME_RUNNER(CICDEvent.runner.id)

AND (
EndpointEvent.process.name IN (
"bash",
"sh",
"powershell.exe",
"pwsh.exe",
"cmd.exe",
"python",
"python3",
"node",
"ruby",
"perl",
"curl",
"wget",
"tar",
"zip",
"docker",
"kubectl",
"helm",
"aws",
"az",
"gcloud",
"git",
"npm",
"pip"
)

OR EndpointEvent.process.command_line CONTAINS ANY (
"printenv",
"cat /proc/self/environ",
"credential",
"token",
"secret",
"private_key",
"id_rsa",
"kubeconfig",
".aws/credentials",
".docker/config.json",
"archive",
"upload",
"artifact",
"cache",
"registry",
"docker login",
"kubectl config",
"aws sts",
"az account",
"gcloud auth"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_RUNNER_FOLLOWON_WINDOW (
NetworkOrRegistryOrCloudEvent.event.action IN (
"unusual_outbound_communication",
"registry_authentication",
"package_access",
"artifact_access",
"image_push",
"cloud_api_activity",
"kubernetes_api_activity",
"deployment_activity"
)
WHERE NetworkOrRegistryOrCloudEvent.host.name IN SAME_HOST(EndpointEvent.host.name)
)

AND NOT ChangeContext IN (
"approved_workflow_refactor",
"approved_release_engineering",
"approved_runner_migration",
"approved_package_publication_change",
"approved_iac_deployment",
"approved_security_testing",
"approved_incident_response"
)

Rule

Automation Token or Webhook Change Followed by Suspicious Repository, Registry, or Deployment Activity

Rule Format

Elastic multi-source automation-credential and webhook correlation rule suitable for Git audit logs, CI/CD logs, identity logs, token lifecycle logs, deploy-key logs, webhook logs, OAuth application logs, service-account logs, runner logs, registry logs, package-service logs, artifact-store logs, endpoint telemetry, network telemetry, cloud audit logs, Kubernetes audit logs, and deployment logs after ECS field validation, custom field mapping, credential lineage validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect creation or modification of automation credentials, deploy keys, access tokens, OAuth applications, webhooks, service accounts, workload identities, runner tokens, or automation identities followed by suspicious repository, registry, package, artifact, deployment, cloud, or Kubernetes activity.

·        Identify potential abuse of trusted Git and CI/CD automation paths tied to sensitive repositories, production deployment paths, package-publishing authority, image-publishing authority, signing authority, infrastructure-as-code control, cloud deployment, Kubernetes deployment, or high-value build systems.

·        Prioritize automation or webhook changes performed by newly privileged users, inactive users, unfamiliar maintainers, unfamiliar bot accounts, service accounts, external contributors, or accounts authenticating from unusual source infrastructure.

·        Support escalation when automation changes are followed by repository cloning, project export, pipeline execution, runner execution, artifact access, package access, image pull, image push, registry authentication, release modification, deployment activity, cloud API use, Kubernetes API use, or secret-manager access.

·        Preserve separation between suspicious automation activity and confirmed compromise by requiring supporting repository, CI/CD, identity, endpoint, registry, package, cloud, Kubernetes, deployment, or incident-response evidence before classifying compromise as confirmed.

·        This rule does not prove credential theft, token theft, webhook abuse, registry compromise, package compromise, cloud compromise, Kubernetes compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify creation, modification, scope expansion, permission change, unusual use, or destination change involving deploy keys, project access tokens, group access tokens, personal access tokens, OAuth applications, webhooks, service accounts, workload identities, runner tokens, or automation identities.

·        Prioritize automation changes affecting sensitive repositories, protected branches, production deployment workflows, package-publishing workflows, image-publishing workflows, signing workflows, infrastructure-as-code workflows, cloud deployment workflows, Kubernetes deployment workflows, or release automation.

·        Prioritize automation changes performed by newly privileged users, inactive users, unfamiliar maintainers, unfamiliar bot accounts, service accounts, external contributors, or accounts authenticating from unusual source infrastructure.

·        Correlate automation changes with follow-on repository cloning, project export, pipeline execution, runner execution, artifact access, package access, image pull, image push, registry authentication, release modification, deployment activity, cloud API activity, Kubernetes API activity, or secret-manager access.

·        Increase confidence when follow-on activity occurs outside expected repository, runner, branch, project, group, time window, geography, source network, device, environment, or deployment path.

·        Increase confidence when multiple automation credentials are created or modified in a short period, when credential scope is broader than expected, when a webhook destination is new or unfamiliar, or when service-account ownership is unclear.

·        Increase confidence when downstream activity is performed using the new or modified credential, related automation identity, related service account, related webhook destination, or source host associated with CI/CD infrastructure.

·        Reduce severity when activity matches approved integration onboarding, token rotation, deploy-key maintenance, webhook maintenance, runner migration, service-account rotation, release engineering, cloud operations, security testing, incident response, or documented change-control activity.

·        Do not classify automation credential creation, webhook creation, or service-account modification as compromise without follow-on use, suspicious scope, suspicious destination, actor-risk context, downstream activity, or incident-response validation.

·        Do not treat token creation, deploy-key creation, webhook creation, service-account changes, or OAuth application creation as compromise evidence by itself.

Required Telemetry

·        Git audit logs.

·        Repository access logs.

·        Deploy-key logs.

·        Token lifecycle logs.

·        Project access token logs.

·        Group access token logs.

·        Personal access token logs where available.

·        OAuth application logs.

·        Webhook logs.

·        Service-account logs.

·        Workload identity logs where available.

·        Runner registration logs.

·        Runner token logs where available.

·        CI/CD pipeline logs.

·        CI/CD job logs.

·        Runner telemetry.

·        Identity logs.

·        Endpoint telemetry where available.

·        Network telemetry where available.

·        Registry logs.

·        Package-service logs.

·        Artifact-store logs.

·        Release-system logs.

·        Deployment logs.

·        Cloud audit logs where available.

·        Kubernetes audit logs where available.

·        Actor identity.

·        Token or credential identifier where available.

·        Credential scope.

·        Credential permission level.

·        Webhook destination.

·        Webhook response status where available.

·        OAuth application identifier where available.

·        Service-account identifier where available.

·        Repository.

·        Project or group.

·        Branch.

·        Workflow.

·        Pipeline ID.

·        Runner ID.

·        Source IP.

·        Source ASN and source geography where available.

·        Destination service.

·        Action.

·        Result.

·        Timestamp.

·        Repository sensitivity enrichment.

·        Automation identity inventory.

·        Service-account inventory.

·        Approved token inventory.

·        Approved webhook inventory.

·        Approved deploy-key inventory.

·        Approved integration records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build automation event groups covering deploy-key creation, deploy-key modification, token creation, token scope change, token permission change, OAuth application creation, webhook creation, webhook modification, webhook destination change, service-account creation, workload identity change, runner token activity, and automation identity changes.

·        Build sensitive repository and workflow groups covering production deployment, package publishing, image publishing, signing, infrastructure-as-code, cloud deployment, Kubernetes deployment, release automation, and high-value application repositories.

·        Build actor-risk groups covering newly privileged users, inactive users, unfamiliar maintainers, unfamiliar bot accounts, service accounts, external contributors, rare source geographies, rare ASNs, and unusual source networks.

·        Build suspicious webhook groups for new destinations, unfamiliar destinations, destinations outside approved integration inventory, unmanaged object storage, external automation endpoints, temporary infrastructure, tunneling services, dynamic DNS, and failed-then-successful webhook delivery patterns.

·        Build follow-on activity groups covering repository cloning, project export, pipeline execution, runner execution, artifact access, package access, image pull, image push, registry authentication, release modification, deployment activity, cloud API activity, Kubernetes API activity, secret-manager access, and infrastructure changes.

·        Build lineage groups that map credential identifier, automation identity, service account, webhook destination, runner token, project, group, repository, branch, pipeline, runner, source host, and downstream action where telemetry permits.

·        Validate Elastic index patterns, ECS mappings, custom Git fields, custom CI/CD fields, token scope fields, webhook destination fields, service-account identifiers, repository names, project or group identifiers, timestamps, and join reliability.

·        Validate joins or event sequences between Git audit logs, identity logs, CI/CD logs, registry logs, package logs, artifact logs, endpoint telemetry, network telemetry, deployment logs, cloud logs, Kubernetes logs, and incident-response evidence.

·        Use short correlation windows when automation changes are followed immediately by pipeline execution, registry activity, repository access, webhook delivery, or deployment activity.

·        Use moderate correlation windows for delayed package access, image activity, artifact access, cloud activity, Kubernetes activity, or deployment activity after automation changes.

·        Use longer correlation windows only when credential lineage, webhook lineage, identity evidence, CI/CD evidence, cloud evidence, registry evidence, or incident-response evidence supports delayed linkage.

·        Add severity weighting for sensitive repository scope, broad credential permissions, privileged actor, unusual source infrastructure, new webhook destination, package publication authority, image publication authority, production deployment authority, cloud deployment authority, Kubernetes deployment authority, and follow-on use.

·        Treat automation changes as confidence anchors, not standalone proof of compromise.

·        Build exceptions for approved token rotation, deploy-key maintenance, webhook onboarding, integration onboarding, runner migration, service-account rotation, release engineering, cloud operations, security testing, incident response, and known automation.

·        Do not enable alert mode until credential lineage, token scope mapping, webhook validation, custom field availability, ECS mapping, repository sensitivity enrichment, false-positive rate, query performance, SOC triage workflow, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.4 / 10

·        The rule is behaviorally anchored to automation credential and webhook changes followed by downstream use rather than static indicators, fixed token names, repository names, domains, IP addresses, package names, image names, hashes, or CVE identifiers.

·        The rule remains useful if an adversary changes credential type, token name, webhook destination, service account, repository path, runner host, registry endpoint, package, image, cloud service, or timing.

·        The score is supported by the durability of credential creation, scope expansion, webhook creation, webhook destination change, OAuth application creation, service-account changes, and follow-on repository, registry, artifact, deployment, cloud, or Kubernetes activity.

·        The score is constrained by incomplete token lifecycle logging, missing credential identifiers, poor webhook visibility, weak service-account mapping, and legitimate integration onboarding or token rotation.

·        The rule is durable as automation lineage coverage but should not be treated as standalone proof of credential theft, webhook abuse, cloud compromise, registry compromise, or actor attribution.

TCR Assessment

Operational TCR

7.6 / 10

Full-Telemetry TCR

8.8 / 10

·        Operational confidence depends on Git audit coverage, token lifecycle logging, deploy-key visibility, webhook visibility, service-account mapping, identity enrichment, downstream registry or cloud visibility, ECS mapping, custom field mapping, and Elastic event-sequence quality.

·        Operational confidence is reduced where token identifiers are masked, credential scope is unavailable, webhook destination logging is incomplete, service-account ownership is unclear, or downstream activity cannot be tied to the credential or webhook.

·        Operational confidence is reduced during integration onboarding, token rotation, deploy-key maintenance, service-account rotation, runner migration, release engineering, cloud operations, and incident-response activity.

·        Full-telemetry confidence improves when Elastic correlates credential lifecycle events with CI/CD logs, registry logs, package logs, artifact logs, endpoint telemetry, network telemetry, cloud logs, Kubernetes logs, identity logs, and change-control records.

·        Even under full telemetry conditions, this rule should support escalation and lineage reconstruction rather than standalone confirmation of compromise.

Limitations

·        Elastic cannot prove credential theft, token theft, or webhook abuse unless follow-on use, unauthorized activity, or incident-response evidence supports that conclusion.

·        Some Git and CI/CD platforms may mask token identifiers, reduce token lifecycle visibility, or omit webhook payload details.

·        Legitimate integration onboarding, token rotation, service-account rotation, webhook maintenance, and runner migration can resemble suspicious automation activity.

·        Weak credential lineage, inconsistent repository naming, incomplete service-account mapping, incomplete webhook logging, or missing downstream logs can reduce confidence.

·        The rule may miss abuse of existing long-lived credentials or webhooks if no recent creation, modification, or scope change is visible.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Elastic automation credential or webhook change to downstream activity query pattern requiring index-pattern validation, ECS field validation, credential identifier validation, token scope validation, webhook field validation, service-account mapping, downstream lineage validation, approved integration allowlisting, timing-window tuning, and environment-specific false-positive testing before production deployment.

ElasticSequence AS AutomationChangeToDownstreamActivity

WHERE GitOrIdentityEvent.event.action IN (
"deploy_key_created",
"deploy_key_modified",
"project_token_created",
"group_token_created",
"personal_access_token_created",
"token_scope_changed",
"token_permission_changed",
"oauth_application_created",
"webhook_created",
"webhook_modified",
"webhook_destination_changed",
"service_account_created",
"service_account_modified",
"workload_identity_changed",
"runner_token_created",
"automation_identity_changed"
)

AND GitOrIdentityEvent.repository.sensitivity IN (
"production_deployment",
"package_publishing",
"image_publishing",
"signing",
"infrastructure_as_code",
"cloud_deployment",
"kubernetes_deployment",
"high_value_repository"
)

AND (
GitOrIdentityEvent.actor.context IN (
"newly_privileged_user",
"inactive_user",
"unfamiliar_maintainer",
"unfamiliar_bot_account",
"service_account",
"external_contributor",
"unusual_source_infrastructure"
)

OR GitOrIdentityEvent.credential.context IN (
"broad_scope",
"long_expiration",
"privileged_scope",
"registry_scope",
"api_scope",
"write_scope",
"deployment_scope",
"new_or_unfamiliar_webhook_destination"
)
)

FOLLOWED_BY WITHIN ENV_AUTOMATION_CHANGE_TO_USE_WINDOW

DownstreamEvent.event.action IN (
"repository_cloned",
"project_exported",
"pipeline_executed",
"runner_executed",
"artifact_accessed",
"package_accessed",
"image_pulled",
"image_pushed",
"registry_authenticated",
"release_modified",
"deployment_executed",
"cloud_api_called",
"kubernetes_api_called",
"secret_manager_accessed",
"infrastructure_modified"
)

WHERE (
DownstreamEvent.credential.id IN SAME_CREDENTIAL_OR_RELATED_IDENTITY(GitOrIdentityEvent.credential.id)
OR DownstreamEvent.user.name IN SAME_AUTOMATION_IDENTITY(GitOrIdentityEvent.actor.name)
OR DownstreamEvent.repository.name IN SAME_REPOSITORY_OR_GROUP(GitOrIdentityEvent.repository.name)
OR DownstreamEvent.destination.domain IN SAME_WEBHOOK_DESTINATION(GitOrIdentityEvent.webhook.destination)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_DOWNSTREAM_ANOMALY_WINDOW (
SecurityEvent.event.action IN (
"outside_expected_repository",
"outside_expected_runner",
"outside_expected_branch",
"outside_expected_time_window",
"outside_expected_source_network",
"outside_expected_geography",
"outside_expected_deployment_path",
"multiple_credential_changes",
"multiple_sensitive_repositories_accessed"
)
WHERE SecurityEvent.user.name IN SAME_ACTOR_OR_AUTOMATION_IDENTITY(DownstreamEvent.user.name)
)

AND NOT ChangeContext IN (
"approved_token_rotation",
"approved_deploy_key_maintenance",
"approved_webhook_onboarding",
"approved_integration_onboarding",
"approved_runner_migration",
"approved_service_account_rotation",
"approved_release_engineering",
"approved_cloud_operations",
"approved_security_testing",
"approved_incident_response"
)

Rule

CI/CD-Linked Identity Use Followed by Cloud, Kubernetes, or Deployment Activity

Rule Format

Elastic multi-source CI/CD-to-control-plane correlation rule suitable for CI/CD logs, Git audit logs, identity logs, runner logs, Elastic Defend endpoint telemetry, registry logs, cloud audit logs, Kubernetes audit logs, deployment logs, secret-manager logs, network telemetry, and SIEM correlation after ECS field validation, identity mapping, credential lineage validation, source-network validation, downstream action validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious use of CI/CD-linked credentials, automation identities, service accounts, workload identities, deploy accounts, cloud roles, Kubernetes identities, package-publishing identities, image-publishing identities, or deployment identities followed by cloud, Kubernetes, deployment, registry, secret-manager, storage, or infrastructure activity.

·        Identify potential downstream expansion after repository workflow abuse, credential exposure, token exposure, runner compromise, malicious pipeline execution, or automation identity misuse.

·        Prioritize downstream activity occurring outside expected repository, branch, workflow, runner, source network, geography, project, namespace, region, account, subscription, tenant, environment, deployment path, or approved time window.

·        Support escalation when suspicious CI/CD-linked identity use follows workflow modification, token creation, deploy-key creation, webhook modification, runner changes, suspicious runner execution, credential access, registry activity, or unusual outbound communication.

·        Preserve separation between suspicious downstream control-plane activity and confirmed compromise by requiring repository, CI/CD, identity, endpoint, network, registry, cloud, Kubernetes, deployment, or incident-response evidence before classifying compromise as confirmed.

·        This rule does not prove repository compromise, credential theft, cloud compromise, Kubernetes compromise, deployment compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify use of CI/CD-linked credentials, automation identities, service accounts, workload identities, deploy accounts, cloud roles, Kubernetes identities, package-publishing identities, image-publishing identities, or deployment identities.

·        Prioritize use outside expected repository, branch, workflow, runner, source network, geography, project, namespace, region, account, subscription, tenant, environment, deployment path, or approved time window.

·        Detect follow-on activity involving cloud API calls, IAM changes, role assignment, access-key creation, secret-manager access, container registry access, artifact access, Kubernetes API activity, deployment execution, infrastructure-as-code execution, storage access, function changes, workload changes, or release activity.

·        Correlate downstream activity with suspicious upstream context, including workflow modification, suspicious pipeline execution, new runner registration, runner tag change, token creation, deploy-key creation, webhook modification, OAuth application creation, protected-branch change, credential access, unusual outbound communication, or registry activity.

·        Increase confidence when the same identity, token, runner host, service account, workload identity, source IP, pipeline, repository, deployment account, or incident timeline connects upstream CI/CD activity to downstream control-plane activity.

·        Increase confidence when downstream actions modify identity, privileges, secrets, networking, storage, container images, deployment manifests, infrastructure templates, Kubernetes role bindings, image-pull secrets, or production workloads.

·        Increase confidence when control-plane activity is rare for the identity, new for the environment, outside the expected region or namespace, or inconsistent with the account’s normal role.

·        Reduce severity when activity matches approved deployment workflows, infrastructure deployment, cloud operations, Kubernetes operations, release engineering, package publication, image publication, vulnerability scanning, security testing, incident response, or documented change-control activity.

·        Do not attribute cloud, Kubernetes, or deployment activity to repository workflow compromise without identity, timing, runner, repository, credential, source-network, or incident-response linkage.

·        Do not treat cloud API activity, Kubernetes API activity, deployment activity, registry activity, or secret-manager activity as compromise evidence by itself.

Required Telemetry

·        CI/CD pipeline logs.

·        CI/CD job logs.

·        Runner logs.

·        Git audit logs.

·        Identity logs.

·        Service-account logs.

·        Workload identity logs where available.

·        Token lifecycle logs where available.

·        Elastic Defend endpoint telemetry from runners where available.

·        Network telemetry where available.

·        DNS logs where available.

·        Proxy logs where available.

·        Registry logs.

·        Package-service logs where available.

·        Artifact-store logs where available.

·        Cloud audit logs.

·        Kubernetes audit logs.

·        Deployment platform logs.

·        Secret-manager logs where available.

·        Infrastructure-as-code execution logs where available.

·        User identity.

·        Automation identity.

·        Service-account identity.

·        Workload identity.

·        Credential identifier where available.

·        Runner ID.

·        Runner host.

·        Repository.

·        Branch.

·        Workflow.

·        Pipeline ID.

·        Job ID.

·        Source IP.

·        Source ASN and source geography where available.

·        Cloud account, project, subscription, tenant, or region.

·        Kubernetes cluster, namespace, service account, and role binding where available.

·        Deployment environment.

·        Resource action.

·        Result.

·        Timestamp.

·        Repository sensitivity enrichment.

·        CI/CD credential inventory.

·        Cloud identity inventory.

·        Kubernetes identity inventory.

·        Deployment account inventory.

·        Approved deployment records.

·        Approved cloud operation records.

·        Approved Kubernetes operation records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build CI/CD credential and identity groups covering automation identities, service accounts, workload identities, deploy accounts, cloud roles, Kubernetes identities, package-publishing identities, image-publishing identities, and deployment identities.

·        Build downstream control-plane action groups covering cloud API calls, IAM changes, role assignment, access-key creation, secret-manager access, registry access, artifact access, Kubernetes API activity, deployment execution, infrastructure-as-code execution, storage access, function changes, workload changes, and release activity.

·        Build expected-use baselines by repository, branch, workflow, runner, source network, geography, project, namespace, region, account, subscription, tenant, environment, and deployment path.

·        Build upstream suspicious context groups using Git audit logs, CI/CD logs, runner metadata, endpoint telemetry, network telemetry, identity logs, registry logs, package logs, cloud logs, Kubernetes logs, and Elastic event context that identifies workflow modification, suspicious pipeline execution, runner changes, token creation, deploy-key creation, webhook modification, credential access, unusual egress, or registry activity.

·        Build lineage logic mapping identity, credential, token, runner host, source IP, pipeline, repository, deployment account, service account, workload identity, and incident timeline.

·        Validate Elastic index coverage, ECS mappings, custom field mappings, identity normalization, service-account mapping, workload identity mapping, credential identifiers, source IP preservation, cloud project or subscription fields, Kubernetes namespace fields, deployment fields, and timestamp consistency.

·        Validate event sequences or joins between CI/CD logs, Git audit logs, identity logs, endpoint telemetry, network telemetry, registry logs, package logs, cloud logs, Kubernetes logs, deployment logs, and incident-response evidence.

·        Use short correlation windows when downstream control-plane activity occurs during or immediately after suspicious CI/CD execution.

·        Use moderate correlation windows when downstream activity follows workflow modification, runner changes, token creation, credential access, unusual egress, or registry activity.

·        Use longer correlation windows only when identity lineage, cloud evidence, Kubernetes evidence, endpoint evidence, CI/CD lineage, or incident-response evidence supports delayed linkage.

·        Add severity weighting for privileged identity use, production deployment access, secret-manager access, IAM changes, role assignments, access-key creation, Kubernetes role binding changes, image-pull secret changes, production workload changes, sensitive storage access, and source-network mismatch.

·        Treat downstream control-plane activity as a confidence amplifier unless linked to suspicious CI/CD, credential, runner, identity, source-network, or incident-response evidence.

·        Build exceptions for approved deployment workflows, infrastructure deployment, cloud operations, Kubernetes operations, release engineering, package publication, image publication, vulnerability scanning, security testing, incident response, and known automation.

·        Do not enable alert mode until identity mapping, credential lineage, source-network validation, expected-use baselines, ECS field mapping, custom field mapping, correlation reliability, false-positive rate, query performance, SOC triage workflow, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.4 / 10

·        The rule is behaviorally anchored to CI/CD-linked identity use followed by cloud, Kubernetes, or deployment activity rather than static domains, IP addresses, hashes, repository names, package names, image names, or CVE identifiers.

·        The rule remains useful if an adversary changes workflow content, runner host, cloud service, Kubernetes namespace, deployment target, source infrastructure, credential type, identity type, tool sequence, or timing.

·        The score is supported by the durability of automation identity use, cloud API activity, Kubernetes API activity, deployment execution, secret-manager access, registry access, IAM changes, role assignments, source-network mismatch, and unexpected production-environment activity.

·        The score is constrained by identity federation complexity, weak credential lineage, incomplete source IP preservation, noisy deployment activity, inconsistent cloud and Kubernetes logging, and legitimate automation workflows.

·        The rule is durable as CI/CD-to-control-plane correlation coverage but should not be treated as standalone proof of repository workflow compromise, credential theft, cloud compromise, Kubernetes compromise, or actor attribution.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

8.8 / 10

·        Operational confidence depends on CI/CD logs, identity logs, cloud audit logs, Kubernetes audit logs, deployment logs, credential lineage, source-network preservation, repository sensitivity mapping, ECS mapping, custom field mapping, and Elastic event-sequence quality.

·        Operational confidence is reduced where identity federation obscures the initiating repository, source IPs are transformed, cloud sessions are reused, workload identities are shared, deployment logs lack pipeline context, or Elastic field mappings are incomplete.

·        Operational confidence is reduced during normal infrastructure deployment, release engineering, cloud operations, Kubernetes operations, image publication, package publication, vulnerability scanning, and incident-response activity.

·        Full-telemetry confidence improves when Elastic correlates CI/CD logs, Git audit logs, runner endpoint telemetry, network telemetry, registry logs, package logs, cloud logs, Kubernetes logs, identity logs, deployment logs, and change-control records.

·        Even under full telemetry conditions, this rule should support downstream exposure scoping and containment prioritization rather than standalone confirmation of compromise.

Limitations

·        Elastic cannot attribute cloud, Kubernetes, or deployment activity to repository workflow compromise without reliable identity, runner, repository, credential, source-network, or timing linkage.

·        Federated identity, workload identity, shared service accounts, NAT, proxying, cloud session reuse, and token reuse can obscure lineage.

·        Legitimate deployment workflows and cloud operations can closely resemble suspicious downstream activity.

·        Missing cloud logs, missing Kubernetes logs, weak source IP preservation, incomplete deployment logs, inconsistent identity mapping, or incomplete ECS mapping can reduce confidence.

·        The rule may miss downstream abuse that uses expected deployment paths, approved identities, normal source networks, or delayed execution outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Elastic CI/CD-linked identity use to cloud, Kubernetes, or deployment activity query pattern requiring index-pattern validation, ECS field validation, identity mapping, credential lineage validation, source-network validation, cloud action validation, Kubernetes action validation, deployment lineage validation, approved workflow allowlisting, timing-window tuning, and environment-specific false-positive testing before production deployment.

ElasticSequence AS CICDIdentityToControlPlaneActivity

WHERE CICDOrIdentityEvent.identity.type IN (
"automation_identity",
"service_account",
"workload_identity",
"deploy_account",
"cloud_role",
"kubernetes_identity",
"package_publishing_identity",
"image_publishing_identity",
"deployment_identity"
)

AND (
CICDOrIdentityEvent.use.context IN (
"outside_expected_repository",
"outside_expected_branch",
"outside_expected_workflow",
"outside_expected_runner",
"outside_expected_source_network",
"outside_expected_geography",
"outside_expected_time_window",
"outside_expected_deployment_path",
"rare_use_for_identity"
)

OR CICDOrIdentityEvent.repository.sensitivity IN (
"production_deployment",
"package_publishing",
"image_publishing",
"signing",
"infrastructure_as_code",
"cloud_deployment",
"kubernetes_deployment",
"high_value_repository"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_CICD_UPSTREAM_CONTEXT_WINDOW (
CICDOrGitOrEndpointEvent.event.action IN (
"recent_workflow_change",
"suspicious_pipeline_execution",
"recent_runner_registration",
"recent_runner_tag_change",
"recent_token_creation",
"recent_deploy_key_creation",
"recent_webhook_change",
"credential_access_behavior",
"unusual_runner_egress",
"registry_activity"
)
WHERE CICDOrGitOrEndpointEvent.repository.name IN SAME_REPOSITORY_OR_WORKFLOW(CICDOrIdentityEvent.repository.name)
)

FOLLOWED_BY WITHIN ENV_CICD_TO_CONTROL_PLANE_WINDOW

CloudKubernetesOrDeploymentEvent.event.action IN (
"cloud_api_called",
"iam_changed",
"role_assigned",
"access_key_created",
"secret_manager_accessed",
"container_registry_accessed",
"artifact_accessed",
"kubernetes_api_called",
"deployment_executed",
"infrastructure_as_code_executed",
"storage_accessed",
"function_modified",
"workload_modified",
"release_modified"
)

WHERE CloudKubernetesOrDeploymentEvent.user.name IN SAME_IDENTITY_OR_RELATED_WORKLOAD(CICDOrIdentityEvent.user.name)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_DOWNSTREAM_ANOMALY_WINDOW (
SecurityEvent.event.action IN (
"privileged_identity_use",
"production_environment_access",
"source_network_mismatch",
"region_mismatch",
"namespace_mismatch",
"secret_access",
"iam_privilege_change",
"kubernetes_role_binding_change",
"image_pull_secret_change",
"production_workload_change"
)
WHERE SecurityEvent.user.name IN SAME_IDENTITY(CloudKubernetesOrDeploymentEvent.user.name)
)

AND NOT ChangeContext IN (
"approved_deployment_workflow",
"approved_iac_deployment",
"approved_cloud_operations",
"approved_kubernetes_operations",
"approved_release_engineering",
"approved_package_publication",
"approved_image_publication",
"approved_security_testing",
"approved_incident_response"
)

QRadar

Detection Viability Assessment

QRadar has three rules for this EXP report.

·        QRadar is viable for detecting self-hosted Git platform compromise through repository workflow abuse where Git audit logs, CI/CD pipeline logs, runner telemetry, endpoint telemetry, identity logs, NDR telemetry, DNS logs, proxy logs, registry logs, package-service logs, artifact-store logs, cloud logs, Kubernetes logs, and deployment logs are ingested, parsed, and mapped into usable event properties.

·        QRadar is strongest where custom properties can preserve repository, project, group, branch, workflow, pipeline, job, runner, host, user, token, service-account, source IP, destination, registry, package, image, artifact, cloud identity, Kubernetes identity, and deployment context.

·        QRadar can build offenses across repository-control events, CI/CD execution events, runner behavior, automation credential changes, registry or package access, endpoint process activity, suspicious outbound communication, and downstream cloud or Kubernetes activity when event normalization and correlation timing are reliable.

·        QRadar is not a standalone source for confirming repository workflow compromise unless the required event sources are present, parsed consistently, and correlated through reliable identity, repository, runner, credential, host, and timestamp lineage.

·        QRadar detections must avoid treating single events as confirmed compromise. Workflow changes, token creation, runner activity, registry access, cloud API activity, endpoint process activity, or outbound communication should be treated as correlation anchors unless additional stages of the attack chain are visible.

·        QRadar detection content should support offense creation, SOC triage, lineage reconstruction, exposure scoping, and escalation where repository, CI/CD, runner, credential, endpoint, network, registry, cloud, Kubernetes, and deployment telemetry align.

·        QRadar rules should not generate high-confidence alerting from a workflow change alone, token creation alone, runner execution alone, registry access alone, cloud activity alone, endpoint process activity alone, or unusual outbound communication alone without supporting lineage and context.

Rule

Workflow Change Followed by CI/CD Runner Execution and Suspicious Host or Network Activity

Rule Format

QRadar correlation rule suitable for Git audit logs, CI/CD logs, runner events, endpoint telemetry, process events, network events, DNS events, proxy events, identity logs, registry logs, repository sensitivity enrichment, runner inventory, custom properties, reference sets, building blocks, and offense rules after log-source validation, custom-property validation, timing-window tuning, reference-set validation, and environment-specific allowlisting.

Detection Purpose

·        Detect repository workflow modification followed by CI/CD runner execution and suspicious host or network behavior.

·        Identify cases where trusted repository automation may be modified to execute unauthorized logic, inspect secrets, stage artifacts, retrieve payloads, use registry tooling, initiate outbound communication, or prepare downstream deployment activity.

·        Prioritize workflow changes involving sensitive repositories, protected branches, production deployment workflows, package-publishing workflows, container-build workflows, signing workflows, infrastructure-as-code workflows, cloud deployment workflows, Kubernetes deployment workflows, or high-value build paths.

·        Support escalation when workflow modification is followed by suspicious runner execution, credential inspection, environment-variable access, archive creation, outbound communication, registry access, package access, artifact access, cloud CLI use, or Kubernetes CLI use.

·        Preserve separation between suspicious workflow activity and confirmed compromise by requiring supporting CI/CD, runner, endpoint, network, registry, identity, cloud, Kubernetes, or incident-response evidence before classifying activity as probable compromise.

·        This rule does not prove repository compromise, credential theft, malicious package publication, image compromise, cloud compromise, Kubernetes compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify repository workflow file creation, modification, deletion, permission change, CI/CD configuration modification, build-script modification, deployment-script modification, release-script modification, package-publishing workflow change, container-build workflow change, or infrastructure-as-code workflow change.

·        Prioritize workflow changes made by newly privileged users, inactive users, unfamiliar maintainers, external contributors, unfamiliar bot accounts, service accounts, or accounts authenticating from unusual source infrastructure.

·        Correlate workflow changes with CI/CD pipeline execution, job execution, runner assignment, workflow execution, release execution, package-publishing execution, container-build execution, infrastructure-as-code execution, or deployment execution from the same repository, project, group, branch, workflow, runner, or job.

·        Detect suspicious runner-host activity involving shell interpreters, scripting engines, package managers, archive utilities, compression tools, network transfer tools, registry clients, container tooling, cloud CLIs, Kubernetes CLIs, credential helpers, or secret-management tools.

·        Prioritize command lines or normalized process events involving environment-variable inspection, protected-variable exposure, credential-location probing, secret-file access, recursive file collection, repository bundling, archive creation, remote retrieval, direct IP access, encoded execution, suspicious command chaining, artifact staging, cache access, registry authentication, or external transfer.

·        Prioritize network activity from the runner or build host to newly observed external destinations, unmanaged object storage, raw-file hosting, paste services, tunneling services, dynamic DNS, unknown external infrastructure, or destinations not approved for build and release workflows.

·        Increase confidence when the affected repository, runner, host, or workflow is associated with production deployment, package publication, image publication, signing, infrastructure-as-code, cloud deployment, Kubernetes deployment, or high-value build paths.

·        Reduce severity when activity matches approved workflow maintenance, release engineering, CI/CD refactoring, runner migration, package publication, container builds, infrastructure deployment, vulnerability scanning, security testing, incident response, or documented change-control activity.

·        Do not classify workflow modification or runner activity as compromise without suspicious execution, credential behavior, registry behavior, network behavior, downstream control-plane behavior, or incident-response validation.

·        Do not treat workflow modification, pipeline execution, shell execution, outbound communication, registry access, or cloud CLI execution as compromise evidence by itself.

Required Telemetry

·        Git audit logs.

·        Repository activity logs.

·        Workflow file change events.

·        CI/CD configuration change events.

·        Commit metadata.

·        Merge request or pull request metadata.

·        Protected-branch logs where available.

·        Approval-rule logs where available.

·        CI/CD pipeline logs.

·        CI/CD job logs.

·        Runner assignment logs.

·        Runner tag logs.

·        Runner registration logs where available.

·        Endpoint process telemetry from runners and build hosts.

·        Command-line telemetry where available.

·        Parent process and process lineage where available.

·        File creation and file modification telemetry where available.

·        Network-flow telemetry.

·        DNS logs.

·        Proxy logs where available.

·        Firewall logs where available.

·        Registry logs where available.

·        Package-service logs where available.

·        Artifact-store logs where available.

·        Cloud audit logs where available.

·        Kubernetes audit logs where available.

·        Identity logs.

·        User identity.

·        Service-account identity where available.

·        Source IP.

·        Destination IP.

·        Destination domain.

·        Destination category where available.

·        Repository.

·        Project or group.

·        Branch.

·        Workflow file path.

·        Pipeline ID.

·        Job ID.

·        Runner ID.

·        Runner host.

·        Runner tag.

·        Timestamp.

·        Repository sensitivity enrichment.

·        Runner inventory.

·        QRadar log-source identifiers.

·        QRadar custom properties.

·        QRadar reference sets for approved runners, repositories, destinations, workflows, and change windows.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build QRadar log-source groups for Git platforms, CI/CD systems, runner hosts, endpoint telemetry, proxy logs, DNS logs, firewall logs, registry logs, package-service logs, cloud logs, Kubernetes logs, identity logs, and deployment logs.

·        Build custom properties for repository, project, group, branch, workflow file, pipeline ID, job ID, runner ID, runner host, runner tag, actor, service account, token identifier where available, source IP, destination domain, destination IP, destination category, action, result, and timestamp.

·        Build reference sets for sensitive repositories, production deployment workflows, package-publishing workflows, image-publishing workflows, signing workflows, infrastructure-as-code workflows, cloud deployment workflows, Kubernetes deployment workflows, approved runners, approved destinations, approved workflow-change windows, and approved release windows.

·        Build building blocks for workflow modification, suspicious actor context, pipeline execution, runner execution, suspicious process activity, suspicious command-line activity, unusual outbound communication, registry access, package access, artifact access, cloud activity, and Kubernetes activity.

·        Build offense logic that requires workflow modification plus CI/CD execution plus either suspicious runner-host activity, suspicious outbound communication, registry activity, package activity, artifact activity, or downstream control-plane activity.

·        Validate QRadar parsing for Git, CI/CD, endpoint, network, registry, package, cloud, Kubernetes, identity, and deployment events before enabling alerting.

·        Validate custom-property extraction consistency across all relevant log sources.

·        Validate reference-set population, reference-set expiration behavior, update cadence, and owner accountability.

·        Use short correlation windows when workflow modification is followed immediately by pipeline execution or runner activity.

·        Use moderate correlation windows when workflow modification is followed by delayed runner execution, registry access, artifact movement, outbound communication, cloud activity, or Kubernetes activity.

·        Use longer correlation windows only when CI/CD lineage, repeated runner behavior, identity evidence, registry evidence, cloud evidence, Kubernetes evidence, or incident-response evidence supports delayed linkage.

·        Add severity weighting for sensitive repository class, privileged actor, protected branch, suspicious runner command, credential inspection, external transfer, registry activity, cloud activity, Kubernetes activity, and absence of approved change context.

·        Treat workflow modification as a confidence anchor, not standalone proof of compromise.

·        Build exceptions for approved workflow refactoring, release engineering, runner migration, package-publication changes, infrastructure deployment, vulnerability scanning, security testing, incident response, and known automation.

·        Do not enable alert mode until log-source coverage, custom properties, reference sets, building blocks, timing windows, false-positive rate, rule performance, SOC triage workflow, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.4 / 10

·        The rule is behaviorally anchored to workflow modification followed by CI/CD runner activity and suspicious host or network behavior rather than static indicators, CVE identifiers, domains, IP addresses, hashes, package names, image names, or repository names.

·        The rule remains useful if an adversary changes workflow filename, repository path, command syntax, runner host, interpreter, transfer utility, registry client, cloud CLI, Kubernetes CLI, destination, or timing.

·        The score is supported by the durability of repository-control activity followed by trusted automation execution, credential inspection, archive creation, artifact staging, registry access, outbound communication, cloud tooling, and Kubernetes tooling.

·        The score is constrained by incomplete Git audit logs, missing CI/CD job detail, weak runner identity mapping, incomplete command-line telemetry, parser inconsistencies, and QRadar custom-property gaps.

·        The rule is durable as a repository-to-runner correlation detector but should not be treated as standalone proof of credential theft, package compromise, cloud compromise, Kubernetes compromise, or actor attribution.

TCR Assessment

Operational TCR

7.6 / 10

Full-Telemetry TCR

8.8 / 10

·        Operational confidence depends on Git audit coverage, CI/CD log coverage, runner identity mapping, command-line visibility, repository sensitivity enrichment, custom-property extraction, reference-set quality, and QRadar offense correlation quality.

·        Operational confidence is reduced where workflow changes are frequent, CI/CD logs lack command detail, runner hosts are ephemeral, custom properties are inconsistent, or change-control records are incomplete.

·        Operational confidence is reduced during release engineering, CI/CD refactoring, runner migration, repository migration, package-publication changes, infrastructure deployment, vulnerability scanning, and incident-response activity.

·        Full-telemetry confidence improves when QRadar correlates Git audit logs, CI/CD logs, endpoint telemetry, DNS logs, proxy logs, registry logs, package logs, cloud logs, Kubernetes logs, identity logs, deployment logs, and change-control records.

·        Even under full telemetry conditions, this rule should support escalation and scoping rather than standalone confirmation of compromise.

Limitations

·        QRadar cannot correlate this behavior unless Git, CI/CD, endpoint, runner, identity, network, registry, cloud, and Kubernetes data are ingested and parsed consistently.

·        Workflow changes may be legitimate during normal release engineering, CI/CD refactoring, runner migration, repository migration, or infrastructure updates.

·        Runner execution may be noisy in high-change build environments.

·        Missing command-line telemetry, weak runner identity mapping, inconsistent repository naming, parser gaps, or incomplete custom properties can reduce confidence.

·        The rule may miss workflow abuse that uses approved workflows, expected runner commands, low-noise credential access, approved destinations, or normal release paths.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

QRadar workflow modification to suspicious runner activity query pattern requiring log-source validation, custom-property validation, reference-set validation, offense-rule validation, repository identity mapping, runner identity mapping, timestamp normalization, approved workflow allowlisting, timing-window tuning, and environment-specific false-positive testing before production deployment.

QRadarEvent AS WorkflowChange

WHERE WorkflowChange.EventName IN (
"workflow_file_created",
"workflow_file_modified",
"workflow_file_deleted",
"ci_config_modified",
"build_script_modified",
"deployment_script_modified",
"release_script_modified",
"protected_branch_changed",
"approval_rule_changed"
)

AND WorkflowChange.Repository IN REFERENCE_SET (
"Sensitive Repositories",
"Production Deployment Repositories",
"Package Publishing Repositories",
"Image Publishing Repositories",
"Signing Repositories",
"Infrastructure As Code Repositories",
"Cloud Deployment Repositories",
"Kubernetes Deployment Repositories"
)

AND (
WorkflowChange.ActorContext IN (
"newly_privileged_user",
"inactive_user",
"unfamiliar_maintainer",
"external_contributor",
"unfamiliar_bot_account",
"service_account",
"unusual_source_infrastructure"
)

OR WorkflowChange.SourceContext IN (
"rare_asn",
"unusual_geography",
"new_source_for_actor",
"source_not_in_actor_baseline"
)
)

FOLLOWED_BY WITHIN ENV_WORKFLOW_TO_PIPELINE_WINDOW

QRadarEvent AS PipelineExecution

WHERE PipelineExecution.EventName IN (
"pipeline_executed",
"job_executed",
"workflow_executed",
"release_workflow_executed",
"package_publishing_workflow_executed",
"container_build_workflow_executed",
"iac_workflow_executed",
"deployment_workflow_executed"
)

AND PipelineExecution.Repository IN SAME_REPOSITORY(WorkflowChange.Repository)

FOLLOWED_BY WITHIN ENV_PIPELINE_TO_RUNNER_WINDOW

QRadarEvent AS RunnerActivity

WHERE RunnerActivity.RunnerHost IN SAME_RUNNER(PipelineExecution.RunnerId)

AND (
RunnerActivity.ProcessName IN (
"bash",
"sh",
"powershell.exe",
"pwsh.exe",
"cmd.exe",
"python",
"python3",
"node",
"ruby",
"perl",
"curl",
"wget",
"tar",
"zip",
"docker",
"kubectl",
"helm",
"aws",
"az",
"gcloud",
"git",
"npm",
"pip"
)

OR RunnerActivity.CommandLine CONTAINS ANY (
"printenv",
"cat /proc/self/environ",
"credential",
"token",
"secret",
"private_key",
"id_rsa",
"kubeconfig",
".aws/credentials",
".docker/config.json",
"archive",
"upload",
"artifact",
"cache",
"registry",
"docker login",
"kubectl config",
"aws sts",
"az account",
"gcloud auth"
)

OR RunnerActivity.DestinationContext IN (
"new_external_destination",
"rare_destination_for_runner",
"unmanaged_object_storage",
"raw_file_hosting",
"paste_service",
"tunnel_service",
"dynamic_dns",
"unknown_external"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_RUNNER_FOLLOWON_WINDOW (
QRadarEvent AS FollowOnActivity
WHERE FollowOnActivity.RunnerHost IN SAME_HOST(RunnerActivity.RunnerHost)
AND FollowOnActivity.EventPattern IN (
"registry_authentication",
"package_access",
"artifact_access",
"image_push",
"cloud_api_activity",
"kubernetes_api_activity",
"deployment_activity",
"unusual_internal_service_access"
)
)

AND NOT ChangeContext IN (
"approved_workflow_refactor",
"approved_release_engineering",
"approved_runner_migration",
"approved_package_publication_change",
"approved_iac_deployment",
"approved_security_testing",
"approved_incident_response"
)

Rule

Automation Credential or Webhook Change Followed by Registry, Artifact, or Deployment Activity

Rule Format

QRadar automation-credential and downstream-activity correlation rule suitable for Git audit logs, CI/CD logs, identity logs, token lifecycle logs, deploy-key logs, webhook logs, OAuth application logs, service-account logs, runner logs, registry logs, package-service logs, artifact-store logs, deployment logs, cloud audit logs, Kubernetes audit logs, custom properties, reference sets, building blocks, and offense rules after log-source validation, custom-property validation, credential-lineage validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect creation or modification of automation credentials, deploy keys, access tokens, OAuth applications, webhooks, service accounts, workload identities, runner tokens, or automation identities followed by suspicious repository, registry, package, artifact, deployment, cloud, or Kubernetes activity.

·        Identify potential abuse of trusted Git and CI/CD automation paths tied to sensitive repositories, production deployment paths, package-publishing authority, image-publishing authority, signing authority, infrastructure-as-code control, cloud deployment, Kubernetes deployment, or high-value build systems.

·        Prioritize automation or webhook changes performed by newly privileged users, inactive users, unfamiliar maintainers, unfamiliar bot accounts, service accounts, external contributors, or accounts authenticating from unusual source infrastructure.

·        Support escalation when automation changes are followed by repository cloning, project export, pipeline execution, runner execution, artifact access, package access, image pull, image push, registry authentication, release modification, deployment activity, cloud API use, Kubernetes API use, or secret-manager access.

·        Preserve separation between suspicious automation activity and confirmed compromise by requiring supporting repository, CI/CD, identity, endpoint, registry, package, cloud, Kubernetes, deployment, or incident-response evidence before classifying compromise as confirmed.

·        This rule does not prove credential theft, token theft, webhook abuse, registry compromise, package compromise, cloud compromise, Kubernetes compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify creation, modification, scope expansion, permission change, unusual use, or destination change involving deploy keys, project access tokens, group access tokens, personal access tokens, OAuth applications, webhooks, service accounts, workload identities, runner tokens, or automation identities.

·        Prioritize automation changes affecting sensitive repositories, protected branches, production deployment workflows, package-publishing workflows, image-publishing workflows, signing workflows, infrastructure-as-code workflows, cloud deployment workflows, Kubernetes deployment workflows, or release automation.

·        Prioritize automation changes performed by newly privileged users, inactive users, unfamiliar maintainers, unfamiliar bot accounts, service accounts, external contributors, or accounts authenticating from unusual source infrastructure.

·        Correlate automation changes with follow-on repository cloning, project export, pipeline execution, runner execution, artifact access, package access, image pull, image push, registry authentication, release modification, deployment activity, cloud API activity, Kubernetes API activity, or secret-manager access.

·        Increase confidence when follow-on activity occurs outside expected repository, runner, branch, project, group, time window, geography, source network, device, environment, or deployment path.

·        Increase confidence when multiple automation credentials are created or modified in a short period, when credential scope is broader than expected, when a webhook destination is new or unfamiliar, or when service-account ownership is unclear.

·        Increase confidence when downstream activity is performed using the new or modified credential, related automation identity, related service account, related webhook destination, or source host associated with CI/CD infrastructure.

·        Reduce severity when activity matches approved integration onboarding, token rotation, deploy-key maintenance, webhook maintenance, runner migration, service-account rotation, release engineering, cloud operations, security testing, incident response, or documented change-control activity.

·        Do not classify automation credential creation, webhook creation, or service-account modification as compromise without follow-on use, suspicious scope, suspicious destination, actor-risk context, downstream activity, or incident-response validation.

·        Do not treat token creation, deploy-key creation, webhook creation, service-account changes, or OAuth application creation as compromise evidence by itself.

Required Telemetry

·        Git audit logs.

·        Repository access logs.

·        Deploy-key logs.

·        Token lifecycle logs.

·        Project access token logs.

·        Group access token logs.

·        Personal access token logs where available.

·        OAuth application logs.

·        Webhook logs.

·        Service-account logs.

·        Workload identity logs where available.

·        Runner registration logs.

·        Runner token logs where available.

·        CI/CD pipeline logs.

·        CI/CD job logs.

·        Runner telemetry.

·        Identity logs.

·        Endpoint telemetry where available.

·        Network telemetry where available.

·        Registry logs.

·        Package-service logs.

·        Artifact-store logs.

·        Release-system logs.

·        Deployment logs.

·        Cloud audit logs where available.

·        Kubernetes audit logs where available.

·        Actor identity.

·        Token or credential identifier where available.

·        Credential scope.

·        Credential permission level.

·        Webhook destination.

·        Webhook response status where available.

·        OAuth application identifier where available.

·        Service-account identifier where available.

·        Repository.

·        Project or group.

·        Branch.

·        Workflow.

·        Pipeline ID.

·        Runner ID.

·        Source IP.

·        Source ASN and source geography where available.

·        Destination service.

·        Action.

·        Result.

·        Timestamp.

·        Repository sensitivity enrichment.

·        Automation identity inventory.

·        Service-account inventory.

·        Approved token inventory.

·        Approved webhook inventory.

·        Approved deploy-key inventory.

·        Approved integration records.

·        QRadar custom properties.

·        QRadar reference sets.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build QRadar log-source groups for Git platforms, CI/CD systems, identity providers, token lifecycle events, webhook events, OAuth events, service-account events, runner events, endpoint telemetry, network telemetry, registry logs, package-service logs, artifact-store logs, deployment logs, cloud logs, and Kubernetes logs.

·        Build custom properties for credential identifier, token identifier, token scope, credential permission level, deploy key, webhook destination, webhook response status, OAuth application identifier, service account, workload identity, actor, repository, project, group, branch, workflow, pipeline, runner, source IP, destination service, action, result, and timestamp.

·        Build reference sets for approved tokens, approved deploy keys, approved webhooks, approved service accounts, approved OAuth applications, approved automation identities, sensitive repositories, approved integration destinations, approved token-rotation windows, approved webhook-maintenance windows, and approved release windows.

·        Build building blocks for automation credential creation, credential scope expansion, webhook creation, webhook destination change, OAuth application creation, service-account modification, suspicious actor context, suspicious source context, repository access, registry activity, package activity, artifact activity, deployment activity, cloud activity, and Kubernetes activity.

·        Build offense logic that requires an automation credential or webhook change plus follow-on repository, registry, package, artifact, deployment, cloud, or Kubernetes activity with actor-risk, credential-scope, destination, timing, or sensitivity context.

·        Build credential-lineage logic that maps credential identifier, automation identity, service account, webhook destination, runner token, project, group, repository, branch, pipeline, runner, source host, and downstream action where telemetry permits.

·        Validate QRadar parsing for token lifecycle logs, webhook logs, OAuth logs, service-account logs, Git audit logs, CI/CD logs, registry logs, package logs, cloud logs, Kubernetes logs, and deployment logs.

·        Validate custom-property extraction consistency for credential identifiers, webhook destinations, service-account identifiers, repository names, runner identifiers, timestamps, and downstream action fields.

·        Validate reference-set ownership, update cadence, expiration behavior, and exception review.

·        Use short correlation windows when automation changes are followed immediately by pipeline execution, registry activity, repository access, webhook delivery, or deployment activity.

·        Use moderate correlation windows for delayed package access, image activity, artifact access, cloud activity, Kubernetes activity, or deployment activity after automation changes.

·        Use longer correlation windows only when credential lineage, webhook lineage, identity evidence, CI/CD evidence, cloud evidence, registry evidence, or incident-response evidence supports delayed linkage.

·        Add severity weighting for sensitive repository scope, broad credential permissions, privileged actor, unusual source infrastructure, new webhook destination, package publication authority, image publication authority, production deployment authority, cloud deployment authority, Kubernetes deployment authority, and follow-on use.

·        Treat automation changes as confidence anchors, not standalone proof of compromise.

·        Build exceptions for approved token rotation, deploy-key maintenance, webhook onboarding, integration onboarding, runner migration, service-account rotation, release engineering, cloud operations, security testing, incident response, and known automation.

·        Do not enable alert mode until log-source coverage, credential lineage, token scope mapping, webhook validation, custom-property extraction, reference-set quality, false-positive rate, rule performance, SOC triage workflow, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.3 / 10

·        The rule is behaviorally anchored to automation credential and webhook changes followed by downstream use rather than static indicators, fixed token names, repository names, domains, IP addresses, package names, image names, hashes, or CVE identifiers.

·        The rule remains useful if an adversary changes credential type, token name, webhook destination, service account, repository path, runner host, registry endpoint, package, image, cloud service, or timing.

·        The score is supported by the durability of credential creation, scope expansion, webhook creation, webhook destination change, OAuth application creation, service-account changes, and follow-on repository, registry, artifact, deployment, cloud, or Kubernetes activity.

·        The score is constrained by incomplete token lifecycle logging, missing credential identifiers, poor webhook visibility, weak service-account mapping, and legitimate integration onboarding or token rotation.

·        The rule is durable as automation lineage coverage but should not be treated as standalone proof of credential theft, webhook abuse, cloud compromise, registry compromise, or actor attribution.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

8.7 / 10

·        Operational confidence depends on Git audit coverage, token lifecycle logging, deploy-key visibility, webhook visibility, service-account mapping, identity enrichment, downstream registry or cloud visibility, QRadar custom-property extraction, reference-set quality, and offense correlation quality.

·        Operational confidence is reduced where token identifiers are masked, credential scope is unavailable, webhook destination logging is incomplete, service-account ownership is unclear, or downstream activity cannot be tied to the credential or webhook.

·        Operational confidence is reduced during integration onboarding, token rotation, deploy-key maintenance, service-account rotation, runner migration, release engineering, cloud operations, and incident-response activity.

·        Full-telemetry confidence improves when QRadar correlates credential lifecycle events with CI/CD logs, registry logs, package logs, artifact logs, endpoint telemetry, network telemetry, cloud logs, Kubernetes logs, identity logs, and change-control records.

·        Even under full telemetry conditions, this rule should support escalation and lineage reconstruction rather than standalone confirmation of compromise.

Limitations

·        QRadar cannot prove credential theft, token theft, or webhook abuse unless follow-on use, unauthorized activity, or incident-response evidence supports that conclusion.

·        Some Git and CI/CD platforms may mask token identifiers, reduce token lifecycle visibility, or omit webhook payload details.

·        Legitimate integration onboarding, token rotation, service-account rotation, webhook maintenance, and runner migration can resemble suspicious automation activity.

·        Weak credential lineage, inconsistent repository naming, incomplete service-account mapping, incomplete webhook logging, parser gaps, or missing downstream logs can reduce confidence.

·        The rule may miss abuse of existing long-lived credentials or webhooks if no recent creation, modification, or scope change is visible.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

QRadar automation credential or webhook change to downstream activity query pattern requiring log-source validation, custom-property validation, credential identifier validation, token scope validation, webhook field validation, service-account mapping, reference-set validation, downstream lineage validation, approved integration allowlisting, timing-window tuning, and environment-specific false-positive testing before production deployment.

QRadarEvent AS AutomationChange

WHERE AutomationChange.EventName IN (
"deploy_key_created",
"deploy_key_modified",
"project_token_created",
"group_token_created",
"personal_access_token_created",
"token_scope_changed",
"token_permission_changed",
"oauth_application_created",
"webhook_created",
"webhook_modified",
"webhook_destination_changed",
"service_account_created",
"service_account_modified",
"workload_identity_changed",
"runner_token_created",
"automation_identity_changed"
)

AND AutomationChange.Repository IN REFERENCE_SET (
"Sensitive Repositories",
"Production Deployment Repositories",
"Package Publishing Repositories",
"Image Publishing Repositories",
"Signing Repositories",
"Infrastructure As Code Repositories",
"Cloud Deployment Repositories",
"Kubernetes Deployment Repositories"
)

AND (
AutomationChange.ActorContext IN (
"newly_privileged_user",
"inactive_user",
"unfamiliar_maintainer",
"unfamiliar_bot_account",
"service_account",
"external_contributor",
"unusual_source_infrastructure"
)

OR AutomationChange.CredentialContext IN (
"broad_scope",
"long_expiration",
"privileged_scope",
"registry_scope",
"api_scope",
"write_scope",
"deployment_scope",
"new_or_unfamiliar_webhook_destination"
)
)

FOLLOWED_BY WITHIN ENV_AUTOMATION_CHANGE_TO_USE_WINDOW

QRadarEvent AS DownstreamActivity

WHERE DownstreamActivity.EventName IN (
"repository_cloned",
"project_exported",
"pipeline_executed",
"runner_executed",
"artifact_accessed",
"package_accessed",
"image_pulled",
"image_pushed",
"registry_authenticated",
"release_modified",
"deployment_executed",
"cloud_api_called",
"kubernetes_api_called",
"secret_manager_accessed",
"infrastructure_modified"
)

AND (
DownstreamActivity.CredentialId IN SAME_CREDENTIAL_OR_RELATED_IDENTITY(AutomationChange.CredentialId)
OR DownstreamActivity.Actor IN SAME_AUTOMATION_IDENTITY(AutomationChange.Actor)
OR DownstreamActivity.Repository IN SAME_REPOSITORY_OR_GROUP(AutomationChange.Repository)
OR DownstreamActivity.DestinationDomain IN SAME_WEBHOOK_DESTINATION(AutomationChange.WebhookDestination)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_DOWNSTREAM_ANOMALY_WINDOW (
QRadarEvent AS DownstreamAnomaly
WHERE DownstreamAnomaly.EventPattern IN (
"outside_expected_repository",
"outside_expected_runner",
"outside_expected_branch",
"outside_expected_time_window",
"outside_expected_source_network",
"outside_expected_geography",
"outside_expected_deployment_path",
"multiple_credential_changes",
"multiple_sensitive_repositories_accessed"
)
AND DownstreamAnomaly.Actor IN SAME_ACTOR_OR_AUTOMATION_IDENTITY(DownstreamActivity.Actor)
)

AND NOT ChangeContext IN (
"approved_token_rotation",
"approved_deploy_key_maintenance",
"approved_webhook_onboarding",
"approved_integration_onboarding",
"approved_runner_migration",
"approved_service_account_rotation",
"approved_release_engineering",
"approved_cloud_operations",
"approved_security_testing",
"approved_incident_response"
)

Rule

CI/CD-Linked Identity Use Followed by Cloud, Kubernetes, or Deployment Activity

Rule Format

QRadar CI/CD-to-control-plane correlation rule suitable for CI/CD logs, Git audit logs, identity logs, runner logs, endpoint telemetry, NDR telemetry, registry logs, cloud audit logs, Kubernetes audit logs, deployment logs, secret-manager logs, custom properties, reference sets, building blocks, and offense rules after log-source validation, identity mapping, credential-lineage validation, source-network validation, downstream-action validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious use of CI/CD-linked credentials, automation identities, service accounts, workload identities, deploy accounts, cloud roles, Kubernetes identities, package-publishing identities, image-publishing identities, or deployment identities followed by cloud, Kubernetes, deployment, registry, secret-manager, storage, or infrastructure activity.

·        Identify potential downstream expansion after repository workflow abuse, credential exposure, token exposure, runner compromise, malicious pipeline execution, or automation identity misuse.

·        Prioritize downstream activity occurring outside expected repository, branch, workflow, runner, source network, geography, project, namespace, region, account, subscription, tenant, environment, deployment path, or approved time window.

·        Support escalation when suspicious CI/CD-linked identity use follows workflow modification, token creation, deploy-key creation, webhook modification, runner changes, suspicious runner execution, credential access, registry activity, or unusual outbound communication.

·        Preserve separation between suspicious downstream control-plane activity and confirmed compromise by requiring repository, CI/CD, identity, endpoint, network, registry, cloud, Kubernetes, deployment, or incident-response evidence before classifying compromise as confirmed.

·        This rule does not prove repository compromise, credential theft, cloud compromise, Kubernetes compromise, deployment compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify use of CI/CD-linked credentials, automation identities, service accounts, workload identities, deploy accounts, cloud roles, Kubernetes identities, package-publishing identities, image-publishing identities, or deployment identities.

·        Prioritize use outside expected repository, branch, workflow, runner, source network, geography, project, namespace, region, account, subscription, tenant, environment, deployment path, or approved time window.

·        Detect follow-on activity involving cloud API calls, IAM changes, role assignment, access-key creation, secret-manager access, container registry access, artifact access, Kubernetes API activity, deployment execution, infrastructure-as-code execution, storage access, function changes, workload changes, or release activity.

·        Correlate downstream activity with suspicious upstream context, including workflow modification, suspicious pipeline execution, new runner registration, runner tag change, token creation, deploy-key creation, webhook modification, OAuth application creation, protected-branch change, credential access, unusual outbound communication, or registry activity.

·        Increase confidence when the same identity, token, runner host, service account, workload identity, source IP, pipeline, repository, deployment account, or incident timeline connects upstream CI/CD activity to downstream control-plane activity.

·        Increase confidence when downstream actions modify identity, privileges, secrets, networking, storage, container images, deployment manifests, infrastructure templates, Kubernetes role bindings, image-pull secrets, or production workloads.

·        Increase confidence when control-plane activity is rare for the identity, new for the environment, outside the expected region or namespace, or inconsistent with the account’s normal role.

·        Reduce severity when activity matches approved deployment workflows, infrastructure deployment, cloud operations, Kubernetes operations, release engineering, package publication, image publication, vulnerability scanning, security testing, incident response, or documented change-control activity.

·        Do not attribute cloud, Kubernetes, or deployment activity to repository workflow compromise without identity, timing, runner, repository, credential, source-network, or incident-response linkage.

·        Do not treat cloud API activity, Kubernetes API activity, deployment activity, registry activity, or secret-manager activity as compromise evidence by itself.

Required Telemetry

·        CI/CD pipeline logs.

·        CI/CD job logs.

·        Runner logs.

·        Git audit logs.

·        Identity logs.

·        Service-account logs.

·        Workload identity logs where available.

·        Token lifecycle logs where available.

·        Endpoint telemetry from runners where available.

·        NDR telemetry where available.

·        DNS logs where available.

·        Proxy logs where available.

·        Registry logs.

·        Package-service logs where available.

·        Artifact-store logs where available.

·        Cloud audit logs.

·        Kubernetes audit logs.

·        Deployment platform logs.

·        Secret-manager logs where available.

·        Infrastructure-as-code execution logs where available.

·        User identity.

·        Automation identity.

·        Service-account identity.

·        Workload identity.

·        Credential identifier where available.

·        Runner ID.

·        Runner host.

·        Repository.

·        Branch.

·        Workflow.

·        Pipeline ID.

·        Job ID.

·        Source IP.

·        Source ASN and source geography where available.

·        Cloud account, project, subscription, tenant, or region.

·        Kubernetes cluster, namespace, service account, and role binding where available.

·        Deployment environment.

·        Resource action.

·        Result.

·        Timestamp.

·        Repository sensitivity enrichment.

·        CI/CD credential inventory.

·        Cloud identity inventory.

·        Kubernetes identity inventory.

·        Deployment account inventory.

·        QRadar custom properties.

·        QRadar reference sets.

·        Approved deployment records.

·        Approved cloud operation records.

·        Approved Kubernetes operation records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build QRadar log-source groups for CI/CD systems, Git platforms, identity providers, endpoint telemetry, NDR telemetry, registry logs, package logs, cloud logs, Kubernetes logs, deployment logs, secret-manager logs, and infrastructure-as-code execution logs.

·        Build custom properties for automation identity, service account, workload identity, deploy account, cloud role, Kubernetes identity, runner ID, runner host, repository, branch, workflow, pipeline ID, job ID, source IP, cloud account, cloud project, subscription, tenant, region, Kubernetes cluster, namespace, resource action, result, and timestamp.

·        Build reference sets for CI/CD credentials, automation identities, service accounts, workload identities, deploy accounts, cloud roles, Kubernetes identities, deployment identities, approved source networks, approved deployment windows, approved cloud operations, approved Kubernetes operations, and sensitive repositories.

·        Build downstream control-plane building blocks for cloud API calls, IAM changes, role assignment, access-key creation, secret-manager access, registry access, artifact access, Kubernetes API activity, deployment execution, infrastructure-as-code execution, storage access, function changes, workload changes, and release activity.

·        Build upstream suspicious context building blocks for workflow modification, suspicious pipeline execution, runner changes, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, registry activity, and suspicious endpoint behavior.

·        Build lineage logic mapping identity, credential, token, runner host, source IP, pipeline, repository, deployment account, service account, workload identity, and incident timeline.

·        Validate QRadar parsing for CI/CD logs, Git audit logs, identity logs, endpoint telemetry, NDR telemetry, registry logs, package logs, cloud logs, Kubernetes logs, deployment logs, and incident-response evidence.

·        Validate custom-property extraction consistency for identity, credential, runner, repository, source network, cloud, Kubernetes, deployment, and timestamp fields.

·        Validate reference-set ownership, update cadence, expiration behavior, and exception review.

·        Use short correlation windows when downstream control-plane activity occurs during or immediately after suspicious CI/CD execution.

·        Use moderate correlation windows when downstream activity follows workflow modification, runner changes, token creation, credential access, unusual egress, or registry activity.

·        Use longer correlation windows only when identity lineage, cloud evidence, Kubernetes evidence, endpoint evidence, CI/CD lineage, or incident-response evidence supports delayed linkage.

·        Add severity weighting for privileged identity use, production deployment access, secret-manager access, IAM changes, role assignments, access-key creation, Kubernetes role binding changes, image-pull secret changes, production workload changes, sensitive storage access, and source-network mismatch.

·        Treat downstream control-plane activity as a confidence amplifier unless linked to suspicious CI/CD, credential, runner, identity, source-network, or incident-response evidence.

·        Build exceptions for approved deployment workflows, infrastructure deployment, cloud operations, Kubernetes operations, release engineering, package publication, image publication, vulnerability scanning, security testing, incident response, and known automation.

·        Do not enable alert mode until log-source coverage, identity mapping, credential lineage, source-network validation, reference-set quality, custom-property extraction, expected-use baselines, false-positive rate, rule performance, SOC triage workflow, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.4 / 10

·        The rule is behaviorally anchored to CI/CD-linked identity use followed by cloud, Kubernetes, or deployment activity rather than static domains, IP addresses, hashes, repository names, package names, image names, or CVE identifiers.

·        The rule remains useful if an adversary changes workflow content, runner host, cloud service, Kubernetes namespace, deployment target, source infrastructure, credential type, identity type, tool sequence, or timing.

·        The score is supported by the durability of automation identity use, cloud API activity, Kubernetes API activity, deployment execution, secret-manager access, registry access, IAM changes, role assignments, source-network mismatch, and unexpected production-environment activity.

·        The score is constrained by identity federation complexity, weak credential lineage, incomplete source IP preservation, noisy deployment activity, inconsistent cloud and Kubernetes logging, custom-property gaps, and legitimate automation workflows.

·        The rule is durable as CI/CD-to-control-plane correlation coverage but should not be treated as standalone proof of repository workflow compromise, credential theft, cloud compromise, Kubernetes compromise, or actor attribution.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

8.7 / 10

·        Operational confidence depends on CI/CD logs, identity logs, cloud audit logs, Kubernetes audit logs, deployment logs, credential lineage, source-network preservation, repository sensitivity mapping, custom-property extraction, reference-set quality, and QRadar offense correlation quality.

·        Operational confidence is reduced where identity federation obscures the initiating repository, source IPs are transformed, cloud sessions are reused, workload identities are shared, deployment logs lack pipeline context, or QRadar field extraction is incomplete.

·        Operational confidence is reduced during normal infrastructure deployment, release engineering, cloud operations, Kubernetes operations, image publication, package publication, vulnerability scanning, and incident-response activity.

·        Full-telemetry confidence improves when QRadar correlates CI/CD logs, Git audit logs, runner endpoint telemetry, NDR telemetry, registry logs, package logs, cloud logs, Kubernetes logs, identity logs, deployment logs, and change-control records.

·        Even under full telemetry conditions, this rule should support downstream exposure scoping and containment prioritization rather than standalone confirmation of compromise.

Limitations

·        QRadar cannot attribute cloud, Kubernetes, or deployment activity to repository workflow compromise without reliable identity, runner, repository, credential, source-network, or timing linkage.

·        Federated identity, workload identity, shared service accounts, NAT, proxying, cloud session reuse, and token reuse can obscure lineage.

·        Legitimate deployment workflows and cloud operations can closely resemble suspicious downstream activity.

·        Missing cloud logs, missing Kubernetes logs, weak source IP preservation, incomplete deployment logs, inconsistent identity mapping, parser gaps, or incomplete custom properties can reduce confidence.

·        The rule may miss downstream abuse that uses expected deployment paths, approved identities, normal source networks, or delayed execution outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

QRadar CI/CD-linked identity use to cloud, Kubernetes, or deployment activity query pattern requiring log-source validation, custom-property validation, identity mapping, credential-lineage validation, source-network validation, downstream-action validation, reference-set validation, approved workflow allowlisting, timing-window tuning, and environment-specific false-positive testing before production deployment.

QRadarEvent AS SuspiciousCICDIdentityUse

WHERE SuspiciousCICDIdentityUse.IdentityType IN (
"automation_identity",
"service_account",
"workload_identity",
"deploy_account",
"cloud_role",
"kubernetes_identity",
"package_publishing_identity",
"image_publishing_identity",
"deployment_identity"
)

AND (
SuspiciousCICDIdentityUse.UseContext IN (
"outside_expected_repository",
"outside_expected_branch",
"outside_expected_workflow",
"outside_expected_runner",
"outside_expected_source_network",
"outside_expected_geography",
"outside_expected_time_window",
"outside_expected_deployment_path",
"rare_use_for_identity"
)

OR SuspiciousCICDIdentityUse.Repository IN REFERENCE_SET (
"Production Deployment Repositories",
"Package Publishing Repositories",
"Image Publishing Repositories",
"Signing Repositories",
"Infrastructure As Code Repositories",
"Cloud Deployment Repositories",
"Kubernetes Deployment Repositories",
"High Value Repositories"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_CICD_UPSTREAM_CONTEXT_WINDOW (
QRadarEvent AS UpstreamSuspiciousContext
WHERE UpstreamSuspiciousContext.Repository IN SAME_REPOSITORY_OR_WORKFLOW(SuspiciousCICDIdentityUse.Repository)
AND UpstreamSuspiciousContext.EventPattern IN (
"recent_workflow_change",
"suspicious_pipeline_execution",
"recent_runner_registration",
"recent_runner_tag_change",
"recent_token_creation",
"recent_deploy_key_creation",
"recent_webhook_change",
"credential_access_behavior",
"unusual_runner_egress",
"registry_activity"
)
)

FOLLOWED_BY WITHIN ENV_CICD_TO_CONTROL_PLANE_WINDOW

QRadarEvent AS DownstreamControlPlaneActivity

WHERE DownstreamControlPlaneActivity.Identity IN SAME_IDENTITY_OR_RELATED_WORKLOAD(SuspiciousCICDIdentityUse.Identity)

AND DownstreamControlPlaneActivity.EventName IN (
"cloud_api_called",
"iam_changed",
"role_assigned",
"access_key_created",
"secret_manager_accessed",
"container_registry_accessed",
"artifact_accessed",
"kubernetes_api_called",
"deployment_executed",
"infrastructure_as_code_executed",
"storage_accessed",
"function_modified",
"workload_modified",
"release_modified"
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_DOWNSTREAM_ANOMALY_WINDOW (
QRadarEvent AS DownstreamAnomaly
WHERE DownstreamAnomaly.Identity IN SAME_IDENTITY(DownstreamControlPlaneActivity.Identity)
AND DownstreamAnomaly.EventPattern IN (
"privileged_identity_use",
"production_environment_access",
"source_network_mismatch",
"region_mismatch",
"namespace_mismatch",
"secret_access",
"iam_privilege_change",
"kubernetes_role_binding_change",
"image_pull_secret_change",
"production_workload_change"
)
)

AND NOT ChangeContext IN (
"approved_deployment_workflow",
"approved_iac_deployment",
"approved_cloud_operations",
"approved_kubernetes_operations",
"approved_release_engineering",
"approved_package_publication",
"approved_image_publication",
"approved_security_testing",
"approved_incident_response"
)

SIGMA

Detection Viability Assessment

SIGMA has three rules for this EXP report.

·        SIGMA is viable for this report as a portable detection-pattern format for repository workflow abuse, CI/CD runner misuse, automation credential changes, suspicious runner-host execution, and downstream cloud or deployment activity where local SIEMs can map the required fields.

·        SIGMA is strongest when used as implementation-ready detection logic that can be translated into Splunk, Elastic, QRadar, Sentinel, Chronicle, or other SIEM platforms after local field mapping, log-source validation, correlation translation, and false-positive testing.

·        SIGMA should not be treated as a fully deployable rule format by itself because platform-specific field names, event identifiers, indexes, sourcetypes, data streams, custom properties, parser behavior, and correlation syntax vary across environments.

·        SIGMA detections for this report should focus on durable behavior: workflow modification, suspicious CI/CD execution, runner process activity, automation credential changes, webhook changes, registry activity, package activity, artifact activity, cloud activity, Kubernetes activity, and deployment activity.

·        SIGMA rules must avoid single-event overclaiming. Workflow changes, token creation, runner process execution, registry access, package access, cloud activity, or deployment activity should be treated as detection anchors unless correlated with supporting telemetry.

·        SIGMA content should support local SIEM engineering, hunt-mode deployment, rule translation, and consistent detection coverage across environments with different telemetry pipelines.

·        SIGMA rules should not generate high-confidence alerting from a single Git event, CI/CD event, endpoint event, registry event, cloud event, or network event without supporting repository, runner, credential, identity, registry, cloud, Kubernetes, or deployment context.

Rule

Repository Workflow Modification Followed by Suspicious CI/CD Runner Execution

Rule Format

SIGMA portable correlation-pattern rule suitable for Git audit logs, CI/CD pipeline logs, runner telemetry, endpoint process telemetry, command-line telemetry, identity logs, network telemetry, registry logs, package-service logs, cloud logs, Kubernetes logs, and deployment logs after local log-source mapping, field normalization, sequence translation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect repository workflow modification followed by suspicious CI/CD runner execution or build-host process activity.

·        Identify behavior consistent with repository workflow abuse, malicious CI/CD job execution, credential inspection, protected-variable exposure, artifact staging, source-code bundling, payload retrieval, registry tooling, cloud tooling, Kubernetes tooling, or downstream deployment preparation.

·        Prioritize sensitive repositories, protected branches, package-publishing workflows, container-build workflows, signing workflows, infrastructure-as-code workflows, cloud deployment workflows, Kubernetes deployment workflows, production deployment workflows, and high-value build paths.

·        Provide portable detection logic that can be translated into platform-specific SIEM rules after field mapping and validation.

·        Preserve separation between suspicious workflow activity and confirmed compromise by requiring supporting CI/CD, runner, endpoint, network, registry, identity, cloud, Kubernetes, deployment, or incident-response evidence before classifying compromise as confirmed.

·        This rule does not prove repository compromise, credential theft, token theft, malicious package publication, image compromise, cloud compromise, Kubernetes compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify repository workflow file creation, modification, deletion, permission change, CI/CD configuration modification, build-script modification, deployment-script modification, release-script modification, package-publishing workflow change, container-build workflow change, or infrastructure-as-code workflow change.

·        Prioritize workflow changes made by newly privileged users, inactive users, unfamiliar maintainers, external contributors, unfamiliar bot accounts, service accounts, or accounts authenticating from unusual source infrastructure.

·        Correlate workflow changes with CI/CD pipeline execution, job execution, runner assignment, workflow execution, release execution, package-publishing execution, container-build execution, infrastructure-as-code execution, or deployment execution from the same repository, project, group, branch, workflow, runner, or job.

·        Detect suspicious runner-host process activity involving shell interpreters, scripting engines, package managers, archive utilities, compression tools, network transfer tools, registry clients, container tooling, cloud CLIs, Kubernetes CLIs, credential helpers, or secret-management tools.

·        Prioritize command lines involving environment-variable inspection, protected-variable exposure, credential-location probing, secret-file access, recursive file collection, repository bundling, archive creation, remote retrieval, direct IP access, encoded execution, suspicious command chaining, artifact staging, cache access, registry authentication, cloud role discovery, or external transfer.

·        Increase confidence when the repository, runner, workflow, or host is associated with production deployment, package publication, image publication, signing, infrastructure-as-code, cloud deployment, Kubernetes deployment, or high-value application delivery.

·        Increase confidence when runner activity is followed by outbound communication, registry authentication, package access, artifact access, image activity, cloud API activity, Kubernetes API activity, deployment activity, or unusual internal service access.

·        Reduce severity when activity matches approved workflow maintenance, release engineering, CI/CD refactoring, runner migration, package publication, container builds, infrastructure deployment, vulnerability scanning, security testing, incident response, or documented change-control activity.

·        Do not classify workflow modification or runner process activity as compromise without suspicious execution, credential behavior, registry behavior, network behavior, downstream control-plane behavior, or incident-response validation.

·        Do not treat workflow modification, pipeline execution, shell execution, package-manager activity, archive creation, registry client execution, cloud CLI execution, Kubernetes CLI execution, or outbound communication as compromise evidence by itself.

Required Telemetry

·        Git audit logs.

·        Repository activity logs.

·        Workflow file change events.

·        CI/CD configuration change events.

·        Commit metadata.

·        Merge request or pull request metadata.

·        Protected-branch logs where available.

·        Approval-rule logs where available.

·        CI/CD pipeline logs.

·        CI/CD job logs.

·        Runner assignment logs.

·        Runner tag logs.

·        Runner registration logs where available.

·        Endpoint process telemetry from runners and build hosts.

·        Command-line telemetry from runners and build hosts.

·        Parent process and process lineage where available.

·        File creation and file modification telemetry where available.

·        Network connection telemetry.

·        DNS logs where available.

·        Proxy logs where available.

·        Firewall logs where available.

·        Registry logs where available.

·        Package-service logs where available.

·        Artifact-store logs where available.

·        Cloud audit logs where available.

·        Kubernetes audit logs where available.

·        Identity logs.

·        User identity.

·        Service-account identity where available.

·        Source IP.

·        Destination IP.

·        Destination domain.

·        Destination category where available.

·        Repository.

·        Project or group.

·        Branch.

·        Workflow file path.

·        Pipeline ID.

·        Job ID.

·        Runner ID.

·        Runner host.

·        Runner tag.

·        Timestamp.

·        Repository sensitivity enrichment.

·        Runner inventory.

·        Approved workflow-change baselines.

·        Approved release records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Treat the SIGMA rule as a portable detection pattern requiring translation into the target SIEM’s native syntax before deployment.

·        Map Git, CI/CD, runner, endpoint, network, identity, registry, package, cloud, Kubernetes, and deployment fields into the local SIEM schema before enabling the rule.

·        Build workflow-change selections for workflow file modification, CI/CD configuration changes, build-script changes, deployment-script changes, release-script changes, package-publishing workflow changes, container-build workflow changes, protected-branch changes, approval-rule changes, and review-control changes.

·        Build CI/CD execution selections for pipeline execution, job execution, workflow execution, runner assignment, release workflow execution, package-publishing workflow execution, container-build workflow execution, infrastructure-as-code workflow execution, and deployment workflow execution.

·        Build runner process selections for shell interpreters, scripting engines, package managers, archive utilities, transfer utilities, registry clients, container tooling, cloud CLIs, Kubernetes CLIs, credential helpers, and secret-management tools.

·        Build suspicious command selections for environment-variable inspection, protected-variable exposure, credential-location probing, secret-file access, archive creation, recursive collection, repository bundling, direct IP use, remote retrieval, encoded execution, suspicious command chaining, and external transfer.

·        Build repository sensitivity enrichment for production deployment repositories, package-publishing repositories, image-publishing repositories, signing repositories, infrastructure-as-code repositories, cloud deployment repositories, Kubernetes deployment repositories, and high-value application repositories.

·        Build local allowlists for approved workflow refactoring, release engineering, runner migration, package-publication changes, infrastructure deployment, vulnerability scanning, security testing, incident response, and known automation.

·        Translate the sequence into the target SIEM using native correlation syntax, scheduled searches, EQL sequences, SPL transactions or stats, QRadar building blocks, Sentinel KQL joins, or equivalent platform logic.

·        Validate timestamp normalization, sequence ordering, join keys, field extraction, field casing, parser behavior, and event latency before production deployment.

·        Use short correlation windows when workflow modification is followed immediately by pipeline execution or runner activity.

·        Use moderate correlation windows when workflow modification is followed by delayed runner execution, registry access, artifact movement, outbound communication, cloud activity, or Kubernetes activity.

·        Use longer correlation windows only when CI/CD lineage, repeated runner behavior, identity evidence, registry evidence, cloud evidence, Kubernetes evidence, or incident-response evidence supports delayed linkage.

·        Treat workflow modification as a confidence anchor, not standalone proof of compromise.

·        Do not enable alert mode until log-source coverage, field mapping, sequence translation, timing windows, false-positive rate, query performance, SOC triage workflow, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.3 / 10

·        The rule is behaviorally anchored to workflow modification followed by CI/CD runner activity and suspicious host behavior rather than static indicators, CVE identifiers, domains, IP addresses, hashes, package names, image names, or repository names.

·        The rule remains useful if an adversary changes workflow filename, repository path, command syntax, runner host, interpreter, transfer utility, registry client, cloud CLI, Kubernetes CLI, destination, or timing.

·        The score is supported by the durability of repository-control activity followed by trusted automation execution, credential inspection, archive creation, artifact staging, registry access, outbound communication, cloud tooling, and Kubernetes tooling.

·        The score is constrained by SIGMA’s portability limits, local field-mapping differences, incomplete Git audit logs, missing CI/CD job detail, weak runner identity mapping, incomplete command-line telemetry, and platform-specific correlation constraints.

·        The rule is durable as a portable repository-to-runner correlation pattern but should not be treated as standalone proof of credential theft, package compromise, cloud compromise, Kubernetes compromise, or actor attribution.

TCR Assessment

Operational TCR

7.2 / 10

Full-Telemetry TCR

8.5 / 10

·        Operational confidence depends on local log-source coverage, field mapping, CI/CD log quality, runner identity mapping, command-line visibility, repository sensitivity enrichment, parser quality, and SIEM correlation capability.

·        Operational confidence is reduced where SIGMA translation loses sequence semantics, where workflow changes are frequent, where CI/CD logs lack command detail, where runner hosts are ephemeral, or where change-control records are incomplete.

·        Operational confidence is reduced during release engineering, CI/CD refactoring, runner migration, repository migration, package-publication changes, infrastructure deployment, vulnerability scanning, and incident-response activity.

·        Full-telemetry confidence improves when the translated SIGMA logic correlates Git audit logs, CI/CD logs, endpoint telemetry, DNS logs, proxy logs, registry logs, package logs, cloud logs, Kubernetes logs, identity logs, deployment logs, and change-control records.

·        Even under full telemetry conditions, this rule should support escalation and scoping rather than standalone confirmation of compromise.

Limitations

·        SIGMA cannot guarantee native support for multi-stage correlation across all SIEM platforms without translation.

·        Field names, event identifiers, correlation windows, event ordering, and sequence semantics must be adapted locally.

·        Workflow changes may be legitimate during normal release engineering, CI/CD refactoring, runner migration, repository migration, or infrastructure updates.

·        Runner execution may be noisy in high-change build environments.

·        Missing command-line telemetry, weak runner identity mapping, inconsistent repository naming, parser gaps, or incomplete field mapping can reduce confidence.

·        The rule may miss workflow abuse that uses approved workflows, expected runner commands, low-noise credential access, approved destinations, or normal release paths.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

SIGMA portable workflow modification to suspicious runner execution pattern requiring local SIEM translation, log-source validation, field mapping, sequence support validation, repository identity mapping, runner identity mapping, timestamp normalization, approved workflow allowlisting, timing-window tuning, and environment-specific false-positive testing before production deployment.

title: Repository Workflow Modification Followed By Suspicious CI/CD Runner Execution
id: cyberdax-self-hosted-git-workflow-abuse-runner-execution
status: test
description: Detects repository workflow or CI/CD configuration changes followed by suspicious CI/CD runner process activity or related downstream behavior.
logsource:
  product: application
  service: git-ci-cd
detection:
  selection_workflow_change:
    event.action:
      - workflow_file_created
      - workflow_file_modified
      - workflow_file_deleted
      - ci_config_modified
      - build_script_modified
      - deployment_script_modified
      - release_script_modified
      - protected_branch_changed
      - approval_rule_changed
  selection_sensitive_repository:
    repository.sensitivity:
      - production_deployment
      - package_publishing
      - image_publishing
      - signing
      - infrastructure_as_code
      - cloud_deployment
      - kubernetes_deployment
      - high_value_repository
  selection_actor_risk:
    actor.context:
      - newly_privileged_user
      - inactive_user
      - unfamiliar_maintainer
      - external_contributor
      - unfamiliar_bot_account
      - service_account
      - unusual_source_infrastructure
  selection_pipeline_execution:
    event.action:
      - pipeline_executed
      - job_executed
      - workflow_executed
      - release_workflow_executed
      - package_publishing_workflow_executed
      - container_build_workflow_executed
      - iac_workflow_executed
      - deployment_workflow_executed
  selection_runner_process:
process.name:
      - bash
      - sh
      - powershell.exe
      - pwsh.exe
      - cmd.exe
      - python
      - python3
      - node
      - ruby
      - perl
      - curl
      - wget
      - tar
      - zip
      - docker
      - kubectl
      - helm
      - aws
      - az
      - gcloud
      - git
      - npm
      - pip
  selection_runner_command:
    process.command_line|contains:
      - printenv
      - cat /proc/self/environ
      - credential
      - token
      - secret
      - private_key
      - id_rsa
      - kubeconfig
      - .aws/credentials
      - .docker/config.json
      - archive
      - upload
      - artifact
      - cache
      - registry
      - docker login
      - kubectl config
      - aws sts
      - az account
      - gcloud auth
  filter_approved_change:
    change.context:
      - approved_workflow_refactor
      - approved_release_engineering
      - approved_runner_migration
      - approved_package_publication_change
      - approved_iac_deployment
      - approved_security_testing
      - approved_incident_response
  condition: selection_workflow_change and selection_sensitive_repository and selection_actor_risk and selection_pipeline_execution and (selection_runner_process or selection_runner_command) and not filter_approved_change
fields:
  - event.action
  - repository.name
  - repository.sensitivity
  - actor.name
  - actor.context
  - source.ip
  - branch.name
  - workflow.path
  - pipeline.id
  - job.id
  - runner.id
  - host.name
  - process.name
  - process.command_line
  - change.context
falsepositives:
  - Approved workflow refactoring
  - Release engineering
  - Runner migration
  - Package publication changes
  - Infrastructure deployment
  - Security testing
  - Incident response
level: high

Rule

Automation Credential or Webhook Change Followed by Suspicious Downstream Activity

Rule Format

SIGMA portable automation-credential correlation pattern suitable for Git audit logs, CI/CD logs, identity logs, token lifecycle logs, deploy-key logs, webhook logs, OAuth application logs, service-account logs, runner logs, registry logs, package-service logs, artifact-store logs, deployment logs, cloud audit logs, Kubernetes audit logs, and SIEM correlation after local field mapping, credential-lineage validation, sequence translation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect creation or modification of automation credentials, deploy keys, access tokens, OAuth applications, webhooks, service accounts, workload identities, runner tokens, or automation identities followed by suspicious repository, registry, package, artifact, deployment, cloud, or Kubernetes activity.

·        Identify potential abuse of trusted Git and CI/CD automation paths tied to sensitive repositories, production deployment paths, package-publishing authority, image-publishing authority, signing authority, infrastructure-as-code control, cloud deployment, Kubernetes deployment, or high-value build systems.

·        Prioritize automation or webhook changes performed by newly privileged users, inactive users, unfamiliar maintainers, unfamiliar bot accounts, service accounts, external contributors, or accounts authenticating from unusual source infrastructure.

·        Provide portable detection logic that can be translated into local SIEM correlation rules, watchlists, building blocks, saved searches, scheduled hunts, or event-sequence rules.

·        Preserve separation between suspicious automation activity and confirmed compromise by requiring supporting repository, CI/CD, identity, endpoint, registry, package, cloud, Kubernetes, deployment, or incident-response evidence before classifying compromise as confirmed.

·        This rule does not prove credential theft, token theft, webhook abuse, registry compromise, package compromise, cloud compromise, Kubernetes compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify creation, modification, scope expansion, permission change, unusual use, or destination change involving deploy keys, project access tokens, group access tokens, personal access tokens, OAuth applications, webhooks, service accounts, workload identities, runner tokens, or automation identities.

·        Prioritize automation changes affecting sensitive repositories, protected branches, production deployment workflows, package-publishing workflows, image-publishing workflows, signing workflows, infrastructure-as-code workflows, cloud deployment workflows, Kubernetes deployment workflows, or release automation.

·        Prioritize automation changes performed by newly privileged users, inactive users, unfamiliar maintainers, unfamiliar bot accounts, service accounts, external contributors, or accounts authenticating from unusual source infrastructure.

·        Correlate automation changes with follow-on repository cloning, project export, pipeline execution, runner execution, artifact access, package access, image pull, image push, registry authentication, release modification, deployment activity, cloud API activity, Kubernetes API activity, or secret-manager access.

·        Increase confidence when follow-on activity occurs outside expected repository, runner, branch, project, group, time window, geography, source network, device, environment, or deployment path.

·        Increase confidence when multiple automation credentials are created or modified in a short period, when credential scope is broader than expected, when a webhook destination is new or unfamiliar, or when service-account ownership is unclear.

·        Increase confidence when downstream activity is performed using the new or modified credential, related automation identity, related service account, related webhook destination, or source host associated with CI/CD infrastructure.

·        Reduce severity when activity matches approved integration onboarding, token rotation, deploy-key maintenance, webhook maintenance, runner migration, service-account rotation, release engineering, cloud operations, security testing, incident response, or documented change-control activity.

·        Do not classify automation credential creation, webhook creation, or service-account modification as compromise without follow-on use, suspicious scope, suspicious destination, actor-risk context, downstream activity, or incident-response validation.

·        Do not treat token creation, deploy-key creation, webhook creation, service-account changes, or OAuth application creation as compromise evidence by itself.

Required Telemetry

·        Git audit logs.

·        Repository access logs.

·        Deploy-key logs.

·        Token lifecycle logs.

·        Project access token logs.

·        Group access token logs.

·        Personal access token logs where available.

·        OAuth application logs.

·        Webhook logs.

·        Service-account logs.

·        Workload identity logs where available.

·        Runner registration logs.

·        Runner token logs where available.

·        CI/CD pipeline logs.

·        CI/CD job logs.

·        Runner telemetry.

·        Identity logs.

·        Endpoint telemetry where available.

·        Network telemetry where available.

·        Registry logs.

·        Package-service logs.

·        Artifact-store logs.

·        Release-system logs.

·        Deployment logs.

·        Cloud audit logs where available.

·        Kubernetes audit logs where available.

·        Actor identity.

·        Token or credential identifier where available.

·        Credential scope.

·        Credential permission level.

·        Webhook destination.

·        Webhook response status where available.

·        OAuth application identifier where available.

·        Service-account identifier where available.

·        Repository.

·        Project or group.

·        Branch.

·        Workflow.

·        Pipeline ID.

·        Runner ID.

·        Source IP.

·        Source ASN and source geography where available.

·        Destination service.

·        Action.

·        Result.

·        Timestamp.

·        Repository sensitivity enrichment.

·        Automation identity inventory.

·        Service-account inventory.

·        Approved token inventory.

·        Approved webhook inventory.

·        Approved deploy-key inventory.

·        Approved integration records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Treat the SIGMA rule as a portable pattern requiring local SIEM translation before deployment.

·        Map Git, CI/CD, token lifecycle, deploy-key, webhook, OAuth, service-account, runner, registry, package, artifact, deployment, cloud, Kubernetes, identity, endpoint, and network fields into the local SIEM schema.

·        Build automation event selections for deploy-key creation, deploy-key modification, token creation, token scope change, token permission change, OAuth application creation, webhook creation, webhook modification, webhook destination change, service-account creation, workload identity change, runner token activity, and automation identity changes.

·        Build sensitive repository and workflow selections for production deployment, package publishing, image publishing, signing, infrastructure-as-code, cloud deployment, Kubernetes deployment, release automation, and high-value application repositories.

·        Build separate actor-risk and credential-risk selections so the translated rule does not require both actor context and credential context to exist on the same event.

·        Build suspicious webhook selections for new destinations, unfamiliar destinations, destinations outside approved integration inventory, unmanaged object storage, external automation endpoints, temporary infrastructure, tunneling services, dynamic DNS, and failed-then-successful webhook delivery patterns.

·        Build downstream activity selections for repository cloning, project export, pipeline execution, runner execution, artifact access, package access, image pull, image push, registry authentication, release modification, deployment activity, cloud API activity, Kubernetes API activity, secret-manager access, and infrastructure changes.

·        Translate follow-on activity requirements into the target SIEM using native correlation syntax, scheduled searches, EQL sequences, SPL transactions or stats, QRadar building blocks, Sentinel KQL joins, or equivalent platform logic.

·        Validate credential identifiers, token scope fields, webhook destination fields, service-account identifiers, repository names, project or group identifiers, timestamps, and join reliability.

·        Use short correlation windows when automation changes are followed immediately by pipeline execution, registry activity, repository access, webhook delivery, or deployment activity.

·        Use moderate correlation windows for delayed package access, image activity, artifact access, cloud activity, Kubernetes activity, or deployment activity after automation changes.

·        Use longer correlation windows only when credential lineage, webhook lineage, identity evidence, CI/CD evidence, cloud evidence, registry evidence, or incident-response evidence supports delayed linkage.

·        Treat automation changes as confidence anchors, not standalone proof of compromise.

·        Build exceptions for approved token rotation, deploy-key maintenance, webhook onboarding, integration onboarding, runner migration, service-account rotation, release engineering, cloud operations, security testing, incident response, and known automation.

·        Do not enable alert mode until log-source coverage, field mapping, credential lineage, webhook validation, sequence translation, false-positive rate, query performance, SOC triage workflow, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.2 / 10

·        The rule is behaviorally anchored to automation credential and webhook changes followed by downstream activity rather than static indicators, fixed token names, repository names, domains, IP addresses, package names, image names, hashes, or CVE identifiers.

·        The rule remains useful if an adversary changes credential type, token name, webhook destination, service account, repository path, runner host, registry endpoint, package, image, cloud service, or timing.

·        The score is supported by the durability of credential creation, scope expansion, webhook creation, webhook destination change, OAuth application creation, service-account changes, and follow-on repository, registry, artifact, deployment, cloud, or Kubernetes activity.

·        The score is constrained by SIGMA’s portability limits, incomplete token lifecycle logging, missing credential identifiers, weak webhook visibility, weak service-account mapping, and legitimate integration onboarding or token rotation.

·        The rule is durable as a portable automation-lineage pattern but should not be treated as standalone proof of credential theft, webhook abuse, cloud compromise, registry compromise, or actor attribution.

TCR Assessment

Operational TCR

7.1 / 10

Full-Telemetry TCR

8.4 / 10

·        Operational confidence depends on local log-source coverage, field mapping, token lifecycle logging, deploy-key visibility, webhook visibility, service-account mapping, identity enrichment, downstream registry or cloud visibility, parser quality, and SIEM correlation capability.

·        Operational confidence is reduced where SIGMA translation loses sequence semantics, token identifiers are masked, credential scope is unavailable, webhook destination logging is incomplete, service-account ownership is unclear, or downstream activity cannot be tied to the credential or webhook.

·        Operational confidence is reduced during integration onboarding, token rotation, deploy-key maintenance, service-account rotation, runner migration, release engineering, cloud operations, and incident-response activity.

·        Full-telemetry confidence improves when the translated SIGMA logic correlates credential lifecycle events with CI/CD logs, registry logs, package logs, artifact logs, endpoint telemetry, network telemetry, cloud logs, Kubernetes logs, identity logs, and change-control records.

·        Even under full telemetry conditions, this rule should support escalation and lineage reconstruction rather than standalone confirmation of compromise.

Limitations

·        SIGMA cannot guarantee native support for multi-stage credential lineage across all SIEM platforms without translation.

·        Some Git and CI/CD platforms may mask token identifiers, reduce token lifecycle visibility, or omit webhook payload details.

·        Legitimate integration onboarding, token rotation, service-account rotation, webhook maintenance, and runner migration can resemble suspicious automation activity.

·        Weak credential lineage, inconsistent repository naming, incomplete service-account mapping, incomplete webhook logging, parser gaps, or missing downstream logs can reduce confidence.

·        The rule may miss abuse of existing long-lived credentials or webhooks if no recent creation, modification, or scope change is visible.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

SIGMA portable automation credential or webhook change to downstream activity pattern requiring local SIEM translation, log-source validation, field mapping, credential identifier validation, token scope validation, webhook field validation, service-account mapping, downstream lineage validation, approved integration allowlisting, timing-window tuning, and environment-specific false-positive testing before production deployment.

title: Automation Credential Or Webhook Change Followed By Suspicious Downstream Activity
id: cyberdax-self-hosted-git-automation-change-downstream-activity
status: test
description: Detects automation credential, deploy key, webhook, OAuth application, service account, or runner token changes followed by suspicious repository, registry, artifact, deployment, cloud, or Kubernetes activity.
logsource:
  product: application
  service: git-ci-cd
detection:
  selection_automation_change:
    event.action:
      - deploy_key_created
      - deploy_key_modified
      - project_token_created
      - group_token_created
      - personal_access_token_created
      - token_scope_changed
      - token_permission_changed
      - oauth_application_created
      - webhook_created
      - webhook_modified
      - webhook_destination_changed
      - service_account_created
      - service_account_modified
      - workload_identity_changed
      - runner_token_created
      - automation_identity_changed
  selection_sensitive_repository:
    repository.sensitivity:
      - production_deployment
      - package_publishing
      - image_publishing
      - signing
      - infrastructure_as_code
      - cloud_deployment
      - kubernetes_deployment
      - high_value_repository
  selection_actor_risk:
    actor.context:
      - newly_privileged_user
      - inactive_user
      - unfamiliar_maintainer
      - unfamiliar_bot_account
      - service_account
      - external_contributor
      - unusual_source_infrastructure
  selection_credential_risk:
    credential.context:
      - broad_scope
      - long_expiration
      - privileged_scope
      - registry_scope
      - api_scope
      - write_scope
      - deployment_scope
      - new_or_unfamiliar_webhook_destination
  selection_downstream_activity:
    event.action:
      - repository_cloned
      - project_exported
      - pipeline_executed
      - runner_executed
      - artifact_accessed
      - package_accessed
      - image_pulled
      - image_pushed
      - registry_authenticated
      - release_modified
      - deployment_executed
      - cloud_api_called
      - kubernetes_api_called
      - secret_manager_accessed
      - infrastructure_modified
  filter_approved_change:
    change.context:
      - approved_token_rotation
      - approved_deploy_key_maintenance
      - approved_webhook_onboarding
      - approved_integration_onboarding
      - approved_runner_migration
      - approved_service_account_rotation
      - approved_release_engineering
      - approved_cloud_operations
      - approved_security_testing
      - approved_incident_response
  condition: selection_automation_change and selection_sensitive_repository and (selection_actor_risk or selection_credential_risk) and selection_downstream_activity and not filter_approved_change
fields:
  - event.action
  - repository.name
  - repository.sensitivity
  - actor.name
  - actor.context
  - credential.id
  - credential.scope
  - webhook.destination
  - service_account.id
  - source.ip
  - pipeline.id
  - runner.id
  - destination.service
  - change.context
falsepositives:
  - Approved token rotation
  - Deploy key maintenance
  - Webhook onboarding
  - Integration onboarding
  - Runner migration
  - Service-account rotation
  - Release engineering
  - Cloud operations
  - Security testing
  - Incident response
level: high

Rule

CI/CD-Linked Identity Use Followed by Cloud, Kubernetes, or Deployment Activity

Rule Format

SIGMA portable CI/CD-to-control-plane correlation pattern suitable for CI/CD logs, Git audit logs, identity logs, runner logs, endpoint telemetry, registry logs, cloud audit logs, Kubernetes audit logs, deployment logs, secret-manager logs, network telemetry, and SIEM correlation after local field mapping, identity mapping, credential-lineage validation, source-network validation, downstream-action validation, sequence translation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious use of CI/CD-linked credentials, automation identities, service accounts, workload identities, deploy accounts, cloud roles, Kubernetes identities, package-publishing identities, image-publishing identities, or deployment identities followed by cloud, Kubernetes, deployment, registry, secret-manager, storage, or infrastructure activity.

·        Identify potential downstream expansion after repository workflow abuse, credential exposure, token exposure, runner compromise, malicious pipeline execution, or automation identity misuse.

·        Prioritize downstream activity occurring outside expected repository, branch, workflow, runner, source network, geography, project, namespace, region, account, subscription, tenant, environment, deployment path, or approved time window.

·        Provide portable detection logic that can be translated into local SIEM correlation rules, watchlists, building blocks, saved searches, scheduled hunts, or event-sequence rules.

·        Preserve separation between suspicious downstream control-plane activity and confirmed compromise by requiring repository, CI/CD, identity, endpoint, network, registry, cloud, Kubernetes, deployment, or incident-response evidence before classifying compromise as confirmed.

·        This rule does not prove repository compromise, credential theft, cloud compromise, Kubernetes compromise, deployment compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify use of CI/CD-linked credentials, automation identities, service accounts, workload identities, deploy accounts, cloud roles, Kubernetes identities, package-publishing identities, image-publishing identities, or deployment identities.

·        Prioritize use outside expected repository, branch, workflow, runner, source network, geography, project, namespace, region, account, subscription, tenant, environment, deployment path, or approved time window.

·        Detect follow-on activity involving cloud API calls, IAM changes, role assignment, access-key creation, secret-manager access, container registry access, artifact access, Kubernetes API activity, deployment execution, infrastructure-as-code execution, storage access, function changes, workload changes, or release activity.

·        Correlate downstream activity with suspicious upstream context, including workflow modification, suspicious pipeline execution, new runner registration, runner tag change, token creation, deploy-key creation, webhook modification, OAuth application creation, protected-branch change, credential access, unusual outbound communication, or registry activity.

·        Increase confidence when the same identity, token, runner host, service account, workload identity, source IP, pipeline, repository, deployment account, or incident timeline connects upstream CI/CD activity to downstream control-plane activity.

·        Increase confidence when downstream actions modify identity, privileges, secrets, networking, storage, container images, deployment manifests, infrastructure templates, Kubernetes role bindings, image-pull secrets, or production workloads.

·        Increase confidence when control-plane activity is rare for the identity, new for the environment, outside the expected region or namespace, or inconsistent with the account’s normal role.

·        Reduce severity when activity matches approved deployment workflows, infrastructure deployment, cloud operations, Kubernetes operations, release engineering, package publication, image publication, vulnerability scanning, security testing, incident response, or documented change-control activity.

·        Do not attribute cloud, Kubernetes, or deployment activity to repository workflow compromise without identity, timing, runner, repository, credential, source-network, or incident-response linkage.

·        Do not treat cloud API activity, Kubernetes API activity, deployment activity, registry activity, or secret-manager activity as compromise evidence by itself.

Required Telemetry

·        CI/CD pipeline logs.

·        CI/CD job logs.

·        Runner logs.

·        Git audit logs.

·        Identity logs.

·        Service-account logs.

·        Workload identity logs where available.

·        Token lifecycle logs where available.

·        Endpoint telemetry from runners where available.

·        Network telemetry where available.

·        DNS logs where available.

·        Proxy logs where available.

·        Registry logs.

·        Package-service logs where available.

·        Artifact-store logs where available.

·        Cloud audit logs.

·        Kubernetes audit logs.

·        Deployment platform logs.

·        Secret-manager logs where available.

·        Infrastructure-as-code execution logs where available.

·        User identity.

·        Automation identity.

·        Service-account identity.

·        Workload identity.

·        Credential identifier where available.

·        Runner ID.

·        Runner host.

·        Repository.

·        Branch.

·        Workflow.

·        Pipeline ID.

·        Job ID.

·        Source IP.

·        Source ASN and source geography where available.

·        Cloud account, project, subscription, tenant, or region.

·        Kubernetes cluster, namespace, service account, and role binding where available.

·        Deployment environment.

·        Resource action.

·        Result.

·        Timestamp.

·        Repository sensitivity enrichment.

·        CI/CD credential inventory.

·        Cloud identity inventory.

·        Kubernetes identity inventory.

·        Deployment account inventory.

·        Approved deployment records.

·        Approved cloud operation records.

·        Approved Kubernetes operation records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Treat the SIGMA rule as a portable pattern requiring local SIEM translation before deployment.

·        Map CI/CD, Git, identity, runner, endpoint, network, registry, package, artifact, cloud, Kubernetes, deployment, and secret-manager fields into the local SIEM schema.

·        Build CI/CD credential and identity selections for automation identities, service accounts, workload identities, deploy accounts, cloud roles, Kubernetes identities, package-publishing identities, image-publishing identities, and deployment identities.

·        Build downstream control-plane selections for cloud API calls, IAM changes, role assignment, access-key creation, secret-manager access, registry access, artifact access, Kubernetes API activity, deployment execution, infrastructure-as-code execution, storage access, function changes, workload changes, and release activity.

·        Build upstream suspicious context selections for workflow modification, suspicious pipeline execution, runner changes, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, registry activity, and suspicious endpoint behavior.

·        Build expected-use baselines by repository, branch, workflow, runner, source network, geography, project, namespace, region, account, subscription, tenant, environment, and deployment path.

·        Build lineage logic mapping identity, credential, token, runner host, source IP, pipeline, repository, deployment account, service account, workload identity, and incident timeline.

·        Translate downstream control-plane activity requirements into the target SIEM using native correlation syntax, scheduled searches, EQL sequences, SPL transactions or stats, QRadar building blocks, Sentinel KQL joins, or equivalent platform logic.

·        Validate identity mapping, credential lineage, source-network preservation, cloud project or subscription fields, Kubernetes namespace fields, deployment fields, parser behavior, field extraction, and timestamp consistency.

·        Use short correlation windows when downstream control-plane activity occurs during or immediately after suspicious CI/CD execution.

·        Use moderate correlation windows when downstream activity follows workflow modification, runner changes, token creation, credential access, unusual egress, or registry activity.

·        Use longer correlation windows only when identity lineage, cloud evidence, Kubernetes evidence, endpoint evidence, CI/CD lineage, or incident-response evidence supports delayed linkage.

·        Treat downstream control-plane activity as a confidence amplifier unless linked to suspicious CI/CD, credential, runner, identity, source-network, or incident-response evidence.

·        Build exceptions for approved deployment workflows, infrastructure deployment, cloud operations, Kubernetes operations, release engineering, package publication, image publication, vulnerability scanning, security testing, incident response, and known automation.

·        Do not enable alert mode until log-source coverage, identity mapping, credential lineage, source-network validation, sequence translation, false-positive rate, query performance, SOC triage workflow, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.2 / 10

·        The rule is behaviorally anchored to CI/CD-linked identity use followed by cloud, Kubernetes, or deployment activity rather than static domains, IP addresses, hashes, repository names, package names, image names, or CVE identifiers.

·        The rule remains useful if an adversary changes workflow content, runner host, cloud service, Kubernetes namespace, deployment target, source infrastructure, credential type, identity type, tool sequence, or timing.

·        The score is supported by the durability of automation identity use, cloud API activity, Kubernetes API activity, deployment execution, secret-manager access, registry access, IAM changes, role assignments, source-network mismatch, and unexpected production-environment activity.

·        The score is constrained by SIGMA’s portability limits, identity federation complexity, weak credential lineage, incomplete source IP preservation, noisy deployment activity, inconsistent cloud and Kubernetes logging, and legitimate automation workflows.

·        The rule is durable as a portable CI/CD-to-control-plane correlation pattern but should not be treated as standalone proof of repository workflow compromise, credential theft, cloud compromise, Kubernetes compromise, or actor attribution.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.4 / 10

·        Operational confidence depends on local log-source coverage, field mapping, CI/CD logs, identity logs, cloud audit logs, Kubernetes audit logs, deployment logs, credential lineage, source-network preservation, parser quality, and SIEM correlation capability.

·        Operational confidence is reduced where SIGMA translation loses sequence semantics, identity federation obscures the initiating repository, source IPs are transformed, cloud sessions are reused, workload identities are shared, or deployment logs lack pipeline context.

·        Operational confidence is reduced during normal infrastructure deployment, release engineering, cloud operations, Kubernetes operations, image publication, package publication, vulnerability scanning, and incident-response activity.

·        Full-telemetry confidence improves when the translated SIGMA logic correlates CI/CD logs, Git audit logs, runner endpoint telemetry, network telemetry, registry logs, package logs, cloud logs, Kubernetes logs, identity logs, deployment logs, and change-control records.

·        Even under full telemetry conditions, this rule should support downstream exposure scoping and containment prioritization rather than standalone confirmation of compromise.

Limitations

·        SIGMA cannot guarantee native support for multi-stage CI/CD-to-control-plane correlation across all SIEM platforms without translation.

·        Federated identity, workload identity, shared service accounts, NAT, proxying, cloud session reuse, and token reuse can obscure lineage.

·        Legitimate deployment workflows and cloud operations can closely resemble suspicious downstream activity.

·        Missing cloud logs, missing Kubernetes logs, weak source IP preservation, incomplete deployment logs, inconsistent identity mapping, parser gaps, or incomplete field mapping can reduce confidence.

·        The rule may miss downstream abuse that uses expected deployment paths, approved identities, normal source networks, or delayed execution outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

SIGMA portable CI/CD-linked identity use to cloud, Kubernetes, or deployment activity pattern requiring local SIEM translation, log-source validation, field mapping, identity mapping, credential-lineage validation, source-network validation, downstream-action validation, approved workflow allowlisting, timing-window tuning, and environment-specific false-positive testing before production deployment.

title: CI/CD-Linked Identity Use Followed By Cloud Kubernetes Or Deployment Activity
id: cyberdax-self-hosted-git-cicd-identity-control-plane-activity
status: test
description: Detects suspicious CI/CD-linked identity use followed by cloud, Kubernetes, deployment, registry, secret-manager, storage, or infrastructure activity.
logsource:
  product: application
  service: ci-cd-control-plane
detection:
  selection_identity_use:
    identity.type:
      - automation_identity
      - service_account
      - workload_identity
      - deploy_account
      - cloud_role
      - kubernetes_identity
      - package_publishing_identity
      - image_publishing_identity
      - deployment_identity
  selection_use_context:
    use.context:
      - outside_expected_repository
      - outside_expected_branch
      - outside_expected_workflow
      - outside_expected_runner
      - outside_expected_source_network
      - outside_expected_geography
      - outside_expected_time_window
      - outside_expected_deployment_path
      - rare_use_for_identity
  selection_repository_sensitivity:
    repository.sensitivity:
      - production_deployment
      - package_publishing
      - image_publishing
      - signing
      - infrastructure_as_code
      - cloud_deployment
      - kubernetes_deployment
      - high_value_repository
  selection_upstream_context:
    event.action:
      - recent_workflow_change
      - suspicious_pipeline_execution
      - recent_runner_registration
      - recent_runner_tag_change
      - recent_token_creation
      - recent_deploy_key_creation
      - recent_webhook_change
      - credential_access_behavior
      - unusual_runner_egress
      - registry_activity
  selection_downstream_control_plane:
    event.action:
      - cloud_api_called
      - iam_changed
      - role_assigned
      - access_key_created
      - secret_manager_accessed
      - container_registry_accessed
      - artifact_accessed
      - kubernetes_api_called
      - deployment_executed
      - infrastructure_as_code_executed
      - storage_accessed
      - function_modified
      - workload_modified
      - release_modified
  filter_approved_change:
    change.context:
      - approved_deployment_workflow
      - approved_iac_deployment
      - approved_cloud_operations
      - approved_kubernetes_operations
      - approved_release_engineering
      - approved_package_publication
      - approved_image_publication
      - approved_security_testing
      - approved_incident_response
  condition: selection_identity_use and (selection_use_context or selection_repository_sensitivity) and selection_upstream_context and selection_downstream_control_plane and not filter_approved_change
fields:
  - event.action
  - identity.type
  - identity.name
  - repository.name
  - repository.sensitivity
  - workflow.name
  - runner.id
  - host.name
  - source.ip
  - cloud.account.id
  - cloud.project.id
  - kubernetes.cluster.name
  - kubernetes.namespace
  - deployment.environment
  - resource.action
  - change.context
falsepositives:
  - Approved deployment workflows
  - Infrastructure deployment
  - Cloud operations
  - Kubernetes operations
  - Release engineering
  - Package publication
  - Image publication
  - Security testing
  - Incident response
level: high

YARA

Detection Viability Assessment

YARA has zero primary rules for this EXP report.

·        YARA is not recommended for primary S25 detection because the governing detection model is behavior-led, not artifact-led.

·        The report’s strongest detection coverage comes from repository workflow modification patterns, CI/CD pipeline execution context, runner assignment and runner registration activity, automation credential changes, deploy-key activity, webhook modification, OAuth application creation, protected-branch control changes, suspicious runner-host execution, credential and token access behavior, registry access, package access, artifact movement, outbound network behavior, cloud-control-plane activity, Kubernetes activity, deployment activity, and downstream identity-plane correlation.

·        YARA does not observe repository workflow changes, Git audit activity, CI/CD job execution, runner registration, runner assignment, runner tag changes, token lifecycle activity, deploy-key creation, webhook modification, OAuth application creation, protected-branch changes, CI/CD variable exposure, service-account use, cloud role use, Kubernetes API activity, registry authentication, package publication, deployment lineage, source-to-runner behavior, source-to-registry behavior, or backend SIEM correlation context.

·        YARA can support optional investigative hunting if responders recover a stable artifact during incident response, such as a webshell, loader, dropper, staged script, malicious workflow payload, runner-stage script, credential-access tool, remote-access tool, memory artifact, encoded payload, suspicious binary, configuration artifact, or reusable file-content pattern linked to suspicious repository workflow activity or downstream CI/CD activity.

·        Including a primary YARA rule would create unnecessary artifact dependency and would be weaker than the accepted behavior-led rule sets for NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, and SIGMA.

·        YARA should remain a conditional investigative control rather than a primary detection system unless stable artifact evidence becomes available from the affected environment.

·        YARA should not be used to infer successful repository compromise, workflow abuse, credential theft, token theft, package compromise, registry compromise, image compromise, cloud compromise, Kubernetes compromise, deployment compromise, endpoint compromise, persistence, lateral movement, data access, or actor attribution without supporting endpoint, identity, network, repository, CI/CD, registry, package, cloud, Kubernetes, deployment, file, memory, or incident-response evidence.

Final Disposition

No primary YARA rule is included.

AWS

Detection Viability Assessment

AWS has three rules for this EXP report.

·        AWS is viable for detecting downstream cloud-control-plane activity associated with self-hosted Git platform compromise through repository workflow abuse when AWS CloudTrail, IAM activity, STS activity, Secrets Manager logs, ECR logs, S3 data events, CodeDeploy or deployment telemetry, VPC Flow Logs, GuardDuty findings, and CI/CD identity mappings are available.

·        AWS is strongest when cloud events can be correlated with Git audit logs, CI/CD pipeline logs, runner telemetry, identity-provider logs, registry activity, deployment activity, source IP context, workload identity context, and repository sensitivity enrichment.

·        AWS can identify suspicious use of CI/CD-linked roles, service accounts, workload identities, access keys, federated identities, deployment roles, ECR identities, S3 identities, Secrets Manager access, IAM changes, role assumption, access-key creation, image push or pull activity, and deployment activity after suspicious repository workflow or automation credential activity.

·        AWS is not a standalone source for confirming repository workflow compromise because AWS telemetry does not directly prove Git platform compromise, workflow abuse, token theft, runner compromise, package compromise, or actor attribution without upstream repository, CI/CD, endpoint, identity, or incident-response evidence.

·        AWS detections must avoid treating cloud API activity, role assumption, ECR access, S3 access, Secrets Manager access, IAM changes, Lambda changes, ECS changes, EKS activity, or deployment actions as confirmed compromise by themselves.

·        AWS detections should support downstream exposure scoping, cloud containment prioritization, identity investigation, credential-use review, and impact assessment when suspicious repository or CI/CD activity aligns with AWS control-plane activity.

·        AWS rules should not generate high-confidence alerting from a single AWS event unless the activity is correlated with suspicious repository, CI/CD, runner, identity, credential, registry, deployment, or incident-response context.

Rule

Suspicious CI/CD-Linked AWS Role Assumption After Repository Workflow Activity

Rule Format

AWS cloud-control-plane correlation rule suitable for CloudTrail, STS AssumeRole events, IAM role activity, identity-provider logs, CI/CD logs, Git audit logs, runner metadata, source IP enrichment, repository sensitivity enrichment, VPC Flow Logs where available, GuardDuty findings where available, and SIEM correlation after AWS account mapping, role mapping, source-network validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious AWS role assumption, federated identity use, or CI/CD-linked cloud identity use after repository workflow modification, suspicious pipeline execution, runner changes, token creation, deploy-key creation, webhook modification, or credential-access behavior.

·        Identify possible downstream AWS access following repository workflow abuse, CI/CD credential exposure, runner compromise, or automation identity misuse.

·        Prioritize role assumption involving deployment roles, production roles, ECR roles, EKS roles, ECS roles, Lambda deployment roles, infrastructure-as-code roles, Secrets Manager roles, S3 access roles, administrator-like roles, and roles tied to sensitive repositories.

·        Support escalation when AWS role assumption occurs from unexpected source networks, unusual geographies, unfamiliar runners, rare identities, new user agents, unusual sessions, unexpected repositories, or outside approved deployment windows.

·        Preserve separation between suspicious AWS identity use and confirmed compromise by requiring upstream Git, CI/CD, runner, endpoint, identity, network, registry, deployment, or incident-response evidence before classifying cloud activity as compromise.

·        This rule does not prove repository compromise, workflow abuse, credential theft, cloud compromise, AWS account compromise, deployment compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify AWS STS AssumeRole, AssumeRoleWithWebIdentity, GetCallerIdentity, GetSessionToken, or federated identity activity involving CI/CD-linked roles, deployment roles, infrastructure roles, ECR roles, EKS roles, ECS roles, Lambda roles, Secrets Manager roles, S3 roles, or privileged roles.

·        Prioritize AWS identity use following repository workflow modification, suspicious pipeline execution, new runner registration, runner tag change, token creation, deploy-key creation, webhook modification, protected-branch change, credential-access behavior, unusual runner egress, or registry activity.

·        Prioritize source context that is outside expected runner networks, outside approved CI/CD infrastructure, outside expected AWS regions, outside expected geographies, new for the identity, rare for the role, inconsistent with the deployment path, or not present in approved source baselines.

·        Prioritize role sessions with unusual session names, unusual user agents, unusual external IDs, new role chains, unexpected principals, broad privilege scope, long session duration, or activity outside approved deployment windows.

·        Increase confidence when role assumption is followed by IAM changes, access-key creation, Secrets Manager access, S3 access, ECR authentication, image push, Lambda changes, ECS task changes, EKS activity, CloudFormation activity, infrastructure-as-code execution, or production deployment activity.

·        Increase confidence when the AWS role maps to sensitive repositories, production deployment, package publication, image publication, signing, infrastructure-as-code, cloud deployment, Kubernetes deployment, or high-value application delivery.

·        Reduce severity when activity matches approved deployment workflows, infrastructure deployment, cloud operations, role rotation, CI/CD migration, incident response, security testing, or documented change-control activity.

·        Do not classify AWS role assumption as repository workflow compromise without upstream repository, CI/CD, runner, credential, identity, network, or incident-response linkage.

·        Do not treat AssumeRole, federated identity use, ECR authentication, S3 access, IAM activity, or deployment activity as compromise evidence by itself.

Required Telemetry

·        AWS CloudTrail management events.

·        AWS STS AssumeRole events.

·        AWS STS AssumeRoleWithWebIdentity events.

·        AWS GetCallerIdentity events where available.

·        AWS IAM role activity.

·        AWS IAM policy activity.

·        AWS access-key lifecycle events.

·        AWS Secrets Manager events.

·        AWS ECR authentication and image events.

·        AWS S3 data events where enabled.

·        AWS CloudFormation events where available.

·        AWS Lambda events where available.

·        AWS ECS events where available.

·        AWS EKS control-plane events where available.

·        AWS CodeDeploy or deployment platform logs where available.

·        AWS GuardDuty findings where available.

·        VPC Flow Logs where available.

·        Identity-provider logs.

·        CI/CD pipeline logs.

·        CI/CD job logs.

·        Runner metadata.

·        Git audit logs.

·        Repository sensitivity enrichment.

·        AWS account ID.

·        AWS organization ID where available.

·        AWS region.

·        Role ARN.

·        Principal ARN.

·        Session name.

·        Source IP.

·        User agent.

·        External ID where available.

·        MFA context where available.

·        Request parameters.

·        Response result.

·        Error code where applicable.

·        Timestamp.

·        Approved CI/CD source networks.

·        Approved role-to-repository mapping.

·        Approved deployment windows.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build AWS role groups for CI/CD-linked roles, deployment roles, production roles, ECR roles, EKS roles, ECS roles, Lambda roles, CloudFormation roles, infrastructure-as-code roles, Secrets Manager roles, S3 roles, and privileged roles.

·        Build suspicious source groups for non-runner networks, rare geographies, rare ASNs, new source IPs for the role, source IPs outside approved CI/CD infrastructure, unexpected AWS regions, and identities outside expected repository-to-role mappings.

·        Build upstream suspicious context groups using Git audit logs, CI/CD logs, runner metadata, endpoint telemetry, NDR telemetry, identity logs, registry logs, and SIEM context that identifies workflow modification, suspicious pipeline execution, runner registration, runner tag change, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, or registry activity.

·        Build follow-on AWS activity groups for IAM changes, access-key creation, Secrets Manager access, S3 object access, ECR authentication, image push, Lambda modification, ECS task changes, EKS API activity, CloudFormation activity, infrastructure-as-code execution, and deployment activity.

·        Build repository-to-role and role-to-environment mappings for sensitive repositories, production deployment, package publication, image publication, signing, infrastructure-as-code, cloud deployment, Kubernetes deployment, and high-value application delivery.

·        Validate CloudTrail event coverage, region coverage, organization coverage, management-event coverage, data-event coverage, STS field extraction, source IP preservation, role ARN mapping, session-name parsing, user-agent parsing, and CI/CD identity mapping.

·        Validate joins between AWS CloudTrail, identity-provider logs, CI/CD logs, Git audit logs, runner metadata, endpoint telemetry, network telemetry, registry logs, deployment logs, and incident-response evidence.

·        Use short correlation windows when role assumption occurs during or immediately after suspicious CI/CD execution.

·        Use moderate correlation windows when role assumption follows workflow modification, runner changes, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, or registry activity.

·        Use longer correlation windows only when AWS identity lineage, CI/CD lineage, runner evidence, cloud evidence, identity evidence, or incident-response evidence supports delayed linkage.

·        Add severity weighting for privileged role use, production account access, unusual source network, role-chain anomaly, long session duration, IAM changes, access-key creation, Secrets Manager access, ECR image push, S3 sensitive object access, and production deployment actions.

·        Treat AWS role assumption as a confidence amplifier unless linked to suspicious repository, CI/CD, runner, credential, identity, network, deployment, or incident-response evidence.

·        Build allowlists for approved deployment workflows, infrastructure deployment, cloud operations, CI/CD migration, role rotation, vulnerability scanning, security testing, incident response, and known automation.

·        Do not enable alert mode until AWS account coverage, CloudTrail coverage, role mapping, source-network validation, repository-to-role enrichment, field mapping, correlation reliability, false-positive rate, query performance, SOC triage workflow, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.4 / 10

·        The rule is behaviorally anchored to CI/CD-linked AWS role assumption and downstream identity use rather than static indicators, domains, IP addresses, hashes, repository names, package names, image names, or CVE identifiers.

·        The rule remains useful if an adversary changes workflow content, runner host, role session name, source infrastructure, AWS region, user agent, token source, deployment path, or timing.

·        The score is supported by the durability of role assumption, federated identity use, unusual source context, role-to-repository mismatch, IAM activity, Secrets Manager access, ECR access, S3 access, and production deployment activity.

·        The score is constrained by legitimate deployment workflows, federated identity complexity, NAT or proxy effects, shared runner networks, incomplete CloudTrail coverage, incomplete data events, and weak repository-to-role mapping.

·        The rule is durable as AWS identity-lineage coverage but should not be treated as standalone proof of repository workflow compromise, credential theft, AWS compromise, deployment compromise, or actor attribution.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

8.8 / 10

·        Operational confidence depends on CloudTrail coverage, STS visibility, identity-provider logs, CI/CD logs, repository-to-role mapping, source-network preservation, runner identity mapping, AWS account mapping, and SIEM correlation quality.

·        Operational confidence is reduced where federated identity obscures repository lineage, source IPs are transformed, sessions are reused, runners share networks, CloudTrail data events are incomplete, or deployment records lack pipeline context.

·        Operational confidence is reduced during normal infrastructure deployment, release engineering, cloud operations, CI/CD migration, role rotation, incident response, and security testing.

·        Full-telemetry confidence improves when AWS CloudTrail is correlated with Git audit logs, CI/CD logs, runner metadata, endpoint telemetry, NDR telemetry, identity logs, registry logs, deployment logs, and change-control records.

·        Even under full telemetry conditions, this rule should support cloud exposure scoping and containment prioritization rather than standalone confirmation of compromise.

Limitations

·        AWS cannot attribute role assumption to repository workflow compromise without reliable Git, CI/CD, runner, credential, identity, source-network, or timing linkage.

·        Federated identity, workload identity, shared deployment roles, NAT, proxying, session reuse, and role chaining can obscure lineage.

·        Legitimate deployment workflows and cloud operations can closely resemble suspicious AWS activity.

·        Missing CloudTrail regions, missing data events, weak source IP preservation, incomplete identity-provider logs, or weak repository-to-role mapping can reduce confidence.

·        The rule may miss downstream abuse that uses expected roles, approved source networks, normal deployment paths, or delayed execution outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

AWS CI/CD-linked role assumption after repository workflow activity query pattern requiring CloudTrail validation, AWS account mapping, role mapping, source-network validation, repository-to-role enrichment, CI/CD lineage validation, timing-window tuning, approved workflow allowlisting, and environment-specific false-positive testing before production deployment.

CloudTrailEvent AS AWSRoleAssumption

WHERE AWSRoleAssumption.EventName IN (
"AssumeRole",
"AssumeRoleWithWebIdentity",
"GetCallerIdentity",
"GetSessionToken"
)

AND AWSRoleAssumption.RoleArn IN REFERENCE_SET (
"CI/CD Linked Roles",
"Deployment Roles",
"Production Roles",
"ECR Roles",
"EKS Roles",
"ECS Roles",
"Lambda Deployment Roles",
"CloudFormation Roles",
"Infrastructure As Code Roles",
"Secrets Manager Roles",
"S3 Access Roles",
"Privileged Roles"
)

AND (
AWSRoleAssumption.SourceContext IN (
"outside_expected_runner_network",
"outside_approved_cicd_infrastructure",
"unexpected_aws_region",
"rare_geography",
"rare_asn",
"new_source_for_role",
"role_to_repository_mismatch",
"outside_approved_deployment_window"
)

OR AWSRoleAssumption.SessionContext IN (
"unusual_session_name",
"unusual_user_agent",
"unexpected_principal",
"new_role_chain",
"broad_privilege_scope",
"long_session_duration"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_CICD_UPSTREAM_CONTEXT_WINDOW (
CICDOrGitEvent AS UpstreamSuspiciousContext
WHERE UpstreamSuspiciousContext.Repository IN SAME_REPOSITORY_OR_ROLE_MAPPING(AWSRoleAssumption.RoleArn)
AND UpstreamSuspiciousContext.EventPattern IN (
"recent_workflow_change",
"suspicious_pipeline_execution",
"recent_runner_registration",
"recent_runner_tag_change",
"recent_token_creation",
"recent_deploy_key_creation",
"recent_webhook_change",
"credential_access_behavior",
"unusual_runner_egress",
"registry_activity"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_AWS_FOLLOWON_WINDOW (
CloudTrailEvent AS FollowOnAWSActivity
WHERE FollowOnAWSActivity.PrincipalArn IN SAME_PRINCIPAL_OR_SESSION(AWSRoleAssumption.PrincipalArn)
AND FollowOnAWSActivity.EventName IN (
"CreateAccessKey",
"AttachRolePolicy",
"PutRolePolicy",
"UpdateAssumeRolePolicy",
"GetSecretValue",
"PutImage",
"BatchGetImage",
"GetObject",
"PutObject",
"UpdateFunctionCode",
"RunTask",
"CreateDeployment",
"UpdateClusterConfig",
"CreateStack",
"UpdateStack"
)
)

AND NOT ChangeContext IN (
"approved_deployment_workflow",
"approved_iac_deployment",
"approved_cloud_operations",
"approved_cicd_migration",
"approved_role_rotation",
"approved_security_testing",
"approved_incident_response"
)

Rule

AWS Secrets, ECR, or S3 Access Following Suspicious CI/CD Credential Context

Rule Format

AWS downstream resource-access correlation rule suitable for CloudTrail, Secrets Manager events, ECR events, S3 data events, STS activity, IAM activity, CI/CD logs, Git audit logs, runner telemetry, identity-provider logs, repository sensitivity enrichment, and SIEM correlation after AWS data-event validation, resource-sensitivity mapping, identity mapping, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious AWS Secrets Manager, ECR, or S3 activity following suspicious CI/CD credential context, repository workflow activity, runner execution, or automation identity activity.

·        Identify possible use of exposed CI/CD credentials or trusted automation identities to access secrets, registry images, packages, artifacts, deployment objects, sensitive source outputs, or cloud resources.

·        Prioritize Secrets Manager access, ECR authentication, ECR image push or pull, S3 object access, artifact access, deployment package access, and sensitive bucket interaction from CI/CD-linked roles or suspicious source contexts.

·        Support escalation when AWS resource access follows workflow modification, token creation, deploy-key creation, webhook modification, suspicious pipeline execution, runner credential access, unusual runner egress, or AWS role assumption.

·        Preserve separation between suspicious AWS resource access and confirmed compromise by requiring upstream repository, CI/CD, runner, identity, network, registry, deployment, or incident-response evidence before classifying cloud activity as compromise.

·        This rule does not prove credential theft, secret theft, registry compromise, package compromise, S3 compromise, cloud compromise, repository compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify AWS Secrets Manager GetSecretValue, BatchGetSecretValue, DescribeSecret, PutSecretValue, UpdateSecret, ECR GetAuthorizationToken, BatchGetImage, PutImage, InitiateLayerUpload, CompleteLayerUpload, S3 GetObject, PutObject, ListBucket, DeleteObject, or deployment artifact access.

·        Prioritize access by CI/CD-linked roles, deployment roles, image-publishing roles, package-publishing roles, infrastructure-as-code roles, production roles, service roles, or identities recently associated with suspicious CI/CD or repository activity.

·        Prioritize access to sensitive secrets, deployment secrets, registry repositories, production images, signing materials, release artifacts, deployment buckets, infrastructure-state buckets, build artifacts, package artifacts, or high-value application assets.

·        Correlate AWS resource access with upstream workflow modification, suspicious pipeline execution, runner changes, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, registry activity, or role assumption.

·        Increase confidence when resource access occurs outside expected repository, workflow, runner, source network, AWS region, account, deployment path, time window, or role baseline.

·        Increase confidence when Secrets Manager access is followed by IAM changes, ECR image push, S3 object movement, deployment activity, Lambda modification, ECS task changes, EKS activity, or CloudFormation activity.

·        Increase confidence when ECR image push or S3 object write occurs after suspicious workflow or runner activity and affects production deployment artifacts, release images, package staging, or infrastructure deployment assets.

·        Reduce severity when activity matches approved deployment workflows, image publication, package publication, infrastructure deployment, cloud operations, secret rotation, incident response, security testing, or documented change-control activity.

·        Do not classify AWS Secrets Manager, ECR, or S3 access as compromise without upstream repository, CI/CD, runner, identity, network, resource lineage, or incident-response evidence.

·        Do not treat Secrets Manager access, ECR activity, S3 activity, or deployment artifact access as compromise evidence by itself.

Required Telemetry

·        AWS CloudTrail management events.

·        AWS CloudTrail data events for S3 where enabled.

·        AWS Secrets Manager events.

·        AWS ECR events.

·        AWS STS events.

·        AWS IAM events.

·        AWS Lambda events where available.

·        AWS ECS events where available.

·        AWS EKS control-plane events where available.

·        AWS CloudFormation events where available.

·        AWS CodeDeploy or deployment logs where available.

·        AWS GuardDuty findings where available.

·        VPC Flow Logs where available.

·        CI/CD pipeline logs.

·        CI/CD job logs.

·        Runner telemetry.

·        Git audit logs.

·        Identity-provider logs.

·        Repository sensitivity enrichment.

·        Resource sensitivity enrichment.

·        AWS account ID.

·        AWS region.

·        Principal ARN.

·        Role ARN.

·        Session name.

·        Source IP.

·        User agent.

·        Resource ARN.

·        Secret name or ARN.

·        ECR repository.

·        Image digest where available.

·        Image tag where available.

·        S3 bucket.

·        S3 object key where available.

·        Event name.

·        Request parameters.

·        Result.

·        Error code where applicable.

·        Timestamp.

·        Approved resource-access baselines.

·        Approved deployment windows.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build AWS resource groups for sensitive secrets, deployment secrets, CI/CD secrets, registry repositories, production images, signing materials, release artifacts, deployment buckets, infrastructure-state buckets, build artifacts, package artifacts, and high-value application assets.

·        Build AWS identity groups for CI/CD-linked roles, deployment roles, image-publishing roles, package-publishing roles, infrastructure-as-code roles, production roles, service roles, and privileged roles.

·        Build upstream suspicious context groups using Git audit logs, CI/CD logs, runner metadata, endpoint telemetry, NDR telemetry, identity logs, registry logs, and SIEM context that identifies workflow modification, suspicious pipeline execution, runner registration, runner tag change, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, registry activity, or role assumption.

·        Build follow-on AWS behavior groups for IAM changes, ECR image push, S3 object movement, deployment activity, Lambda modification, ECS task changes, EKS activity, CloudFormation activity, and GuardDuty findings.

·        Build expected-use baselines by repository, workflow, runner, role, source network, AWS account, AWS region, resource ARN, ECR repository, S3 bucket, secret name, deployment path, and time window.

·        Validate CloudTrail management-event coverage, S3 data-event coverage, Secrets Manager coverage, ECR coverage, AWS region coverage, source IP preservation, principal ARN mapping, role ARN mapping, resource ARN mapping, image tag extraction, image digest extraction, and S3 object-key visibility.

·        Validate joins between AWS CloudTrail, CI/CD logs, Git audit logs, runner telemetry, endpoint telemetry, network telemetry, identity-provider logs, registry logs, deployment logs, and incident-response evidence.

·        Use short correlation windows when AWS resource access occurs during or immediately after suspicious CI/CD execution.

·        Use moderate correlation windows when AWS resource access follows workflow modification, runner changes, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, registry activity, or AWS role assumption.

·        Use longer correlation windows only when resource lineage, identity lineage, CI/CD lineage, cloud evidence, or incident-response evidence supports delayed linkage.

·        Add severity weighting for Secrets Manager access, sensitive secret access, production ECR repository access, image push, sensitive S3 object access, object writes to deployment paths, cross-region access, source-network mismatch, privileged role use, and follow-on IAM or deployment activity.

·        Treat AWS resource access as a confidence amplifier unless linked to suspicious repository, CI/CD, runner, credential, identity, network, deployment, or incident-response evidence.

·        Build allowlists for approved deployment workflows, image publication, package publication, infrastructure deployment, cloud operations, secret rotation, vulnerability scanning, security testing, incident response, and known automation.

·        Do not enable alert mode until CloudTrail coverage, data-event coverage, resource sensitivity mapping, identity mapping, source-network validation, field mapping, correlation reliability, false-positive rate, query performance, SOC triage workflow, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.3 / 10

·        The rule is behaviorally anchored to AWS Secrets Manager, ECR, and S3 resource access following suspicious CI/CD credential context rather than static indicators, package names, image names, domains, IP addresses, hashes, or CVE identifiers.

·        The rule remains useful if an adversary changes workflow content, runner host, role session name, AWS region, source infrastructure, image tag, S3 object key, secret name, or timing.

·        The score is supported by the durability of secret access, ECR authentication, image push, S3 object access, deployment artifact access, source-network mismatch, resource-sensitivity mismatch, and follow-on deployment or IAM activity.

·        The score is constrained by incomplete CloudTrail data events, legitimate deployment workflows, secret rotation, image publication, package publication, shared roles, NAT or proxy effects, and weak resource-sensitivity mapping.

·        The rule is durable as AWS resource-access coverage but should not be treated as standalone proof of credential theft, secret theft, registry compromise, S3 compromise, cloud compromise, or actor attribution.

TCR Assessment

Operational TCR

7.4 / 10

Full-Telemetry TCR

8.7 / 10

·        Operational confidence depends on CloudTrail coverage, S3 data events, Secrets Manager logging, ECR logging, CI/CD logs, resource sensitivity mapping, principal mapping, source-network preservation, and SIEM correlation quality.

·        Operational confidence is reduced where S3 data events are not enabled, image tags are reused, secrets are accessed frequently by automation, source IPs are transformed, resource sensitivity is not mapped, or deployment logs lack pipeline context.

·        Operational confidence is reduced during normal deployment, image publication, package publication, cloud operations, secret rotation, infrastructure deployment, incident response, and security testing.

·        Full-telemetry confidence improves when AWS CloudTrail is correlated with Git audit logs, CI/CD logs, runner metadata, endpoint telemetry, NDR telemetry, identity logs, registry logs, deployment logs, and change-control records.

·        Even under full telemetry conditions, this rule should support cloud resource scoping and containment prioritization rather than standalone confirmation of compromise.

Limitations

·        AWS cannot prove credential theft or secret theft without reliable upstream context, downstream use, exfiltration evidence, unauthorized access, or incident-response validation.

·        S3 data events may be disabled or selectively enabled, which can reduce visibility.

·        ECR and S3 activity can be normal in deployment and image publication workflows.

·        Shared roles, reused image tags, NAT, proxying, and CI/CD federation can obscure lineage.

·        The rule may miss abuse that uses expected roles, approved resource paths, normal source networks, or delayed execution outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

AWS Secrets Manager, ECR, or S3 access following suspicious CI/CD credential context query pattern requiring CloudTrail validation, data-event validation, resource sensitivity mapping, identity mapping, source-network validation, CI/CD lineage validation, timing-window tuning, approved workflow allowlisting, and environment-specific false-positive testing before production deployment.

CloudTrailEvent AS AWSResourceAccess

WHERE AWSResourceAccess.EventName IN (
"GetSecretValue",
"BatchGetSecretValue",
"DescribeSecret",
"PutSecretValue",
"UpdateSecret",
"GetAuthorizationToken",
"BatchGetImage",
"PutImage",
"InitiateLayerUpload",
"CompleteLayerUpload",
"GetObject",
"PutObject",
"ListBucket",
"DeleteObject"
)

AND AWSResourceAccess.ResourceArn IN REFERENCE_SET (
"Sensitive Secrets",
"Deployment Secrets",
"CI/CD Secrets",
"Production ECR Repositories",
"Signing Materials",
"Release Artifacts",
"Deployment Buckets",
"Infrastructure State Buckets",
"Build Artifacts",
"Package Artifacts",
"High Value Application Assets"
)

AND AWSResourceAccess.PrincipalArn IN REFERENCE_SET (
"CI/CD Linked Roles",
"Deployment Roles",
"Image Publishing Roles",
"Package Publishing Roles",
"Infrastructure As Code Roles",
"Production Roles",
"Service Roles",
"Privileged Roles"
)

AND (
AWSResourceAccess.SourceContext IN (
"outside_expected_runner_network",
"outside_approved_cicd_infrastructure",
"unexpected_aws_region",
"rare_geography",
"rare_asn",
"new_source_for_role",
"outside_approved_deployment_window"
)

OR AWSResourceAccess.ResourceContext IN (
"sensitive_secret",
"production_image_repository",
"signing_material",
"deployment_artifact",
"infrastructure_state",
"sensitive_bucket_object",
"unexpected_resource_for_role"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_CICD_UPSTREAM_CONTEXT_WINDOW (
CICDOrGitEvent AS UpstreamSuspiciousContext
WHERE UpstreamSuspiciousContext.Repository IN SAME_REPOSITORY_OR_ROLE_MAPPING(AWSResourceAccess.PrincipalArn)
AND UpstreamSuspiciousContext.EventPattern IN (
"recent_workflow_change",
"suspicious_pipeline_execution",
"recent_runner_registration",
"recent_runner_tag_change",
"recent_token_creation",
"recent_deploy_key_creation",
"recent_webhook_change",
"credential_access_behavior",
"unusual_runner_egress",
"aws_role_assumption"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_AWS_FOLLOWON_WINDOW (
CloudTrailEvent AS FollowOnAWSActivity
WHERE FollowOnAWSActivity.PrincipalArn IN SAME_PRINCIPAL_OR_SESSION(AWSResourceAccess.PrincipalArn)
AND FollowOnAWSActivity.EventName IN (
"CreateAccessKey",
"AttachRolePolicy",
"PutRolePolicy",
"UpdateAssumeRolePolicy",
"UpdateFunctionCode",
"RunTask",
"CreateDeployment",
"UpdateClusterConfig",
"CreateStack",
"UpdateStack"
)
)

AND NOT ChangeContext IN (
"approved_deployment_workflow",
"approved_image_publication",
"approved_package_publication",
"approved_iac_deployment",
"approved_cloud_operations",
"approved_secret_rotation",
"approved_security_testing",
"approved_incident_response"
)

Rule

AWS IAM or Deployment Change Following Suspicious CI/CD Activity

Rule Format

AWS IAM and deployment-control correlation rule suitable for CloudTrail, IAM events, STS events, Lambda events, ECS events, EKS events, CloudFormation events, CodeDeploy or deployment logs, CI/CD logs, Git audit logs, runner telemetry, identity-provider logs, repository sensitivity enrichment, and SIEM correlation after AWS account validation, identity mapping, resource mapping, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious AWS IAM, infrastructure, workload, or deployment changes following suspicious repository workflow activity, CI/CD execution, credential exposure, automation credential change, or AWS role assumption.

·        Identify possible downstream cloud impact after repository workflow abuse, CI/CD credential misuse, runner compromise, or automation identity misuse.

·        Prioritize IAM policy changes, role trust changes, access-key creation, Secrets Manager changes, Lambda code changes, ECS task changes, EKS cluster or role-binding activity, CloudFormation changes, CodeDeploy activity, and production deployment activity.

·        Support escalation when AWS changes occur outside expected repository, workflow, runner, source network, AWS region, account, environment, deployment path, or approved change window.

·        Preserve separation between suspicious AWS control-plane changes and confirmed compromise by requiring upstream repository, CI/CD, runner, identity, credential, network, deployment, or incident-response evidence before classifying cloud activity as compromise.

·        This rule does not prove repository compromise, credential theft, AWS compromise, IAM compromise, workload compromise, deployment compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify AWS IAM actions, access-key lifecycle actions, Secrets Manager modification actions, Lambda modification actions, ECS task or service changes, EKS cluster activity, CloudFormation stack changes, CodeDeploy activity, deployment activity, or infrastructure-as-code execution.

·        Prioritize actions performed by CI/CD-linked roles, deployment roles, infrastructure-as-code roles, production roles, service roles, workload identities, newly used principals, rare principals, or identities recently associated with suspicious CI/CD activity.

·        Correlate AWS changes with upstream workflow modification, suspicious pipeline execution, runner changes, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, registry activity, AWS role assumption, or sensitive resource access.

·        Increase confidence when AWS changes involve IAM policy attachment, inline policy creation, role trust modification, access-key creation, security group changes, production Lambda updates, ECS service updates, EKS cluster or identity changes, CloudFormation stack updates, or deployment changes affecting production workloads.

·        Increase confidence when the same principal, role session, source IP, repository, workflow, runner, deployment account, or incident timeline connects upstream CI/CD activity to AWS changes.

·        Increase confidence when changes are rare for the identity, new for the environment, outside approved deployment windows, outside expected source networks, or inconsistent with the mapped repository-to-role relationship.

·        Reduce severity when activity matches approved deployment workflows, infrastructure deployment, cloud operations, role rotation, secret rotation, release engineering, vulnerability scanning, security testing, incident response, or documented change-control activity.

·        Do not attribute AWS IAM or deployment changes to repository workflow compromise without identity, timing, runner, repository, credential, source-network, or incident-response linkage.

·        Do not treat IAM changes, Lambda changes, ECS changes, EKS activity, CloudFormation changes, or deployment activity as compromise evidence by itself.

Required Telemetry

·        AWS CloudTrail management events.

·        AWS IAM events.

·        AWS STS events.

·        AWS access-key lifecycle events.

·        AWS Secrets Manager events.

·        AWS Lambda events.

·        AWS ECS events.

·        AWS EKS control-plane events where available.

·        AWS CloudFormation events.

·        AWS CodeDeploy or deployment logs where available.

·        AWS Config where available.

·        AWS GuardDuty findings where available.

·        VPC Flow Logs where available.

·        CI/CD pipeline logs.

·        CI/CD job logs.

·        Runner metadata.

·        Git audit logs.

·        Identity-provider logs.

·        Repository sensitivity enrichment.

·        AWS account ID.

·        AWS organization ID where available.

·        AWS region.

·        Principal ARN.

·        Role ARN.

·        Session name.

·        Source IP.

·        User agent.

·        Event name.

·        Resource ARN.

·        Request parameters.

·        Response result.

·        Error code where applicable.

·        Deployment environment.

·        Resource action.

·        Timestamp.

·        Approved deployment records.

·        Approved infrastructure deployment records.

·        Approved cloud operation records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build AWS action groups for IAM policy attachment, inline policy creation, role trust modification, access-key creation, Secrets Manager modification, Lambda code update, ECS task or service update, EKS cluster or identity activity, CloudFormation stack creation or update, CodeDeploy activity, security group change, and production deployment action.

·        Build AWS identity groups for CI/CD-linked roles, deployment roles, infrastructure-as-code roles, production roles, service roles, workload identities, privileged roles, rare principals, and newly used principals.

·        Build upstream suspicious context groups using Git audit logs, CI/CD logs, runner metadata, endpoint telemetry, NDR telemetry, identity logs, registry logs, and SIEM context that identifies workflow modification, suspicious pipeline execution, runner changes, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, registry activity, AWS role assumption, or sensitive resource access.

·        Build production impact groups for production Lambda functions, ECS services, EKS clusters, CloudFormation stacks, IAM roles, security groups, Secrets Manager entries, deployment resources, and high-value AWS accounts.

·        Build expected-use baselines by repository, workflow, runner, principal, role, source network, AWS account, AWS region, deployment path, and change window.

·        Validate CloudTrail management-event coverage, IAM event coverage, STS event coverage, Lambda event coverage, ECS event coverage, EKS control-plane coverage, CloudFormation coverage, deployment log coverage, source IP preservation, principal ARN mapping, role ARN mapping, and resource ARN mapping.

·        Validate joins between AWS CloudTrail, CI/CD logs, Git audit logs, runner metadata, endpoint telemetry, network telemetry, identity-provider logs, registry logs, deployment logs, and incident-response evidence.

·        Use short correlation windows when AWS IAM or deployment changes occur during or immediately after suspicious CI/CD execution.

·        Use moderate correlation windows when AWS changes follow workflow modification, runner changes, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, role assumption, or resource access.

·        Use longer correlation windows only when AWS identity lineage, CI/CD lineage, runner evidence, cloud evidence, identity evidence, or incident-response evidence supports delayed linkage.

·        Add severity weighting for IAM privilege changes, role trust changes, access-key creation, production Lambda changes, ECS or EKS production changes, CloudFormation updates, production deployment actions, security group changes, source-network mismatch, and absence of approved change context.

·        Treat AWS IAM or deployment changes as confidence amplifiers unless linked to suspicious repository, CI/CD, runner, credential, identity, network, deployment, or incident-response evidence.

·        Build allowlists for approved deployment workflows, infrastructure deployment, cloud operations, role rotation, secret rotation, release engineering, vulnerability scanning, security testing, incident response, and known automation.

·        Do not enable alert mode until AWS account coverage, CloudTrail coverage, identity mapping, resource mapping, source-network validation, expected-use baselines, field mapping, correlation reliability, false-positive rate, query performance, SOC triage workflow, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.2 / 10

·        The rule is behaviorally anchored to AWS IAM, workload, infrastructure, and deployment changes following suspicious CI/CD activity rather than static indicators, domains, IP addresses, hashes, package names, image names, repository names, or CVE identifiers.

·        The rule remains useful if an adversary changes workflow content, runner host, AWS principal, role session name, AWS region, deployment target, source infrastructure, tool sequence, or timing.

·        The score is supported by the durability of IAM changes, role trust changes, access-key creation, Secrets Manager modification, Lambda changes, ECS changes, EKS activity, CloudFormation changes, deployment activity, and production-impact context.

·        The score is constrained by legitimate infrastructure deployment, release engineering, cloud operations, role rotation, shared roles, source IP transformation, incomplete CloudTrail coverage, and weak repository-to-role mapping.

·        The rule is durable as AWS downstream-impact coverage but should not be treated as standalone proof of repository workflow compromise, credential theft, AWS compromise, workload compromise, deployment compromise, or actor attribution.

TCR Assessment

Operational TCR

7.3 / 10

Full-Telemetry TCR

8.6 / 10

·        Operational confidence depends on CloudTrail management-event coverage, IAM visibility, CI/CD logs, identity-provider logs, repository-to-role mapping, source-network preservation, AWS account mapping, resource mapping, and SIEM correlation quality.

·        Operational confidence is reduced where deployment activity is frequent, infrastructure-as-code changes are noisy, source IPs are transformed, CloudTrail coverage is incomplete, or deployment records lack pipeline context.

·        Operational confidence is reduced during normal infrastructure deployment, release engineering, cloud operations, role rotation, secret rotation, incident response, and security testing.

·        Full-telemetry confidence improves when AWS CloudTrail is correlated with Git audit logs, CI/CD logs, runner metadata, endpoint telemetry, NDR telemetry, identity logs, registry logs, deployment logs, AWS Config, GuardDuty, and change-control records.

·        Even under full telemetry conditions, this rule should support cloud impact assessment and containment prioritization rather than standalone confirmation of compromise.

Limitations

·        AWS cannot attribute IAM or deployment changes to repository workflow compromise without reliable Git, CI/CD, runner, credential, identity, source-network, or timing linkage.

·        Legitimate deployment workflows, infrastructure-as-code, cloud operations, and release engineering can closely resemble suspicious AWS control-plane activity.

·        Federated identity, shared roles, NAT, proxying, session reuse, and role chaining can obscure lineage.

·        Missing CloudTrail regions, incomplete EKS control-plane logging, incomplete deployment logs, or weak source IP preservation can reduce confidence.

·        The rule may miss downstream abuse that uses expected roles, approved deployment paths, normal source networks, or delayed execution outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

AWS IAM or deployment change following suspicious CI/CD activity query pattern requiring CloudTrail validation, AWS account mapping, identity mapping, resource mapping, source-network validation, CI/CD lineage validation, timing-window tuning, approved workflow allowlisting, and environment-specific false-positive testing before production deployment.

CloudTrailEvent AS AWSControlPlaneChange

WHERE AWSControlPlaneChange.EventName IN (
"AttachRolePolicy",
"PutRolePolicy",
"UpdateAssumeRolePolicy",
"CreateAccessKey",
"DeleteAccessKey",
"PutSecretValue",
"UpdateSecret",
"UpdateFunctionCode",
"RunTask",
"UpdateService",
"CreateDeployment",
"UpdateClusterConfig",
"CreateStack",
"UpdateStack",
"AuthorizeSecurityGroupIngress",
"AuthorizeSecurityGroupEgress"
)

AND AWSControlPlaneChange.PrincipalArn IN REFERENCE_SET (
"CI/CD Linked Roles",
"Deployment Roles",
"Infrastructure As Code Roles",
"Production Roles",
"Service Roles",
"Workload Identities",
"Privileged Roles",
"Rare Principals",
"Newly Used Principals"
)

AND (
AWSControlPlaneChange.ResourceContext IN (
"production_lambda",
"production_ecs_service",
"production_eks_cluster",
"production_cloudformation_stack",
"privileged_iam_role",
"sensitive_secret",
"deployment_resource",
"high_value_aws_account"
)

OR AWSControlPlaneChange.SourceContext IN (
"outside_expected_runner_network",
"outside_approved_cicd_infrastructure",
"unexpected_aws_region",
"rare_geography",
"rare_asn",
"new_source_for_role",
"outside_approved_deployment_window",
"repository_to_role_mismatch"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_CICD_UPSTREAM_CONTEXT_WINDOW (
CICDOrGitEvent AS UpstreamSuspiciousContext
WHERE UpstreamSuspiciousContext.Repository IN SAME_REPOSITORY_OR_ROLE_MAPPING(AWSControlPlaneChange.PrincipalArn)
AND UpstreamSuspiciousContext.EventPattern IN (
"recent_workflow_change",
"suspicious_pipeline_execution",
"recent_runner_registration",
"recent_runner_tag_change",
"recent_token_creation",
"recent_deploy_key_creation",
"recent_webhook_change",
"credential_access_behavior",
"unusual_runner_egress",
"aws_role_assumption",
"sensitive_resource_access"
)
)

AND NOT ChangeContext IN (
"approved_deployment_workflow",
"approved_iac_deployment",
"approved_cloud_operations",
"approved_role_rotation",
"approved_secret_rotation",
"approved_release_engineering",
"approved_security_testing",
"approved_incident_response"
)

Azure

Detection Viability Assessment

Azure has three rules for this EXP report.

·        Azure is viable for detecting downstream cloud-control-plane and identity-plane activity associated with self-hosted Git platform compromise through repository workflow abuse when Microsoft Entra ID logs, Azure Activity logs, Azure Resource Manager activity, Key Vault logs, Azure Container Registry logs, Storage logs, deployment logs, Defender for Cloud alerts, and CI/CD identity mappings are available.

·        Azure is strongest when cloud and identity events can be correlated with Git audit logs, CI/CD pipeline logs, runner telemetry, identity-provider logs, registry activity, deployment activity, source IP context, workload identity context, managed identity context, service principal context, and repository sensitivity enrichment.

·        Azure can identify suspicious use of CI/CD-linked service principals, managed identities, federated credentials, workload identities, deployment identities, Azure Container Registry identities, Key Vault access, Storage access, role assignment changes, credential changes, application secret changes, container image activity, and deployment activity after suspicious repository workflow or automation credential activity.

·        Azure is not a standalone source for confirming repository workflow compromise because Azure telemetry does not directly prove Git platform compromise, workflow abuse, token theft, runner compromise, package compromise, or actor attribution without upstream repository, CI/CD, endpoint, identity, or incident-response evidence.

·        Azure detections must avoid treating Azure API activity, service principal sign-in, managed identity use, role assignment, Key Vault access, Azure Container Registry access, Storage access, Azure Functions changes, AKS activity, or deployment actions as confirmed compromise by themselves.

·        Azure detections should support downstream exposure scoping, identity investigation, cloud containment prioritization, credential-use review, deployment review, and impact assessment when suspicious repository or CI/CD activity aligns with Azure control-plane activity.

·        Azure rules should not generate high-confidence alerting from a single Azure event unless the activity is correlated with suspicious repository, CI/CD, runner, identity, credential, registry, deployment, or incident-response context.

Rule

Suspicious CI/CD-Linked Azure Identity Use After Repository Workflow Activity

Rule Format

Azure identity-plane and cloud-control-plane correlation rule suitable for Microsoft Entra ID sign-in logs, service principal sign-in logs, managed identity activity, federated credential activity, Azure Activity logs, Azure Resource Manager events, CI/CD logs, Git audit logs, runner metadata, source IP enrichment, repository sensitivity enrichment, Defender for Cloud alerts where available, and SIEM correlation after Azure tenant mapping, subscription mapping, identity mapping, source-network validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious use of CI/CD-linked service principals, managed identities, workload identities, federated credentials, deployment identities, or privileged Azure identities after repository workflow modification, suspicious pipeline execution, runner changes, token creation, deploy-key creation, webhook modification, or credential-access behavior.

·        Identify possible downstream Azure access following repository workflow abuse, CI/CD credential exposure, runner compromise, or automation identity misuse.

·        Prioritize identity use involving deployment identities, production identities, Azure Container Registry identities, AKS identities, Azure Functions deployment identities, infrastructure-as-code identities, Key Vault identities, Storage identities, owner-like identities, contributor-like identities, and identities tied to sensitive repositories.

·        Support escalation when Azure identity use occurs from unexpected source networks, unusual geographies, unfamiliar runners, rare identities, new user agents, unusual sign-in patterns, unexpected repositories, unexpected subscriptions, or outside approved deployment windows.

·        Preserve separation between suspicious Azure identity use and confirmed compromise by requiring upstream Git, CI/CD, runner, endpoint, identity, network, registry, deployment, or incident-response evidence before classifying cloud activity as compromise.

·        This rule does not prove repository compromise, workflow abuse, credential theft, cloud compromise, Azure tenant compromise, deployment compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify Microsoft Entra ID sign-in activity, service principal sign-in activity, managed identity activity, workload identity use, federated credential use, Azure Resource Manager activity, token issuance, token exchange, or identity activity involving CI/CD-linked identities, deployment identities, infrastructure-as-code identities, ACR identities, AKS identities, Azure Functions identities, Key Vault identities, Storage identities, or privileged identities.

·        Prioritize Azure identity use following repository workflow modification, suspicious pipeline execution, new runner registration, runner tag change, token creation, deploy-key creation, webhook modification, protected-branch change, credential-access behavior, unusual runner egress, or registry activity.

·        Prioritize source context that is outside expected runner networks, outside approved CI/CD infrastructure, outside expected Azure regions, outside expected geographies, new for the identity, rare for the service principal, inconsistent with the deployment path, or not present in approved source baselines.

·        Prioritize sessions or sign-ins with unusual user agents, unfamiliar application IDs, new federated credential paths, unexpected service principals, broad privilege scope, unexpected Conditional Access behavior, or activity outside approved deployment windows.

·        Increase confidence when Azure identity use is followed by role assignment changes, application credential changes, federated credential changes, Key Vault access, Storage access, Azure Container Registry authentication, image push, Azure Functions changes, App Service changes, AKS activity, Azure Resource Manager deployment activity, or production deployment activity.

·        Increase confidence when the Azure identity maps to sensitive repositories, production deployment, package publication, image publication, signing, infrastructure-as-code, cloud deployment, Kubernetes deployment, or high-value application delivery.

·        Reduce severity when activity matches approved deployment workflows, infrastructure deployment, cloud operations, identity rotation, CI/CD migration, incident response, security testing, or documented change-control activity.

·        Do not classify Azure identity use as repository workflow compromise without upstream repository, CI/CD, runner, credential, identity, network, or incident-response linkage.

·        Do not treat service principal sign-in, managed identity use, federated identity use, ACR authentication, Storage access, role assignment activity, or deployment activity as compromise evidence by itself.

Required Telemetry

·        Microsoft Entra ID sign-in logs.

·        Microsoft Entra ID service principal sign-in logs.

·        Microsoft Entra ID audit logs.

·        Managed identity activity where available.

·        Federated credential activity where available.

·        Azure Activity logs.

·        Azure Resource Manager events.

·        Azure role assignment events.

·        Azure application credential events.

·        Azure Key Vault access logs.

·        Azure Container Registry events.

·        Azure Storage data logs where enabled.

·        Azure Functions logs where available.

·        Azure App Service logs where available.

·        Azure Kubernetes Service audit logs where available.

·        Azure deployment logs where available.

·        Defender for Cloud alerts where available.

·        Network telemetry where available.

·        Identity-provider logs.

·        CI/CD pipeline logs.

·        CI/CD job logs.

·        Runner metadata.

·        Git audit logs.

·        Repository sensitivity enrichment.

·        Azure tenant ID.

·        Azure subscription ID.

·        Azure resource group.

·        Azure region.

·        Application ID.

·        Service principal ID.

·        Managed identity ID.

·        Principal ID.

·        User principal name where applicable.

·        Source IP.

·        User agent.

·        Conditional Access result where available.

·        Resource ID.

·        Operation name.

·        Result.

·        Error code where applicable.

·        Timestamp.

·        Approved CI/CD source networks.

·        Approved identity-to-repository mapping.

·        Approved deployment windows.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build Azure identity groups for CI/CD-linked service principals, managed identities, workload identities, deployment identities, production identities, ACR identities, AKS identities, Azure Functions identities, App Service identities, infrastructure-as-code identities, Key Vault identities, Storage identities, owner-like identities, contributor-like identities, and privileged identities.

·        Build suspicious source groups for non-runner networks, rare geographies, rare ASNs, new source IPs for the identity, source IPs outside approved CI/CD infrastructure, unexpected Azure regions, and identities outside expected repository-to-identity mappings.

·        Build upstream suspicious context groups using Git audit logs, CI/CD logs, runner metadata, endpoint telemetry, NDR telemetry, identity logs, registry logs, and SIEM context that identifies workflow modification, suspicious pipeline execution, runner registration, runner tag change, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, or registry activity.

·        Build follow-on Azure activity groups for role assignment changes, application credential changes, federated credential changes, Key Vault access, Storage access, ACR authentication, image push, Azure Functions modification, App Service modification, AKS activity, Azure Resource Manager deployment activity, and production deployment activity.

·        Build repository-to-identity and identity-to-environment mappings for sensitive repositories, production deployment, package publication, image publication, signing, infrastructure-as-code, cloud deployment, Kubernetes deployment, and high-value application delivery.

·        Validate Microsoft Entra ID log coverage, service principal sign-in coverage, audit-log coverage, Azure Activity coverage, subscription coverage, tenant coverage, Key Vault diagnostic settings, ACR diagnostic settings, Storage data logging, source IP preservation, service principal mapping, managed identity mapping, federated credential mapping, and CI/CD identity mapping.

·        Validate joins between Microsoft Entra ID logs, Azure Activity logs, CI/CD logs, Git audit logs, runner metadata, endpoint telemetry, network telemetry, registry logs, deployment logs, and incident-response evidence.

·        Use short correlation windows when Azure identity use occurs during or immediately after suspicious CI/CD execution.

·        Use moderate correlation windows when identity use follows workflow modification, runner changes, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, or registry activity.

·        Use longer correlation windows only when Azure identity lineage, CI/CD lineage, runner evidence, cloud evidence, identity evidence, or incident-response evidence supports delayed linkage.

·        Add severity weighting for privileged identity use, production subscription access, unusual source network, new federated credential use, application credential changes, role assignment changes, Key Vault access, ACR image push, sensitive Storage access, and production deployment actions.

·        Treat Azure identity use as a confidence amplifier unless linked to suspicious repository, CI/CD, runner, credential, identity, network, deployment, or incident-response evidence.

·        Build allowlists for approved deployment workflows, infrastructure deployment, cloud operations, CI/CD migration, identity rotation, credential rotation, vulnerability scanning, security testing, incident response, and known automation.

·        Do not enable alert mode until Azure tenant coverage, subscription coverage, Entra ID coverage, Azure Activity coverage, identity mapping, source-network validation, repository-to-identity enrichment, field mapping, correlation reliability, false-positive rate, query performance, SOC triage workflow, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.4 / 10

·        The rule is behaviorally anchored to CI/CD-linked Azure identity use and downstream control-plane activity rather than static indicators, domains, IP addresses, hashes, repository names, package names, image names, or CVE identifiers.

·        The rule remains useful if an adversary changes workflow content, runner host, service principal, managed identity, federated credential path, source infrastructure, Azure region, user agent, token source, deployment path, or timing.

·        The score is supported by the durability of service principal use, managed identity use, federated identity use, unusual source context, identity-to-repository mismatch, role assignment activity, Key Vault access, ACR access, Storage access, and production deployment activity.

·        The score is constrained by legitimate deployment workflows, federated identity complexity, NAT or proxy effects, shared runner networks, incomplete diagnostic logging, incomplete Storage data logs, and weak repository-to-identity mapping.

·        The rule is durable as Azure identity-lineage coverage but should not be treated as standalone proof of repository workflow compromise, credential theft, Azure compromise, deployment compromise, or actor attribution.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

8.8 / 10

·        Operational confidence depends on Microsoft Entra ID logs, service principal sign-in logs, Azure Activity logs, identity-provider logs, CI/CD logs, repository-to-identity mapping, source-network preservation, runner identity mapping, tenant mapping, subscription mapping, and SIEM correlation quality.

·        Operational confidence is reduced where federated identity obscures repository lineage, source IPs are transformed, service principal sign-ins are incomplete, diagnostic settings are inconsistent, runners share networks, Storage data logs are incomplete, or deployment records lack pipeline context.

·        Operational confidence is reduced during normal infrastructure deployment, release engineering, cloud operations, CI/CD migration, identity rotation, credential rotation, incident response, and security testing.

·        Full-telemetry confidence improves when Azure telemetry is correlated with Git audit logs, CI/CD logs, runner metadata, endpoint telemetry, NDR telemetry, identity logs, registry logs, deployment logs, Defender for Cloud, and change-control records.

·        Even under full telemetry conditions, this rule should support cloud exposure scoping and containment prioritization rather than standalone confirmation of compromise.

Limitations

·        Azure cannot attribute identity use to repository workflow compromise without reliable Git, CI/CD, runner, credential, identity, source-network, or timing linkage.

·        Federated identity, workload identity, shared deployment identities, NAT, proxying, session reuse, and service principal reuse can obscure lineage.

·        Legitimate deployment workflows and cloud operations can closely resemble suspicious Azure activity.

·        Missing Entra ID logs, missing Azure Activity logs, missing diagnostic settings, missing Storage data logs, weak source IP preservation, incomplete identity-provider logs, or weak repository-to-identity mapping can reduce confidence.

·        The rule may miss downstream abuse that uses expected identities, approved source networks, normal deployment paths, or delayed execution outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Azure CI/CD-linked identity use after repository workflow activity query pattern requiring Microsoft Entra ID validation, Azure Activity validation, tenant mapping, subscription mapping, identity mapping, source-network validation, repository-to-identity enrichment, CI/CD lineage validation, timing-window tuning, approved workflow allowlisting, and environment-specific false-positive testing before production deployment.

AzureIdentityEvent AS AzureIdentityUse

WHERE AzureIdentityUse.EventName IN (
"ServicePrincipalSignIn",
"ManagedIdentitySignIn",
"FederatedCredentialSignIn",
"TokenIssued",
"TokenExchanged",
"AzureResourceManagerCall"
)

AND AzureIdentityUse.PrincipalId IN REFERENCE_SET (
"CI/CD Linked Service Principals",
"Managed Identities",
"Workload Identities",
"Deployment Identities",
"Production Identities",
"ACR Identities",
"AKS Identities",
"Azure Functions Identities",
"App Service Identities",
"Infrastructure As Code Identities",
"Key Vault Identities",
"Storage Identities",
"Owner Like Identities",
"Contributor Like Identities",
"Privileged Identities"
)

AND (
AzureIdentityUse.SourceContext IN (
"outside_expected_runner_network",
"outside_approved_cicd_infrastructure",
"unexpected_azure_region",
"rare_geography",
"rare_asn",
"new_source_for_identity",
"identity_to_repository_mismatch",
"outside_approved_deployment_window"
)

OR AzureIdentityUse.SessionContext IN (
"unusual_user_agent",
"unexpected_application_id",
"new_federated_credential_path",
"unexpected_service_principal",
"broad_privilege_scope",
"conditional_access_anomaly"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_CICD_UPSTREAM_CONTEXT_WINDOW (
CICDOrGitEvent AS UpstreamSuspiciousContext
WHERE UpstreamSuspiciousContext.Repository IN SAME_REPOSITORY_OR_IDENTITY_MAPPING(AzureIdentityUse.PrincipalId)
AND UpstreamSuspiciousContext.EventPattern IN (
"recent_workflow_change",
"suspicious_pipeline_execution",
"recent_runner_registration",
"recent_runner_tag_change",
"recent_token_creation",
"recent_deploy_key_creation",
"recent_webhook_change",
"credential_access_behavior",
"unusual_runner_egress",
"registry_activity"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_AZURE_FOLLOWON_WINDOW (
AzureActivityEvent AS FollowOnAzureActivity
WHERE FollowOnAzureActivity.PrincipalId IN SAME_PRINCIPAL_OR_SESSION(AzureIdentityUse.PrincipalId)
AND FollowOnAzureActivity.OperationName IN (
"Microsoft.Authorization/roleAssignments/write",
"Microsoft.Graph/applications/credentials/update",
"Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write",
"Microsoft.KeyVault/vaults/secrets/read",
"Microsoft.ContainerRegistry/registries/push/write",
"Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read",
"Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write",
"Microsoft.Web/sites/functions/write",
"Microsoft.Web/sites/write",
"Microsoft.ContainerService/managedClusters/write",
"Microsoft.Resources/deployments/write"
)
)

AND NOT ChangeContext IN (
"approved_deployment_workflow",
"approved_iac_deployment",
"approved_cloud_operations",
"approved_cicd_migration",
"approved_identity_rotation",
"approved_credential_rotation",
"approved_security_testing",
"approved_incident_response"
)

Rule

Azure Key Vault, ACR, or Storage Access Following Suspicious CI/CD Credential Context

Rule Format

Azure downstream resource-access correlation rule suitable for Microsoft Entra ID logs, Azure Activity logs, Key Vault diagnostic logs, Azure Container Registry logs, Azure Storage data logs, managed identity logs, service principal sign-in logs, CI/CD logs, Git audit logs, runner telemetry, repository sensitivity enrichment, resource sensitivity enrichment, and SIEM correlation after diagnostic-log validation, resource-sensitivity mapping, identity mapping, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious Azure Key Vault, Azure Container Registry, or Azure Storage activity following suspicious CI/CD credential context, repository workflow activity, runner execution, or automation identity activity.

·        Identify possible use of exposed CI/CD credentials or trusted automation identities to access secrets, registry images, packages, artifacts, deployment objects, sensitive source outputs, or Azure resources.

·        Prioritize Key Vault secret access, certificate access, key access, ACR authentication, ACR image push or pull, Storage blob access, artifact access, deployment package access, and sensitive container interaction from CI/CD-linked identities or suspicious source contexts.

·        Support escalation when Azure resource access follows workflow modification, token creation, deploy-key creation, webhook modification, suspicious pipeline execution, runner credential access, unusual runner egress, or Azure identity use.

·        Preserve separation between suspicious Azure resource access and confirmed compromise by requiring upstream repository, CI/CD, runner, identity, network, registry, deployment, or incident-response evidence before classifying cloud activity as compromise.

·        This rule does not prove credential theft, secret theft, registry compromise, package compromise, Storage compromise, cloud compromise, repository compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify Azure Key Vault secret get, key get, certificate get, secret set, key update, certificate update, Azure Container Registry authentication, image pull, image push, repository write, Azure Storage blob read, blob write, container listing, blob delete, or deployment artifact access.

·        Prioritize access by CI/CD-linked service principals, managed identities, workload identities, deployment identities, image-publishing identities, package-publishing identities, infrastructure-as-code identities, production identities, service identities, or identities recently associated with suspicious CI/CD or repository activity.

·        Prioritize access to sensitive secrets, deployment secrets, registry repositories, production images, signing materials, release artifacts, deployment containers, infrastructure-state containers, build artifacts, package artifacts, or high-value application assets.

·        Correlate Azure resource access with upstream workflow modification, suspicious pipeline execution, runner changes, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, registry activity, or Azure identity use.

·        Increase confidence when resource access occurs outside expected repository, workflow, runner, source network, Azure region, subscription, resource group, deployment path, time window, or identity baseline.

·        Increase confidence when Key Vault access is followed by role assignment changes, ACR image push, Storage object movement, deployment activity, Azure Functions modification, App Service modification, AKS activity, or Azure Resource Manager deployment activity.

·        Increase confidence when ACR image push or Storage blob write occurs after suspicious workflow or runner activity and affects production deployment artifacts, release images, package staging, or infrastructure deployment assets.

·        Reduce severity when activity matches approved deployment workflows, image publication, package publication, infrastructure deployment, cloud operations, secret rotation, certificate rotation, incident response, security testing, or documented change-control activity.

·        Do not classify Azure Key Vault, ACR, or Storage access as compromise without upstream repository, CI/CD, runner, identity, network, resource lineage, or incident-response evidence.

·        Do not treat Key Vault access, ACR activity, Storage activity, or deployment artifact access as compromise evidence by itself.

Required Telemetry

·        Microsoft Entra ID sign-in logs.

·        Microsoft Entra ID service principal sign-in logs.

·        Microsoft Entra ID audit logs.

·        Azure Activity logs.

·        Azure Key Vault diagnostic logs.

·        Azure Container Registry logs.

·        Azure Storage data logs where enabled.

·        Managed identity activity where available.

·        Federated credential activity where available.

·        Azure Resource Manager events.

·        Azure Functions logs where available.

·        Azure App Service logs where available.

·        Azure Kubernetes Service audit logs where available.

·        Azure deployment logs where available.

·        Defender for Cloud alerts where available.

·        Network telemetry where available.

·        CI/CD pipeline logs.

·        CI/CD job logs.

·        Runner telemetry.

·        Git audit logs.

·        Identity-provider logs.

·        Repository sensitivity enrichment.

·        Resource sensitivity enrichment.

·        Azure tenant ID.

·        Azure subscription ID.

·        Azure resource group.

·        Azure region.

·        Principal ID.

·        Service principal ID.

·        Managed identity ID.

·        Application ID.

·        Source IP.

·        User agent.

·        Resource ID.

·        Key Vault name.

·        Secret name where available.

·        Key name where available.

·        Certificate name where available.

·        ACR registry.

·        Image digest where available.

·        Image tag where available.

·        Storage account.

·        Storage container.

·        Blob path where available.

·        Operation name.

·        Result.

·        Error code where applicable.

·        Timestamp.

·        Approved resource-access baselines.

·        Approved deployment windows.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build Azure resource groups for sensitive secrets, deployment secrets, CI/CD secrets, Key Vault keys, certificates, registry repositories, production images, signing materials, release artifacts, deployment containers, infrastructure-state containers, build artifacts, package artifacts, and high-value application assets.

·        Build Azure identity groups for CI/CD-linked service principals, managed identities, workload identities, deployment identities, image-publishing identities, package-publishing identities, infrastructure-as-code identities, production identities, service identities, and privileged identities.

·        Build upstream suspicious context groups using Git audit logs, CI/CD logs, runner metadata, endpoint telemetry, NDR telemetry, identity logs, registry logs, and SIEM context that identifies workflow modification, suspicious pipeline execution, runner registration, runner tag change, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, registry activity, or Azure identity use.

·        Build follow-on Azure behavior groups for role assignment changes, ACR image push, Storage object movement, deployment activity, Azure Functions modification, App Service modification, AKS activity, Azure Resource Manager deployment activity, and Defender for Cloud alerts.

·        Build expected-use baselines by repository, workflow, runner, identity, source network, tenant, subscription, Azure region, resource ID, ACR registry, Storage account, Key Vault name, deployment path, and time window.

·        Validate Key Vault diagnostic settings, ACR diagnostic settings, Storage data logs, Azure Activity coverage, Entra ID coverage, tenant coverage, subscription coverage, source IP preservation, principal ID mapping, managed identity mapping, service principal mapping, resource ID mapping, image tag extraction, image digest extraction, and blob path visibility.

·        Validate joins between Azure telemetry, CI/CD logs, Git audit logs, runner telemetry, endpoint telemetry, network telemetry, identity-provider logs, registry logs, deployment logs, and incident-response evidence.

·        Use short correlation windows when Azure resource access occurs during or immediately after suspicious CI/CD execution.

·        Use moderate correlation windows when Azure resource access follows workflow modification, runner changes, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, registry activity, or Azure identity use.

·        Use longer correlation windows only when resource lineage, identity lineage, CI/CD lineage, cloud evidence, or incident-response evidence supports delayed linkage.

·        Add severity weighting for Key Vault secret access, sensitive secret access, production ACR repository access, image push, sensitive Storage object access, blob writes to deployment paths, cross-region access, source-network mismatch, privileged identity use, and follow-on role assignment or deployment activity.

·        Treat Azure resource access as a confidence amplifier unless linked to suspicious repository, CI/CD, runner, credential, identity, network, deployment, or incident-response evidence.

·        Build allowlists for approved deployment workflows, image publication, package publication, infrastructure deployment, cloud operations, secret rotation, certificate rotation, vulnerability scanning, security testing, incident response, and known automation.

·        Do not enable alert mode until diagnostic-log coverage, Storage data-log coverage, resource sensitivity mapping, identity mapping, source-network validation, field mapping, correlation reliability, false-positive rate, query performance, SOC triage workflow, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.3 / 10

·        The rule is behaviorally anchored to Azure Key Vault, ACR, and Storage resource access following suspicious CI/CD credential context rather than static indicators, package names, image names, domains, IP addresses, hashes, or CVE identifiers.

·        The rule remains useful if an adversary changes workflow content, runner host, service principal, managed identity, Azure region, source infrastructure, image tag, blob path, secret name, certificate name, or timing.

·        The score is supported by the durability of secret access, certificate access, ACR authentication, image push, Storage blob access, deployment artifact access, source-network mismatch, resource-sensitivity mismatch, and follow-on deployment or role assignment activity.

·        The score is constrained by incomplete diagnostic logging, legitimate deployment workflows, secret rotation, certificate rotation, image publication, package publication, shared identities, NAT or proxy effects, and weak resource-sensitivity mapping.

·        The rule is durable as Azure resource-access coverage but should not be treated as standalone proof of credential theft, secret theft, registry compromise, Storage compromise, cloud compromise, or actor attribution.

TCR Assessment

Operational TCR

7.4 / 10

Full-Telemetry TCR

8.7 / 10

·        Operational confidence depends on Azure Activity coverage, Key Vault diagnostics, ACR diagnostics, Storage data logs, Entra ID logs, CI/CD logs, resource sensitivity mapping, principal mapping, source-network preservation, and SIEM correlation quality.

·        Operational confidence is reduced where Storage data logs are not enabled, image tags are reused, secrets are accessed frequently by automation, source IPs are transformed, resource sensitivity is not mapped, or deployment logs lack pipeline context.

·        Operational confidence is reduced during normal deployment, image publication, package publication, cloud operations, secret rotation, certificate rotation, infrastructure deployment, incident response, and security testing.

·        Full-telemetry confidence improves when Azure telemetry is correlated with Git audit logs, CI/CD logs, runner metadata, endpoint telemetry, NDR telemetry, identity logs, registry logs, deployment logs, Defender for Cloud, and change-control records.

·        Even under full telemetry conditions, this rule should support cloud resource scoping and containment prioritization rather than standalone confirmation of compromise.

Limitations

·        Azure cannot prove credential theft or secret theft without reliable upstream context, downstream use, exfiltration evidence, unauthorized access, or incident-response validation.

·        Azure Storage data logs may be disabled or selectively enabled, which can reduce visibility.

·        ACR and Storage activity can be normal in deployment and image publication workflows.

·        Shared identities, reused image tags, NAT, proxying, and CI/CD federation can obscure lineage.

·        The rule may miss abuse that uses expected identities, approved resource paths, normal source networks, or delayed execution outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Azure Key Vault, ACR, or Storage access following suspicious CI/CD credential context query pattern requiring Microsoft Entra ID validation, Azure Activity validation, diagnostic-log validation, Storage data-log validation, resource sensitivity mapping, identity mapping, source-network validation, CI/CD lineage validation, timing-window tuning, approved workflow allowlisting, and environment-specific false-positive testing before production deployment.

AzureResourceEvent AS AzureResourceAccess

WHERE AzureResourceAccess.OperationName IN (
"SecretGet",
"SecretList",
"SecretSet",
"KeyGet",
"KeyList",
"CertificateGet",
"CertificateList",
"ContainerRegistryLogin",
"ImagePull",
"ImagePush",
"RepositoryWrite",
"BlobRead",
"BlobWrite",
"ContainerList",
"BlobDelete",
"DeploymentArtifactAccess"
)

AND AzureResourceAccess.ResourceId IN REFERENCE_SET (
"Sensitive Secrets",
"Deployment Secrets",
"CI/CD Secrets",
"Key Vault Keys",
"Certificates",
"Production ACR Repositories",
"Signing Materials",
"Release Artifacts",
"Deployment Containers",
"Infrastructure State Containers",
"Build Artifacts",
"Package Artifacts",
"High Value Application Assets"
)

AND AzureResourceAccess.PrincipalId IN REFERENCE_SET (
"CI/CD Linked Service Principals",
"Managed Identities",
"Workload Identities",
"Deployment Identities",
"Image Publishing Identities",
"Package Publishing Identities",
"Infrastructure As Code Identities",
"Production Identities",
"Service Identities",
"Privileged Identities"
)

AND (
AzureResourceAccess.SourceContext IN (
"outside_expected_runner_network",
"outside_approved_cicd_infrastructure",
"unexpected_azure_region",
"rare_geography",
"rare_asn",
"new_source_for_identity",
"outside_approved_deployment_window"
)

OR AzureResourceAccess.ResourceContext IN (
"sensitive_secret",
"sensitive_key",
"certificate_material",
"production_image_repository",
"signing_material",
"deployment_artifact",
"infrastructure_state",
"sensitive_storage_object",
"unexpected_resource_for_identity"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_CICD_UPSTREAM_CONTEXT_WINDOW (
CICDOrGitEvent AS UpstreamSuspiciousContext
WHERE UpstreamSuspiciousContext.Repository IN SAME_REPOSITORY_OR_IDENTITY_MAPPING(AzureResourceAccess.PrincipalId)
AND UpstreamSuspiciousContext.EventPattern IN (
"recent_workflow_change",
"suspicious_pipeline_execution",
"recent_runner_registration",
"recent_runner_tag_change",
"recent_token_creation",
"recent_deploy_key_creation",
"recent_webhook_change",
"credential_access_behavior",
"unusual_runner_egress",
"azure_identity_use"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_AZURE_FOLLOWON_WINDOW (
AzureActivityEvent AS FollowOnAzureActivity
WHERE FollowOnAzureActivity.PrincipalId IN SAME_PRINCIPAL_OR_SESSION(AzureResourceAccess.PrincipalId)
AND FollowOnAzureActivity.OperationName IN (
"Microsoft.Authorization/roleAssignments/write",
"Microsoft.Graph/applications/credentials/update",
"Microsoft.ContainerRegistry/registries/push/write",
"Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write",
"Microsoft.Web/sites/functions/write",
"Microsoft.Web/sites/write",
"Microsoft.ContainerService/managedClusters/write",
"Microsoft.Resources/deployments/write"
)
)

AND NOT ChangeContext IN (
"approved_deployment_workflow",
"approved_image_publication",
"approved_package_publication",
"approved_iac_deployment",
"approved_cloud_operations",
"approved_secret_rotation",
"approved_certificate_rotation",
"approved_security_testing",
"approved_incident_response"
)

Rule

Azure Role Assignment or Deployment Change Following Suspicious CI/CD Activity

Rule Format

Azure role-assignment and deployment-control correlation rule suitable for Microsoft Entra ID logs, Azure Activity logs, Azure Resource Manager events, role assignment events, application credential events, managed identity events, Azure Functions events, App Service events, AKS events, deployment logs, CI/CD logs, Git audit logs, runner telemetry, identity-provider logs, repository sensitivity enrichment, and SIEM correlation after Azure tenant validation, subscription validation, identity mapping, resource mapping, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious Azure role assignment, identity, infrastructure, workload, or deployment changes following suspicious repository workflow activity, CI/CD execution, credential exposure, automation credential change, or Azure identity use.

·        Identify possible downstream cloud impact after repository workflow abuse, CI/CD credential misuse, runner compromise, or automation identity misuse.

·        Prioritize role assignment changes, application credential changes, federated credential changes, managed identity changes, Key Vault changes, Azure Functions code changes, App Service changes, AKS cluster or role-binding activity, Azure Resource Manager deployments, and production deployment activity.

·        Support escalation when Azure changes occur outside expected repository, workflow, runner, source network, Azure region, subscription, resource group, environment, deployment path, or approved change window.

·        Preserve separation between suspicious Azure control-plane changes and confirmed compromise by requiring upstream repository, CI/CD, runner, identity, credential, network, deployment, or incident-response evidence before classifying cloud activity as compromise.

·        This rule does not prove repository compromise, credential theft, Azure compromise, Entra ID compromise, workload compromise, deployment compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify Azure role assignment actions, application credential changes, service principal credential changes, federated identity credential changes, managed identity changes, Key Vault modification actions, Azure Functions modification actions, App Service changes, AKS cluster activity, Azure Resource Manager deployment activity, deployment activity, or infrastructure-as-code execution.

·        Prioritize actions performed by CI/CD-linked service principals, managed identities, workload identities, deployment identities, infrastructure-as-code identities, production identities, service identities, newly used principals, rare principals, or identities recently associated with suspicious CI/CD activity.

·        Correlate Azure changes with upstream workflow modification, suspicious pipeline execution, runner changes, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, registry activity, Azure identity use, or sensitive resource access.

·        Increase confidence when Azure changes involve owner-like role assignment, contributor-like role assignment, application secret creation, federated credential creation, managed identity assignment, Key Vault policy changes, production Azure Functions updates, App Service updates, AKS cluster or identity changes, Azure Resource Manager deployments, or deployment changes affecting production workloads.

·        Increase confidence when the same principal, service principal, managed identity, source IP, repository, workflow, runner, deployment account, or incident timeline connects upstream CI/CD activity to Azure changes.

·        Increase confidence when changes are rare for the identity, new for the environment, outside approved deployment windows, outside expected source networks, or inconsistent with the mapped repository-to-identity relationship.

·        Reduce severity when activity matches approved deployment workflows, infrastructure deployment, cloud operations, identity rotation, credential rotation, secret rotation, release engineering, vulnerability scanning, security testing, incident response, or documented change-control activity.

·        Do not attribute Azure role assignment or deployment changes to repository workflow compromise without identity, timing, runner, repository, credential, source-network, or incident-response linkage.

·        Do not treat role assignment changes, application credential changes, managed identity changes, Azure Functions changes, App Service changes, AKS activity, Azure Resource Manager deployments, or deployment activity as compromise evidence by itself.

Required Telemetry

·        Microsoft Entra ID sign-in logs.

·        Microsoft Entra ID service principal sign-in logs.

·        Microsoft Entra ID audit logs.

·        Azure Activity logs.

·        Azure Resource Manager events.

·        Azure role assignment events.

·        Azure application credential events.

·        Federated identity credential events where available.

·        Managed identity events where available.

·        Azure Key Vault events.

·        Azure Functions events where available.

·        Azure App Service events where available.

·        Azure Kubernetes Service audit logs where available.

·        Azure deployment logs where available.

·        Defender for Cloud alerts where available.

·        Azure Policy or Resource Graph context where available.

·        Network telemetry where available.

·        CI/CD pipeline logs.

·        CI/CD job logs.

·        Runner metadata.

·        Git audit logs.

·        Identity-provider logs.

·        Repository sensitivity enrichment.

·        Azure tenant ID.

·        Azure subscription ID.

·        Azure resource group.

·        Azure region.

·        Principal ID.

·        Service principal ID.

·        Managed identity ID.

·        Application ID.

·        User principal name where applicable.

·        Source IP.

·        User agent.

·        Operation name.

·        Resource ID.

·        Role definition ID where available.

·        Role assignment ID where available.

·        Request parameters.

·        Response result.

·        Error code where applicable.

·        Deployment environment.

·        Resource action.

·        Timestamp.

·        Approved deployment records.

·        Approved infrastructure deployment records.

·        Approved cloud operation records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build Azure action groups for owner-like role assignment, contributor-like role assignment, application credential creation, service principal credential creation, federated credential creation, managed identity assignment, Key Vault policy change, Key Vault secret modification, Azure Functions code update, App Service update, AKS cluster or identity activity, Azure Resource Manager deployment creation or update, security rule changes, and production deployment action.

·        Build Azure identity groups for CI/CD-linked service principals, managed identities, workload identities, deployment identities, infrastructure-as-code identities, production identities, service identities, privileged identities, rare principals, and newly used principals.

·        Build upstream suspicious context groups using Git audit logs, CI/CD logs, runner metadata, endpoint telemetry, NDR telemetry, identity logs, registry logs, and SIEM context that identifies workflow modification, suspicious pipeline execution, runner changes, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, registry activity, Azure identity use, or sensitive resource access.

·        Build production impact groups for production Azure Functions, App Services, AKS clusters, Resource Manager deployments, role assignments, managed identities, Key Vault entries, deployment resources, and high-value Azure subscriptions.

·        Build expected-use baselines by repository, workflow, runner, principal, service principal, managed identity, source network, tenant, subscription, Azure region, resource group, deployment path, and change window.

·        Validate Azure Activity coverage, Entra ID audit coverage, service principal sign-in coverage, role assignment coverage, application credential event coverage, managed identity coverage, AKS audit coverage, deployment log coverage, source IP preservation, principal ID mapping, service principal mapping, managed identity mapping, and resource ID mapping.

·        Validate joins between Azure telemetry, CI/CD logs, Git audit logs, runner metadata, endpoint telemetry, network telemetry, identity-provider logs, registry logs, deployment logs, and incident-response evidence.

·        Use short correlation windows when Azure role assignment or deployment changes occur during or immediately after suspicious CI/CD execution.

·        Use moderate correlation windows when Azure changes follow workflow modification, runner changes, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, Azure identity use, or resource access.

·        Use longer correlation windows only when Azure identity lineage, CI/CD lineage, runner evidence, cloud evidence, identity evidence, or incident-response evidence supports delayed linkage.

·        Add severity weighting for owner-like role assignment, contributor-like role assignment, application credential changes, federated credential changes, managed identity assignment, Key Vault policy changes, production Azure Functions changes, App Service changes, AKS production changes, Resource Manager deployments, production deployment actions, security rule changes, source-network mismatch, and absence of approved change context.

·        Treat Azure role assignment or deployment changes as confidence amplifiers unless linked to suspicious repository, CI/CD, runner, credential, identity, network, deployment, or incident-response evidence.

·        Build allowlists for approved deployment workflows, infrastructure deployment, cloud operations, identity rotation, credential rotation, secret rotation, release engineering, vulnerability scanning, security testing, incident response, and known automation.

·        Do not enable alert mode until Azure tenant coverage, subscription coverage, Entra ID coverage, Azure Activity coverage, identity mapping, resource mapping, source-network validation, expected-use baselines, field mapping, correlation reliability, false-positive rate, query performance, SOC triage workflow, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.2 / 10

·        The rule is behaviorally anchored to Azure role assignment, identity, workload, infrastructure, and deployment changes following suspicious CI/CD activity rather than static indicators, domains, IP addresses, hashes, package names, image names, repository names, or CVE identifiers.

·        The rule remains useful if an adversary changes workflow content, runner host, service principal, managed identity, Azure region, deployment target, source infrastructure, tool sequence, or timing.

·        The score is supported by the durability of role assignment changes, application credential changes, federated credential changes, managed identity changes, Key Vault modification, Azure Functions changes, App Service changes, AKS activity, Resource Manager deployments, deployment activity, and production-impact context.

·        The score is constrained by legitimate infrastructure deployment, release engineering, cloud operations, identity rotation, credential rotation, shared identities, source IP transformation, incomplete diagnostic logging, and weak repository-to-identity mapping.

·        The rule is durable as Azure downstream-impact coverage but should not be treated as standalone proof of repository workflow compromise, credential theft, Azure compromise, workload compromise, deployment compromise, or actor attribution.

TCR Assessment

Operational TCR

7.3 / 10

Full-Telemetry TCR

8.6 / 10

·        Operational confidence depends on Azure Activity coverage, Entra ID visibility, service principal sign-in logs, CI/CD logs, identity-provider logs, repository-to-identity mapping, source-network preservation, tenant mapping, subscription mapping, resource mapping, and SIEM correlation quality.

·        Operational confidence is reduced where deployment activity is frequent, infrastructure-as-code changes are noisy, source IPs are transformed, diagnostic settings are incomplete, service principal logging is incomplete, or deployment records lack pipeline context.

·        Operational confidence is reduced during normal infrastructure deployment, release engineering, cloud operations, identity rotation, credential rotation, secret rotation, incident response, and security testing.

·        Full-telemetry confidence improves when Azure telemetry is correlated with Git audit logs, CI/CD logs, runner metadata, endpoint telemetry, NDR telemetry, identity logs, registry logs, deployment logs, Defender for Cloud, Azure Policy, and change-control records.

·        Even under full telemetry conditions, this rule should support cloud impact assessment and containment prioritization rather than standalone confirmation of compromise.

Limitations

·        Azure cannot attribute role assignment or deployment changes to repository workflow compromise without reliable Git, CI/CD, runner, credential, identity, source-network, or timing linkage.

·        Legitimate deployment workflows, infrastructure-as-code, cloud operations, and release engineering can closely resemble suspicious Azure control-plane activity.

·        Federated identity, shared identities, NAT, proxying, session reuse, and service principal reuse can obscure lineage.

·        Missing Entra ID logs, missing Azure Activity logs, incomplete AKS audit logging, incomplete deployment logs, or weak source IP preservation can reduce confidence.

·        The rule may miss downstream abuse that uses expected identities, approved deployment paths, normal source networks, or delayed execution outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

Azure role assignment or deployment change following suspicious CI/CD activity query pattern requiring Microsoft Entra ID validation, Azure Activity validation, tenant mapping, subscription mapping, identity mapping, resource mapping, source-network validation, CI/CD lineage validation, timing-window tuning, approved workflow allowlisting, and environment-specific false-positive testing before production deployment.

AzureActivityEvent AS AzureControlPlaneChange

WHERE AzureControlPlaneChange.OperationName IN (
"Microsoft.Authorization/roleAssignments/write",
"Microsoft.Authorization/roleAssignments/delete",
"Microsoft.Graph/applications/credentials/update",
"Microsoft.Graph/servicePrincipals/credentials/update",
"Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write",
"Microsoft.ManagedIdentity/userAssignedIdentities/write",
"Microsoft.KeyVault/vaults/accessPolicies/write",
"Microsoft.KeyVault/vaults/secrets/write",
"Microsoft.Web/sites/functions/write",
"Microsoft.Web/sites/write",
"Microsoft.ContainerService/managedClusters/write",
"Microsoft.Resources/deployments/write",
"Microsoft.Network/networkSecurityGroups/securityRules/write"
)

AND AzureControlPlaneChange.PrincipalId IN REFERENCE_SET (
"CI/CD Linked Service Principals",
"Managed Identities",
"Workload Identities",
"Deployment Identities",
"Infrastructure As Code Identities",
"Production Identities",
"Service Identities",
"Privileged Identities",
"Rare Principals",
"Newly Used Principals"
)

AND (
AzureControlPlaneChange.ResourceContext IN (
"production_function",
"production_app_service",
"production_aks_cluster",
"production_resource_manager_deployment",
"privileged_role_assignment",
"sensitive_key_vault",
"deployment_resource",
"high_value_azure_subscription"
)

OR AzureControlPlaneChange.SourceContext IN (
"outside_expected_runner_network",
"outside_approved_cicd_infrastructure",
"unexpected_azure_region",
"rare_geography",
"rare_asn",
"new_source_for_identity",
"outside_approved_deployment_window",
"repository_to_identity_mismatch"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_CICD_UPSTREAM_CONTEXT_WINDOW (
CICDOrGitEvent AS UpstreamSuspiciousContext
WHERE UpstreamSuspiciousContext.Repository IN SAME_REPOSITORY_OR_IDENTITY_MAPPING(AzureControlPlaneChange.PrincipalId)
AND UpstreamSuspiciousContext.EventPattern IN (
"recent_workflow_change",
"suspicious_pipeline_execution",
"recent_runner_registration",
"recent_runner_tag_change",
"recent_token_creation",
"recent_deploy_key_creation",
"recent_webhook_change",
"credential_access_behavior",
"unusual_runner_egress",
"azure_identity_use",
"sensitive_resource_access"
)
)

AND NOT ChangeContext IN (
"approved_deployment_workflow",
"approved_iac_deployment",
"approved_cloud_operations",
"approved_identity_rotation",
"approved_credential_rotation",
"approved_secret_rotation",
"approved_release_engineering",
"approved_security_testing",
"approved_incident_response"
)

GCP

Detection Viability Assessment

GCP has three rules for this EXP report.

·        GCP is viable for detecting downstream cloud-control-plane and identity-plane activity associated with self-hosted Git platform compromise through repository workflow abuse when Google Cloud Audit Logs, IAM activity, service account activity, workload identity federation logs, Secret Manager logs, Artifact Registry logs, Cloud Storage data access logs, Cloud Build or deployment logs, GKE audit logs, Security Command Center findings, and CI/CD identity mappings are available.

·        GCP is strongest when cloud and identity events can be correlated with Git audit logs, CI/CD pipeline logs, runner telemetry, identity-provider logs, registry activity, deployment activity, source IP context, workload identity federation context, service account context, and repository sensitivity enrichment.

·        GCP can identify suspicious use of CI/CD-linked service accounts, workload identity federation, deployment identities, Artifact Registry identities, Secret Manager access, Cloud Storage access, IAM policy changes, service-account key creation, container image activity, GKE activity, Cloud Run activity, Cloud Functions activity, and deployment activity after suspicious repository workflow or automation credential activity.

·        GCP is not a standalone source for confirming repository workflow compromise because GCP telemetry does not directly prove Git platform compromise, workflow abuse, token theft, runner compromise, package compromise, or actor attribution without upstream repository, CI/CD, endpoint, identity, or incident-response evidence.

·        GCP detections must avoid treating Google Cloud API activity, service account use, workload identity federation use, IAM policy changes, Secret Manager access, Artifact Registry access, Cloud Storage access, Cloud Functions changes, Cloud Run changes, GKE activity, or deployment actions as confirmed compromise by themselves.

·        GCP detections should support downstream exposure scoping, identity investigation, cloud containment prioritization, credential-use review, deployment review, and impact assessment when suspicious repository or CI/CD activity aligns with GCP control-plane activity.

·        GCP rules should not generate high-confidence alerting from a single GCP event unless the activity is correlated with suspicious repository, CI/CD, runner, identity, credential, registry, deployment, or incident-response context.

Rule

Suspicious CI/CD-Linked GCP Service Account or Workload Identity Use After Repository Workflow Activity

Rule Format

GCP identity-plane and cloud-control-plane correlation rule suitable for Google Cloud Audit Logs, IAM activity, service account activity, workload identity federation activity, Security Token Service activity, CI/CD logs, Git audit logs, runner metadata, source IP enrichment, repository sensitivity enrichment, Security Command Center findings where available, and SIEM correlation after organization mapping, folder mapping, project mapping, identity mapping, source-network validation, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious use of CI/CD-linked service accounts, workload identities, workload identity federation, deployment identities, or privileged GCP identities after repository workflow modification, suspicious pipeline execution, runner changes, token creation, deploy-key creation, webhook modification, or credential-access behavior.

·        Identify possible downstream GCP access following repository workflow abuse, CI/CD credential exposure, runner compromise, or automation identity misuse.

·        Prioritize identity use involving deployment identities, production identities, Artifact Registry identities, GKE identities, Cloud Run identities, Cloud Functions deployment identities, infrastructure-as-code identities, Secret Manager identities, Cloud Storage identities, owner-like identities, editor-like identities, and identities tied to sensitive repositories.

·        Support escalation when GCP identity use occurs from unexpected source networks, unusual geographies, unfamiliar runners, rare identities, new user agents, unusual token exchange patterns, unexpected repositories, unexpected projects, or outside approved deployment windows.

·        Preserve separation between suspicious GCP identity use and confirmed compromise by requiring upstream Git, CI/CD, runner, endpoint, identity, network, registry, deployment, or incident-response evidence before classifying cloud activity as compromise.

·        This rule does not prove repository compromise, workflow abuse, credential theft, cloud compromise, GCP project compromise, deployment compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify Google Cloud Audit Logs, IAM activity, service account activity, workload identity federation activity, Security Token Service token exchange, service account impersonation, or cloud-control-plane activity involving CI/CD-linked service accounts, deployment identities, infrastructure-as-code identities, Artifact Registry identities, GKE identities, Cloud Run identities, Cloud Functions identities, Secret Manager identities, Cloud Storage identities, or privileged identities.

·        Prioritize GCP identity use following repository workflow modification, suspicious pipeline execution, new runner registration, runner tag change, token creation, deploy-key creation, webhook modification, protected-branch change, credential-access behavior, unusual runner egress, or registry activity.

·        Prioritize source context that is outside expected runner networks, outside approved CI/CD infrastructure, outside expected GCP regions, outside expected geographies, new for the identity, rare for the service account, inconsistent with the deployment path, or not present in approved source baselines.

·        Prioritize token exchanges, impersonation, or API use with unusual user agents, unfamiliar workload identity pools, unfamiliar providers, unexpected service accounts, broad privilege scope, unusual principal subject values, or activity outside approved deployment windows.

·        Increase confidence when GCP identity use is followed by IAM policy changes, service-account key creation, Secret Manager access, Cloud Storage access, Artifact Registry authentication, image push, Cloud Functions changes, Cloud Run changes, GKE activity, Cloud Build activity, Deployment Manager activity, Terraform activity, or production deployment activity.

·        Increase confidence when the GCP identity maps to sensitive repositories, production deployment, package publication, image publication, signing, infrastructure-as-code, cloud deployment, Kubernetes deployment, or high-value application delivery.

·        Reduce severity when activity matches approved deployment workflows, infrastructure deployment, cloud operations, identity rotation, CI/CD migration, incident response, security testing, or documented change-control activity.

·        Do not classify GCP identity use as repository workflow compromise without upstream repository, CI/CD, runner, credential, identity, network, or incident-response linkage.

·        Do not treat service account use, workload identity federation use, service account impersonation, Artifact Registry authentication, Cloud Storage access, IAM activity, or deployment activity as compromise evidence by itself.

Required Telemetry

·        Google Cloud Audit Logs.

·        Admin Activity logs.

·        Data Access logs where enabled.

·        IAM policy change logs.

·        Service account activity logs.

·        Service account key lifecycle events.

·        Workload identity federation events where available.

·        Security Token Service events where available.

·        Service account impersonation events.

·        Secret Manager access logs.

·        Artifact Registry events.

·        Cloud Storage data access logs where enabled.

·        Cloud Functions logs where available.

·        Cloud Run logs where available.

·        GKE audit logs where available.

·        Cloud Build logs where available.

·        Deployment Manager logs where available.

·        Security Command Center findings where available.

·        VPC Flow Logs where available.

·        Identity-provider logs.

·        CI/CD pipeline logs.

·        CI/CD job logs.

·        Runner metadata.

·        Git audit logs.

·        Repository sensitivity enrichment.

·        GCP organization ID.

·        GCP folder ID where available.

·        GCP project ID.

·        GCP region.

·        Service account email.

·        Principal subject.

·        Principal email.

·        Workload identity pool.

·        Workload identity provider.

·        Source IP.

·        User agent.

·        Resource name.

·        Method name.

·        Permission.

·        Result.

·        Error code where applicable.

·        Timestamp.

·        Approved CI/CD source networks.

·        Approved identity-to-repository mapping.

·        Approved deployment windows.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build GCP identity groups for CI/CD-linked service accounts, workload identities, workload identity federation principals, deployment identities, production identities, Artifact Registry identities, GKE identities, Cloud Run identities, Cloud Functions identities, infrastructure-as-code identities, Secret Manager identities, Cloud Storage identities, owner-like identities, editor-like identities, and privileged identities.

·        Build suspicious source groups for non-runner networks, rare geographies, rare ASNs, new source IPs for the identity, source IPs outside approved CI/CD infrastructure, unexpected GCP regions, and identities outside expected repository-to-identity mappings.

·        Build upstream suspicious context groups using Git audit logs, CI/CD logs, runner metadata, endpoint telemetry, NDR telemetry, identity logs, registry logs, and SIEM context that identifies workflow modification, suspicious pipeline execution, runner registration, runner tag change, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, or registry activity.

·        Build follow-on GCP activity groups for IAM policy changes, service-account key creation, service-account impersonation, Secret Manager access, Cloud Storage access, Artifact Registry authentication, image push, Cloud Functions modification, Cloud Run modification, GKE activity, Cloud Build activity, Deployment Manager activity, Terraform activity, and production deployment activity.

·        Build repository-to-identity and identity-to-environment mappings for sensitive repositories, production deployment, package publication, image publication, signing, infrastructure-as-code, cloud deployment, Kubernetes deployment, and high-value application delivery.

·        Validate Google Cloud Audit Logs coverage, Admin Activity coverage, Data Access logging coverage, project coverage, organization coverage, Secret Manager logging, Artifact Registry logging, Cloud Storage data access logging, source IP preservation, service account mapping, workload identity federation mapping, principal subject mapping, and CI/CD identity mapping.

·        Validate joins between Google Cloud Audit Logs, identity-provider logs, CI/CD logs, Git audit logs, runner metadata, endpoint telemetry, network telemetry, registry logs, deployment logs, and incident-response evidence.

·        Use short correlation windows when GCP identity use occurs during or immediately after suspicious CI/CD execution.

·        Use moderate correlation windows when identity use follows workflow modification, runner changes, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, or registry activity.

·        Use longer correlation windows only when GCP identity lineage, CI/CD lineage, runner evidence, cloud evidence, identity evidence, or incident-response evidence supports delayed linkage.

·        Add severity weighting for privileged identity use, production project access, unusual source network, workload identity federation anomaly, service-account key creation, IAM policy changes, Secret Manager access, Artifact Registry image push, sensitive Cloud Storage access, and production deployment actions.

·        Treat GCP identity use as a confidence amplifier unless linked to suspicious repository, CI/CD, runner, credential, identity, network, deployment, or incident-response evidence.

·        Build allowlists for approved deployment workflows, infrastructure deployment, cloud operations, CI/CD migration, identity rotation, credential rotation, vulnerability scanning, security testing, incident response, and known automation.

·        Do not enable alert mode until GCP organization coverage, project coverage, audit-log coverage, identity mapping, source-network validation, repository-to-identity enrichment, field mapping, correlation reliability, false-positive rate, query performance, SOC triage workflow, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.4 / 10

·        The rule is behaviorally anchored to CI/CD-linked GCP identity use and downstream control-plane activity rather than static indicators, domains, IP addresses, hashes, repository names, package names, image names, or CVE identifiers.

·        The rule remains useful if an adversary changes workflow content, runner host, service account, workload identity provider, workload identity pool, principal subject, source infrastructure, GCP region, user agent, token source, deployment path, or timing.

·        The score is supported by the durability of service account use, workload identity federation use, service account impersonation, unusual source context, identity-to-repository mismatch, IAM policy activity, Secret Manager access, Artifact Registry access, Cloud Storage access, and production deployment activity.

·        The score is constrained by legitimate deployment workflows, workload identity federation complexity, NAT or proxy effects, shared runner networks, incomplete audit logging, incomplete Data Access logs, and weak repository-to-identity mapping.

·        The rule is durable as GCP identity-lineage coverage but should not be treated as standalone proof of repository workflow compromise, credential theft, GCP compromise, deployment compromise, or actor attribution.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

8.8 / 10

·        Operational confidence depends on Google Cloud Audit Logs, Admin Activity logs, Data Access logs, identity-provider logs, CI/CD logs, repository-to-identity mapping, source-network preservation, runner identity mapping, organization mapping, project mapping, and SIEM correlation quality.

·        Operational confidence is reduced where workload identity federation obscures repository lineage, source IPs are transformed, service account activity is incomplete, audit logging is inconsistent, runners share networks, Cloud Storage data access logs are incomplete, or deployment records lack pipeline context.

·        Operational confidence is reduced during normal infrastructure deployment, release engineering, cloud operations, CI/CD migration, identity rotation, credential rotation, incident response, and security testing.

·        Full-telemetry confidence improves when GCP telemetry is correlated with Git audit logs, CI/CD logs, runner metadata, endpoint telemetry, NDR telemetry, identity logs, registry logs, deployment logs, Security Command Center, and change-control records.

·        Even under full telemetry conditions, this rule should support cloud exposure scoping and containment prioritization rather than standalone confirmation of compromise.

Limitations

·        GCP cannot attribute identity use to repository workflow compromise without reliable Git, CI/CD, runner, credential, identity, source-network, or timing linkage.

·        Workload identity federation, shared service accounts, service account impersonation, NAT, proxying, session reuse, and service account reuse can obscure lineage.

·        Legitimate deployment workflows and cloud operations can closely resemble suspicious GCP activity.

·        Missing audit logs, missing Data Access logs, missing project coverage, weak source IP preservation, incomplete identity-provider logs, or weak repository-to-identity mapping can reduce confidence.

·        The rule may miss downstream abuse that uses expected identities, approved source networks, normal deployment paths, or delayed execution outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

GCP CI/CD-linked identity use after repository workflow activity query pattern requiring Google Cloud Audit Logs validation, Admin Activity validation, Data Access validation where needed, organization mapping, project mapping, identity mapping, source-network validation, repository-to-identity enrichment, CI/CD lineage validation, timing-window tuning, approved workflow allowlisting, and environment-specific false-positive testing before production deployment.

GCPAuditEvent AS GCPIdentityUse

WHERE GCPIdentityUse.MethodName IN (
"google.iam.credentials.v1.GenerateAccessToken",
"google.iam.credentials.v1.GenerateIdToken",
"google.iam.credentials.v1.SignJwt",
"google.iam.credentials.v1.SignBlob",
"sts.googleapis.com.TokenExchange",
"iam.serviceAccounts.actAs",
"resourcemanager.projects.get",
"cloudresourcemanager.googleapis.com.SetIamPolicy"
)

AND GCPIdentityUse.PrincipalEmail IN REFERENCE_SET (
"CI/CD Linked Service Accounts",
"Workload Identities",
"Workload Identity Federation Principals",
"Deployment Identities",
"Production Identities",
"Artifact Registry Identities",
"GKE Identities",
"Cloud Run Identities",
"Cloud Functions Identities",
"Infrastructure As Code Identities",
"Secret Manager Identities",
"Cloud Storage Identities",
"Owner Like Identities",
"Editor Like Identities",
"Privileged Identities"
)

AND (
GCPIdentityUse.SourceContext IN (
"outside_expected_runner_network",
"outside_approved_cicd_infrastructure",
"unexpected_gcp_region",
"rare_geography",
"rare_asn",
"new_source_for_identity",
"identity_to_repository_mismatch",
"outside_approved_deployment_window"
)

OR GCPIdentityUse.SessionContext IN (
"unusual_user_agent",
"unexpected_service_account",
"new_workload_identity_provider",
"new_workload_identity_pool",
"unusual_principal_subject",
"broad_privilege_scope"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_CICD_UPSTREAM_CONTEXT_WINDOW (
CICDOrGitEvent AS UpstreamSuspiciousContext
WHERE UpstreamSuspiciousContext.Repository IN SAME_REPOSITORY_OR_IDENTITY_MAPPING(GCPIdentityUse.PrincipalEmail)
AND UpstreamSuspiciousContext.EventPattern IN (
"recent_workflow_change",
"suspicious_pipeline_execution",
"recent_runner_registration",
"recent_runner_tag_change",
"recent_token_creation",
"recent_deploy_key_creation",
"recent_webhook_change",
"credential_access_behavior",
"unusual_runner_egress",
"registry_activity"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_GCP_FOLLOWON_WINDOW (
GCPAuditEvent AS FollowOnGCPActivity
WHERE FollowOnGCPActivity.PrincipalEmail IN SAME_PRINCIPAL_OR_SESSION(GCPIdentityUse.PrincipalEmail)
AND FollowOnGCPActivity.MethodName IN (
"SetIamPolicy",
"CreateServiceAccountKey",
"AccessSecretVersion",
"storage.objects.get",
"storage.objects.create",
"artifactregistry.repositories.uploadArtifacts",
"cloudfunctions.functions.update",
"run.services.update",
"container.clusters.update",
"cloudbuild.builds.create",
"deploymentmanager.deployments.update"
)
)

AND NOT ChangeContext IN (
"approved_deployment_workflow",
"approved_iac_deployment",
"approved_cloud_operations",
"approved_cicd_migration",
"approved_identity_rotation",
"approved_credential_rotation",
"approved_security_testing",
"approved_incident_response"
)

Rule

GCP Secret Manager, Artifact Registry, or Cloud Storage Access Following Suspicious CI/CD Credential Context

Rule Format

GCP downstream resource-access correlation rule suitable for Google Cloud Audit Logs, Data Access logs, Secret Manager logs, Artifact Registry logs, Cloud Storage data access logs, service account activity, workload identity federation logs, CI/CD logs, Git audit logs, runner telemetry, repository sensitivity enrichment, resource sensitivity enrichment, and SIEM correlation after audit-log validation, data-access-log validation, resource-sensitivity mapping, identity mapping, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious GCP Secret Manager, Artifact Registry, or Cloud Storage activity following suspicious CI/CD credential context, repository workflow activity, runner execution, or automation identity activity.

·        Identify possible use of exposed CI/CD credentials or trusted automation identities to access secrets, registry images, packages, artifacts, deployment objects, sensitive source outputs, or GCP resources.

·        Prioritize Secret Manager secret access, Artifact Registry authentication, Artifact Registry image push or pull, Cloud Storage object access, artifact access, deployment package access, and sensitive bucket interaction from CI/CD-linked identities or suspicious source contexts.

·        Support escalation when GCP resource access follows workflow modification, token creation, deploy-key creation, webhook modification, suspicious pipeline execution, runner credential access, unusual runner egress, or GCP identity use.

·        Preserve separation between suspicious GCP resource access and confirmed compromise by requiring upstream repository, CI/CD, runner, identity, network, registry, deployment, or incident-response evidence before classifying cloud activity as compromise.

·        This rule does not prove credential theft, secret theft, registry compromise, package compromise, Cloud Storage compromise, cloud compromise, repository compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify Secret Manager AccessSecretVersion, Secret Manager AddSecretVersion, Artifact Registry authentication, image pull, image push, package upload, package download, Cloud Storage object read, object write, bucket listing, object delete, or deployment artifact access.

·        Prioritize access by CI/CD-linked service accounts, workload identities, workload identity federation principals, deployment identities, image-publishing identities, package-publishing identities, infrastructure-as-code identities, production identities, service identities, or identities recently associated with suspicious CI/CD or repository activity.

·        Prioritize access to sensitive secrets, deployment secrets, registry repositories, production images, signing materials, release artifacts, deployment buckets, infrastructure-state buckets, build artifacts, package artifacts, or high-value application assets.

·        Correlate GCP resource access with upstream workflow modification, suspicious pipeline execution, runner changes, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, registry activity, or GCP identity use.

·        Increase confidence when resource access occurs outside expected repository, workflow, runner, source network, GCP region, project, deployment path, time window, or identity baseline.

·        Increase confidence when Secret Manager access is followed by IAM policy changes, Artifact Registry image push, Cloud Storage object movement, deployment activity, Cloud Functions modification, Cloud Run modification, GKE activity, Cloud Build activity, or Deployment Manager activity.

·        Increase confidence when Artifact Registry image push or Cloud Storage object write occurs after suspicious workflow or runner activity and affects production deployment artifacts, release images, package staging, or infrastructure deployment assets.

·        Reduce severity when activity matches approved deployment workflows, image publication, package publication, infrastructure deployment, cloud operations, secret rotation, incident response, security testing, or documented change-control activity.

·        Do not classify GCP Secret Manager, Artifact Registry, or Cloud Storage access as compromise without upstream repository, CI/CD, runner, identity, network, resource lineage, or incident-response evidence.

·        Do not treat Secret Manager access, Artifact Registry activity, Cloud Storage activity, or deployment artifact access as compromise evidence by itself.

Required Telemetry

·        Google Cloud Audit Logs.

·        Admin Activity logs.

·        Data Access logs where enabled.

·        Secret Manager access logs.

·        Artifact Registry logs.

·        Cloud Storage data access logs where enabled.

·        IAM activity logs.

·        Service account activity logs.

·        Workload identity federation events where available.

·        Service account impersonation events.

·        Cloud Functions logs where available.

·        Cloud Run logs where available.

·        GKE audit logs where available.

·        Cloud Build logs where available.

·        Deployment Manager logs where available.

·        Security Command Center findings where available.

·        VPC Flow Logs where available.

·        CI/CD pipeline logs.

·        CI/CD job logs.

·        Runner telemetry.

·        Git audit logs.

·        Identity-provider logs.

·        Repository sensitivity enrichment.

·        Resource sensitivity enrichment.

·        GCP organization ID.

·        GCP folder ID where available.

·        GCP project ID.

·        GCP region.

·        Service account email.

·        Principal email.

·        Principal subject.

·        Source IP.

·        User agent.

·        Resource name.

·        Secret name where available.

·        Artifact Registry repository.

·        Image digest where available.

·        Image tag where available.

·        Cloud Storage bucket.

·        Cloud Storage object path where available.

·        Method name.

·        Permission.

·        Result.

·        Error code where applicable.

·        Timestamp.

·        Approved resource-access baselines.

·        Approved deployment windows.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build GCP resource groups for sensitive secrets, deployment secrets, CI/CD secrets, registry repositories, production images, signing materials, release artifacts, deployment buckets, infrastructure-state buckets, build artifacts, package artifacts, and high-value application assets.

·        Build GCP identity groups for CI/CD-linked service accounts, workload identities, workload identity federation principals, deployment identities, image-publishing identities, package-publishing identities, infrastructure-as-code identities, production identities, service identities, and privileged identities.

·        Build upstream suspicious context groups using Git audit logs, CI/CD logs, runner metadata, endpoint telemetry, NDR telemetry, identity logs, registry logs, and SIEM context that identifies workflow modification, suspicious pipeline execution, runner registration, runner tag change, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, registry activity, or GCP identity use.

·        Build follow-on GCP behavior groups for IAM policy changes, service-account key creation, service-account impersonation, Artifact Registry image push, Cloud Storage object movement, deployment activity, Cloud Functions modification, Cloud Run modification, GKE activity, Cloud Build activity, Deployment Manager activity, and Security Command Center findings.

·        Build expected-use baselines by repository, workflow, runner, identity, source network, organization, folder, project, GCP region, resource name, Artifact Registry repository, Cloud Storage bucket, Secret Manager secret name, deployment path, and time window.

·        Validate Secret Manager logging, Artifact Registry logging, Cloud Storage Data Access logs, Google Cloud Audit Logs coverage, Admin Activity coverage, Data Access logging coverage, project coverage, organization coverage, source IP preservation, principal email mapping, service account mapping, workload identity federation mapping, resource name mapping, image tag extraction, image digest extraction, and Cloud Storage object visibility.

·        Validate joins between GCP telemetry, CI/CD logs, Git audit logs, runner telemetry, endpoint telemetry, network telemetry, identity-provider logs, registry logs, deployment logs, and incident-response evidence.

·        Use short correlation windows when GCP resource access occurs during or immediately after suspicious CI/CD execution.

·        Use moderate correlation windows when GCP resource access follows workflow modification, runner changes, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, registry activity, or GCP identity use.

·        Use longer correlation windows only when resource lineage, identity lineage, CI/CD lineage, cloud evidence, or incident-response evidence supports delayed linkage.

·        Add severity weighting for Secret Manager access, sensitive secret access, production Artifact Registry repository access, image push, sensitive Cloud Storage object access, object writes to deployment paths, cross-region access, source-network mismatch, privileged identity use, and follow-on IAM or deployment activity.

·        Treat GCP resource access as a confidence amplifier unless linked to suspicious repository, CI/CD, runner, credential, identity, network, deployment, or incident-response evidence.

·        Build allowlists for approved deployment workflows, image publication, package publication, infrastructure deployment, cloud operations, secret rotation, vulnerability scanning, security testing, incident response, and known automation.

·        Do not enable alert mode until audit-log coverage, Data Access log coverage, resource sensitivity mapping, identity mapping, source-network validation, field mapping, correlation reliability, false-positive rate, query performance, SOC triage workflow, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.3 / 10

·        The rule is behaviorally anchored to GCP Secret Manager, Artifact Registry, and Cloud Storage resource access following suspicious CI/CD credential context rather than static indicators, package names, image names, domains, IP addresses, hashes, or CVE identifiers.

·        The rule remains useful if an adversary changes workflow content, runner host, service account, workload identity provider, GCP region, source infrastructure, image tag, Cloud Storage object path, secret name, or timing.

·        The score is supported by the durability of secret access, Artifact Registry authentication, image push, Cloud Storage object access, deployment artifact access, source-network mismatch, resource-sensitivity mismatch, and follow-on deployment or IAM activity.

·        The score is constrained by incomplete Data Access logging, legitimate deployment workflows, secret rotation, image publication, package publication, shared identities, NAT or proxy effects, and weak resource-sensitivity mapping.

·        The rule is durable as GCP resource-access coverage but should not be treated as standalone proof of credential theft, secret theft, registry compromise, Cloud Storage compromise, cloud compromise, or actor attribution.

TCR Assessment

Operational TCR

7.4 / 10

Full-Telemetry TCR

8.7 / 10

·        Operational confidence depends on Google Cloud Audit Logs, Data Access logs, Secret Manager logging, Artifact Registry logging, Cloud Storage data access logs, CI/CD logs, resource sensitivity mapping, principal mapping, source-network preservation, and SIEM correlation quality.

·        Operational confidence is reduced where Cloud Storage data access logs are not enabled, image tags are reused, secrets are accessed frequently by automation, source IPs are transformed, resource sensitivity is not mapped, or deployment logs lack pipeline context.

·        Operational confidence is reduced during normal deployment, image publication, package publication, cloud operations, secret rotation, infrastructure deployment, incident response, and security testing.

·        Full-telemetry confidence improves when GCP telemetry is correlated with Git audit logs, CI/CD logs, runner metadata, endpoint telemetry, NDR telemetry, identity logs, registry logs, deployment logs, Security Command Center, and change-control records.

·        Even under full telemetry conditions, this rule should support cloud resource scoping and containment prioritization rather than standalone confirmation of compromise.

Limitations

·        GCP cannot prove credential theft or secret theft without reliable upstream context, downstream use, exfiltration evidence, unauthorized access, or incident-response validation.

·        Cloud Storage Data Access logs may be disabled or selectively enabled, which can reduce visibility.

·        Artifact Registry and Cloud Storage activity can be normal in deployment and image publication workflows.

·        Shared service accounts, reused image tags, NAT, proxying, and CI/CD federation can obscure lineage.

·        The rule may miss abuse that uses expected identities, approved resource paths, normal source networks, or delayed execution outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

GCP Secret Manager, Artifact Registry, or Cloud Storage access following suspicious CI/CD credential context query pattern requiring Google Cloud Audit Logs validation, Admin Activity validation, Data Access validation, resource sensitivity mapping, identity mapping, source-network validation, CI/CD lineage validation, timing-window tuning, approved workflow allowlisting, and environment-specific false-positive testing before production deployment.

GCPAuditEvent AS GCPResourceAccess

WHERE GCPResourceAccess.MethodName IN (
"secretmanager.versions.access",
"secretmanager.versions.add",
"artifactregistry.repositories.downloadArtifacts",
"artifactregistry.repositories.uploadArtifacts",
"storage.objects.get",
"storage.objects.create",
"storage.objects.list",
"storage.objects.delete",
"cloudbuild.builds.create",
"deploymentmanager.deployments.update"
)

AND GCPResourceAccess.ResourceName IN REFERENCE_SET (
"Sensitive Secrets",
"Deployment Secrets",
"CI/CD Secrets",
"Production Artifact Registry Repositories",
"Signing Materials",
"Release Artifacts",
"Deployment Buckets",
"Infrastructure State Buckets",
"Build Artifacts",
"Package Artifacts",
"High Value Application Assets"
)

AND GCPResourceAccess.PrincipalEmail IN REFERENCE_SET (
"CI/CD Linked Service Accounts",
"Workload Identities",
"Workload Identity Federation Principals",
"Deployment Identities",
"Image Publishing Identities",
"Package Publishing Identities",
"Infrastructure As Code Identities",
"Production Identities",
"Service Identities",
"Privileged Identities"
)

AND (
GCPResourceAccess.SourceContext IN (
"outside_expected_runner_network",
"outside_approved_cicd_infrastructure",
"unexpected_gcp_region",
"rare_geography",
"rare_asn",
"new_source_for_identity",
"outside_approved_deployment_window"
)

OR GCPResourceAccess.ResourceContext IN (
"sensitive_secret",
"production_image_repository",
"signing_material",
"deployment_artifact",
"infrastructure_state",
"sensitive_storage_object",
"unexpected_resource_for_identity"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_CICD_UPSTREAM_CONTEXT_WINDOW (
CICDOrGitEvent AS UpstreamSuspiciousContext
WHERE UpstreamSuspiciousContext.Repository IN SAME_REPOSITORY_OR_IDENTITY_MAPPING(GCPResourceAccess.PrincipalEmail)
AND UpstreamSuspiciousContext.EventPattern IN (
"recent_workflow_change",
"suspicious_pipeline_execution",
"recent_runner_registration",
"recent_runner_tag_change",
"recent_token_creation",
"recent_deploy_key_creation",
"recent_webhook_change",
"credential_access_behavior",
"unusual_runner_egress",
"gcp_identity_use"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_GCP_FOLLOWON_WINDOW (
GCPAuditEvent AS FollowOnGCPActivity
WHERE FollowOnGCPActivity.PrincipalEmail IN SAME_PRINCIPAL_OR_SESSION(GCPResourceAccess.PrincipalEmail)
AND FollowOnGCPActivity.MethodName IN (
"SetIamPolicy",
"CreateServiceAccountKey",
"artifactregistry.repositories.uploadArtifacts",
"storage.objects.create",
"cloudfunctions.functions.update",
"run.services.update",
"container.clusters.update",
"cloudbuild.builds.create",
"deploymentmanager.deployments.update"
)
)

AND NOT ChangeContext IN (
"approved_deployment_workflow",
"approved_image_publication",
"approved_package_publication",
"approved_iac_deployment",
"approved_cloud_operations",
"approved_secret_rotation",
"approved_security_testing",
"approved_incident_response"
)

Rule

GCP IAM or Deployment Change Following Suspicious CI/CD Activity

Rule Format

GCP IAM and deployment-control correlation rule suitable for Google Cloud Audit Logs, IAM events, service account events, workload identity federation events, Cloud Functions events, Cloud Run events, GKE events, Cloud Build events, Deployment Manager events, CI/CD logs, Git audit logs, runner telemetry, identity-provider logs, repository sensitivity enrichment, and SIEM correlation after organization validation, project validation, identity mapping, resource mapping, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious GCP IAM, identity, infrastructure, workload, or deployment changes following suspicious repository workflow activity, CI/CD execution, credential exposure, automation credential change, or GCP identity use.

·        Identify possible downstream cloud impact after repository workflow abuse, CI/CD credential misuse, runner compromise, or automation identity misuse.

·        Prioritize IAM policy changes, service-account key creation, service-account impersonation, workload identity federation changes, Secret Manager changes, Cloud Functions changes, Cloud Run changes, GKE cluster or role-binding activity, Cloud Build activity, Deployment Manager activity, and production deployment activity.

·        Support escalation when GCP changes occur outside expected repository, workflow, runner, source network, GCP region, project, environment, deployment path, or approved change window.

·        Preserve separation between suspicious GCP control-plane changes and confirmed compromise by requiring upstream repository, CI/CD, runner, identity, credential, network, deployment, or incident-response evidence before classifying cloud activity as compromise.

·        This rule does not prove repository compromise, credential theft, GCP compromise, IAM compromise, workload compromise, deployment compromise, or actor attribution without supporting telemetry.

Detection Logic

·        Identify GCP IAM policy changes, service-account key lifecycle actions, service-account impersonation changes, workload identity pool or provider changes, Secret Manager modification actions, Cloud Functions modification actions, Cloud Run service changes, GKE cluster activity, Cloud Build activity, Deployment Manager activity, deployment activity, or infrastructure-as-code execution.

·        Prioritize actions performed by CI/CD-linked service accounts, workload identities, workload identity federation principals, deployment identities, infrastructure-as-code identities, production identities, service identities, newly used principals, rare principals, or identities recently associated with suspicious CI/CD activity.

·        Correlate GCP changes with upstream workflow modification, suspicious pipeline execution, runner changes, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, registry activity, GCP identity use, or sensitive resource access.

·        Increase confidence when GCP changes involve owner-like IAM policy changes, editor-like IAM policy changes, service-account key creation, workload identity federation changes, Secret Manager modification, production Cloud Functions updates, Cloud Run updates, GKE cluster or identity changes, Cloud Build activity, Deployment Manager updates, or deployment changes affecting production workloads.

·        Increase confidence when the same principal, service account, workload identity, source IP, repository, workflow, runner, deployment account, or incident timeline connects upstream CI/CD activity to GCP changes.

·        Increase confidence when changes are rare for the identity, new for the environment, outside approved deployment windows, outside expected source networks, or inconsistent with the mapped repository-to-identity relationship.

·        Reduce severity when activity matches approved deployment workflows, infrastructure deployment, cloud operations, identity rotation, credential rotation, secret rotation, release engineering, vulnerability scanning, security testing, incident response, or documented change-control activity.

·        Do not attribute GCP IAM or deployment changes to repository workflow compromise without identity, timing, runner, repository, credential, source-network, or incident-response linkage.

·        Do not treat IAM policy changes, service-account key creation, workload identity federation changes, Cloud Functions changes, Cloud Run changes, GKE activity, Cloud Build activity, Deployment Manager updates, or deployment activity as compromise evidence by itself.

Required Telemetry

·        Google Cloud Audit Logs.

·        Admin Activity logs.

·        Data Access logs where enabled.

·        IAM policy change logs.

·        Service account activity logs.

·        Service account key lifecycle logs.

·        Workload identity federation events where available.

·        Service account impersonation events.

·        Secret Manager events.

·        Cloud Functions logs where available.

·        Cloud Run logs where available.

·        GKE audit logs where available.

·        Cloud Build logs.

·        Deployment Manager logs where available.

·        Security Command Center findings where available.

·        GCP Asset Inventory context where available.

·        VPC Flow Logs where available.

·        CI/CD pipeline logs.

·        CI/CD job logs.

·        Runner metadata.

·        Git audit logs.

·        Identity-provider logs.

·        Repository sensitivity enrichment.

·        GCP organization ID.

·        GCP folder ID where available.

·        GCP project ID.

·        GCP region.

·        Principal email.

·        Principal subject.

·        Service account email.

·        Source IP.

·        User agent.

·        Method name.

·        Resource name.

·        Permission.

·        Request parameters.

·        Response result.

·        Error code where applicable.

·        Deployment environment.

·        Resource action.

·        Timestamp.

·        Approved deployment records.

·        Approved infrastructure deployment records.

·        Approved cloud operation records.

·        Change-control records.

·        Incident-response records.

Engineering Implementation Instructions

·        Build GCP action groups for owner-like IAM policy changes, editor-like IAM policy changes, service-account key creation, service-account impersonation changes, workload identity pool changes, workload identity provider changes, Secret Manager modification, Cloud Functions update, Cloud Run update, GKE cluster or identity activity, Cloud Build creation, Deployment Manager creation or update, firewall rule changes, and production deployment action.

·        Build GCP identity groups for CI/CD-linked service accounts, workload identities, workload identity federation principals, deployment identities, infrastructure-as-code identities, production identities, service identities, privileged identities, rare principals, and newly used principals.

·        Build upstream suspicious context groups using Git audit logs, CI/CD logs, runner metadata, endpoint telemetry, NDR telemetry, identity logs, registry logs, and SIEM context that identifies workflow modification, suspicious pipeline execution, runner changes, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, registry activity, GCP identity use, or sensitive resource access.

·        Build production impact groups for production Cloud Functions, Cloud Run services, GKE clusters, Deployment Manager deployments, IAM policies, service accounts, Secret Manager entries, deployment resources, and high-value GCP projects.

·        Build expected-use baselines by repository, workflow, runner, principal, service account, workload identity, source network, organization, folder, project, GCP region, deployment path, and change window.

·        Validate Google Cloud Audit Logs coverage, Admin Activity coverage, Data Access logging coverage, IAM event coverage, service account event coverage, workload identity federation coverage, GKE audit coverage, Cloud Build coverage, deployment log coverage, source IP preservation, principal email mapping, service account mapping, workload identity mapping, and resource name mapping.

·        Validate joins between GCP telemetry, CI/CD logs, Git audit logs, runner metadata, endpoint telemetry, network telemetry, identity-provider logs, registry logs, deployment logs, and incident-response evidence.

·        Use short correlation windows when GCP IAM or deployment changes occur during or immediately after suspicious CI/CD execution.

·        Use moderate correlation windows when GCP changes follow workflow modification, runner changes, token creation, deploy-key creation, webhook modification, credential access, unusual runner egress, GCP identity use, or resource access.

·        Use longer correlation windows only when GCP identity lineage, CI/CD lineage, runner evidence, cloud evidence, identity evidence, or incident-response evidence supports delayed linkage.

·        Add severity weighting for owner-like IAM policy changes, editor-like IAM policy changes, service-account key creation, workload identity federation changes, service-account impersonation, Secret Manager modification, production Cloud Functions changes, Cloud Run changes, GKE production changes, Deployment Manager changes, production deployment actions, firewall rule changes, source-network mismatch, and absence of approved change context.

·        Treat GCP IAM or deployment changes as confidence amplifiers unless linked to suspicious repository, CI/CD, runner, credential, identity, network, deployment, or incident-response evidence.

·        Build allowlists for approved deployment workflows, infrastructure deployment, cloud operations, identity rotation, credential rotation, secret rotation, release engineering, vulnerability scanning, security testing, incident response, and known automation.

·        Do not enable alert mode until GCP organization coverage, project coverage, audit-log coverage, identity mapping, resource mapping, source-network validation, expected-use baselines, field mapping, correlation reliability, false-positive rate, query performance, SOC triage workflow, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

DRI

8.2 / 10

·        The rule is behaviorally anchored to GCP IAM, identity, workload, infrastructure, and deployment changes following suspicious CI/CD activity rather than static indicators, domains, IP addresses, hashes, package names, image names, repository names, or CVE identifiers.

·        The rule remains useful if an adversary changes workflow content, runner host, service account, workload identity provider, GCP region, deployment target, source infrastructure, tool sequence, or timing.

·        The score is supported by the durability of IAM policy changes, service-account key creation, workload identity federation changes, Secret Manager modification, Cloud Functions changes, Cloud Run changes, GKE activity, Cloud Build activity, Deployment Manager activity, deployment activity, and production-impact context.

·        The score is constrained by legitimate infrastructure deployment, release engineering, cloud operations, identity rotation, credential rotation, shared service accounts, source IP transformation, incomplete audit logging, and weak repository-to-identity mapping.

·        The rule is durable as GCP downstream-impact coverage but should not be treated as standalone proof of repository workflow compromise, credential theft, GCP compromise, workload compromise, deployment compromise, or actor attribution.

TCR Assessment

Operational TCR

7.3 / 10

Full-Telemetry TCR

8.6 / 10

·        Operational confidence depends on Google Cloud Audit Logs, Admin Activity logs, CI/CD logs, identity-provider logs, repository-to-identity mapping, source-network preservation, organization mapping, project mapping, resource mapping, and SIEM correlation quality.

·        Operational confidence is reduced where deployment activity is frequent, infrastructure-as-code changes are noisy, source IPs are transformed, audit logging is incomplete, service account logging is incomplete, or deployment records lack pipeline context.

·        Operational confidence is reduced during normal infrastructure deployment, release engineering, cloud operations, identity rotation, credential rotation, secret rotation, incident response, and security testing.

·        Full-telemetry confidence improves when GCP telemetry is correlated with Git audit logs, CI/CD logs, runner metadata, endpoint telemetry, NDR telemetry, identity logs, registry logs, deployment logs, Security Command Center, Asset Inventory, and change-control records.

·        Even under full telemetry conditions, this rule should support cloud impact assessment and containment prioritization rather than standalone confirmation of compromise.

Limitations

·        GCP cannot attribute IAM or deployment changes to repository workflow compromise without reliable Git, CI/CD, runner, credential, identity, source-network, or timing linkage.

·        Legitimate deployment workflows, infrastructure-as-code, cloud operations, and release engineering can closely resemble suspicious GCP control-plane activity.

·        Workload identity federation, shared service accounts, NAT, proxying, session reuse, service account impersonation, and service account reuse can obscure lineage.

·        Missing audit logs, incomplete GKE audit logging, incomplete deployment logs, or weak source IP preservation can reduce confidence.

·        The rule may miss downstream abuse that uses expected identities, approved deployment paths, normal source networks, or delayed execution outside the correlation window.

·        The rule should not be used for actor attribution without incident-specific intelligence, validated behavioral correlation, or confirmed victim-environment evidence.

Detection Query Pattern

GCP IAM or deployment change following suspicious CI/CD activity query pattern requiring Google Cloud Audit Logs validation, Admin Activity validation, organization mapping, project mapping, identity mapping, resource mapping, source-network validation, CI/CD lineage validation, timing-window tuning, approved workflow allowlisting, and environment-specific false-positive testing before production deployment.

GCPAuditEvent AS GCPControlPlaneChange

WHERE GCPControlPlaneChange.MethodName IN (
"SetIamPolicy",
"CreateServiceAccountKey",
"DeleteServiceAccountKey",
"iam.workloadIdentityPools.create",
"iam.workloadIdentityPools.update",
"iam.workloadIdentityPoolProviders.create",
"iam.workloadIdentityPoolProviders.update",
"secretmanager.secrets.update",
"secretmanager.versions.add",
"cloudfunctions.functions.update",
"run.services.update",
"container.clusters.update",
"cloudbuild.builds.create",
"deploymentmanager.deployments.update",
"compute.firewalls.insert",
"compute.firewalls.update"
)

AND GCPControlPlaneChange.PrincipalEmail IN REFERENCE_SET (
"CI/CD Linked Service Accounts",
"Workload Identities",
"Workload Identity Federation Principals",
"Deployment Identities",
"Infrastructure As Code Identities",
"Production Identities",
"Service Identities",
"Privileged Identities",
"Rare Principals",
"Newly Used Principals"
)

AND (
GCPControlPlaneChange.ResourceContext IN (
"production_cloud_function",
"production_cloud_run_service",
"production_gke_cluster",
"production_deployment_manager_deployment",
"privileged_iam_policy",
"sensitive_secret",
"deployment_resource",
"high_value_gcp_project"
)

OR GCPControlPlaneChange.SourceContext IN (
"outside_expected_runner_network",
"outside_approved_cicd_infrastructure",
"unexpected_gcp_region",
"rare_geography",
"rare_asn",
"new_source_for_identity",
"outside_approved_deployment_window",
"repository_to_identity_mismatch"
)
)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_CICD_UPSTREAM_CONTEXT_WINDOW (
CICDOrGitEvent AS UpstreamSuspiciousContext
WHERE UpstreamSuspiciousContext.Repository IN SAME_REPOSITORY_OR_IDENTITY_MAPPING(GCPControlPlaneChange.PrincipalEmail)
AND UpstreamSuspiciousContext.EventPattern IN (
"recent_workflow_change",
"suspicious_pipeline_execution",
"recent_runner_registration",
"recent_runner_tag_change",
"recent_token_creation",
"recent_deploy_key_creation",
"recent_webhook_change",
"credential_access_behavior",
"unusual_runner_egress",
"gcp_identity_use",
"sensitive_resource_access"
)
)

AND NOT ChangeContext IN (
"approved_deployment_workflow",
"approved_iac_deployment",
"approved_cloud_operations",
"approved_identity_rotation",
"approved_credential_rotation",
"approved_secret_rotation",
"approved_release_engineering",
"approved_security_testing",
"approved_incident_response"
)

S26 Threat-to-Rule Traceability Matrix

Threat-to-Rule Traceability Matrix

This section maps the report’s behavior-led detection model to the S25 rule coverage. The purpose is to show how repository workflow abuse, trusted automation misuse, runner execution, automation credential changes, downstream registry activity, cloud-control-plane exposure, Kubernetes activity, and deployment activity are covered across the validated detection systems.

Detection Coverage Summary

·        The S25 rule set provides strong behavior-led coverage for self-hosted Git platform compromise through repository workflow abuse.

·        Coverage is strongest where repository audit logs, CI/CD logs, runner telemetry, endpoint telemetry, identity logs, registry logs, package logs, artifact logs, cloud logs, Kubernetes logs, and deployment logs are correlated.

·        The detection model does not depend on a single CVE, IOC, malware hash, domain, IP address, package name, image name, repository name, or static artifact.

·        The rules are designed to identify the operational chain from repository-control change to trusted automation execution and downstream identity, registry, package, artifact, cloud, Kubernetes, or deployment activity.

·        No rule should be treated as standalone proof of compromise without supporting telemetry, validated correlation, or incident-response evidence.

Primary Threat Behavior

Repository workflow modification used to introduce unauthorized CI/CD execution.

Mapped Rule Coverage

·        NDR / Network Behavioral Analytics detects network-facing effects of suspicious runner behavior, unusual outbound communication, registry access, artifact movement, internal service access, cloud endpoint communication, and downstream Kubernetes or deployment activity.

·        SentinelOne detects suspicious runner-host process execution, credential-access preparation, artifact staging, archive creation, scripting activity, cloud CLI use, Kubernetes CLI use, registry tooling, and suspicious child-process behavior.

·        Splunk detects workflow modification followed by CI/CD execution, runner activity, registry access, outbound communication, and downstream control-plane activity through multi-source correlation.

·        Elastic detects workflow modification followed by suspicious runner-host process activity using Git, CI/CD, endpoint, network, identity, registry, cloud, Kubernetes, and deployment telemetry.

·        QRadar detects workflow change followed by CI/CD runner execution and suspicious host or network activity using custom properties, reference sets, building blocks, and offense logic.

·        SIGMA provides portable workflow-to-runner correlation patterns for translation into local SIEM platforms.

·        AWS, Azure, and GCP provide downstream cloud-control-plane coverage where repository or CI/CD activity can be linked to cloud identity use, resource access, or deployment activity.

·        YARA has no primary coverage because the governing detection model is behavior-led rather than artifact-led.

Coverage Assessment

This behavior is directly covered by the deployed S25 detection model when workflow-change telemetry, CI/CD execution logs, runner identity, endpoint telemetry, and repository sensitivity enrichment are available.

Primary Threat Behavior

Suspicious CI/CD runner execution after repository workflow or CI/CD configuration change.

Mapped Rule Coverage

·        SentinelOne provides direct endpoint coverage for runner-host command execution, process lineage, script execution, credential probing, archive creation, package-manager activity, transfer utilities, container tooling, cloud CLI use, Kubernetes CLI use, and suspicious child-process behavior.

·        Splunk, Elastic, and QRadar provide multi-source correlation coverage tying workflow changes to pipeline execution, runner assignment, suspicious process behavior, outbound communication, registry activity, artifact movement, cloud activity, Kubernetes activity, and downstream deployment context.

·        NDR / Network Behavioral Analytics provides supporting coverage for runner-originated outbound communication, rare destinations, unusual internal service access, registry interaction, artifact movement, cloud endpoint communication, and suspicious egress patterns.

·        SIGMA provides portable runner-execution patterns that can be translated into Splunk, Elastic, QRadar, Sentinel, Chronicle, or other SIEM platforms.

·        AWS, Azure, and GCP do not directly observe runner-host process behavior, but they provide downstream correlation when suspicious runner activity is followed by cloud identity use, resource access, or deployment activity.

·        YARA remains conditional only if a stable runner-stage script, payload, binary, or reusable file-content artifact is recovered.

Coverage Assessment

This behavior is directly covered by SentinelOne, Splunk, Elastic, QRadar, and SIGMA, and is supported by NDR / Network Behavioral Analytics and cloud-platform correlation where downstream effects are visible.

Primary Threat Behavior

Automation credential, deploy-key, token, OAuth application, service-account, workload-identity, runner-token, or webhook change followed by downstream activity.

Mapped Rule Coverage

·        Splunk detects automation token or webhook changes followed by suspicious repository, registry, artifact, package, deployment, cloud, or Kubernetes activity.

·        Elastic detects automation token or webhook changes followed by suspicious repository, registry, artifact, package, cloud, Kubernetes, or deployment activity through event sequencing and identity lineage.

·        QRadar detects automation credential or webhook changes followed by registry, artifact, or deployment activity using custom properties, reference sets, and offense logic.

·        SIGMA provides portable automation credential and webhook change patterns for local SIEM translation.

·        AWS detects downstream role assumption, Secrets Manager access, ECR activity, S3 access, IAM changes, workload changes, and deployment changes when tied to suspicious CI/CD credential context.

·        Azure detects downstream service principal use, managed identity use, federated credential use, Key Vault access, ACR activity, Storage access, role assignment changes, workload changes, and deployment changes when tied to suspicious CI/CD credential context.

·        GCP detects downstream service account use, workload identity federation, Secret Manager access, Artifact Registry activity, Cloud Storage access, IAM changes, workload changes, and deployment changes when tied to suspicious CI/CD credential context.

·        SentinelOne may support the chain where credential access or token handling produces endpoint-observable behavior on a runner or build host.

·        NDR / Network Behavioral Analytics may support the chain where credential misuse produces unusual external communication, registry access, artifact movement, cloud-control-plane communication, or Kubernetes API communication.

·        YARA has no primary coverage unless a stable credential-theft tool, script, loader, payload, or reusable artifact is recovered.

Coverage Assessment

This behavior is directly covered by Splunk, Elastic, QRadar, SIGMA, AWS, Azure, and GCP when credential lifecycle, identity, repository, registry, cloud, Kubernetes, and deployment telemetry are available.

Primary Threat Behavior

Repository or CI/CD abuse followed by registry, package, artifact, image, or deployment activity.

Mapped Rule Coverage

·        Splunk, Elastic, and QRadar correlate repository workflow changes, automation credential changes, or suspicious CI/CD execution with registry authentication, package access, artifact access, image pull, image push, release modification, or deployment execution.

·        NDR / Network Behavioral Analytics provides supporting coverage for runner-to-registry communication, artifact movement, package-service access, unexpected external destinations, and unusual internal service communication.

·        SentinelOne provides endpoint support where registry clients, package managers, container tooling, archive utilities, or deployment tools execute on runners or build hosts.

·        SIGMA provides portable registry, artifact, and deployment-correlation patterns that require local SIEM translation.

·        AWS detects ECR activity, S3 artifact access, Secrets Manager access, CodeDeploy or deployment activity, and related IAM or workload changes.

·        Azure detects ACR activity, Storage artifact access, Key Vault access, Azure Resource Manager deployment activity, App Service activity, Functions activity, and AKS activity.

·        GCP detects Artifact Registry activity, Cloud Storage artifact access, Secret Manager access, Cloud Build activity, Cloud Run activity, Cloud Functions activity, GKE activity, and Deployment Manager activity.

·        YARA remains non-primary because registry, package, artifact, and deployment activity are behavioral and telemetry-driven rather than file-signature-driven.

Coverage Assessment

This behavior is directly covered by the SIEM and cloud rule sets when registry, package, artifact, image, cloud, and deployment telemetry are available and mapped to repository or CI/CD lineage.

Primary Threat Behavior

CI/CD-linked identity use followed by cloud, Kubernetes, or deployment activity.

Mapped Rule Coverage

·        Splunk detects CI/CD-linked identity use followed by cloud, Kubernetes, or deployment activity through identity, CI/CD, registry, cloud, Kubernetes, and deployment telemetry.

·        Elastic detects CI/CD-linked identity use followed by cloud, Kubernetes, or deployment activity through multi-source event sequencing.

·        QRadar detects CI/CD-linked identity use followed by cloud, Kubernetes, or deployment activity through custom properties, reference sets, building blocks, and offense logic.

·        SIGMA provides portable CI/CD-to-control-plane detection patterns for local SIEM translation.

·        AWS detects suspicious CI/CD-linked role assumption, Secrets Manager access, ECR access, S3 access, IAM changes, workload changes, and deployment changes.

·        Azure detects suspicious CI/CD-linked service principal use, managed identity use, federated credential use, Key Vault access, ACR access, Storage access, role assignment changes, workload changes, and deployment changes.

·        GCP detects suspicious CI/CD-linked service account use, workload identity federation, Secret Manager access, Artifact Registry access, Cloud Storage access, IAM changes, workload changes, and deployment changes.

·        NDR / Network Behavioral Analytics provides supporting network visibility where runner-to-cloud or runner-to-Kubernetes communication is observable.

·        SentinelOne provides supporting endpoint visibility where cloud CLIs, Kubernetes CLIs, container tooling, deployment tools, or credential-access utilities execute on the runner or build host.

·        YARA has no primary coverage for identity-to-cloud-control-plane behavior.

Coverage Assessment

This behavior is directly covered by Splunk, Elastic, QRadar, SIGMA, AWS, Azure, and GCP, and is supported by NDR / Network Behavioral Analytics and SentinelOne where runner-side or network-side evidence is present.

Primary Threat Behavior

Suspicious downstream IAM, role, service-account, workload-identity, secrets, storage, registry, Kubernetes, workload, or deployment changes after repository or CI/CD activity.

Mapped Rule Coverage

·        AWS detects IAM changes, role trust changes, access-key creation, Secrets Manager access, ECR activity, S3 access, Lambda changes, ECS changes, EKS activity, CloudFormation changes, and deployment activity.

·        Azure detects role assignment changes, application credential changes, federated credential changes, managed identity changes, Key Vault access, ACR activity, Storage access, Azure Functions changes, App Service changes, AKS activity, and Azure Resource Manager deployments.

·        GCP detects IAM policy changes, service-account key creation, workload identity federation changes, Secret Manager access, Artifact Registry activity, Cloud Storage access, Cloud Functions changes, Cloud Run changes, GKE activity, Cloud Build activity, and Deployment Manager activity.

·        Splunk, Elastic, and QRadar correlate the downstream cloud activity back to suspicious repository, CI/CD, runner, identity, credential, registry, or deployment context.

·        SIGMA provides portable cloud-control-plane correlation patterns that require local translation.

·        NDR / Network Behavioral Analytics and SentinelOne provide supporting evidence where cloud activity is preceded by suspicious runner network traffic or endpoint execution.

·        YARA has no primary coverage for cloud-control-plane behavior.

Coverage Assessment

This behavior is directly covered by AWS, Azure, GCP, Splunk, Elastic, QRadar, and SIGMA when cloud logs and upstream CI/CD lineage are available.

Primary Threat Behavior

Optional artifact recovery during incident response.

Mapped Rule Coverage

·        YARA can support conditional investigative hunting if responders recover a stable artifact, such as a malicious workflow payload, runner-stage script, credential-access tool, loader, dropper, webshell, remote-access tool, suspicious binary, memory artifact, encoded payload, configuration artifact, or reusable file-content pattern.

·        YARA should not be used as a primary detection mechanism because the report’s governing detection model does not depend on a stable file artifact.

·        YARA should not be used to infer successful repository compromise, workflow abuse, credential theft, package compromise, cloud compromise, Kubernetes compromise, deployment compromise, or actor attribution without supporting endpoint, identity, network, repository, CI/CD, registry, package, cloud, Kubernetes, deployment, file, memory, or incident-response evidence.

Coverage Assessment

This behavior has conditional investigative coverage only. No primary YARA rule is included because stable artifact evidence is not required for the report’s primary detection model.

Coverage Gaps and Conditional Dependencies

·        YARA has zero primary rules because no stable file, memory, payload, script, binary, webshell, loader, or reusable artifact is required for the governing detection model.

·        Cloud detections require validated linkage to upstream repository, CI/CD, runner, identity, credential, registry, deployment, or incident-response evidence.

·        SIEM correlation depends on reliable field mapping, timestamp normalization, repository identity mapping, runner identity mapping, credential lineage, service-account mapping, workload-identity mapping, source-network preservation, and event latency handling.

·        Endpoint detection depends on runner and build-host telemetry quality, process lineage, command-line visibility, file telemetry, and agent coverage.

·        Network detection depends on visibility into runner egress, registry access, artifact movement, DNS, proxy, firewall, NDR, cloud endpoint communication, Kubernetes API communication, and internal service communication.

·        Registry, package, artifact, and deployment coverage depends on diagnostic logging, data-event logging, package-service logs, registry logs, image metadata, artifact metadata, deployment platform logs, and repository-to-deployment lineage.

·        High-confidence alerting should not be enabled until local mapping, exception handling, false-positive testing, query performance, SOC triage workflow, and incident-response evidence requirements are validated.

Traceability Conclusion

The S25 rule set provides strong behavior-led coverage for the report’s intended detection model across NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA, AWS, Azure, and GCP. YARA is correctly excluded as a primary rule system because the report’s durable detection surface is telemetry-led and behavior-led rather than artifact-led.

The strongest coverage comes from correlating repository workflow changes, CI/CD execution, runner activity, automation credential changes, registry or package activity, endpoint behavior, network egress, cloud identity use, Kubernetes activity, and deployment-control-plane activity. The model remains reusable across GitLab, Gitea, Forgejo, Bitbucket Server, self-hosted GitHub Enterprise Server, and similar self-hosted Git platforms when telemetry is locally mapped and validated.

S27 Behavior & Log Artifacts

Behavior & Log Artifacts

This section identifies the primary behavior and log artifacts expected during self-hosted Git platform compromise through repository workflow abuse. These artifacts support SOC triage, detection validation, incident scoping, and escalation decisions.

Repository Control Artifacts

·        Workflow file creation, modification, deletion, or permission change.

·        CI/CD configuration modification.

·        Build-script modification.

·        Deployment-script modification.

·        Release-script modification.

·        Package-publishing workflow change.

·        Container-build workflow change.

·        Infrastructure-as-code workflow change.

·        Protected-branch setting change.

·        Approval-rule change.

·        Merge or pull request merged outside normal review patterns.

·        Commit activity from newly privileged, inactive, unfamiliar, external, service-account, or unusual accounts.

·        Repository change activity from unfamiliar source networks, rare geographies, unusual automation identities, or unexpected source infrastructure.

·        Workflow or CI/CD configuration changes affecting sensitive repositories, production deployment paths, package-publication paths, image-publication paths, signing paths, infrastructure-as-code paths, cloud deployment paths, or Kubernetes deployment paths.

CI/CD and Runner Artifacts

·        Pipeline execution shortly after workflow or CI/CD configuration modification.

·        Job execution from sensitive repositories or protected branches.

·        Runner assignment to unexpected repository, project, group, branch, workflow, or job.

·        Runner tag change.

·        New runner registration.

·        Runner execution outside expected source network, time window, branch, project, or deployment path.

·        Runner process execution involving shell interpreters, scripting engines, package managers, archive utilities, network transfer utilities, registry clients, container tooling, cloud CLIs, Kubernetes CLIs, credential helpers, or secret-management tooling.

·        Command-line activity involving environment-variable inspection, protected-variable exposure, credential-location probing, secret-file access, recursive file collection, repository bundling, archive creation, remote retrieval, direct IP access, encoded execution, suspicious command chaining, artifact staging, cache access, registry authentication, or external transfer.

·        CI/CD job behavior inconsistent with the expected workflow purpose or repository role.

·        Build-host or runner-host activity that appears unrelated to the declared pipeline stage.

Credential and Automation Artifacts

·        Deploy-key creation, modification, or permission expansion.

·        Project access token creation.

·        Group access token creation.

·        Personal access token creation where available.

·        Token scope expansion.

·        Token permission change.

·        OAuth application creation.

·        Webhook creation.

·        Webhook modification.

·        Webhook destination change.

·        Service-account creation or modification.

·        Workload-identity change.

·        Runner-token creation or modification.

·        Automation identity change.

·        Multiple automation credentials created or modified within a short period.

·        Automation credentials created by newly privileged, inactive, unfamiliar, external, or service accounts.

·        Webhook destination that is new, unfamiliar, external, temporary, unmanaged, or outside approved integration inventory.

·        Follow-on repository cloning, project export, pipeline execution, runner execution, artifact access, package access, image activity, registry authentication, release modification, deployment activity, cloud API activity, Kubernetes API activity, or secret-manager access after automation credential changes.

Endpoint and Process Artifacts

·        Suspicious child process execution from CI/CD runner services, build agents, deployment agents, or job workers.

·        Shell interpreter use from runner or build-host contexts.

·        Scripting-engine execution from build pipelines where not expected.

·        Archive utility execution after repository or workspace enumeration.

·        Network transfer utility execution from runner or build-host contexts.

·        Container tooling used outside expected build stages.

·        Cloud CLI or Kubernetes CLI use from a runner that does not normally perform cloud or Kubernetes deployment actions.

·        Credential helper or secret-management utility activity from a pipeline stage that does not normally require it.

·        File collection, workspace bundling, cache access, artifact staging, or recursive enumeration from runner workspace paths.

·        Access to local credential paths, cloud credential files, container registry authentication files, kubeconfig files, SSH keys, token files, or environment variables from runner contexts.

·        Encoded or chained command execution within CI/CD job steps.

·        Process activity followed by unusual network egress, registry access, artifact movement, cloud activity, Kubernetes activity, or deployment activity.

Network and Egress Artifacts

·        Runner-originated outbound communication to newly observed external destinations.

·        Runner-originated communication to rare destinations for the repository, workflow, or build host.

·        Direct IP communication from runner or build-host contexts.

·        DNS queries to unusual, temporary, dynamic, or low-reputation infrastructure.

·        Connections to unmanaged object storage, raw-file hosting, paste services, tunneling services, dynamic DNS, external automation endpoints, or unknown external infrastructure.

·        Registry access from unexpected runner, source network, repository, branch, or workflow context.

·        Artifact movement to destinations not approved for build, release, or deployment workflows.

·        Unusual internal service access from runner hosts.

·        Unexpected runner-to-cloud control-plane communication.

·        Unexpected runner-to-Kubernetes API communication.

·        Egress activity that occurs after workflow modification, suspicious pipeline execution, credential access, automation credential changes, or registry activity.

Registry, Package, Artifact, and Deployment Artifacts

·        Registry authentication from unexpected runner, identity, source network, repository, or workflow.

·        Package access outside expected publishing or build paths.

·        Artifact access outside expected pipeline stage or repository path.

·        Image pull or image push from unexpected identity, repository, branch, workflow, runner, or deployment path.

·        Release modification after suspicious repository or automation activity.

·        Deployment execution after suspicious workflow, runner, or credential behavior.

·        Artifact-store access involving sensitive build outputs, deployment packages, signing material, release artifacts, infrastructure state, or high-value application assets.

·        Package publication, image publication, or deployment activity that does not match approved release windows or change-control records.

·        Registry, package, artifact, or deployment behavior tied to recently modified workflows or newly created automation credentials.

AWS Artifacts

·        STS AssumeRole or AssumeRoleWithWebIdentity activity from CI/CD-linked roles.

·        GetCallerIdentity or GetSessionToken activity from unusual source context.

·        Role assumption from outside approved CI/CD infrastructure or expected runner networks.

·        New or unusual role session names, user agents, external IDs, or role chains.

·        IAM policy attachment, inline policy creation, role trust modification, or access-key creation after suspicious CI/CD activity.

·        Secrets Manager access following suspicious repository, runner, or credential context.

·        ECR authentication, image pull, or image push from unexpected identity or source network.

·        S3 object access, object write, bucket listing, or artifact access involving deployment buckets, infrastructure-state buckets, build artifacts, package artifacts, or high-value assets.

·        Lambda, ECS, EKS, CloudFormation, CodeDeploy, or infrastructure deployment activity following suspicious CI/CD lineage.

·        GuardDuty findings that align with suspicious cloud identity, source network, or workload behavior.

Azure Artifacts

·        Microsoft Entra ID service principal sign-in from unusual source context.

·        Managed identity or federated credential use outside expected deployment path.

·        Azure Resource Manager activity from CI/CD-linked identities after suspicious repository or runner activity.

·        Role assignment write or delete activity.

·        Application credential or service principal credential changes.

·        Federated credential creation or modification.

·        Key Vault secret, key, or certificate access from suspicious identity or source context.

·        Azure Container Registry authentication, image pull, or image push from unexpected identity or source network.

·        Storage blob read, write, list, or delete activity involving deployment containers, infrastructure-state containers, build artifacts, package artifacts, or high-value assets.

·        Azure Functions, App Service, AKS, Resource Manager deployment, or network security rule changes following suspicious CI/CD lineage.

·        Defender for Cloud alerts that align with suspicious identity, cloud resource, or deployment behavior.

GCP Artifacts

·        Service account use from unusual source context.

·        Workload identity federation token exchange outside expected repository, provider, pool, source network, or deployment path.

·        Service account impersonation from unfamiliar principal subject or runner context.

·        IAM policy changes, service-account key creation, or workload identity federation changes after suspicious CI/CD activity.

·        Secret Manager access following suspicious repository, runner, or credential context.

·        Artifact Registry authentication, image pull, image push, package upload, or package download from unexpected identity or source network.

·        Cloud Storage object read, write, list, or delete activity involving deployment buckets, infrastructure-state buckets, build artifacts, package artifacts, or high-value assets.

·        Cloud Functions, Cloud Run, GKE, Cloud Build, Deployment Manager, or firewall changes following suspicious CI/CD lineage.

·        Security Command Center findings that align with suspicious cloud identity, source network, or workload behavior.

YARA and File Artifact Conditions

·        YARA has no primary detection artifact requirement for this report.

·        YARA may become useful only if incident response recovers a stable artifact.

·        Possible conditional artifacts include a malicious workflow payload, runner-stage script, loader, dropper, webshell, credential-access tool, remote-access tool, suspicious binary, memory artifact, encoded payload, configuration artifact, or reusable file-content pattern.

·        YARA artifacts should be treated as investigative support only and should not replace repository, CI/CD, runner, identity, network, registry, cloud, Kubernetes, deployment, or incident-response telemetry.

Artifact Interpretation Guidance

·        A single workflow change does not prove compromise.

·        A single token creation event does not prove compromise.

·        A single runner process event does not prove compromise.

·        A single registry event does not prove compromise.

·        A single cloud API event does not prove compromise.

·        A single deployment event does not prove compromise.

·        Confidence increases when repository, CI/CD, runner, endpoint, network, credential, registry, package, cloud, Kubernetes, deployment, and incident-response artifacts align within a defensible timeline.

·        Analyst escalation should focus on lineage: actor, repository, branch, workflow, pipeline, job, runner, credential, identity, source IP, destination, resource, cloud account, Kubernetes cluster, deployment environment, and timestamp.

S28 Detection Strategy and SOC Implementation Guidance

Figure 5

Detection Strategy and SOC Implementation Guidance

This section provides SOC implementation guidance for operationalizing the S25 rule set and the S26 traceability model.

Implementation Objective

The primary implementation objective is to detect repository workflow abuse before it becomes downstream credential misuse, registry compromise, package compromise, cloud-control-plane exposure, Kubernetes exposure, or deployment compromise.

Detection Model

·        Use behavior-led detection rather than IOC-led detection.

·        Treat repository workflow changes as detection anchors.

·        Treat CI/CD runner execution as a high-value correlation point.

·        Treat automation credential changes as high-value lineage events.

·        Treat registry, package, artifact, and deployment activity as downstream exposure indicators.

·        Treat AWS, Azure, and GCP activity as downstream cloud-control-plane and identity-plane correlation.

·        Treat YARA as conditional investigative support only when stable artifacts are recovered.

·        Do not treat any single event as proof of compromise without supporting telemetry.

Recommended SOC Workflow

·        Confirm the affected repository, project, group, branch, workflow file, pipeline, job, runner, actor, service account, source IP, and timestamp.

·        Determine whether the workflow, CI/CD configuration, deployment script, release script, package-publishing path, container-build path, signing path, infrastructure-as-code path, cloud deployment path, or Kubernetes deployment path was modified.

·        Identify whether the modifying account was newly privileged, inactive, unfamiliar, external, service-account based, or authenticating from unusual source infrastructure.

·        Review merge, pull request, approval-rule, protected-branch, and change-control records.

·        Determine whether the modified workflow executed.

·        Review runner assignment, runner tag, runner registration, job logs, command-line telemetry, and runner-host process lineage.

·        Identify credential-access behavior, environment-variable inspection, archive creation, recursive file collection, external transfer, package-manager activity, registry tooling, cloud CLI use, Kubernetes CLI use, or deployment tooling.

·        Review network telemetry for unusual runner egress, registry access, artifact movement, cloud endpoint communication, Kubernetes API communication, and internal service access.

·        Review automation credential changes, token scope changes, deploy-key changes, OAuth application creation, webhook changes, service-account changes, workload identity changes, and runner-token changes.

·        Review registry, package, artifact, image, release, and deployment telemetry.

·        Review AWS, Azure, or GCP activity for identity use, secrets access, registry access, storage access, IAM changes, workload changes, and deployment changes.

·        Scope impact by repository, runner, credential, identity, registry, package, artifact, image, cloud account, subscription, project, Kubernetes cluster, deployment environment, and production workload.

Triage Questions

·        Was the repository or workflow sensitive enough to affect production deployment, package publication, image publication, signing, infrastructure-as-code, cloud deployment, Kubernetes deployment, or high-value application delivery?

·        Was the workflow change approved, reviewed, and tied to a legitimate change-control record?

·        Did the workflow execute after modification?

·        Did the runner execute suspicious commands or access sensitive paths?

·        Did the runner inspect environment variables, protected variables, token material, cloud credentials, registry credentials, kubeconfig files, SSH keys, or secret files?

·        Did the runner communicate with new, rare, unmanaged, external, or suspicious destinations?

·        Did automation credentials, deploy keys, tokens, OAuth applications, webhooks, service accounts, workload identities, or runner tokens change before downstream activity?

·        Did registry, package, artifact, image, release, or deployment activity occur after the suspicious repository or credential event?

·        Did cloud identity use occur from unexpected source networks, regions, geographies, user agents, service accounts, roles, or principals?

·        Did IAM, role assignment, application credential, service-account key, workload identity, Key Vault, Secrets Manager, storage, registry, Kubernetes, workload, or deployment changes occur after suspicious CI/CD activity?

·        Does the timeline show a defensible chain from repository-control change to runner execution to downstream exposure?

Severity Guidance

·        Assign higher severity when the affected repository supports production deployment, package publication, image publication, signing, infrastructure-as-code, cloud deployment, Kubernetes deployment, or high-value application delivery.

·        Assign higher severity when suspicious workflow changes are followed by runner execution and credential-access behavior.

·        Assign higher severity when runner execution is followed by external transfer, registry access, artifact movement, cloud identity use, Kubernetes activity, or deployment activity.

·        Assign higher severity when automation credentials are created, expanded, or modified before downstream activity.

·        Assign higher severity when cloud activity involves privileged roles, owner-like identities, editor-like identities, service-account key creation, access-key creation, role assignment changes, IAM policy changes, Key Vault access, Secrets Manager access, Artifact Registry access, ECR access, ACR access, storage access, deployment resources, production workloads, or infrastructure-state assets.

·        Assign lower severity when activity is clearly tied to approved release engineering, CI/CD refactoring, runner migration, infrastructure deployment, cloud operations, credential rotation, secret rotation, vulnerability scanning, security testing, incident response, or documented change-control activity.

·        Do not downgrade solely because the actor is a service account if the service account is newly created, newly privileged, broadly scoped, or acting outside expected repository, runner, source network, time window, or deployment path.

Containment Guidance

·        Preserve repository, CI/CD, runner, identity, registry, cloud, Kubernetes, deployment, and endpoint evidence before disruptive containment where possible.

·        Disable or rotate suspicious project, group, personal, deploy-key, runner-token, service-account, workload-identity, cloud-role, application, or webhook credentials.

·        Pause suspicious pipelines, workflows, runners, deployment jobs, package-publication jobs, image-publication jobs, and release jobs.

·        Quarantine or isolate affected runners and build hosts where endpoint evidence suggests compromise.

·        Revoke or constrain cloud sessions tied to suspicious CI/CD-linked identities.

·        Rotate secrets exposed to affected runners, workflows, repositories, artifacts, packages, registries, cloud identities, Kubernetes clusters, and deployment environments.

·        Review and revert unauthorized workflow, CI/CD configuration, deployment script, release script, package-publishing, container-build, signing, infrastructure-as-code, cloud deployment, and Kubernetes deployment changes.

·        Review registry images, packages, artifacts, and release assets produced during the suspicious window.

·        Review cloud IAM, role assignment, application credential, service-account key, workload identity, Key Vault, Secrets Manager, storage, registry, Kubernetes, workload, and deployment changes.

·        Avoid broad containment actions that destroy telemetry before scope is understood unless active harm is ongoing.

Validation Requirements

·        Validate exact SIEM schemas.

·        Validate indexes, sourcetypes, data streams, custom properties, and parser behavior.

·        Validate Git audit fields.

·        Validate CI/CD job and pipeline fields.

·        Validate runner identity fields.

·        Validate endpoint process and command-line fields.

·        Validate network, DNS, proxy, firewall, and NDR fields.

·        Validate registry, package, artifact, image, release, and deployment fields.

·        Validate AWS CloudTrail, S3 data-event, Secrets Manager, ECR, IAM, STS, Lambda, ECS, EKS, CloudFormation, and deployment fields where relevant.

·        Validate Azure Entra ID, Azure Activity, Key Vault, ACR, Storage, App Service, Functions, AKS, Resource Manager, and deployment fields where relevant.

·        Validate GCP Audit Logs, Admin Activity, Data Access, IAM, service account, workload identity federation, Secret Manager, Artifact Registry, Cloud Storage, Cloud Functions, Cloud Run, GKE, Cloud Build, and Deployment Manager fields where relevant.

·        Validate repository-to-runner mapping.

·        Validate repository-to-identity mapping.

·        Validate repository-to-deployment mapping.

·        Validate identity lineage.

·        Validate credential lineage.

·        Validate source-network preservation.

·        Validate timestamp normalization and event latency.

·        Validate reference sets, allowlists, baselines, and exception records.

·        Validate false-positive rates.

·        Validate query performance.

·        Validate SOC triage workflow.

·        Validate hunt-to-alert promotion criteria.

·        Validate incident-response evidence requirements.

Hunt-to-Alert Promotion Criteria

·        Promote to alerting only after the rule has been validated against local telemetry.

·        Promote to alerting only after expected workflow changes, release engineering, runner migration, package publication, image publication, infrastructure deployment, cloud operations, security testing, vulnerability scanning, and incident-response patterns have been baselined.

·        Promote to alerting only when the rule produces a manageable false-positive rate.

·        Promote to alerting only when the SOC has a clear triage path and ownership model.

·        Promote to alerting only when the detection includes enough context to reconstruct repository, pipeline, runner, credential, identity, source, destination, resource, and deployment lineage.

·        Keep in hunt mode where logs are incomplete, field mappings are unstable, event latency is unresolved, or cloud-to-CI/CD lineage is weak.

S29 Detection Coverage Summary

Detection Coverage Summary

The detection strategy provides strong behavior-led coverage for self-hosted Git platform compromise through repository workflow abuse. Coverage is strongest where repository, CI/CD, runner, endpoint, network, identity, registry, package, artifact, cloud, Kubernetes, and deployment telemetry are correlated.

Overall Coverage

·        Repository workflow abuse is directly covered through workflow-change, CI/CD execution, runner execution, and automation credential correlation.

·        Suspicious runner execution is directly covered through endpoint, process, command-line, SIEM, and network correlation.

·        Automation credential abuse is directly covered through token, deploy-key, OAuth application, webhook, service-account, workload-identity, and runner-token change correlation.

·        Registry, package, artifact, image, release, and deployment activity are directly covered where downstream activity can be tied to repository or CI/CD lineage.

·        Cloud-control-plane and identity-plane activity are directly covered in AWS, Azure, and GCP when cloud events can be linked to upstream repository, CI/CD, runner, credential, or identity context.

·        YARA is correctly excluded from primary coverage because no stable artifact is required for the governing detection model.

·        The model is durable because it does not depend on a single CVE, IOC, malware hash, domain, IP address, package name, image name, repository name, or one-time exploit string.

Covered Systems

·        NDR / Network Behavioral Analytics provides network behavior coverage for runner egress, registry communication, artifact movement, cloud endpoint communication, Kubernetes API communication, and unusual internal service access.

·        SentinelOne provides endpoint and runner-host coverage for suspicious process execution, credential-access preparation, archive creation, scripting behavior, package-manager activity, container tooling, cloud CLI use, Kubernetes CLI use, and suspicious child-process lineage.

·        Splunk provides multi-source SIEM correlation across Git, CI/CD, runner, endpoint, network, identity, registry, package, cloud, Kubernetes, and deployment telemetry.

·        Elastic provides behavior-led event sequencing across Git, CI/CD, endpoint, network, identity, registry, cloud, Kubernetes, and deployment telemetry.

·        QRadar provides correlation using custom properties, reference sets, building blocks, offense logic, and multi-source event mapping.

·        SIGMA provides portable detection patterns that can be translated into local SIEM logic.

·        AWS provides downstream cloud-control-plane and identity-plane coverage for role assumption, Secrets Manager access, ECR activity, S3 activity, IAM changes, workload changes, and deployment changes.

·        Azure provides downstream cloud-control-plane and identity-plane coverage for service principal use, managed identity use, federated credential use, Key Vault access, ACR activity, Storage activity, role assignment changes, workload changes, and deployment changes.

·        GCP provides downstream cloud-control-plane and identity-plane coverage for service account use, workload identity federation, Secret Manager access, Artifact Registry activity, Cloud Storage activity, IAM changes, workload changes, and deployment changes.

·        YARA provides no primary coverage and remains conditional investigative support only if stable file, memory, script, payload, binary, or reusable artifact evidence is recovered.

Strongest Coverage Areas

·        Workflow modification followed by CI/CD execution.

·        Workflow modification followed by suspicious runner-host execution.

·        Runner execution involving credential access, environment-variable inspection, archive creation, registry tooling, cloud CLI use, Kubernetes CLI use, or deployment tooling.

·        Automation credential, deploy-key, token, OAuth application, webhook, service-account, workload-identity, or runner-token change followed by downstream activity.

·        Registry, package, artifact, image, release, or deployment activity tied to suspicious repository or CI/CD lineage.

·        CI/CD-linked identity use followed by AWS, Azure, or GCP control-plane activity.

·        Cloud secret, storage, registry, workload, IAM, or deployment changes tied to suspicious CI/CD context.

·        Network egress from runner or build-host infrastructure to rare, unmanaged, temporary, or unauthorized destinations.

·        Repository-to-runner-to-cloud lineage where timestamps, identities, and source context align.

Partial Coverage Areas

·        Workflow abuse that uses approved workflows and expected runner commands may require deeper baseline comparison.

·        Credential misuse involving existing long-lived credentials may be harder to detect if no recent credential creation, scope expansion, or permission change is visible.

·        Cloud activity may remain ambiguous where identity federation, NAT, proxying, service-account reuse, role chaining, or session reuse obscures lineage.

·        Registry, package, artifact, and deployment activity may require strong image, package, artifact, and release metadata to determine whether output was unauthorized.

·        Kubernetes activity may require dedicated audit logging, service-account mapping, namespace mapping, and deployment lineage.

·        Endpoint coverage may be limited where runners are ephemeral, unmanaged, or missing command-line telemetry.

·        Network coverage may be limited where runner egress is not logged, encrypted traffic is not enriched, or proxy visibility is incomplete.

·        YARA coverage remains conditional and artifact-dependent.

Uncovered or Non-Primary Areas

·        Successful compromise cannot be proven by any single S25 rule alone.

·        Actor attribution is not provided by these detections without incident-specific intelligence.

·        YARA is not a primary detection mechanism for this report.

·        Offline repository compromise, out-of-band credential theft, or preexisting cloud credential misuse may not be visible unless it produces observable repository, CI/CD, runner, identity, registry, cloud, Kubernetes, deployment, endpoint, or network activity.

·        Environments without Git audit logs, CI/CD logs, runner telemetry, identity logs, registry logs, cloud logs, or deployment logs will have reduced coverage.

·        Environments with incomplete field mapping, inconsistent parser behavior, missing timestamps, weak source-network preservation, or poor repository-to-identity mapping will have reduced confidence.

Coverage Confidence

Coverage confidence is high when repository, CI/CD, runner, endpoint, network, identity, registry, package, artifact, cloud, Kubernetes, and deployment telemetry are available and correlated.

Coverage confidence is moderate when repository, CI/CD, runner, and SIEM telemetry are available, but endpoint, network, cloud, Kubernetes, or deployment telemetry is incomplete.

Coverage confidence is low when the environment lacks Git audit logs, CI/CD job logs, runner identity, command-line telemetry, credential lifecycle logs, registry logs, package logs, cloud logs, Kubernetes logs, deployment logs, or source-network preservation.

Coverage Conclusion

The completed S25 rule set provides strong behavior-led coverage for the report’s intended detection model. The model is durable because it tracks operational behavior across repository control, trusted automation, runner execution, credential changes, registry and artifact activity, cloud identity use, Kubernetes activity, and deployment control.

The coverage is not dependent on artifact recovery or static indicators. This makes the model reusable across self-hosted Git environments where the required telemetry can be collected, normalized, correlated, and validated.

S30 Intelligence Maturity Assessment

Intelligence Maturity Assessment

This section assesses the maturity of the detection model and the operational intelligence available for self-hosted Git platform compromise through repository workflow abuse.

Maturity Rating

Advanced.

Assessment Basis

·        The detection model is behavior-led rather than IOC-led.

·        The detection model focuses on durable attacker behavior across repository control, CI/CD execution, runner activity, automation credential changes, registry and artifact activity, cloud identity use, Kubernetes activity, and deployment control.

·        The model avoids dependency on a single CVE, exploit string, domain, IP address, package name, image name, repository name, hash, malware family, or recovered artifact.

·        The rule set provides coverage across NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA, AWS, Azure, and GCP.

·        YARA is correctly excluded from primary detection because the governing model is telemetry-led rather than artifact-led.

·        The report distinguishes suspicious behavior from confirmed compromise and avoids over-attribution.

·        The report defines operational dependencies, telemetry requirements, validation gates, and hunt-to-alert promotion criteria.

Maturity Strengths

·        Strong mapping between threat behavior and detection engineering.

·        Durable coverage across repository, CI/CD, runner, endpoint, network, identity, registry, package, artifact, cloud, Kubernetes, and deployment telemetry.

·        Clear separation between detection anchors and compromise confirmation.

·        Strong downstream cloud-control-plane coverage across AWS, Azure, and GCP.

·        Strong endpoint and network support for runner-host and runner-egress behavior.

·        Strong SIEM portability through Splunk, Elastic, QRadar, and SIGMA.

·        Strong traceability from S25 rule logic to S26 behavior mapping.

·        Clear zero-rule disposition for YARA.

·        Conservative treatment of cloud events, credential events, workflow changes, registry activity, and deployment activity.

·        Report-ready guidance for SOC triage, containment, validation, and hunt-to-alert promotion.

Maturity Constraints

·        Detection confidence depends on local telemetry availability and schema quality.

·        CI/CD and Git audit telemetry may vary significantly by platform.

·        Runner identity mapping may be weak in ephemeral or unmanaged runner environments.

·        Endpoint telemetry may be incomplete on temporary build hosts.

·        Network telemetry may be incomplete where runner egress is not centrally observed.

·        Cloud lineage may be obscured by identity federation, shared service accounts, shared roles, NAT, proxying, role chaining, service-account impersonation, or session reuse.

·        Registry, package, artifact, image, and deployment confidence depends on metadata quality.

·        Kubernetes coverage depends on audit logging, namespace mapping, service-account mapping, and deployment lineage.

·        YARA can only provide investigative value when stable artifacts are recovered.

·        Production readiness depends on local validation, false-positive testing, query-performance testing, SOC workflow readiness, and incident-response evidence requirements.

Operational Intelligence Value

·        The model helps defenders identify suspicious changes to repository automation before downstream impact occurs.

·        The model helps SOC teams connect repository activity to runner execution, credential access, registry activity, cloud identity use, Kubernetes activity, and deployment changes.

·        The model helps distinguish normal release engineering from suspicious workflow abuse by using lineage, sensitivity, source context, and change-control validation.

·        The model helps prioritize containment around affected repositories, workflows, runners, credentials, identities, registries, packages, artifacts, cloud resources, Kubernetes clusters, and deployment environments.

·        The model provides reusable detection coverage across multiple self-hosted Git platforms and cloud providers.

·        The model supports future amendments without requiring the report to be scoped to a single CVE or one-time exploit path.

Intelligence Gaps

·        Public reporting may not provide enough victim-environment telemetry to validate every possible repository-to-cloud lineage path.

·        Exact platform fields differ across GitLab, Gitea, Forgejo, Bitbucket Server, GitHub Enterprise Server, and other self-hosted Git systems.

·        CI/CD job log depth, runner metadata, and workflow audit detail vary by deployment.

·        Some environments may not log protected-variable access, token lifecycle events, deploy-key changes, webhook payloads, or runner command lines.

·        Cloud providers may not preserve enough source identity or source-network context to prove repository-to-cloud lineage without SIEM enrichment.

·        Kubernetes and deployment platforms may require separate logging and enrichment to tie control-plane changes back to CI/CD lineage.

·        Artifact-based evidence may not exist unless attackers stage reusable scripts, binaries, payloads, webshells, tools, or configuration artifacts.

·        Threat actor attribution remains out of scope without incident-specific intelligence or validated campaign reporting.

Maturity Improvement Path

·        Standardize Git audit log ingestion and field mapping.

·        Standardize CI/CD pipeline, job, runner, and workflow telemetry.

·        Enforce command-line and process telemetry on runners and build hosts.

·        Capture runner egress through DNS, proxy, firewall, NDR, and cloud endpoint visibility.

·        Enable registry, package, artifact, image, and deployment logging.

·        Enable AWS, Azure, and GCP cloud audit logging, data-event logging, identity logging, and diagnostic logging where relevant.

·        Enable Kubernetes audit logging and deployment-platform telemetry.

·        Build repository-to-runner, repository-to-identity, repository-to-deployment, and identity-to-resource mappings.

·        Maintain reference sets for sensitive repositories, approved runners, approved identities, approved destinations, approved workflows, approved deployments, and approved change windows.

·        Validate S25 rules in hunt mode before promotion to alert mode.

·        Conduct false-positive testing, query-performance testing, SOC triage testing, and incident-response tabletop testing.

·        Capture recovered artifacts for optional YARA support only when stable artifacts exist.

Final Maturity Determination

The intelligence maturity for this report is advanced because the detection model is behavior-led, cross-platform, telemetry-driven, and operationally reusable. It provides strong coverage across repository workflow abuse, CI/CD runner activity, automation credential changes, registry and artifact activity, cloud identity use, Kubernetes activity, and deployment control.

The model is not fully production-complete until each customer environment validates its telemetry, schemas, field mappings, baselines, exception logic, query performance, SOC triage workflow, and incident-response evidence requirements.

S31 — Telemetry Dependencies

Self-hosted Git platform compromise through repository workflow abuse requires telemetry that can prove whether suspicious repository, workflow, CI/CD, runner, credential, registry, package, image, artifact, cloud, Kubernetes, or deployment activity remained limited to exposure or attempted abuse, or whether it affected software-delivery integrity, automation identity trust, protected variables, build outputs, release artifacts, deployment paths, or downstream production-adjacent systems. The central dependency is the ability to correlate Git audit logs, CI/CD pipeline logs, runner telemetry, endpoint and process telemetry, identity and token telemetry, registry and package logs, artifact telemetry, network egress, cloud logs, Kubernetes logs, deployment logs, asset context, automation identity mapping, and change-control evidence into a single software-delivery control-plane investigation model.

Self-Hosted Git Audit Telemetry

·        Git audit logs must capture repository changes, workflow-file changes, protected-branch changes, merge request activity, group and project permission changes, deploy-key creation, token creation, webhook modification, OAuth application activity, runner registration, repository export, archive access, and administrative actions.

·        Required fields include actor, actor type, user ID, account name, repository, project, group, branch, workflow file, affected object, action, result, source IP, user agent, authentication method, timestamp, and administrative context where available.

·        Git audit telemetry is required to determine whether suspicious repository-control activity preceded workflow execution, runner activity, credential access, registry access, or downstream deployment activity.

CI/CD Pipeline and Workflow Telemetry

·        CI/CD telemetry must capture pipeline creation, workflow source, job execution, runner assignment, job token use, branch or merge request context, workflow-file origin, protected-variable behavior, cache access, artifact use, environment deployment, and job result.

·        Required fields include pipeline ID, job ID, workflow name, workflow file, repository, branch, merge request, triggering actor, token or job identity, runner ID, runner tags, runner scope, command context where available, artifact references, cache references, timestamp, and result.

·        CI/CD telemetry is required to determine whether a suspicious workflow change or automation identity event resulted in trusted runner execution, credential exposure behavior, artifact access, package activity, image activity, or downstream deployment activity.

Runner Host and Endpoint Telemetry

·        Runner host telemetry should capture process creation, command-line execution, parent-child process lineage, shell activity, container execution, Docker socket use, workspace access, file access, credential-file access, environment-variable inspection, archive creation, outbound connections, and persistence attempts.

·        Required fields include host name, runner ID, runner tag, repository, pipeline ID, job ID, process name, command line, parent process, user or service account, working directory, file path, container context, network destination, timestamp, and result where available.

·        Runner host telemetry is required to validate whether suspicious CI/CD execution attempted credential access, artifact staging, source-code bundling, outbound transfer, internal service access, package or registry interaction, cloud CLI use, Kubernetes CLI use, or persistence.

Identity, Token, and Automation Credential Telemetry

·        Identity telemetry must capture user authentication, token lifecycle events, deploy-key creation, project token activity, group token activity, personal access token activity, OAuth application activity, service-account use, bot-account use, workload identity use, privilege changes, group membership changes, and multi-factor authentication context.

·        Required fields include actor, account type, token type, token scope, service account, workload identity, OAuth application, deploy key, source IP, device context, authentication method, MFA status, privilege level, affected repository or group, timestamp, and result where available.

·        Identity and token telemetry is required to determine whether repository workflow abuse involved compromised maintainers, automation identities, broad-scope tokens, deploy keys, OAuth applications, service accounts, or workload identities with downstream access.

Registry, Package, Image, and Artifact Telemetry

·        Registry, package, image, and artifact telemetry must capture package publication, package download, image pull, image push, image overwrite, tag creation, tag modification, release asset modification, artifact download, artifact upload, cache access, token use, authentication failures, and unauthorized access attempts.

·        Required fields include package name, image name, tag, artifact ID, cache key, registry, repository, actor, token identity, source IP, runner identity, pipeline ID, job ID, action, result, timestamp, and object lineage where available.

·        Registry and artifact telemetry is required to determine whether suspicious workflow activity affected build outputs, packages, images, release artifacts, caches, or trusted software-delivery material.

Network and Outbound Communication Telemetry

·        Network telemetry must capture runner, build-host, Git platform, registry, package-service, release-system, and deployment-system communication to internal and external destinations.

·        Required fields include source host, source role, destination domain, destination IP, destination service, destination port, protocol, request method where available, byte count, directionality, timing, user agent where available, connection result, and process or job context where available.

·        Network telemetry is required to identify unusual runner egress, raw-file retrieval, external staging, object-storage transfer, webhook delivery, artifact movement, cache movement, source-code bundle transfer, internal service access, and downstream control-plane interaction.

Cloud, Kubernetes, and Deployment Telemetry

·        Cloud, Kubernetes, and deployment telemetry must capture service-principal use, workload identity use, access-key use, deployment actions, secret-manager access, role changes, infrastructure changes, container registry access, Kubernetes API activity, deployment controller activity, and actions performed by CI/CD-associated identities.

·        Required fields include identity, role, credential source, source IP, runner or workload context, repository or pipeline context where available, cloud account, subscription, project, region, resource, namespace, cluster, deployment target, API action, timestamp, and result.

·        Cloud, Kubernetes, and deployment telemetry is required to scope downstream exposure after suspicious repository workflow activity and to determine whether CI/CD-linked credentials were used outside expected repository, runner, branch, project, time window, geography, device, host, or network context.

Asset, Repository, Runner, and Change-Control Telemetry

·        Required context includes self-hosted Git platform inventory, repository inventory, sensitive repository classification, group and project ownership, runner inventory, runner tag inventory, runner scope, runner privilege level, package registry inventory, container registry inventory, artifact-store inventory, deployment-system inventory, cloud account inventory, Kubernetes cluster inventory, and automation identity inventory.

·        Change-control records should include approved workflow changes, release activity, runner registration, runner migration, deploy-key creation, token creation, webhook changes, OAuth application onboarding, package publication, image publication, artifact retention, infrastructure deployment, cloud changes, Kubernetes changes, security testing, and incident-response activity.

·        Asset, repository, runner, and change-control context is required to separate suspicious repository workflow abuse from legitimate release engineering, CI/CD refactoring, runner scaling, package publication, container builds, registry maintenance, deployment work, and platform administration.

S32 — Detection Limitations

Detection of self-hosted Git platform compromise through repository workflow abuse is limited by whether the organization can reconstruct the relationship between repository-control activity, workflow execution, runner behavior, credential access, registry or artifact activity, outbound communication, and downstream cloud, Kubernetes, or deployment activity. Environments that rely only on repository change history, pipeline status, isolated job failures, registry events, or cloud alerts will not have enough evidence for high-confidence compromise determination.

Primary Limitations

·        Limited Git audit logging may reduce visibility into workflow-file changes, deploy-key creation, token creation, webhook modification, OAuth application activity, runner registration, protected-branch changes, permission changes, and administrative actions.

·        Short CI/CD log retention may prevent responders from reconstructing pipeline execution, job context, runner assignment, protected-variable behavior, artifact access, cache access, or command activity after delayed discovery.

·        Missing runner endpoint telemetry may prevent validation of command execution, credential access, environment-variable inspection, archive creation, outbound transfer, Docker socket use, container activity, persistence, or internal service access.

·        Shared, persistent, or privileged runners may make it difficult to separate normal build activity from suspicious execution or cross-project exposure.

·        Metadata-only network visibility may identify unusual runner destinations or transfer patterns but may not confirm payload, artifact, credential, package, image, or repository context.

·        Missing registry, package, image, or artifact lineage may prevent reliable validation of package publication, image push, image overwrite, artifact modification, cache exposure, or release asset tampering.

·        Missing identity and token telemetry may prevent defenders from identifying compromised maintainers, stale accounts, bot-account misuse, token creation, token scope, service-account activity, OAuth application abuse, or workload identity use.

·        Missing cloud or Kubernetes identity mapping may prevent attribution of downstream API activity to CI/CD credentials, service principals, workload identities, runner hosts, repository events, or pipeline timing.

·        Poor asset and repository inventory may make it difficult to distinguish sensitive repositories, production deployment workflows, signing workflows, package-publishing workflows, image-publishing workflows, privileged runners, and approved deployment paths.

·        Missing change-control records may increase false positives around release engineering, workflow refactoring, runner migration, package publication, image publication, artifact retention, registry maintenance, deployment automation, cloud changes, and Kubernetes changes.

·        Poor timestamp normalization can break sequence logic between repository-control activity, workflow execution, runner behavior, credential access, outbound transfer, registry activity, and downstream deployment or cloud activity.

Detection Boundary

·        A workflow-file change is not proof of compromise by itself.

·        A pipeline failure, runner error, registry error, or cloud authorization failure is not proof of compromise by itself.

·        A new deploy key, token, webhook, OAuth application, service account, or runner registration is not proof of compromise without actor, scope, timing, repository sensitivity, and follow-on activity.

·        A single outbound connection from a runner is not sufficient to infer exfiltration.

·        Registry access, package access, artifact download, image pull, image push, or cache access is not proof of malicious software-delivery activity without supporting lineage.

·        Cloud, Kubernetes, or deployment activity should remain downstream investigative leads unless linked to suspicious repository or CI/CD activity through timing, identity, credential, runner, workflow, pipeline, endpoint, or incident-response evidence.

·        Valid maintainer activity should not be treated as malicious when it aligns with approved release work, change-control records, branch protections, workflow ownership, runner scope, and expected deployment behavior.

·        Detection logic must not rely on prior alert state, another rule’s output, analyst judgment after alert generation, DRI, or TCR as an input.

·        High-confidence alerting should require validated multi-signal correlation across repository control, workflow execution, runner behavior, credential access, registry or artifact activity, outbound communication, or downstream control-plane behavior.

Operational Impact of Limitations

Detection coverage should be reduced, scoped down, or withheld when required telemetry is unavailable, incomplete, delayed, or not normalized. Suspicious repository workflow activity may be analytically important but unsuitable for high-confidence alerting if the organization cannot validate actor identity, repository sensitivity, workflow change context, runner execution, credential exposure, registry activity, outbound communication, downstream control-plane activity, and change-control evidence within bounded and locally validated correlation windows.

S33 — Defensive Control & Hardening Improvements

Defensive improvement should focus on making software-delivery trust measurable, enforceable, and recoverable after suspicious repository workflow activity. The objective is not only to harden a self-hosted Git platform, but to prove that repository integrity, workflow execution, runner trust, automation credentials, protected variables, package outputs, container images, artifacts, deployment paths, and downstream cloud or Kubernetes activity remain trustworthy.

Repository and Workflow Governance

·        Maintain a complete inventory of self-hosted Git platforms, groups, projects, repositories, protected branches, release branches, workflow files, CI/CD configuration paths, package-publishing workflows, image-publishing workflows, signing workflows, infrastructure-as-code workflows, and deployment workflows.

·        Classify sensitive repositories based on production deployment access, package-publication authority, image-publication authority, signing authority, infrastructure-as-code control, secret access, cloud access, Kubernetes access, regulated data exposure, and business-critical application ownership.

·        Require auditable change-control for workflow-file changes, protected-branch changes, approval-rule changes, CODEOWNERS changes, release-control changes, and CI/CD configuration changes affecting sensitive repositories.

·        Treat unexplained workflow changes in sensitive repositories as software-delivery control-plane events requiring validation.

Runner Segmentation and Execution Hardening

·        Maintain an authoritative inventory of self-hosted runners, shared runners, persistent runners, privileged runners, runner tags, runner scopes, runner owners, runner network access, runner service accounts, and runner credential exposure.

·        Segment runners by repository sensitivity, environment, workflow class, credential exposure, network access, and deployment authority.

·        Restrict privileged runners, Docker socket access, persistent workspaces, broad internal network reach, and access to protected variables to approved workflows and repositories.

·        Prefer ephemeral runners for sensitive workflows where operationally feasible.

·        Monitor for new runner registration, runner reuse, runner tag changes, runner scope expansion, privileged container use, Docker socket access, and sensitive workflow execution outside approved patterns.

Automation Identity and Secret Hardening

·        Review deploy keys, project access tokens, group access tokens, personal access tokens, OAuth applications, webhooks, bot accounts, service accounts, workload identities, deployment identities, package credentials, registry credentials, cloud credentials, Kubernetes credentials, and signing material.

·        Reduce broad-scope tokens, long-lived credentials, standing automation privilege, and cross-project access where possible.

·        Restrict protected variables, deployment credentials, signing material, registry credentials, cloud credentials, and Kubernetes credentials to approved repositories, branches, workflows, environments, and runner scopes.

·        Require ownership, expiration, scope review, and rotation procedures for high-risk automation credentials.

·        Treat unexpected automation credential creation or expansion near suspicious workflow activity as a high-priority escalation event.

Package, Image, Artifact, and Registry Integrity

·        Maintain ownership and lineage records for packages, container images, release assets, build artifacts, caches, image tags, signing outputs, deployment manifests, and infrastructure templates.

·        Monitor for unusual package publication, image push, image overwrite, release asset modification, artifact download, cache access, registry authentication, and package or image activity after suspicious workflow activity.

·        Require validation procedures for packages, images, artifacts, release assets, and deployment manifests affected by suspicious repository or CI/CD activity.

·        Build rollback and revocation procedures for suspicious packages, container images, release artifacts, registry credentials, signing material, and deployment outputs.

Cloud, Kubernetes, and Deployment Control Hardening

·        Map CI/CD credentials, service principals, workload identities, deployment identities, cloud roles, Kubernetes service accounts, namespace permissions, secret-manager access, and deployment-controller permissions to repositories, workflows, runners, and environments.

·        Restrict cloud and Kubernetes permissions used by CI/CD automation to least privilege and expected deployment scope.

·        Monitor for cloud API activity, Kubernetes API activity, deployment-platform activity, infrastructure-as-code execution, secret access, role changes, and production deployment actions after suspicious repository or workflow activity.

·        Treat downstream cloud, Kubernetes, and deployment activity as linked to repository workflow abuse only when identity, credential, runner, workflow, repository, timing, pipeline, or incident-response evidence supports the connection.

Telemetry, Baseline, and Correlation Hardening

·        Enable and retain Git audit logs, CI/CD pipeline logs, runner telemetry, endpoint process telemetry, network egress logs, registry logs, package-service logs, artifact logs, identity logs, cloud logs, Kubernetes logs, and deployment logs long enough for retrospective investigation.

·        Normalize timestamps, repository identifiers, runner identifiers, token identifiers, service-account names, package names, image names, artifact identifiers, cloud identities, Kubernetes namespaces, and deployment identifiers.

·        Baseline normal workflow changes, runner usage, token creation, webhook creation, deploy-key creation, package publication, image pushes, artifact access, outbound destinations, cloud actions, Kubernetes actions, and deployment behavior.

·        Require multi-signal correlation before high-severity alerting.

Incident Response and Recovery Hardening

·        Create response procedures for suspected repository workflow abuse, runner compromise, automation credential exposure, protected-variable access, registry abuse, package manipulation, image manipulation, artifact tampering, deployment compromise, cloud activity, and Kubernetes activity.

·        Require rapid validation of repository state, workflow state, runner state, token scope, deploy keys, webhooks, OAuth applications, protected variables, package outputs, image outputs, artifact integrity, deployment activity, and downstream cloud or Kubernetes access.

·        Prepare decision paths for token revocation, secret rotation, deploy-key removal, webhook removal, OAuth application removal, runner quarantine, package rollback, image rollback, artifact invalidation, deployment rollback, cloud containment, and Kubernetes containment.

·        Treat suspected repository workflow abuse as a software-delivery control-plane incident, not a routine source-code or CI/CD alert.

S34 — Defensive Control & Hardening Architecture

Figure 6

The defensive architecture should treat self-hosted Git, CI/CD, runner, registry, package, artifact, deployment, cloud, and Kubernetes trust as monitored software-delivery control-plane infrastructure rather than an assumed condition. The architecture must connect repository governance, workflow execution, runner context, credential and secret controls, registry and artifact integrity, network behavior, downstream control-plane activity, change-control context, and recovery workflows into a single validation model.

Architecture Layer 1: Repository Inventory and Sensitivity Governance

Repository inventory and sensitivity governance establishes what software-delivery assets exist and which ones carry production, package, image, signing, cloud, Kubernetes, or business-critical authority. This layer captures self-hosted Git platforms, groups, projects, repositories, protected branches, release branches, workflow files, CI/CD configuration paths, repository owners, sensitivity classification, and downstream dependency mapping.

Architecture Layer 2: Workflow and CI/CD Execution Control

Workflow and CI/CD execution control determines whether trusted automation is being changed or executed through expected paths. This layer captures workflow-file changes, pipeline triggers, job execution, runner selection, branch and merge request context, approval rules, CODEOWNERS controls, protected-variable access, artifact use, cache access, and job-token behavior.

Architecture Layer 3: Runner Isolation and Host-Level Monitoring

Runner isolation and host-level monitoring determines whether CI/CD execution remained within expected workflow scope. This layer captures runner inventory, runner tags, runner scope, runner privilege level, Docker socket access, persistent workspace access, process execution, command-line activity, container execution, file access, internal service access, outbound communication, and persistence attempts.

Architecture Layer 4: Automation Identity and Secret Governance

Automation identity and secret governance determines whether suspicious activity affected credentials that connect repositories to downstream systems. This layer captures deploy keys, project tokens, group tokens, personal access tokens, OAuth applications, webhooks, bot accounts, service accounts, workload identities, protected variables, registry credentials, package credentials, cloud credentials, Kubernetes credentials, signing material, and deployment credentials.

Architecture Layer 5: Package, Image, Artifact, and Registry Integrity

Package, image, artifact, and registry integrity determines whether trusted software-delivery outputs remained reliable. This layer captures package publication, package download, image pull, image push, image overwrite, tag creation, release asset modification, artifact upload, artifact download, cache access, build-output staging, signing outputs, and release lineage.

Architecture Layer 6: Downstream Cloud, Kubernetes, and Deployment Monitoring

Downstream cloud, Kubernetes, and deployment monitoring determines whether repository workflow abuse expanded into operational control. This layer captures cloud API activity, Kubernetes API activity, deployment-platform actions, infrastructure-as-code execution, service-principal use, workload identity use, secret-manager access, role changes, production deployment actions, and environment modifications tied to CI/CD credentials or runner lineage.

Architecture Layer 7: SOC Correlation and Software-Delivery Trust Restoration Workflow

SOC correlation joins repository-control activity with workflow execution, runner behavior, credential activity, registry and artifact activity, network behavior, downstream control-plane activity, change-control records, and incident-response evidence. The response workflow requires repository validation, workflow validation, runner containment, token and secret review, deploy-key and webhook review, package and image validation, artifact review, cloud and Kubernetes scoping, deployment rollback analysis, and software-delivery trust restoration.

Architecture Outcome

The architecture should enable the organization to answer five questions during an incident:

·        Did suspicious activity affect a repository, workflow, token, deploy key, webhook, OAuth application, runner, or CI/CD configuration path?

·        Did the activity align with an approved actor, repository owner, branch, workflow, release window, runner scope, or change-control record?

·        Did the activity result in trusted runner execution, credential exposure, artifact access, package activity, image activity, registry access, or outbound communication?

·        Did the activity lead to cloud API use, Kubernetes API use, infrastructure-as-code execution, deployment activity, production workload impact, package manipulation, image manipulation, artifact tampering, or customer-facing release exposure?

·        Can repository integrity, runner trust, automation credential scope, package lineage, image integrity, artifact integrity, deployment behavior, and downstream environment trust be restored with confidence before affected systems return to normal operation?

S35 — Defensive Control Mapping Matrix

Preventive Controls

·        Self-hosted Git platform hardening.

·        Sensitive repository classification.

·        Protected-branch enforcement.

·        Required review and approval governance.

·        CODEOWNERS enforcement.

·        Workflow change governance.

·        CI/CD configuration change governance.

·        Runner inventory and ownership governance.

·        Runner segmentation by sensitivity and environment.

·        Restricted privileged runner use.

·        Restricted Docker socket access.

·        Ephemeral runner adoption for sensitive workflows where feasible.

·        Least-privilege deploy-key governance.

·        Least-privilege token governance.

·        OAuth application governance.

·        Webhook governance.

·        Protected-variable scoping.

·        Secret-store access restriction.

·        Package registry access restriction.

·        Container registry access restriction.

·        Signing material protection.

·        Cloud credential minimization.

·        Kubernetes credential minimization.

·        Deployment credential minimization.

·        Change-control governance for release, package, image, artifact, cloud, Kubernetes, and deployment activity.

Detective Controls

·        Git audit log monitoring.

·        Workflow-file change monitoring.

·        Protected-branch change monitoring.

·        Deploy-key creation monitoring.

·        Token creation and token-scope monitoring.

·        Webhook modification monitoring.

·        OAuth application activity monitoring.

·        Runner registration monitoring.

·        Runner tag and runner scope monitoring.

·        CI/CD pipeline execution monitoring.

·        Protected-variable access monitoring.

·        Runner process and command-line monitoring.

·        Runner outbound communication monitoring.

·        Runner east-west access monitoring.

·        Secret-store access monitoring.

·        Package publication monitoring.

·        Image push and image overwrite monitoring.

·        Artifact access and release asset monitoring.

·        Registry authentication monitoring.

·        Cloud API activity monitoring.

·        Kubernetes API activity monitoring.

·        Deployment-platform activity monitoring.

·        Infrastructure-as-code execution monitoring.

·        Multi-signal repository-to-runner-to-downstream correlation.

Responsive Controls

·        Suspicious account containment.

·        Token revocation.

·        Secret rotation.

·        Deploy-key removal.

·        Webhook removal.

·        OAuth application removal.

·        Service-account suspension.

·        Workload identity review.

·        Runner quarantine.

·        Runner rebuild.

·        Workflow rollback.

·        Protected-branch restoration.

·        Package rollback.

·        Image rollback.

·        Artifact invalidation.

·        Release asset review.

·        Registry credential rotation.

·        Cloud credential rotation.

·        Kubernetes credential rotation.

·        Cloud and Kubernetes containment.

·        Deployment rollback.

·        Production exposure scoping.

·        Customer-facing release review where required.

·        Software-delivery trust restoration before return to normal operation.

Governance Controls

·        Approved self-hosted Git platform inventory.

·        Approved repository inventory.

·        Approved sensitive repository classification.

·        Approved workflow inventory.

·        Approved CI/CD runner inventory.

·        Approved runner tag and runner scope inventory.

·        Approved deploy-key inventory.

·        Approved token inventory.

·        Approved webhook inventory.

·        Approved OAuth application inventory.

·        Approved service-account and workload-identity inventory.

·        Approved package registry inventory.

·        Approved container registry inventory.

·        Approved artifact-store inventory.

·        Approved cloud account mapping.

·        Approved Kubernetes cluster mapping.

·        Approved deployment path inventory.

·        Change-control records for repository, workflow, runner, token, webhook, package, image, artifact, cloud, Kubernetes, and deployment changes.

·        Executive reporting for high-risk software-delivery control-plane events.

·        Risk-register tracking for repository workflow abuse and software-delivery trust exposure.

Control Mapping Summary

The strongest control posture combines prevention of unauthorized repository and workflow changes, detection of suspicious runner and automation identity activity, and response workflows that restore software-delivery trust. Controls should be prioritized for sensitive repositories, privileged workflows, CI/CD runners, automation credentials, protected variables, package registries, container registries, artifact stores, cloud accounts, Kubernetes clusters, deployment platforms, and customer-facing release paths.

S36 — CyberDax Intelligence Maturity Assessment

Current Intelligence Maturity

Moderate

Maturity Rationale

Self-hosted Git platform compromise through repository workflow abuse is a well-defined behavior class, but organization-specific maturity depends on whether repository-control activity can be correlated with workflow execution, runner behavior, credential activity, registry and artifact events, network telemetry, cloud or Kubernetes activity, asset context, and change-management evidence. Many environments can identify repository changes or CI/CD job activity, but fewer can reconstruct whether suspicious workflow activity affected protected variables, automation credentials, packages, images, artifacts, deployment paths, cloud access, Kubernetes access, or production-adjacent systems.

Strengths

·        The behavior pattern is durable because it focuses on software-delivery trust impact rather than one CVE, exploit string, repository name, workflow filename, runner host, package name, image tag, domain, IP address, event ID, or malware artifact.

·        The core sequence is analytically clear: repository-control access, workflow or automation modification, trusted CI/CD runner execution, credential or build-output exposure, registry or deployment interaction, and downstream control-plane activity tied to CI/CD lineage.

·        Detection opportunities are strong where Git audit logs, CI/CD logs, runner telemetry, endpoint telemetry, network telemetry, identity logs, registry logs, package logs, artifact logs, cloud logs, Kubernetes logs, deployment logs, asset inventory, and change-management records can be correlated.

·        Defensive controls can be mapped directly to repository governance, workflow control, runner segmentation, automation identity hardening, protected-variable scoping, package and image integrity, registry monitoring, deployment governance, cloud and Kubernetes scoping, and trust restoration.

·        S17 TTP coverage remains lean while still capturing the core operational chain.

Maturity Gaps

·        Git audit logs may not retain enough detail about workflow-file changes, deploy-key creation, token creation, webhook changes, OAuth application activity, runner registration, protected-branch changes, or administrative actions.

·        CI/CD logs may not preserve command-line detail, protected-variable behavior, job-token context, runner assignment, artifact access, cache use, or pipeline-triggering identity.

·        Runner hosts may lack EDR, process telemetry, command-line capture, file telemetry, container runtime telemetry, Docker socket visibility, or outbound network visibility.

·        Shared or persistent runners may obscure which repository, workflow, job, token, or actor caused suspicious execution.

·        Registry, package, image, artifact, and release logs may not preserve object lineage, token identity, source IP, runner context, repository association, or package and image version context.

·        Identity telemetry may not capture token lifecycle events, service-account activity, bot-account use, OAuth application activity, MFA context, device context, source network, or privilege changes.

·        Cloud and Kubernetes logs may not clearly connect API activity to CI/CD credentials, workload identities, service principals, runner hosts, repository events, or pipeline timing.

·        Change-management records may not reliably explain workflow refactoring, runner migration, package publication, image publication, registry maintenance, artifact retention, cloud deployment, Kubernetes deployment, or incident-response activity.

·        Organizations may over-rely on isolated Git events, pipeline failures, registry activity, cloud alerts, or IOCs rather than validating the full software-delivery sequence.

Maturity Improvement Priorities

·        Normalize Git audit logs, CI/CD logs, runner telemetry, endpoint telemetry, network telemetry, identity logs, registry logs, package logs, artifact logs, cloud logs, Kubernetes logs, deployment logs, and SIEM telemetry.

·        Improve repository inventory, sensitive repository classification, runner inventory, runner tag mapping, runner scope mapping, automation identity mapping, package registry inventory, container registry inventory, artifact-store inventory, cloud account mapping, Kubernetes cluster mapping, and deployment path mapping.

·        Improve visibility into workflow-file changes, protected-branch changes, token creation, deploy-key changes, webhook changes, OAuth application activity, runner registration, runner tag changes, protected-variable access, artifact access, registry activity, and downstream deployment activity.

·        Improve auditing for package publication, image push, image overwrite, release artifact modification, cache access, signing material access, infrastructure-as-code execution, cloud API use, Kubernetes API use, and deployment actions.

·        Improve privileged maintainer, repository administrator, CI/CD administrator, service-account, bot-account, workload-identity, dormant-account, newly privileged account, and low-frequency high-privilege account baselines.

·        Improve correlation between suspicious repository workflow activity and downstream endpoint, network, registry, package, image, artifact, cloud, Kubernetes, deployment, and production access.

·        Add repository workflow abuse and software-delivery trust validation steps to SOC and incident-response playbooks.

Maturity Outlook

Maturity can improve quickly if the organization prioritizes software-delivery lineage and repository-to-runner-to-downstream correlation. The highest-value improvements are Git and CI/CD telemetry normalization, runner instrumentation, automation identity mapping, protected-variable scoping, registry and package lineage, cloud and Kubernetes identity mapping, change-control validation, and integrated SOC, DevOps, platform engineering, cloud, Kubernetes, and application-owner response workflows.

S37 — Strategic Defensive Improvements

Strategic improvement should reduce the likelihood that attackers can abuse repository workflow paths without detection and reduce the response burden when software-delivery trust cannot be validated quickly. The objective is measurable software-delivery trust, not Git or CI/CD hardening alone.

Priority 1: Establish Software-Delivery Trust Assurance as a Security Metric

·        Define measurable assurance metrics for sensitive repository inventory, workflow governance, runner segmentation, automation credential scope, protected-variable access, package lineage, image integrity, artifact integrity, deployment authority, cloud identity use, Kubernetes identity use, and downstream exposure.

·        Track trust-assurance completeness for sensitive repositories, privileged workflows, production deployment paths, signing workflows, package-publishing workflows, image-publishing workflows, infrastructure-as-code repositories, automation identities, and runners with downstream access.

·        Report unresolved software-delivery trust gaps as control-plane risks.

·        Treat unexplained workflow changes, automation credential changes, runner changes, or package and image changes near suspicious CI/CD activity as executive-relevant control failures.

Priority 2: Harden Repository and Workflow Governance

·        Maintain a live inventory of self-hosted Git platforms, groups, projects, repositories, protected branches, workflow files, CI/CD configuration paths, release branches, workflow owners, repository owners, and downstream dependency mappings.

·        Classify repositories by production deployment access, package-publication authority, image-publication authority, signing authority, infrastructure-as-code control, cloud access, Kubernetes access, secret access, regulated data exposure, and business-critical application ownership.

·        Require change-control evidence for workflow-file changes, protected-branch changes, approval-rule changes, CODEOWNERS changes, release-control changes, and CI/CD configuration changes affecting sensitive repositories.

·        Reduce unmanaged, unknown, broadly accessible, or poorly governed workflow paths.

Priority 3: Strengthen Runner and Automation Identity Governance

·        Reduce standing privilege for CI/CD runners, automation accounts, service accounts, bot accounts, deployment identities, workload identities, package-publishing identities, image-publishing identities, cloud identities, Kubernetes identities, and low-frequency high-privilege accounts.

·        Segment runners by repository class, workflow type, environment, network access, credential exposure, and deployment authority.

·        Restrict protected variables, deployment credentials, registry credentials, package credentials, signing material, cloud credentials, and Kubernetes credentials to approved workflows, branches, environments, repositories, and runner scopes.

·        Review administrative workflows for runner registration, runner migration, token creation, deploy-key creation, webhook modification, OAuth application onboarding, package publication, image publication, cloud deployment, Kubernetes deployment, security testing, and incident response.

Priority 4: Improve Software-Delivery Telemetry and Correlation

·        Improve telemetry that links Git audit activity, CI/CD pipeline execution, runner process activity, endpoint telemetry, token lifecycle events, registry activity, package activity, artifact activity, network egress, cloud activity, Kubernetes activity, deployment activity, and change-control records.

·        Baseline normal workflow changes, runner selection, token creation, deploy-key creation, webhook changes, OAuth application activity, package publication, image pushes, artifact access, outbound destinations, deployment actions, cloud API activity, and Kubernetes API activity.

·        Prioritize detection for suspicious repository-control activity followed by workflow execution, credential access, outbound communication, registry access, package activity, image activity, artifact activity, deployment activity, cloud API use, or Kubernetes API use.

·        Validate timestamp normalization, field mapping, lookup accuracy, schema mapping, enrichment quality, and SIEM correlation before promoting hunt logic into alerting.

Priority 5: Improve Package, Image, Artifact, Cloud, and Kubernetes Exposure Correlation

·        Correlate suspicious repository workflow activity with package publication, image push, image overwrite, release artifact modification, artifact download, cache access, deployment-platform activity, cloud API use, Kubernetes API use, infrastructure-as-code execution, secret access, and production changes.

·        Monitor privileged cloud and Kubernetes actions after suspicious repository, workflow, runner, or automation identity activity, including role changes, access-key creation, service-account changes, workload identity changes, secret access, deployment controller changes, image-pull secret changes, and infrastructure modification.

·        Treat downstream package, image, artifact, cloud, Kubernetes, and deployment activity as investigative leads unless linked to suspicious repository or CI/CD evidence.

·        Build incident-response workflows that scope software-delivery control-plane impact across build, release, cloud, Kubernetes, registry, package, artifact, and production systems.

Priority 6: Strengthen SOC and DevOps Response to Software-Delivery Trust Failure

·        Create or update playbooks for suspicious workflow modification, runner compromise, automation credential exposure, protected-variable access, registry abuse, package manipulation, image manipulation, artifact tampering, deployment compromise, cloud-control-plane activity, and Kubernetes-control-plane activity.

·        Require responders to validate actor identity, repository sensitivity, workflow change context, runner execution, protected-variable access, credential exposure, outbound communication, registry activity, package activity, image activity, artifact activity, cloud activity, Kubernetes activity, deployment activity, and change-management context.

·        Require rapid account containment, token revocation, secret rotation, deploy-key removal, webhook removal, OAuth application removal, runner quarantine, package validation, image validation, artifact validation, cloud scoping, Kubernetes scoping, deployment rollback analysis, and customer-facing release review where required.

·        Require software-delivery trust restoration before affected workflows, runners, credentials, packages, images, artifacts, deployment paths, cloud identities, Kubernetes identities, or production release paths return to normal operation.

Strategic Outcome

The organization should be able to prove whether suspicious repository workflow activity affected trusted software delivery, detect when repository-to-runner-to-downstream evidence does not reconcile, scope package, image, artifact, cloud, Kubernetes, deployment, and production exposure with confidence, and restore software-delivery trust before attackers convert repository workflow abuse into broader enterprise disruption.

S38 — Attack Economics & Organizational Impact Model

Self-hosted Git platform compromise through repository workflow abuse changes the economics of intrusion by allowing adversaries to pursue control over trusted software-delivery paths instead of compromising each downstream system individually. When suspicious repository, workflow, CI/CD, runner, credential, registry, package, image, artifact, cloud, Kubernetes, or deployment activity can affect build outputs, release artifacts, automation identities, protected variables, or downstream production access, the attacker can increase operational leverage while forcing defenders to validate whether the software-delivery control plane remained trustworthy.

Adversary Economic Advantage

·        Repository workflow abuse can reduce attacker friction because downstream systems may already trust CI/CD pipelines, runner identities, package outputs, container images, release artifacts, deployment credentials, and automation identities.

·        CI/CD runner abuse can allow attacker-controlled or unauthorized logic to execute inside environments that may have access to protected variables, artifacts, registries, package systems, cloud credentials, Kubernetes credentials, or deployment paths.

·        Automation credential exposure can shift attacker effort from broad endpoint compromise to targeted abuse of trusted tokens, deploy keys, webhooks, OAuth applications, service accounts, workload identities, and deployment identities.

·        Registry, package, image, and artifact abuse can create downstream leverage because dependent systems may consume build outputs as trusted software-delivery material.

·        Suspicious activity can blend with legitimate workflow refactoring, release engineering, runner migration, package publication, image publication, dependency updates, infrastructure deployment, security testing, or incident-response activity.

·        A single affected repository, workflow, runner, token, registry path, package-publishing workflow, image-publishing workflow, signing workflow, infrastructure-as-code workflow, or deployment workflow can create disproportionate leverage when it supports production release, cloud deployment, Kubernetes deployment, or customer-facing software.

·        The attacker benefits when defenders cannot quickly determine whether repository integrity, workflow logic, runner execution, protected variables, automation credentials, package lineage, image integrity, artifact integrity, deployment behavior, cloud identity use, or Kubernetes identity use remained intact.

Defender Cost Expansion

·        The organization must investigate both the suspicious repository workflow activity and the integrity of the software-delivery control plane.

·        Response teams may need to reconstruct Git audit events, CI/CD pipeline execution, runner host activity, command-line behavior, identity and token activity, registry access, package activity, image activity, artifact activity, network egress, cloud activity, Kubernetes activity, deployment activity, and change-management evidence.

·        Token revocation, secret rotation, deploy-key removal, webhook removal, OAuth application removal, service-account review, workload-identity review, runner quarantine, package validation, image validation, artifact review, cloud scoping, Kubernetes scoping, and deployment rollback may be required even when ransomware or confirmed data theft is not proven.

·        Internal exposure scoping may be required across source-code systems, CI/CD infrastructure, runners, registries, package services, artifact stores, build caches, deployment systems, cloud accounts, Kubernetes clusters, secret stores, identity providers, databases, file stores, and sensitive business applications.

·        Response cost increases when Git audit logs, CI/CD logs, runner telemetry, endpoint telemetry, registry logs, package logs, artifact logs, network telemetry, identity logs, cloud logs, Kubernetes logs, deployment logs, asset inventory, automation identity mapping, change-control records, or timestamp normalization are incomplete.

·        High-value software-delivery dependencies create disproportionate exposure because one suspicious workflow or runner trust event can expand scoping requirements across build, release, deployment, cloud, Kubernetes, package, image, artifact, and production environments.

Organizational Impact Model

Software-Delivery Control-Plane Impact

The organization must determine whether repository integrity, workflow logic, CI/CD execution, runner trust, automation credential scope, protected variables, package outputs, container images, release artifacts, and deployment paths remained reliable.

Automation Identity Impact

The organization must determine whether suspicious activity affected deploy keys, project tokens, group tokens, personal access tokens, OAuth applications, webhooks, bot accounts, service accounts, workload identities, deployment identities, registry credentials, package credentials, cloud credentials, Kubernetes credentials, or signing material.

Build and Release Integrity Impact

The organization must determine whether suspicious workflow or runner activity altered packages, images, release assets, build artifacts, caches, signing outputs, deployment manifests, infrastructure templates, or customer-consumed software-delivery material.

Downstream Control-Plane Impact

The organization must determine whether suspicious repository workflow activity enabled cloud API use, Kubernetes API use, deployment-platform activity, infrastructure-as-code execution, secret-manager access, role changes, production deployment, data access, ransomware staging, or extortion.

Recovery Impact

The organization must restore software-delivery trust through repository validation, workflow review, runner containment, token and secret review, package and image validation, artifact review, registry credential review, cloud and Kubernetes scoping, deployment rollback analysis, and production-release assurance.

Governance Impact

Leadership may need to treat confirmed or strongly suspected repository workflow abuse as an executive incident because self-hosted Git and CI/CD systems govern how software is built, packaged, released, deployed, and trusted by downstream business systems.

Economic Impact Summary

Self-hosted Git platform compromise through repository workflow abuse is economically powerful for adversaries because it can convert repository or workflow influence into trusted execution, credential exposure, package or image manipulation, deployment access, and downstream control-plane leverage. The organization’s financial exposure grows when it cannot quickly prove whether repository integrity, runner trust, automation credentials, packages, images, artifacts, deployment paths, cloud identities, Kubernetes identities, and production release behavior remained intact.

S39 — Economic Impact & Organizational Exposure

Figure 7

Self-hosted Git platform compromise through repository workflow abuse creates organizational exposure by increasing uncertainty around software-delivery integrity, trusted CI/CD execution, automation credentials, protected variables, registry outputs, package lineage, image integrity, artifact integrity, deployment behavior, cloud identity use, Kubernetes identity use, and production-release trust. Exposure rises when suspicious activity involves sensitive repositories, privileged workflows, protected branches, CI/CD runners, deploy keys, broad-scope tokens, webhooks, OAuth applications, package registries, container registries, artifact stores, cloud accounts, Kubernetes clusters, deployment systems, or customer-facing release paths.

Estimated Economic Exposure

Estimated exposure should be treated as scenario-based rather than fixed. The most defensible enterprise estimate is tied to whether the activity remains attempted workflow abuse or isolated suspicious CI/CD behavior, becomes confirmed or strongly suspected software-delivery control-plane compromise, or expands into automation credential misuse, protected-variable exposure, package manipulation, image manipulation, artifact tampering, cloud or Kubernetes control-plane activity, production deployment impact, customer-facing release exposure, ransomware staging, extortion, or broad software-delivery trust restoration.

Low Impact Scenario

Estimated $750K – $3.5M.

This scenario applies when suspicious repository workflow activity is detected quickly, no protected variables or secrets are confirmed exposed, no unauthorized package or image publication occurs, no release artifact is modified, no downstream cloud or Kubernetes activity is observed, no production deployment is affected, and telemetry is sufficient to validate the repository-to-runner activity path quickly.

Moderate Impact Scenario

Estimated $6M – $25M.

This scenario applies when confirmed or strongly suspected repository workflow abuse, runner misuse, protected-variable exposure, automation credential misuse, registry access, artifact access, package activity, image activity, or deployment uncertainty requires the organization to treat the event as a software-delivery control-plane incident even without confirmed ransomware, confirmed data theft, confirmed customer impact, or full production compromise. Response may require repository and workflow review, CI/CD pipeline reconstruction, runner isolation, token and secret rotation, deploy-key and webhook validation, package and container registry review, artifact integrity validation, cloud and Kubernetes identity scoping, deployment review, SOC surge activity, change-management validation, legal and executive reporting, and downstream validation of production, cloud, Kubernetes, source-code, package, image, artifact, and release environments.

High Impact Scenario

Estimated $30M – $125M+.

This scenario applies when repository workflow abuse becomes an enterprise-impact pathway involving malicious build execution, credential theft, trusted package or image manipulation, release artifact replacement, production deployment compromise, cloud or Kubernetes control-plane abuse, customer-facing software impact, data theft, extortion, ransomware staging, or broad loss of confidence in software-delivery integrity. The upper range applies only when the organization must halt or roll back releases, validate or rebuild CI/CD infrastructure, rotate high-risk automation credentials at scale, verify package and image integrity, review customer-consumed artifacts, contain cloud or Kubernetes changes, restore production systems affected through the compromised software-delivery path, or support customer, regulatory, legal, cyber-insurance, and board-level response.

Annualized Risk Exposure

Estimated $6M – $30M+ for materially exposed enterprise environments with self-hosted Git dependency, broad CI/CD runner access, sensitive repository exposure, incomplete Git or CI/CD telemetry, privileged automation identity exposure, weak runner segmentation, limited package or image lineage, incomplete change-management validation, or high downstream dependency on automated deployment paths. Exposure may exceed $50M – $125M+ where confirmed software-delivery compromise requires enterprise-scale credential rotation, CI/CD rebuild, package or image integrity validation, customer-facing release review, production rollback, cloud or Kubernetes containment, regulatory response, customer notification, extortion response, or restoration of business-critical systems affected through the compromised software-delivery path.

Operational Dependency

Operational dependency is high where self-hosted Git platforms and CI/CD systems support source-code control, workflow execution, protected-variable access, package publication, image publication, artifact generation, deployment automation, infrastructure-as-code, cloud deployment, Kubernetes deployment, customer-facing software, and business-critical application release paths. Dependency increases when repository workflow integrity is required for recovery operations, privileged access, regulated systems, production continuity, or customer assurance.

Control Trust

Control trust is reduced when the organization cannot prove that repository state, workflow logic, runner execution, protected variables, automation credentials, package lineage, image integrity, artifact integrity, deployment behavior, cloud identity use, Kubernetes identity use, and production release behavior remained intact. Control trust is further reduced when Git audit logs, CI/CD logs, runner telemetry, endpoint telemetry, registry logs, package logs, artifact logs, identity logs, cloud logs, Kubernetes logs, deployment logs, network telemetry, or change-control evidence is incomplete or inconsistent.

Visibility Confidence

Visibility confidence is highest when Git audit logs, CI/CD logs, runner telemetry, endpoint telemetry, network telemetry, identity logs, registry logs, package logs, artifact logs, cloud logs, Kubernetes logs, deployment logs, asset inventory, automation identity mapping, change-control records, and SIEM correlation can be joined reliably. Visibility confidence is reduced where Git audit logging is incomplete, CI/CD retention is short, runner endpoint telemetry is missing, registry or package lineage is weak, cloud or Kubernetes identity mapping is incomplete, timestamps are inconsistent, or asset-role enrichment is weak.

Change-Control Confidence

Change-control confidence is high when workflow changes, runner registration, runner migration, token creation, deploy-key creation, webhook changes, OAuth application onboarding, package publication, image publication, artifact retention, registry maintenance, cloud deployment, Kubernetes deployment, release engineering, security testing, and incident-response actions are documented and attributable. Confidence is reduced when change-control records are incomplete, delayed, inconsistent, or unavailable during suspicious repository workflow review.

Downstream Dependency

Downstream dependency is high when trusted software-delivery paths provide access to package registries, container registries, artifact stores, secret stores, identity providers, deployment systems, cloud accounts, Kubernetes clusters, databases, file stores, customer-facing applications, internal business applications, SaaS integrations, developer platforms, and production environments. These dependencies increase the impact of even a single suspicious repository workflow or runner trust event.

Customer and Regulatory Exposure

Customer and regulatory exposure increases when suspicious repository workflow activity may have affected regulated data, customer-facing software, packages, container images, release artifacts, deployment manifests, cloud environments, Kubernetes clusters, secret stores, or business-critical applications. Exposure also increases when incomplete telemetry prevents timely confirmation of whether sensitive systems were accessed, whether build outputs were altered, whether data was exposed, or whether downstream compromise occurred.

Residual Economic Risk

Residual economic risk remains after containment if the organization cannot prove that repository integrity was restored, workflow logic was validated, runners were contained or rebuilt, tokens and secrets were rotated or validated, deploy keys and webhooks were reviewed, package and image lineage was verified, artifacts were validated, cloud and Kubernetes access was scoped, deployment paths were reviewed, and production release trust was restored. Residual risk is highest where Git audit evidence, CI/CD logs, runner telemetry, registry logs, package logs, artifact logs, endpoint telemetry, network telemetry, cloud logs, Kubernetes logs, deployment logs, or change-control evidence are incomplete.

Proof-of-Concept Behavioral Coverage Assessment

This assessment is anchored to the self-hosted Git platform workflow-abuse behavior class rather than a single vulnerability. The coverage model is designed to show how the same detection strategy can remain relevant when different CVEs, proof-of-concept paths, or platform-specific weaknesses produce the same operational outcomes: suspicious repository-control activity, unauthorized workflow execution, CI/CD runner misuse, protected-variable exposure, automation credential abuse, registry access, package or image manipulation, artifact exposure, deployment activity, cloud API use, Kubernetes API use, or downstream production-adjacent impact.

The model should not be read as universal exploit detection, universal Git-platform coverage, or universal zero-day prevention. It demonstrates coverage when a known CVE, new proof-of-concept, or future vulnerability produces observable repository, workflow, runner, credential, registry, package, artifact, network, cloud, Kubernetes, deployment, or production-release trust anomalies.

CVE / Proof-of-Concept Behavioral Coverage Scope

This assessment applies to CVEs and proof-of-concept activity that can affect repository workflow trust, CI/CD execution identity, automation credentials, protected variables, deploy keys, webhooks, OAuth applications, package registries, container registries, artifacts, images, deployment systems, or downstream control-plane activity. CVEs that affect unrelated application features, availability-only behavior, or non-software-delivery paths should not be counted as direct coverage unless observed activity links them to the repository-to-runner-to-downstream behavior chain.

Detection Engineering Coverage Interpretation

Coverage is strongest when proof-of-concept or exploit activity results in observable workflow changes, unauthorized pipeline execution, runner activity, protected-variable access, CI/CD variable exposure, token or deploy-key activity, webhook modification, OAuth application activity, registry access, package publication, image pull or push, artifact access, outbound runner communication, cloud API use, Kubernetes API use, deployment activity, or software-delivery output manipulation. Coverage is weaker when exploit activity produces no observable difference in Git audit logs, CI/CD logs, runner telemetry, endpoint telemetry, identity logs, registry logs, package logs, artifact logs, network telemetry, cloud logs, Kubernetes logs, deployment logs, or SIEM telemetry.

Direct Coverage

Direct behavioral coverage applies to the following CVEs when exploitation or abuse produces observable unauthorized workflow execution, CI/CD identity misuse, protected-variable exposure, registry exposure, package or image activity, artifact exposure, or software-delivery trust impact:

·        CVE-2024-5655 — GitLab pipeline execution as another user. This is directly covered when activity results in unauthorized pipeline execution, CI/CD identity misuse, protected-variable access, runner execution, artifact access, registry access, or downstream deployment activity.

·        CVE-2024-6385 — GitLab arbitrary pipeline job execution as another user. This is directly covered when activity results in unauthorized pipeline execution, CI/CD job execution under another user context, protected-variable access, runner misuse, package or image activity, or deployment-path exposure.

·        CVE-2024-8970 — GitLab pipeline triggering as another user under specific import-related conditions. This is directly covered when exploitation produces unauthorized pipeline execution, CI/CD runtime identity mismatch, sensitive workflow execution, protected-variable exposure, or downstream automation identity use.

·        CVE-2024-11931 — GitLab protected CI/CD variable exposure through CI lint. This is directly covered when activity produces protected-variable exposure, CI/CD secret exposure, suspicious CI lint use, automation credential access, or follow-on token, registry, cloud, Kubernetes, or deployment activity.

·        CVE-2026-4868 — GitLab Duo AI workflow runners executing under another user identity. This is directly covered when activity produces unauthorized workflow-runner execution, identity mismatch, privileged CI/CD execution context, protected-variable access, automation credential exposure, or downstream software-delivery activity.

·        CVE-2026-27771 — Gitea / Forgejo private container image exposure through container registry behavior. This is directly covered for registry, image, package, and artifact exposure when activity produces private image access, registry authentication anomalies, unexpected image pulls, exposed build outputs, or downstream software-delivery trust impact.

Coverage With Adaptation

Coverage with adaptation applies to related Git platform, CI/CD, registry, package, artifact, approval, token, OAuth, deployment-data, or repository-governance vulnerabilities where the local incident shows software-delivery control-plane behavior that can be linked to repository workflow abuse, credential exposure, registry activity, package activity, artifact access, deployment activity, or downstream control-plane activity.

·        CVE-2024-5470 — GitLab custom-role deploy token creation issue. This is covered with adaptation when activity involves unexpected deploy token creation, token scope expansion, sensitive repository access, registry access, package access, or downstream automation identity use.

·        CVE-2024-6595 — GitLab package registry manifest confusion. This is covered with adaptation for package registry integrity, package metadata manipulation, package publication validation, and downstream package trust triage, but it should not be counted as direct workflow compromise unless linked to repository or CI/CD activity.

·        CVE-2024-3959 — GitLab private job artifact access exposure. This is covered with adaptation when activity involves private artifact access, artifact download, CI/CD output exposure, sensitive build-log exposure, or follow-on registry, package, cloud, Kubernetes, or deployment activity.

·        CVE-2024-5430 — GitLab merge request approval policy bypass by project maintainers. This is covered with adaptation when activity affects workflow governance, approval rules, protected branch controls, release controls, or sensitive repository change validation.

·        CVE-2024-4994 — GitLab GraphQL CSRF leading to arbitrary GraphQL mutations. This is covered with adaptation when activity results in repository setting changes, permission changes, workflow changes, token changes, webhook changes, OAuth application changes, or automation control changes.

·        CVE-2024-2177 — GitLab OAuth flow abuse through cross-window forgery. This is covered with adaptation when activity affects OAuth application trust, account linkage, token access, integration abuse, or downstream automation identity use.

·        CVE-2024-6323 — GitLab private repository content exposure through global search authorization weakness. This is covered with adaptation for repository exposure and sensitive code scoping, but it should not be counted as direct workflow or CI/CD compromise unless follow-on repository-control, workflow, runner, or automation identity behavior is observed.

·        CVE-2026-8716 — GitLab CI data access from a different ref type than intended. This is covered with adaptation when activity exposes CI data, pipeline context, workflow context, branch or ref-sensitive CI information, or follow-on credential, artifact, registry, package, deployment, or downstream activity.

·        CVE-2026-2710 — GitLab blocked project access token continuing to access private resources. This is covered with adaptation when activity involves token authorization failure, continued private-resource access, repository access, package or registry access, artifact access, or downstream automation identity use.

·        CVE-2026-2601 — GitLab sensitive deployment data exposure through operations authorization weakness. This is covered with adaptation when activity exposes deployment context, environment data, deployment metadata, production release information, cloud or Kubernetes deployment information, or follow-on deployment-path abuse.

·        CVE-2026-5296 — GitLab Duo Workflows restriction bypass under group-level foundational flow conditions. This is covered with adaptation when activity affects workflow governance, automated execution scope, group-level workflow restrictions, automation identity behavior, or downstream software-delivery execution.

Limited / Non-Direct Coverage

Limited or non-direct coverage applies where a CVE affects the self-hosted Git platform but does not directly affect workflow execution, CI/CD runtime identity, protected variables, deploy keys, webhooks, OAuth application trust, package or registry integrity, artifact access, deployment data, or downstream software-delivery behavior.

·        CVE-2021-22205 — GitLab remote code execution through ExifTool image parsing is relevant to self-managed GitLab exposure, but it is not direct coverage for this report unless exploitation leads to repository-control activity, workflow modification, runner misuse, credential access, registry activity, artifact access, or downstream deployment behavior.

·        Availability-only Git platform vulnerabilities should not be counted as direct coverage unless they are paired with suspicious repository-control, workflow-execution, credential-access, registry, package, artifact, cloud, Kubernetes, deployment, or incident-response evidence.

·        General Git platform information disclosure should remain limited coverage unless the exposed data materially supports repository workflow abuse, secret exposure, package or image manipulation, or downstream control-plane activity.

·        General package, dependency, or container vulnerabilities should remain outside this report unless incident evidence links them to self-hosted Git platform workflow abuse or software-delivery control-plane compromise.

·        Cloud, Kubernetes, or deployment vulnerabilities should remain outside this report unless activity can be tied back to CI/CD credentials, runners, workflows, repositories, pipeline timing, automation identities, or incident-response evidence.

Direct Coverage Conditions

Direct coverage applies when proof-of-concept or exploit activity produces one or more of the following behaviors:

·        Unauthorized workflow or CI/CD pipeline execution.

·        Pipeline execution under an unexpected user, token, service account, job identity, or automation identity.

·        Protected-variable exposure or CI/CD secret exposure.

·        Suspicious CI lint, workflow evaluation, job-token, or variable-access behavior.

·        Workflow-runner execution under an unexpected user or automation identity.

·        Runner execution from unusual repository, branch, merge request, job, project, token, or actor context.

·        Deploy-key creation, token creation, webhook modification, OAuth application activity, service-account activity, or workload-identity activity tied to suspicious repository or CI/CD behavior.

·        Private job artifact access, release artifact access, cache exposure, package retrieval, registry access, image pull, image push, image overwrite, or package publication following suspicious repository or workflow activity.

·        Outbound runner communication, source bundle movement, artifact transfer, package transfer, image transfer, credential transfer, or unusual external staging.

·        Cloud API activity, Kubernetes API activity, infrastructure-as-code execution, or deployment-platform activity tied to CI/CD identity, runner, repository, workflow, pipeline, or credential lineage.

·        Production deployment, customer-facing release impact, data access, ransomware staging, or extortion following suspicious software-delivery control-plane activity.

Coverage With Adaptation Conditions

Coverage with adaptation applies when activity uses a novel exploit mechanism, altered workflow path, CI/CD feature abuse, unusual API path, changed request pattern, compromised maintainer account, abused automation identity, registry weakness, package metadata issue, artifact exposure, OAuth flow abuse, permission-model flaw, deployment-data exposure, project-token issue, or adjacent Git platform vulnerability but still creates repository, workflow, runner, identity, registry, package, artifact, network, cloud, Kubernetes, deployment, or downstream anomalies. Adaptation may require local tuning for Git audit event names, CI/CD event fields, runner identifiers, token schemas, deploy-key records, webhook records, OAuth application logs, registry fields, package fields, artifact fields, network telemetry, cloud identity mappings, Kubernetes audit fields, timing windows, repository sensitivity inventory, change-control records, and exception lists.

Non-Coverage Conditions

Non-coverage applies when activity does not create observable repository, workflow, runner, identity, credential, registry, package, artifact, network, cloud, Kubernetes, deployment, or downstream differences in available telemetry. This includes scenarios where:

·        The attacker uses valid credentials and approved engineering systems with no suspicious repository, workflow, runner, credential, registry, package, artifact, cloud, Kubernetes, or deployment behavior.

·        The activity does not interact with self-hosted Git, CI/CD, runner, registry, package, artifact, deployment, cloud, or Kubernetes paths.

·        The activity affects only unrelated application features without software-delivery trust impact.

·        The activity remains limited to scanning, version exposure, patch-state exposure, or vulnerability inventory without exploit-attempt behavior.

·        The activity affects only availability or platform stability without repository-control, workflow-execution, credential-access, registry, package, artifact, cloud, Kubernetes, deployment, or downstream impact.

·        Required Git audit logs, CI/CD logs, runner telemetry, endpoint telemetry, identity logs, registry logs, package logs, artifact logs, network logs, cloud logs, Kubernetes logs, deployment logs, change-control records, or SIEM telemetry are unavailable.

·        Source hosts, users, tokens, runners, repositories, workflows, pipelines, packages, images, artifacts, timestamps, credentials, or downstream sessions cannot be joined reliably.

·        Downstream cloud, Kubernetes, deployment, production, package, image, artifact, or customer-facing activity cannot be linked to suspicious repository workflow behavior.

·        Activity is better explained by approved workflow maintenance, release engineering, runner migration, package publication, image publication, registry maintenance, artifact retention, cloud deployment, Kubernetes deployment, security testing, vulnerability management, or incident response.

Current Coverage Count

Current behavior-led coverage directly supports 6 CVEs where the documented behavior aligns with unauthorized pipeline execution, CI/CD runtime identity misuse, protected-variable exposure, workflow-runner identity misuse, registry exposure, package or image exposure, artifact exposure, or software-delivery control-plane trust impact. The model also supports 11 additional GitLab-related CVEs with adaptation where local activity can be linked to token creation, package registry manipulation, private artifact access, approval-policy bypass, GraphQL mutation abuse, OAuth flow abuse, repository exposure, CI data exposure, project-access-token enforcement failure, deployment-data exposure, workflow restriction bypass, or follow-on software-delivery behavior. One additional GitLab platform RCE example is listed as limited / non-direct coverage because it is relevant to self-managed GitLab exposure but does not become report-covered unless incident evidence links it to repository workflow abuse, CI/CD execution, credential access, registry activity, artifact access, or downstream deployment behavior.

Coverage Qualification

Coverage is strong for behaviorally visible repository workflow abuse and weaker for silent valid-administration abuse where all required Git, CI/CD, runner, identity, registry, package, artifact, network, cloud, Kubernetes, deployment, and change-control evidence appears normal. The report should not claim universal exploit detection, universal self-hosted Git platform coverage, universal CI/CD coverage, universal CVE coverage, or standalone attribution. Detection confidence depends on telemetry completeness, field mapping, local baselines, repository inventory, runner inventory, automation identity mapping, package and image lineage, cloud and Kubernetes identity mapping, change-control records, false-positive testing, query performance testing, and SOC triage readiness.

Zero-Day Coverage Interpretation

The purpose of this S39 coverage model is to show that the detection strategy is not limited to the known exploit mechanics of the listed CVEs. Future zero-day or proof-of-concept activity affecting self-hosted Git platforms, CI/CD workflows, runner assignment, automation credentials, protected variables, package registries, container registries, artifact stores, deployment systems, cloud identity, or Kubernetes identity should still be detectable when it produces the same operational behaviors: suspicious repository-control activity, unauthorized workflow execution, trusted runner execution, credential exposure, artifact access, registry access, package publication, image activity, outbound transfer, cloud API activity, Kubernetes API activity, deployment action, or downstream production impact. The model should not be presented as universal zero-day prevention; it is behavior-led coverage for zero-day activity that becomes visible through the software-delivery control-plane chain.

Executive Exposure Statement

The organization’s economic exposure is highest when self-hosted Git platform compromise or suspected repository workflow abuse creates uncertainty around whether trusted software delivery remained reliable. The strategic risk is not only unauthorized repository access or a CI/CD pipeline anomaly; it is the possibility that attackers can compromise or cast doubt on the systems that build, package, release, deploy, and maintain business-critical software.

S40 — References

Vendor / Platform Documentation

·        GitLab Docs — Critical Patch Release 17.1.1, 17.0.3, 16.11.5 — hxxps://docs[.]gitlab[.]com/releases/patches/patch-release-gitlab-17-1-1-released/

·        GitLab Docs — Critical Patch Release 17.1.2, 17.0.4, 16.11.6 — hxxps://docs[.]gitlab[.]com/releases/patches/patch-release-gitlab-17-1-2-released/

·        GitLab Docs — Patch Release 17.8.1, 17.7.3, 17.6.4 — hxxps://docs[.]gitlab[.]com/releases/patches/patch-release-gitlab-17-8-1-released/

·        GitLab Docs — Patch Release 19.0.1, 18.11.4, 18.10.7 — hxxps://docs[.]gitlab[.]com/releases/patches/patch-release-gitlab-19-0-1-released/

·        GitLab Docs — CI/CD Variables — hxxps://docs[.]gitlab[.]com/ci/variables/

·        GitLab Docs — GitLab Runner — hxxps://docs[.]gitlab[.]com/runner/

·        GitLab Docs — Project Deploy Keys — hxxps://docs[.]gitlab[.]com/user/project/deploy_keys/

·        GitLab Docs — Deploy Tokens — hxxps://docs[.]gitlab[.]com/user/project/deploy_tokens/

·        GitLab Docs — Project Access Tokens — hxxps://docs[.]gitlab[.]com/user/project/settings/project_access_tokens/

·        GitLab Docs — Job Artifacts — hxxps://docs[.]gitlab[.]com/ci/jobs/job_artifacts/

·        GitLab Docs — Container Registry — hxxps://docs[.]gitlab[.]com/user/packages/container_registry/

·        Gitea Blog — Gitea 1.26.2 Release — hxxps://blog[.]gitea[.]com/release-of-1[.]26[.]2/

·        Gitea Documentation — Actions — hxxps://docs[.]gitea[.]com/usage/actions/

·        Forgejo Documentation — Actions — hxxps://forgejo[.]org/docs/latest/user/actions/actions/

Threat Technique Framework

·        MITRE ATT&CK — Enterprise Matrix / Techniques Catalog — hxxps://attack[.]mitre[.]org/

Security Vendor Analysis

·        CISA — Known Exploited Vulnerabilities Catalog — hxxps://www[.]cisa[.]gov/known-exploited-vulnerabilities-catalog

·        NVD — Vulnerability Database / CVE Catalog — hxxps://nvd[.]nist[.]gov/vuln

·        CVE Program — CVE Records — hxxps://www[.]cve[.]org/CVERecord

Threat Tradecraft and Intrusion Patterns

·        NoScope — CVE-2026-27771: NoScope Discovered 30,000+ Gitea Instances Exposing Private Container Images for 4 Years — hxxps://www[.]noscope[.]com/blog/gitea-instances-exposing-private-container