[EXP] Self-Hosted Software-Delivery Control-Plane Compromise and Downstream Trust Risk

Report Type: EXP

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

Assessment Date: June 2, 2026

Amendment Date: September 07, 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

Published by: CyberDax LLC
Author: Edward “Tony” Dolley
Role: Founder / Principal Threat Researcher, CyberDax LLC
Publication Date: July 09, 2026
Publication Type: Cybersecurity Research Report / White Paper

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 software-delivery control-plane platforms, source-code repositories, workflow files, Git hooks, CI/CD pipelines, runners, package and container registries, artifact repositories, credentials, deployment systems, cloud environments, Kubernetes clusters, and downstream systems that depend on trusted software delivery.

• Self-hosted Git, source-code, package-management, registry, and artifact-repository platforms, including Gitea, Forgejo, GitLab-style environments, and self-hosted JFrog Artifactory instances.

• Repository groups, projects, namespaces, protected branches, merge-request paths, release branches, Git hooks, workflow configuration files, local repositories, remote repositories, virtual repositories, build records, artifact metadata, and platform-administration interfaces.

• CI/CD pipelines, job definitions, build scripts, release scripts, deployment scripts, infrastructure-as-code workflows, package- and image-publishing workflows, artifact-promotion paths, repository-replication processes, and signing workflows.

• Self-hosted, shared, persistent, or privileged runners; runner managers, service accounts, workspaces, caches, and hosts with Docker socket access, privileged automation authority, or internal network reach.

• Deploy keys, project and group access tokens, personal access tokens, OAuth applications, webhooks, bot accounts, service accounts, workload identities, deployment identities, package and registry credentials, artifact-repository credentials, cloud credentials, Kubernetes credentials, platform-administration credentials, and signing material.

• Protected variables, environment variables, build-environment properties, secret stores, credential files, build logs, artifacts, caches, package outputs, container images, release assets, deployment manifests, infrastructure templates, repository metadata, and resources accessible to software-delivery platform or automation service accounts.

• Package registries, container registries, artifact repositories, build-cache systems, package mirrors, internal dependency sources, image repositories, object-storage locations, release systems, replication targets, and other trusted software-distribution intermediaries.

• Cloud accounts, cloud APIs, Kubernetes clusters and APIs, deployment controllers, infrastructure-as-code systems, production deployment platforms, secret-management systems, identity providers, signing services, and privileged administration paths tied to repository, registry, artifact, build, release, or CI/CD automation.

• Customer-facing applications, internal business applications, databases, file stores, SaaS integrations, developer platforms, build systems, package consumers, deployment environments, and production systems that consume or depend on trusted source code, packages, images, artifacts, builds, or release outputs.

• Internet-accessible Gitea environments, including instances with open registration, user-controlled repository creation, or ordinary repository write permissions that may allow an external actor to introduce attacker-controlled content, create or replace a Git hook, and execute commands under the Gitea service account.

• Self-hosted Artifactory deployments running affected versions before the applicable fixed release, including environments where repository, artifact, package, build-information, authentication, authorization, API, or server-side request paths are reachable by anonymous, low-privilege, or repository-scoped users under the conditions applicable to the affected vulnerability.

• Artifactory environments with Anonymous Access enabled where that configuration expands access to an affected repository, package, artifact, build-information, API, or server-side request path. Anonymous Access is an exposure condition only for applicable vulnerabilities and should not be treated as a prerequisite for the entire vulnerability set.

• Self-hosted Octopus Server deployments where authenticated users with Environment or Project editing permissions can submit attacker-controlled project or environment content that reaches trusted server-side processing, including affected deployments where crafted JSON can be insecurely deserialized and result in arbitrary code execution in the Octopus Server process.

• Environments where unauthorized access to repository, artifact, package, build-information, authentication, authorization, or server-side request functions could weaken confidence in package integrity, artifact integrity, platform administration, connected services, or downstream developer, CI/CD, deployment, cloud, Kubernetes, and production workflows.

• Environments with incomplete Git, Gitea, Artifactory, Octopus Server, repository, package, build, artifact, deployment, API, authentication, authorization, administrative, service-account, network, or host telemetry; limited file-integrity or command-line visibility; short retention; weak platform ownership; poor automation-identity mapping; or missing change-control records.

• Environments that permit Gitea, Artifactory, Octopus Server, runner, build, or other software-delivery service accounts to reach internal services, secret stores, package mirrors, registries, artifact stores, cloud endpoints, Kubernetes APIs, signing systems, deployment controllers, production networks, or other high-value systems after a software-delivery control-plane trust-boundary failure.

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, authentication, 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, reverse-proxy authentication behavior, trusted-header identity assertion, and downstream cloud or deployment behavior.

The primary detection objective is to identify when an attacker uses trusted development infrastructure or a self-hosted Git authentication boundary to execute unauthorized logic, impersonate a user, 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, registry action, reverse-proxy-authenticated request, or Gitea user session may be benign when observed alone. Detection value increases when those events occur together, originate from unusual identity or network context, affect sensitive repositories, involve unexpected trusted-header identity assertion, or are followed by secret access, outbound communication, artifact manipulation, registry access, administrative changes, 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.

·        Self-hosted Gitea instances using reverse-proxy authentication show trusted-header or proxy-trust anomalies, including spoofed X-WEBAUTH-USER values, unexpected authenticated user context, administrative impersonation, or user activity inconsistent with the source proxy, identity provider, source IP, device, session, or approved reverse-proxy path.

·        Gitea authentication events are followed by repository access, permission changes, token creation, deploy-key creation, webhook modification, workflow activity, package or registry access, or administrative actions by an account that does not match the expected identity, device, source network, reverse-proxy source, or change-control context.

·        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 or suspicious platform-authentication activity.

·        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 platform administration.

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, self-hosted Git administrative paths, reverse-proxy authentication paths, 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 or platform-authentication abuse followed by workflow execution, credential exposure behavior, runner abuse, artifact or registry access, administrative change, 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.

·        Reverse-proxy-authenticated Gitea access, spoofed trusted-header authentication, or unexpected X-WEBAUTH-USER identity assertion followed by repository cloning, privileged permission changes, token creation, deploy-key creation, webhook modification, workflow execution, registry access, package access, or administrative 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, token, trusted-header identity, or reverse-proxy context.

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

·        Cloud, Kubernetes, or deployment-platform activity using CI/CD credentials after suspicious Git, workflow, runner, authentication, or repository-control 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.

·        Gitea reverse-proxy-authenticated user activity where the asserted user, source IP, proxy path, device, session, or identity-provider context is incomplete, unusual, or not clearly attributable.

·        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, authentication, or downstream-control-plane anomalies.

·        Reverse-proxy authentication events without repository-control activity, administrative activity, or identity-lineage mismatch.

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

·        Normal runner scaling, runner replacement, CI/CD migration activity, reverse-proxy maintenance, or authentication infrastructure changes with approved change-control context.

Correlation Strategy

Detection logic must avoid treating a single Git, CI/CD, runner, authentication, proxy, or registry event as confirmed compromise. The required model is multi-signal correlation across platform authentication, 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 or platform-authentication 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, runner registration, reverse-proxy-authenticated access anomaly, spoofed trusted-header identity assertion, unexpected X-WEBAUTH-USER value, or Gitea administrative activity inconsistent with the expected source proxy, identity provider, source IP, device, session, or change-control context.

·        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, unexpected project scope, or suspicious platform-authenticated session.

·        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, registry-token use, or suspicious token creation after anomalous Gitea authentication.

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

·        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 or platform-authentication 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 or platform-admin activity.

Correlation must preserve identity lineage. Analyst review should connect the initiating account, asserted trusted-header identity, reverse-proxy source, identity-provider record, 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 authentication anomalies, repository changes, workflow changes, or permission 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, administrative actions, and authentication events.

·        Gitea authentication logs, reverse-proxy logs, container logs, access logs, and application logs showing authenticated user, asserted trusted-header value, X-WEBAUTH-USER value, source proxy, source IP, request path, user agent, session, administrative action, repository action, and authentication result.

·        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, high-risk egress paths, and reverse-proxy source-path validation.

·        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, user, or platform-authenticated 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, reverse-proxy authentication lineage, and token lifecycle events.

Endpoint telemetry should focus first on runner hosts, Git platform hosts, reverse-proxy 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, release, authentication, and platform administration activity. Self-hosted Git and CI/CD environments are high-change systems, so detections must account for normal merge activity, workflow maintenance, runner scaling, reverse-proxy maintenance, authentication infrastructure changes, 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, suspicious Gitea authentication, trusted-header anomaly, or downstream cloud action.

The detection model should not assume that every reverse-proxy-authenticated Gitea request is malicious. It should require supporting context such as unexpected X-WEBAUTH-USER value, source-proxy mismatch, missing identity-provider event, unusual source IP, administrative action, repository-control action, token creation, deploy-key creation, webhook change, workflow execution, or downstream activity.

The detection model should not assume that every CI/CD job failure, runner error, authentication failure, reverse-proxy error, or pipeline retry indicates compromise. Instability signals are useful only when they align with suspicious repository changes, authentication anomalies, 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, platform-admin activity, 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, repository names, header values, and platform-specific event IDs 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, authentication, reverse-proxy, 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 Gitea reverse-proxy authentication paths, approved proxy source ranges, trusted-header handling, X-WEBAUTH-USER usage, identity-provider linkage, container network exposure, and administrative authentication flows.

·        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, reverse-proxy field mapping, and false-positive review are complete.

High-severity alerting should require confirmed correlation across platform authentication, 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, reverse-proxy authentication designs, and deployment architectures. The detection model should not depend on a single product-specific event name, repository path, workflow filename, CVE identifier, header value, or malicious infrastructure indicator.

Variant-resilient detection should focus on recurring attacker objectives:

·        Gain or abuse repository control.

·        Abuse self-hosted Git platform authentication boundaries, including reverse-proxy trust configuration, trusted-header identity assertion, proxy-authentication assumptions, or source-proxy validation gaps.

·        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, privileged runners, administrative settings, organization memberships, or platform-authentication configuration.

Detection should support platform-specific field mapping for GitLab, Gitea, Forgejo, self-hosted runners, reverse proxies, 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, reverse-proxy authentication paths, Gitea administrative actions, and automation identities with unusual behavior. Medium-confidence detections should alert when suspicious repository-control, platform-authentication, or workflow-execution events occur in sensitive repositories or privileged automation paths. High-confidence detections should alert when suspicious repository, authentication, 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, trusted-header value, reverse-proxy source, identity-provider event, 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, authentication, administrative action, or runner behavior expected under an approved change or release process?

·        Did Gitea trust a reverse-proxy identity assertion from an approved proxy source, expected source IP, expected container network, and valid identity-provider flow?

·        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, network, proxy, or identity-provider context?

The detection model should support both real-time alerting and retrospective threat hunting. Retrospective hunting is especially important when audit logs, reverse-proxy 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, platform-authentication behavior, 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, authenticated, 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.

·        Gitea or comparable self-hosted Git platform accepts reverse-proxy-authenticated requests where the asserted user identity, X-WEBAUTH-USER value, source proxy, source IP, session context, device context, or identity-provider context does not align with expected authentication flow.

·        Reverse-proxy-authenticated Gitea activity creates or modifies repository permissions, deploy keys, project tokens, webhooks, OAuth applications, protected-branch settings, organization membership, repository visibility, runner settings, or administrative configuration.

·        A Gitea user or administrator account performs repository-control, token, deploy-key, webhook, workflow, registry, package, or administrative activity shortly after trusted-header authentication from an unexpected source, proxy path, container network, reverse-proxy configuration, or unauthenticated edge path.

·        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 or suspicious platform-authentication events.

·        Cloud, Kubernetes, deployment-platform, or infrastructure-as-code activity using credentials associated with CI/CD, Git automation, runners, deploy accounts, service principals, workload identities, or administrative identities after suspicious repository, authentication, 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, authentication path, or deployment path.

Supporting signals include:

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

·        Gitea access logs, reverse-proxy logs, container logs, or identity-provider records show mismatch between the authenticated user, asserted reverse-proxy header, source proxy, source IP, request path, user agent, session, and expected identity-provider flow.

·        Multiple Gitea accounts appear to authenticate through the same unexpected proxy path, container source, source IP, header pattern, or unauthenticated route.

·        Administrative or maintainer actions occur from a Gitea session that lacks corresponding identity-provider authentication, MFA evidence, expected reverse-proxy source, or approved change-control record.

·        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, trusted-header identity, 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, recently privilege-elevated, or unexpectedly asserted accounts in sensitive repository, Gitea, 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, reverse-proxy authentication mismatch, 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, authentication, 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, reverse-proxy changes, 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.

·        Gitea, reverse-proxy, or container logs show repeated requests using unexpected trusted identity headers, including X-WEBAUTH-USER, from sources that should not be allowed to assert authenticated user context.

·        Gitea authentication, proxy, or application logs show rejected, malformed, unexpected, or conflicting reverse-proxy identity headers before successful repository or administrative access.

·        Reverse-proxy configuration, container deployment, or Gitea runtime settings indicate broad trusted-proxy acceptance, wildcard proxy trust, or authentication-header trust that is not limited to approved reverse-proxy infrastructure.

·        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, source networks, or platform-authenticated sessions.

·        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, anomalous authentication, 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, reverse-proxy infrastructure, and deployment automation systems is a high-value signal when it deviates from approved build, package, registry, authentication, and deployment destinations. These systems often require legitimate external connectivity, so detection must focus on unusual destinations, unusual timing, unusual initiating jobs, unusual users, unexpected proxy paths, 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, suspicious Gitea authentication, 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.

·        Reverse-proxy or Git platform host communication patterns inconsistent with approved authentication, repository, administrative, or integration flows.

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

Persistence and Post-Exploitation Signals

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, anomalous Gitea authentication, 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, automation credentials, repository permissions, organization memberships, administrator settings, or reverse-proxy authentication settings after suspicious workflow activity or anomalous Gitea trusted-header authentication.

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

·        Protected-branch weakening, approval-rule changes, required-review bypasses, CODEOWNERS changes, repository visibility changes, organization membership changes, or administrative setting changes after suspicious authentication or workflow activity.

·        New webhook destinations, OAuth applications, integration tokens, service accounts, workload identities, deployment identities, registry credentials, package credentials, or cloud credentials created after suspicious repository activity.

·        Package publication, image push, image overwrite, release artifact modification, cache manipulation, or artifact replacement after suspicious workflow activity.

·        Cloud API activity, Kubernetes API activity, deployment action, infrastructure-as-code execution, secret-manager access, storage access, or production workload changes tied to CI/CD identities after suspicious Git, Gitea, or runner activity.

·        Attempts to disable logging, reduce retention, alter audit settings, remove webhook history, clear job logs, delete artifacts, rotate suspicious tokens, or remove evidence after suspicious repository or platform-authentication activity.

Lateral Movement and Expansion Signals

Lateral movement and expansion signals indicate that the activity may have moved beyond the Git platform, repository, CI/CD, or authentication layer. These signals should drive escalation when they can be tied to repository-control activity, platform-authentication anomalies, workflow execution, runner activity, automation credentials, or downstream identity use.

Relevant expansion signals include:

·        CI/CD-linked identities, service principals, workload identities, deploy accounts, registry tokens, package tokens, or runner-derived credentials used outside expected repository, branch, workflow, runner, source network, time window, or deployment path.

·        Cloud API, Kubernetes API, deployment-platform, infrastructure-as-code, secret-manager, storage, function, workload, or production environment activity after suspicious repository, workflow, or Gitea authentication activity.

·        Package registry, container registry, artifact store, build-cache, release system, or deployment system access from unfamiliar users, runners, identities, source IPs, or trusted-header sessions.

·        Multiple repositories, groups, organizations, runners, registries, packages, images, artifacts, or deployment paths affected by the same account, token, webhook, runner, proxy path, or automation identity.

·        Internal service access from runner hosts, Git platform hosts, reverse-proxy hosts, registry hosts, or build systems after suspicious repository-control or authentication activity.

·        Similar authentication, trusted-header, workflow, runner, token, registry, or downstream-control-plane activity appearing across multiple projects or self-hosted Git instances.

Signal Usage Constraints

Signals must be interpreted through correlation and business context. Self-hosted Git platforms, CI/CD systems, reverse proxies, runners, registries, package systems, cloud environments, Kubernetes clusters, and deployment automation produce high volumes of legitimate administrative and engineering activity.

·        Do not treat workflow-file modification as compromise by itself.

·        Do not treat Gitea reverse-proxy authentication as compromise by itself.

·        Do not treat X-WEBAUTH-USER presence as malicious without source-proxy, identity-provider, session, user, and repository context.

·        Do not treat CI/CD job execution as malicious without repository, runner, identity, workflow, command, credential, registry, or downstream context.

·        Do not treat token creation, deploy-key creation, webhook changes, or runner registration as compromise without supporting context.

·        Do not treat outbound runner traffic as malicious without destination, command, repository, workflow, job, and timing context.

·        Do not attribute cloud, Kubernetes, or deployment activity to repository workflow abuse unless lineage ties it to CI/CD credentials, workflow execution, runner hosts, automation identities, suspicious authentication, or platform-admin activity.

·        Do not use CVE presence, exploit reporting, or platform version alone as proof of compromise.

·        Do not rely on IP addresses, domains, repository names, image tags, package names, header values, or event IDs as primary detection logic.

·        Do not broadly suppress trusted administrators, trusted repositories, trusted runners, trusted reverse proxies, or trusted service accounts without validating activity against change-control, identity, and downstream behavior.

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 platform-authentication activity, 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:

·        Self-hosted Gitea reverse-proxy authentication anomalies followed by repository-control activity, including spoofed trusted-header identity assertion, unexpected X-WEBAUTH-USER values, user impersonation, administrative impersonation, permission changes, token creation, deploy-key creation, webhook modification, workflow execution, registry access, package access, or administrative configuration changes.

·        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.

·        Gitea authentication, reverse-proxy, container, and Git audit telemetry can be correlated to identify when a trusted-header authentication path produces repository, token, webhook, package, registry, CI/CD, or administrative activity that does not match expected identity-provider, source-proxy, source-IP, session, or change-control context.

·        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 or suspicious platform-authentication activity.

·        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, authentication, 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 platform authentication or repository control into trusted automation execution and then into credential, artifact, registry, deployment, or cloud abuse.

High-value correlation chains include:

·        Gitea reverse-proxy authentication anomaly followed by repository permission change, token creation, deploy-key creation, webhook modification, workflow execution, or administrative configuration change.

·        Unexpected X-WEBAUTH-USER assertion followed by repository cloning, organization membership change, administrative action, protected-branch change, token creation, package access, registry access, or CI/CD activity.

·        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.

Detection Gaps

Detection gaps are significant because repository workflow abuse crosses Git, authentication, reverse-proxy, CI/CD, runner, registry, identity, cloud, Kubernetes, deployment, and change-management boundaries. Missing telemetry at any point can prevent analysts from proving whether suspicious workflow or authentication activity resulted in credential exposure, artifact manipulation, package or image abuse, administrative impersonation, or downstream environment access.

Common detection gaps 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, permission changes, organization membership changes, repository visibility changes, or administrative activity.

·        Gitea and reverse-proxy logs may not preserve enough detail to prove whether authenticated user context came from an approved proxy, trusted identity provider, expected source IP, expected container network, or spoofable trusted-header value.

·        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, container runtime visibility, or workspace context.

·        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, URL, reverse-proxy source, or workload 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, trusted-header assertion context, proxy authentication context, or privilege changes.

·        Reverse-proxy authentication can create identity-lineage gaps when Gitea trusts inbound identity headers but the SIEM cannot join Gitea audit events to proxy logs, identity-provider records, source IP, device context, MFA evidence, and session context.

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

·        Inconsistent naming conventions across repositories, runners, tokens, service accounts, registries, images, packages, reverse-proxy components, 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, authentication, repository, workflow, runner, credential, registry, network, or downstream-control-plane correlation.

Platform and Authentication Visibility Gaps

Self-hosted Git platforms frequently rely on reverse proxies, identity providers, local containers, internal networks, and application-layer headers. These layers may not be logged consistently or joined in SIEM pipelines.

Key platform and authentication visibility gaps include:

·        Gitea trusted-header behavior may not be visible if application logs do not preserve asserted user headers, source proxy, source IP, request path, session, and administrative action together.

·        Reverse-proxy logs may not include enough application context to determine which repository, organization, project, workflow, token, or administrative object was affected.

·        Container logs may not preserve source-path detail when reverse proxy, Gitea, and supporting services communicate over internal container networks.

·        Identity-provider logs may show no corresponding authentication event when Gitea accepts a spoofed or improperly trusted authenticated-user header.

·        Header spoofing attempts may be lost if only successful Git or web actions are retained.

·        Administrative impersonation may appear as legitimate user activity unless Gitea audit events are joined to proxy, identity-provider, source-IP, device, and session evidence.

·        Wildcard trusted-proxy configuration or broad reverse-proxy trust may not be represented as a security event unless configuration-state monitoring is enabled.

Repository and CI/CD Coverage Gaps

Repository and CI/CD telemetry can be incomplete even when Git platform logs are available. This creates uncertainty about whether platform-authenticated access changed software-delivery behavior.

Key repository and CI/CD gaps include:

·        Workflow edits may not retain enough diff, actor, source, branch, or approval context to distinguish authorized release engineering from suspicious manipulation.

·        Token, deploy-key, webhook, OAuth application, service-account, and workload-identity creation may not be joined to later repository, CI/CD, package, registry, or deployment actions.

·        CI/CD job logs may mask secrets but still fail to prove whether secret access was attempted, blocked, printed, staged, or transmitted.

·        Runner telemetry may be absent when self-hosted runners are treated as unmanaged build infrastructure rather than high-risk execution infrastructure.

·        Package and image lineage may be incomplete, preventing confident validation of whether build outputs were altered after suspicious repository or authentication activity.

·        Artifact, cache, and release-asset access may not be joined to repository workflow changes or runner identity.

·        Downstream cloud, Kubernetes, and deployment activity may be logged separately from CI/CD and Git activity, causing lineage gaps.

Detection Gap Mitigation Priorities

The highest-value mitigations are those that restore lineage from authentication and repository control into workflow execution and downstream software-delivery impact.

Priority mitigations include:

·        Integrate endpoint execution events with network, identity, reverse-proxy, Gitea audit, repository, CI/CD, package-registry, registry, artifact, cloud-control-plane, Kubernetes, and deployment telemetry.

·        Validate Gitea reverse-proxy trust configuration, trusted-header handling, approved proxy source ranges, identity-provider linkage, container network exposure, and logging coverage for X-WEBAUTH-USER or comparable authenticated-user assertion headers.

·        Ensure Git audit logs retain workflow-file changes, deploy-key creation, token creation, webhook changes, runner registration, protected-branch changes, administrative actions, permission changes, organization membership changes, repository visibility changes, and authentication events.

·        Ensure reverse-proxy logs preserve source IP, source proxy, request path, user agent, asserted identity header, upstream target, response status, and timestamp.

·        Ensure Gitea application logs preserve authenticated user, administrative action, repository action, organization action, token action, webhook action, runner action, source IP, session, and timestamp.

·        Ensure CI/CD logs preserve job command context, runner assignment, pipeline source, branch, merge request, actor, artifact access, cache access, protected-variable behavior, and triggering identity.

·        Ensure runner hosts have EDR, process telemetry, command-line capture, container runtime visibility, network telemetry, file telemetry, and workspace context.

·        Ensure package, container registry, artifact, and release logs preserve actor, token, source IP, repository, package, image tag, artifact lineage, and timestamp.

·        Ensure identity-provider logs preserve MFA context, device context, token lifecycle, source IP, reverse-proxy linkage, service-account behavior, bot-account behavior, and privilege changes.

·        Ensure cloud and Kubernetes logs identify API action, identity, role, credential source, source IP, service principal, workload identity, resource, region, namespace, deployment target, and result.

·        Normalize timestamps and time zones across Git, reverse-proxy, Gitea, CI/CD, runner, registry, package, cloud, Kubernetes, identity, and SIEM telemetry.

·        Maintain approved baselines for reverse-proxy sources, Gitea authentication flows, trusted headers, repository permissions, workflow owners, runner inventory, token inventory, webhook inventory, automation identities, registry paths, and deployment identities.

Detection Coverage Summary

Detection coverage is strongest when Git audit logs, Gitea authentication logs, reverse-proxy logs, container logs, CI/CD pipeline logs, runner telemetry, command-line capture, file telemetry, process-aware network telemetry, identity-provider telemetry, registry logs, package logs, cloud logs, Kubernetes logs, and deployment logs can be joined into a single repository-to-runner-to-downstream lineage.

Coverage is strongest when the organization can connect authentication context, repository control, workflow execution, runner behavior, credential exposure, registry activity, package or image activity, artifact access, and downstream cloud, Kubernetes, or deployment activity. In that state, defenders can identify whether a suspicious Gitea authentication event, workflow edit, token creation, deploy-key change, webhook modification, runner action, or CI/CD job created real software-delivery exposure.

Coverage is moderate when Git, CI/CD, registry, and cloud logs are available but reverse-proxy, Gitea authentication, runner process, command-line, or identity-provider correlation is incomplete. In that state, suspicious workflow and downstream activity may still be detected, but attribution to authentication abuse, user impersonation, or trusted-header spoofing may remain uncertain.

Coverage is weak when the organization lacks Git audit detail, reverse-proxy logs, Gitea authentication logs, runner telemetry, CI/CD job detail, package or registry lineage, cloud or Kubernetes identity mapping, and change-control validation. In that state, detections should remain hunting-oriented because high-confidence conclusions about software-delivery compromise, authentication abuse, credential exposure, or downstream deployment impact may not be supportable.

The amended detection model provides strong coverage for Gitea reverse-proxy trusted-header abuse when the activity becomes visible through anomalous authentication, user impersonation, administrative action, repository-control changes, token or deploy-key creation, workflow execution, registry activity, package activity, CI/CD activity, or downstream control-plane use. It should not be presented as universal detection of every Gitea proxy misconfiguration or header spoofing attempt; coverage depends on telemetry that proves the relationship between authentication boundary failure and software-delivery control-plane behavior.

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 software-delivery control-plane compromise creates organizational exposure by increasing uncertainty around software-delivery integrity, trusted CI/CD execution, software-delivery credentials, protected variables, package lineage, image integrity, artifact integrity, deployment behavior, cloud identity use, Kubernetes identity use, repository permission boundaries, branch write authorization, Git hook integrity, Gitea service-account execution, self-hosted Git platform authentication lineage, GitLab GraphQL request integrity, GitLab project and user-data integrity, GitHub Enterprise Server repository-write and upload-processing integrity, GitHub Enterprise Server Manage API trust, pre-receive-hook networking and internal-service trust, management-token integrity, dependency-update credential handling, dependency-update command execution, dependency-update secret handling, dependency-release-age controls, agentic workflow authorization, AI-assisted repository tooling, private repository access by software-delivery tools, public issue and pull request input handling, public agent output behavior, JFrog Artifactory authentication and authorization state, administrative privilege integrity, repository integrity, remote-repository trust, cache integrity, package and artifact integrity, configuration integrity, token and session integrity, service-account behavior, Amazon CodeCatalyst blueprint resynthesis behavior, Coder Registry software-supply-chain trust, Vite development-server filesystem access boundaries, development-environment secret handling, DeepSeek-Reasonix repository-local Git configuration integrity, developer-tool diff-processing trust, cloud and infrastructure credential exposure, filesystem boundaries, and downstream release assurance.

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, customer-facing release paths, self-hosted GitLab, GitHub Enterprise Server, Gitea, or Artifactory administrative access, unauthenticated GraphQL mutation behavior, unauthorized modification or deletion of public projects or user data, GitHub Enterprise Server upload-processing race behavior, unauthenticated Manage API activity, attacker-controlled cluster-configuration input, outbound management requests to attacker-controlled infrastructure, replayable management-token exposure, pre-receive-hook internal-service redirection, reverse-proxy authentication, trusted-header identity assertion, user or administrator impersonation, branch write-permission escalation, repository-writer abuse, unauthorized Git hook creation or replacement, shell-command execution under a trusted Git-platform service context, private repository or LFS exposure, repository token-scope enforcement failure, webhook or migration SSRF, internal-service access, dependency-update tooling forwarding trusted credentials to attacker-influenced pagination destinations, unsafe processing of repository-controlled dependency-update inputs, disclosure of dependency-update secrets or private keys through logs, premature digest-update processing that bypasses intended release-age controls, agentic workflow prompt injection, unauthenticated Artifactory administrative takeover, Artifactory authentication or authorization failure, unauthorized Artifactory privilege or configuration changes, Artifactory identity or token abuse, package or cache poisoning, restricted-artifact exposure, protected package manipulation, release-promotion manipulation, unauthorized Artifactory file writes, Artifactory-originated requests to unintended destinations, malicious registry-delivered Coder modules, exposed Vite development servers returning files blocked by intended filesystem-deny controls, unauthenticated retrieval of environment files, cloud credentials, Infrastructure-as-Code state, or process-environment data, repository-controlled project configuration reaching a trusted software-delivery execution environment, or repository-local Git configuration and attribute poisoning causing attacker-controlled command execution through affected DeepSeek-Reasonix diff processing.

Estimated Economic Exposure

Estimated exposure should be treated as scenario-based rather than fixed. The most defensible enterprise estimate is tied to whether activity remains attempted workflow abuse, isolated suspicious CI/CD behavior, exposed self-hosted Git platform configuration, anomalous GitLab GraphQL request behavior, GitHub Enterprise Server upload-processing or repository-write exposure, Manage API exposure, pre-receive-hook networking exposure, Gitea reverse-proxy trusted-header exposure, dependency-update exposure, anomalous GitHub, GitLab, NuGet, or container-registry pagination behavior, dependency-update command-execution exposure, dependency-update secret or private-key logging exposure, digest-update release-age-control exposure, Vite development-server exposure, DeepSeek-Reasonix affected-version or repository-local configuration exposure, agentic workflow exposure, private repository or object exposure, token-scope exposure, branch write-permission exposure, webhook or internal-service access concern, affected Artifactory exposure, suspicious unauthenticated Artifactory access, unusual repository or cache behavior, affected Amazon CodeCatalyst blueprints SDK direct-consumer exposure, Coder Registry exposure, or probing of a self-hosted software-delivery platform; becomes confirmed or strongly suspected software-delivery control-plane compromise; or expands into unauthorized project or user-data modification, privileged Git-platform execution, authentication bypass, administrator impersonation, unauthorized branch writes, dependency-update credential exfiltration, dependency-update command execution, dependency-update secret disclosure, premature untrusted dependency processing, Vite sensitive-file or credential disclosure, DeepSeek-Reasonix repository-controlled command execution, artifact-platform administrative privilege acquisition, repository or configuration modification, cache poisoning, artifact-integrity loss, package modification, token or session abuse, unauthorized file writes, repository-controlled command execution, software-delivery credential exposure, internal-service access, cloud or Kubernetes control-plane activity, production deployment impact, customer-facing release exposure, ransomware staging, extortion, or broad software-delivery trust restoration.

Economic exposure increases when the organization cannot quickly prove whether GitLab accepted unauthorized GraphQL mutations, whether public projects or user data were modified or deleted, whether GitHub Enterprise Server accepted or processed attacker-controlled upload content after validation, whether Manage API activity caused attacker-directed outbound management requests, whether a privileged management bearer token was exposed or replayed, whether pre-receive-hook functionality redirected trusted internal requests to a privileged service, whether Gitea accepted spoofed or improperly trusted reverse-proxy identity headers, whether branch write permissions were abused, whether private repository or LFS content was exposed, whether repository token-scope controls were bypassed, whether webhook or migration behavior reached internal addresses, whether Renovate transmitted GitHub, GitLab, NuGet, or registry credentials to an unintended destination, whether Renovate processed attacker-controlled repository or dependency metadata through an unsafe command path, whether Mutual TLS private-key material was exposed in Renovate logs, whether digest updates bypassed an intended minimum-release-age gate and caused premature pull-request or CI activity, whether an exposed Vite development server returned sensitive files that intended filesystem controls should have denied, whether development-environment credentials or infrastructure secrets were exposed, whether DeepSeek-Reasonix processed attacker-controlled repository-local Git configuration or .gitattributes content through the affected diff-rendering path, whether public repository-adjacent content influenced privileged agentic workflows, whether an unauthenticated request to an affected Artifactory instance produced administrative privilege, whether a stale or forged Artifactory identity remained usable, whether restricted repository content was exposed, whether trusted package, cache, or release-promotion state was modified, whether service-account file activity remained inside approved platform boundaries, whether repository-controlled ownership metadata was interpreted as shell input during Amazon CodeCatalyst blueprint resynthesis, whether a Coder Registry module delivered during the documented compromise window executed in a trusted provisioner context, and whether Git, GitLab, GitHub Enterprise Server, Gitea, Renovate, Vite, DeepSeek-Reasonix, Artifactory, CodeCatalyst, Coder, identity-provider, workflow, CI/CD, registry, package, artifact, host, cloud, Kubernetes, deployment, and change-control telemetry can be joined into a reliable lineage chain.

Low Impact Scenario

Estimated $750K - $3.5M.

This scenario applies when suspicious repository workflow activity, anomalous GitLab GraphQL behavior, suspicious GitHub Enterprise Server upload-processing behavior, Manage API probing, pre-receive-hook exposure, suspicious Gitea reverse-proxy authentication behavior, exposed trusted-proxy configuration, affected Renovate exposure, suspicious GitHub, GitLab, NuGet, or container-registry pagination behavior, suspicious Renovate command-path or log-sanitization behavior, minimum-release-age-control exposure, exposed Vite development-server risk, DeepSeek-Reasonix affected-version or repository-configuration exposure, agentic workflow exposure, private repository exposure risk, token-scope exposure risk, branch write-permission exposure, webhook or internal-service access concern, affected Artifactory exposure, unauthenticated Artifactory probing, remote-repository activity, cache-integrity concern, affected Amazon CodeCatalyst blueprints SDK exposure, suspicious repository-controlled .ownership-file content, Coder Registry exposure, or software-delivery platform probing is detected quickly, but available telemetry confirms no successful impersonation, no unauthorized repository access, no unauthorized project or user-data modification, no privileged GitHub Enterprise Server execution, no management-token replay, no pre-receive-hook internal-service impersonation, no unauthorized branch write activity, no Renovate credential exfiltration, no Renovate command execution, no dependency-update private-key disclosure, no premature CI execution with malicious dependency content, no unauthorized Vite sensitive-file retrieval, no development-environment credential disclosure, no DeepSeek-Reasonix attacker-controlled command execution, no Artifactory administrative privilege acquisition, no unauthorized repository or configuration change, no package or cache poisoning, no restricted-artifact disclosure, no unauthorized token or session establishment, no unauthorized service-account file write, no repository-controlled command execution during blueprint resynthesis, no malicious Coder module execution, no protected-variable or credential exposure, no unauthorized package or image publication, no release artifact modification, no cloud or Kubernetes activity, no production deployment impact, and no customer-facing software-delivery impact.

Response remains limited to patch validation, GitLab GraphQL and project-integrity review, GitHub Enterprise Server release and appliance-state review, repository upload and processing review, Manage API and management-token review, pre-receive-hook review, Gitea and reverse-proxy configuration review, Renovate version and configuration validation, GitHub, GitLab, NuGet, and registry credential review, pagination-origin review, Renovate execution and command-path review, Renovate log and secret-handling review, minimumReleaseAge and digest-update review, Vite version and exposure validation, development-server request review, filesystem-scope and server.fs configuration review, sensitive-file and credential review, DeepSeek-Reasonix version validation, repository-local .git/config and .gitattributes review, developer-workstation process review, Artifactory configuration and administrative-state review, remote-repository and cache review, Amazon CodeCatalyst blueprints SDK version validation for direct consumers, repository-controlled ownership metadata review, Coder version and module-cache review, branch permission review, agentic workflow permission review, targeted hunting, short-term monitoring, and executive tracking.

Moderate Impact Scenario

Estimated $6M - $25M.

This scenario applies when confirmed or strongly suspected repository workflow abuse, unauthorized GitLab GraphQL mutation behavior, unauthorized project or user-data modification, GitHub Enterprise Server upload-processing abuse, suspicious Manage API activity, management-token exposure or replay concern, pre-receive-hook internal-service redirection, Gitea trusted-header authentication abuse, user or administrator impersonation, branch write-permission abuse, Renovate GitHub, GitLab, NuGet, or container-registry credential exposure, Renovate command execution from repository-controlled or dependency-controlled input, Renovate private-key or secret disclosure through logging, premature digest-update processing that weakens configured release-age protections, unauthorized Vite file disclosure involving environment files, cloud credentials, Infrastructure-as-Code state, process-environment data, certificates, application source, or other secrets, DeepSeek-Reasonix repository-local configuration poisoning and resulting attacker-controlled command execution, unauthenticated Artifactory administrative takeover, Artifactory authorization abuse, unauthorized repository or configuration changes, package or cache poisoning, restricted-artifact exposure, token or session abuse, SAML or integration-identity misuse, protected package or release-promotion manipulation, unauthorized Artifactory file-write behavior, suspicious remote-repository activity, repository-controlled command execution during blueprint resynthesis, Coder Registry malicious-module execution concern, agentic workflow prompt injection, runner misuse, protected-variable exposure, software-delivery credential misuse, registry access, artifact access, package activity, image activity, administrative activity, or deployment uncertainty requires the organization to treat the event as a software-delivery control-plane incident even without confirmed customer impact, ransomware, or full production compromise.

Response may require repository and workflow review, GitLab GraphQL and audit review, GitHub Enterprise Server appliance and audit review, repository upload-processing reconstruction, Manage API request review, management-token rotation and replay assessment, pre-receive-hook review, internal-service validation, Gitea authentication review, reverse-proxy log review, Renovate execution and HTTP pagination review, GitHub, GitLab, NuGet, and registry credential rotation, command-execution reconstruction for applicable Renovate managers, log review and private-key rotation where disclosure cannot be excluded, digest-update and CI execution review, Vite request reconstruction, development-server exposure review, filesystem-access review, DeepSeek-Reasonix repository-local Git configuration and attribute reconstruction, developer-workstation process and command-line review, cloud and development credential rotation where disclosure cannot be excluded, Artifactory authentication and session reconstruction, administrative-state review, repository and remote-repository review, configuration and permission review, token and service-account review, SAML and integration-identity review, cache-path reconstruction, package and release-promotion validation, filesystem review, Amazon CodeCatalyst blueprint resynthesis review, .ownership-file history reconstruction, Coder registry and module-cache review, provisioner review, agentic workflow review, CI/CD pipeline reconstruction, runner isolation, credential and secret rotation, 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, unauthorized GitLab project or user-data modification, GitHub Enterprise Server arbitrary code execution or management-boundary compromise, pre-receive-hook internal-service impersonation, Gitea authentication-boundary abuse, branch write-permission abuse, dependency-update credential exfiltration, dependency-update command injection, dependency-update secret or private-key exposure, bypass of dependency-age controls that enables execution of malicious dependency content, Vite development-server file-disclosure abuse that exposes cloud, infrastructure, application, signing, CI/CD, or other privileged secrets, DeepSeek-Reasonix repository-local configuration poisoning that results in attacker-controlled execution under a developer context, unauthenticated Artifactory administrator takeover, Artifactory token or identity abuse, unauthorized package or cache poisoning, restricted-artifact disclosure, path-traversal or arbitrary-file-write behavior, artifact-repository compromise, protected package or release-promotion manipulation, service-account misuse, repository-controlled command execution in a trusted resynthesis or build environment, malicious registry-delivered module execution, software-delivery credential exposure, agentic workflow prompt injection, private repository exposure, webhook or internal-service access, or another software-delivery control-plane abuse becomes an enterprise-impact pathway involving malicious build execution, credential theft, administrator impersonation, sensitive repository access, unauthorized branch writes, unauthorized artifact-platform administrative actions, 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, malicious release risk, or broad loss of confidence in software-delivery integrity.

The upper end of this range applies when the organization must halt or roll back releases, reconstruct affected GitLab or GitHub Enterprise Server repository or management state, validate or rebuild CI/CD or artifact infrastructure, reconstruct Renovate pagination, command execution, credential use, log exposure, and dependency-age-control activity, reconstruct Vite development-server request and sensitive-file-access history, reconstruct DeepSeek-Reasonix repository-local Git configuration, .gitattributes state, diff-processing activity, and developer-workstation command execution, rotate potentially exposed cloud, development, infrastructure, application, or CI/CD credentials, reconstruct blueprint resynthesis execution, reconstruct privileged sessions and administrative changes, validate Coder Registry module provenance, rotate high-risk GitHub, GitLab, NuGet, registry, management, Mutual TLS, SAML, token, integration, service-account, or software-delivery credentials at scale, verify package and image integrity, review customer-consumed artifacts, validate whether unauthorized Artifactory access altered trusted software-delivery material, 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, self-hosted artifact-repository dependency, direct consumption of vulnerable software-delivery SDKs, broad CI/CD runner access, sensitive repository exposure, incomplete Git or CI/CD telemetry, privileged software-delivery identity exposure, dependency-update tooling using trusted GitHub, GitLab, NuGet, or registry credentials, dependency-update tooling permitted to execute external commands, dependency-update Mutual TLS private-key use, weak dependency-release-age enforcement, exposed Vite development servers, development environments containing reusable cloud or infrastructure credentials, DeepSeek-Reasonix or similar Git-wrapping developer tooling that processes repository-local Git configuration, weak runner segmentation, limited package or image lineage, incomplete artifact-repository filesystem monitoring, weak token and session governance, incomplete SAML or integration-identity visibility, weak remote-repository or cache-boundary validation, incomplete change-management validation, weak branch-permission validation, incomplete private-repository visibility controls, repository-controlled project metadata consumed by privileged software-delivery components, agentic workflows with broad private-repository access, webhook or internal-service reachability gaps, or high downstream dependency on automated deployment paths.

Exposure may exceed $50M - $125M+ where confirmed software-delivery compromise, confirmed unauthorized GitLab project or user-data modification, confirmed GitHub Enterprise Server arbitrary code execution or management-boundary compromise, confirmed Gitea authentication-boundary abuse, confirmed Renovate credential exfiltration, confirmed Renovate command execution, confirmed dependency-update secret or private-key disclosure, confirmed malicious dependency execution after release-age-control bypass, confirmed Vite development-server disclosure of reusable cloud, infrastructure, application, or software-delivery credentials, confirmed DeepSeek-Reasonix attacker-controlled command execution from poisoned repository-local Git configuration, confirmed Artifactory administrator takeover, confirmed identity or token abuse, confirmed package or cache poisoning, confirmed artifact-platform file-write or artifact-integrity compromise, confirmed repository-controlled command execution within a trusted resynthesis environment, confirmed Coder Registry malicious-module execution, confirmed privileged software-delivery credential exposure, confirmed agentic workflow data exposure, or confirmed private repository disclosure requires enterprise-scale credential rotation, CI/CD or artifact-platform 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.

Operational Dependency

Operational dependency is high where self-hosted Git platforms, GitHub Enterprise Server appliances, GitHub organizations, Gitea instances, GitLab instances, Forgejo instances, reverse proxies, identity providers, management APIs, pre-receive-hook infrastructure, Renovate dependency-update tooling, Vite development servers, DeepSeek-Reasonix Studio or other Git-wrapping AI-assisted development tools, self-hosted artifact repositories, Amazon CodeCatalyst blueprint SDK direct-consumer implementations, blueprint resynthesis environments, Coder and Coder Registry components, agentic workflows, AI-assisted development tooling, CI/CD runners, package registries, container registries, artifact stores, remote repositories, package caches, Docker caches, LFS stores, deployment controllers, cloud environments, Kubernetes clusters, secret stores, and production release workflows are required to build, package, release, deploy, and maintain business-critical software.

Dependency increases when sensitive repositories, private repositories, privileged workflows, package-publishing paths, image-publishing paths, infrastructure-as-code workflows, production deployment workflows, privileged runners, branch-specific write controls, management interfaces, pre-receive hooks, artifact-platform administrative interfaces, SAML and token infrastructure, remote-repository configuration, package caches, service-account filesystem access, repository-controlled .ownership-file metadata, blueprint resynthesis processes, Renovate GitHub, GitLab, NuGet, or registry credentials, Renovate external-command execution, Mutual TLS credentials, minimumReleaseAge controls, Vite development servers reachable from untrusted networks, development environments containing cloud or infrastructure credentials, repository-local .git/config and .gitattributes content processed by developer tooling, registry-delivered infrastructure modules, public issue or pull request triggers, agentic workflow output paths, or software-delivery identities with downstream access are involved.

Control Trust

Control trust is reduced when the organization cannot prove that repository permissions, branch permissions, project and user-data integrity, workflow files, protected branches, deploy keys, tokens, management bearer tokens, webhooks, OAuth applications, runner assignments, GitLab GraphQL activity, GitHub Enterprise Server repository upload-processing activity, Manage API activity, cluster-configuration input, pre-receive-hook configuration and networking, trusted internal-service request paths, Gitea authentication state, reverse-proxy trust configuration, identity-provider linkage, Renovate pagination-origin enforcement, GitHub, GitLab, NuGet, and registry credential handling, Renovate command-argument handling, log sanitization, Mutual TLS private-key handling, minimumReleaseAge enforcement, Vite development-server exposure state, filesystem restrictions, server.fs.allow and server.fs.deny configuration, DeepSeek-Reasonix version state, repository-local .git/config and .gitattributes integrity, diff-rendering execution behavior, artifact-platform authentication and authorization state, administrator state, administrative-session lineage, token scope, refresh-token integrity, SAML identity mapping, integration credentials, repository permissions, remote-repository configuration, package-cache integrity, release-promotion information, service-account file writes, repository-controlled ownership metadata, blueprint resynthesis command handling, Coder Registry module provenance, package lineage, image lineage, artifact lineage, deployment identity use, cloud identity use, Kubernetes identity use, and post-containment remediation evidence remained reliable during the activity window.

Control trust is further reduced when self-hosted Git administrative actions, GitLab GraphQL mutations, GitLab project or user-data changes, GitHub Enterprise Server upload-processing events, Manage API requests, management-token use, pre-receive-hook execution, Gitea user or administrator actions, spoofed trusted-header values, Renovate requests to unexpected pagination destinations, unexpected Renovate external-command execution, unexpected dependency-update log exposure, premature digest-update processing, suspicious Vite /@fs/ requests, unexpected development-server retrieval of sensitive files, unexpected DeepSeek-Reasonix diff rendering accompanied by shell or child-process execution, unexpected artifact-platform requests, privileged-session creation, repository migration, permission or configuration changes, SAML or integration-identity events, remote-repository access, package-cache changes, release-promotion changes, service-account filesystem changes, .ownership-file modification, blueprint resynthesis execution, Coder registry-module downloads, template or workspace activity, workflow runs, branch writes, CI/CD jobs, registry actions, package actions, artifact downloads, cloud API calls, Kubernetes API calls, webhook requests, migration requests, or deployment actions cannot be tied to approved users, sessions, origins, change records, workflows, service accounts, software-delivery identities, and validated release paths.

Visibility Confidence

Visibility confidence is highest when Git audit logs, GitLab audit and GraphQL telemetry, GitHub Enterprise Server appliance and administrative logs, repository upload-processing records, Manage API request records, management-token use, pre-receive-hook configuration and execution records, Gitea authentication and administrative logs, GitHub organization audit logs, Renovate execution logs, HTTP request and response telemetry, pagination-destination telemetry, dependency-manager and external-command telemetry, Renovate configuration telemetry, log-access telemetry, secret-management records, Mutual TLS credential inventory, minimumReleaseAge configuration, digest-update and pull-request records, Vite development-server request logs, reverse-proxy or ingress logs, query-string and /@fs/ request context, Vite version and exposure inventory, server.fs.allow and server.fs.deny configuration, filesystem-access telemetry where available, DeepSeek-Reasonix version and asset inventory, repository-local .git/config and .gitattributes state, repository provenance, diff-view activity, developer-workstation process and command-line telemetry, artifact-platform authentication and request logs, administrative and access logs, repository and package logs, remote-repository logs, configuration-change records, permission and token records, SAML and integration-identity events, package-cache and release-promotion records, service-account host telemetry, filesystem-audit telemetry, Amazon CodeCatalyst blueprint SDK execution telemetry where available, blueprint resynthesis logs, repository history for .ownership-file, Coder version and registry-module records, module-cache state, template and workspace events, provisioner telemetry, workflow run logs, agentic workflow logs, reverse-proxy logs, identity-provider logs, branch-permission records, repository visibility records, LFS object access records, CI/CD pipeline logs, runner telemetry, endpoint telemetry, process-aware network telemetry, DNS logs, proxy logs, firewall logs, registry logs, package logs, artifact logs, cloud logs, Kubernetes logs, deployment logs, change-control records, repository inventory, runner inventory, software-delivery identity inventory, package ownership records, image ownership records, artifact lineage, and SIEM correlation can be joined reliably.

Visibility confidence is reduced when Git audit logs are incomplete; GitLab GraphQL or project-change activity cannot be reconstructed; GitHub Enterprise Server upload-processing, management, or hook activity cannot be reconstructed; management-token use cannot be attributed; Renovate telemetry cannot establish the original GitHub, GitLab, NuGet, or registry origin, pagination destination, credential scope, cross-origin request, dependency-manager command path, repository-controlled input, secret or private-key exposure, minimumReleaseAge state, digest update, or resulting CI execution; Vite request telemetry cannot establish whether filesystem-deny bypass requests succeeded or what file content was returned; development-server exposure history cannot be reconstructed; DeepSeek-Reasonix version, repository-local Git configuration, .gitattributes state, diff-rendering activity, or resulting child-process execution cannot be reconstructed; artifact-platform request logs do not preserve authentication state, source, session, user, repository, route, administrative context, remote-repository context, migration context, package-cache behavior, token context, or identity context; administrative changes cannot be tied to an approved administrator; filesystem telemetry cannot establish whether a service account wrote outside approved platform paths; repository and package logs cannot establish cache poisoning or protected-content changes; repository history cannot establish who modified .ownership-file; blueprint resynthesis telemetry cannot establish the command path, runtime identity, environment, or credentials available during execution; Coder registry and module-cache state cannot be reconstructed; agentic workflow logs do not preserve input, tool-use, repository-access, or output context; cloud or Kubernetes activity is not tied to CI/CD identity; timestamps are inconsistent; change records are incomplete; or retention windows are too short to reconstruct repository-to-management-to-hook-to-dependency-update-to-development-server-to-developer-tool-to-agent-to-workflow-to-resynthesis-to-provisioner-to-runner-to-artifact-platform-to-downstream lineage.

Change-Control Confidence

Change-control confidence is high when workflow changes, GitLab project and user-data changes, GitHub Enterprise Server management configuration, pre-receive-hook changes, cluster configuration, Renovate version or configuration changes, GitHub, GitLab, NuGet, and registry credential changes, Renovate external-command permissions, dependency manager configuration, Mutual TLS secret configuration, minimumReleaseAge settings, digest-update controls, Vite version and exposure changes, DeepSeek-Reasonix version changes, repository-local Git configuration and attribute changes, artifact-platform repository changes, administrator or permission changes, configuration changes, token and service-account changes, SAML or integration-identity changes, remote-repository configuration, cache-path behavior, package-cache changes, release-promotion changes, service-account filesystem changes, .ownership-file modifications, blueprint project configuration changes, blueprint resynthesis behavior, Coder version or registry-module changes, template or workspace changes, agentic workflow configuration changes, AI-agent permission changes, token creation, deploy-key changes, webhook changes, runner changes, package publication, image publication, artifact changes, deployment actions, branch permission changes, repository visibility changes, reverse-proxy configuration changes, trusted-header configuration changes, identity-provider changes, and migration activity can be tied to approved maintenance, release engineering, platform administration, security testing, or incident-response records.

Confidence is reduced when suspicious activity occurs outside approved windows, lacks an owning ticket, affects sensitive repositories, involves privileged software-delivery paths, changes authentication boundaries, modifies project or user data through unexpected GraphQL activity, modifies GitHub Enterprise Server management or pre-receive-hook state, causes attacker-directed management requests, causes Renovate to follow an unexpected pagination destination while attaching trusted credentials, causes Renovate to process attacker-controlled dependency or repository content through an unsafe command path, causes Mutual TLS private-key material or another configured secret to appear unexpectedly in logs, bypasses a configured minimum release age for digest updates, exposes a Vite development server to an untrusted path or permits filesystem-deny bypass requests to retrieve sensitive files, introduces attacker-controlled repository-local Git filter configuration consumed by DeepSeek-Reasonix or similar developer tooling, creates an unexpected artifact-platform administrator or privileged session, alters token or SAML trust, modifies repository permissions or configuration without approved action, modifies repository-controlled blueprint ownership metadata with shell-sensitive content, causes blueprint resynthesis to execute unexpected operating-system commands, downloads a registry module from unauthorized Coder infrastructure, poisons package or remote-repository cache content, causes service-account writes outside intended platform boundaries, exposes restricted artifact content, reaches internal services through server-side requests, or creates uncertainty around whether an action was performed by the expected user, administrator, token, runner, service account, dependency-update identity, developer tool, provisioner, AI agent, or workload identity.

Downstream Dependency

Downstream dependency is high when Git platform, dependency-update tooling, Vite development-server activity, DeepSeek-Reasonix or similar Git-wrapping developer-tool activity, blueprint resynthesis, Coder provisioner, or artifact-repository activity can influence production deployment, cloud infrastructure, Kubernetes clusters, package registries, container registries, artifact stores, remote-repository caches, LFS stores, release systems, customer-facing applications, regulated workloads, internal business systems, secret stores, identity providers, databases, file stores, or recovery-critical systems.

These dependencies increase the impact of even limited repository-control, project-integrity, Git-platform management, authentication-boundary, branch-permission, management-token, Renovate credential, dependency-update command-execution, dependency-update secret exposure, release-age-control, Vite sensitive-file disclosure, DeepSeek-Reasonix repository-local configuration poisoning, artifact-platform administrative, token, SAML, migration, package-cache, artifact-access, private-object, blueprint metadata, resynthesis, malicious-module, agentic workflow, webhook, or server-side request abuse because responders may need to prove that trusted build outputs, packages, images, artifacts, source-code objects, deployment actions, management credentials, GitHub credentials, GitLab credentials, NuGet credentials, registry credentials, Mutual TLS credentials, development-environment secrets, cloud identities, Kubernetes identities, and production release behavior remained intact.

Customer and Regulatory Exposure

Customer and regulatory exposure increases when suspicious repository workflow abuse, unauthorized GitLab project or user-data modification, GitHub Enterprise Server arbitrary code execution or management-boundary abuse, Gitea trusted-header authentication abuse, administrator impersonation, branch write-permission abuse, dependency-update credential exfiltration, dependency-update command injection, dependency-update secret or private-key disclosure, premature execution of untrusted dependency content after release-age-control bypass, Vite development-server file disclosure exposing cloud, infrastructure, application, source-code, or software-delivery secrets, DeepSeek-Reasonix repository-local configuration poisoning and resulting attacker-controlled command execution, unauthenticated artifact-platform administrative takeover, artifact-platform identity or token abuse, unauthorized package or cache poisoning, restricted-artifact exposure, protected package modification, release-promotion manipulation, repository-controlled command execution during blueprint resynthesis, malicious registry-module execution, privileged software-delivery credential exposure, agentic workflow prompt injection, private repository exposure, webhook or internal-service access, workflow execution, package publication, image publication, release artifact modification, deployment action, cloud API activity, Kubernetes API activity, data access, or customer-facing release uncertainty affects regulated environments, customer software, hosted services, contractual security commitments, software-supply-chain obligations, or business-critical production systems.

Exposure also increases when telemetry gaps prevent timely confirmation of whether sensitive repositories, protected variables, management tokens, GitHub credentials, GitLab credentials, NuGet credentials, registry credentials, Mutual TLS keys, dependency-update command paths, dependency-release-age controls, Vite-served environment files, cloud credentials, Infrastructure-as-Code state, process-environment data, repository-local .git/config or .gitattributes state, developer-workstation execution, packages, images, artifacts, artifact-platform administrative state, token or SAML state, package caches, remote repositories, filesystem locations, blueprint ownership metadata, resynthesis environments, Coder module caches, deployments, cloud resources, Kubernetes resources, agentic workflow outputs, or customer-facing release paths were impacted.

Residual Economic Risk

Residual economic risk remains after upgrading affected GitLab installations to corrected releases, affected Gitea instances to corrected releases, affected GitHub Enterprise Server installations to applicable corrected releases, affected Renovate deployments to corrected releases, affected Vite development-server deployments to corrected releases, affected DeepSeek-Reasonix Studio and DeepSeek Reasonix npm deployments to corrected releases, affected self-hosted JFrog Artifactory deployments to the applicable corrected release, affected direct consumers of the Amazon CodeCatalyst blueprints SDK to the corrected package release, affected Coder deployments to corrected releases, and affected Perforce P4 Search deployments to version 2026.4.2 or later when the pre-remediation activity window cannot be reconstructed.

For CVE-2026-106218, affected TeamCity deployments should be upgraded to a vendor-corrected release. The documented Kotlin DSL sandbox-escape condition can permit server-side remote code execution under the affected conditions. Upgrading removes the documented vulnerable path but does not prove that attacker-controlled Kotlin DSL content did not previously escape the sandbox or execute commands in the TeamCity server context. Organizations should review the pre-remediation window for suspicious Kotlin DSL changes, build-configuration changes, TeamCity server process and child-process execution, filesystem changes, credential or secret access, repository activity, network connections, build activity, artifact activity, and downstream software-delivery effects.

For CVE-2026-106219, affected TeamCity deployments should be upgraded to version 2026.2.1 or a later corrected release applicable to the deployed branch. The documented Git submodule URL validation weakness can permit local repository reads from the TeamCity server under the affected conditions. Upgrading removes the documented vulnerable path but does not prove that local repository content was not accessed before remediation. Organizations should review the pre-remediation window for suspicious repository configuration, Git submodule activity, local repository access, TeamCity server filesystem activity, build activity, credential or secret access, repository activity, artifact activity, and downstream software-delivery effects.

For CVE-2026-100102, CVE-2026-100103, CVE-2026-103507, CVE-2026-103510, CVE-2026-103511, and CVE-2026-103512, affected P4 Search deployments should be upgraded to version 2026.4.2 or later. Upgrading removes the documented exposed debug-interface, default or blank service-authentication-token, arbitrary file-write, unsafe extension-installation, and P4 Server ticket host-binding paths, but does not prove that unauthorized privileged access, code execution, file writes, service-account activity, stolen-ticket use, connected P4 Server access, repository activity, credential access, or downstream software-delivery activity did not occur before remediation. Organizations should review the pre-remediation window for P4 Search network access, debug-interface reachability, service-token configuration and use, authentication events, P4 Server ticket activity, extension installation, logging configuration, filesystem writes, P4 Search process and child-process execution, service-account activity, credential access, repository activity, connected P4 Server activity, network connections, and downstream software-delivery effects.

GitLab upgrading reduces future exposure but does not prove that project or user-data modification, pipeline-policy abuse, approval-control abuse, or other repository-control activity did not occur before remediation.

For CVE-2026-73802, affected Gitea act_runner deployments should be upgraded to version 3.0.0 or later. Upgrading removes the documented unsafe Docker HostConfig handling path but does not prove that a repository-controlled Actions workflow did not previously supply host namespace, capability, security-profile, or related container options that enabled execution on the runner host or access to secrets, deployment credentials, adjacent build infrastructure, or downstream software-delivery resources. Organizations should review the pre-remediation window for suspicious workflow changes, act_runner jobs, container configuration, Docker runtime activity, runner-host process execution, credential or secret access, filesystem activity, network activity, registry or artifact access, cloud or Kubernetes activity, and downstream build or deployment actions.

Gitea upgrading reduces future CVE-2026-60004 exposure but does not prove that repository write access was not previously used to create or replace a Git hook or execute commands under the Gitea service account.

GitHub Enterprise Server upgrading reduces future CVE-2026-19118, CVE-2026-18730, and CVE-2026-76851 exposure but does not prove that attacker-controlled upload content was not previously processed, that an outbound management request did not expose a replayable management token, that a management token was not replayed, or that a pre-receive hook did not redirect trusted internal requests.

For CVE-2026-88880, affected Renovate npm and renovate/renovate container deployments should be upgraded to version 44.11.3 or later. Applicable Mend Renovate CE/EE deployment artifacts should be upgraded to their corrected releases. Upgrading prevents future exploitation of the documented GitLab pagination condition but does not prove that credentials were not previously transmitted to an unintended destination.

For CVE-2026-88881, affected Renovate npm and renovate/renovate container deployments should be upgraded to version 44.11.3 or later. Applicable Mend Renovate CE/EE deployment artifacts should be upgraded to their corrected releases. Upgrading prevents future exploitation of the documented GitHub pagination condition but does not prove that credentials were not previously transmitted to an unintended destination.

For CVE-2026-88882, affected Renovate npm and renovate/renovate container deployments should be upgraded to version 44.11.2 or later. Applicable Mend Renovate CE/EE deployment artifacts should be upgraded to their corrected releases. Upgrading prevents future exploitation of the documented NuGet pagination condition but does not prove that credentials were not previously transmitted to an unintended destination.

For CVE-2026-88883, affected Renovate npm and renovate/renovate container deployments should be upgraded to version 44.14.4 or later. Applicable Mend Renovate CE/EE deployment artifacts should be upgraded to their corrected releases. Mutual TLS private keys that may have been exposed in logs should be rotated where disclosure cannot be excluded. Upgrading prevents the documented log-sanitization weakness but does not establish that pre-remediation logs did not contain sensitive private-key material.

For CVE-2026-88884, affected Renovate npm and renovate/renovate container deployments should be upgraded to version 44.3.1 or later. Applicable Mend Renovate CE/EE deployment artifacts should be upgraded to their corrected releases. Upgrading restores intended minimumReleaseAge handling for applicable digest updates but does not prove that a premature digest-update pull request or associated CI execution did not occur before remediation.

For CVE-2026-88885, CVE-2026-88886, CVE-2026-88888, and CVE-2026-88889, affected Renovate npm and renovate/renovate container deployments should be upgraded to version 44.14.7 or later. Applicable Mend Renovate CE/EE deployment artifacts should be upgraded to their corrected releases. Upgrading removes the documented command-injection paths but does not prove that repository-controlled or dependency-controlled values were not previously processed through affected external-command execution paths.

For CVE-2026-88887, affected Renovate npm and renovate/renovate container deployments should be upgraded to version 44.11.2 or later. Applicable Mend Renovate CE/EE deployment artifacts should be upgraded to their corrected releases. Upgrading prevents future exploitation of the documented container-registry pagination condition but does not prove that registry credentials were not previously transmitted to an unintended destination.

For CVE-2026-82329, applicable self-hosted Artifactory deployments should be upgraded according to the applicable JFrog corrected branch. Active exploitation has been confirmed. Affected organizations should review the pre-remediation window for unauthorized administrative access, unexpected administrator-account creation, anomalous token or user activity, configuration access, plugin deployment, command execution, payload retrieval, webshell activity, suspicious egress, repository access, artifact access, and other downstream software-delivery activity. Upgrading reduces future exposure but does not prove that administrative compromise or follow-on activity did not occur before remediation.

For CVE-2026-42018 and CVE-2026-42016, affected self-hosted Artifactory deployments should be upgraded according to the applicable JFrog corrected branch. Public exploitation reporting documents attackers chaining CVE-2026-42018 token exposure with CVE-2026-42016 token-scope escalation to obtain administrative authority. Organizations should review the pre-remediation window for anomalous internal anonymous-token activity, low-privilege identities obtaining elevated token scope, unexpected privileged actions, administrator-account creation, malicious plugin installation, command execution, second-stage payload delivery, webshell activity, suspicious egress, and downstream package or artifact manipulation.

For CVE-2026-66384 and other Artifactory vulnerabilities retained as software-delivery behavioral context, affected self-hosted deployments should be upgraded according to the governing JFrog advisory and applicable branch-specific corrected release.

For CVE-2026-85012, direct consumers of @amazon-codecatalyst/blueprints.blueprint impacted versions <= 0.3.155 should upgrade to 0.3.156 or later. AWS states that the managed Amazon CodeCatalyst service does not require action for the documented condition because managed resynthesis uses isolated per-project execution, scoped credentials, and additional server-side validation.

For the Coder Registry supply-chain compromise, affected Coder deployments should be upgraded to the applicable corrected supported-branch release, affected cached modules should be cleared, potentially affected template and workspace activity should be reviewed, and credentials or secrets accessible to affected provisioners should be rotated where exposure cannot be excluded.

For CVE-2026-102437, affected DeepSeek-Reasonix Studio installations should be updated to version 2.21.0 or later, and affected DeepSeek Reasonix npm package deployments should be updated to version 1.39.3 or later. The documented ConfigPoisoning condition can allow attacker-controlled repository-local Git configuration and .gitattributes content to invoke attacker-controlled command execution when a developer views a file diff. Upgrading prevents future exploitation of the documented path but does not prove that a poisoned repository configuration was not previously present or that attacker-controlled commands did not execute before remediation. Organizations should review repository-local .git/config state, .gitattributes history, developer-workstation process execution, shell activity, credential access, filesystem changes, network activity, and downstream software-delivery effects for the pre-remediation window.

For CVE-2026-78210, affected self-hosted Octopus Server deployments should be upgraded to an applicable fixed build or later. Affected releases include all 2019.x releases after 2019.5.9, all 2020.x through 2025.x releases, 2026.1.x before 2026.1.11739, 2026.2.x before 2026.2.13364, and 2026.3.x before 2026.3.13951. Octopus Deploy released fixed builds 2026.1.11739, 2026.2.13364, and 2026.3.13951. The vulnerability can permit users with certain scoped permission sets to execute arbitrary scripts in an environment without the required authorization.

For CVE-2026-102488, affected self-hosted Octopus Server deployments should be upgraded to an applicable fixed build or later. Affected releases include 2019.x releases from 2019.5.x onward, all 2020.x through 2025.x releases, all 2026.1.x releases, 2026.2.x before 2026.2.13438, and 2026.3.x before 2026.3.15816. Octopus Deploy released fixed builds 2026.2.13438 and 2026.3.15816 and directs older supported trains to the applicable later fixed release. The vulnerability can cause incorrect evaluation of multiple scoped permission assignments and permit a highly privileged user to obtain deployment permissions beyond those actually granted.

For CVE-2026-102478, affected self-hosted Octopus Server deployments should be upgraded to an applicable fixed build or later. Affected releases include 2023.2.x after 2023.2.945, all 2023.3.x, 2023.4.x, 2024.x, and 2025.x releases, 2026.1.x before 2026.1.11768, 2026.2.x before 2026.2.13408, 2026.3.x before 2026.3.15816, and 2026.4.x before 2026.4.1480. Octopus Deploy released fixed builds 2026.1.11768, 2026.2.13408, and 2026.3.15816. The vulnerability permits an authenticated user with permission to modify roles to weaken a built-in role and add an account to a privileged team through unsafe Unicode-equivalence handling.

Octopus Deploy states that no known mitigation is available for these three vulnerabilities other than upgrading. Organizations should review role and team changes, scoped permission assignments, deployment permissions, script execution, Environment activity, affected-user activity, Octopus Server process and child-process execution, credential or secret access, outbound communication, deployment actions, cloud or Kubernetes follow-on, and downstream release integrity during the pre-remediation window. Upgrading reduces future exposure but does not prove that privilege escalation, excess deployment authority, or unauthorized script execution did not occur before remediation.

For CVE-2026-101169, affected self-hosted Octopus Server deployments should be upgraded to an applicable fixed build or later. Affected releases include all 2019.4.x versions, all 2020.x through 2025.x versions, 2026.1.x before 2026.1.11781, 2026.2.x before 2026.2.13441, 2026.3.x before 2026.3.15829, and 2026.4.x before 2026.4.1619. Octopus Cloud instances were updated by the vendor. The vendor states that no mitigation is available other than upgrading. Organizations should identify Environment and Project editors and review the pre-remediation window for unexpected object changes, Octopus Server process or child-process execution, file or configuration changes, credential or secret access, outbound communication, artifact activity, deployment actions, cloud or Kubernetes follow-on, and downstream release integrity. Upgrading reduces future exposure but does not prove that crafted content was not previously deserialized or that arbitrary code did not execute in the Octopus Server process.

For CVE-2026-39364, affected Vite development-server deployments should be updated to Vite 7.3.2, 8.0.5, or a later corrected release applicable to the deployed branch. For CVE-2025-30208 and CVE-2025-31125, affected older Vite branches should be updated to the applicable vendor-fixed release. Development servers should not be exposed to untrusted networks. Where an affected Vite development server was externally reachable, responders should review requests to /@fs/ and related file-serving paths and treat potentially retrieved .env files, AWS credentials, Azure tokens, Terraform state, process-environment data, certificates, private application material, and other secrets as potentially exposed until telemetry demonstrates otherwise. Upgrading reduces future file-read exposure but does not prove that sensitive files or credentials were not retrieved before remediation.

CVE-2024-45811 remains relevant as historical Vite behavioral context for older deployments but is not an additional active-register CVE in this amendment.

Upgrading reduces future exposure but does not prove that authentication bypass, administrative takeover, platform authorization abuse, token or session abuse, SAML or integration-identity impersonation, repository migration abuse, package or cache poisoning, restricted-artifact access, unauthorized service-account file writes, repository-controlled command execution, dependency-update credential exfiltration, dependency-update command injection, dependency-update secret disclosure, release-age-control bypass, Vite sensitive-file disclosure, DeepSeek-Reasonix repository-local configuration poisoning and command execution, malicious module execution, server-side requests, unsafe package processing, or follow-on software-delivery activity did not occur before remediation.

Residual risk should remain elevated until relevant platform, authentication, administrative, repository, configuration, permission, token, SAML, remote-repository, package-cache, artifact, service-account, filesystem, dependency-update, Vite development-server, DeepSeek-Reasonix developer-tool, resynthesis, provisioner, host, network, credential, CI/CD, cloud, Kubernetes, deployment, and change-control telemetry has been reviewed.

Proof-of-Concept / Behavioral Coverage Assessment

This report’s behavioral detection model directly covers self-hosted software-delivery control-plane compromise where observable telemetry shows repository-control activity, workflow modification, unauthorized CI/CD execution, trusted runner execution, credential exposure, protected-variable access, deploy-key abuse, token abuse, webhook abuse, registry activity, package activity, artifact access, cloud activity, Kubernetes activity, deployment activity, or downstream software-delivery trust impact.

The model directly covers CVE-2026-18252 when authenticated developer-role activity causes GitLab Duo’s Claude AI agent to process configuration from a user-controlled source and execute arbitrary commands in a CI context.

The model directly covers CVE-2026-15387 when authenticated developer-role activity influences the execution environment of Pipeline Execution Policy enforcement jobs and observable policy-job, runner, workflow, or downstream CI/CD behavior results.

The model directly covers CVE-2026-7487 when an authenticated reporter-role merge request author improperly resets merge request approval rules and the reset produces observable approval-boundary, repository-control, workflow, protected-branch, CI/CD, package, registry, artifact, cloud, Kubernetes, deployment, or downstream software-delivery behavior.

The model directly covers CVE-2026-60004 when repository write access is used to create or replace a Git hook and execute commands under the Gitea service account.

The model directly covers CVE-2024-5655 when activity results in unauthorized GitLab pipeline execution as another user, CI/CD identity misuse, protected-variable access, runner execution, artifact access, registry access, or downstream deployment activity.

The model directly covers CVE-2024-6385 when activity results in arbitrary GitLab pipeline job execution as another user, CI/CD job execution under another user context, protected-variable access, runner misuse, package or image activity, or deployment-path exposure.

The model directly covers CVE-2024-8970 when activity results in GitLab pipeline triggering as another user under import-related conditions, CI/CD runtime identity mismatch, sensitive workflow execution, protected-variable exposure, or downstream software-delivery identity use.

The model directly covers CVE-2024-11931 when activity results in GitLab protected CI/CD variable exposure through CI lint, CI/CD secret exposure, suspicious CI lint use, software-delivery credential access, or follow-on token, registry, cloud, Kubernetes, or deployment activity.

The model directly covers CVE-2026-4868 when activity results in GitLab Duo AI workflow runners executing under another user identity, unauthorized workflow-runner execution, identity mismatch, privileged CI/CD execution context, protected-variable access, software-delivery credential exposure, or downstream software-delivery activity.

The model directly covers CVE-2026-27771 when activity results in Gitea or Forgejo private container image exposure through container-registry behavior, private image access, registry authentication anomalies, unexpected image pulls, exposed build outputs, or downstream software-delivery trust impact.

The model directly covers CVE-2026-20896 with conditions where Gitea reverse-proxy authentication-boundary abuse, trusted-header identity assertion, user or administrator impersonation, and follow-on repository-control or software-delivery activity are observable.

The model directly covers CVE-2026-27775 with conditions where branch write-permission failure produces unauthorized repository write capability, protected workflow exposure, or downstream CI/CD risk.

The model provides Coverage With Adaptation for CVE-2026-106218 where affected TeamCity Kotlin DSL processing permits a sandbox escape and resulting server-side command execution can be correlated with TeamCity project or build-configuration activity, Kotlin DSL changes, server process or child-process execution, filesystem activity, credential access, repository activity, build activity, artifact activity, network activity, or downstream software-delivery effects.

The model provides Coverage With Adaptation for CVE-2026-106219 where affected TeamCity Git submodule URL handling permits access to local repositories and resulting repository or filesystem access can be correlated with TeamCity project configuration, Git submodule activity, repository access, filesystem telemetry, build activity, credential or secret access, artifact activity, or downstream software-delivery effects.

The model provides Coverage With Adaptation for CVE-2026-100102 where an affected P4 Search container image before 2026.4.2 exposes the Java debug interface to an untrusted network path and resulting code execution or service-account activity can be correlated with P4 Search, host, connected P4 Server, repository, credential, network, or downstream software-delivery telemetry.

The model provides Coverage With Adaptation for CVE-2026-100103 where an affected P4 Search container image before 2026.4.2 uses the documented default service authentication token and unauthenticated highest-privilege application activity can be correlated with administrative actions, process execution, service-account activity, connected P4 Server access, repository activity, credential access, or downstream software-delivery behavior.

The model provides Coverage With Adaptation for CVE-2026-103507 where an affected P4 Search deployment before 2026.4.2 permits a service-authentication-token holder to control logging output paths and resulting arbitrary file writes or code execution can be correlated with logging configuration, filesystem telemetry, service-account execution, connected P4 Server activity, or downstream software-delivery behavior.

The model provides Coverage With Adaptation for CVE-2026-103510 where an affected P4 Search deployment before 2026.4.2 has a blank service authentication token and resulting unauthenticated highest-privilege application activity can be correlated with configuration state, authentication events, administrative actions, process execution, connected P4 Server activity, repository access, or downstream software-delivery behavior.

The model provides Coverage With Adaptation for CVE-2026-103511 where an affected P4 Search deployment before 2026.4.2 processes attacker-controlled filenames during extension installation and resulting arbitrary file writes can be correlated with extension-installation activity, privileged identity or token use, filesystem changes, service-account execution, connected P4 Server activity, or downstream software-delivery behavior.

The model provides Coverage With Adaptation for CVE-2026-103512 where an affected P4 Search deployment before 2026.4.2 trusts attacker-controlled client-address data during P4 Server ticket validation and resulting host-binding or trusted-address bypass can be correlated with ticket use, asserted client address, source network context, authentication activity, repository access, connected P4 Server activity, or downstream software-delivery behavior.

The model provides Coverage With Adaptation for CVE-2026-3035 where unauthorized protected-environment terminal access requires product-specific authorization and environment context before consequential command, credential, deployment, cloud, Kubernetes, registry, or artifact behavior can be reliably identified.

The model provides Coverage With Adaptation for CVE-2026-4398 where unauthorized compliance-framework assignment requires GitLab-specific governance and authorization context before consequential repository-governance, policy, approval, or pipeline effects can be reliably identified.

The model provides Coverage With Adaptation for CVE-2026-19478 where unauthenticated GitLab GraphQL directive abuse produces project or user-data integrity loss and related repository-control uncertainty.

The model provides Coverage With Adaptation for CVE-2026-19650 where unauthenticated GitLab GraphQL mutation behavior produces unexpected platform mutation, project-integrity impact, or downstream software-delivery uncertainty.

The model provides Coverage With Adaptation for CVE-2026-19118 where GitHub Enterprise Server upload-processing race behavior can produce arbitrary code execution but reliable identification requires GitHub Enterprise Server-specific appliance, version, repository-write, upload-processing, execution, and downstream context.

The model provides Coverage With Adaptation for CVE-2026-18730 where GitHub Enterprise Server Manage API SSRF and management-token exposure require management-path, topology, token, outbound-request, and privileged-action context.

The model provides Coverage With Adaptation for CVE-2026-76851 where GitHub Enterprise Server pre-receive-hook SSRF and internal-service impersonation require hook configuration, trusted internal-request, internal-service, execution, and appliance context.

The model provides Coverage With Adaptation for CVE-2026-24451 where fork synchronization after a parent repository privacy change exposes private repository content or affects repository trust.

The model provides Coverage With Adaptation for CVE-2026-28740 where private LFS object exposure affects source material, build inputs, release artifacts, credentials, or other software-delivery material.

The model provides Coverage With Adaptation for CVE-2026-27761 where repository token-scope enforcement failure enables unauthorized repository data access or follow-on software-delivery abuse.

The model provides Coverage With Adaptation for CVE-2026-22874 where webhook or migration SSRF reaches internal services, secret stores, metadata services, CI/CD infrastructure, registries, package systems, cloud endpoints, Kubernetes endpoints, deployment systems, or other software-delivery control-plane components.

The model provides Coverage With Adaptation for CVE-2026-8716, CVE-2026-5296, CVE-2026-2710, CVE-2026-2601, CVE-2024-6595, CVE-2024-6323, CVE-2024-5470, CVE-2024-5430, CVE-2024-4994, CVE-2024-3959, and CVE-2024-2177 where the local initiating path requires platform-specific repository, authorization, workflow, registry, package, identity, or application context but the consequential behavior falls within the report’s existing software-delivery detection model.

The model provides Coverage With Adaptation for CVE-2026-88880 where Renovate interacts with an applicable malicious or compromised GitLab server and follows an attacker-controlled pagination destination supplied through an HTTP Link header while attaching credentials associated with the originating GitLab server. The meaningful behavior maps to trusted dependency-update tooling, GitLab credential exposure, attacker-influenced outbound requests, repository trust loss, credential reuse risk, and potential downstream CI/CD or software-delivery compromise.

The model provides Coverage With Adaptation for CVE-2026-88881 where Renovate interacts with a malicious or compromised GitHub server or applicable GitHub datasource and follows an attacker-controlled pagination destination supplied through an HTTP Link header while attaching credentials configured for the originating GitHub host. The meaningful behavior maps to trusted dependency-update tooling, GitHub credential exposure, attacker-influenced outbound requests, repository trust loss, credential reuse risk, and potential downstream CI/CD or software-delivery compromise.

The model provides Coverage With Adaptation for CVE-2026-88882 where Renovate lists package versions from a malicious or compromised NuGet registry and follows an attacker-controlled pagination destination supplied through an HTTP Link header while attaching registry credentials. The meaningful behavior maps to trusted dependency-update tooling, package-registry credential exposure, attacker-influenced outbound requests, package trust loss, credential reuse risk, and potential downstream CI/CD or software-delivery compromise.

The model provides Coverage With Adaptation for CVE-2026-88883 where Renovate Mutual TLS private-key material configured through hostRules[].httpsPrivateKey can appear elsewhere in Renovate logs without complete sanitization. The meaningful behavior maps to dependency-update secret exposure, log-based credential disclosure, Mutual TLS identity risk, credential reuse or impersonation risk, and potential downstream repository, package, registry, CI/CD, or software-delivery compromise.

The model provides Coverage With Adaptation for CVE-2026-88884 where a repository using minimumReleaseAge receives an applicable digest update and Renovate can raise the digest-update pull request before the configured release-age requirement is internally satisfied. The meaningful behavior maps to dependency-trust weakening, premature pull-request creation, possible premature CI execution, package or image trust uncertainty, and potential downstream software-delivery compromise.

The model provides Coverage With Adaptation for CVE-2026-88885 where self-hosted Renovate operating with binarySource=docker processes an applicable Go module major-version update with gomodUpdateImportPaths and attacker-influenced dependency-name content reaches an external import-path update command. The meaningful behavior maps to repository-controlled or dependency-controlled command input, trusted software-delivery command execution, Renovate-user execution, credential or environment-secret exposure, and possible downstream CI/CD or software-delivery compromise.

The model provides Coverage With Adaptation for CVE-2026-88886 where self-hosted Renovate operating with binarySource=docker and Gradle Wrapper execution explicitly allowed processes a repository-controlled malicious distributionUrl during a Gradle Wrapper update. The meaningful behavior maps to repository-controlled command input, trusted software-delivery command execution, Renovate-user execution, credential or environment-secret exposure, and possible downstream CI/CD or software-delivery compromise.

The model provides Coverage With Adaptation for CVE-2026-88887 where Renovate processes applicable container dependencies and follows an attacker-controlled pagination destination supplied by a malicious or compromised container registry while attaching registry credentials. The meaningful behavior maps to trusted dependency-update tooling, container-registry credential exposure, attacker-influenced outbound requests, package and image trust loss, credential reuse risk, and potential downstream CI/CD or deployment compromise.

The model provides Coverage With Adaptation for CVE-2026-88888 where self-hosted Renovate operating with binarySource=docker processes an applicable private Mix dependency and attacker-influenced organization or package-name content can reach the Hex authentication command path. The meaningful behavior maps to dependency-controlled command input, trusted software-delivery command execution, Renovate-user execution, credential or environment-secret exposure, and potential downstream software-delivery compromise.

The model provides Coverage With Adaptation for CVE-2026-88889 where self-hosted Renovate operating with binarySource=docker processes an applicable Maven Wrapper update and repository-controlled distributionType content reaches the Maven Wrapper command path. The meaningful behavior maps to repository-controlled command input, trusted software-delivery command execution, Renovate-user execution, credential or environment-secret exposure, and potential downstream CI/CD or software-delivery compromise.

The model provides Coverage With Adaptation for CVE-2026-39364 where an exposed affected Vite development server permits a request to bypass intended server.fs.deny restrictions using documented query-parameter behavior and retrieve a file within reachable filesystem scope. The meaningful behavior maps to unauthorized sensitive-file access, development-environment secret exposure, cloud or infrastructure credential disclosure, source-code or configuration exposure, credential reuse risk, and potential downstream CI/CD, cloud, Kubernetes, or software-delivery compromise.

The model provides Coverage With Adaptation for CVE-2025-30208 where an exposed affected Vite development server processes a documented trailing-query-separator filesystem-deny bypass against /@fs/ file-serving behavior. The meaningful behavior maps to unauthorized sensitive-file retrieval, environment and credential disclosure, cloud identity exposure, and potential downstream software-delivery compromise.

The model provides Coverage With Adaptation for CVE-2025-31125 where an exposed affected Vite development server processes the documented ?inline&import / ?raw?import filesystem-deny bypass. The meaningful behavior maps to unauthorized file disclosure, development-environment credential exposure, cloud or infrastructure secret access, and possible downstream software-delivery compromise. CISA KEV status increases remediation and retrospective-hunting urgency.

The model provides Coverage With Adaptation for CVE-2026-102437 where DeepSeek-Reasonix Studio or the DeepSeek Reasonix npm package processes a repository whose local Git configuration and .gitattributes content cause attacker-controlled execution when a developer views a file diff. Reliable attribution requires DeepSeek-Reasonix asset and version context, repository-local .git/config state, .gitattributes content, developer identity and workstation context, diff-rendering activity, process or shell telemetry, filesystem activity, credential access, network activity, and downstream software-delivery evidence. The consequential command execution and follow-on behavior fall within the report’s existing software-delivery detection model.

The model provides Coverage With Adaptation for CVE-2026-78210 where users with certain scoped permission sets can execute arbitrary scripts in an environment without the required authorization. Reliable attribution requires Octopus Server asset and version context, scoped permission state, actor identity, Environment authorization context, script and task execution records, server-process telemetry, deployment activity, and downstream credential, cloud, Kubernetes, or release-integrity evidence.

The model provides Coverage With Adaptation for CVE-2026-102488 where Octopus Server incorrectly evaluates multiple scoped permission assignments and a highly privileged user obtains deployment permissions beyond those actually granted. Reliable attribution requires Octopus Server asset and version context, scoped permission assignments, actor identity, effective deployment permissions, deployment history, change-control evidence, and downstream environment activity.

The model provides Coverage With Adaptation for CVE-2026-102478 where an authenticated Octopus Server user with permission to modify roles abuses unsafe Unicode-equivalence handling to weaken a built-in role and add an account to a privileged team. Reliable attribution requires Octopus Server asset and version context, actor identity, role-modification authority, role and team change history, privilege state, authentication activity, deployment activity, and downstream software-delivery evidence.

The model provides Coverage With Adaptation for CVE-2026-101169 where an authenticated Octopus Server user with Environment or Project editing permission submits crafted JSON that reaches insecure deserialization and results in arbitrary code execution in the Octopus Server process. Reliable attribution requires Octopus Server asset and version context, editor identity and permission context, Environment or Project change history, application and host process telemetry, and downstream deployment, credential, artifact, cloud, Kubernetes, or release-integrity evidence. The consequential execution and downstream behavior fall within the report’s existing software-delivery detection model.

Vite Historical Behavioral Context — Not an Additional Active-Register CVE

CVE-2024-45811 is retained as supporting Vite development-server behavioral context because it documents an earlier ?import&raw filesystem-deny bypass affecting the same durable behavior family: unauthorized file retrieval from an exposed development server and potential disclosure of development-environment secrets.

It does not increase the active CVE register because the current amendment is driven by the newer Vite campaign and currently actionable active-register objects.

The behavior remains relevant for retrospective hunting, control validation, and zero-day interpretation where older Vite deployments may still be exposed.

Affected-version exposure alone is not proof of successful exploitation.

Software-Delivery Behavioral Context — Not Additional Active-Register CVEs

The following material remains in this report because it represents software-delivery behaviors, platform trust boundaries, remediation considerations, and source mappings that remain useful for detection engineering and investigation. These contextual CVEs and named incidents are not additional entries in the 62-CVE active register.

JFrog Artifactory Behavioral Context

The report retains Artifactory behavior coverage where observable activity involves authentication or authorization anomalies, unexpected privilege establishment, administrative-session changes, repository migration, remote-repository access, package-cache manipulation, package or artifact modification, token or SAML abuse, file writes, server-side requests, package-processing behavior, service-account activity, or downstream software-delivery consequences.

Public JFrog advisory material reconciled to this behavior family includes:

·        CVE-2026-82329 — unauthenticated administrative privilege acquisition under documented affected/default conditions. Active in-the-wild exploitation is confirmed by public reporting. CISA added CVE-2026-82329 to the Known Exploited Vulnerabilities Catalog on September 2, 2026

·        CVE-2026-66384 — authenticated path-traversal file-write behavior in Docker remote-repository cache handling

·        CVE-2026-65921 — unauthorized file-write behavior through archive-processing path traversal

·        CVE-2026-65923 — Artifactory-originated server-side requests through Ansible remote-repository handling

·        CVE-2026-65924 — server-side requests through Terraform remote-repository handling

·        CVE-2026-65925 — server-side requests through Cargo remote-repository handling

·        CVE-2026-66014 — authentication weakness and privilege escalation beyond the intended user level

·        CVE-2026-66015 — authenticated privilege escalation under required account conditions

·        CVE-2026-65617 — unsafe deserialization during package handling

·        CVE-2026-66018 — unauthorized access to protected build-environment properties

·        CVE-2026-70551 — VCS remote-download SSRF and requests to attacker-influenced destinations

·        CVE-2026-69104 — unauthorized repository-migration operations

·        CVE-2026-69105 — injection of untrusted package content into cache and resulting artifact-integrity uncertainty

·        CVE-2026-69107 — unauthorized access to restricted artifact content under affected configurations

·        CVE-2026-69106 — low-privilege cache poisoning capable of causing retrieval of untrusted artifact content

·        CVE-2026-42018 — exposure of an internal anonymous-user token under documented conditions. Active in-the-wild exploitation is confirmed. Public exploitation reporting documents use of this condition as the token-exposure component of a chain with CVE-2026-42016 that can result in administrative privilege. CISA added CVE-2026-42018 to the Known Exploited Vulnerabilities Catalog on September 11, 2026

·        CVE-2026-66375 — unauthorized removal of protected internal metadata

·        CVE-2026-68760 — authentication bypass under documented remember-me and cache conditions

·        CVE-2026-66381 — repository access outside a configured upstream content path under documented conditions

·        CVE-2026-66382 — authenticated file write outside the intended Artifactory work directory

·        CVE-2026-66376 — residual unauthorized-session risk for deleted-user credentials

·        CVE-2026-68754 — protected package-content modification despite missing delete authorization

·        CVE-2026-68757 — SAML-response verification weakness and user impersonation

·        CVE-2026-68756 — unsafe deserialization involving stored session data

·        CVE-2026-68752 — Project Resource Manager privilege escalation

·        CVE-2026-68755 — unauthorized modification of trusted release-promotion information

·        CVE-2026-68753 — unauthorized access to restricted content through affected credentialed remote-repository configurations

·        CVE-2026-68759 — user impersonation through a valid integration credential under affected conditions

·        CVE-2026-65922 — restricted internal metadata write by a limited repository user

·        CVE-2026-65616 — refresh-token signature-validation weakness enabling administrator-token acquisition

·        CVE-2026-42017 — exposure of privileged authorization material to a lower-privileged user

·        CVE-2026-42016 — token scope-validation weakness permitting privilege escalation. Active in-the-wild exploitation is confirmed. Public exploitation reporting documents use of this condition as the privilege-escalation component of a chain with CVE-2026-42018. CISA added CVE-2026-42016 to the Known Exploited Vulnerabilities Catalog on September 11, 2026

·        CVE-2026-65618 — URL-validation weakness causing unauthorized Artifactory-originated requests

These CVEs remain contextual supporting mappings rather than additional current-register entries. Reliable identification requires applicable Artifactory asset and version context plus request, session, authentication, administrator, token, SAML, repository, migration, remote-repository, cache, artifact, service-account, filesystem, network, CI/CD, cloud, Kubernetes, deployment, or downstream evidence.

CVE-2026-82329, CVE-2026-42018, and CVE-2026-42016 now have confirmed public exploitation and CISA KEV status. CVE-2026-82329 is independently exploited. CVE-2026-42018 and CVE-2026-42016 have also been observed as a chained exploitation path. Their exploitation state materially increases remediation and retrospective-hunting urgency but does not, by itself, convert them into additional entries in the active 62-CVE behavioral register.

Affected-version exposure alone is not evidence of successful exploitation.

Amazon CodeCatalyst Blueprints SDK Behavioral Context

CVE-2026-85012 remains software-delivery behavioral context because the report already models repository-controlled inputs, workflow and software-delivery execution, unexpected process activity, trusted credentials, artifact and registry activity, cloud and Kubernetes access, and downstream software-delivery consequences.

The documented vulnerable condition affects direct consumers of @amazon-codecatalyst/blueprints.blueprint versions <= 0.3.155 where repository-controlled .ownership-file content in a [local] merge-strategy path can reach operating-system command execution during blueprint resynthesis.

Version 0.3.156 is the corrected release.

AWS states that no action is required for use of the managed Amazon CodeCatalyst service for this condition because managed resynthesis uses isolated per-project environments, scoped credentials, and server-side validation.

Repository write permission, package presence, impacted-version exposure, .ownership-file presence, or ordinary blueprint resynthesis activity alone does not establish successful exploitation.

Coder Registry Supply-Chain Behavioral Context

The Coder Registry supply-chain compromise tracked as GHSA-vx42-ghc9-gw65 remains a named non-CVE Coverage With Adaptation behavioral object.

The incident is retained because it maps directly to malicious registry delivery, package and module trust, cache integrity, trusted provisioner or workflow execution, credential and environment-secret access, suspicious egress, cloud or CI/CD follow-on, and downstream software-delivery effects.

Publicly documented incident context includes:

·        Incident type: confirmed software-supply-chain compromise without a CVE

·        Public incident date: August 31, 2026

·        Documented malicious-delivery window: August 31, 2026 from 07:35 UTC through 21:45 UTC

·        Delivery mechanism: malicious Coder Registry Terraform modules served to a subset of users

·        Corrected supported-branch releases: 2.37.0, 2.36.4, 2.35.7, and 2.34.9

·        Potentially affected activity: template creation or update, template dry runs, and workspace deployment when a registry module was downloaded during the documented window

·        Investigation context: registry backend provenance, registry module-download timing, template or workspace activity, module-cache state, Terraform external-data execution, provisioner context, accessible secret classes, destination evidence, and downstream credential use

·        Publicly documented exfiltration destination: coder-infra[.]com

·        CISA KEV state: not applicable because the incident is not represented by a CVE

This named incident does not change the active CVE register.

Detection Engineering Coverage Interpretation

The S25 detection content provides direct behavioral coverage when suspicious self-hosted Git, repository, workflow, runner, Gitea authentication, reverse-proxy trusted-header, branch permission, token, deploy-key, webhook, registry, package, artifact, cloud, Kubernetes, or deployment activity falls inside the report’s modeled software-delivery control-plane chain.

The S25 detection content provides Coverage With Adaptation when protected-environment authorization failure, compliance-framework assignment abuse, GitLab GraphQL mutation or project-integrity behavior, GitHub Enterprise Server upload-processing race behavior, Manage API SSRF, management-token exposure or replay, pre-receive-hook internal-service redirection, repository data exposure, private object exposure, token-scope failure, webhook or migration internal-service access, dependency-update credential exposure, dependency-update unsafe command execution, dependency-update secret or private-key exposure, dependency-release-age-control weakness, Vite development-server file disclosure, DeepSeek-Reasonix repository-local Git configuration poisoning, agentic workflow prompt injection, Perforce P4 Search authentication or service-token failure, exposed debug access, arbitrary file-write behavior, P4 Server ticket host-binding bypass, or related platform-authentication behavior requires product-specific initiating context but produces consequential software-delivery behavior already modeled by S25.

The S25 model also provides behavioral context for Artifactory activity where observable behavior involves anomalous authentication or authorization, unexpected administrative or privilege changes, token or SAML anomalies, repository migration, remote-repository or cache activity, package or cache integrity changes, unexpected filesystem writes, server-side requests, service-account activity, artifact access, or downstream software-delivery behavior.

For the confirmed Artifactory exploitation activity, coverage is strongest when Artifactory request and identity telemetry can identify anomalous token establishment or scope changes, unexpected administrator creation, unauthorized administrative actions, malicious plugin deployment, command execution, filesystem changes, payload retrieval, suspicious egress, webshell activity, repository access, artifact modification, or other downstream software-delivery consequences.

The S25 model also provides behavioral context for CVE-2026-85012 where repository-control, configuration-change, workflow or software-delivery execution, unexpected process execution, credential-access, abnormal egress, artifact, registry, cloud, Kubernetes, deployment, or downstream-control telemetry captures the meaningful consequences of repository-controlled blueprint metadata reaching a resynthesis command path.

The S25 model also provides Coverage With Adaptation for the Coder Registry supply-chain compromise through registry and package trust, cache-integrity, template or workflow execution, provisioner or runner behavior, credential and environment-secret access, suspicious egress, cloud or CI/CD follow-on, and downstream software-delivery telemetry.

The existing S25 behavior model provides Coverage With Adaptation for CVE-2026-106218 and CVE-2026-106219 where TeamCity-specific initiating context can be correlated with unexpected server-side process or child-process execution, Kotlin DSL or build-configuration changes, Git submodule activity, repository or filesystem access, credential or secret access, build activity, artifact activity, network activity, or downstream software-delivery effects. Product-specific TeamCity context strengthens attribution without creating a new generic detection requirement.

The existing S25 behavior model provides Coverage With Adaptation for CVE-2026-100102, CVE-2026-100103, CVE-2026-103507, CVE-2026-103510, CVE-2026-103511, and CVE-2026-103512 where P4 Search-specific initiating context can be correlated with unexpected authentication or privileged activity, debug-interface access, process or child-process execution, service-account activity, logging changes, filesystem writes, extension-installation activity, P4 Server ticket use, source-address anomalies, repository access, credential access, network activity, connected P4 Server activity, or downstream software-delivery effects. Product-specific initiating context strengthens attribution without creating a new generic detection requirement.

The existing S25 behavior model provides Coverage With Adaptation for CVE-2026-88880, CVE-2026-88881, CVE-2026-88882, CVE-2026-88883, CVE-2026-88884, CVE-2026-88885, CVE-2026-88886, CVE-2026-88887, CVE-2026-88888, and CVE-2026-88889 where dependency-update tooling produces anomalous credential-bearing network requests, unexpected GitHub, GitLab, NuGet, or registry destinations, credential or private-key exposure, unexpected external-command execution, premature dependency-update workflow activity, repository activity, registry activity, package or image activity, CI/CD follow-on, or downstream software-delivery consequences.

The existing S25 behavior model also provides Coverage With Adaptation for CVE-2026-39364, CVE-2025-30208, and CVE-2025-31125 where an exposed Vite development server permits unauthorized file retrieval and the resulting activity can be correlated with sensitive-file access, environment or credential exposure, cloud or infrastructure credential use, suspicious network activity, repository or build-host context, CI/CD activity, cloud activity, Kubernetes activity, deployment behavior, or downstream software-delivery consequences. Vite-specific asset, version, network-exposure, request-path, query-string, filesystem, development-server, and response telemetry is required for reliable local attribution.

The existing S25 behavior model also provides Coverage With Adaptation for CVE-2026-102437 where DeepSeek-Reasonix-specific repository-local Git configuration and .gitattributes context can be correlated with unexpected process or shell execution, filesystem activity, credential or secret access, outbound communication, repository activity, CI/CD activity, cloud or Kubernetes follow-on, or downstream release-integrity impact. Product-specific initiating context strengthens attribution without creating a new generic detection requirement.

The existing S25 behavior model also provides Coverage With Adaptation for CVE-2026-78210, CVE-2026-102488, and CVE-2026-102478 where Octopus Server-specific role, team, scoped-permission, effective-deployment-permission, Environment-authorization, script-execution, deployment, process, identity, credential, network, cloud, Kubernetes, or downstream release-integrity context can be correlated. These product-specific conditions strengthen attribution without creating a new generic detection requirement.

The existing S25 behavior model also provides Coverage With Adaptation for CVE-2026-101169 where Octopus Server-specific initiating context can be correlated with unexpected process or child-process execution, file or configuration changes, credential or secret access, outbound communication, artifact activity, deployment actions, cloud or Kubernetes follow-on, or downstream release-integrity impact.

No new generic S25 rule family is required for CVE-2026-106218, CVE-2026-106219, CVE-2026-100102, CVE-2026-100103, CVE-2026-103507, CVE-2026-103510, CVE-2026-103511, CVE-2026-103512, CVE-2026-73802, CVE-2026-102437, CVE-2026-78210, CVE-2026-102488, CVE-2026-102478, CVE-2026-101169, or for these Vite, Renovate, or Artifactory exploitation updates.

Detection coverage should be interpreted as behavior-led coverage, not CVE-string or exploit-name coverage.

CVE identifiers, product names, package names, repository names, actor labels, source IPs, domains, user agents, proof-of-concept labels, scanner labels, pagination header values, configuration-property values, or named exploit strings should not be used as primary detection inputs unless locally approved as enrichment supporting triage.

Direct Coverage

Direct Coverage applies where observable activity aligns with unauthorized repository workflow execution, Git hook creation or replacement, Gitea service-account command execution, trusted CI/CD runner execution, software-delivery credential misuse, protected-variable exposure, workflow-runner identity misuse, pipeline-policy enforcement abuse, merge-request approval-control abuse, registry exposure, package or image exposure, artifact exposure, reverse-proxy trusted-header impersonation, administrative impersonation, branch write-permission abuse, repository authorization-boundary failure, or software-delivery control-plane trust impact.

Directly Covered CVEs

·        CVE-2026-18252

·        CVE-2026-15387

·        CVE-2026-7487

·        CVE-2026-60004

·        CVE-2026-27775

·        CVE-2026-27771

·        CVE-2026-20896

·        CVE-2026-4868

·        CVE-2024-11931

·        CVE-2024-8970

·        CVE-2024-6385

·        CVE-2024-5655

CVE-2026-18252 should be counted as Direct Coverage when authenticated developer-role activity causes GitLab Duo’s Claude AI agent to process configuration from a user-controlled source and arbitrary commands execute in a CI context.

CVE-2026-15387 should be counted as Direct Coverage when authenticated developer-role activity influences the execution environment of Pipeline Execution Policy enforcement jobs and observable policy-job, runner, workflow, or downstream CI/CD behavior results.

CVE-2026-7487 should be counted as Direct Coverage when an authenticated reporter-role merge request author improperly resets merge request approval rules and the reset produces observable approval-boundary, repository-control, workflow, protected-branch, CI/CD, package, registry, artifact, cloud, Kubernetes, deployment, or downstream software-delivery behavior.

CVE-2026-20896 should be counted as Direct Coverage only when trusted-header authentication abuse is observable through anomalous authentication, impersonation, repository-control activity, token or deploy-key creation, webhook modification, workflow execution, package or registry access, administrative action, CI/CD activity, cloud activity, Kubernetes activity, or downstream deployment behavior.

CVE-2026-27775 should be counted as Direct Coverage only when branch write-permission abuse is observable through unauthorized repository write activity, protected branch or workflow modification, repository-control activity, workflow execution, token or deploy-key creation, package or registry access, artifact activity, CI/CD activity, cloud activity, Kubernetes activity, or downstream deployment behavior.

CVE-2026-60004 should be counted as Direct Coverage when authenticated repository write access is used to create or replace a Git hook and execute shell commands under the Gitea service account.

Affected-version exposure, open registration, repository creation, ordinary repository write permission, or proof-of-concept availability without observable execution or follow-on behavior should remain exposure-management or hunting context rather than confirmed compromise.

Coverage With Adaptation

Coverage With Adaptation applies to related Git, CI/CD, registry, package, artifact, authentication, authorization, repository-governance, protected-environment authorization, compliance-framework authorization, GitLab GraphQL request validation, GitHub Enterprise Server repository-upload processing, GitHub Enterprise Server management APIs, management-token trust, pre-receive-hook behavior, project or user-data integrity, reverse-proxy, webhook, migration, SSRF, private object, repository-data exposure, token-scope, Gitea Actions workflow definition, act_runner container configuration, Docker HostConfig pass-through, host namespace or capability exposure, runner-host execution, dependency-update tooling, GitHub, GitLab, NuGet, or registry credential handling, dependency-manager external-command execution, dependency-update log sanitization, Mutual TLS secret handling, dependency-release-age enforcement, Vite development-server file-serving and filesystem-deny enforcement, development-environment secret exposure, DeepSeek-Reasonix repository-local Git configuration and attribute handling, Octopus Server Environment or Project editing, authenticated crafted-content processing, insecure deserialization, role and team modification, scoped-permission evaluation, deployment-permission enforcement, Environment authorization, unauthorized script execution, Perforce P4 Search authentication-token handling, exposed debug interfaces, service-token trust, extension installation, log-path file writes, P4 Server ticket host binding, AI-assisted development tooling, or agentic workflow issues where the local incident shows behavior that can be linked to repository-control activity, unauthorized platform mutation, privileged Git-platform execution, workflow execution, runner-host execution, credential exposure, private repository exposure, internal-service access, registry activity, package activity, artifact access, deployment activity, or downstream control-plane activity.

CVEs Covered With Adaptation

·        CVE-2026-106218

·        CVE-2026-106219

·        CVE-2026-100102

·        CVE-2026-100103

·        CVE-2026-103507

·        CVE-2026-103510

·        CVE-2026-103511

·        CVE-2026-103512

·        CVE-2026-73802

·        CVE-2026-102437

·        CVE-2026-78210

·        CVE-2026-102488

·        CVE-2026-102478

·        CVE-2026-101169

·        CVE-2026-39364

·        CVE-2025-31125

·        CVE-2025-30208

·        CVE-2026-88889

·        CVE-2026-88888

·        CVE-2026-88887

·        CVE-2026-88886

·        CVE-2026-88885

·        CVE-2026-88884

·        CVE-2026-88883

·        CVE-2026-88882

·        CVE-2026-88881

·        CVE-2026-88880

·        CVE-2026-76851

·        CVE-2026-19118

·        CVE-2026-18730

·        CVE-2026-87817

·        CVE-2026-3035

·        CVE-2026-4398

·        CVE-2026-28740

·        CVE-2026-27761

·        CVE-2026-24451

·        CVE-2026-22874

·        CVE-2026-19650

·        CVE-2026-19478

·        CVE-2026-8716

·        CVE-2026-5296

·        CVE-2026-2710

·        CVE-2026-2601

·        CVE-2024-6595

·        CVE-2024-6323

·        CVE-2024-5470

·        CVE-2024-5430

·        CVE-2024-4994

·        CVE-2024-3959

·        CVE-2024-2177

CVE-2026-106218 remains Coverage With Adaptation because the initiating condition depends on an affected TeamCity deployment, attacker-controlled or untrusted Kotlin DSL content reaching the vulnerable sandbox-processing path, and execution escaping the intended sandbox boundary. Coverage becomes strongest when TeamCity asset and version context, project or build-configuration changes, Kotlin DSL activity, server process and child-process execution, filesystem changes, credential or secret access, repository activity, network activity, build activity, artifact activity, or downstream software-delivery effects can be correlated. Affected-version exposure or ordinary Kotlin DSL use alone is not evidence of successful exploitation.

CVE-2026-106219 remains Coverage With Adaptation because the initiating condition depends on an affected TeamCity deployment and Git submodule URL input reaching the vulnerable validation path in a manner that permits local repository access. Coverage becomes strongest when TeamCity asset and version context, repository configuration, Git submodule activity, local repository access, filesystem telemetry, build activity, credential or secret access, artifact activity, network activity, or downstream software-delivery effects can be correlated. Affected-version exposure or ordinary Git submodule use alone is not evidence of successful exploitation.

CVE-2026-100102 remains Coverage With Adaptation because the initiating condition depends on an affected Perforce P4 Search container image before 2026.4.2 with the Java debug interface exposed to a reachable network path. Coverage becomes strongest when P4 Search asset and version context, debug-port reachability, process and child-process execution, service-account activity, filesystem changes, credential access, network connections, connected P4 Server activity, and downstream software-delivery effects can be correlated. Affected-version exposure or debug-port reachability alone is not evidence of successful exploitation.

CVE-2026-100103 remains Coverage With Adaptation because the initiating condition depends on an affected P4 Search container image before 2026.4.2 and a publicly documented default service authentication token that permits an unauthenticated network attacker to obtain the highest application privilege. Coverage becomes strongest when network access, authentication-token use, privileged P4 Search activity, process execution, service-account activity, filesystem changes, connected P4 Server activity, credential access, and downstream software-delivery effects can be correlated. Affected-version exposure alone is not evidence of successful exploitation.

CVE-2026-103507 remains Coverage With Adaptation because the initiating condition depends on an affected P4 Search version before 2026.4.2, possession of the service authentication token, and attacker-controlled logging output paths that can produce arbitrary file writes on the host. Coverage becomes strongest when service-token use, logging-configuration changes, filesystem writes, P4 Search service-account process execution, credential access, network activity, connected P4 Server activity, and downstream software-delivery effects can be correlated. Affected-version exposure or possession of a valid token alone is not evidence of successful exploitation.

CVE-2026-103510 remains Coverage With Adaptation because the initiating condition depends on an affected P4 Search version before 2026.4.2 with a blank service authentication token that causes the application to fail open and grant the highest application privilege to an unauthenticated network attacker. Coverage becomes strongest when configuration state, network reachability, unauthenticated privileged activity, administrative actions, process execution, service-account behavior, connected P4 Server activity, credential access, and downstream software-delivery effects can be correlated. Affected-version exposure alone is not evidence of successful exploitation.

CVE-2026-103511 remains Coverage With Adaptation because the initiating condition depends on an affected P4 Search version before 2026.4.2, super-user or service-token privilege, and attacker-controlled filenames supplied to the extension-installation feature. Coverage becomes strongest when privileged identity or token use, extension-installation activity, filesystem writes inside the P4 Search installation directory, process execution, service-account activity, credential access, connected P4 Server activity, and downstream software-delivery effects can be correlated. Affected-version exposure or ordinary extension administration alone is not evidence of successful exploitation.

CVE-2026-103512 remains Coverage With Adaptation because the initiating condition depends on an affected P4 Search version before 2026.4.2, possession of a stolen P4 Server ticket, and client-supplied address data used during authentication validation to bypass host-binding or trusted-address restrictions. Coverage becomes strongest when ticket use, asserted client address, source network context, authentication events, P4 Search identity activity, connected P4 Server access, repository activity, credential use, and downstream software-delivery effects can be correlated. Affected-version exposure or possession of a valid ticket alone is not evidence of successful exploitation.

CVE-2026-73802 remains Coverage With Adaptation because the initiating condition depends on an affected Gitea act_runner version, a repository user able to define or modify an Actions workflow, attacker-controlled values reaching jobs.<job>.container.options, and Docker HostConfig options that can alter host namespace, Linux capability, or security-profile behavior despite privileged mode being disabled. Coverage becomes strongest when repository and workflow authorship, Actions workflow changes, act_runner job execution, container configuration, Docker runtime behavior, host namespace or capability changes, unexpected runner-host process execution, credential or secret access, filesystem activity, network activity, registry or artifact access, cloud or Kubernetes activity, or downstream build and deployment effects can be correlated. Affected-version exposure, ordinary workflow execution, or the presence of a self-hosted runner alone is not evidence of successful exploitation.

CVE-2026-102437 remains Coverage With Adaptation because the initiating condition depends on an affected DeepSeek-Reasonix Studio or DeepSeek Reasonix npm version, repository-local Git configuration containing attacker-controlled filter behavior, .gitattributes content selecting the affected filter path, and a developer action that causes the affected diff-rendering path to process the repository. Coverage becomes strongest when repository-local .git/config and .gitattributes state can be correlated with developer diff activity, unexpected child-process or shell execution, command-line anomalies, filesystem changes, credential access, network activity, CI/CD activity, cloud or Kubernetes activity, or downstream software-delivery effects. Affected-version exposure, repository presence, or ordinary diff viewing alone is not evidence of successful exploitation.

CVE-2026-78210 remains Coverage With Adaptation because the initiating condition depends on an affected Octopus Server version, applicable scoped permission sets, an Environment authorization boundary, and script execution occurring without the required authorization. Coverage becomes strongest when scoped permissions, actor identity, Environment access, script or task execution, server-process activity, deployment actions, credential or secret access, outbound communication, cloud or Kubernetes activity, or downstream release-integrity effects can be correlated. Affected-version exposure or ordinary authorized script execution alone is not evidence of successful exploitation.

CVE-2026-102488 remains Coverage With Adaptation because the initiating condition depends on an affected Octopus Server version, multiple scoped permission assignments, a highly privileged user context, and incorrect effective-permission evaluation that can grant deployment authority beyond what was intended. Coverage becomes strongest when scoped assignments, effective permissions, actor identity, deployment activity, Environment or Project changes, change-control records, and downstream software-delivery effects can be correlated. Affected-version exposure or the presence of multiple scoped assignments alone is not evidence of successful exploitation.

CVE-2026-102478 remains Coverage With Adaptation because the initiating condition depends on an affected Octopus Server version, an authenticated user with permission to modify roles, unsafe Unicode-equivalence handling, and resulting role or team changes that can expand privilege. Coverage becomes strongest when role modification, built-in role state, privileged-team membership, actor identity, authentication activity, deployment actions, process activity, credential access, or downstream software-delivery effects can be correlated. Affected-version exposure or role-modification permission alone is not evidence of successful exploitation.

CVE-2026-101169 remains Coverage With Adaptation because the initiating condition depends on an affected self-hosted Octopus Server version, an authenticated user with Environment or Project editing permission, crafted JSON reaching the vulnerable server-side deserialization path, and execution occurring in the Octopus Server process. Coverage becomes strongest when Environment or Project changes and editor identity can be correlated with unexpected Octopus Server process or child-process execution, file or configuration changes, credential or secret access, outbound communication, artifact activity, deployment actions, cloud or Kubernetes activity, or downstream release-integrity effects. Affected-version exposure or editing permission alone is not evidence of successful exploitation.

CVE-2026-39364 remains Coverage With Adaptation because the initiating condition depends on an affected Vite development-server version, network exposure of the development server, applicable server.fs.allow and server.fs.deny context, attacker-controlled /@fs/ file requests, query-parameter bypass behavior, and the presence of sensitive files inside reachable filesystem scope. Coverage becomes strongest when unauthorized file-read requests can be correlated with HTTP 200 responses, access to environment files, cloud credentials, Infrastructure-as-Code state, process-environment data, certificates, application source, subsequent credential use, cloud or Kubernetes activity, CI/CD activity, or downstream software-delivery effects.

CVE-2025-30208 remains Coverage With Adaptation because the initiating condition depends on an exposed affected Vite development server and the documented trailing-query-separator bypass behavior affecting /@fs/ file access. Coverage becomes strongest when bypass-style requests can be correlated with successful sensitive-file responses, credential or environment exposure, subsequent credential use, cloud activity, CI/CD activity, or other downstream software-delivery effects.

CVE-2025-31125 remains Coverage With Adaptation because the initiating condition depends on an exposed affected Vite development server and the documented ?inline&import / ?raw?import filesystem-deny bypass. CISA KEV status confirms exploitation in the wild and increases remediation and retrospective-hunting urgency, but local compromise should be established through request, response, file-access, credential-use, cloud, CI/CD, or incident-response evidence.

CVE-2026-88880 remains Coverage With Adaptation because the initiating condition depends on Renovate-specific GitLab pagination behavior, an originating GitLab server, HTTP Link-header content, credential configuration, destination-origin validation, and network evidence. Coverage becomes strongest when an unexpected pagination destination can be correlated with a credential-bearing request, repository activity, token use, credential reuse, CI/CD activity, package activity, registry activity, cloud activity, Kubernetes activity, deployment behavior, or downstream software-delivery effects.

CVE-2026-88881 remains Coverage With Adaptation because the initiating condition depends on Renovate-specific GitHub pagination behavior, the originating GitHub server or datasource, HTTP Link-header content, credential configuration, destination-origin validation, and network evidence. Coverage becomes strongest when an unexpected pagination destination can be correlated with a credential-bearing request, repository activity, token use, credential reuse, CI/CD activity, package activity, registry activity, cloud activity, Kubernetes activity, deployment behavior, or downstream software-delivery effects.

CVE-2026-88882 remains Coverage With Adaptation because the initiating condition depends on Renovate-specific NuGet pagination behavior, the originating registry, HTTP Link-header content, registry credential configuration, destination-origin validation, and network evidence. Coverage becomes strongest when an unexpected pagination destination can be correlated with a credential-bearing request, credential reuse, package activity, CI/CD activity, cloud activity, deployment behavior, or downstream software-delivery effects.

CVE-2026-88883 remains Coverage With Adaptation because the initiating condition depends on Renovate-specific Mutual TLS configuration, hostRules[].httpsPrivateKey use, log-sanitization behavior, log-access context, and whether sensitive key material appears elsewhere in configuration or logged fields. Coverage becomes strongest when exposed key material can be correlated with unauthorized log access, subsequent Mutual TLS identity use, repository or registry access, credential reuse, CI/CD activity, or downstream software-delivery effects.

CVE-2026-88884 remains Coverage With Adaptation because the initiating condition depends on Renovate-specific minimumReleaseAge configuration and an applicable digest update. Coverage becomes strongest when a premature pull request or CI execution can be correlated with newly published dependency content, package or image activity, workflow execution, artifact creation, cloud or Kubernetes activity, deployment behavior, or downstream software-delivery effects.

CVE-2026-88885 remains Coverage With Adaptation because the initiating condition depends on the Renovate Go module manager, binarySource=docker, a major-version Go module update, gomodUpdateImportPaths, attacker-influenced dependency-name content, and external-command execution. Coverage becomes strongest when the initiating path can be correlated with unexpected Renovate-user process execution, command-line anomalies, filesystem or network activity, credential access, CI/CD activity, cloud or Kubernetes activity, or downstream software-delivery effects.

CVE-2026-88886 remains Coverage With Adaptation because the initiating condition depends on the Renovate Gradle Wrapper manager, binarySource=docker, allowedUnsafeExecutions permitting gradleWrapper, repository-controlled gradle-wrapper.properties content, a malicious distributionUrl, and a Gradle Wrapper update. Coverage becomes strongest when the initiating path can be correlated with unexpected Renovate-user process execution, filesystem or network activity, credential access, CI/CD activity, cloud or Kubernetes activity, or downstream software-delivery effects.

CVE-2026-88887 remains Coverage With Adaptation because the initiating condition depends on Renovate-specific container-registry pagination behavior, the originating registry, container dependency processing, HTTP Link-header content, registry credential configuration, destination-origin validation, and network evidence. Coverage becomes strongest when an unexpected pagination destination can be correlated with a credential-bearing registry request, credential reuse, image or package activity, CI/CD activity, cloud activity, Kubernetes activity, deployment behavior, or downstream software-delivery effects.

CVE-2026-88888 remains Coverage With Adaptation because the initiating condition depends on the Renovate Mix manager, binarySource=docker, private Mix dependencies, attacker-influenced package or organization input, and Hex authentication command execution. Coverage becomes strongest when the initiating path can be correlated with unexpected Renovate-user process execution, credential exposure, filesystem or network activity, package or registry activity, CI/CD activity, or downstream software-delivery effects.

CVE-2026-88889 remains Coverage With Adaptation because the initiating condition depends on the Renovate Maven Wrapper manager, binarySource=docker, repository-controlled Maven Wrapper configuration, a malicious distributionType, and a Maven Wrapper update. Coverage becomes strongest when the initiating path can be correlated with unexpected Renovate-user process execution, filesystem or network activity, credential access, CI/CD activity, cloud or Kubernetes activity, or downstream software-delivery effects.

CVE-2026-76851 remains Coverage With Adaptation because the GitHub Enterprise Server initiating path depends on product-specific pre-receive-hook networking, hook configuration or modification authority, trusted internal-request behavior, privileged internal-service access, and appliance execution evidence.

CVE-2026-19118 remains Coverage With Adaptation because the GitHub Enterprise Server TOCTOU initiating path depends on precise concurrent upload timing, repository-write authorization, validated-content replacement, product-specific upload-processing behavior, appliance execution evidence, and affected-version context.

CVE-2026-18730 remains Coverage With Adaptation because the GitHub Enterprise Server Manage API SSRF path depends on product-specific cluster-configuration parsing, management gateway-to-agent behavior, outbound management requests, replayable management bearer-token exposure, topology, and privileged management activity.

CVE-2026-87817 remains Coverage With Adaptation because the initiating condition depends on GitPython-specific repository discovery, an affected GitPython version before 3.1.60, attacker-controlled repository content capable of impersonating Git-directory structures through repository-controlled gitdir, commondir, HEAD, or hook content, and GitPython activity that reaches the affected path. Coverage becomes strongest when this repository context can be correlated with unexpected Git hook or command execution and consequential software-delivery activity.

CVE-2026-3035 remains Coverage With Adaptation unless local telemetry demonstrates that unauthorized protected-environment terminal access produced consequential command execution, deployment modification, credential access, cloud or Kubernetes activity, registry or artifact activity, or other software-delivery control-plane behavior sufficient for stronger classification.

CVE-2026-4398 remains Coverage With Adaptation unless local telemetry demonstrates that unauthorized compliance-framework assignment altered policy enforcement, repository governance, approval controls, pipeline execution policy, or downstream software-delivery behavior sufficient for stronger classification.

CVE-2026-19478 remains Coverage With Adaptation unless local telemetry demonstrates that unauthenticated GraphQL directive abuse directly produced repository-control, workflow, credential, registry, package, CI/CD, cloud, Kubernetes, or deployment-control behavior sufficient for stronger classification.

CVE-2026-19650 remains Coverage With Adaptation unless local telemetry demonstrates that unauthenticated GraphQL mutations produced repository-control, workflow, permission, credential, registry, package, CI/CD, cloud, Kubernetes, or deployment-control behavior sufficient for stronger classification.

Related GitLab GraphQL, GitHub Enterprise Server, Gitea, Forgejo, Renovate, reverse-proxy, self-hosted Git, repository-upload, management API, management-token, pre-receive-hook, webhook, migration, SSRF, token-scope, private-object, repository-data exposure, protected-environment authorization, compliance-framework authorization, platform-authentication, dependency-update tooling, Vite development-server file disclosure, DeepSeek-Reasonix repository-local configuration poisoning, Perforce P4 Search authentication, debug-interface, file-write or ticket-validation behavior, development-environment secret exposure, agentic workflow, or AI-assisted repository tooling issues should remain Coverage With Adaptation unless observable activity maps to repository-control, workflow execution, privileged Git-platform execution, credential exposure, internal-service access, registry activity, package activity, CI/CD activity, cloud activity, Kubernetes activity, or deployment-control behavior strongly enough to support Direct Coverage.

Non-CVE Behavior-Led Coverage

Non-CVE behavior-led coverage applies where a source-supported Git platform, CI/CD, registry, software-supply-chain, or agentic workflow security issue does not carry a CVE identifier in the active register but still maps to the report’s S25 software-delivery control-plane behavior model.

These items do not increase the Direct or Adapted CVE counts.

Direct Non-CVE Behavior-Led Items

·        Gitea Actions fork PR approval-gate bypass

The model directly covers the Gitea Actions fork PR approval-gate bypass because the behavior aligns with unauthorized workflow execution, CI/CD approval-gate weakness, workflow YAML trust abuse, and trusted software-delivery execution.

Adapted Non-CVE Behavior-Led Items

·        Coder Registry supply-chain compromise — GHSA-vx42-ghc9-gw65

·        Gitea stale OIDC external-login-link account-confusion behavior

·        Gitea SSH LFS unknown sub-verb authentication-bypass prevention

·        Gitea hostmatcher private/reserved-address filtering fixes

·        GitLost GitHub Agentic Workflows prompt-injection private-repository exposure

The Coder Registry supply-chain compromise remains Coverage With Adaptation because the report already models malicious or unauthorized registry and package delivery, cache integrity, template or workflow execution, provisioner and runner behavior, credential and environment-secret access, suspicious egress, cloud or CI/CD activity, and downstream software-delivery effects, while reliable attribution requires Coder-specific product and telemetry context.

The remaining adapted non-CVE items require platform-specific identity, object-access, SSRF/internal-service, or agentic workflow input/output telemetry rather than a separate first-class S25 object.

Limited / Non-Direct Platform CVE Examples

Limited or non-direct coverage applies where a CVE affects a related software-delivery 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, branch write authorization, reverse-proxy authentication, repository token-scope boundaries, private-object access, dependency-update credential handling, agentic workflow behavior, or downstream software-delivery behavior.

Limited / Non-Direct CVE Examples

·        CVE-2021-22205

CVE-2021-22205 remains relevant to self-managed GitLab exposure, but it is not Direct Coverage unless exploitation leads to repository-control activity, workflow modification, runner misuse, credential access, registry activity, artifact access, package activity, cloud activity, Kubernetes activity, deployment behavior, or downstream software-delivery impact.

Explicit Exclusions From the Active CVE Register

The following JFrog Artifactory CVEs remain intentionally outside the active 62-CVE register because their documented behavior was assessed as metadata-only exposure, highly privileged or local-only conditions, lower-value information disclosure, or behavior not independently meeting the active-register materiality gate:

·        CVE-2026-70550

·        CVE-2026-70548

·        CVE-2026-70547

·        CVE-2026-66016

·        CVE-2026-65926

·        CVE-2026-66378

·        CVE-2026-66380

·        CVE-2026-68758

·        CVE-2026-66377

·        CVE-2026-66379

The following existing exclusions remain unchanged:

·        CVE-2026-25038 remains excluded because available Gitea public security context maps more closely to private organization metadata leakage than to this report’s material software-delivery control-plane model

·        Gitea private organization label leakage remains excluded unless future public evidence ties the behavior to source-code exposure, workflow manipulation, token exposure, registry activity, package activity, artifact access, CI/CD execution, cloud activity, Kubernetes activity, deployment behavior, or downstream impact

·        Gitea notification-subject leakage after repository-access revocation remains excluded unless future public evidence establishes material source-code, credential, workflow, token, package, registry, artifact, CI/CD, cloud, Kubernetes, deployment, or downstream impact

·        Gitea private-repository anonymous-clone behavior remains excluded when it reflects intended anonymous Code-unit access without unauthorized workflow execution, credential exposure, token abuse, registry activity, package activity, artifact access, cloud activity, Kubernetes activity, deployment behavior, or downstream impact

·        Gitea CODEOWNERS regex match-time issues remain excluded unless future public evidence ties them to repository-control compromise, approval bypass, workflow execution, protected-branch bypass, credential exposure, CI/CD activity, package or registry activity, artifact activity, cloud activity, Kubernetes activity, or deployment impact

·        Debian ParseControlFile bounds issues remain excluded unless future public evidence ties the behavior to repository-control compromise, workflow execution, credential exposure, package activity, registry activity, artifact activity, cloud activity, Kubernetes activity, deployment behavior, or downstream software-delivery impact

·        Dependency-update security items remain excluded unless the documented behavior materially affects repository control, workflow execution, credential exposure, registry or package trust, artifact trust, cloud activity, Kubernetes activity, deployment behavior, or downstream software delivery

CVE-2026-88880, CVE-2026-88881, CVE-2026-88882, CVE-2026-88883, CVE-2026-88884, CVE-2026-88885, CVE-2026-88886, CVE-2026-88887, CVE-2026-88888, and CVE-2026-88889 meet that materiality gate because their publicly documented behavior can expose trusted software-delivery credentials or private-key material, weaken configured dependency-trust controls, or cause repository-controlled or dependency-controlled input to reach trusted Renovate execution paths. They are therefore included in the active register as Coverage With Adaptation.

CVE-2026-39364, CVE-2025-30208, and CVE-2025-31125 meet the materiality gate because their documented behavior can bypass intended Vite development-server filesystem restrictions and expose development-environment files, credentials, infrastructure state, source material, or other secrets capable of enabling downstream software-delivery compromise.

CVE-2026-102437 meets the materiality gate because repository-local Git configuration and .gitattributes content can cause attacker-controlled commands to execute under the developer context when the affected DeepSeek-Reasonix diff-rendering path is reached.

CVE-2026-106218 and CVE-2026-106219 meet the materiality gate because their documented TeamCity behaviors can permit server-side command execution through Kotlin DSL sandbox escape or unauthorized access to local repository content through insufficient Git submodule URL validation within a trusted software-delivery control-plane component.

CVE-2026-100102, CVE-2026-100103, CVE-2026-103507, CVE-2026-103510, CVE-2026-103511, and CVE-2026-103512 meet the materiality gate because their documented P4 Search behaviors can permit unauthenticated or improperly trusted privileged access, arbitrary code execution, arbitrary file writes, authentication-boundary bypass, or use of stolen P4 Server tickets against a software-delivery control-plane component connected to source-code infrastructure.

CVE-2024-45811 remains supporting historical Vite behavioral context and does not increase the active register.

Named Malware / Tooling / Exploit-Framework Coverage

Named malware, tooling, exploit-framework, scanner, proof-of-concept, Git platform, artifact platform, dependency-update tool, Vite development server, DeepSeek-Reasonix, Perforce P4 Search, AI agent, prompt-injection label, reverse proxy, package, registry, CI/CD, runner, cloud, Kubernetes, webhook, migration, SSRF, management API, management-token, pre-receive-hook, blueprint SDK, provisioner, or deployment coverage should be interpreted as behavior-led coverage only.

A tool name, exploit name, scanner label, proof-of-concept label, source IP, user agent, payload artifact, prompt string, repository name, package name, image tag, header name, feature name, configuration-file name, or CVE label should not be used as a primary detection input unless locally approved as enrichment supporting triage.

Named Actor / Campaign Activity Coverage

Actor, campaign, ransomware, cybercrime, cloud-extortion, supply-chain, initial-access, platform-exploitation, AI-agent-abuse, or prompt-injection coverage should be treated as enrichment and coverage context only.

The report does not detect actor names directly.

It detects the behavior actors, affiliates, operators, or toolchains may produce when abusing self-hosted Git platforms, GitLab GraphQL functionality, GitHub Enterprise Server repository-upload or management functionality, pre-receive hooks, Gitea authentication boundaries, reverse proxies, branch permissions, repository workflows, Git hooks, software-delivery service accounts, Renovate dependency-update tooling, Vite development servers, DeepSeek-Reasonix or similar Git-wrapping developer tooling, Perforce P4 Search and connected P4 Server trust paths, artifact repositories, blueprint-resynthesis environments, registry-delivered modules, agentic workflows, CI/CD runners, deploy keys, tokens, webhooks, registry credentials, package credentials, cloud credentials, Kubernetes credentials, deployment identities, or software-delivery control-plane paths.

Active Exploitation and KEV Coverage Interpretation

Active exploitation, probing, proof-of-concept availability, and KEV status should be treated as urgency and remediation-prioritization signals, not as detection coverage by themselves.

Public advisory publication, proof-of-concept availability, critical or high severity, release inclusion, scanner coverage, or named research should not be treated as proof of successful compromise in a local environment without supporting authentication, repository, management, workflow, hook, dependency-update, Vite development-server, DeepSeek-Reasonix developer-tool, P4 Search, agentic, administrative, registry, package, CI/CD, cloud, Kubernetes, or deployment telemetry.

CVE-2026-82329 is confirmed as actively exploited in the wild. CISA added CVE-2026-82329 to the Known Exploited Vulnerabilities Catalog on September 2, 2026. Public exploitation reporting establishes successful unauthenticated administrative compromise against affected Artifactory instances and observed follow-on administrative and execution activity. This exploitation path is distinct from the CVE-2026-42018 and CVE-2026-42016 chain.

CVE-2026-42018 and CVE-2026-42016 are confirmed as actively exploited in the wild. CISA added both vulnerabilities to the Known Exploited Vulnerabilities Catalog on September 11, 2026.

Public exploitation reporting documents multiple actors chaining CVE-2026-42018 and CVE-2026-42016 against self-hosted Artifactory. CVE-2026-42018 can expose an internal anonymous-user token, and CVE-2026-42016 can permit low-privilege token scope to be escalated to administrative authority. Observed follow-on activity includes persistent administrator-account creation, malicious Groovy plugin deployment, arbitrary command execution, second-stage payload delivery, webshell activity, and custom Rust backdoor deployment.

These three Artifactory vulnerabilities remain contextual software-delivery mappings. Their exploitation and KEV status materially increase remediation and retrospective-hunting urgency but do not independently alter their contextual classification or increase the active 62-CVE register.

CVE-2025-31125 is CISA KEV-confirmed and should be counted as an actively exploited / in-the-wild vulnerability in the current active register. Its KEV status increases remediation and retrospective-hunting urgency for exposed affected Vite development servers but does not independently establish that a specific local server disclosed files or credentials.

F5 Labs reported sustained August 2026 mass scanning against exposed Vite development servers, including probes matching CVE-2026-39364 and CVE-2025-30208 and recurring signatures for older Vite filesystem-bypass flaws. The observed activity targeted .env files, AWS credentials, Azure tokens, Infrastructure-as-Code state, and process-environment data. This source-qualified sensor evidence should be retained as active probing / exploitation-attempt context. It should not, by itself, be counted as proof that CVE-2026-39364 or CVE-2025-30208 successfully disclosed data on a specific victim system.

CVE-2026-60004 was added to the CISA Known Exploited Vulnerabilities Catalog on August 25, 2026 based on evidence of active exploitation. The KEV addition increases remediation and retrospective-hunting urgency but does not independently establish successful compromise in a local environment or change its Direct Coverage classification.

CVE-2026-19478 is represented as actively exploited / in-the-wild based on public reporting of watchTowr honeypot observations. This source-qualified exploitation state increases remediation and retrospective-hunting urgency for affected self-managed GitLab installations but does not independently establish successful compromise in a local environment or change its Coverage With Adaptation classification.

CVE-2026-19650 should continue to be treated as an urgent remediation item for affected installations, but public disclosure, severity, proof-of-concept availability, scanner coverage, or unauthenticated exploitability should not by themselves be counted as confirmed active exploitation.

CVE-2026-19118, CVE-2026-18730, and CVE-2026-76851 do not change the current active-register exploitation or KEV counts.

CVE-2026-100102, CVE-2026-100103, CVE-2026-103507, CVE-2026-103510, CVE-2026-103511, and CVE-2026-103512 do not change the current active-register exploitation or KEV counts. No authoritative public active-exploitation evidence or CISA KEV designation is established in the source set supporting this amendment.

CVE-2026-102437 does not change the current active-register exploitation or KEV counts. No authoritative public active-exploitation claim or CISA KEV designation is established in the source set supporting this amendment.

CVE-2026-78210, CVE-2026-102488, and CVE-2026-102478 do not change the current active-register exploitation or KEV counts. Octopus Deploy states that its security team is not aware of public announcements or malicious use of these vulnerabilities, and no CISA KEV designation is established in the source set supporting this amendment.

CVE-2026-73802 does not change the current active-register exploitation or KEV counts. No confirmed in-the-wild exploitation or CISA KEV designation is established in the source set supporting this amendment.

CVE-2026-101169 does not change the current active-register exploitation or KEV counts. Octopus Deploy reported no known public announcement or malicious use before disclosure, and no CISA KEV designation is established in the source set supporting this amendment.

CVE-2026-88880, CVE-2026-88881, CVE-2026-88882, CVE-2026-88883, CVE-2026-88884, CVE-2026-88885, CVE-2026-88886, CVE-2026-88887, CVE-2026-88888, and CVE-2026-88889 do not change the current active-register exploitation or KEV counts. No authoritative public active-exploitation or CISA KEV state is assigned to these Renovate vulnerabilities.

CVE-2026-60004 and CVE-2025-31125 are the two CISA KEV-confirmed CVEs in the current active register.

CVE-2026-19478 is counted as actively exploited / in-the-wild but is not counted as CISA KEV-confirmed.

The active behavioral register therefore contains 3 exploited / in-the-wild vulnerabilities and 2 CISA KEV-confirmed vulnerabilities.

Separately, the contextual Artifactory vulnerability set contains 3 vulnerabilities confirmed as actively exploited and CISA KEV-listed:

·        CVE-2026-82329 — actively exploited / in-the-wild; CISA KEV added September 2, 2026

·        CVE-2026-42018 — actively exploited / in-the-wild; CISA KEV added September 11, 2026

·        CVE-2026-42016 — actively exploited / in-the-wild; CISA KEV added September 11, 2026

These contextual Artifactory vulnerabilities do not alter the active register’s 3 exploited / 2 KEV count because they are not additional active-register entries.

Non-Coverage Conditions

Non-coverage applies where related activity does not produce observable suspicious repository-control activity, GitLab GraphQL mutation or project-integrity activity, GitHub Enterprise Server upload-processing or management-path activity, pre-receive-hook internal-service activity, Git hook creation or replacement, Gitea service-account execution, platform-authentication abuse, branch write abuse, dependency-update credential exposure, dependency-update command execution, dependency-update secret disclosure, dependency-release-age-control impact, Vite sensitive-file disclosure, DeepSeek-Reasonix attacker-controlled execution, P4 Search authentication-boundary abuse, P4 Search privileged activity, P4 Search arbitrary file writes, P4 Search service-account execution, P4 Server ticket misuse, workflow execution, runner execution, blueprint-resynthesis command execution, malicious registry-module execution, artifact-platform administrative or service-account activity, agentic workflow misuse, private repository exposure, credential access, token creation, deploy-key creation, webhook modification, package access, registry access, artifact access, unauthorized filesystem writes, internal-service access, cloud activity, Kubernetes activity, deployment activity, or downstream software-delivery impact.

For CVE-2026-100102, CVE-2026-100103, CVE-2026-103507, CVE-2026-103510, CVE-2026-103511, and CVE-2026-103512, non-coverage applies where the environment does not run an affected P4 Search version, the applicable debug interface, authentication-token, logging-path, extension-installation, or ticket host-binding condition is not present, required attacker credentials or tokens are not available where applicable, or reliable P4 Search, P4 Server, authentication, process, filesystem, network, repository, credential, and incident-response evidence establishes that no unauthorized privilege, file write, code execution, identity use, repository access, or consequential software-delivery activity occurred.

For CVE-2026-73802, non-coverage applies where the environment does not run an affected Gitea act_runner version, the relevant user cannot define or modify an Actions workflow, attacker-controlled jobs.<job>.container.options content does not reach the affected Docker HostConfig handling path, the supplied container options do not alter host namespace, capability, security-profile, or equivalent runner-host security boundaries, or reliable workflow, runner, container, Docker, host-process, filesystem, credential, secret, network, registry, artifact, cloud, Kubernetes, deployment, and incident-response evidence establishes that no unauthorized runner-host execution or consequential software-delivery activity occurred.

For CVE-2026-102437, non-coverage applies where the environment does not run an affected DeepSeek-Reasonix Studio or DeepSeek Reasonix npm version, repository-local .git/config does not contain the attacker-controlled filter configuration, .gitattributes does not select the affected filter path, the vulnerable diff-rendering path is not reached, or reliable repository, process, filesystem, credential, network, CI/CD, cloud, Kubernetes, and incident-response evidence establishes that no attacker-controlled command execution or consequential software-delivery activity occurred.

For CVE-2026-78210, non-coverage applies where the environment does not run an affected Octopus Server version, the applicable scoped permission condition is not present, the user possesses the required Environment authorization, or reliable permission, Environment, script, task, process, deployment, network, cloud, Kubernetes, and incident-response evidence establishes that no unauthorized script execution or consequential software-delivery activity occurred.

For CVE-2026-102488, non-coverage applies where the environment does not run an affected Octopus Server version, the vulnerable multiple-scoped-permission evaluation condition is not present, effective deployment permissions remain within the intended grants, or reliable permission, identity, deployment, change-control, and incident-response evidence establishes that no unauthorized deployment authority or consequential software-delivery activity occurred.

For CVE-2026-102478, non-coverage applies where the environment does not run an affected Octopus Server version, the user cannot modify roles, the unsafe Unicode-equivalence condition is not reached, or reliable role, team, identity, authentication, privilege, deployment, and incident-response evidence establishes that no unauthorized privilege expansion or consequential software-delivery activity occurred.

For CVE-2026-101169, non-coverage applies where the environment does not run an affected self-hosted Octopus Server version, the user does not have Environment or Project editing permission, crafted JSON does not reach the vulnerable deserialization path, or reliable Environment or Project change, application, process, file, configuration, credential, network, deployment, cloud, Kubernetes, and incident-response evidence establishes that no unauthorized server-process execution or consequential software-delivery activity occurred.

For CVE-2026-88880, non-coverage applies where Renovate is not running an affected version, does not interact with the applicable malicious or compromised GitLab server required by the vulnerability, does not process an attacker-controlled pagination destination, or reliable telemetry establishes that configured GitLab credentials were not transmitted to an unintended destination.

For CVE-2026-88881, non-coverage applies where Renovate is not running an affected version, does not interact with the malicious or compromised GitHub server or applicable GitHub datasource required by the vulnerability, does not process an attacker-controlled pagination destination, or reliable telemetry establishes that configured GitHub credentials were not transmitted to an unintended destination.

For CVE-2026-88882, non-coverage applies where Renovate is not running an affected version, does not interact with the malicious or compromised NuGet registry required by the vulnerability, does not process an attacker-controlled pagination destination, or reliable telemetry establishes that registry credentials were not transmitted to an unintended destination.

For CVE-2026-88883, non-coverage applies where Renovate is not running an affected version, Mutual TLS is not configured through the affected hostRules[].httpsPrivateKey path, sensitive private-key material does not appear elsewhere in logged configuration or messages, or reliable evidence establishes that no sensitive key material was exposed through accessible logs.

For CVE-2026-88884, non-coverage applies where Renovate is not running an affected version, minimumReleaseAge is not configured, no applicable digest updates are processed, digest updates are disabled or approval-gated, or reliable evidence establishes that no premature dependency-update pull request or consequential CI activity occurred.

For CVE-2026-88885, non-coverage applies where Renovate is not running an affected version, binarySource=docker is not used, the Go module manager is not processing the required major-version update path, gomodUpdateImportPaths is not enabled, attacker-influenced dependency-name content is absent, or reliable telemetry establishes that no unintended external command executed.

For CVE-2026-88886, non-coverage applies where Renovate is not running an affected version, binarySource=docker is not used, gradleWrapper is not allowed through allowedUnsafeExecutions, the affected Gradle Wrapper update path is not reached, a malicious distributionUrl is absent, or reliable telemetry establishes that no unintended command executed.

For CVE-2026-88887, non-coverage applies where Renovate is not running an affected version, does not process applicable container dependencies, does not interact with the malicious or compromised container registry required by the vulnerability, does not process an attacker-controlled pagination destination, or reliable telemetry establishes that registry credentials were not transmitted to an unintended destination.

For CVE-2026-88888, non-coverage applies where Renovate is not running an affected version, binarySource=docker is not used, private Mix dependencies are not processed, attacker-influenced package or organization input is absent, or reliable telemetry establishes that no unintended command or credential-handling behavior occurred.

For CVE-2026-88889, non-coverage applies where Renovate is not running an affected version, binarySource=docker is not used, the Maven Wrapper manager does not process the repository, malicious distributionType content is absent, no applicable Maven Wrapper update occurs, or reliable telemetry establishes that no unintended command executed.

For CVE-2026-39364, CVE-2025-30208, and CVE-2025-31125, non-coverage applies where the environment does not run an affected Vite development-server version, the development server is not reachable from an untrusted network path applicable to the vulnerability, the targeted file is not inside reachable filesystem scope, the documented bypass path is not reached, or reliable request, response, filesystem, credential, cloud, and incident-response evidence establishes that no unauthorized sensitive-file retrieval or consequential credential use occurred.

For CVE-2026-85012 contextual coverage, non-coverage applies where the environment uses only the managed Amazon CodeCatalyst service, does not directly consume affected package versions, or repository-controlled ownership metadata does not reach the documented vulnerable resynthesis path.

For the Coder Registry supply-chain compromise, non-coverage applies where the organization did not use an affected Coder version during the documented malicious-delivery window, did not download a registry module during that window, or reliable evidence establishes that no affected registry module was retained or executed.

For Artifactory contextual coverage, non-coverage applies where activity remains limited to affected-version exposure, ordinary authentication or repository permissions without misuse, expected remote-repository and cache activity within intended boundaries, expected package or archive processing, authorized administrative activity, authorized SAML or token use, authorized service-account file activity within approved paths, expected migration operations, metadata-only disclosure without material software-delivery consequence, or server-side requests limited to approved destinations.

For CVE-2026-82329, affected-version state or isolated probing alone is insufficient to establish local compromise. Confidence increases when anomalous unauthenticated activity is correlated with unauthorized administrative access, administrator-account creation, configuration or token access, plugin deployment, command execution, payload retrieval, webshell activity, repository or artifact access, or suspicious egress.

For CVE-2026-42018 and CVE-2026-42016, affected-version state alone is insufficient to establish local compromise. Confidence increases when anomalous internal anonymous-token activity, low-privilege token establishment, token-scope escalation, unexpected privileged actions, administrator-account creation, plugin activity, command execution, payload retrieval, webshell activity, or other post-compromise behavior is observed.

Affected-version exposure, internet reachability, vulnerability-scanner identification, isolated unauthenticated requests, ordinary authenticated requests, repository write permission, ordinary Renovate operation, ordinary registry access, or a CVE identifier alone should not be treated as evidence of compromise.

Non-coverage also applies where required Git, GitLab, GitHub Enterprise Server, Gitea, Renovate, Vite, DeepSeek-Reasonix, Perforce P4 Search, P4 Server, artifact-platform, CodeCatalyst, Coder, identity, SAML, token, repository, remote-repository, package, cache, module-cache, template, workspace, provisioner, filesystem, workflow, resynthesis, CI/CD, runner, endpoint, network, registry, artifact, cloud, Kubernetes, deployment, change-control, or SIEM telemetry is unavailable or cannot be joined reliably.

Activity should not be counted when it is better explained by approved repository or Git hook maintenance, pre-receive-hook maintenance, GitHub Enterprise Server administration, Renovate maintenance, dependency-update configuration, Vite development-server testing or approved development activity, DeepSeek-Reasonix approved developer activity involving trusted repository configuration, P4 Search administration, P4 Server administration, approved extension installation, logging configuration, service-token rotation, workflow maintenance, release engineering, GitLab administration, runner migration, reverse-proxy maintenance, Gitea administration, artifact-platform administration, Coder administration, package publication, image publication, registry maintenance, artifact retention, webhook maintenance, migration activity, cloud deployment, Kubernetes deployment, security testing, vulnerability management, or incident response.

Current Coverage Count

Directly Covered CVEs

12

CVEs Covered With Adaptation

50

Total CVEs Directly or Adaptively Covered by This Report’s Current Active Behavioral Detection Register

62

Limited / Non-Direct Software-Delivery Platform CVE Examples

1

Direct Non-CVE Behavior-Led Items

1

Adapted Non-CVE Behavior-Led Items

5

Known Exploited / Actively Exploited / In-the-Wild Vulnerabilities in the Active Register

3

·        CVE-2026-60004 — CISA KEV-confirmed based on evidence of active exploitation

·        CVE-2026-19478 — actively exploited / in-the-wild based on public reporting of watchTowr honeypot observations

·        CVE-2025-31125 — CISA KEV-confirmed based on evidence of active exploitation

CVE-2026-106218 and CVE-2026-106219 do not change this count because no authoritative public active-exploitation evidence is established in the source set supporting this amendment.

CVE-2026-100102, CVE-2026-100103, CVE-2026-103507, CVE-2026-103510, CVE-2026-103511, and CVE-2026-103512 do not change this count because no authoritative public active-exploitation evidence is established in the source set supporting this amendment.

CVE-2026-102437 does not change this count because no authoritative public active-exploitation evidence is established in the source set supporting this amendment.

The Renovate vulnerabilities in the active register do not change this count.

CVE-2026-78210, CVE-2026-102488, and CVE-2026-102478 do not change this count because no authoritative malicious exploitation is established in the source set supporting this amendment.

CVE-2026-101169 does not change this count because no authoritative malicious exploitation is established in the source set supporting this amendment.

CVE-2026-73802 does not change this count because no confirmed in-the-wild exploitation is established in the source set supporting this amendment.

The three actively exploited Artifactory vulnerabilities are contextual mappings and therefore do not change this active-register count.

CISA KEV-Confirmed Subset in the Active Register

2

·        CVE-2026-60004

·        CVE-2025-31125

CVE-2026-19478 is actively exploited / in-the-wild but is not counted as CISA KEV-confirmed.

CVE-2026-106218 and CVE-2026-106219 are not counted as CISA KEV-confirmed.

CVE-2026-100102, CVE-2026-100103, CVE-2026-103507, CVE-2026-103510, CVE-2026-103511, and CVE-2026-103512 are not counted as CISA KEV-confirmed.

CVE-2026-102437 is not counted as CISA KEV-confirmed.

CVE-2026-88880, CVE-2026-88881, CVE-2026-88882, CVE-2026-88883, CVE-2026-88884, CVE-2026-88885, CVE-2026-88886, CVE-2026-88887, CVE-2026-88888, and CVE-2026-88889 are not counted as CISA KEV-confirmed.

CVE-2026-78210, CVE-2026-102488, and CVE-2026-102478 are not counted as CISA KEV-confirmed.

CVE-2026-101169 is not counted as CISA KEV-confirmed.

CVE-2026-73802 is not counted as CISA KEV-confirmed.

Contextual Artifactory Actively Exploited / In-the-Wild Vulnerabilities

3

·        CVE-2026-82329

·        CVE-2026-42018

·        CVE-2026-42016

Contextual Artifactory CISA KEV-Confirmed Vulnerabilities

3

·        CVE-2026-82329 — added September 2, 2026

·        CVE-2026-42018 — added September 11, 2026

·        CVE-2026-42016 — added September 11, 2026

These contextual counts are maintained separately and do not increase the active 62-CVE register or alter its 3 exploited / 2 KEV accounting.

Coverage Qualification

Coverage is strong for behaviorally visible repository workflow abuse, GitLab GraphQL mutation or project-integrity abuse, GitHub Enterprise Server management or execution abuse, Git hook creation or replacement, Gitea service-account command execution, Gitea trusted-header authentication abuse, branch write-permission abuse, GitLab Duo AI agent command execution in a CI context, Pipeline Execution Policy abuse, merge-request approval-rule abuse, dependency-update credential exfiltration that produces observable abnormal destination or credential-use behavior, dependency-update command injection that produces observable process, filesystem, network, credential, or downstream activity, dependency-update secret disclosure that can be tied to exposed log material and subsequent identity use, minimum-release-age bypass that produces observable premature pull-request or CI execution, Vite development-server file disclosure correlated with sensitive-file or credential exposure, DeepSeek-Reasonix repository-local configuration poisoning correlated with attacker-controlled process execution, Perforce P4 Search authentication-boundary abuse, exposed debug-interface activity, service-token misuse, arbitrary file-write behavior, extension-installation abuse, P4 Server ticket host-binding bypass, artifact-platform activity that produces observable unauthorized administrative, identity, repository, package, cache, file-write, or downstream effects, repository-controlled blueprint configuration reaching trusted execution, Coder Registry module abuse, agentic workflow prompt injection, and software-delivery control-plane activity that can be joined across Git, GitLab, GitHub Enterprise Server, GitHub, Gitea, Renovate, Vite, DeepSeek-Reasonix, P4 Search, P4 Server, Artifactory, CodeCatalyst, Coder, identity-provider, management, hook, agentic workflow, CI/CD, runner, registry, package, artifact, filesystem, webhook, migration, network, cloud, Kubernetes, deployment, and change-control telemetry.

Coverage is weaker for silent valid-administration abuse, exposure-only affected-version state, ordinary repository permissions without misuse, authentication anomalies without consequential activity, Renovate affected-version exposure without pagination and destination evidence, command-path evidence, log-access evidence, or minimum-release-age and digest-update evidence, Vite affected-version exposure without evidence of untrusted reachability or successful file retrieval, DeepSeek-Reasonix affected-version exposure without evidence that repository-local filter configuration reached the vulnerable diff-processing path or caused execution, P4 Search affected-version exposure without the applicable debug-interface, service-token, logging-path, extension-installation, ticket, authentication, filesystem, process, network, or P4 Server evidence, normal remote-repository caching inside intended paths, metadata-only disclosure, low-value package or repository information exposure, highly privileged or local-only operations, repository-controlled metadata without execution evidence, managed CodeCatalyst service use that AWS states requires no action for CVE-2026-85012, ordinary Coder use outside the documented compromise path, agentic workflow configurations without private-repository access or public output capability, private-object exposure without software-delivery impact, token-scope weakness without access evidence, or SSRF behavior without internal-service impact.

Coverage for the Perforce P4 Search cohort is strongest when P4 Search version and asset inventory, container-image provenance, network reachability, debug-port exposure, service-authentication-token state and use, P4 Server ticket and host-binding context, privileged P4 Search actions, extension-installation activity, logging configuration, filesystem writes, service-account process execution, credential access, connected P4 Server activity, repository access, network connections, and downstream software-delivery effects can be correlated.

Coverage for CVE-2026-102437 is strongest when DeepSeek-Reasonix version and asset inventory, repository-local .git/config content, .gitattributes history, repository provenance, developer identity, diff-view activity, endpoint process and command-line telemetry, filesystem activity, credential access, DNS, proxy or firewall telemetry, and downstream CI/CD, cloud, Kubernetes, deployment, or incident-response evidence can be correlated.

Coverage for CVE-2026-78210 is strongest when Octopus Server version and asset inventory, scoped permission state, Environment authorization, actor identity, script and task execution records, application and server-process telemetry, deployment activity, credential and secret access, network connections, cloud and Kubernetes activity, change-control records, and incident-response evidence can be correlated.

Coverage for CVE-2026-102488 is strongest when Octopus Server version and asset inventory, scoped permission assignments, effective permission calculations, actor identity, deployment permissions, Environment and Project activity, deployment records, change-control records, and incident-response evidence can be correlated.

Coverage for CVE-2026-102478 is strongest when Octopus Server version and asset inventory, role-modification permissions, role-definition history, privileged-team membership changes, actor identity, authentication events, deployment records, process activity, credential access, change-control records, and incident-response evidence can be correlated.

Coverage for CVE-2026-101169 is strongest when Octopus Server version and asset inventory, Environment and Project editor permissions, object-change history, application logs, server-process and child-process telemetry, file and configuration telemetry, credential and secret access, network connections, artifact activity, deployment records, cloud and Kubernetes activity, change-control records, and incident-response evidence can be correlated.

Coverage for CVE-2026-88880 is strongest when Renovate version and asset inventory, GitLab host configuration, HTTP request and response telemetry, pagination Link-header context, destination origin, credential configuration, endpoint or process telemetry, DNS, proxy or firewall evidence, repository activity, and downstream credential use can be correlated.

Coverage for CVE-2026-88881 is strongest when Renovate version and asset inventory, GitHub host or datasource configuration, HTTP request and response telemetry, pagination Link-header context, destination origin, credential configuration, endpoint or process telemetry, DNS, proxy or firewall evidence, repository activity, and downstream credential use can be correlated.

Coverage for CVE-2026-88882 is strongest when Renovate version and asset inventory, NuGet registry configuration, HTTP request and response telemetry, pagination Link-header context, destination origin, registry credential configuration, endpoint or process telemetry, DNS, proxy or firewall evidence, package activity, CI/CD activity, and downstream credential use can be correlated.

Coverage for CVE-2026-88883 is strongest when Renovate version and asset inventory, hostRules configuration, Mutual TLS private-key inventory, secret-management configuration, Renovate logs, log-access records, endpoint telemetry, authentication events, network activity, and subsequent use of the affected certificate or key material can be correlated.

Coverage for CVE-2026-88884 is strongest when Renovate version and configuration, minimumReleaseAge settings, dependency and digest-update records, pull-request creation timestamps, stability-check state, CI workflow execution, package or image publication times, artifact creation, and downstream deployment behavior can be correlated.

Coverage for CVE-2026-88885 is strongest when Renovate version and configuration, binarySource state, Go module dependency inventory, postUpdateOptions, repository content, dependency-name values, process and command-line telemetry, filesystem activity, network activity, credential access, CI/CD activity, and downstream execution can be correlated.

Coverage for CVE-2026-88886 is strongest when Renovate version and configuration, binarySource state, allowedUnsafeExecutions, Gradle Wrapper configuration, distributionUrl history, repository commit history, process and command-line telemetry, filesystem activity, network activity, credential access, CI/CD activity, and downstream execution can be correlated.

Coverage for CVE-2026-88887 is strongest when Renovate version and asset inventory, container dependency inventory, registry configuration, HTTP request and response telemetry, pagination Link-header context, destination origin, registry credential configuration, endpoint or process telemetry, DNS, proxy or firewall evidence, package or image activity, CI/CD activity, and downstream credential use can be correlated.

Coverage for CVE-2026-88888 is strongest when Renovate version and configuration, binarySource state, Mix dependency inventory, private-dependency configuration, package and organization values, process and command-line telemetry, Hex credential use, filesystem activity, network activity, CI/CD activity, and downstream execution can be correlated.

Coverage for CVE-2026-88889 is strongest when Renovate version and configuration, binarySource state, Maven Wrapper configuration, distributionType history, repository commit history, process and command-line telemetry, filesystem activity, network activity, credential access, CI/CD activity, and downstream execution can be correlated.

Coverage for the Vite development-server family is strongest when Vite version and asset inventory, development-server exposure state, host and container mapping, reverse-proxy or ingress configuration, HTTP request and response telemetry, /@fs/ request paths, query-string values, response status and size, filesystem scope, server.fs.allow and server.fs.deny configuration, file-access telemetry where available, credential inventory, cloud audit telemetry, CI/CD context, DNS, proxy, firewall, and incident-response evidence can be correlated. Particular attention should be given to retrieval attempts for .env files, AWS credentials, Azure tokens, Terraform state, process environment data, certificates, private source material, and other secrets.

Coverage for Artifactory contextual behavior is strongest when asset and affected-version inventory, platform requests, authentication state, session context, authorization and administrative activity, SAML and token events, repository activity, remote-repository activity, migration operations, configuration and permission changes, package-cache behavior, package or artifact state, service-account activity, filesystem changes, network connections, CI/CD activity, deployment activity, cloud activity, and Kubernetes activity can be correlated.

Coverage for CVE-2026-82329 exploitation is strongest when affected Artifactory asset context and anomalous unauthenticated activity can be correlated with unauthorized administrative privilege, unexpected administrator-account creation, configuration or token access, privileged administrative actions, plugin deployment, command execution, filesystem changes, payload retrieval, webshell activity, repository or artifact access, or suspicious network activity.

Coverage for the CVE-2026-42018 and CVE-2026-42016 exploitation chain is strongest when Artifactory telemetry can correlate anomalous internal anonymous-token activity with low-privilege token creation or scope escalation, unexpected privileged actions, administrator-account creation, plugin activity, command execution, payload delivery, filesystem modification, webshell activity, or suspicious egress.

Coverage for CVE-2026-85012 contextual behavior is strongest when impacted package inventory, repository commit history, .ownership-file changes, contributor identity, blueprint resynthesis logs, process execution telemetry, command-line context, runtime identity, credential availability, network connections, artifact or registry activity, deployment activity, cloud activity, Kubernetes activity, and downstream software-delivery effects can be correlated.

Coverage for the Coder Registry supply-chain compromise is strongest when Coder version and asset inventory, the August 31 exposure window, registry backend provenance, registry module-download evidence, template and workspace events, module-cache state, Terraform external-data execution, provisioner process and environment context, accessible secret classes, DNS, proxy, firewall or VPC flow evidence, public malicious-destination evidence, and downstream credential use can be correlated.

The report should not claim universal exploit detection, universal GitLab GraphQL exploit detection, universal GitHub Enterprise Server exploit detection, universal TOCTOU detection, universal Manage API SSRF detection, universal management-token theft or replay detection, universal pre-receive-hook exploitation detection, universal Gitea detection, universal Git hook detection, universal Renovate detection, universal pagination-origin detection, universal credential-exfiltration detection, universal command-injection detection, universal secret-log-exposure detection, universal dependency-release-age bypass detection, universal Vite development-server file-disclosure detection, universal DeepSeek-Reasonix ConfigPoisoning detection, universal P4 Search exploit detection, universal Artifactory authentication-bypass detection, universal administrator-takeover detection, universal token or SAML detection, universal package-cache poisoning detection, universal path-traversal detection, universal SSRF detection, universal service-account execution detection, universal blueprint-resynthesis command-injection detection, universal Coder Registry compromise detection, universal AI-agent detection, universal self-hosted software-delivery platform coverage, universal CI/CD coverage, universal CVE coverage, or standalone attribution.

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 or named proof-of-concept activity.

Future zero-day or proof-of-concept activity affecting self-hosted Git platforms, GitHub Enterprise Server appliances, GitHub organizations, GitLab GraphQL functionality, Gitea, Forgejo, dependency-update tooling, GitHub, GitLab, NuGet, or container-registry credential handling, dependency-manager external-command execution, software-delivery secret handling, dependency-release-age controls, Vite development servers and development-environment filesystem boundaries, DeepSeek-Reasonix or similar developer tooling that consumes repository-local Git configuration, Perforce P4 Search or connected P4 Server authentication and service boundaries, artifact repositories, repository write permissions, repository-controlled project metadata, blueprint and resynthesis frameworks, registry-delivered infrastructure modules, Git hooks, software-delivery service accounts, authentication or administrative privilege boundaries, SAML or token trust, repository migration, package caches, remote repositories, release-promotion state, CI/CD workflows, agentic workflows, privileged software-delivery credentials, protected variables, package registries, container registries, artifact stores, webhook behavior, internal-service reachability, deployment systems, cloud identity, or Kubernetes identity should still be detectable when it produces the same operational behaviors.

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 software-delivery control-plane compromise, unauthorized GitLab project or user-data modification, GitHub Enterprise Server arbitrary code execution or management-boundary compromise, repository write-permission abuse, unauthorized Git hook or pre-receive-hook execution, Gitea service-account command execution, trusted-header authentication abuse, dependency-update credential exfiltration, dependency-update command execution, dependency-update secret or private-key disclosure, dependency-trust-control bypass, Vite development-server sensitive-file or credential disclosure, DeepSeek-Reasonix repository-local configuration poisoning and attacker-controlled developer-context execution, Perforce P4 Search authentication bypass or service-account code execution, artifact-platform administrator takeover, artifact-platform identity or token abuse, package or cache poisoning, restricted-artifact access, service-account file-write abuse, repository-controlled command execution during blueprint resynthesis, malicious registry-module execution, privileged software-delivery credential exposure, branch authorization failure, private repository or object exposure, webhook or internal-service access, agentic workflow prompt injection, or suspected repository workflow abuse creates uncertainty around whether trusted software delivery remained reliable.

The strategic risk is not one CVE or one exploit. It is the possibility that attackers can compromise or cast doubt on the systems that authenticate users, authorize repository actions, interpret repository-controlled software-delivery metadata, process repository-local Git configuration, execute developer-tool diff operations, execute dependency-update and software-delivery processes, operate connected source-code search and indexing services, use trusted GitHub, GitLab, NuGet, registry, P4 Search, and P4 Server credentials or tickets, protect software-delivery secrets, expose development-environment secrets through improperly reachable development infrastructure, enforce dependency-age controls, cache packages, store artifacts, build software, execute infrastructure modules, publish packages or images, promote releases, execute CI/CD workflows, deploy production changes, and maintain business-critical software.

S40 — References

Perforce P4 Search Security Advisory Sources

·        Perforce Support Portal — CVE-2026-100102 — P4 Search exposed Java debug interface permitting unauthenticated remote code execution in affected container images before 2026.4.2 — hxxps://portal[.]perforce[.]com/s/cve/a91Qi000003FE7NIAW/rce-via-exposed-jdwp-debug-agent-in-p4search

·        Perforce Support Portal — CVE-2026-100103 — P4 Search default service authentication token permitting unauthenticated highest-privilege application access in affected container images before 2026.4.2 — hxxps://portal[.]perforce[.]com/s/cve/a91Qi000003FE8zIAG/authentication-bypass-via-default-auth-token-in-p4search

·        Perforce Support Portal — CVE-2026-103507 — P4 Search logging-output-path control permitting arbitrary file writes by a service-authentication-token holder in affected versions before 2026.4.2 — hxxps://portal[.]perforce[.]com/s/cve/a91Qi000003FE49IAG/arbitrary-filewrite-via-log-configuration-path-in-p4search

·        Perforce Support Portal — CVE-2026-103510 — P4 Search blank service authentication token fail-open condition permitting unauthenticated highest-privilege application access in affected versions before 2026.4.2 — hxxps://portal[.]perforce[.]com/s/cve/a91Qi000003FDw5IAG/authentication-bypass-via-blank-auth-token-in-p4search

·        Perforce Support Portal — CVE-2026-103511 — P4 Search extension-installation filename validation weakness permitting arbitrary-content file writes by a super-user or service-token holder in affected versions before 2026.4.2 — hxxps://portal[.]perforce[.]com/s/cve/a91Qi000003FDpdIAG/arbitrary-filewrite-via-extension-installation-in-p4search

·        Perforce Support Portal — CVE-2026-103512 — P4 Search client-address trust weakness permitting P4 Server ticket host-binding or trusted-address bypass in affected versions before 2026.4.2 — hxxps://portal[.]perforce[.]com/s/cve/a91Qi000003FDo1IAG/ticket-hostbinding-bypass-via-spoofed-client-ip-in-p4search

DeepSeek-Reasonix Repository Configuration / Command-Execution Sources

·        GitLab Threat Research — DeepSeek-Reasonix ConfigPoisoning / CVE-2026-102437 — October 2, 2026 — documents malicious repository-local Git configuration and .gitattributes behavior capable of causing attacker-controlled command execution when a developer views a file diff; corrected in DeepSeek-Reasonix Studio 2.21.0 and DeepSeek Reasonix npm 1.39.3

·        GitHub Advisory Database — GHSA-grg2-7gc6-36m6 — CVE-2026-102437 — DeepSeek-Reasonix repository configuration poisoning and command-execution vulnerability — hxxps://github[.]com/advisories/GHSA-grg2-7gc6-36m6

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

Vite Development Server File-Disclosure and Credential-Harvesting Sources

·        F5 Labs — Cloud Takeover: Mass Scanning for Exposed Vite Endpoints (CVE-2026-39364) — September 11, 2026 — hxxps://www[.]f5[.]com/labs/articles/cloud-takeover-mass-scanning-for-exposed-vite-endpoints-cve-2026-39364

·        Vite / GitHub Security Advisory — GHSA-v2wj-q39q-566r — CVE-2026-39364 — server.fs.deny bypass with query parameters; affected Vite 7.1.0 through 7.3.1 and 8.0.0 through 8.0.4; corrected in 7.3.2 and 8.0.5 — hxxps://github[.]com/vitejs/vite/security/advisories/GHSA-v2wj-q39q-566r

·        Vite / GitHub Security Advisory — GHSA-x574-m823-4x7w — CVE-2025-30208 — server.fs.deny bypass using trailing query separators; corrected in 6.2.3, 6.1.2, 6.0.12, 5.4.15, and 4.5.10 — hxxps://github[.]com/vitejs/vite/security/advisories/GHSA-x574-m823-4x7w

·        Vite / GitHub Security Advisory — GHSA-4r4m-qw57-chr8 — CVE-2025-31125 — ?inline&import / ?raw?import filesystem-deny bypass; corrected in 6.2.4, 6.1.3, 6.0.13, 5.4.16, and 4.5.11 — hxxps://github[.]com/vitejs/vite/security/advisories/GHSA-4r4m-qw57-chr8

·        CISA — Known Exploited Vulnerabilities Catalog — CVE-2025-31125 — Vite improper access control / file-disclosure vulnerability — hxxps://www[.]cisa[.]gov/known-exploited-vulnerabilities-catalog

·        Vite / GitHub Security Advisory — GHSA-9cwx-2883-4wfx — CVE-2024-45811 — historical/supporting Vite filesystem-deny bypass using ?import&raw; retained as behavioral context rather than an additional active-register CVE — hxxps://github[.]com/vitejs/vite/security/advisories/GHSA-9cwx-2883-4wfx

Vendor / Platform Documentation

·        JetBrains — Security Issues Fixed — TeamCity — CVE-2026-106218 — Kotlin DSL sandbox escape permitting server-side remote code execution in affected TeamCity versions before 2026.1.3 / 2025.11.7 — CVSS 8.8 High hxxps://www[.]jetbrains[.]com/privacy-security/issues-fixed/

·        JetBrains — Security Issues Fixed — TeamCity — CVE-2026-106219 — insufficient validation of Git submodule URLs permitting reads of local repositories on the TeamCity server in versions before 2026.2.1 — CVSS 6.5 Medium

hxxps://www[.]jetbrains[.]com/privacy-security/issues-fixed/

·        JetBrains TeamCity — TeamCity 2026.2.1 and 2026.1.5 Are Out — October 5, 2026 — documents two TeamCity On-Premises bug-fix releases addressing more than 40 security vulnerabilities combined and recommends upgrading as soon as possible hxxps://blog[.]jetbrains[.]com/teamcity/2026/10/teamcity-2026-2-1-2026-1-5-bugfix/

·        Octopus Deploy — Security Advisory 2026-13 — CVE-2026-78210 — incorrect authorization permitting users with certain scoped permission sets to execute arbitrary scripts in an Environment without the required authorization; affected and fixed Octopus Server release boundaries documented by the vendor — September 30, 2026 — hxxps://advisories[.]octopus[.]com/post/2026/sa2026-13/

·        Octopus Deploy — Security Advisory 2026-12 — CVE-2026-102488 — incorrect evaluation of multiple scoped permission assignments can allow a highly privileged user to obtain deployment permissions beyond those actually granted; affected and fixed Octopus Server release boundaries documented by the vendor — September 30, 2026 — hxxps://advisories[.]octopus[.]com/post/2026/sa2026-12/

·        Octopus Deploy — Security Advisory 2026-11 — CVE-2026-102478 — authenticated user with permission to modify roles can exploit unsafe Unicode equivalence handling to weaken a built-in role and add an account to a privileged team; affected and fixed Octopus Server release boundaries documented by the vendor — September 30, 2026 — hxxps://advisories[.]octopus[.]com/post/2026/sa2026-11/

·        Octopus Deploy — Security Advisory 2026-10 — CVE-2026-101169 — authenticated Environment or Project editor can submit crafted JSON that is insecurely deserialized and results in arbitrary code execution in the Octopus Server process; affected and fixed self-hosted release boundaries documented by the vendor — September 29, 2026 — hxxps://advisories[.]octopus[.]com/post/2026/sa2026-10/

·        Renovate / GitHub Security Advisory — GHSA-f2v7-35mm-3hx7 — CVE-2026-88889 — Maven Wrapper distributionType command-injection condition — September 10, 2026 — hxxps://github[.]com/renovatebot/renovate/security/advisories/GHSA-f2v7-35mm-3hx7

·        Renovate / GitHub Security Advisory — GHSA-v85g-rq5w-c46q — CVE-2026-88888 — Mix private-dependency organization command-injection condition — September 10, 2026 — hxxps://github[.]com/renovatebot/renovate/security/advisories/GHSA-v85g-rq5w-c46q

·        Renovate / GitHub Security Advisory — GHSA-v73q-hvqx-hxwx — CVE-2026-88887 — container-registry pagination credential-exfiltration condition — September 10, 2026 — hxxps://github[.]com/renovatebot/renovate/security/advisories/GHSA-v73q-hvqx-hxwx

·        Renovate / GitHub Security Advisory — GHSA-7chm-46wx-888m — CVE-2026-88886 — Gradle Wrapper distributionUrl command-injection condition — September 10, 2026 — hxxps://github[.]com/renovatebot/renovate/security/advisories/GHSA-7chm-46wx-888m

·        Renovate / GitHub Security Advisory — GHSA-mpf8-qxrw-gq3w — CVE-2026-88885 — Go module depName command-injection condition — September 10, 2026 — hxxps://github[.]com/renovatebot/renovate/security/advisories/GHSA-mpf8-qxrw-gq3w

·        Renovate / GitHub Security Advisory — GHSA-g4qr-hw2h-687r — CVE-2026-88884 — digest-update minimumReleaseAge bypass condition — September 10, 2026 — hxxps://github[.]com/renovatebot/renovate/security/advisories/GHSA-g4qr-hw2h-687r

·        Renovate / GitHub Security Advisory — GHSA-4hmw-qw74-vrhm — CVE-2026-88883 — Mutual TLS private-key log-sanitization condition — September 10, 2026 — hxxps://github[.]com/renovatebot/renovate/security/advisories/GHSA-4hmw-qw74-vrhm

·        Renovate / GitHub Security Advisory — GHSA-rh7w-ccch-gh49 — CVE-2026-88882 — NuGet pagination credential-exfiltration condition — September 10, 2026 — hxxps://github[.]com/renovatebot/renovate/security/advisories/GHSA-rh7w-ccch-gh49

·        Renovate / GitHub Security Advisory — GHSA-w57v-h33h-835c — CVE-2026-88881 — GitHub pagination credential-exfiltration condition — September 10, 2026 — hxxps://github[.]com/renovatebot/renovate/security/advisories/GHSA-w57v-h33h-835c

·        Renovate / GitHub Security Advisory — GHSA-9hmg-9h89-jhmx — CVE-2026-88880 — GitLab pagination credential-exfiltration condition — September 10, 2026 — hxxps://github[.]com/renovatebot/renovate/security/advisories/GHSA-9hmg-9h89-jhmx

·        GitHub Docs — GitHub Enterprise Server 3.21.5 Release Notes — September 1, 2026 — hxxps://docs[.]github[.]com/en/enterprise-server@3.21/admin/release-notes#3-21-5

·        GitLab Docs — Patch Release 19.3.1, 19.2.5, 19.1.7 — hxxps://docs[.]gitlab[.]com/releases/patches/patch-release-gitlab-19-3-1-released/

·        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 — Critical 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 — Critical Patch Release 19.2.4, 19.1.6, 19.0.8, 18.11.11 — hxxps://docs[.]gitlab[.]com/releases/patches/patch-release-gitlab-19-2-4-released/

·        GitLab Docs — CI/CD Pipelines — hxxps://docs[.]gitlab[.]com/ci/pipelines/

·        GitHub Docs — Security Hardening for GitHub Actions — hxxps://docs[.]github[.]com/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions

·        GitHub Docs — Organization Audit Log — hxxps://docs[.]github[.]com/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/reviewing-the-audit-log-for-your-organization

·        Gitea Documentation — Actions — hxxps://docs[.]gitea[.]com/usage/actions/

·        Gitea Documentation — Reverse Proxies — hxxps://docs[.]gitea[.]com/administration/reverse-proxies

·        Gitea Documentation — Container Registry Packages — hxxps://docs[.]gitea[.]com/usage/packages/container

·        Forgejo Documentation — Actions — hxxps://forgejo[.]org/docs/latest/user/actions/actions/

·        JFrog — JFrog Security Advisories — hxxps://docs[.]jfrog[.]com/releases/docs/jfrog-security-advisories

·        JFrog — Artifactory Self-Managed Releases — hxxps://docs[.]jfrog[.]com/releases/docs/artifactory-self-managed-releases

·        AWS — Security Bulletin 2026-095-AWS — CVE-2026-85012 — Amazon CodeCatalyst Blueprints SDK — September 3, 2026 — hxxps://aws[.]amazon[.]com/security/security-bulletins/2026-095-aws/

·        GitHub Security Advisory — GHSA-c7rj-fr2j-64w7 — CVE-2026-85012 — Amazon CodeCatalyst Blueprints SDK Command Injection

·        GitHub — AWS CodeCatalyst Blueprints Source Repository — hxxps://github[.]com/aws/codecatalyst-blueprints

·        Coder / GitHub Security Advisory — GHSA-vx42-ghc9-gw65 — Coder Registry supply-chain compromise — September 1, 2026 — hxxps://github[.]com/coder/coder/security/advisories/GHSA-vx42-ghc9-gw65

Active-Register Vulnerability Records and Advisory Sources

·        CVE Program — CVE-2026-106218 — JetBrains TeamCity Kotlin DSL sandbox escape permitting server-side remote code execution under the documented affected-version condition —
hxxps://www[.]cve[.]org/CVERecord?id=CVE-2026-106218

·        CVE Program — CVE-2026-106219 — JetBrains TeamCity insufficient Git submodule URL validation permitting reads of local repositories on the server under the documented affected-version condition —
hxxps://www[.]cve[.]org/CVERecord?id=CVE-2026-106219

·        GitHub Advisory Database — GHSA-x4q3-gcj3-m6cf — CVE-2026-73802 — Gitea act_runner Docker HostConfig handling permits repository-controlled Actions workflow container options to alter host namespace, Linux capability, or security-profile behavior and enable runner-host execution under the documented conditions; corrected in act_runner 3.0.0 — hxxps://github[.]com/advisories/GHSA-x4q3-gcj3-m6cf

·        GitHub Advisory Database — GHSA-grg2-7gc6-36m6 — CVE-2026-102437 — DeepSeek-Reasonix ConfigPoisoning repository-local Git configuration and diff-processing command-execution condition; corrected in DeepSeek-Reasonix Studio 2.21.0 and DeepSeek Reasonix npm 1.39.3 — hxxps://github[.]com/advisories/GHSA-grg2-7gc6-36m6

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

·        CVE Program — CVE-2026-78210 — Octopus Server incorrect authorization permitting arbitrary script execution in an Environment under the documented scoped-permission condition — hxxps://www[.]cve[.]org/CVERecord?id=CVE-2026-78210

·        CVE Program — CVE-2026-102488 — Octopus Server incorrect authorization caused by multiple scoped permission assignments being evaluated incorrectly, permitting excess deployment permissions under the documented condition — hxxps://www[.]cve[.]org/CVERecord?id=CVE-2026-102488

·        CVE Program — CVE-2026-102478 — Octopus Server improper validation of unsafe equivalence in input resulting in authenticated privilege escalation under the documented role-modification condition — hxxps://www[.]cve[.]org/CVERecord?id=CVE-2026-102478

·        CVE Program — CVE-2026-101169 — Octopus Server insecure deserialization leading to authenticated arbitrary code execution under the documented Environment or Project editing condition — hxxps://www[.]cve[.]org/CVERecord?id=CVE-2026-101169

·        GitHub Advisory Database — GHSA-hp6r-mrh8-47vq — CVE-2026-76851 — GitHub Enterprise Server pre-receive-hook / internal-service behavior — hxxps://github[.]com/advisories/GHSA-hp6r-mrh8-47vq

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

·        GitHub Advisory Database — GHSA-4fq5-hf84-xr75 — CVE-2026-19118 — GitHub Enterprise Server TOCTOU upload-processing condition — hxxps://github[.]com/advisories/GHSA-4fq5-hf84-xr75

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

·        GitHub Advisory Database — GHSA-xh7g-7v3x-h73p — CVE-2026-18730 — GitHub Enterprise Server Manage API SSRF and management-token exposure — hxxps://github[.]com/advisories/GHSA-xh7g-7v3x-h73p

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

·        GitPython / GitHub Security Advisory — GHSA-239g-whfq-7xj9 — CVE-2026-87817 — affected GitPython versions before 3.1.60; corrected in 3.1.60; repository content can impersonate the Git directory and enable repository-controlled hook execution under the documented vulnerable path — hxxps://github[.]com/gitpython-developers/GitPython/security/advisories/GHSA-239g-whfq-7xj9

·        GitLab Docs — CVE-2026-18252 — GitLab Duo Claude AI Agent — hxxps://docs[.]gitlab[.]com/releases/patches/patch-release-gitlab-19-3-1-released/

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

·        GitLab Docs — CVE-2026-15387 — Pipeline Execution Policies — hxxps://docs[.]gitlab[.]com/releases/patches/patch-release-gitlab-19-3-1-released/

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

·        GitLab Docs — CVE-2026-7487 — Merge Request Approval Rules Reset — hxxps://docs[.]gitlab[.]com/releases/patches/patch-release-gitlab-19-3-1-released/

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

·        GitLab Docs — CVE-2026-3035 — Protected Environments — hxxps://docs[.]gitlab[.]com/releases/patches/patch-release-gitlab-19-3-1-released/

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

·        GitLab Docs — CVE-2026-4398 — Compliance Framework Assignment — hxxps://docs[.]gitlab[.]com/releases/patches/patch-release-gitlab-19-3-1-released/

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

·        NVD — CVE-2026-19478 — GitLab GraphQL vulnerability — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-19478

·        NVD — CVE-2026-19650 — GitLab GraphQL request-handling vulnerability — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-19650

·        GitHub — Gitea Security Advisory GHSA-rcr6-4jqh-j84m — CVE-2026-60004 — hxxps://github[.]com/go-gitea/gitea/security/advisories/GHSA-rcr6-4jqh-j84m

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

·        NVD — CVE-2026-20896 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-20896

·        Gitea Blog — Release of 1.26.3 and 1.26.4 — hxxps://blog[.]gitea[.]com/release-of-1[.]26[.]3-and-1[.]26[.]4/

·        GitHub — Gitea Security Advisory GHSA-f75j-4cw6-rmx4 — hxxps://github[.]com/go-gitea/gitea/security/advisories/GHSA-f75j-4cw6-rmx4

·        GitHub — Gitea v1.26.3 Release — hxxps://github[.]com/go-gitea/gitea/releases/tag/v1[.]26[.]3

Coder Registry Supply-Chain Compromise — GHSA-vx42-ghc9-gw65

Coder published its public incident advisory on September 1, 2026. Additional public technical reporting followed.

·        Incident type: confirmed software-supply-chain compromise without a CVE

·        Infrastructure compromise: Coder publicly reported unauthorized manipulation of infrastructure serving registry.coder.com that caused some registry requests to be routed to attacker-controlled infrastructure

·        Documented malicious-delivery window: August 31, 2026 from 07:35 UTC through 21:45 UTC

·        Delivered content: malicious Coder Registry Terraform modules served to a subset of users

·        Affected versions: Coder releases earlier than the applicable corrected supported-branch release

·        Corrected releases: 2.37.0, 2.36.4, 2.35.7, and 2.34.9

·        Potentially affected activity: creation or update of workspace templates, template dry runs, and workspace deployment during the documented incident window when a registry module was downloaded

·        Publicly documented secret-discovery scope included provisioner environment variables, cloud and AI-tooling API keys, CI/CD credentials, configuration secrets, terminal history, user OIDC tokens, configured SSH keys, external-authentication tokens, and certain Coder configuration secrets under applicable execution conditions

·        Publicly documented exfiltration destination: coder-infra[.]com

·        Investigation scope: firewall, proxy, DNS, VPC flow, provisioner, template, module-cache, workspace, credential, cloud, CI/CD, identity, repository, database, and downstream deployment evidence

·        Response actions: upgrade to the applicable corrected release, clear affected cached modules, review potentially affected template and workspace activity, and rotate credentials or secrets accessible to affected provisioners where exposure cannot be excluded

·        CISA KEV state: not applicable because the incident is not represented by a CVE

·        Coverage classification: Coverage With Adaptation as a named non-CVE behavior-led item

·        Coder / GitHub Security Advisory — GHSA-vx42-ghc9-gw65 — hxxps://github[.]com/coder/coder/security/advisories/GHSA-vx42-ghc9-gw65

·        BleepingComputer — Coder Registry Infrastructure Compromise Reporting — September 3, 2026 — hxxps://www[.]bleepingcomputer[.]com/news/security/coders-registry-infrastructure-compromised-to-push-malicious-modules/

Amazon CodeCatalyst Blueprints SDK — CVE-2026-85012

AWS published Security Bulletin 2026-095-AWS on September 3, 2026.

·        Product: @amazon-codecatalyst/blueprints.blueprint

·        Impacted versions: <= 0.3.155

·        Corrected version: 0.3.156

·        Publicly documented behavior: during blueprint resynthesis, repository-controlled .ownership-file content can reach an operating-system command path under the documented [local] merge-strategy condition

·        Required attacker position: permission to commit attacker-controlled content to a repository in the project

·        Potential impact: command execution with privileges and credentials available to the environment performing resynthesis

·        Resolution: version 0.3.156 removes the vulnerable shell interpretation and restricts accepted values

·        Direct-consumer remediation: upgrade to 0.3.156 or later

·        Managed-service scope: AWS states that no action is required for use of the managed Amazon CodeCatalyst service for the documented condition

·        Exploitation qualification: no authoritative public active-exploitation claim established

·        CISA KEV qualification: not listed as KEV

·        Coverage classification: software-delivery behavioral context; not an additional CVE in the active 62-CVE register

·        AWS — Security Bulletin 2026-095-AWS — hxxps://aws[.]amazon[.]com/security/security-bulletins/2026-095-aws/

·        GitHub Security Advisory — GHSA-c7rj-fr2j-64w7

JFrog Artifactory Public CNA Reconciliation — Contextual Source Set

JFrog’s public Security Advisories inventory remains the authoritative vendor/CNA source for the Artifactory vulnerability reconciliation retained as contextual software-delivery coverage.

The reconciliation includes 43 publicly disclosed Artifactory CVEs through August 28, 2026:

·        33 map to software-delivery behaviors retained in this report as contextual Coverage With Adaptation

·        10 remain intentionally excluded under the materiality gate

·        These contextual mappings do not increase the active 62-CVE register

·        Three retained contextual mappings — CVE-2026-82329, CVE-2026-42018, and CVE-2026-42016 — are confirmed as actively exploited / in-the-wild and CISA KEV-listed

·        CVE-2026-82329 is an independently exploited Artifactory administrative-compromise path

·        CVE-2026-42018 and CVE-2026-42016 have been observed in a chained token-exposure and privilege-escalation path

·        JFrog — JFrog Security Advisories — hxxps://docs[.]jfrog[.]com/releases/docs/jfrog-security-advisories

JFrog Artifactory CVEs Retained as Contextual Behavioral Mappings

·        CVE-2026-82329

·        CVE-2026-66384

·        CVE-2026-65921

·        CVE-2026-65923

·        CVE-2026-65924

·        CVE-2026-65925

·        CVE-2026-66014

·        CVE-2026-66015

·        CVE-2026-65617

·        CVE-2026-66018

·        CVE-2026-70551

·        CVE-2026-69104

·        CVE-2026-69105

·        CVE-2026-69107

·        CVE-2026-69106

·        CVE-2026-42018

·        CVE-2026-66375

·        CVE-2026-68760

·        CVE-2026-66381

·        CVE-2026-66382

·        CVE-2026-66376

·        CVE-2026-68754

·        CVE-2026-68757

·        CVE-2026-68756

·        CVE-2026-68752

·        CVE-2026-68755

·        CVE-2026-68753

·        CVE-2026-68759

·        CVE-2026-65922

·        CVE-2026-65616

·        CVE-2026-42017

·        CVE-2026-42016

·        CVE-2026-65618

JFrog Artifactory CVEs Reviewed and Intentionally Excluded From the Active Register

·        CVE-2026-70550

·        CVE-2026-70548

·        CVE-2026-70547

·        CVE-2026-66016

·        CVE-2026-65926

·        CVE-2026-66378

·        CVE-2026-66380

·        CVE-2026-68758

·        CVE-2026-66377

·        CVE-2026-66379

The controlling public validation source for these contextual mappings and exclusions remains:

·        JFrog — JFrog Security Advisories — hxxps://docs[.]jfrog[.]com/releases/docs/jfrog-security-advisories

Supplemental JFrog Vulnerability Records

The following public CVE Program and NVD records provide supplemental per-identifier reference material:

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

·        NVD — CVE-2026-82329 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-82329

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

·        NVD — CVE-2026-66384 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-66384

·        NVD — CVE-2026-65921 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-65921

·        NVD — CVE-2026-65923 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-65923

·        NVD — CVE-2026-65924 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-65924

·        NVD — CVE-2026-65925 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-65925

·        NVD — CVE-2026-66014 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-66014

·        NVD — CVE-2026-66015 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-66015

·        NVD — CVE-2026-65617 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-65617

·        NVD — CVE-2026-66018 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-66018

Gitea and Self-Hosted Git Vulnerability Records

·        GitHub — Gitea Security Advisory — GHSA-x4q3-gcj3-m6cf — CVE-2026-73802 — act_runner Docker HostConfig pass-through permits repository-controlled Actions workflow container options to alter host namespace, capability, or security-profile settings and enable runner-host command execution under the documented conditions; corrected in act_runner 3.0.0 — hxxps://github[.]com/go-gitea/gitea/security/advisories/GHSA-x4q3-gcj3-m6cf

·        GitHub — Gitea Security Advisory GHSA-rcr6-4jqh-j84m — CVE-2026-60004 — hxxps://github[.]com/go-gitea/gitea/security/advisories/GHSA-rcr6-4jqh-j84m

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

·        NVD — CVE-2026-20896 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-20896

·        Gitea Blog — Release of 1.26.3 and 1.26.4 — hxxps://blog[.]gitea[.]com/release-of-1[.]26[.]3-and-1[.]26[.]4/

·        GitHub — Gitea Security Advisory GHSA-f75j-4cw6-rmx4 — hxxps://github[.]com/go-gitea/gitea/security/advisories/GHSA-f75j-4cw6-rmx4

·        GitHub — Gitea v1.26.3 Release — hxxps://github[.]com/go-gitea/gitea/releases/tag/v1[.]26[.]3

·        NoScope — CVE-2026-27771: NoScope Discovered 30,000+ Gitea Instances Exposing Private Container Images for Four Years — hxxps://www[.]noscope[.]com/blog/gitea-instances-exposing-private-container-images

Agentic Workflow / AI-Assisted Repository Research

·        Noma Security — GitLost: How We Tricked GitHub’s AI Agent into Leaking Private Repos — hxxps://noma[.]security/blog/gitlost-how-we-tricked-githubs-ai-agent-into-leaking-private-repos/

·        arXiv — Demystifying and Detecting Agentic Workflow Injection Vulnerabilities in GitHub Actions — hxxps://arxiv[.]org/abs/2605.07135

Threat Technique Framework

·        MITRE ATT&CK — Enterprise Matrix / Techniques Catalog — hxxps://attack[.]mitre[.]org/

Federal / KEV / Exploitation Catalog

·        CISA — Known Exploited Vulnerabilities Catalog — hxxps://www[.]cisa[.]gov/known-exploited-vulnerabilities-catalog

·        CISA — August 25, 2026 Known Exploited Vulnerabilities Update — CVE-2026-60004 / Gitea

·        CISA — Known Exploited Vulnerabilities Catalog — CVE-2025-31125 / Vite

·        Canadian Centre for Cyber Security — JFrog security advisory (AV26-867) – Update 2 — updated September 11, 2026 — confirms CVE-2026-82329 was added to the CISA KEV Catalog on September 2, 2026 and CVE-2026-42016 and CVE-2026-42018 were added on September 11, 2026 — hxxps://www[.]cyber[.]gc[.]ca/en/alerts-advisories/jfrog-security-advisory-av26-867

·        Canadian Centre for Cyber Security — Gitea Security Advisory AV26-845 — hxxps://www[.]cyber[.]gc[.]ca/en/alerts-advisories/gitea-security-advisory-av26-845

·        CISA — BOD 26-04: Implementation Guidance for Prioritizing Security Updates Based on Risk — hxxps://www[.]cisa[.]gov/news-events/directives/bod-26-04-implementation-guidance-prioritizing-security-updates-based-risk

The current active-register KEV count is 2.

The contextual Artifactory KEV count is 3.

Contextual vulnerability references retained elsewhere in this section do not alter the active-register count.

Exploitation Reporting

·        F5 Labs — Cloud Takeover: Mass Scanning for Exposed Vite Endpoints (CVE-2026-39364) — September 11, 2026 — documents sustained August 2026 scanning and exploitation attempts against exposed Vite development servers, including attempts associated with CVE-2026-39364 and CVE-2025-30208 and targeting of .env files, AWS credentials, Azure tokens, Terraform state, and process-environment data — hxxps://www[.]f5[.]com/labs/articles/cloud-takeover-mass-scanning-for-exposed-vite-endpoints-cve-2026-39364

·        Wiz Research — Artifactory Under Attack: In-the-Wild Exploitation of CVE-2026-42016, CVE-2026-42018 & CVE-2026-82329 — September 10, 2026 — confirms active in-the-wild exploitation of all three vulnerabilities, including independent exploitation of CVE-2026-82329 and chaining of CVE-2026-42018 with CVE-2026-42016 for administrative compromise and post-exploitation activity — hxxps://www[.]wiz[.]io/blog/artifactory-under-attack-in-the-wild-exploitation-of-cve-2026-42016-cve-2026-42018-cve-2026-82329

·        SecurityWeek — Critical GitLab Flaw Exploited Shortly After Disclosure — August 20, 2026 — hxxps://www[.]securityweek[.]com/critical-gitlab-flaw-exploited-shortly-after-disclosure/

·        BleepingComputer — Coder Registry Infrastructure Compromise Reporting — September 3, 2026 — hxxps://www[.]bleepingcomputer[.]com/news/security/coders-registry-infrastructure-compromised-to-push-malicious-modules/

·        SecurityWeek — Critical JFrog Artifactory Vulnerability Reportedly Exploited in the Wild — September 1, 2026 — hxxps://www[.]securityweek[.]com/critical-jfrog-artifactory-vulnerability-reportedly-exploited-in-the-wild/

·        BleepingComputer — Over 8,300 Gitea Servers Vulnerable to Code Execution Attacks — August 28, 2026 — hxxps://www[.]bleepingcomputer[.]com/news/security/over-8-300-gitea-servers-vulnerable-to-code-execution-attacks/

·        Shadowserver Foundation — Vulnerable HTTP Report; Gitea CVE-2026-60004 vulnerable-instance exposure reporting — hxxps://www[.]shadowserver[.]org/what-we-do/network-reporting/vulnerable-http-report/

The F5 Vite reporting is retained as source-qualified active probing and exploitation-attempt context. It does not by itself establish successful sensitive-file retrieval on a specific affected server.

No authoritative active-exploitation source is assigned to CVE-2026-106218, CVE-2026-106219, CVE-2026-100102, CVE-2026-100103, CVE-2026-103507, CVE-2026-103510, CVE-2026-103511, CVE-2026-103512, CVE-2026-102437, or CVE-2026-73802 in this amendment. Their inclusion therefore does not change the active-register exploited or KEV counts.

The JFrog exploitation references are retained as contextual software-delivery intelligence. CVE-2026-82329, CVE-2026-42018, and CVE-2026-42016 are confirmed as actively exploited and CISA KEV-listed, but because they remain contextual mappings they do not increase the active-register exploitation or KEV counts.

Threat Tradecraft and Intrusion Patterns

·        Public threat and vulnerability reporting retained in this section is used to contextualize observable repository-control, authentication, workflow, dependency-update, Vite development-server, DeepSeek-Reasonix developer-tool, Perforce P4 Search, credential-access, package, registry, artifact, CI/CD, cloud, Kubernetes, deployment, and software-supply-chain behaviors

Threat reporting should be interpreted as supporting context and enrichment rather than as standalone proof of local compromise.