[SUP] SAP npm Package Poisoning and Shai-Hulud-Style Developer Credential Theft

Report Type:
SUP

Threat Category:
Developer Ecosystem and Software Supply Chain Compromise

Assessment Date:
April 29, 2026

Amendment Date:
June 21, 2026

Primary Impact Domain:
Credential Theft and Downstream Supply Chain Compromise

Secondary Impact Domains:
Cloud Control-Plane Abuse; Source-Code Platform Abuse; Package Registry Abuse; CI/CD Pipeline Exposure; Developer Workstation Compromise; Secret and Token Exposure

Affected Asset Class:
Developer Workstations; CI/CD Runners; Build and Release Systems; Source-Code Repositories; npm Packages and Package Registry Accounts; Cloud Identities; Deployment Credentials; Artifact and Dependency Caches

Threat Objective Classification:
Credential Harvesting, Token Abuse, Supply Chain Propagation, Repository and Workflow Manipulation, Cloud Credential Misuse, and Downstream Deployment-Path Compromise
Published by: CyberDax LLC
Author: Edward “Tony” Dolley
Role: Founder / Principal Threat Researcher, CyberDax LLC
Publication Date: June 21, 2026
Publication Type: Cybersecurity Research Report / White Paper

BLUF

 Compromised SAP-related npm packages create material enterprise risk by turning trusted developer dependencies into a path for credential theft, CI/CD exposure, source-code platform abuse, package-registry abuse, and downstream software supply-chain compromise. The risk is driven by malicious install-time package behavior, including npm lifecycle execution, suspicious runtime staging, developer secret discovery, encrypted exfiltration, and Shai-Hulud-style propagation tradecraft. The threat posture is elevated because affected packages can execute inside developer workstations, CI/CD runners, release workflows, and package-publishing environments that may hold GitHub tokens, npm tokens, cloud keys, SSH material, deployment credentials, and CI/CD secrets. Executive action is required to identify exposed dependency use, rotate at-risk credentials, validate developer and CI/CD telemetry, review GitHub and npm activity, and confirm that affected build outputs, internal mirrors, dependency caches, and release artifacts have not carried the compromise forward.

Executive Risk Translation

SAP-related npm package poisoning shifts business risk from a single vulnerable application or isolated developer endpoint to the trusted software development pipeline. The primary concern is that a legitimate dependency may execute attacker-controlled code during installation, collect developer or automation secrets, and enable unauthorized access to repositories, package registries, CI/CD workflows, cloud environments, or downstream release artifacts. If exposure cannot be scoped quickly, response may expand into broad credential rotation, dependency-cache review, internal package mirror validation, CI/CD runner investigation, source-code audit, package-publishing review, cloud-control-plane review, artifact assurance, and customer-facing trust validation. This creates financial, operational, governance, software-integrity, and third-party-risk exposure beyond the first exposed developer system or build job.

S3 — Why This Matters Now

·        Multiple SAP-related npm packages were publicly reported as compromised in late April 2026, with malicious package versions introduced through npm publishing activity.

·        Public reporting identifies malicious install-time behavior involving a preinstall hook, setup.mjs, Bun runtime execution, credential theft, encrypted exfiltration, and propagation behavior aligned with Mini Shai-Hulud or TeamPCP-style npm supply-chain activity.

·        The affected trust path is high value because SAP-related npm packages may be used in SAP CAP development, application extension work, Fiori application backends, integration flows, build pipelines, and release automation.

·        The primary enterprise concern is not only package exposure; the primary concern is whether installation occurred on systems that held developer credentials, GitHub tokens, npm tokens, SSH keys, cloud credentials, package-publishing authority, or deployment secrets.

·        Install-time npm execution should be treated as a high-risk software supply-chain pathway because package installation can become an execution and credential-harvesting primitive.

·        CI/CD exposure increases business risk because build runners and release workflows may hold privileged automation credentials, repository permissions, artifact-signing authority, registry access, or deployment paths.

·        Static indicators such as package names, package versions, file names, hashes, and infrastructure are useful for scoping, but they are not sufficient as the durable detection or risk model.

·        Organizations without endpoint process telemetry, CI/CD runner visibility, npm registry audit data, GitHub audit logs, dependency-cache records, and cloud-control-plane logging face elevated risk of delayed scoping and incomplete containment.

S4 — Key Judgments

·        This is a trusted-dependency supply-chain compromise, not a conventional perimeter intrusion or CVE-led vulnerability event.

·        The primary business risk is unauthorized use of developer, maintainer, package-registry, source-code, cloud, and CI/CD credentials after malicious package installation.

·        Package exposure alone does not prove compromise, but exposure on systems with privileged developer or automation secrets materially increases risk.

·        The strongest risk signal is package-manager lifecycle execution followed by unexpected runtime activity, credential access, local staging, suspicious egress, GitHub activity, npm publishing activity, or cloud-control-plane activity.

·        Bun runtime activity is a high-priority indicator where Bun is not approved for the host, repository, build image, or release workflow.

·        GitHub workflow modification, repository creation, deploy-key changes, webhook changes, npm publication, package ownership changes, token validation, or cloud privilege changes after exposure should be treated as potential downstream credential abuse.

·        Detection must be behavior-led because package names, loader names, hashes, infrastructure, and exfiltration paths may change quickly.

·        Managed CI/CD runners, ephemeral build containers, incomplete file-access telemetry, limited npm audit depth, and encrypted egress are expected confidence constraints.

·        Artifact, lockfile, internal mirror, package-cache, and build-output review are required for exposure validation, but they do not prove execution or credential theft by themselves.

·        Executive risk reduction depends on rapid exposure scoping, credential rotation, package-cache and artifact review, GitHub and npm audit review, CI/CD validation, cloud credential review, and behavior-based detection coverage.

S5 — Executive Risk Summary

Business Risk

SAP-related npm package poisoning can undermine confidence in the organization’s software development and release pipeline by allowing a trusted dependency to become the execution vehicle for credential theft, repository abuse, npm package-publishing abuse, cloud credential misuse, and downstream artifact compromise. Risk increases when affected installations occurred on developer endpoints, self-hosted CI/CD runners, package-publishing systems, release engineering hosts, SAP development environments, or systems connected to production deployment workflows.

Technical Cause

The risk is driven by malicious npm package versions that introduced install-time execution through package lifecycle behavior. Public reporting describes a preinstall hook that runs setup.mjs, stages or invokes Bun runtime execution, and supports credential theft and propagation-style activity associated with Mini Shai-Hulud or TeamPCP tradecraft.

Threat Posture

The threat posture is elevated because developer and CI/CD environments often contain reusable credentials, repository access, registry tokens, cloud keys, SSH material, deployment secrets, artifact access, and release automation authority. If stolen credentials are reused, the impact can extend from local developer compromise to repository modification, workflow abuse, npm package publication, cloud-control-plane activity, poisoned artifacts, and downstream software trust degradation.

Executive Decision Requirement

Executives must require immediate exposure scoping across dependency files, lockfiles, package caches, build logs, internal npm mirrors, CI/CD runners, developer systems, and release artifacts. Response leadership should also require credential rotation for exposed systems, GitHub and npm audit review, cloud-control-plane review, package-publishing validation, and confirmation that behavior-based detection is in place for malicious package lifecycle execution, credential access, token abuse, and suspicious egress.

S6 — Executive Cost Summary

SAP npm package poisoning and Shai-Hulud-style developer credential theft create financial exposure based on dependency exposure scope, privileged credential presence, detection latency, CI/CD runner visibility, developer endpoint visibility, credential rotation burden, source-code and package-registry review, cloud-control-plane validation, artifact assurance, and downstream customer or regulatory obligations. Financial impact increases when exposed systems have package-publishing authority, deployment credentials, production cloud access, privileged repository access, artifact-signing authority, or customer-facing release responsibilities.

Low Impact Scenario

Exposure is limited to dependency presence, internal mirror retention, or a small number of non-privileged developer systems, and investigation confirms no malicious lifecycle execution, no credential access, no suspicious egress, no GitHub or npm abuse, no cloud-control-plane activity, and no affected release artifact; estimated impact $250K to $1M.

Moderate Impact Scenario

One or more developer systems, build environments, release workflows, dependency caches, or internal npm mirrors were exposed to compromised package versions, requiring credential rotation, endpoint investigation, CI/CD log review, GitHub and npm audit review, dependency-cache cleanup, package mirror validation, artifact review, cloud activity review, detection tuning, and executive incident coordination; estimated impact $1.5M to $8M.

High Impact Scenario

Malicious package execution results in confirmed or strongly suspected theft of GitHub tokens, npm tokens, SSH material, cloud keys, package-publishing credentials, CI/CD secrets, or deployment credentials, enabling repository modification, workflow abuse, package publication, cloud-control-plane activity, artifact compromise, downstream customer exposure, or prolonged software-integrity uncertainty; estimated impact $10M to $75M or higher.

S6A — Key Cost Drivers

·        Number and criticality of exposed developer endpoints, CI/CD runners, release systems, package-publishing systems, and SAP-related development environments.

·        Whether affected package versions were installed, executed, cached, mirrored, or included in build artifacts.

·        Presence of GitHub tokens, npm tokens, SSH keys, cloud credentials, deployment secrets, CI/CD variables, package-publishing credentials, or artifact-signing authority on exposed systems.

·        Time from malicious package publication or installation to detection, containment, and credential rotation.

·        Ability to confirm package-manager lifecycle execution, Bun or Node runtime activity, credential access, local staging, and outbound transfer.

·        Scope of GitHub repository, workflow, deploy-key, webhook, secret, branch, release, and organization audit review.

·        Scope of npm token, maintainer, package ownership, package publication, metadata, access, and provenance review.

·        Scope of AWS, Azure, GCP, identity, secret-manager, container registry, artifact repository, and deployment-path validation.

·        Availability of endpoint process telemetry, file-access telemetry, command-line logging, CI/CD logs, GitHub audit logs, npm registry logs, cloud audit logs, DNS logs, proxy logs, and artifact records.

·        Whether managed CI/CD runners or ephemeral build containers limit forensic reconstruction.

·        Whether internal npm mirrors, dependency caches, package-lock files, build images, containers, software bills of materials, or artifacts retained poisoned package versions.

·        Need for customer assurance, software integrity attestation, legal review, regulatory notification analysis, insurance reporting, or board-level incident governance.

Most Likely Scenario Justification

Moderate scenario is most likely when an organization uses SAP-related npm packages in developer or CI/CD workflows because exposure validation, credential assurance, dependency-cache review, and artifact confidence can create meaningful response cost even without confirmed downstream compromise. The estimate moves toward the lower end when telemetry confirms limited installation, no lifecycle execution, no credential access, no suspicious egress, no GitHub or npm abuse, no cloud-control-plane activity, and no affected release artifact. The estimate moves toward the upper end when privileged developer identities, CI/CD secrets, package-publishing authority, cloud deployment credentials, incomplete telemetry, internal package mirrors, regulated data access, or customer-facing release artifacts are involved.

S6B — Compliance and Risk Context

Compliance Exposure Indicator

Moderate to High depending on whether malicious package execution resulted in unauthorized access to regulated data, proprietary source code, customer environments, production cloud resources, CI/CD secrets, software release artifacts, or downstream customer-facing packages.

Risk Register Entry

Risk Title

SAP-Related npm Package Poisoning and Developer Credential Theft Exposure

Risk Description

Adversaries may compromise trusted SAP-related npm packages and use install-time package lifecycle execution to run attacker-controlled code, harvest developer and CI/CD credentials, exfiltrate secrets, abuse GitHub or npm tokens, modify workflows or packages, access cloud resources, and propagate compromise through software development and release pipelines.

Likelihood

High.

Impact

High.

Risk Rating

High.

Annualized Risk Exposure

Estimated $3M to $20M or higher based on SAP dependency exposure, developer and CI/CD credential concentration, package-publishing authority, release workflow sensitivity, cloud access, artifact assurance requirements, detection latency, and downstream customer or regulatory obligations.

S7 — Risk Drivers

·        Trusted SAP-related npm dependencies installed in developer, CI/CD, release, or build environments.

·        Malicious npm lifecycle execution through package installation workflows.

·        Use of setup.mjs, Bun runtime execution, credential theft, encrypted exfiltration, and propagation behavior reported in the current incident.

·        Developer systems containing reusable GitHub, npm, SSH, cloud, registry, Kubernetes, Docker, or deployment credentials.

·        CI/CD runners containing secrets, package-publishing tokens, deployment credentials, artifact access, or repository write permissions.

·        Internal npm mirrors, dependency caches, lockfiles, build images, and artifacts retaining poisoned package versions after public registry action.

·        Incomplete endpoint telemetry, missing command-line logging, weak file-access visibility, limited CI/CD runner telemetry, or short-lived ephemeral runners.

·        GitHub audit gaps, npm registry audit limitations, token attribution constraints, and source-code platform logging retention limits.

·        Encrypted egress to common developer destinations such as GitHub, webhook services, raw-content platforms, cloud storage, or unfamiliar infrastructure.

·        Over-reliance on package names, hashes, filenames, or known infrastructure instead of behavior-based execution, credential-access, token-abuse, and propagation detection.

·        Delayed credential rotation or incomplete validation of GitHub, npm, cloud, SSH, deployment, and CI/CD secrets after exposure.

·        Downstream uncertainty around source-code integrity, package integrity, build-output integrity, artifact provenance, and customer assurance.

S8 — Bottom Line for Executives

SAP-related npm package poisoning should be treated as a high-priority software supply-chain and developer credential risk because trusted dependency installation can become the path for attacker-controlled code execution. The key executive concern is not only whether affected packages appeared in dependency files, but whether they executed in environments with privileged developer, CI/CD, package-publishing, cloud, or deployment credentials. Risk reduction depends on exposure scoping, rapid credential rotation, GitHub and npm audit review, cloud-control-plane validation, internal package-cache and artifact review, and behavior-based detection for lifecycle execution, credential access, token abuse, and suspicious egress. Organizations should prioritize this incident as a software-trust and business-resilience issue because developer credential theft can extend quickly into repository compromise, package propagation, cloud access, release integrity concerns, and downstream customer assurance.

S9 — Board-Level Takeaway

SAP npm package poisoning turns trusted developer dependencies into part of the enterprise attack surface. The board-level risk is that attackers may use legitimate package installation workflows to steal credentials, abuse source-code and package-registry access, compromise CI/CD workflows, and create uncertainty around software release integrity. Leadership should require evidence that exposed packages were identified, affected systems were scoped, privileged credentials were rotated, GitHub and npm activity was reviewed, cloud access was validated, and build artifacts or internal mirrors were checked for residual exposure. This report supports governance decisions around software supply-chain risk, developer credential protection, CI/CD assurance, package-publishing controls, cloud credential governance, and detection readiness for trusted-dependency compromise.

Figure 2

S10 — Supply Chain Attack Overview

The SAP npm package poisoning incident is a trusted-dependency supply-chain compromise affecting developer and CI/CD workflows that consume SAP-related JavaScript packages. The attack used legitimate npm package distribution paths to introduce malicious install-time execution into packages associated with SAP cloud application development. The governing concern is not exploitation of a single CVE; the governing concern is abuse of package trust, npm publishing authority, package lifecycle scripts, developer credentials, and CI/CD automation.

Public reporting identifies four compromised package versions associated with SAP-related development workflows: mbt 1.2.48, @cap-js/db-service 2.10.1, @cap-js/postgres 2.2.2, and @cap-js/sqlite 2.2.2. Reporting also identifies a malicious package.json preinstall hook that ran setup.mjs, used Bun runtime execution, and supported credential theft and propagation behavior aligned with Mini Shai-Hulud or TeamPCP-style npm supply-chain activity.

The enterprise risk extends beyond the affected packages because malicious package installation may occur on developer systems, build runners, release workflows, or package-publishing environments that hold GitHub tokens, npm tokens, SSH keys, cloud credentials, Kubernetes configuration, deployment secrets, or CI/CD variables. If those credentials are stolen and reused, the incident can progress from local dependency execution into repository modification, workflow abuse, package-registry abuse, cloud-control-plane activity, and downstream software-integrity uncertainty.

Supply Chain Attack Model

·        Trusted SAP-related npm package versions are published or modified with malicious lifecycle behavior.

·        Developer or CI/CD systems install the affected package versions through normal dependency restoration.

·        The package installation triggers attacker-controlled code during preinstall execution.

·        setup.mjs and runtime bootstrapping move the attack from package presence to local execution.

·        The payload targets developer, source-code, package-registry, cloud, SSH, Kubernetes, Docker, and CI/CD secrets.

·        Collected material may be staged, encrypted, and exfiltrated through attacker-selected or attacker-abused channels.

·        Stolen GitHub or npm credentials may be reused to modify repositories, workflows, packages, or publishing paths.

·        Internal mirrors, dependency caches, build artifacts, containers, and release outputs may require validation even when direct downstream compromise is not confirmed.

Supply Chain Attack Disposition

This is a high-impact software supply-chain event because the compromise operates through trusted package installation rather than direct intrusion against a single endpoint or application. The strongest enterprise risk is the possibility that developer, CI/CD, package-registry, or cloud credentials were exposed and then reused to expand access across source-code, package, cloud, and release systems.

S11 — Affected Product / Trust Dependency Overview

Affected Trust Dependency

The affected trust dependency is the SAP-related npm package distribution and development workflow path. This includes package maintainers, npm package publishing, package integrity, dependency resolution, lockfile integrity, internal package mirrors, dependency caches, developer installation, CI/CD dependency restoration, and downstream release workflows.

Affected Package Context

The compromised packages are associated with SAP Cloud Application Programming Model and SAP cloud development workflows. Public reporting and SAP CAP ecosystem documentation indicate that @cap-js-scoped packages are part of CAP development and are maintained in close relationship with SAP development teams. Security reporting also notes relevance to SAP CAP, S/4HANA extensions, Fiori application backends, Multi-Target Applications, and integration flows.

Affected Package Versions

·        mbt 1.2.48.

·        @cap-js/db-service 2.10.1.

·        @cap-js/postgres 2.2.2.

·        @cap-js/sqlite 2.2.2.

Trust Dependency Exposure

Exposure may exist where affected versions were installed, cached, mirrored, restored, or included during the malicious publication window. Risk is higher when affected packages were installed on systems with privileged developer access, CI/CD secrets, package-publishing authority, production deployment access, cloud credentials, artifact-signing authority, or access to sensitive source-code repositories.

Primary Trust Boundaries at Risk

·        npm package publishing and maintainer account trust.

·        Dependency lockfile and package integrity trust.

·        Developer workstation execution trust.

·        CI/CD runner and build image trust.

·        GitHub repository and workflow trust.

·        npm token and package-publishing trust.

·        Cloud credential and deployment-path trust.

·        Internal package mirror and dependency-cache trust.

·        Build artifact, container image, and release provenance trust.

·        Customer-facing software integrity and assurance trust.

Affected Product / Trust Dependency Disposition

The affected product risk should be treated as a dependency-trust and software-development-pipeline risk, not only as a vulnerable-package inventory issue. Package presence identifies exposure; execution context, credential access, token reuse, artifact integrity, and downstream control-plane activity determine business impact.

S12 — Enabling Vulnerability and Exposure Context

Enabling Condition

The enabling condition is abuse of trusted npm package publishing and install-time package lifecycle behavior. The attack did not require exploitation of a conventional CVE in the consuming organization. It relied on the ability to publish or modify trusted package versions and have those packages execute code automatically during dependency installation.

Exposure Path

The exposure path begins when an affected package version is resolved by a developer workstation, CI/CD job, release workflow, internal package mirror, dependency cache, or build environment. If lifecycle scripts are enabled, malicious preinstall behavior may execute as part of routine dependency installation. The exposure becomes materially higher risk when the executing environment contains reusable secrets, cloud access, repository write authority, package-publishing tokens, or deployment permissions.

Why the Exposure Is Material

·        Package installation is a normal and trusted part of developer and CI/CD workflows.

·        npm lifecycle scripts can execute code during installation before application runtime.

·        Developer and CI/CD environments often hold high-value credentials.

·        Build systems may have access to repositories, package registries, artifact stores, cloud environments, and deployment workflows.

·        Stolen credentials may enable downstream compromise even after the malicious package is removed.

·        Internal mirrors, caches, build images, containers, and artifacts may retain affected package versions.

·        Managed runners and ephemeral build containers may limit forensic reconstruction.

·        Lack of file-access telemetry can make credential theft difficult to confirm or disprove.

Exposure Determination Requirements

·        Identify whether affected package versions were present in package.json, lockfiles, build logs, dependency caches, internal npm mirrors, package tarballs, containers, software bills of materials, or release artifacts.

·        Determine whether affected versions were installed during the exposure window.

·        Determine whether lifecycle scripts executed.

·        Determine whether execution occurred on developer workstations, self-hosted CI/CD runners, managed CI/CD runners, release systems, or package-publishing systems.

·        Determine whether exposed systems held GitHub tokens, npm tokens, SSH keys, cloud credentials, Kubernetes configuration, Docker credentials, deployment secrets, or CI/CD environment variables.

·        Determine whether GitHub, npm, cloud, identity, artifact, or network activity occurred after exposure.

·        Determine whether any build output, internal package, container image, or release artifact was produced from an exposed dependency set.

Enabling Vulnerability and Exposure Disposition

The central exposure is trusted installation of compromised package versions with malicious lifecycle behavior. Organizations should treat confirmed installation on privileged developer or CI/CD systems as high-priority exposure even when direct credential theft is not immediately proven.

S13 — Exploitability, Patch, and Exposure Management Status

Exploitability Assessment

Exploitability is high for environments that installed affected package versions while npm lifecycle scripts were enabled. The attack path is operationally simple from the consumer perspective because routine dependency installation can trigger malicious code execution. User interaction beyond normal developer or CI/CD dependency restoration may not be required once an affected package version is resolved and installed.

Exploitability Drivers

·        Affected package versions were distributed through npm, a trusted package ecosystem.

·        Package installation can automatically execute lifecycle scripts.

·        Developer and CI/CD systems commonly perform dependency installation as a routine workflow.

·        CI/CD runners may contain injected secrets, release tokens, deployment credentials, and repository permissions.

·        Loose dependency ranges, transitive dependencies, dependency caches, and internal mirrors can complicate exposure determination.

·        Build pipelines may run package installation automatically on pull requests, scheduled builds, release workflows, or deployment jobs.

·        Malicious execution may occur before traditional application runtime or deployment validation.

Patch and Remediation Status

Public reporting indicates the compromised versions were deprecated, removed, or superseded after discovery. Exposure management should not rely only on upgrading or removing the affected package versions. Because the reported activity targets credentials and developer workflow trust, remediation also requires credential rotation, token revocation, GitHub and npm audit review, cloud-control-plane review, CI/CD validation, dependency-cache cleanup, and artifact assurance.

Required Exposure Management Actions

·        Remove or supersede affected package versions from dependency files and lockfiles.

·        Clear dependency caches that may retain affected package tarballs.

·        Validate internal npm mirrors and artifact repositories for retained malicious versions.

·        Review developer endpoints and CI/CD runners that installed affected versions.

·        Rotate exposed or potentially exposed GitHub, npm, SSH, cloud, Kubernetes, Docker, deployment, and CI/CD secrets.

·        Review GitHub repositories, workflows, secrets, deploy keys, webhooks, branch protections, releases, and repository visibility changes.

·        Review npm token use, package publication, maintainer changes, package ownership changes, access changes, metadata changes, and package provenance.

·        Review cloud audit logs for unusual identity use, secret access, service-account changes, access-key changes, role changes, container registry actions, storage actions, and deployment-path activity.

·        Review artifacts, containers, software bills of materials, release outputs, and build provenance generated during the exposure window.

·        Disable or restrict install-time scripts in high-risk CI/CD workflows where operationally feasible.

·        Enforce package provenance, trusted publishing restrictions, workflow scoping, and least-privilege release credentials.

Exploitability and Exposure Management Disposition

Exploitability is high where affected package versions were installed with lifecycle scripts enabled. Exposure management must combine package remediation with credential assurance, CI/CD review, source-code platform review, cloud validation, cache cleanup, and artifact integrity review.

S14 — Sectors / Countries Affected
S14 — Sectors / Countries Affected

Sectors Affected

Observed and likely exposed sectors include organizations that use npm packages in developer workstations, CI/CD pipelines, internal package mirrors, build images, release automation, cloud-connected software-delivery workflows, or software-development environments that depend on external package ecosystems. The exposure is not limited to SAP development or AI development because the delivery model is dependency-driven and depends on package consumption, install-time execution, credential exposure, and downstream software-delivery authority.

Most likely exposed sectors include:

·        Technology and software development.

·        Enterprise application-development teams dependent on third-party package ecosystems.

·        AI application development, AI SaaS, and LLM-enabled product teams.

·        Managed service providers and systems integrators supporting SAP, cloud, AI, or enterprise application development workflows.

·        Financial services.

·        Healthcare and life sciences.

·        Manufacturing.

·        Retail and e-commerce.

·        Professional services.

·        Education and research.

·        Government-adjacent and regulated infrastructure environments where developers, administrators, or build systems interact with external package ecosystems.

Sector exposure should be treated as broad unless incident-specific evidence shows that a campaign targeted a narrower victim group. Risk is highest where package installation occurs on systems with privileged developer access, source-code access, GitHub access, npm publishing authority, CI/CD secrets, cloud credentials, LLM or SaaS API keys, artifact-signing authority, deployment access, or customer-data access.

Countries Affected

Global.

Geographic exposure should be treated as global because npm package distribution, cloud development, CI/CD dependency restoration, and software-development dependency consumption are not geographically restricted. The primary exposure boundary is dependency consumption and execution context, not country. Unless incident-specific evidence limits activity to a particular country, language group, hosting region, customer base, or affected population, any organization that installed compromised package versions, restored affected dependencies, cached affected packages, mirrored affected packages internally, or built artifacts from exposed dependency sets may be affected.

S15 — Adversary Capability Profiling

Adversary Capability Overview

The activity reflects a capable software supply-chain operator with practical knowledge of npm publishing, package lifecycle execution, developer credential storage, CI/CD secret exposure, GitHub workflow abuse, package-registry propagation, cloud credential harvesting, and encrypted exfiltration. The tradecraft is consistent with a developer-ecosystem intrusion model rather than commodity endpoint-only malware.

Observed or Reported Capability Indicators

·        Ability to introduce malicious versions into trusted npm package distribution paths.

·        Use of npm preinstall behavior to trigger execution during routine package installation.

·        Use of setup.mjs as a loader or bootstrap component.

·        Use of Bun runtime execution to support payload execution.

·        Targeting of developer credentials, GitHub tokens, npm tokens, SSH material, cloud credentials, Kubernetes configuration, CI/CD secrets, and environment variables.

·        Encrypted handling of exfiltrated material.

·        Use of GitHub or developer-platform mechanisms for exfiltration, propagation, or abuse where credentials permit access.

·        Capability to search for and reuse GitHub or npm tokens.

·        Capability to modify repositories, workflows, packages, or package publication paths where stolen credentials permit access.

·        Operational overlap with prior Shai-Hulud or TeamPCP-style npm supply-chain activity.

Adversary Strengths

·        Exploits trust in normal dependency installation workflows.

·        Targets environments where high-value secrets are commonly present.

·        Uses legitimate package distribution infrastructure to reach developers and CI/CD systems.

·        Benefits from ephemeral infrastructure and limited runner telemetry.

·        Can potentially propagate through stolen source-code or package-registry credentials.

·        Can create business impact even when malware execution is short-lived because stolen credentials may remain valid after package removal.

·        Can abuse common developer services such as GitHub and npm in ways that may appear legitimate without context.

Adversary Constraints

·        Requires affected package installation or package consumption by target environments.

·        Requires lifecycle script execution or equivalent install-time execution to trigger the payload.

·        Downstream access depends on available credentials, token scopes, repository permissions, cloud permissions, and package-publishing rights.

·        Detection likelihood increases where endpoint, CI/CD, GitHub, npm, cloud, identity, and network telemetry are correlated.

·        Credential rotation, token revocation, package provenance enforcement, workflow scoping, and least-privilege publishing reduce propagation potential.

·        Internal mirrors, build logs, lockfiles, and artifact records may preserve evidence of exposure.

Adversary Capability Disposition

The adversary capability should be assessed as high for developer supply-chain compromise. The actor does not need direct access to every target organization; successful package poisoning can execute inside trusted development and CI/CD workflows across downstream consumers.

S16 — Targeting Probability Assessment

Targeting Probability

High for organizations that used affected SAP-related npm package versions in developer, CI/CD, SAP CAP, MTA, SAP Business Technology Platform, or SAP extension workflows.

Targeting Logic

This incident is dependency-driven rather than individually targeted in every downstream environment. Organizations become exposed when they install or restore affected package versions. The probability of meaningful impact rises when exposed systems hold privileged credentials, package-publishing authority, repository write access, cloud deployment authority, or sensitive release responsibilities.

High Probability Exposure Conditions

·        Affected package versions appear in package.json, package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, yarn.lock, dependency caches, internal npm mirrors, build logs, containers, or artifacts.

·        Affected versions were installed during the exposure window.

·        Lifecycle scripts were enabled during dependency installation.

·        Installation occurred on developer endpoints with GitHub, npm, SSH, cloud, Kubernetes, Docker, or deployment credentials.

·        Installation occurred on self-hosted CI/CD runners, package-publishing systems, release engineering hosts, or deployment workflows.

·        CI/CD workflows exposed npm tokens, GitHub Actions tokens, repository secrets, package-publishing credentials, or cloud deployment credentials.

·        GitHub, npm, cloud, identity, artifact, or network logs are incomplete or not centrally correlated.

·        Internal mirrors or dependency caches retained affected package versions after public registry remediation.

Moderate Probability Exposure Conditions

·        Affected packages were present in dependency files but installation timing is unclear.

·        Affected packages were cached or mirrored internally but execution has not been confirmed.

·        Affected packages were used in development environments with limited credential access.

·        Build systems installed dependencies but had limited release, cloud, or package-publishing permissions.

·        Telemetry is sufficient to scope package exposure but insufficient to prove or disprove credential access.

·        GitHub and npm activity appears normal, but audit depth or retention is limited.

Lower Probability Exposure Conditions

·        Affected packages were not present in dependency files, lockfiles, caches, mirrors, build logs, containers, or artifacts.

·        Affected versions were blocked before installation.

·        Lifecycle scripts were disabled in the relevant workflows.

·        Installation occurred only in isolated environments without reusable credentials or outbound access.

·        Credential rotation and audit review confirmed no suspicious post-exposure activity.

·        Build artifacts from the exposure window were not promoted, deployed, or distributed.

Targeting Probability Disposition

The targeting probability is high for organizations that consumed the affected SAP-related npm package versions in privileged developer or CI/CD contexts. The probability is lower where exposure review confirms affected versions were never installed, lifecycle execution was blocked, secrets were not present, and post-exposure GitHub, npm, cloud, identity, network, and artifact review is clean.

S17 — MITRE ATT&CK Chain Flow Mapping

Stage 1 — Trusted Package Distribution Compromise

The attack begins with malicious package versions entering a trusted npm distribution path for SAP-related development packages. This creates a supply-chain execution opportunity through legitimate package resolution and dependency restoration.

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

Stage 2 — Developer or CI/CD Dependency Installation

A developer workstation, CI/CD runner, release workflow, or build environment installs or restores the affected package version. The installation path appears operationally normal because dependency installation is expected behavior in software development and release workflows.

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

·        MITRE ATT&CK: T1059 — Command and Scripting Interpreter.

Stage 3 — npm Lifecycle Execution Through JavaScript

The compromised package uses install-time lifecycle behavior to execute attacker-controlled logic. The reported preinstall hook and setup.mjs loader move the attack from package presence to local execution.

·        MITRE ATT&CK: T1059.007 — Command and Scripting Interpreter: JavaScript.

Stage 4 — Runtime Bootstrapping and Payload Execution

The loader stages or invokes runtime execution to run the credential-stealing and propagation payload. In the reported SAP npm incident, public reporting identifies Bun runtime execution as part of the malicious install-time flow.

·        MITRE ATT&CK: T1059 — Command and Scripting Interpreter.

·        MITRE ATT&CK: T1105 — Ingress Tool Transfer, where runtime or payload components are retrieved.

Stage 5 — Developer and CI/CD Secret Discovery

The payload searches for developer and automation secrets that may include GitHub tokens, npm tokens, SSH keys, cloud credentials, Kubernetes configuration, CI/CD secrets, and environment variables. This is the primary transition from package execution to enterprise exposure.

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

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

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

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

Stage 6 — Local Staging and Encrypted Handling

Collected secrets may be staged locally, serialized, encoded, compressed, or encrypted before outbound transfer. Public reporting describes encrypted handling of exfiltrated data in the SAP-related npm activity.

·        MITRE ATT&CK: T1074 — Data Staged.

·        MITRE ATT&CK: T1027.013 — Obfuscated Files or Information: Encrypted/Encoded File.

Stage 7 — Exfiltration Through Developer or Web Services

The attack may exfiltrate stolen material through GitHub or other web-accessible developer services. This stage should be treated as reported or likely only where telemetry confirms GitHub, webhook, raw-content, cloud-storage, paste-like, or unfamiliar outbound transfer after local credential collection.

·        MITRE ATT&CK: T1567.001 — Exfiltration Over Web Service: Exfiltration to Code Repository.

Stage 8 — Credential Reuse and Control-Plane Abuse

Stolen GitHub, npm, cloud, SSH, or CI/CD credentials may be reused to access repositories, package registries, cloud environments, deployment workflows, or automation systems. This stage shifts the incident from local package execution to broader control-plane compromise.

·        MITRE ATT&CK: T1078 — Valid Accounts.

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

Stage 9 — Repository, Workflow, or Package Propagation

Where credential scope permits, the attacker may modify repositories, workflows, packages, or package publication paths to propagate compromise. This is the stage most directly associated with Shai-Hulud-style npm propagation risk and should be treated as conditional unless organization-specific GitHub, npm, or repository evidence confirms it.

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

Stage 10 — Downstream Software Integrity Exposure

The final business-impact stage occurs when poisoned dependencies, modified repositories, malicious workflow outputs, stolen credentials, or exposed build environments create uncertainty around internal packages, containers, software bills of materials, build artifacts, release artifacts, or customer-facing software. This stage is a risk and assurance outcome, not a separate technique unless telemetry confirms additional malicious activity.

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

Observed / Reported ATT&CK Coverage

·        T1195.002 — Compromise Software Supply Chain.

·        T1059.007 — JavaScript.

·        T1059 — Command and Scripting Interpreter.

·        T1552.001 — Credentials In Files.

·        T1552.004 — Private Keys.

·        T1083 — File and Directory Discovery.

·        T1005 — Data from Local System.

·        T1074 — Data Staged.

·        T1027.013 — Encrypted/Encoded File.

·        T1567.001 — Exfiltration to Code Repository.

·        T1528 — Steal Application Access Token.

Conditional ATT&CK Coverage

·        T1078 — Valid Accounts, where stolen credentials are reused against GitHub, npm, cloud, CI/CD, or source-code platforms.

·        T1105 — Ingress Tool Transfer, where telemetry confirms runtime or payload retrieval.

·        T1195.002 — Compromise Software Supply Chain, where downstream repository, workflow, or package propagation is confirmed.

MITRE ATT&CK Chain Flow Disposition

The attack chain progresses from trusted package compromise to install-time JavaScript execution, runtime execution, credential discovery, local staging, encrypted handling, exfiltration, token theft, credential reuse, and potential downstream package or repository propagation. The most important defensive conclusion is that exposure review must not stop at package inventory. It must extend into execution telemetry, credential assurance, GitHub and npm audit review, CI/CD workflow validation, cloud-control-plane review, artifact assurance, and release integrity validation.

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

Attack Path Objective

Define the likely execution flow for SAP-related npm package poisoning and Shai-Hulud-style developer credential theft using observable signals rather than package indicators alone. This section connects trusted dependency exposure, install-time execution, runtime bootstrapping, credential discovery, encrypted handling, exfiltration, token abuse, and conditional downstream propagation.

Stage 1 — Trusted Dependency Exposure

The attack begins when compromised SAP-related npm package versions enter the trusted npm distribution path. Public reporting identifies affected SAP-related packages and versions, including mbt 1.2.48, @cap-js/db-service 2.10.1, @cap-js/postgres 2.2.2, and @cap-js/sqlite 2.2.2. These packages may enter developer and CI/CD environments through direct dependency installation, dependency restoration, lockfile use, dependency-cache reuse, internal npm mirror synchronization, build-image creation, or automated release workflows.

Primary Signals

·        Affected package versions appear in package.json, package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, yarn.lock, dependency caches, internal npm mirrors, package tarballs, build logs, containers, or software bills of materials.

·        Build or developer logs show package installation during the exposure window.

·        Internal npm mirrors or artifact repositories retain compromised package versions.

·        CI/CD dependency restoration pulls an affected version into a build environment.

Stage 2 — Install-Time Lifecycle Execution

The attack transitions from exposure to execution when npm lifecycle behavior triggers attacker-controlled code. Public reporting identifies a malicious package.json preinstall hook that runs setup.mjs, turning package installation into the initial execution vehicle. This is the critical trust-boundary crossing: a package expected to provide legitimate development functionality becomes a code execution path inside developer and CI/CD environments.

Primary Signals

·        npm, pnpm, or yarn executes preinstall, postinstall, setup.mjs, or suspicious lifecycle commands.

·        Package-manager parent processes spawn Node, Bun, shell, PowerShell, curl, wget, archive utilities, Python, or encoded-command behavior.

·        Execution occurs from node_modules, package caches, temporary directories, user-profile paths, CI workspaces, actions-runner paths, or _work directories.

·        Package installation is followed quickly by runtime activity, credential access, local staging, or outbound traffic.

Stage 3 — Runtime Bootstrapping

The attack uses runtime bootstrapping to move from lifecycle script execution into payload execution. Public reporting identifies Bun runtime execution as part of the malicious SAP npm package flow, with setup.mjs acting as a loader for the credential-stealing and propagation framework.

Primary Signals

·        Bun execution appears on systems where Bun is not approved or previously observed.

·        Bun or Node executes from dependency, cache, temporary, user-profile, or CI workspace paths.

·        Runtime execution is parented by npm, pnpm, yarn, shell, or CI runner processes.

·        Runtime execution occurs during dependency restoration rather than approved build-image provisioning.

·        Runtime activity is followed by file discovery, secret access, environment-variable enumeration, outbound transfer, GitHub activity, npm activity, or cloud activity.

Stage 4 — Developer and CI/CD Secret Discovery

After execution, the payload targets credentials and configuration material commonly present in developer and automation environments. Public reporting identifies developer credential and authentication-token theft as the core objective, while the completed Block 4 detection model prioritizes access to .npmrc, Git credentials, SSH keys, cloud credential files, Kubernetes configuration, Docker credentials, GitHub tokens, npm tokens, and CI/CD environment variables.

Primary Signals

·        Access to .npmrc, npm tokens, Git credential stores, SSH keys, cloud credential files, Kubernetes configuration, Docker credentials, repository configuration files, or CI/CD environment material.

·        Environment-variable enumeration containing token, secret, key, credential, password, GitHub, npm, AWS, Azure, GCP, Kubernetes, Docker, registry, deploy, or CI/CD naming patterns.

·        File discovery across home directories, repository roots, build workspaces, package caches, and release directories.

·        Process interaction with /proc/self/environ, environment dumping, runtime memory access, or CI runner secret material where telemetry permits visibility.

Stage 5 — Local Collection, Staging, and Encrypted Handling

Collected material may be staged locally before exfiltration. Public reporting describes encrypted handling of stolen data using AES-256-GCM and RSA-4096 key encapsulation. This stage is important because staging and encryption may be the last local evidence before outbound transfer or credential reuse.

Primary Signals

·        Creation of JSON, archive, encoded, compressed, encrypted, or blob-like files after credential access.

·        Short-lived files created in temporary, dependency, workspace, cache, or user-profile locations.

·        Runtime processes reading credential material and then writing new local files.

·        File staging followed by outbound transfer to GitHub, webhook services, raw-content hosts, cloud storage, paste-like platforms, or unfamiliar infrastructure.

Stage 6 — Exfiltration Through Developer-Adjacent Channels

The payload may exfiltrate stolen material through GitHub, developer-platform services, web-accessible endpoints, or attacker-controlled infrastructure. Network visibility alone may be insufficient because destinations such as GitHub or cloud services can be normal in developer workflows. Detection confidence increases when outbound transfer follows package lifecycle execution, runtime bootstrapping, credential access, or local staging.

Primary Signals

·        Outbound connections from npm, Node, Bun, shell, CI runner, or package-manager-descended process trees.

·        Upload-like traffic after credential access or local staging.

·        Connections to GitHub API paths, raw-content hosts, webhook services, paste-like platforms, cloud storage, file-sharing endpoints, or unfamiliar infrastructure.

·        New or unusual destination domains, request paths, user agents, bytes sent, or TLS metadata from developer and CI/CD systems.

·        GitHub activity from hosts, users, runners, user agents, autonomous systems, or geographies outside normal release behavior.

Stage 7 — Credential Reuse and Control-Plane Abuse

If credentials are stolen, the incident can move from local execution into control-plane abuse. Stolen GitHub, npm, cloud, SSH, or CI/CD credentials may be reused to access repositories, package registries, build systems, deployment workflows, cloud resources, or artifact stores. This stage materially increases enterprise impact because package removal alone does not revoke already-stolen credentials.

Primary Signals

·        GitHub repository creation, repository visibility change, workflow creation, workflow modification, deploy-key changes, webhook changes, secrets-related activity, or unusual API use after exposure.

·        npm token validation, token use, package publication, package version changes, maintainer changes, ownership changes, access changes, or package metadata updates.

·        AWS, Azure, or GCP activity from new locations, user agents, identities, access keys, service accounts, or automation contexts.

·        Secret-manager, key-vault, storage, compute, IAM, container-registry, artifact, or deployment activity outside normal release behavior.

·        Reuse of credentials from systems or identities that had exposed package installation.

Stage 8 — Repository, Workflow, Package, or Artifact Propagation

Where stolen credentials provide sufficient access, the attack may propagate through repositories, workflows, package publication paths, or downstream build artifacts. This stage is conditional and should not be assumed without supporting GitHub, npm, CI/CD, artifact, or repository evidence. Historical Shai-Hulud activity demonstrates propagation through npm packages and GitHub-based secret exposure, but this report should treat propagation in the SAP npm incident as evidence-dependent for each organization.

Primary Signals

·        New or modified .github/workflows/ content outside approved release processes.

·        Package publication or package metadata changes after suspicious developer or CI/CD activity.

·        Multiple repositories, workflows, packages, or release paths modified by the same identity within a compressed time window.

·        Build artifacts, containers, internal packages, or release outputs generated from exposed dependency sets.

·        Internal package mirrors or dependency caches continuing to serve affected package versions after public registry remediation.

Stage 9 — Software Integrity and Business Assurance Impact

The final business-impact stage is uncertainty around software integrity, release provenance, credential trust, and downstream exposure. Even without confirmed propagation, organizations may need to validate whether affected dependencies, stolen credentials, modified workflows, or compromised build environments influenced packages, containers, artifacts, deployments, or customer-facing releases.

Primary Signals

·        Affected package versions present in released artifacts, containers, SBOMs, build images, or promoted release outputs.

·        Build or release activity from exposed CI/CD runners during the exposure window.

·        Unexplained changes to workflow files, repository settings, deployment configuration, package metadata, artifact signatures, or provenance records.

·        Customer-facing packages, integrations, or SAP-related deliverables built from exposed dependency sets.

·        Gaps in telemetry that prevent confidence in whether execution, credential theft, or artifact impact occurred.

Attack Path Narrative Disposition

The attack path moves from trusted dependency exposure to install-time execution, runtime bootstrapping, credential discovery, local staging, encrypted handling, exfiltration, credential reuse, possible propagation, and software-integrity uncertainty. The strongest investigative priority is to determine whether affected package installation occurred on systems with reusable developer, CI/CD, package-registry, cloud, deployment, or artifact-signing credentials.

S19 — Attack Chain Risk Amplification Summary

Risk Amplification Objective

Explain why this supply-chain attack can exceed the impact of a single compromised package or developer endpoint. The risk amplifies because package installation occurs inside trusted development and automation environments that may hold credentials capable of modifying source code, publishing packages, accessing cloud resources, changing workflows, or producing release artifacts.

Amplification Factor 1 — Trusted Package Execution

The attack abuses the trust organizations place in npm package installation. A developer or CI/CD workflow may execute malicious lifecycle logic while performing routine dependency restoration. This reduces the chance that the initial activity is treated as suspicious unless telemetry connects package-manager behavior to unexpected runtime execution, credential access, or outbound activity.

Business Impact

·        Normal development workflows become execution paths.

·        Dependency restoration can trigger attacker-controlled code before application runtime.

·        Static package inventory does not prove whether execution occurred.

·        Package removal does not resolve credential exposure if secrets were already stolen.

Amplification Factor 2 — Developer Credential Concentration

Developer systems commonly contain GitHub tokens, SSH keys, npm credentials, cloud CLI credentials, Kubernetes configuration, Docker credentials, package-registry authentication, and local repository access. A single exposed developer system can therefore provide access beyond the local host.

Business Impact

·        Repository access may expand from one endpoint to multiple codebases.

·        GitHub, npm, cloud, SSH, and deployment credentials may require rotation.

·        Response scope may include source-code review, package-registry review, cloud audit, and identity assurance.

·        Incomplete endpoint telemetry can force broader containment and validation.

Amplification Factor 3 — CI/CD Secret Exposure

CI/CD environments can hold secrets with broader permissions than individual developers. Build runners may access source code, package registries, cloud deployment targets, artifact repositories, signing systems, and production release paths.

Business Impact

·        A single exposed build job can create multi-system credential risk.

·        Release workflows may need to be paused, validated, or re-baselined.

·        Managed runners and ephemeral containers may limit forensic reconstruction.

·        Secret exposure may remain uncertain even after the runner is destroyed.

Amplification Factor 4 — GitHub and Source-Code Platform Abuse

Stolen GitHub credentials or automation tokens may enable repository creation, workflow modification, deploy-key changes, webhook changes, repository visibility changes, or secrets-related activity. This can convert a package exposure event into a source-code platform trust incident.

Business Impact

·        Source-code integrity may require validation.

·        Workflow files may need to be reviewed for unauthorized logic.

·        Repository permissions, deploy keys, branch protections, webhooks, and secrets may require audit.

·        Developer or automation identities may need access review and token revocation.

Amplification Factor 5 — npm Registry and Package-Publishing Abuse

Stolen npm credentials may allow package publication, maintainer changes, ownership changes, token validation, access changes, or package metadata modification. This creates downstream propagation risk if the attacker can publish new poisoned versions or alter packages under trusted names.

Business Impact

·        Package-publishing trust may be degraded.

·        Maintainer and token governance may require emergency review.

·        Internal package consumers may need dependency and mirror validation.

·        Customer-facing packages may require assurance if release authority was exposed.

Amplification Factor 6 — Cloud and Deployment Credential Misuse

Cloud credentials, service-account keys, workload identities, deployment tokens, and secret-manager access may allow attackers to move from developer supply-chain compromise into cloud-control-plane activity. This stage is conditional but high impact when exposed credentials have meaningful privileges.

Business Impact

·        Secret stores, cloud storage, container registries, compute, IAM, and deployment paths may require review.

·        Cloud activity may show credential use without revealing how the credential was stolen.

·        Response may require broad token revocation, key rotation, role review, and deployment validation.

·        Production and staging environments may require assurance even without confirmed artifact tampering.

Amplification Factor 7 — Internal Mirror, Cache, and Artifact Persistence

Compromised packages may remain in internal npm mirrors, dependency caches, build images, containers, lockfiles, artifact repositories, or software bills of materials after public registry remediation. This creates residual exposure even after package versions are removed or deprecated publicly.

Business Impact

·        Internal systems may continue serving affected package versions.

·        Builds may remain exposed through cached dependencies.

·        Artifacts created during the exposure window may require provenance review.

·        Customer assurance may be required if affected dependency sets entered release outputs.

Amplification Factor 8 — Detection and Forensic Visibility Gaps

Managed CI/CD runners, ephemeral build containers, incomplete command-line logging, weak file-access telemetry, limited npm audit depth, incomplete GitHub logs, and encrypted egress can prevent defenders from proving whether credentials were stolen or downstream activity occurred.

Business Impact

·        Response may shift from evidence-driven containment to precautionary rotation and validation.

·        Lack of telemetry can increase response cost and executive uncertainty.

·        Investigation may expand across endpoints, CI/CD, GitHub, npm, cloud, identity, network, and artifact systems.

·        Residual risk remains higher when exposure cannot be confidently disproven.

Risk Amplification Disposition

The attack chain amplifies because npm package trust intersects with developer credentials, CI/CD secrets, source-code platforms, package registries, cloud environments, internal caches, and release artifacts. The most material risk is not package presence alone; it is the possibility that exposed execution environments held credentials capable of changing code, publishing packages, modifying workflows, accessing cloud resources, or influencing downstream software releases.

Figure 3

S20 — Tactics, Techniques, and Procedures

TTP Objective

Summarize the adversary behaviors relevant to this incident in practical operational terms. This section describes observed, reported, likely, and conditional behaviors without overstating unsupported activity.

Tactic 1 — Supply-Chain Initial Access

Technique

Compromise or abuse of trusted npm package publishing to introduce malicious package versions into SAP-related dependency workflows.

Procedure

The adversary publishes or modifies trusted SAP-related npm package versions so that consuming developer or CI/CD systems install malicious package content through normal dependency restoration. Public reporting identifies compromised SAP-related packages and malicious versions connected to SAP cloud application development workflows.

Operational Relevance

·        This makes package installation the initial access path.

·        The consuming organization may not be individually targeted before installation.

·        Exposure depends on dependency resolution, lockfile state, cache state, mirror synchronization, and build timing.

Tactic 2 — Install-Time Execution

Technique

Abuse of npm lifecycle scripts to execute attacker-controlled code during package installation.

Procedure

The malicious package introduces lifecycle behavior, including a preinstall hook that runs setup.mjs. This turns dependency installation into a script execution opportunity before application runtime or deployment validation.

Operational Relevance

·        Package-manager execution should be reviewed for unexpected child processes.

·        CI/CD dependency restoration is a high-value detection point.

·        Lifecycle script controls and build-policy restrictions can reduce execution risk.

Tactic 3 — Runtime Bootstrapping

Technique

Use of JavaScript runtime behavior and Bun execution to launch payload functionality.

Procedure

The reported setup.mjs loader invokes or stages Bun runtime execution to run the credential-stealing and propagation framework. This may create first-seen or abnormal Bun activity on systems where Bun is not approved or expected.

Operational Relevance

·        Bun execution from dependency, cache, temporary, or CI workspace paths is high priority.

·        Approved runtime baselines are required to separate legitimate Bun use from suspicious execution.

·        Runtime bootstrapping provides a durable behavior signal even if package names or filenames change.

Tactic 4 — Credential Discovery

Technique

Search for developer, package-registry, source-code, cloud, SSH, Kubernetes, Docker, and CI/CD secrets.

Procedure

The payload searches local files, environment variables, and development configuration paths for reusable credentials. Credential targets may include .npmrc, npm tokens, GitHub tokens, SSH keys, cloud credentials, Kubernetes configuration, Docker credentials, and CI/CD environment material. Public reporting identifies the campaign goal as stealing developer credentials and authentication tokens.

Operational Relevance

·        Credential access is the central risk transition.

·        File access telemetry and command-line logging materially improve confidence.

·        Environment-variable-only secret exposure may not generate file access evidence.

·        Absence of file-read telemetry does not prove absence of theft.

Tactic 5 — Local Collection and Encrypted Staging

Technique

Collection, staging, encoding, compression, or encryption of stolen material before outbound transfer.

Procedure

Collected secrets may be staged locally and encrypted before exfiltration. Public reporting describes AES-256-GCM encryption and RSA-4096 key encapsulation for stolen data, limiting defender visibility into exfiltrated content.

Operational Relevance

·        Temporary file creation after credential access should be investigated.

·        Encoded, compressed, encrypted, or blob-like files created by package-manager-descended processes are suspicious.

·        Encrypted handling reduces content visibility and increases reliance on process, file, timing, and destination context.

Tactic 6 — Exfiltration

Technique

Outbound transfer through GitHub, developer-platform services, web services, or attacker-controlled destinations.

Procedure

The payload may transfer stolen material through GitHub or other web-accessible channels. Detection should not rely only on destination reputation because developer systems and CI/CD runners commonly access GitHub, package registries, cloud services, and webhook destinations.

Operational Relevance

·        Network detections require source role, process attribution, timing, destination novelty, and upload behavior.

·        GitHub or cloud destinations are not automatically benign when accessed after credential discovery.

·        Proxy, DNS, EDR network, and CI/CD egress telemetry should be correlated.

Tactic 7 — Token Abuse and Valid Account Use

Technique

Reuse of stolen GitHub, npm, cloud, SSH, or CI/CD credentials.

Procedure

If stolen credentials are valid and sufficiently privileged, the adversary may access source-code platforms, package registries, cloud resources, deployment systems, or automation workflows. This stage should be validated through audit logs rather than assumed.

Operational Relevance

·        Token use from new systems, source IPs, user agents, geographies, or automation contexts is high priority.

·        GitHub, npm, cloud, identity, and CI/CD audit logs must be reviewed after exposure.

·        Token rotation and revocation are required when execution occurred on systems holding reusable credentials.

Tactic 8 — Repository, Workflow, and Package Propagation

Technique

Use of stolen credentials to modify repositories, workflows, package contents, package metadata, or publication paths.

Procedure

Where credential scope permits, the adversary may create or modify GitHub repositories, alter workflow files, change deploy keys or webhooks, publish new package versions, alter package metadata, or propagate to additional package consumers. This stage is consistent with Shai-Hulud-style npm propagation but must be confirmed per organization.

Operational Relevance

·        Repository and package changes after local exposure are high-priority investigation targets.

·        Workflow changes should be reviewed for secret dumping, external callbacks, package publishing, or unauthorized artifact handling.

·        npm maintainer, owner, access, token, and publication history should be validated.

Tactic 9 — Artifact and Release Integrity Risk

Technique

Creation of uncertainty around build outputs, internal packages, containers, release artifacts, and software provenance.

Procedure

If exposed dependency sets were used during build or release workflows, organizations may need to validate whether produced artifacts, containers, packages, or software bills of materials were influenced by compromised dependencies or stolen credentials. This is primarily an assurance and integrity risk unless telemetry confirms malicious artifact modification.

Operational Relevance

·        Build artifacts from the exposure window require provenance review.

·        Internal mirrors and dependency caches may preserve exposure after public remediation.

·        Customer-facing releases may require validation and assurance if built from exposed environments.

TTP Disposition

The core TTP set is centered on npm supply-chain compromise, install-time JavaScript execution, runtime bootstrapping, credential discovery, local staging, encrypted exfiltration, token abuse, and conditional propagation. Cloud abuse, artifact compromise, and downstream customer impact should be treated as conditional until supported by telemetry or exposure evidence.

S20A — Adversary Tradecraft Summary

Tradecraft Summary Objective

Summarize the adversary’s operational method and defensive implications in a concise final narrative for Block 3.

Adversary Operating Model

The adversary uses trusted npm package distribution as the access path, not direct exploitation of a traditional enterprise perimeter. By placing malicious logic inside SAP-related npm package versions, the actor relies on normal developer and CI/CD dependency installation to execute code in trusted environments. This approach allows the attack to reach systems that may hold credentials, source-code access, package-publishing authority, cloud access, and deployment permissions.

Tradecraft Strengths

·        The attack blends into legitimate dependency installation workflows.

·        npm lifecycle scripts provide execution before application runtime.

·        Developer and CI/CD environments are credential-rich targets.

·        Bun or runtime bootstrapping can create payload execution paths that differ from expected package behavior.

·        Credential theft can preserve attacker access after malicious packages are removed.

·        GitHub and npm abuse can look like legitimate developer or maintainer activity without identity, source, repository, and timing context.

·        Internal mirrors, caches, and build artifacts can preserve exposure beyond public registry remediation.

·        Ephemeral CI/CD environments and incomplete telemetry can prevent defenders from proving whether theft occurred.

Tradecraft Limitations

·        The attacker depends on package consumption by downstream environments.

·        Lifecycle execution must occur or an equivalent execution path must be available.

·        Downstream impact depends on credential presence, token scope, repository permissions, cloud permissions, and package-publishing rights.

·        Strong endpoint telemetry, CI/CD logs, GitHub audit logs, npm audit logs, cloud audit logs, identity logs, and network telemetry increase detection probability.

·        Rapid credential rotation and token revocation reduce post-exposure value.

·        Package provenance, restricted publishing, CI/CD secret scoping, and install-script controls reduce propagation opportunity.

·        Internal mirror, cache, lockfile, SBOM, and artifact records can support exposure reconstruction.

Defensive Interpretation

This activity should be interpreted as a developer supply-chain credential-theft operation with propagation potential. Package names and affected versions are necessary for scoping, but they are not sufficient for detection or containment. Defenders must determine whether affected package versions executed, whether secrets were accessible, whether credentials were reused, whether source-code or package-registry activity changed, whether cloud access occurred, and whether release artifacts require assurance.

Business Interpretation

The primary business issue is software trust. Affected organizations may need to prove that developer credentials, CI/CD workflows, source-code repositories, package registries, cloud deployment paths, internal package mirrors, and release artifacts remained trustworthy after exposure. Where telemetry cannot provide that assurance, the response burden shifts to precautionary credential rotation, artifact validation, workflow review, and executive governance.

Adversary Tradecraft Disposition

The adversary tradecraft is high leverage because it turns trusted package installation into execution, credential theft, and possible propagation. The highest-risk outcomes occur when affected package installation intersects with privileged developer identities, CI/CD secrets, package-publishing authority, source-code write access, cloud deployment credentials, or customer-facing release workflows.

S21 — Detection Strategy Overview

Detection Strategy Objective

Detect malicious activity caused by compromised SAP-related npm packages before developer credentials, CI/CD secrets, cloud keys, GitHub tokens, npm tokens, SSH material, or package-publishing credentials can be used for downstream compromise.

This strategy treats the incident as a trusted developer dependency compromise. The primary detection concern is not exploitation of a single vulnerability. The primary detection concern is malicious execution during package installation inside developer workstations, CI/CD runners, release workflows, and build environments.

Detection Strategy Summary

The April 2026 SAP npm compromise centers on poisoned package versions that introduced malicious install-time execution. Public reporting identifies a preinstall hook running setup.mjs, with Bun-based payload execution, credential theft, encrypted exfiltration, and propagation behavior aligned with Shai-Hulud / TeamPCP-style npm supply-chain activity.

Detection should focus on five behavior clusters:

·        npm lifecycle execution from compromised or suspicious dependency paths.

·        Unexpected Bun runtime download, staging, or execution.

·        Developer, cloud, and CI/CD secret discovery or collection.

·        GitHub, npm, and CI/CD token abuse.

·        Suspicious exfiltration or propagation following dependency installation.

Governing Detection Model

The governing model is behavior-first and trust-boundary-aware.

This incident should not be detected only through static package names, package versions, file hashes, or known infrastructure. Those indicators are useful for scoping and retroactive exposure checks, but they are too narrow for durable detection. The higher-value model is to detect the attack sequence created when a trusted dependency becomes the execution vehicle.

Detection should therefore focus on the following trust-boundary transitions:

·        A trusted SAP-related npm dependency executes attacker-controlled install logic.

·        A package lifecycle event launches a loader, runtime, shell, or script outside normal build expectations.

·        A developer or CI/CD environment becomes a source of secrets.

·        GitHub, npm, cloud, or CI/CD tokens are used outside normal release behavior.

·        Stolen credentials enable exfiltration, package poisoning, repository modification, or workflow abuse.

The legacy Shai-Hulud report remains useful as campaign-lineage context because it identifies earlier npm package poisoning, Bun-based execution, credential harvesting, GitHub workflow abuse, cloud credential exposure, and propagation patterns. It should not be used as the current report structure because it predates this SAP npm incident and was built under an older CyberDax format.

Primary Detection Priorities

Priority 1 — Install-Time Execution Abuse

Detect package-manager lifecycle execution that spawns unexpected interpreters, runtimes, shells, download utilities, or loader files.

High-priority behavior includes:

·        npm, pnpm, or yarn spawning node, bun, sh, bash, powershell, curl, wget, or archive tools during dependency installation.

·        Execution of setup.mjs or loader-style JavaScript from package, dependency-cache, temporary, or CI workspace paths.

·        Package installation followed by rapid credential discovery, environment enumeration, repository modification, or outbound API activity.

·        Install-time script execution on CI/CD runners that are expected to perform deterministic dependency restoration.

Priority 2 — Unexpected Bun Runtime Activity

Detect Bun runtime staging or execution where Bun is not an approved runtime for the host, repository, build image, or release workflow.

High-priority behavior includes:

·        Bun launched by npm lifecycle scripts.

·        Bun executing from dependency, cache, temporary, user-profile, or CI workspace paths.

·        Bun execution followed by file discovery, environment-variable access, token validation, GitHub API activity, npm publishing activity, or cloud API activity.

·        First-seen Bun execution on developer endpoints, release hosts, or build runners.

Priority 3 — Developer and CI/CD Secret Access

Detect discovery, access, staging, or collection of secrets after package installation activity.

High-priority behavior includes:

·        Access to .npmrc, SSH keys, Git credential stores, cloud credential files, Kubernetes configuration files, package-registry tokens, and CI/CD environment variables.

·        Enumeration of environment variables with token, secret, key, credential, password, registry, cloud, GitHub, npm, or deployment naming patterns.

·        Creation of temporary or encoded files consistent with staged credential collection.

·        Cloud metadata access from developer workstations or CI/CD jobs that do not normally require metadata service interaction.

Priority 4 — GitHub, npm, and Workflow Abuse

Detect unauthorized use of developer, maintainer, package-registry, or automation tokens.

High-priority behavior includes:

·        Unexpected GitHub repository creation, workflow creation, workflow modification, repository visibility changes, or secrets-related activity.

·        New or modified .github/workflows/ content following suspicious npm install behavior.

·        Unexpected npm publish, npm version, token validation, ownership change, or package release activity.

·        GitHub, npm, or cloud API use from systems, users, user agents, geographies, or autonomous systems outside normal release patterns.

Priority 5 — Exfiltration and Propagation

Detect suspicious outbound transfer and downstream compromise activity following dependency execution.

High-priority behavior includes:

·        Outbound traffic to GitHub API paths, webhook services, paste-like services, raw-content hosts, or unfamiliar infrastructure after credential-access behavior.

·        Creation of repositories, workflow artifacts, encoded files, encrypted blobs, or compressed data consistent with staged exfiltration.

·        Package publication or repository modification after local secret discovery.

·        Reuse of stolen tokens across GitHub, npm, cloud, and CI/CD control planes.

Detection Scope

In Scope

·        SAP-related npm package install activity.

·        npm lifecycle script execution.

·        Developer workstation process and file activity.

·        CI/CD runner process and file activity.

·        Bun runtime staging and execution.

·        GitHub repository, workflow, token, and secrets-related activity.

·        npm authentication and package-publishing activity.

·        Cloud credential access and suspicious control-plane use.

·        Network and DNS egress from developer and build environments.

Out of Scope

·        Generic npm package risk without execution or exposure context.

·        Broad malware hunting that is not tied to developer, CI/CD, package-manager, or supply-chain behavior.

·        CVE-style vulnerability detection, because this incident is governed by package compromise and credential theft.

·        Email phishing detection, unless later evidence confirms email as part of package-maintainer compromise.

·        Static IOC matching as the sole detection strategy.

Detection Engineering Principles

·        Detect behavior, not only package names.

·        Use package names and versions for scoping, exposure review, and enrichment.

·        Separate developer workstation behavior from CI/CD runner behavior.

·        Treat Bun as suspicious only where it is unexpected for the asset, repository, build image, or workflow.

·        Prioritize process ancestry, execution path, and event sequence.

·        Correlate endpoint behavior with GitHub, npm, cloud, CI/CD, DNS, and network telemetry.

·        Avoid alerts on all npm installs, all GitHub API activity, or all package publishing.

·        Do not make any rule dependent on another rule firing first.

·        Preserve standalone detection value for each system-specific S25 rule.

Initial Detection Hypothesis

A compromised SAP-related npm package installation is likely to produce one or more of the following observable behaviors:

·        Package-manager lifecycle execution launches an unexpected loader, runtime, shell, or script.

·        Bun or Node executes from an unusual dependency, cache, temporary, user-profile, or CI workspace path.

·        Developer, cloud, package-registry, repository, or CI/CD secrets are accessed or staged.

·        GitHub, npm, cloud, or CI/CD tokens are validated or abused.

·        Repository workflows, package releases, or publishing behavior change unexpectedly.

·        Suspicious egress occurs after local secret discovery or environment enumeration.

Detection Strategy Disposition

The detection strategy is viable and high-value.

The strongest detection opportunities are sequence-based behaviors that connect package installation, unexpected runtime execution, credential access, token abuse, and suspicious egress. S25 rule development should prioritize high-confidence detections that remain useful even if package names, file names, infrastructure, or payload details change.

S22 — Primary Detection Signals

Detection Signal Objective

Define the primary observable signals required to detect malicious package execution, credential theft, token abuse, exfiltration, and propagation associated with the SAP-related npm package poisoning incident.

The signal model is behavior-based. Package names, package versions, file names, hashes, and infrastructure indicators should be used for scoping, enrichment, and exposure review, but they should not be treated as the sole detection strategy.

Primary Signal Model

Detection should prioritize chained behaviors that show a trusted npm dependency crossing into malicious execution, credential access, token abuse, and downstream supply-chain activity.

The highest-value signal sequence is:

·        SAP-related npm dependency installation occurs in a developer, CI/CD, release, or build environment.

·        Package lifecycle execution launches an unexpected script, runtime, shell, loader, or network utility.

·        The process tree accesses developer, package-registry, cloud, repository, or CI/CD secrets.

·        GitHub, npm, cloud, or CI/CD tokens are validated, reused, or abused.

·        Staged data, repository changes, package publishing, or suspicious outbound transfer follows.

Signal Category 1 — Install-Time npm Lifecycle Abuse

This signal identifies malicious or abnormal execution during package installation.

High-value signals include:

·        npm, pnpm, or yarn spawning unexpected child processes during dependency installation.

·        Package-manager execution launching node, bun, sh, bash, powershell, cmd, curl, wget, archive utilities, or encoded commands.

·        Loader-style JavaScript execution from dependency, cache, temporary, user-profile, or CI workspace paths.

·        Install-time execution occurring on CI/CD runners where dependency restoration is expected to be deterministic.

·        Package installation followed quickly by credential access, repository modification, npm publishing activity, cloud API activity, or suspicious egress.

Signal Category 2 — Unexpected Bun and Runtime Execution

This signal identifies runtime execution inconsistent with the host, repository, build image, or release workflow.

High-value signals include:

·        Bun launched by a package manager, shell, Node process, or CI runner.

·        Bun execution from dependency directories, package caches, temporary folders, user-profile paths, or CI workspaces.

·        First-seen Bun activity on developer endpoints, release systems, build hosts, or automation runners.

·        Bun or Node execution followed by file discovery, environment-variable enumeration, credential access, token validation, GitHub API activity, npm registry activity, or cloud API activity.

·        Runtime download or staging during package installation rather than through approved build-image provisioning.

Signal Category 3 — Developer and CI/CD Credential Discovery and Staging

This signal identifies access to secrets that are commonly present on developer systems and build infrastructure.

High-value signals include:

·        Access to .npmrc, npm tokens, Git credential stores, SSH key paths, cloud credential files, Kubernetes configuration files, Docker credentials, repository configuration files, and CI/CD environment variables.

·        Environment-variable enumeration involving token, secret, key, credential, password, GitHub, npm, AWS, Azure, GCP, Kubernetes, Docker, registry, deploy, or CI/CD naming patterns.

·        File discovery across home directories, repository roots, package caches, build workspaces, and release directories after suspicious package execution.

·        Creation of JSON, archive, encoded, encrypted, compressed, or blob-like files after credential access.

·        Short-lived local staging files created before GitHub, webhook, raw-content, paste-like, cloud, or unfamiliar outbound activity.

The legacy Shai-Hulud report identified earlier campaign artifacts involving credential staging files, npm package abuse, Bun-based execution, GitHub workflow abuse, and cloud credential exposure. Those artifacts should be treated as lineage indicators and exposure-review aids, not as the complete signal model for this SAP npm incident.

Signal Category 4 — GitHub Repository and Workflow Abuse

This signal identifies unauthorized use of GitHub credentials for persistence, exfiltration, workflow manipulation, or propagation.

High-value signals include:

·        New GitHub repository creation by developer, maintainer, or automation identities after suspicious package installation.

·        Repository visibility changes or unusual repository metadata following suspicious endpoint or CI/CD activity.

·        Creation or modification of .github/workflows/ content outside approved release processes.

·        Workflow logic attempting to access broad secrets, dump environment variables, publish packages, or call external endpoints.

·        GitHub API calls from developer workstations, build containers, or CI/CD runners that do not normally perform repository administration.

·        Token use from new systems, locations, autonomous systems, user agents, or automation contexts.

Signal Category 5 — npm Registry and Package-Publishing Abuse

This signal identifies reuse of stolen npm credentials to publish, modify, or propagate malicious packages.

High-value signals include:

·        Unexpected npm publish, npm version, token validation, package ownership change, access change, or maintainer change.

·        Package publication from developer endpoints, CI/CD runners, geographies, IP ranges, or user agents outside normal release patterns.

·        New package versions created outside expected release windows.

·        Registry activity following suspicious package installation, credential access, GitHub workflow changes, or local secret staging.

·        Package metadata, lifecycle scripts, maintainers, or release automation modified without approved change context.

Signal Category 6 — Cloud Credential and Control-Plane Abuse

This signal identifies downstream use of stolen cloud or deployment credentials.

High-value signals include:

·        AWS, Azure, or GCP API activity from new locations, user agents, systems, identities, or automation contexts.

·        Cloud access-key, service-account, workload-identity, or deployment-token use shortly after developer endpoint or CI/CD compromise indicators.

·        Cloud metadata service access from developer workstations or CI/CD jobs without approved metadata-service dependency.

·        Secret-manager, key-vault, storage, compute, IAM, service-account, container-registry, or deployment activity outside normal build and release behavior.

·        Creation or modification of access keys, service accounts, permissions, policies, workload identities, or deployment credentials.

Signal Category 7 — Suspicious Egress, Exfiltration, and Propagation

This signal identifies outbound transfer and downstream spread after credential access or local staging.

High-value signals include:

·        Outbound connections to GitHub API paths, raw-content hosts, webhook services, paste-like platforms, file-sharing endpoints, cloud storage, or unfamiliar infrastructure after secret access.

·        Upload-like traffic from developer endpoints or CI/CD runners following package lifecycle execution.

·        Encoded, compressed, encrypted, or blob-like payload transfer after local collection.

·        Repeated outbound attempts from package-manager, Node, Bun, shell, or CI runner process trees.

·        Multiple repositories, packages, workflows, or release paths modified by the same identity within a compressed time window.

·        Repeated patterns of package install, runtime execution, credential access, repository modification, package publishing, or outbound transfer across users or projects.

Signal Prioritization

Highest Priority Signals

·        Package-manager lifecycle execution spawning unexpected loaders, runtimes, shells, download utilities, or encoded commands.

·        Bun or Node execution from dependency, cache, temporary, user-profile, or CI workspace paths.

·        Credential access following suspicious npm install activity.

·        GitHub workflow, repository, or secret-related activity following suspicious package execution.

·        npm publishing or package-management changes following credential discovery.

·        Suspicious outbound transfer after local collection or staging.

Secondary Priority Signals

·        Presence of known affected package versions in dependency files, lockfiles, package caches, build logs, or artifact repositories.

·        First-seen Bun activity in developer or CI/CD environments.

·        Cloud metadata access from unexpected systems.

·        Encoded, encrypted, compressed, or blob-like local file staging.

·        GitHub, npm, cloud, or CI/CD API activity from unusual locations, systems, user agents, or automation contexts.

Enrichment Signals

·        Package name and version.

·        Repository and dependency-lockfile context.

·        Developer endpoint, CI/CD runner, release system, or build image role.

·        Parent-child process lineage.

·        User identity, maintainer role, and automation identity.

·        GitHub organization, repository, workflow, and secret-access context.

·        npm package ownership, maintainer, token, and publishing history.

·        Cloud account, project, subscription, tenant, identity, and access-key context.

·        Network destination, request path, user agent, reputation, and historical baseline.

Signal Confidence Model

High Confidence

High-confidence signals connect install-time execution to credential access, token abuse, exfiltration, or propagation.

Examples include:

·        Package-manager lifecycle execution launches Bun or Node from an abnormal dependency path and is followed by access to .npmrc, cloud credentials, SSH keys, or GitHub token material.

·        A CI/CD runner installs an exposed package version and then creates or modifies GitHub workflow content.

·        A developer endpoint executes a loader-style script, stages secret-like files, and performs upload-like outbound activity.

·        An npm account publishes new package versions shortly after suspicious developer endpoint or CI/CD runner activity.

Medium Confidence

Medium-confidence signals are suspicious but lack complete sequence context.

Examples include:

·        First-seen Bun execution on a developer workstation or build runner.

·        GitHub API activity from a CI/CD runner outside normal user-agent or release patterns.

·        Node or Bun accessing credential files without confirmed package-install context.

·        npm publishing outside normal release windows.

Low Confidence

Low-confidence signals are useful for enrichment, scoping, or retrospective exposure review but should not drive high-priority alerting by themselves.

Examples include:

·        Affected package version present in a lockfile.

·        Generic npm install activity.

·        Generic GitHub API access.

·        Generic cloud API activity.

·        Generic outbound HTTPS traffic from developer or build systems.

Detection Signal Disposition

The primary detection signal set is viable and strong.

The highest-value signals are chained behaviors that connect poisoned dependency installation, install-time execution, unexpected runtime behavior, credential access, token abuse, exfiltration, and propagation. S23 should define the telemetry required to observe these signals reliably, and S24 should separate strong detection opportunities from expected gaps.

S23 — Telemetry Requirements

Telemetry Requirements Objective

Define the telemetry required to detect and reconstruct malicious npm package execution, developer and CI/CD credential access, GitHub and npm token abuse, cloud credential misuse, exfiltration, and propagation associated with the SAP-related npm package poisoning incident.

Telemetry must support behavior-chain reconstruction. The priority is not only to identify whether an affected package was present, but to determine whether package installation led to execution, credential access, token abuse, suspicious egress, or downstream supply-chain compromise.

Core Telemetry Requirement

Defenders need visibility across the developer supply-chain path:

·        Developer workstations.

·        CI/CD runners.

·        Package-manager activity.

·        Source-code platforms.

·        npm registry activity.

·        Cloud control-plane activity.

·        Identity, token, and secrets systems.

·        DNS, proxy, and network egress.

·        Dependency caches, artifacts, and container registries.

No single telemetry source is sufficient. Endpoint and CI/CD telemetry show execution and local secret access. GitHub, npm, cloud, and identity telemetry show post-theft credential use. DNS, proxy, and network telemetry show suspicious egress. SIEM correlation is required to connect these layers into a coherent attack sequence.

Telemetry Category 1 — Endpoint and Developer Workstation Telemetry

Endpoint telemetry is required to detect package-manager execution, child-process behavior, runtime staging, credential access, local collection, and outbound activity from developer systems.

Required telemetry includes:

·        Process creation events.

·        Parent-child process lineage.

·        Full command-line arguments.

·        Executable path and working directory.

·        User and host identity.

·        File read, write, create, rename, and delete events.

·        Network connections by process where available.

·        Script execution telemetry for JavaScript, shell, PowerShell, and CI helper scripts.

·        First-seen executable and runtime activity.

·        EDR detections tied to credential access, suspicious scripting, unusual runtime execution, or local staging.

Required coverage includes:

·        Developer laptops and workstations.

·        Release engineering systems.

·        Package-publishing systems.

·        Systems used to authenticate to GitHub, npm, cloud platforms, or CI/CD services.

·        Administrative systems used to manage source-code or package-registry access.

Minimum useful fields include:

·        Timestamp.

·        Hostname.

·        User.

·        Process name.

·        Process path.

·        Process command line.

·        Parent process name.

·        Parent process command line.

·        Working directory.

·        File path.

·        File operation.

·        Destination domain, IP, URL, or request path where available.

·        Process hash where available.

Telemetry Category 2 — CI/CD Runner and Build System Telemetry

CI/CD telemetry is required because poisoned npm dependencies may execute inside build pipelines that hold repository secrets, deployment credentials, package-publishing tokens, cloud access, or artifact-signing authority.

Required telemetry includes:

·        Job start and end events.

·        Workflow name, job name, step name, and runner identity.

·        Repository, branch, commit, pull request, and triggering actor.

·        Package-install commands and logs.

·        Child-process execution on self-hosted or instrumented runners.

·        Secret injection and secret-use events where available.

·        Artifact creation, upload, and modification events.

·        Cache restore and cache write events.

·        Build image and runner image metadata.

·        Outbound network activity from runners.

·        Workflow file creation and modification history.

·        Runner registration, deregistration, and privilege changes.

Required coverage includes:

·        Self-hosted GitHub Actions runners.

·        Managed CI/CD runners where telemetry is available.

·        Build containers and ephemeral runners.

·        Release pipelines.

·        Package-publishing workflows.

·        Deployment workflows.

·        Artifact-building and artifact-signing workflows.

Minimum useful fields include:

·        Timestamp.

·        Repository.

·        Workflow.

·        Job.

·        Step.

·        Runner name.

·        Runner type.

·        Triggering actor.

·        Commit SHA.

·        Branch.

·        Pull request identifier.

·        Command executed.

·        Build image.

·        Artifact name.

·        Cache key.

·        Secret reference name where available.

·        Destination domain or URL.

·        Job result.

Telemetry Category 3 — Package-Manager and npm Registry Telemetry

Package-manager and npm registry telemetry is required to identify exposure, lifecycle-script execution, dependency restoration paths, token activity, and package-publishing abuse.

Required telemetry includes:

·        package.json dependency history.

·        Lockfile history for package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, and yarn.lock.

·        Package install logs.

·        Package lifecycle script execution logs.

·        Dependency-cache records.

·        Internal artifact repository and npm mirror records.

·        npm authentication events.

·        npm token creation, validation, revocation, and use events.

·        npm package publication events.

·        npm package ownership, maintainer, access, and metadata changes.

·        Package provenance and signing metadata where available.

Required coverage includes:

·        Developer endpoints.

·        CI/CD runners.

·        Internal artifact repositories.

·        Dependency caches.

·        Package-publishing systems.

·        npm organization and package-maintainer accounts.

Minimum useful fields include:

·        Package name.

·        Package version.

·        Registry source.

·        Install timestamp.

·        Install command.

·        Lifecycle script name.

·        Lifecycle script command.

·        User.

·        Host or runner.

·        Repository.

·        Lockfile path.

·        npm account.

·        Token identifier where available.

·        Source IP.

·        User agent.

·        Publication timestamp.

·        Package metadata change type.

Telemetry Category 4 — GitHub and Source-Code Platform Telemetry

Source-code platform telemetry is required to detect repository creation, workflow abuse, token misuse, secrets exposure, persistence, and propagation.

Required telemetry includes:

·        Repository creation events.

·        Repository visibility and metadata changes.

·        Branch, tag, commit, and release events.

·        Workflow file creation and modification events.

·        Workflow run events.

·        Secrets creation, update, deletion, and access events where available.

·        Personal access token, fine-grained token, GitHub App, and OAuth App activity.

·        Deploy key creation or modification.

·        Webhook creation or modification.

·        Organization membership, permission, and role changes.

·        API access logs.

·        Audit log events for administrative actions.

Required coverage includes:

·        GitHub organizations.

·        Enterprise repositories.

·        Developer personal repositories used for company work.

·        Package-maintainer repositories.

·        Release automation repositories.

·        CI/CD configuration repositories.

Minimum useful fields include:

·        Timestamp.

·        Actor.

·        Actor type.

·        Repository.

·        Organization.

·        Event type.

·        Source IP.

·        User agent.

·        Token or app identifier where available.

·        Workflow path.

·        Workflow run identifier.

·        Commit SHA.

·        Branch.

·        Permission change.

·        Repository visibility.

·        API endpoint or action.

·        Authentication method.

Telemetry Category 5 — Cloud Control-Plane and Secrets Telemetry

Cloud and secrets telemetry is required to detect downstream use of stolen cloud credentials, deployment tokens, workload identities, service accounts, and secret-store access.

Required telemetry includes:

·        AWS CloudTrail, Azure Activity Logs, Microsoft Entra ID logs, GCP Cloud Audit Logs, and equivalent platform audit sources.

·        IAM, service-account, workload-identity, and access-key events.

·        Secret-manager and key-vault access events.

·        Container registry events.

·        Storage, compute, serverless, and deployment events.

·        Role assumption and privilege change events.

·        API activity by user, service account, workload identity, access key, or token.

·        Cloud metadata access telemetry where available.

·        Cloud network flow and egress logs where available.

Required coverage includes:

·        Cloud accounts, subscriptions, projects, and tenants connected to development or CI/CD workflows.

·        Build and deployment environments.

·        Container registries.

·        Artifact storage.

·        Secret stores.

·        Production and staging deployment accounts.

·        Developer sandbox accounts that may hold reusable credentials.

Minimum useful fields include:

·        Timestamp.

·        Cloud provider.

·        Account, subscription, project, or tenant.

·        Identity.

·        Access key or credential identifier where available.

·        API action.

·        Resource.

·        Source IP.

·        User agent.

·        Region.

·        Authentication method.

·        MFA or conditional-access context where available.

·        Role assumption chain.

·        Result code.

·        Request parameters where available.

Telemetry Category 6 — Identity, Token, and Access Management Telemetry

Identity telemetry is required to determine whether stolen credentials were accessed, validated, reused, rotated, or abused across developer, CI/CD, source-code, package-registry, and cloud systems.

Required telemetry includes:

·        SSO authentication logs.

·        MFA events.

·        Conditional-access results.

·        OAuth app authorization events.

·        Personal access token and fine-grained token activity.

·        npm token creation, validation, revocation, and use events.

·        Cloud access-key creation, use, and revocation events.

·        SSH key creation, use, and modification events where available.

·        Deploy key activity.

·        CI/CD secret injection and token-use events where available.

·        Secret-manager access logs.

Required coverage includes:

·        Developer identities.

·        Maintainer identities.

·        Automation identities.

·        Service accounts.

·        Package-publishing identities.

·        CI/CD identities.

·        Cloud deployment identities.

·        Source-code platform administrators.

Minimum useful fields include:

·        Timestamp.

·        Identity.

·        Credential type.

·        Credential identifier where available.

·        Action.

·        Source IP.

·        User agent.

·        Resource accessed.

·        Secret name or reference where available.

·        Authentication method.

·        MFA result.

·        Conditional-access result.

·        Token scope where available.

·        Token age where available.

·        Result status.

Telemetry Category 7 — DNS, Proxy, and Network Egress Telemetry

Network telemetry is required to detect runtime downloads, suspicious outbound transfer, webhook or raw-content use, cloud-storage egress, and communication with unfamiliar infrastructure.

Required telemetry includes:

·        DNS queries.

·        HTTP and HTTPS proxy logs.

·        TLS metadata.

·        Firewall egress logs.

·        NetFlow or equivalent flow logs.

·        EDR network events by process where available.

·        Cloud egress logs.

·        CI/CD runner egress logs.

·        Artifact upload and external destination logs.

·        Web gateway detections for suspicious upload, paste, webhook, or file-sharing activity.

Required coverage includes:

·        Developer endpoints.

·        CI/CD runners.

·        Build containers.

·        Release systems.

·        Artifact repositories.

·        Package-publishing systems.

·        Cloud build environments.

Minimum useful fields include:

·        Timestamp.

·        Source host.

·        Source user.

·        Source process where available.

·        Source IP.

·        Destination domain.

·        Destination IP.

·        URL or request path where available.

·        HTTP method where available.

·        User agent.

·        Bytes sent.

·        Bytes received.

·        TLS SNI.

·        TLS fingerprint where available.

·        Proxy action.

·        Firewall action.

·        Reputation verdict where available.

Telemetry Category 8 — Artifact, Container, and Dependency-Cache Telemetry

Artifact, container, and dependency-cache telemetry is required to determine whether poisoned dependencies or stolen credentials affected internal packages, build outputs, containers, release artifacts, or deployment paths.

Required telemetry includes:

·        Artifact repository access and write events.

·        Container image build and push events.

·        Software bill of materials records.

·        Package provenance records.

·        Dependency cache contents.

·        Build artifact creation and signing events.

·        Release artifact promotion events.

·        Internal npm mirror records.

·        Container registry authentication and push events.

·        Build-image change records.

·        Artifact download and deployment records.

Required coverage includes:

·        Internal npm mirrors.

·        Artifact repositories.

·        Container registries.

·        Build-image repositories.

·        Release artifact stores.

·        Software signing systems.

·        Deployment artifact stores.

Minimum useful fields include:

·        Timestamp.

·        Artifact name.

·        Package name.

·        Package version.

·        Image name.

·        Image digest.

·        Repository.

·        Build identifier.

·        Publisher.

·        Uploader.

·        Downloader.

·        Signing identity.

·        Provenance record.

·        Source commit.

·        Deployment target.

·        Registry source.

·        Result status.

Telemetry Correlation Requirements

Telemetry must support correlation across endpoint, CI/CD, GitHub, npm, cloud, identity, secrets, artifact, and network layers.

Required correlation pivots include:

·        User identity.

·        Host identity.

·        CI/CD runner identity.

·        Repository.

·        Package name and version.

·        Dependency lockfile.

·        Process lineage.

·        Command line.

·        Token or credential identifier.

·        Source IP.

·        User agent.

·        GitHub organization and repository.

·        npm account and package.

·        Cloud account, project, subscription, tenant, and identity.

·        Network destination.

·        Timestamp proximity.

Required correlation sequences include:

·        Package installation followed by unexpected lifecycle execution.

·        Lifecycle execution followed by Bun, Node, shell, or network utility execution.

·        Runtime execution followed by credential-file access or environment-variable enumeration.

·        Credential access followed by local staging.

·        Local staging followed by GitHub, webhook, cloud storage, or unfamiliar outbound transfer.

·        Developer or CI/CD compromise signals followed by GitHub repository or workflow modification.

·        Developer or CI/CD compromise signals followed by npm package publication.

·        Developer or CI/CD compromise signals followed by cloud control-plane activity.

Minimum Viable Telemetry Baseline

A minimum viable detection posture requires:

·        Endpoint process creation and command-line telemetry for developer systems and self-hosted CI/CD runners.

·        File access telemetry for sensitive credential paths where available.

·        CI/CD job, workflow, runner, package-install, artifact, and cache logs.

·        GitHub or source-code platform audit logs.

·        npm package-publishing and authentication telemetry.

·        Cloud control-plane audit logs for accounts connected to development and deployment workflows.

·        DNS or proxy logs for developer and CI/CD egress.

·        Identity, token, and secret-access telemetry for developer, maintainer, automation, and deployment accounts.

·        Central SIEM correlation across user, host, repository, package, token, cloud identity, and network context.

Without this baseline, defenders may still identify exposure through dependency and lockfile review, but they will have limited ability to determine whether execution, credential theft, or downstream compromise occurred.

Telemetry Gaps and Constraints

Common telemetry gaps include:

·        Managed CI/CD runners with limited process-level visibility.

·        Ephemeral build containers that disappear before forensic collection.

·        Developer endpoints without full command-line logging.

·        Package-install logs that are not retained.

·        GitHub or npm audit logs that are unavailable, incomplete, or not centrally collected.

·        Cloud credentials without strong mapping to source repository, runner, or developer identity.

·        Network logs that lack process attribution.

·        TLS encryption limiting payload visibility.

·        Secrets access visible only as environment injection rather than direct read events.

·        Dependency caches and internal mirrors retaining poisoned packages after registry removal.

These gaps do not eliminate detection value, but they reduce confidence and increase reliance on correlation, exposure review, credential rotation, and containment actions.

Telemetry Requirements Disposition

The telemetry requirement is achievable but visibility-dependent.

The highest-confidence detections require endpoint or CI/CD process telemetry linked to source-code platform, npm registry, cloud audit, identity, secrets, artifact, and network activity. Organizations lacking runner-level process visibility should prioritize compensating visibility through CI/CD logs, GitHub and npm audit logs, dependency review, secret rotation, artifact review, and outbound egress monitoring.

Figure 4

S24 — Detection Opportunities and Gaps

Detection Opportunities and Gaps Objective

Identify the strongest detection opportunities and the expected visibility gaps for the SAP-related npm package poisoning incident. This section separates reliable detection paths from areas where telemetry limitations, encrypted traffic, ephemeral infrastructure, or platform logging constraints may reduce confidence.

The goal is to define where defenders can detect the attack directly, where detection requires correlation, and where exposure review or containment actions are required because direct visibility may be incomplete.

Primary Detection Opportunity Model

The strongest detection opportunities occur when multiple behaviors align across package installation, runtime execution, credential access, token abuse, and outbound activity.

High-confidence detection is most likely when defenders can observe the following sequence:

·        SAP-related npm package installation or dependency restoration occurs in a developer, CI/CD, release, or build environment.

·        npm lifecycle execution launches an unexpected loader, runtime, shell, script, or network utility.

·        Bun, Node, or shell execution occurs from a dependency, cache, temporary, user-profile, or CI workspace path.

·        Credential files, environment variables, token stores, cloud configurations, package-registry credentials, or CI/CD secrets are accessed.

·        Data is staged locally, encoded, compressed, encrypted, or prepared for transfer.

·        GitHub, npm, cloud, webhook, raw-content, paste-like, or unfamiliar external destinations are contacted.

·        GitHub repositories, workflows, npm packages, cloud identities, or deployment resources are modified after suspicious execution.

Detection Opportunity 1 — npm Lifecycle Execution Abuse

This is one of the strongest detection opportunities because malicious npm package activity depends on install-time execution.

High-value opportunities include:

·        Detecting npm, pnpm, or yarn spawning unexpected child processes during package installation.

·        Detecting package-manager execution of Bun, Node, shell, PowerShell, curl, wget, archive utilities, or encoded commands.

·        Detecting loader-style script execution from dependency, cache, temporary, user-profile, or CI workspace paths.

·        Detecting lifecycle execution followed by credential access, local staging, GitHub API activity, npm publishing activity, cloud API activity, or suspicious egress.

·        Prioritizing CI/CD environments where dependency restoration should be deterministic and package-manager child-process behavior is narrow.

Primary Gap

Developer environments may allow broad npm lifecycle execution, which can increase noise unless detections use process ancestry, execution path, host role, repository context, and follow-on behavior.

Hardening Requirement

Lifecycle abuse detections should not alert on package installation alone. Detection logic must require abnormal child-process behavior, suspicious execution path, sensitive follow-on activity, or high-risk environment context.

Detection Opportunity 2 — Unexpected Bun and Runtime Execution

Unexpected Bun execution is a strong detection opportunity where Bun is not a standard runtime.

High-value opportunities include:

·        Detecting Bun launched by package managers, shell processes, Node processes, or CI runners.

·        Detecting Bun execution from dependency, cache, temporary, user-profile, or CI workspace paths.

·        Detecting first-seen Bun execution on developer endpoints, build hosts, release systems, or automation runners.

·        Detecting Bun or Node followed by file discovery, environment-variable enumeration, credential access, token validation, GitHub API activity, npm registry activity, cloud API activity, or outbound transfer.

·        Prioritizing environments where Bun is not approved or is allowed only in known build images and repositories.

Primary Gap

Organizations that legitimately use Bun require approved runtime inventories, repository-specific context, and build-image baselines to avoid false positives.

Hardening Requirement

Runtime detections should distinguish sanctioned Bun usage from suspicious install-time execution. Strong rules should combine parent process, runtime path, repository or runner context, first-seen status, and follow-on credential or network behavior.

Detection Opportunity 3 — Credential Discovery and Local Staging

Credential access and staging are high-impact detection opportunities because they mark the transition from package execution to enterprise exposure.

High-value opportunities include:

·        Detecting access to .npmrc, SSH keys, Git credential stores, cloud credential files, Kubernetes configuration files, Docker credentials, and CI/CD environment material.

·        Detecting environment-variable enumeration involving token, key, secret, credential, GitHub, npm, cloud, registry, or deployment naming patterns.

·        Detecting file discovery across home directories, repository roots, build workspaces, package caches, and release directories after suspicious runtime execution.

·        Detecting JSON, archive, encoded, encrypted, compressed, or blob-like files created after credential access.

·        Detecting short-lived staging files created before outbound transfer.

Primary Gap

Many endpoint and CI/CD environments do not log file-read activity consistently, and secrets may be exposed through environment injection rather than direct file access.

Hardening Requirement

Credential-access detections should prioritize process lineage and timing. A rule is stronger when credential access follows package-manager lifecycle execution, unexpected runtime execution, or execution from dependency, cache, temporary, user-profile, or CI workspace paths.

Detection Opportunity 4 — GitHub Repository and Workflow Abuse

GitHub repository and workflow activity provides a strong post-compromise detection surface because stolen tokens may be used for exfiltration, persistence, workflow manipulation, or propagation.

High-value opportunities include:

·        Detecting repository creation following suspicious package installation or credential access.

·        Detecting repository visibility changes, unusual repository metadata, or abnormal administrative actions.

·        Detecting creation or modification of .github/workflows/ outside approved release processes.

·        Detecting workflows that attempt broad secret access, environment dumping, package publishing, external callbacks, or unusual artifact handling.

·        Detecting GitHub API use from developer systems, CI/CD runners, geographies, user agents, or automation contexts outside normal patterns.

Primary Gap

GitHub audit depth varies by organization configuration, licensing, log retention, token type, and whether developer personal repositories are involved in company work.

Hardening Requirement

GitHub detections should avoid alerting on ordinary repository administration. Stronger logic should combine unusual actor, token type, repository action, source location, workflow modification, sensitive secret behavior, or proximity to suspicious endpoint or CI/CD activity.

Detection Opportunity 5 — npm Registry and Package-Publishing Abuse

npm registry activity is a high-impact detection opportunity because stolen npm credentials can enable downstream package poisoning and propagation.

High-value opportunities include:

·        Detecting unexpected npm publish, npm version, token validation, maintainer change, access change, or package ownership change.

·        Detecting package publication from unusual endpoints, CI/CD runners, user agents, IP ranges, geographies, or release windows.

·        Detecting registry changes after suspicious package installation, credential access, GitHub workflow changes, or local staging.

·        Detecting lifecycle-script, package metadata, maintainer, or release-automation changes without approved change context.

·        Detecting multiple package publications by the same identity within a compressed time window.

Primary Gap

npm telemetry may be limited unless organization-level logging, token management, package provenance, and publishing workflow records are centrally retained.

Hardening Requirement

npm registry detections should account for normal release automation. Strong detections should compare package-publishing activity against approved maintainers, release windows, publishing hosts, token types, package provenance, and recent suspicious developer or CI/CD activity.

Detection Opportunity 6 — Cloud Credential and Control-Plane Abuse

Cloud control-plane telemetry provides a high-impact detection surface for downstream credential misuse.

High-value opportunities include:

·        Detecting cloud API activity from new locations, user agents, systems, identities, access keys, service accounts, or automation contexts.

·        Detecting cloud access shortly after developer endpoint or CI/CD runner compromise signals.

·        Detecting metadata service access from developer workstations or CI/CD jobs without an approved metadata-service dependency.

·        Detecting secret-manager, key-vault, storage, compute, IAM, container-registry, or deployment activity outside normal build and release behavior.

·        Detecting creation or modification of access keys, service accounts, workload identities, permissions, policies, or deployment credentials.

Primary Gap

Cloud logs often show credential use but may not directly identify how the credential was stolen unless correlated with endpoint, CI/CD, identity, repository, and network telemetry.

Hardening Requirement

Cloud detections should not rely only on unusual location or user agent. Stronger detections should correlate cloud activity with identity role, source system, repository workflow, recent credential exposure, API sensitivity, privilege change, and post-exposure timing.

Detection Opportunity 7 — Suspicious Egress and Exfiltration

Network and egress monitoring can detect exfiltration, but it is strongest when correlated with local staging, credential access, and runtime execution.

High-value opportunities include:

·        Detecting outbound traffic to GitHub API paths, raw-content hosts, webhook services, paste-like platforms, cloud storage, file-sharing endpoints, or unfamiliar infrastructure after suspicious execution.

·        Detecting upload-like traffic from developer endpoints or CI/CD runners following package lifecycle execution.

·        Detecting encoded, compressed, encrypted, or blob-like transfer after local collection.

·        Detecting repeated outbound attempts from package-manager, Node, Bun, shell, or CI runner process trees.

·        Detecting egress from build systems to destinations not required for normal dependency restoration, testing, publishing, or deployment.

Primary Gap

TLS encryption, normal developer access to external services, and lack of process attribution can reduce standalone network detection confidence.

Hardening Requirement

Network detections should not depend solely on destination reputation. Stronger detections should include source role, process attribution where available, destination novelty, upload pattern, timing after local staging, and whether the destination is required for the build or release workflow.

Detection Opportunity 8 — Artifact, Container, and Dependency-Cache Review

Artifact and dependency-cache telemetry provides an important exposure and containment opportunity when direct runtime telemetry is incomplete.

High-value opportunities include:

·        Identifying affected package versions in dependency caches, lockfiles, internal npm mirrors, and build artifacts.

·        Detecting poisoned packages retained after public registry removal.

·        Reviewing build artifacts, containers, software bills of materials, package provenance, and release outputs created during the exposure window.

·        Detecting internal package, container image, or artifact updates following suspicious developer or CI/CD activity.

·        Identifying deployments that may have been built from exposed dependency sets.

Primary Gap

Artifact and cache review can confirm exposure and support containment, but it may not prove whether malicious code executed or whether credentials were stolen.

Hardening Requirement

Artifact and cache review should be treated as exposure validation, not proof of compromise by itself. Stronger assessment requires correlation with package-install logs, CI/CD execution, runtime behavior, credential access, publishing activity, or post-exposure control-plane changes.

Highest-Value Detection Opportunities

The strongest opportunities for S25 rule development are:

·        Package-manager lifecycle execution spawning unexpected runtimes, shells, download utilities, loaders, or encoded commands.

·        Bun or Node execution from dependency, cache, temporary, user-profile, or CI workspace paths.

·        Credential access or local staging following npm install activity.

·        GitHub workflow, repository, or token activity following suspicious endpoint or CI/CD behavior.

·        npm publishing or package-management changes following credential access.

·        Cloud credential use following suspicious developer or CI/CD compromise indicators.

·        Suspicious outbound transfer following local collection or staging.

Expected Detection Gaps

Gap 1 — Managed CI/CD Runner Visibility

Managed runners may not expose process creation, file access, or network telemetry at the level required for high-confidence execution reconstruction.

Impact:

·        Package installation may be visible, but child-process execution and credential access may be partially hidden.

·        Detection may rely on workflow logs, GitHub audit events, npm events, artifact review, and outbound destination logs.

Gap 2 — Ephemeral Build Environment Retention

Ephemeral runners and build containers may terminate before forensic artifacts can be collected.

Impact:

·        Local staging files, temporary payloads, process history, and filesystem evidence may be lost.

·        Detection depends on retained job logs, EDR coverage on runners, artifact records, dependency caches, and centralized telemetry.

Gap 3 — Developer Endpoint Variability

Developer systems often have diverse tooling, broad scripting permissions, external network access, and local credential material.

Impact:

·        Generic npm, Node, shell, GitHub, and cloud activity may be noisy.

·        High-confidence detection requires path context, process ancestry, repository context, host role, runtime baseline, and follow-on behavior.

Gap 4 — Limited npm and Package Registry Audit Visibility

npm authentication, token, ownership, maintainer, and package-publication telemetry may be incomplete or inconsistently retained.

Impact:

·        Propagation activity may be difficult to attribute without registry, identity, package-maintainer, and release-workflow context.

·        Exposure review may require package history, package metadata, provenance records, and external registry validation.

Gap 5 — GitHub and Source-Code Platform Logging Constraints

Source-code platform logs may vary by organization configuration, licensing, log retention, token type, and repository ownership model.

Impact:

·        Token misuse may be visible only as API activity or repository changes without full credential lineage.

·        Developer personal repositories used for company work may fall outside enterprise audit coverage.

Gap 6 — Cloud Credential Attribution Limits

Cloud control-plane logs can show credential use, but they may not identify whether the credential was stolen through package execution.

Impact:

·        Cloud misuse may require correlation with endpoint, CI/CD, repository, identity, and network telemetry.

·        Organizations may need to rotate credentials even when direct theft cannot be proven.

Gap 7 — Encrypted and Legitimate-Looking Egress

Exfiltration may use encrypted traffic or common developer destinations such as GitHub, cloud storage, webhook services, or raw-content platforms.

Impact:

·        Network telemetry alone may not distinguish legitimate developer activity from exfiltration.

·        Detection requires correlation with local collection, process lineage, destination novelty, upload volume, and timing.

Gap 8 — Static IOC Fragility

Package names, file names, hashes, infrastructure, repository names, and exfiltration endpoints may change quickly.

Impact:

·        Static indicators are useful for exposure review and enrichment but are insufficient as the primary detection model.

·        Durable detection must focus on install-time execution, credential access, token abuse, and propagation behavior.

Compensating Detection Approaches

Where direct telemetry is incomplete, defenders should rely on compensating approaches:

·        Review dependency lockfiles, build logs, package caches, internal npm mirrors, and artifact repositories for affected package versions.

·        Identify developer endpoints and CI/CD runners that installed exposed packages during the risk window.

·        Rotate npm, GitHub, cloud, SSH, deployment, and CI/CD secrets associated with exposed systems.

·        Review GitHub repository creation, workflow changes, secret access, deploy keys, webhooks, and package-publishing activity after exposure.

·        Review npm package publication, ownership, maintainer, token, and metadata changes after exposure.

·        Review cloud API activity from developer and CI/CD identities after exposure.

·        Prioritize investigation where package exposure overlaps with privileged developer, maintainer, package-publishing, or deployment identities.

·        Treat affected dependency exposure on systems with privileged secrets as higher risk even when execution telemetry is incomplete.

Detection Opportunities and Gaps Disposition

Detection is viable, but confidence depends on the ability to correlate endpoint, CI/CD, GitHub, npm, cloud, identity, artifact, and network telemetry.

The strongest detection opportunities are behavior-chain detections that connect package installation, lifecycle execution, unexpected runtime activity, credential access, token abuse, suspicious egress, and downstream propagation. The most significant gaps are managed runner visibility, ephemeral build retention, developer endpoint variability, limited registry audit depth, encrypted egress, and weak credential attribution. Where those gaps exist, exposure review, secret rotation, artifact review, and post-exposure control-plane auditing are required to reduce residual risk.

S25 — Ultra-Tuned Detection Engineering Rules

Suricata

Rule Count

·        0 rules selected.

Detection Viability Assessment

Suricata is not selected for a standalone S25 rule for this incident.

The SAP-related npm package poisoning activity is primarily observable through package-manager execution, process ancestry, runtime behavior, credential access, GitHub and npm token abuse, CI/CD workflow activity, cloud-control-plane activity, and post-exposure identity use. Suricata can support network visibility, but it cannot independently observe the local execution chain required to distinguish malicious package activity from normal developer and CI/CD workflows.

Tiering Data

·        Tier 1: Do not use Suricata as a primary detection source; prioritize endpoint, GitHub, npm, dependency review, and secret rotation.

·        Tier 2: Use Suricata only as egress enrichment correlated with endpoint, CI/CD, GitHub, npm, and identity telemetry.

·        Tier 3: Feed Suricata DNS, HTTP, TLS, and flow metadata into SIEM correlation for suspicious egress review.

·        Tier 4: Use Suricata as a supporting telemetry input only; prioritize EDR, SIEM, source-code, npm registry, cloud, and identity telemetry.

Final Suricata Disposition

Suricata is excluded from the final S25 production rule set and retained only as a supporting telemetry source for enrichment, retrospective egress review, and SIEM correlation.

Suricata Rule Count

·        0 production rules.

·        0 conditional rules.

·        0 supplemental rules.

SentinelOne

Detection Viability Assessment

SentinelOne is a strong S25 detection platform for this incident because it can observe package-manager execution, parent-child process lineage, command-line behavior, suspicious runtime execution, file activity, local staging, and network activity from developer endpoints and self-hosted CI/CD runners.

SentinelOne should be used to detect the local execution and credential-access portions of the attack chain before stolen credentials are reused across GitHub, npm, cloud, or CI/CD control planes.

SentinelOne Rule 1

npm Lifecycle Execution Spawning Suspicious Runtime or Shell Activity

Rule Format

SentinelOne Deep Visibility Query with STAR deployment candidate.

Detection Objective

Detect suspicious package-manager lifecycle execution where npm, pnpm, or yarn launches an unexpected runtime, shell, downloader, archive utility, or encoded command from developer or CI/CD execution paths.

Detection Logic

This rule detects the transition from trusted dependency installation to attacker-controlled execution. It focuses on package-manager parent processes spawning child processes commonly used for loader execution, runtime bootstrapping, command execution, or network retrieval.

Required Telemetry

·        Process creation.

·        Parent-child process lineage.

·        Full command-line arguments.

·        Process path.

·        Working directory.

·        User identity.

·        Host identity.

·        Endpoint group or site context.

·        CI/CD runner tagging where available.

Engineering Implementation Instructions

Engineers should scope this rule to developer endpoints, release engineering systems, package-publishing systems, and self-hosted CI/CD runners. Approved build images, known repository-specific install behavior, and expected package-manager child processes should be baselined before production alerting.

The rule should not alert on package-manager activity alone. It should require suspicious child-process execution, abnormal execution path, downloader invocation, encoded command behavior, or CI/CD runner context.

Tiering Data

·        Tier 1: Deploy in alert-only mode on developer and build systems with known npm workflow exposure.

·        Tier 2: Add host role tagging for developer workstations, CI/CD runners, release systems, and package-publishing systems.

·        Tier 3: Correlate with GitHub audit logs, npm registry activity, proxy logs, DNS logs, and identity telemetry in the SIEM.

·        Tier 4: Add repository, runner, build-image, approved runtime, and release workflow context to reduce noise and support higher-confidence escalation.

DRI Assessment

Detection Robustness Index

·        8.7

DRI Justification

The rule is behaviorally anchored on package-manager process ancestry and suspicious child-process execution rather than static package names, filenames, hashes, or infrastructure. It remains useful across package-name changes, payload filename changes, and exfiltration infrastructure changes because it detects the install-time execution transition required for malicious dependency behavior.

TCR Assessment

Operational TCR

·        Moderate to High

Operational TCR Justification

Operational confidence depends on SentinelOne coverage across developer endpoints and self-hosted CI/CD runners with full command-line and parent-child process telemetry enabled. Visibility may be reduced for managed runners, short-lived build containers, or hosts without endpoint instrumentation.

Full-Telemetry TCR

·        High

Full-Telemetry TCR Justification

With endpoint coverage on developer systems and CI/CD runners, SentinelOne can reliably capture parent process, child process, command line, working directory, and execution path context needed for this detection.

Limitations

·        Legitimate lifecycle scripts may execute shells or runtimes during package installation.

·        Environments with custom build scripts require host, repository, runner, and build-image context.

·        Managed CI/CD runners may not provide SentinelOne process telemetry.

Detection Code

// SentinelOne Deep Visibility Query
// Detect package-manager lifecycle execution spawning suspicious runtime, shell, downloader, archive utility, or encoded command behavior.

(
  SrcProcName In Contains AnyCase ("npm", "npm.cmd", "pnpm", "pnpm.cmd", "yarn", "yarn.cmd")
  OR SrcProcCmdLine In Contains AnyCase ("npm install", "npm ci", "pnpm install", "yarn install")
)
AND
(
  TgtProcName In Contains AnyCase (
    "bun", "bun.exe",
    "node", "node.exe",
    "sh", "bash", "zsh",
    "cmd.exe", "powershell.exe", "pwsh.exe",
    "curl", "curl.exe",
    "wget", "wget.exe",
    "tar", "tar.exe",
    "unzip", "unzip.exe",
    "python", "python.exe", "python3"
  )
)
AND
(
  TgtProcCmdLine In Contains AnyCase (
    "preinstall",
    "postinstall",
    "setup.mjs",
    "node_modules",
    ".npm",
    ".pnpm",
    "curl ",
    "wget ",
    "-enc",
    "-encodedcommand",
    "base64",
    "chmod +x"
  )
  OR
  TgtProcImagePath In Contains AnyCase (
    "node_modules",
    ".npm",
    ".pnpm",
    "tmp",
    "temp",
    "workspace",
    "actions-runner",
    "_work"
  )
)

SentinelOne Rule 2

Bun or Node Execution from Dependency or CI Workspace Path with Credential Access Indicators

Rule Format

SentinelOne Deep Visibility Query with STAR deployment candidate.

Detection Objective

Detect suspicious Bun or Node execution from dependency, cache, temporary, user-profile, or CI workspace paths when paired with credential discovery, secret access, or local staging behavior.

Detection Logic

This rule detects runtime execution consistent with malicious dependency payload behavior. It focuses on Bun or Node running from abnormal locations and interacting with credential material, secret-related paths, or staging artifacts.

Required Telemetry

·        Process creation.

·        Parent-child process lineage.

·        Full command-line arguments.

·        File access telemetry.

·        File creation telemetry.

·        Process path.

·        Working directory.

·        Endpoint group or runner context.

·        Network telemetry by process where available.

Engineering Implementation Instructions

Engineers should baseline approved Bun usage before production deployment. If Bun is not approved in the environment, first-seen Bun execution from dependency, temporary, user-profile, or CI workspace paths should be treated as high priority.

If Bun is approved, the rule should require abnormal path, package-manager ancestry, credential-path access, local staging behavior, or follow-on outbound activity.

Tiering Data

·        Tier 1: Alert on Bun execution from dependency, temporary, or CI workspace paths where Bun is not approved.

·        Tier 2: Add credential-path and staging-file conditions to reduce false positives.

·        Tier 3: Correlate with package-install logs, GitHub audit activity, npm registry events, proxy logs, and identity telemetry.

·        Tier 4: Add repository-specific runtime baselines, approved build-image context, and known developer tooling exceptions.

DRI Assessment

Detection Robustness Index

·        8.5

DRI Justification

The rule targets abnormal runtime execution and credential-access behavior rather than a single malicious filename or static package indicator. It remains useful across payload variants that change package names, loader names, or exfiltration infrastructure, provided the attack still requires runtime execution and local secret discovery.

TCR Assessment

Operational TCR

·        Moderate

Operational TCR Justification

Operational confidence depends on SentinelOne file-access visibility and whether sensitive path access is captured consistently. Process telemetry alone provides useful signal, but file-access and staging telemetry materially improve confidence.

Full-Telemetry TCR

·        High

Full-Telemetry TCR Justification

With process, command-line, file-access, path, and network telemetry enabled, SentinelOne can observe runtime behavior, sensitive file interaction, staging activity, and outbound behavior needed to support this rule.

Limitations

·        Legitimate Node or Bun tooling may access project files during builds.

·        File-read visibility may vary by operating system, policy configuration, and endpoint performance settings.

·        Credential access through environment variables may not always produce direct file-access telemetry.

Detection Code

// SentinelOne Deep Visibility Query
// Detect Bun or Node from abnormal dependency or CI paths with credential-access or staging indicators.

(
  TgtProcName In Contains AnyCase ("bun", "bun.exe", "node", "node.exe")
)
AND
(
  TgtProcImagePath In Contains AnyCase (
    "node_modules",
    ".npm",
    ".pnpm",
    "tmp",
    "temp",
    "workspace",
    "actions-runner",
    "_work",
    ".cache"
  )
  OR
  TgtProcCmdLine In Contains AnyCase (
    "setup.mjs",
    "preinstall",
    "postinstall",
    "node_modules",
    ".npm",
    ".pnpm",
    "_work",
    "workspace"
  )
)
AND
(
  TgtProcCmdLine In Contains AnyCase (
    ".npmrc",
    "id_rsa",
    "id_ed25519",
    ".ssh",
    "credentials",
    "kubeconfig",
    ".kube",
    "docker/config.json",
    "GITHUB_TOKEN",
    "npm_TOKEN",
    "AWS_ACCESS_KEY",
    "AZURE_CLIENT_SECRET",
    "GOOGLE_APPLICATION_CREDENTIALS",
    "SECRET",
    "TOKEN",
    "PASSWORD",
    "KEY"
  )
  OR
  FileFullName In Contains AnyCase (
    ".npmrc",
    ".ssh",
    "id_rsa",
    "id_ed25519",
    ".aws/credentials",
    ".azure",
    ".config/gcloud",
    ".kube/config",
    "docker/config.json",
    "environment.json",
    "cloud.json",
    "data.json",
    "secrets",
    "token",
    "credential"
  )
)

SentinelOne Rule 3

Linux CI Runner Memory and Environment Harvesting from Suspicious Runtime Process

Rule Format

SentinelOne Deep Visibility Query with STAR deployment candidate.

Detection Objective

Detect suspicious Linux CI runner behavior where Bun, Node, Python, shell, or package-manager-descended processes attempt to access process environment, process maps, process memory, or sensitive runtime material.

Detection Logic

This rule detects post-execution credential-harvesting behavior on Linux developer or CI/CD systems. It focuses on suspicious access to explicit /proc/self environment and memory-related paths by processes associated with package installation, abnormal runtime execution, or CI workspace execution.

Required Telemetry

·        Process creation.

·        Parent-child process lineage.

·        Full command-line arguments.

·        File access telemetry.

·        Linux path visibility.

·        CI runner host tagging.

·        Working directory.

·        Process path.

·        User identity.

·        Host identity.

Engineering Implementation Instructions

Engineers should scope this rule to Linux developer systems, release hosts, and self-hosted CI/CD runners. The highest-confidence deployment is on CI/CD runners where access to /proc/self/mem, /proc/self/maps, /proc/self/environ, or broad environment scraping is not expected during package installation.

The rule should not alert on all /proc access. It should require suspicious process ancestry, suspicious runtime, package-manager context, abnormal working directory, or sensitive environment access.

Tiering Data

·        Tier 1: Deploy on self-hosted Linux CI/CD runners and release systems first.

·        Tier 2: Add process ancestry and working-directory filters to reduce developer endpoint noise.

·        Tier 3: Correlate with CI job identity, repository, workflow, package-install command, identity activity, and outbound egress.

·        Tier 4: Add runner baseline, approved diagnostic tooling, repository context, build-image context, and identity correlation.

DRI Assessment

Detection Robustness Index

·        8.1

DRI Justification

The rule is anchored on suspicious credential-harvesting behavior from package-manager or runtime-descended processes. It is resilient against package-name, filename, and network-infrastructure changes, but it is narrower than the first two SentinelOne rules because it depends on Linux runner visibility and specific memory or environment access behavior.

TCR Assessment

Operational TCR

·        Moderate

Operational TCR Justification

Operational confidence depends on Linux CI runner coverage, file-access telemetry, and whether SentinelOne records relevant /proc/self interactions. Visibility may be weaker on ephemeral runners, unmanaged build containers, or hosts without file-access telemetry.

Full-Telemetry TCR

·        High

Full-Telemetry TCR Justification

With full Linux file-access, process lineage, command-line, runner identity, and working-directory telemetry, this rule can provide strong evidence of suspicious local credential-harvesting behavior.

Limitations

·        Diagnostic, profiling, monitoring, or security tools may legitimately access /proc/self paths.

·        The rule is strongest on CI/CD runners and release systems, not general-purpose Linux developer workstations.

·        This rule detects a specific harvesting pattern and should not be treated as complete coverage for all secret-theft methods.

Detection Code

// SentinelOne Deep Visibility Query
// Detect suspicious Linux runner memory or environment access from runtime or package-manager-descended processes.

(
  TgtProcName In Contains AnyCase (
    "bun",
    "node",
    "npm",
    "pnpm",
    "yarn",
    "sh",
    "bash",
    "python",
    "python3"
  )
  OR
  SrcProcName In Contains AnyCase (
    "npm",
    "pnpm",
    "yarn",
    "node",
    "bun",
    "sh",
    "bash"
  )
)
AND
(
  FileFullName In Contains AnyCase (
    "/proc/self/environ",
    "/proc/self/maps",
    "/proc/self/mem"
  )
  OR
  TgtProcCmdLine In Contains AnyCase (
    "/proc/self/environ",
    "/proc/self/maps",
    "/proc/self/mem",
    "printenv",
    "env",
    "cat /proc/self/environ",
    "GITHUB_TOKEN",
    "npm_TOKEN",
    "AWS_ACCESS_KEY",
    "SECRET",
    "TOKEN"
  )
)
AND
(
  TgtProcCmdLine In Contains AnyCase (
    "node_modules",
    ".npm",
    ".pnpm",
    "preinstall",
    "postinstall",
    "setup.mjs",
    "_work",
    "actions-runner",
    "workspace"
  )
  OR
  TgtProcImagePath In Contains AnyCase (
    "node_modules",
    ".npm",
    ".pnpm",
    "tmp",
    "temp",
    "_work",
    "actions-runner",
    "workspace"
  )
)

Splunk

Detection Viability Assessment

Splunk is a strong S25 detection platform for this incident because it can correlate endpoint, CI/CD, GitHub, npm registry, identity, cloud, proxy, DNS, and network telemetry into sequence-based detections.

Splunk should be used to detect behavior chains that connect package installation, suspicious lifecycle execution, credential access, GitHub or npm token abuse, and downstream propagation. The Splunk rules below are written as correlation-search templates and require field mapping to the customer’s Splunk CIM, local sourcetypes, and normalized event schema before production deployment.

Splunk Rule 1

npm Lifecycle Execution Followed by Suspicious Runtime and Credential Access

Rule Format

Splunk SPL correlation search template.

Detection Objective

Detect package-manager lifecycle execution where npm, pnpm, or yarn launches suspicious runtime, shell, downloader, archive, or encoded-command behavior and is followed by credential access or local staging activity on the same host and user within a short time window.

Detection Logic

This rule detects the transition from trusted dependency installation to suspicious local execution. It requires package-manager lifecycle behavior and suspicious follow-on behavior on the same host and user. Generic npm installation does not alert by itself.

Required Telemetry

·        Endpoint process creation telemetry.

·        Parent-child process lineage.

·        Full command-line arguments.

·        File access or file creation telemetry.

·        Host identity.

·        User identity.

·        Asset role or endpoint group.

·        CI/CD runner identity where available.

·        Process working directory where available.

Engineering Implementation Instructions

Engineers must map the placeholder fields in this SPL to local Splunk field names or Splunk CIM fields before deployment. Required mappings include process name, parent process name, process command line, process path, file path, user, host, asset role, and timestamp.

The rule should be scoped to developer endpoints, self-hosted CI/CD runners, release systems, and package-publishing systems. Production deployment should require lifecycle behavior plus either credential access or suspicious runtime execution from abnormal package, cache, temporary, user-profile, or CI workspace paths.

Tiering Data

·        Tier 1: Deploy as a scheduled hunt against developer endpoints and self-hosted CI/CD runners.

·        Tier 2: Add asset role tagging for developer workstations, CI/CD runners, release systems, and package-publishing systems.

·        Tier 3: Correlate with GitHub audit logs, npm registry activity, proxy logs, DNS logs, and identity telemetry.

·        Tier 4: Add repository, runner, build-image, approved runtime, release workflow, and known build-tooling context to support higher-confidence escalation.

DRI Assessment

Detection Robustness Index

·        8.8

DRI Justification

The rule is behaviorally anchored on package-manager lifecycle execution, suspicious child-process behavior from abnormal execution paths, and credential-access indicators. It does not depend on package names, hashes, static infrastructure, or a single payload filename. It remains resilient against common attacker changes because malicious npm package execution still requires install-time execution or follow-on local activity.

TCR Assessment

Operational TCR

·        Moderate to High

Operational TCR Justification

Operational confidence depends on endpoint process telemetry, command-line logging, file-access visibility, asset role tagging, and normalized host and user fields. Confidence is reduced where self-hosted CI/CD runners are not instrumented or file-access telemetry is incomplete.

Full-Telemetry TCR

·        High

Full-Telemetry TCR Justification

With process lineage, command-line, file-access, host-role, and CI/CD runner context available, Splunk can reliably correlate local execution and credential-access behavior required for this detection.

Limitations

·        Legitimate lifecycle scripts may spawn shells, runtimes, or archive utilities during package installation.

·        Developer systems with custom build tooling require baseline tuning.

·        Managed CI/CD runners may not provide endpoint-level process telemetry.

·        File-read visibility may vary by endpoint source and operating system.

Detection Code

`comment("Splunk correlation-search template. Map fields to CIM or local sourcetypes before production deployment.")`

index=endpoint earliest=-65m@m latest=now
(
  process_name IN ("npm","npm.cmd","pnpm","pnpm.cmd","yarn","yarn.cmd")
  OR parent_process_name IN ("npm","npm.cmd","pnpm","pnpm.cmd","yarn","yarn.cmd")
  OR process="*npm install*"
  OR process="*npm ci*"
  OR process="*pnpm install*"
  OR process="*yarn install*"
  OR process="*preinstall*"
  OR process="*postinstall*"
  OR process="*setup.mjs*"
)
| eval lifecycle_signal=if(
    process_name IN ("npm","npm.cmd","pnpm","pnpm.cmd","yarn","yarn.cmd")
    OR parent_process_name IN ("npm","npm.cmd","pnpm","pnpm.cmd","yarn","yarn.cmd")
    OR like(process,"%npm install%")
    OR like(process,"%npm ci%")
    OR like(process,"%pnpm install%")
    OR like(process,"%yarn install%")
    OR like(process,"%preinstall%")
    OR like(process,"%postinstall%")
    OR like(process,"%setup.mjs%"),
    1,0
  )
| eval suspicious_child_signal=if(
    parent_process_name IN ("npm","npm.cmd","pnpm","pnpm.cmd","yarn","yarn.cmd")
    AND (
      process_name IN ("bun","bun.exe","node","node.exe","sh","bash","zsh","cmd.exe","powershell.exe","pwsh.exe","curl","curl.exe","wget","wget.exe","tar","tar.exe","unzip","unzip.exe","python","python.exe","python3")
      OR like(process,"%setup.mjs%")
      OR like(process,"%-enc%")
      OR like(process,"%-encodedcommand%")
      OR like(process,"%base64%")
      OR like(process,"%chmod +x%")
      OR like(process,"%curl %")
      OR like(process,"%wget %")
    ),
    1,0
  )
| eval suspicious_path_signal=if(
    like(process_path,"%node_modules%")
    OR like(process_path,"%.npm%")
    OR like(process_path,"%.pnpm%")
    OR like(process_path,"%/tmp/%")
    OR like(process_path,"%\\Temp\\%")
    OR like(process_path,"%workspace%")
    OR like(process_path,"%actions-runner%")
    OR like(process_path,"%_work%"),
    1,0
  )
| eval credential_signal=if(
    like(file_path,"%.npmrc%")
    OR like(file_path,"%.ssh%")
    OR like(file_path,"%id_rsa%")
    OR like(file_path,"%id_ed25519%")
    OR like(file_path,"%.aws/credentials%")
    OR like(file_path,"%.azure%")
    OR like(file_path,"%.config/gcloud%")
    OR like(file_path,"%.kube/config%")
    OR like(file_path,"%docker/config.json%")
    OR like(file_path,"%secrets%")
    OR like(file_path,"%token%")
    OR like(file_path,"%credential%")
    OR like(process,"%GITHUB_TOKEN%")
    OR like(process,"%npm_TOKEN%")
    OR like(process,"%AWS_ACCESS_KEY%")
    OR like(process,"%AZURE_CLIENT_SECRET%")
    OR like(process,"%GOOGLE_APPLICATION_CREDENTIALS%")
    OR like(process,"%SECRET%")
    OR like(process,"%TOKEN%"),
    1,0
  )
| eval follow_on_signal=if(
    credential_signal=1 OR (suspicious_child_signal=1 AND suspicious_path_signal=1),
    1,0
  )
| bin time span=15m
| stats
    earliest(time) as first_seen
    latest(_time) as last_seen
    values(process_name) as process_names
    values(parent_process_name) as parent_processes
    values(process) as command_lines
    values(process_path) as process_paths
    values(file_path) as file_paths
    values(asset_role) as asset_roles
    max(lifecycle_signal) as has_lifecycle
    max(suspicious_child_signal) as has_suspicious_child
    max(suspicious_path_signal) as has_suspicious_path
    max(credential_signal) as has_credential_signal
    max(follow_on_signal) as has_follow_on
    by host user time
| where haslifecycle=1 AND has_follow_on=1
| eval first_seen=strftime(first_seen,"%Y-%m-%d %H:%M:%S")
| eval last_seen=strftime(last_seen,"%Y-%m-%d %H:%M:%S")
| eval severity="high"
| eval detection_name="npm Lifecycle Execution Followed by Suspicious Runtime and Credential Access"
| table first_seen last_seen severity detection_name host user asset_roles process_names parent_processes command_lines process_paths file_paths has_suspicious_child has_suspicious_path has_credential_signal

Splunk Rule 2

GitHub Workflow or Repository Abuse Following Local Compromise Signals

Rule Format

Splunk SPL correlation search template.

Detection Objective

Detect sensitive GitHub repository, workflow, secret, webhook, deploy-key, or token-related activity following suspicious developer endpoint or CI/CD runner behavior.

Detection Logic

This rule correlates local compromise signals with sensitive GitHub activity by actor, source IP, or time proximity. It is designed to detect stolen GitHub token or automation credential use after suspicious npm lifecycle execution, Bun or Node execution, credential access, or local staging.

Required Telemetry

·        Endpoint process telemetry.

·        CI/CD job telemetry where available.

·        GitHub audit logs.

·        GitHub API activity logs where available.

·        Identity telemetry.

·        Source IP and user-agent fields.

·        Repository and organization context.

·        Workflow path and event type.

Engineering Implementation Instructions

Engineers must normalize GitHub audit events into consistent actor, repository, organization, action, source IP, user agent, workflow path, and authentication context fields. The rule should focus on sensitive GitHub actions occurring after suspicious endpoint or CI/CD behavior.

The rule should not alert on ordinary repository administration alone. Production deployment should require a local compromise signal and a sensitive GitHub action connected by actor, source IP, host-to-user mapping, or a defined short time window.

Tiering Data

·        Tier 1: Hunt for workflow and repository changes after known package exposure.

·        Tier 2: Add GitHub organization, repository, actor, source IP, and user-agent baselines.

·        Tier 3: Correlate GitHub events with endpoint, CI/CD, npm, identity, and proxy telemetry.

·        Tier 4: Add repository criticality, maintainer role, token type, workflow sensitivity, and release-process context.

DRI Assessment

Detection Robustness Index

·        8.6

DRI Justification

The rule is anchored on sensitive post-compromise GitHub behaviors following local compromise signals. It does not depend on static package names or payload indicators. It remains resilient because repository creation, workflow modification, deploy-key changes, webhook changes, token activity, and secrets-related actions are durable downstream abuse surfaces.

TCR Assessment

Operational TCR

·        Moderate

Operational TCR Justification

Operational confidence depends on GitHub audit log availability, retention, actor attribution, source IP visibility, user-agent visibility, and the ability to correlate GitHub events with endpoint or CI/CD compromise indicators.

Full-Telemetry TCR

·        High

Full-Telemetry TCR Justification

With GitHub enterprise audit logs, endpoint telemetry, CI/CD telemetry, identity logs, and source IP correlation, Splunk can reconstruct the sequence from local suspicious execution to repository, workflow, or token abuse.

Limitations

·        GitHub audit depth varies by organization configuration and licensing.

·        Personal repositories used for company work may fall outside enterprise logging.

·        Repository administration may be legitimate unless correlated with suspicious timing, actor, source, or workflow behavior.

·        Token lineage may not always identify the original theft point.

Detection Code

`comment("Splunk correlation-search template. Map endpoint and GitHub fields to CIM or local sourcetypes before production deployment.")`

index=endpoint earliest=-65m@m latest=now
(
  parent_process_name IN ("npm","npm.cmd","pnpm","pnpm.cmd","yarn","yarn.cmd")
  OR process="*npm install*"
  OR process="*npm ci*"
  OR process="*pnpm install*"
  OR process="*yarn install*"
  OR process="*setup.mjs*"
  OR process="*preinstall*"
  OR process="*postinstall*"
  OR process_name IN ("bun","bun.exe","node","node.exe","sh","bash","zsh","powershell.exe","pwsh.exe")
)
(
  process="*node_modules*"
  OR process="*.npm*"
  OR process="*.pnpm*"
  OR process="*_work*"
  OR process="*actions-runner*"
  OR process="*workspace*"
  OR process="*GITHUB_TOKEN*"
  OR process="*npm_TOKEN*"
  OR process="*SECRET*"
  OR process="*TOKEN*"
  OR file_path="*.npmrc*"
  OR file_path="*.ssh*"
  OR file_path="*.aws/credentials*"
  OR file_path="*.kube/config*"
  OR file_path="*secrets*"
  OR file_path="*token*"
  OR file_path="*credential*"
)
| eval local_signal=1
| eval correlation_user=coalesce(user, actor)
| eval correlation_ip=coalesce(src_ip, src, source_ip, client_ip)
| eval event_source="endpoint"
| fields time eventsource host correlation_user correlation_ip local_signal process process_name parent_process_name process_path file_path
| append [
    search index=github earliest=-65m@m latest=now
    (
      action IN (
        "repo.create",
        "repo.visibility_change",
        "workflow.create",
        "workflow.update",
        "org.update_actions_secret",
        "repo.update_actions_secret",
        "repo.create_deploy_key",
        "repo.add_deploy_key",
        "hook.create",
        "hook.update",
        "oauth_authorization.create",
        "personal_access_token.used"
      )
      OR event_type IN (
        "workflow",
        "actions_secret",
        "deploy_key",
        "webhook",
        "oauth",
        "personal_access_token"
      )
    )
    | eval github_signal=1
    | eval correlation_user=coalesce(actor,user)
    | eval correlation_ip=coalesce(src_ip,source_ip,client_ip,src)
    | eval event_source="github"
    | fields time eventsource correlation_user correlation_ip github_signal action event_type org repo repository user_agent workflow_path actor authentication_method
  ]
| bin time span=30m
| stats
    earliest(time) as first_seen
    latest(_time) as last_seen
    values(event_source) as event_sources
    values(host) as hosts
    values(process) as command_lines
    values(process_name) as process_names
    values(parent_process_name) as parent_processes
    values(file_path) as file_paths
    values(action) as github_actions
    values(event_type) as github_event_types
    values(org) as github_orgs
    values(repo) as github_repos
    values(repository) as github_repositories
    values(workflow_path) as workflow_paths
    values(user_agent) as user_agents
    values(authentication_method) as authentication_methods
    values(correlation_ip) as source_ips
    max(local_signal) as has_local_signal
    max(github_signal) as has_github_signal
    by correlation_user correlation_ip time
| where haslocal_signal=1 AND has_github_signal=1
| eval first_seen=strftime(first_seen,"%Y-%m-%d %H:%M:%S")
| eval last_seen=strftime(last_seen,"%Y-%m-%d %H:%M:%S")
| eval severity="high"
| eval detection_name="GitHub Workflow or Repository Abuse Following Local Compromise Signals"
| table first_seen last_seen severity detection_name correlation_user source_ips hosts github_orgs github_repos github_repositories github_actions github_event_types workflow_paths user_agents authentication_methods process_names parent_processes command_lines file_paths

Splunk Rule 3

npm Registry Publishing or Token Abuse Following Credential Exposure Signals

Rule Format

Splunk SPL correlation search template.

Detection Objective

Detect npm package publication, token validation, maintainer change, access change, ownership change, or package metadata change following suspicious developer endpoint, CI/CD runner, or credential-access activity.

Detection Logic

This rule correlates local compromise or credential-access indicators with sensitive npm registry actions that may represent propagation, unauthorized package publication, or package-maintainer account abuse.

Required Telemetry

·        npm registry authentication logs.

·        npm package publication logs.

·        npm token activity.

·        npm maintainer, owner, access, and metadata change events.

·        Endpoint process telemetry.

·        CI/CD job telemetry where available.

·        Identity telemetry.

·        Source IP and user-agent fields.

·        Package ownership and maintainer context.

Engineering Implementation Instructions

Engineers must normalize npm registry and package-publishing events into package, version, account, token, action, source IP, and user-agent fields. The rule should be scoped to packages, maintainers, developer systems, CI/CD runners, and release workflows with package-publishing privileges.

The rule should not alert on ordinary release activity alone. Production deployment should require sensitive npm registry activity connected to local credential or execution signals through account, source IP, user mapping, host context, or short-window timing.

Tiering Data

·        Tier 1: Hunt for npm publish and maintainer changes after known package exposure.

·        Tier 2: Add approved maintainer, publishing host, token type, and release-window baselines.

·        Tier 3: Correlate npm activity with endpoint, CI/CD, GitHub, identity, and proxy telemetry.

·        Tier 4: Add package criticality, token type, provenance context, release automation, and artifact-signing context.

DRI Assessment

Detection Robustness Index

·        8.4

DRI Justification

The rule is anchored on sensitive package-registry behavior following credential exposure signals. It is resilient to package filename, payload hash, and exfiltration infrastructure changes. It is slightly lower than the first two Splunk rules because npm telemetry depth and token attribution can vary across environments.

TCR Assessment

Operational TCR

·        Moderate

Operational TCR Justification

Operational confidence depends on whether npm token activity, publishing logs, maintainer changes, source IPs, user agents, and package metadata changes are centrally retained and correlated with endpoint or CI/CD compromise signals.

Full-Telemetry TCR

·        High

Full-Telemetry TCR Justification

With full npm registry telemetry, endpoint telemetry, CI/CD logs, identity telemetry, and package-maintainer context, Splunk can identify suspicious package-publishing or token-use behavior following credential exposure.

Limitations

·        npm audit telemetry may be incomplete depending on organization configuration and retention.

·        Legitimate release automation may publish packages from CI/CD systems.

·        Package publishing requires release-window, maintainer, token, and source-context baselines.

·        This rule detects propagation risk but does not by itself prove the original credential-theft method.

Detection Code

`comment("Splunk correlation-search template. Map endpoint and npm registry fields to CIM or local sourcetypes before production deployment.")`

index=endpoint earliest=-90m@m latest=now
(
  parent_process_name IN ("npm","npm.cmd","pnpm","pnpm.cmd","yarn","yarn.cmd")
  OR process="*npm install*"
  OR process="*npm ci*"
  OR process="*pnpm install*"
  OR process="*yarn install*"
  OR process="*setup.mjs*"
  OR process="*preinstall*"
  OR process="*postinstall*"
  OR process_name IN ("bun","bun.exe","node","node.exe","sh","bash","zsh","powershell.exe","pwsh.exe")
)
(
  process="*.npmrc*"
  OR process="*npm_TOKEN*"
  OR process="*GITHUB_TOKEN*"
  OR process="*SECRET*"
  OR process="*TOKEN*"
  OR process="*node_modules*"
  OR process="*.npm*"
  OR process="*.pnpm*"
  OR process="*_work*"
  OR process="*actions-runner*"
  OR process="*workspace*"
  OR file_path="*.npmrc*"
  OR file_path="*secrets*"
  OR file_path="*token*"
  OR file_path="*credential*"
)
| eval local_signal=1
| eval correlation_user=coalesce(user, actor, account)
| eval correlation_ip=coalesce(src_ip, src, source_ip, client_ip)
| eval event_source="endpoint"
| fields time eventsource host correlation_user correlation_ip local_signal process process_name parent_process_name process_path file_path
| append [
    search index=npm earliest=-90m@m latest=now
    (
      action IN (
        "package.publish",
        "package.version",
        "token.create",
        "token.validate",
        "token.use",
        "package.owner.add",
        "package.owner.remove",
        "package.access.update",
        "package.maintainer.add",
        "package.maintainer.remove",
        "package.metadata.update"
      )
      OR event_type IN (
        "publish",
        "token",
        "owner",
        "maintainer",
        "access",
        "metadata"
      )
    )
    | eval npm_signal=1
    | eval correlation_user=coalesce(npm_account,user,actor,account)
    | eval correlation_ip=coalesce(src_ip,source_ip,client_ip,src)
    | eval event_source="npm"
    | fields time eventsource correlation_user correlation_ip npm_signal action event_type package package_name package_version npm_account token_id src_ip source_ip client_ip user_agent package_scope provenance_result
  ]
| bin time span=60m
| stats
    earliest(time) as first_seen
    latest(_time) as last_seen
    values(event_source) as event_sources
    values(host) as hosts
    values(process) as command_lines
    values(process_name) as process_names
    values(parent_process_name) as parent_processes
    values(file_path) as file_paths
    values(action) as npm_actions
    values(event_type) as npm_event_types
    values(package) as packages
    values(package_name) as package_names
    values(package_version) as package_versions
    values(npm_account) as npm_accounts
    values(token_id) as token_ids
    values(user_agent) as user_agents
    values(package_scope) as package_scopes
    values(provenance_result) as provenance_results
    values(correlation_ip) as source_ips
    max(local_signal) as has_local_signal
    max(npm_signal) as has_npm_signal
    by correlation_user correlation_ip time
| where haslocal_signal=1 AND has_npm_signal=1
| eval first_seen=strftime(first_seen,"%Y-%m-%d %H:%M:%S")
| eval last_seen=strftime(last_seen,"%Y-%m-%d %H:%M:%S")
| eval severity="high"
| eval detection_name="npm Registry Publishing or Token Abuse Following Credential Exposure Signals"
| table first_seen last_seen severity detection_name correlation_user source_ips hosts npm_accounts packages package_names package_versions npm_actions npm_event_types token_ids user_agents package_scopes provenance_results process_names parent_processes command_lines file_paths

Elastic

Detection Viability Assessment

Elastic is a strong S25 detection platform for this incident because it can support endpoint behavior detection, EQL sequence logic, process lineage, file activity, network events, and cross-source enrichment when endpoint, CI/CD, GitHub, npm, identity, and cloud telemetry are normalized into Elastic.

Elastic should be used to detect endpoint and CI/CD execution chains that connect package-manager lifecycle activity, abnormal Bun or Node execution, credential access, local staging, and downstream SaaS or cloud activity. The Elastic rules below are written as detection-rule templates and require validation against Elastic Common Schema fields, source-specific integrations, index naming, event-action values, process entity identifiers, and identity normalization before production deployment.

Elastic Rule 1

npm Lifecycle Execution Followed by Suspicious Runtime or Shell Execution

Rule Status

Production detection rule.

Rule Format

Elastic Detection Rule using EQL sequence logic.

Detection Objective

Detect npm, pnpm, or yarn lifecycle execution followed by suspicious runtime, shell, downloader, archive utility, or encoded-command behavior on the same host and user within a short time window.

Detection Logic

This rule detects the transition from trusted dependency installation to attacker-controlled execution. It requires package-manager lifecycle behavior followed by suspicious child-process execution from npm-related, dependency, cache, temporary, user-profile, or CI workspace context.

Required Telemetry

·        Endpoint process creation events.

·        Parent-child process lineage.

·        Full command-line arguments.

·        Process executable path.

·        Process working directory where available.

·        User identity.

·        Host identity.

·        CI/CD runner tagging where available.

·        Asset role or endpoint group where available.

Engineering Implementation Instructions

Engineers should deploy this rule against developer endpoints, self-hosted CI/CD runners, release engineering systems, and package-publishing systems. The rule must be mapped and validated against Elastic Common Schema fields before deployment, especially process.parent.name, process.command_line, process.executable, host.id, and user.id.

The rule should not alert on npm, pnpm, or yarn execution alone. It should require lifecycle context and suspicious follow-on execution, such as Bun execution, shell execution, downloader use, encoded command use, archive utility execution, or execution from dependency, cache, temporary, or CI workspace paths.

Tiering Data

·        Tier 1: Deploy as a detection or hunt against developer endpoints and self-hosted CI/CD runners.

·        Tier 2: Add asset role tagging for developer systems, CI/CD runners, release systems, and package-publishing systems.

·        Tier 3: Correlate Elastic endpoint alerts with GitHub, npm, proxy, DNS, and identity telemetry.

·        Tier 4: Add repository, runner, build-image, approved runtime, release workflow, and known build-tooling context to reduce noise and support higher-confidence escalation.

DRI Assessment

Detection Robustness Index

·        8.8

DRI Justification

The rule is behaviorally anchored on package-manager lifecycle execution and suspicious follow-on runtime or shell behavior. It does not depend on static package names, filenames, hashes, or attacker infrastructure. It remains resilient to package-name changes and payload refactoring because malicious npm package activity still requires an execution transition from dependency installation into attacker-controlled code.

TCR Assessment

Operational TCR

·        Moderate to High

Operational TCR Justification

Operational confidence depends on Elastic endpoint visibility across developer systems and self-hosted CI/CD runners, including process ancestry, command-line logging, process path, and user/host normalization. Confidence is reduced where managed runners or ephemeral containers lack endpoint telemetry.

Full-Telemetry TCR

·        High

Full-Telemetry TCR Justification

With full Elastic endpoint process telemetry and ECS-normalized host, user, process, and event fields, this rule can reliably detect the install-time execution transition required for malicious dependency behavior.

Limitations

·        Legitimate lifecycle scripts may spawn shells, runtimes, archive tools, or download utilities.

·        Environments with custom build scripts require baseline tuning.

·        Managed CI/CD runners may not provide endpoint-level process telemetry.

·        Rule fidelity depends on ECS field normalization and event retention.

Detection Code

name: "npm Lifecycle Execution Followed by Suspicious Runtime or Shell Execution"
type: eql
severity: high
risk_score: 73
description: >
  Detects npm, pnpm, or yarn lifecycle execution followed by suspicious runtime,
  shell, downloader, archive utility, or encoded-command behavior from developer
  or CI/CD execution contexts. Validate ECS field mappings before production deployment.
index:
  - logs-endpoint.events.process-*
  - endgame-*
language: eql
query: |
  sequence by host.id, user.id with maxspan=15m
    [process where event.type == "start" and
      (
process.name in ("npm", "npm.cmd", "pnpm", "pnpm.cmd", "yarn", "yarn.cmd") or
        process.command_line : ("*npm install*", "*npm ci*", "*pnpm install*", "*yarn install*", "*preinstall*", "*postinstall*", "*setup.mjs*")
      )
    ]
    [process where event.type == "start" and
process.parent.name in ("npm", "npm.cmd", "pnpm", "pnpm.cmd", "yarn", "yarn.cmd") and
      (
process.name in (
          "bun", "bun.exe", "node", "node.exe",
          "sh", "bash", "zsh", "cmd.exe", "powershell.exe", "pwsh.exe",
          "curl", "curl.exe", "wget", "wget.exe",
          "tar", "tar.exe", "unzip", "unzip.exe",
          "python", "python.exe", "python3"
        ) or
        process.command_line : (
          "*setup.mjs*", "*node_modules*", "*.npm*", "*.pnpm*",
          "*curl ", "wget ", "-enc*", "*-encodedcommand*",
          "*base64*", "*chmod +x*"
        ) or
        process.executable : (
          "*node_modules*", "*.npm*", "*.pnpm*", "*/tmp/*", "*\\Temp\\*",
          "*workspace*", "*actions-runner*", "*_work*"
        )
      )
    ]
tags:
  - CyberDax
  - Supply Chain
  - npm
  - Developer Tools
  - CI/CD
  - Shai-Hulud-Style
required_fields:
  - event.type
  - host.id
  - user.id
  - process.name
  - process.parent.name
  - process.command_line
  - process.executable

Elastic Rule 2

Bun or Node Execution from Dependency or CI Workspace Path with Process-Linked Secret Access

Rule Status

Conditional production detection rule.

Rule Format

Elastic Detection Rule using EQL sequence logic.

Detection Objective

Detect Bun or Node execution from dependency, cache, temporary, user-profile, or CI workspace paths followed by credential-file access, secret-related environment discovery, or local staging activity tied to the same process entity where process-to-file linkage is available.

Detection Logic

This rule detects suspicious runtime behavior consistent with malicious dependency payload execution. It requires abnormal Bun or Node execution context and follow-on credential access or staging behavior. This rule is conditional because production-quality precision depends on file events containing process.entity_id or an equivalent process GUID that links file access back to the same runtime process.

Where Elastic telemetry provides reliable process.entity_id on both process and file events, this rule is viable as a conditional production detection. Where that linkage is unavailable, the rule should be downgraded to a hunt or rewritten using stronger host, user, path, working-directory, and short-window constraints.

Required Telemetry

·        Endpoint process creation events.

·        File read, create, and modification events.

·        Parent-child process lineage.

·        Full command-line arguments.

·        Process executable path.

·        Process entity identifier or equivalent process GUID.

·        File path.

·        User identity.

·        Host identity.

·        CI/CD runner tagging where available.

Engineering Implementation Instructions

Engineers should baseline approved Bun usage before production deployment. In environments where Bun is not approved, Bun execution from dependency, temporary, user-profile, or CI workspace paths should receive higher priority. In environments where Bun is approved, detection should require abnormal path context, package-manager ancestry, credential access, staging behavior, or follow-on outbound activity.

Before enabling this rule as a production detection, engineers must validate that file events populate process.entity_id or an equivalent process GUID that matches the runtime process. If process-to-file linkage is missing or inconsistent, this rule should remain a hunt until the telemetry mapping is corrected.

Tiering Data

·        Tier 1: Use as a hunt unless process-to-file linkage is confirmed.

·        Tier 2: Enable conditional production alerting only when credential-path or staging-file activity is linked to the same process entity.

·        Tier 3: Correlate with package-install logs, GitHub audit activity, npm registry events, proxy logs, and identity telemetry.

·        Tier 4: Add repository-specific runtime baselines, approved build-image context, known developer tooling exceptions, and validated process-entity linkage.

DRI Assessment

Detection Robustness Index

·        8.2

DRI Justification

The rule targets abnormal runtime execution and process-linked credential-access behavior rather than a static package, hash, filename, or endpoint. It remains resilient against payload filename changes and infrastructure changes because it detects runtime execution from suspicious dependency or CI paths followed by secret-access behavior. The score is lower than a full production rule because detection strength depends on reliable process-to-file linkage in Elastic telemetry.

TCR Assessment

Operational TCR

·        Moderate when process-to-file linkage is validated.

·        Low to Moderate when process-to-file linkage is unavailable.

Operational TCR Justification

Operational confidence depends on Elastic endpoint process and file telemetry, especially whether file events include process.entity_id or an equivalent process GUID. Confidence is materially reduced where file telemetry is not enabled, process-to-file linkage is missing, or secrets are exposed only through environment variables without file events.

Full-Telemetry TCR

·        High

Full-Telemetry TCR Justification

With ECS-normalized process, file, user, host, path, and process entity telemetry, Elastic can reliably identify abnormal runtime execution and sensitive file interaction on developer systems and CI/CD runners.

Limitations

·        This rule should not be enabled as a production detection unless process-to-file linkage is validated.

·        Legitimate Node or Bun tooling may access project files during builds.

·        File-read visibility may vary by endpoint source, operating system, Elastic integration, and policy configuration.

·        Environment-variable-only secret access may not generate direct file events.

·        Approved Bun environments require stronger runtime and repository baselines.

Detection Code

name: "Bun or Node Execution from Dependency or CI Workspace Path with Process-Linked Secret Access"
type: eql
severity: high
risk_score: 68
description: >
  Conditional production rule. Detects Bun or Node execution from dependency,
  cache, temporary, user-profile, or CI workspace paths followed by credential
  access or staging behavior tied to the same process entity. Enable as a
  production detection only when file events reliably populate process.entity_id
  or an equivalent process GUID.
index:
  - logs-endpoint.events.process-*
  - logs-endpoint.events.file-*
  - endgame-*
language: eql
query: |
  sequence by host.id, user.id, process.entity_id with maxspan=20m
    [process where event.type == "start" and
process.name in ("bun", "bun.exe", "node", "node.exe") and
      (
        process.executable : (
          "*node_modules*", "*.npm*", "*.pnpm*", "*/tmp/*", "*\\Temp\\*",
          "*workspace*", "*actions-runner*", "*_work*", "*.cache*"
        ) or
        process.command_line : (
          "*setup.mjs*", "*preinstall*", "*postinstall*", "*node_modules*",
          "*.npm*", "*.pnpm*", "*_work*", "*workspace*"
        )
      )
    ]
    [file where event.type in ("access", "change", "creation") and
      (
        file.path : (
          "*.npmrc*", "*.ssh*", "*id_rsa*", "*id_ed25519*",
          "*.aws/credentials*", "*.azure*", "*.config/gcloud*",
          "*.kube/config*", "*docker/config.json*",
          "*environment.json*", "*cloud.json*", "*data.json*",
          "*secrets*", "*token*", "*credential*"
        ) or
file.name : (
          ".npmrc", "id_rsa", "id_ed25519", "environment.json",
          "cloud.json", "data.json"
        )
      )
    ]
tags:
  - CyberDax
  - Supply Chain
  - npm
  - Bun
  - Node.js
  - Credential Access
  - CI/CD
required_fields:
  - event.type
  - host.id
  - user.id
  - process.entity_id
  - process.name
  - process.executable
  - process.command_line
  - file.path
  - file.name

Elastic Rule 3

Local Developer or CI/CD Compromise Signal Followed by Sensitive SaaS or Cloud Control-Plane Activity

Rule Status

Production detection rule template requiring source-specific mapping.

Rule Format

Elastic Detection Rule using EQL correlation template with source-specific identity mapping.

Detection Objective

Detect suspicious developer or CI/CD runtime activity followed by sensitive GitHub, npm, or cloud control-plane activity that may indicate token abuse, workflow modification, package publication, privilege change, or downstream credential misuse.

Detection Logic

This rule correlates suspicious local execution or credential-access indicators with sensitive external control-plane activity. It is designed for Elastic environments ingesting endpoint, GitHub, npm, cloud, and identity telemetry into normalized event fields. Because cross-source identity normalization varies widely, this rule must be validated against local mappings before production use.

The strongest deployment requires one or more shared pivots between the local signal and control-plane signal, such as normalized user identity, source IP, automation identity, CI/CD runner identity, repository, package, or token/account context.

Required Telemetry

·        Endpoint process events.

·        Endpoint file events where available.

·        GitHub audit logs or equivalent source-code platform logs.

·        npm registry logs.

·        Cloud control-plane logs.

·        Identity logs.

·        User and actor normalization.

·        Source IP and user-agent fields.

·        Repository, package, cloud account, or tenant context.

·        CI/CD runner or workflow identity where available.

Engineering Implementation Instructions

Engineers must normalize GitHub, npm, cloud, and identity events into consistent event action, event provider, user, source IP, user agent, repository, package, cloud account, and cloud resource fields before deployment. This rule should not be treated as plug-and-play production logic until source-specific mappings are validated.

The rule should not alert on ordinary GitHub administration, npm publishing, or cloud activity alone. Production deployment should require suspicious local execution or credential access followed by sensitive control-plane activity within a defined time window and connected through validated identity, source, repository, package, runner, or automation context.

Cloud activity should be constrained to sensitive actions such as credential creation, privilege change, secret access, service-account modification, role assignment, workload identity modification, container or artifact registry manipulation, or deployment-path modification. Broad cloud API activity without sensitive action context should remain enrichment only.

Tiering Data

·        Tier 1: Use as a hunt for exposed developer or CI/CD identities after package exposure.

·        Tier 2: Add GitHub, npm, and cloud event ingestion with actor, source IP, user-agent, and identity normalization.

·        Tier 3: Correlate endpoint, CI/CD, GitHub, npm, cloud, proxy, DNS, and identity telemetry using validated pivots.

·        Tier 4: Add repository criticality, package maintainer role, token type, cloud identity sensitivity, release workflow context, deployment environment context, and automation identity mapping.

DRI Assessment

Detection Robustness Index

·        8.2

DRI Justification

The rule detects downstream abuse behavior following suspicious local execution or credential access. It is resilient to package-name, filename, hash, and infrastructure changes because it focuses on token abuse and sensitive control-plane actions. The score is lower than the first Elastic rule because effectiveness depends on cross-source identity normalization and source-specific audit fidelity.

TCR Assessment

Operational TCR

·        Moderate

Operational TCR Justification

Operational confidence depends on whether GitHub, npm, cloud, identity, and endpoint events are ingested into Elastic with consistent actor, source IP, event action, user-agent, repository, package, and cloud-resource fields. Confidence is reduced when SaaS and cloud audit logs are incomplete, not mapped to Elastic Common Schema, or cannot be reliably tied back to endpoint or CI/CD identities.

Full-Telemetry TCR

·        High

Full-Telemetry TCR Justification

With endpoint, GitHub, npm, cloud, CI/CD, and identity telemetry normalized into Elastic and connected through validated identity or source pivots, this rule can identify suspicious sequences from local compromise indicators to downstream token or control-plane abuse.

Limitations

·        Cross-source telemetry must be normalized before production deployment.

·        Legitimate release automation may perform GitHub, npm, or cloud actions.

·        Token theft may not always be attributable to the original package execution point.

·        Personal repositories or external package-maintainer accounts may fall outside enterprise logging.

·        Cloud events require sensitive action filtering and validated identity or source context to avoid noise.

Detection Code

name: "Local Developer or CI/CD Compromise Signal Followed by Sensitive SaaS or Cloud Control-Plane Activity"
type: eql
severity: high
risk_score: 67
description: >
  Correlation template for detecting suspicious developer or CI/CD runtime activity
  followed by sensitive GitHub, npm, or cloud control-plane actions. Requires
  source-specific identity, actor, source IP, user-agent, repository, package,
  cloud account, and event.action mapping before production deployment.
index:
  - logs-endpoint.events.process-*
  - logs-endpoint.events.file-*
  - logs-github.audit-*
  - logs-npm.audit-*
  - logs-aws.cloudtrail-*
  - logs-azure.activitylogs-*
  - logs-gcp.audit-*
  - logs-identity-*
language: eql
query: |
  sequence by user.id with maxspan=60m
    [any where
      (
        event.category == "process" and event.type == "start" and
        (
process.parent.name in ("npm", "npm.cmd", "pnpm", "pnpm.cmd", "yarn", "yarn.cmd") or
process.name in ("bun", "bun.exe", "node", "node.exe", "sh", "bash", "zsh", "powershell.exe", "pwsh.exe") or
          process.command_line : (
            "*setup.mjs*", "*preinstall*", "*postinstall*", "*node_modules*",
            "*.npm*", "*.pnpm*", "*GITHUB_TOKEN*", "*npm_TOKEN*", "*SECRET*", "*TOKEN*"
          )
        )
      ) or
      (
        event.category == "file" and event.type in ("access", "change", "creation") and
        file.path : (
          "*.npmrc*", "*.ssh*", "*.aws/credentials*", "*.kube/config*",
          "*secrets*", "*token*", "*credential*"
        )
      )
    ]
    [any where
      (
        event.provider == "github" and
        event.action in (
          "repo.create",
          "repo.visibility_change",
          "workflow.create",
          "workflow.update",
          "org.update_actions_secret",
          "repo.update_actions_secret",
          "repo.create_deploy_key",
          "repo.add_deploy_key",
          "hook.create",
          "hook.update",
          "oauth_authorization.create",
          "personal_access_token.used"
        )
      ) or
      (
        event.provider == "npm" and
        event.action in (
          "package.publish",
          "package.version",
          "token.create",
          "token.validate",
          "token.use",
          "package.owner.add",
          "package.owner.remove",
          "package.access.update",
          "package.maintainer.add",
          "package.maintainer.remove",
          "package.metadata.update"
        )
      ) or
      (
        event.provider == "aws" and
        event.action in (
          "CreateAccessKey",
          "UpdateAccessKey",
          "AssumeRole",
          "PutRolePolicy",
          "AttachRolePolicy",
          "CreatePolicyVersion",
          "PutUserPolicy",
          "PutGroupPolicy",
          "CreateLoginProfile",
          "CreateUser",
          "CreateRole",
          "UpdateAssumeRolePolicy",
          "GetSecretValue",
          "PutSecretValue",
          "CreateSecret",
          "PutResourcePolicy"
        )
      ) or
      (
        event.provider == "azure" and
        event.action in (
          "Microsoft.Authorization/roleAssignments/write",
          "Microsoft.Authorization/roleDefinitions/write",
          "Microsoft.KeyVault/vaults/secrets/read",
          "Microsoft.KeyVault/vaults/secrets/write",
          "Microsoft.ContainerRegistry/registries/write",
          "Microsoft.ManagedIdentity/userAssignedIdentities/write",
          "Add service principal credentials",
          "Update application credentials",
          "Add app role assignment to service principal"
        )
      ) or
      (
        event.provider == "gcp" and
        event.action in (
          "google.iam.admin.v1.CreateServiceAccount",
          "google.iam.admin.v1.CreateServiceAccountKey",
          "SetIamPolicy",
          "google.cloud.secretmanager.v1.AccessSecretVersion",
          "google.cloud.secretmanager.v1.AddSecretVersion",
          "google.devtools.cloudbuild.v1.CreateBuild",
          "google.devtools.artifactregistry.v1.UploadArtifact",
          "google.containeranalysis.v1.CreateOccurrence"
        )
      )
    ]
tags:
  - CyberDax
  - Supply Chain
  - npm
  - GitHub
  - npm Registry
  - Cloud
  - Token Abuse
  - CI/CD
required_fields:
  - event.category
  - event.type
  - event.provider
  - event.action
  - user.id
  - process.name
  - process.parent.name
  - process.command_line
  - file.path

QRadar

Detection Viability Assessment

QRadar is viable for S25 when endpoint, CI/CD, GitHub, npm registry, identity, cloud, proxy, DNS, and network telemetry are normalized with reliable DSM parsing, custom properties, user identity, source IP, host, repository, package, cloud-account, and automation-context fields.

QRadar should be used for correlation-driven detection rather than single-event alerting. The strongest QRadar coverage for this incident comes from CRE rules that connect local developer or CI/CD execution signals with credential access, suspicious egress, GitHub activity, npm registry activity, or cloud-control-plane activity.

The QRadar logic below is written as AQL hunt logic plus CRE correlation requirements. The AQL components support validation and enrichment. Production offense generation should occur only after CRE logic confirms the required sequence and pivot conditions.

QRadar Rule 1

npm Lifecycle Execution with Suspicious Runtime or Credential Access Indicators

Rule Status

Production detection rule using CRE correlation.

Rule Format

QRadar AQL hunt logic with CRE correlation rule requirement.

Detection Objective

Detect npm, pnpm, or yarn lifecycle execution followed by suspicious runtime, shell, downloader, archive utility, encoded-command, credential-access, or local-staging behavior on the same host and user within a short time window.

Detection Logic

This rule detects the transition from trusted package installation to suspicious local execution. Production alerting must require a lifecycle signal plus one or more suspicious follow-on indicators within the same user, host, and correlation window.

Generic npm installation should not alert by itself.

Required CRE Conditions

The production CRE rule should require:

·        A package-manager lifecycle signal from npm, pnpm, or yarn.

·        A suspicious follow-on signal within the defined correlation window.

·        A shared host and user, or an equivalent validated endpoint and identity pivot.

·        Asset role context indicating developer endpoint, CI/CD runner, release system, or package-publishing system.

The suspicious follow-on signal should include at least one of the following:

·        Package-manager child process spawning Bun, Node, shell, PowerShell, downloader, archive utility, Python, or encoded-command execution.

·        Runtime execution from dependency, package-cache, temporary, user-profile, CI workspace, actions-runner, or _work paths.

·        Access to credential, token, secret, cloud configuration, SSH, Kubernetes, Docker, npm, or repository credential material.

·        Local staging activity involving secret-like, token-like, credential-like, JSON, archive, encoded, or compressed files.

Required Telemetry

·        Endpoint process creation events.

·        Parent-child process lineage.

·        Full command-line arguments.

·        Process executable path.

·        File access or file creation telemetry.

·        User identity.

·        Host identity.

·        CI/CD runner identity where available.

·        Asset role or endpoint group where available.

Engineering Implementation Instructions

Engineers must map endpoint telemetry into QRadar event fields and custom properties before deployment. Required mappings include process name, parent process name, process command line, process path, file path, user, host, asset role, and CI/CD runner context where available.

The AQL below should be used to validate candidate events and tune custom properties. Production deployment should be implemented as a CRE correlation rule that requires lifecycle activity plus suspicious follow-on behavior, not as a broad single-event AQL offense.

Tiering Data

·        Tier 1: Deploy as scheduled AQL hunts against developer endpoints and self-hosted CI/CD runners.

·        Tier 2: Add asset role tagging for developer systems, CI/CD runners, release systems, and package-publishing systems.

·        Tier 3: Convert validated AQL logic into a CRE rule with offense generation only when lifecycle and suspicious follow-on signals align.

·        Tier 4: Add repository, runner, build-image, approved runtime, release workflow, and identity context to reduce noise and support high-confidence escalation.

DRI Assessment

Detection Robustness Index

·        8.3

DRI Justification

The rule is behaviorally anchored on package-manager lifecycle execution, suspicious child-process behavior, abnormal execution paths, and credential-access indicators. It does not depend on static package names, payload hashes, or attacker infrastructure. It remains useful across package-name changes and payload refactoring because malicious npm package activity still requires an execution transition or follow-on local activity.

TCR Assessment

Operational TCR

·        Moderate

Operational TCR Justification

Operational confidence depends on endpoint telemetry quality, command-line logging, DSM parsing, custom property extraction, and reliable host and user mapping. Confidence is reduced where developer endpoints or CI/CD runners are not instrumented or where file-access telemetry is unavailable.

Full-Telemetry TCR

·        High

Full-Telemetry TCR Justification

With endpoint process telemetry, file-access telemetry, host-role context, CI/CD runner context, and normalized QRadar custom properties, QRadar can reliably correlate lifecycle execution and credential-access behavior.

Limitations

·        QRadar field quality depends heavily on DSM parsing and custom property extraction.

·        Legitimate lifecycle scripts may spawn shells, runtimes, archive utilities, or download utilities.

·        Managed CI/CD runners may not provide endpoint-level telemetry.

·        Environments with custom build workflows require baseline tuning.

·        Broad AQL matching should be treated as hunt logic until CRE sequence and pivot conditions are validated.

Detection Code

-- QRadar AQL hunt logic for Rule 1.
-- Use this query to validate candidate local execution and credential-access events.
-- Production offense generation should be implemented through CRE correlation requiring:
-- 1. lifecycle signal,
-- 2. suspicious follow-on signal,
-- 3. shared host/user or validated equivalent pivot,
-- 4. developer, CI/CD, release, or package-publishing asset role.

SELECT
  DATEFORMAT(starttime, 'YYYY-MM-dd HH:mm:ss') AS first_seen,
  sourceip,
  destinationip,
  username,
  "ProcessName",
  "ParentProcessName",
  "ProcessCommandLine",
  "ProcessPath",
  "FilePath",
  "AssetRole",
  "RunnerName",
  QIDNAME(qid) AS event_name
FROM events
WHERE
  (
    LOWER("ProcessName") IN ('npm','npm.cmd','pnpm','pnpm.cmd','yarn','yarn.cmd')
    OR LOWER("ParentProcessName") IN ('npm','npm.cmd','pnpm','pnpm.cmd','yarn','yarn.cmd')
    OR LOWER("ProcessCommandLine") LIKE '%npm install%'
    OR LOWER("ProcessCommandLine") LIKE '%npm ci%'
    OR LOWER("ProcessCommandLine") LIKE '%pnpm install%'
    OR LOWER("ProcessCommandLine") LIKE '%yarn install%'
    OR LOWER("ProcessCommandLine") LIKE '%preinstall%'
    OR LOWER("ProcessCommandLine") LIKE '%postinstall%'
    OR LOWER("ProcessCommandLine") LIKE '%setup.mjs%'
  )
  AND
  (
    (
      LOWER("ParentProcessName") IN ('npm','npm.cmd','pnpm','pnpm.cmd','yarn','yarn.cmd')
      AND
      (
        LOWER("ProcessName") IN (
          'bun','bun.exe','node','node.exe','sh','bash','zsh',
          'cmd.exe','powershell.exe','pwsh.exe','curl','curl.exe',
          'wget','wget.exe','tar','tar.exe','unzip','unzip.exe',
          'python','python.exe','python3'
        )
        OR LOWER("ProcessCommandLine") LIKE '%-enc%'
        OR LOWER("ProcessCommandLine") LIKE '%-encodedcommand%'
        OR LOWER("ProcessCommandLine") LIKE '%base64%'
        OR LOWER("ProcessCommandLine") LIKE '%chmod +x%'
        OR LOWER("ProcessCommandLine") LIKE '%curl %'
        OR LOWER("ProcessCommandLine") LIKE '%wget %'
      )
    )
    OR
    (
      (
        LOWER("ProcessPath") LIKE '%node_modules%'
        OR LOWER("ProcessPath") LIKE '%.npm%'
        OR LOWER("ProcessPath") LIKE '%.pnpm%'
        OR LOWER("ProcessPath") LIKE '%/tmp/%'
        OR LOWER("ProcessPath") LIKE '%\\temp\\%'
        OR LOWER("ProcessPath") LIKE '%workspace%'
        OR LOWER("ProcessPath") LIKE '%actions-runner%'
        OR LOWER("ProcessPath") LIKE '%_work%'
      )
      AND
      (
        LOWER("ProcessName") IN ('bun','bun.exe','node','node.exe','sh','bash','zsh','powershell.exe','pwsh.exe','python','python3')
        OR LOWER("ProcessCommandLine") LIKE '%setup.mjs%'
      )
    )
    OR
    (
      LOWER("FilePath") LIKE '%.npmrc%'
      OR LOWER("FilePath") LIKE '%.ssh%'
      OR LOWER("FilePath") LIKE '%id_rsa%'
      OR LOWER("FilePath") LIKE '%id_ed25519%'
      OR LOWER("FilePath") LIKE '%.aws/credentials%'
      OR LOWER("FilePath") LIKE '%.azure%'
      OR LOWER("FilePath") LIKE '%.config/gcloud%'
      OR LOWER("FilePath") LIKE '%.kube/config%'
      OR LOWER("FilePath") LIKE '%docker/config.json%'
      OR LOWER("FilePath") LIKE '%secrets%'
      OR LOWER("FilePath") LIKE '%token%'
      OR LOWER("FilePath") LIKE '%credential%'
      OR LOWER("ProcessCommandLine") LIKE '%github_token%'
      OR LOWER("ProcessCommandLine") LIKE '%npm_token%'
      OR LOWER("ProcessCommandLine") LIKE '%aws_access_key%'
      OR LOWER("ProcessCommandLine") LIKE '%azure_client_secret%'
      OR LOWER("ProcessCommandLine") LIKE '%google_application_credentials%'
      OR LOWER("ProcessCommandLine") LIKE '%secret%'
      OR LOWER("ProcessCommandLine") LIKE '%token%'
    )
  )
  AND
  (
    LOWER("AssetRole") LIKE '%developer%'
    OR LOWER("AssetRole") LIKE '%ci%'
    OR LOWER("AssetRole") LIKE '%runner%'
    OR LOWER("AssetRole") LIKE '%release%'
    OR LOWER("AssetRole") LIKE '%package%'
  )
LAST 60 MINUTES

QRadar Rule 2

Sensitive GitHub, npm, or Cloud Activity Following Local Compromise Signals

Rule Status

Production detection rule using two-stage CRE correlation.

Rule Format

QRadar AQL hunt logic with CRE correlation rule requirement.

Detection Objective

Detect sensitive GitHub, npm registry, or cloud-control-plane activity following suspicious developer endpoint or CI/CD runner behavior that may indicate token abuse, package publication abuse, workflow modification, privilege change, or downstream credential misuse.

Detection Logic

This rule is implemented as a two-stage correlation. Stage 1 identifies local compromise signals from developer endpoint or CI/CD telemetry. Stage 2 identifies sensitive downstream GitHub, npm, or cloud activity. Production offense generation should occur only when both stages occur within the defined correlation window and share a validated pivot.

The AQL components below are not intended to trigger independently as production offenses.

Required CRE Conditions

The production CRE rule should require:

·        Stage 1 local compromise signal.

·        Stage 2 sensitive downstream GitHub, npm, or cloud action.

·        Correlation within the defined time window.

·        At least one validated pivot connecting both stages.

Validated pivots may include:

·        Username or actor.

·        Source IP.

·        CI/CD runner identity.

·        Host-to-user mapping.

·        Repository.

·        Package name.

·        Token identifier where available.

·        Automation identity.

·        Cloud account or tenant.

·        User-agent and source-context alignment.

Required Telemetry

·        Endpoint process telemetry.

·        CI/CD job telemetry where available.

·        GitHub audit logs or equivalent source-code platform logs.

·        npm registry logs.

·        Cloud control-plane logs.

·        Identity logs.

·        Source IP and user-agent fields.

·        Repository, package, cloud account, and tenant context.

·        User, actor, token, or automation identity normalization.

Engineering Implementation Instructions

Engineers must normalize GitHub, npm, cloud, and identity events into QRadar event names and custom properties before deployment. Required mappings include event provider, event action, actor, username, source IP, user agent, repository, package, cloud account, token identifier where available, and CI/CD runner or workflow context where available.

The rule should not alert on ordinary GitHub administration, npm publishing, or cloud activity alone. It should only generate an offense when Stage 1 and Stage 2 both occur and share a validated pivot.

Tiering Data

·        Tier 1: Use as a hunt for exposed developer, maintainer, package-publishing, and CI/CD identities after known package exposure.

·        Tier 2: Add GitHub, npm, and cloud event ingestion with actor, source IP, user-agent, and identity normalization.

·        Tier 3: Convert validated two-stage correlation logic into a CRE rule with offense generation.

·        Tier 4: Add repository criticality, package maintainer role, token type, cloud identity sensitivity, release workflow context, deployment environment context, and automation identity mapping.

DRI Assessment

Detection Robustness Index

·        8.0

DRI Justification

The rule is behaviorally anchored on sensitive downstream control-plane activity following local compromise indicators. It is resilient to package-name, filename, hash, and infrastructure changes because it focuses on token abuse, package-registry abuse, workflow manipulation, privilege changes, and sensitive cloud actions. The score is lower than the first QRadar rule because effectiveness depends on cross-source normalization and identity mapping.

TCR Assessment

Operational TCR

·        Moderate

Operational TCR Justification

Operational confidence depends on QRadar ingestion and normalization of endpoint, GitHub, npm, cloud, identity, and CI/CD events. Confidence is reduced when source logs lack actor, source IP, user-agent, token, repository, package, cloud-resource, or automation-context fields.

Full-Telemetry TCR

·        High

Full-Telemetry TCR Justification

With normalized endpoint, GitHub, npm, cloud, identity, and CI/CD telemetry, QRadar can correlate suspicious local activity with downstream token and control-plane abuse.

Limitations

·        Cross-source correlation depends on DSM parsing and custom property quality.

·        GitHub, npm, and cloud audit depth varies by platform configuration and retention.

·        Legitimate release automation may perform sensitive GitHub, npm, or cloud actions.

·        This rule can identify suspicious downstream activity but may not always prove the original credential-theft path.

·        Stage 1 and Stage 2 AQL components should not generate independent production offenses without CRE correlation.

Detection Code

-- QRadar Rule 2, Stage 1 AQL hunt logic.
-- Local developer or CI/CD compromise signal.
-- Use as the local-signal component for CRE correlation.

SELECT
  DATEFORMAT(starttime, 'YYYY-MM-dd HH:mm:ss') AS first_seen,
  sourceip,
  destinationip,
  username,
  "Actor",
  "RunnerName",
  "Repository",
  "PackageName",
  "ProcessName",
  "ParentProcessName",
  "ProcessCommandLine",
  "ProcessPath",
  "FilePath",
  "AssetRole",
  QIDNAME(qid) AS event_name
FROM events
WHERE
  (
    LOWER("ProcessCommandLine") LIKE '%npm install%'
    OR LOWER("ProcessCommandLine") LIKE '%npm ci%'
    OR LOWER("ProcessCommandLine") LIKE '%pnpm install%'
    OR LOWER("ProcessCommandLine") LIKE '%yarn install%'
    OR LOWER("ProcessCommandLine") LIKE '%setup.mjs%'
    OR LOWER("ProcessCommandLine") LIKE '%preinstall%'
    OR LOWER("ProcessCommandLine") LIKE '%postinstall%'
    OR LOWER("ParentProcessName") IN ('npm','npm.cmd','pnpm','pnpm.cmd','yarn','yarn.cmd')
    OR LOWER("ProcessName") IN ('bun','bun.exe','node','node.exe','sh','bash','zsh','powershell.exe','pwsh.exe')
  )
  AND
  (
    LOWER("ProcessCommandLine") LIKE '%node_modules%'
    OR LOWER("ProcessCommandLine") LIKE '%.npm%'
    OR LOWER("ProcessCommandLine") LIKE '%.pnpm%'
    OR LOWER("ProcessCommandLine") LIKE '%github_token%'
    OR LOWER("ProcessCommandLine") LIKE '%npm_token%'
    OR LOWER("ProcessCommandLine") LIKE '%secret%'
    OR LOWER("ProcessCommandLine") LIKE '%token%'
    OR LOWER("FilePath") LIKE '%.npmrc%'
    OR LOWER("FilePath") LIKE '%.ssh%'
    OR LOWER("FilePath") LIKE '%.aws/credentials%'
    OR LOWER("FilePath") LIKE '%.kube/config%'
    OR LOWER("FilePath") LIKE '%secrets%'
    OR LOWER("FilePath") LIKE '%token%'
    OR LOWER("FilePath") LIKE '%credential%'
  )
  AND
  (
    LOWER("AssetRole") LIKE '%developer%'
    OR LOWER("AssetRole") LIKE '%ci%'
    OR LOWER("AssetRole") LIKE '%runner%'
    OR LOWER("AssetRole") LIKE '%release%'
    OR LOWER("AssetRole") LIKE '%package%'
  )
LAST 90 MINUTES

-- QRadar Rule 2, Stage 2 AQL hunt logic.
-- Sensitive downstream GitHub, npm, or cloud action.
-- Use as the downstream-action component for CRE correlation.

SELECT
  DATEFORMAT(starttime, 'YYYY-MM-dd HH:mm:ss') AS first_seen,
  sourceip,
  username,
  "Actor",
  "EventProvider",
  "EventAction",
  "Repository",
  "PackageName",
  "CloudAccount",
  "CloudTenant",
  "TokenId",
  "UserAgent",
  "RunnerName",
  QIDNAME(qid) AS event_name
FROM events
WHERE
  (
    LOWER("EventProvider") = 'github'
    AND LOWER("EventAction") IN (
      'repo.create',
      'repo.visibility_change',
      'workflow.create',
      'workflow.update',
      'org.update_actions_secret',
      'repo.update_actions_secret',
      'repo.create_deploy_key',
      'repo.add_deploy_key',
      'hook.create',
      'hook.update',
      'oauth_authorization.create',
      'personal_access_token.used'
    )
  )
  OR
  (
    LOWER("EventProvider") = 'npm'
    AND LOWER("EventAction") IN (
      'package.publish',
      'package.version',
      'token.create',
      'token.validate',
      'token.use',
      'package.owner.add',
      'package.owner.remove',
      'package.access.update',
      'package.maintainer.add',
      'package.maintainer.remove',
      'package.metadata.update'
    )
  )
  OR
  (
    LOWER("EventProvider") IN ('aws','azure','gcp')
    AND LOWER("EventAction") IN (
      'createaccesskey',
      'updateaccesskey',
      'assumerole',
      'putrolepolicy',
      'attachrolepolicy',
      'createpolicyversion',
      'putuserpolicy',
      'createloginprofile',
      'getsecretvalue',
      'putsecretvalue',
      'createsecret',
      'microsoft.authorization/roleassignments/write',
      'microsoft.authorization/roledefinitions/write',
      'microsoft.keyvault/vaults/secrets/read',
      'microsoft.keyvault/vaults/secrets/write',
      'add service principal credentials',
      'update application credentials',
      'google.iam.admin.v1.createserviceaccount',
      'google.iam.admin.v1.createserviceaccountkey',
      'setiampolicy',
      'google.cloud.secretmanager.v1.accesssecretversion',
      'google.cloud.secretmanager.v1.addsecretversion',
      'google.devtools.cloudbuild.v1.createbuild'
    )
  )
LAST 90 MINUTES

CRE Correlation Requirement

For production deployment, Rule 2 must be implemented as a CRE correlation rule that requires:

·        A Stage 1 local compromise signal.

·        A Stage 2 sensitive downstream action.

·        A shared validated pivot between the two stages.

·        A defined correlation window.

·        Offense generation only when both stages are satisfied.

SIGMA

Detection Viability Assessment

SIGMA is viable for S25 because the highest-value endpoint behaviors in this incident can be expressed as portable detection logic across SIEM and EDR-backed log sources. SIGMA should focus on endpoint-observable behaviors such as package-manager lifecycle execution, suspicious runtime or shell spawning, Bun or Node execution from abnormal paths, credential access, and local staging.

SIGMA should not attempt to model GitHub, npm registry, cloud-control-plane, or cross-source SaaS correlation for this section. Those behaviors are better handled by native SIEM, source-code platform, package-registry, cloud, and identity telemetry. The SIGMA rules below are scoped to endpoint behavior and require backend field mapping before production deployment.

SIGMA Rule 1

Suspicious npm Lifecycle Execution Spawning Runtime, Shell, or Downloader

Rule Status

Production detection rule.

Rule Format

SIGMA rule format.

Detection Objective

Detect npm, pnpm, or yarn lifecycle execution spawning suspicious runtime, shell, downloader, archive utility, Python, or encoded-command behavior from developer endpoints, release systems, package-publishing systems, or self-hosted CI/CD runners.

Detection Logic

This rule detects the transition from trusted package installation to suspicious local execution. It focuses on package-manager ancestry and suspicious child-process behavior rather than package names, hashes, or static infrastructure.

Required Telemetry

·        Endpoint process creation telemetry.

·        Parent process name.

·        Child process name.

·        Full command-line arguments.

·        Process executable path.

·        Working directory where available.

·        User identity.

·        Host identity.

·        Asset role or endpoint group where available.

Engineering Implementation Instructions

Engineers should map SIGMA fields to the target backend before deployment. The rule should be deployed against developer endpoints, self-hosted CI/CD runners, release engineering systems, and package-publishing systems.

The rule should not be used to alert on package-manager activity alone. Production use should require package-manager ancestry plus suspicious child-process behavior, suspicious execution path, downloader behavior, encoded command behavior, or CI/CD runner context.

Tiering Data

·        Tier 1: Deploy as a hunt on developer endpoints and self-hosted CI/CD runners.

·        Tier 2: Add asset role tagging for developer workstations, CI/CD runners, release systems, and package-publishing systems.

·        Tier 3: Correlate translated SIGMA matches with GitHub audit logs, npm registry activity, proxy logs, DNS logs, and identity telemetry.

·        Tier 4: Add repository, runner, build-image, approved runtime, and release workflow context in the backend SIEM to reduce noise.

DRI Assessment

Detection Robustness Index

·        8.5

DRI Justification

The rule is behaviorally anchored on package-manager ancestry and suspicious child-process execution. It remains useful across package-name changes, filename changes, hash changes, and infrastructure changes because malicious npm package activity still requires install-time execution or follow-on local runtime activity.

TCR Assessment

Operational TCR

·        Moderate to High

Operational TCR Justification

Operational confidence depends on process creation telemetry, parent process visibility, command-line logging, process path visibility, and backend field normalization. Confidence is reduced where endpoint telemetry does not capture process ancestry or full command-line arguments.

Full-Telemetry TCR

·        High

Full-Telemetry TCR Justification

With complete process creation, parent-child lineage, command-line, and process path telemetry, this rule provides strong portable coverage for suspicious npm lifecycle execution.

Limitations

·        Legitimate lifecycle scripts may spawn shells, runtimes, archive utilities, or download utilities.

·        Backend field names vary and must be mapped before deployment.

·        Environments with custom build tooling require baseline tuning.

·        Managed CI/CD runners may not provide endpoint-level telemetry.

Detection Code

title: Suspicious npm Lifecycle Execution Spawning Runtime Shell or Downloader
id: 7cc59b0d-9bcb-4e7b-bc71-5f956a10f1a1
status: experimental
description: Detects npm, pnpm, or yarn spawning suspicious runtime, shell, downloader, archive utility, Python, or encoded-command behavior from developer or CI/CD execution contexts.
author: CyberDax
date: 2026/04/30
logsource:
  category: process_creation
detection:
  selection_parent_image:
    ParentImage|endswith:
      - '\npm.exe'
      - '\npm.cmd'
      - '\pnpm.exe'
      - '\pnpm.cmd'
      - '\yarn.exe'
      - '\yarn.cmd'
      - '/npm'
      - '/pnpm'
      - '/yarn'
  selection_parent_cmd:
    ParentCommandLine|contains:
      - 'npm install'
      - 'npm ci'
      - 'pnpm install'
      - 'yarn install'
      - 'preinstall'
      - 'postinstall'
      - 'setup.mjs'
  selection_child:
    Image|endswith:
      - '\bun.exe'
      - '\node.exe'
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\curl.exe'
      - '\wget.exe'
      - '\tar.exe'
      - '\unzip.exe'
      - '\python.exe'
      - '/bun'
      - '/node'
      - '/sh'
      - '/bash'
      - '/zsh'
      - '/curl'
      - '/wget'
      - '/tar'
      - '/unzip'
      - '/python'
      - '/python3'
  selection_cmd:
    CommandLine|contains:
      - 'setup.mjs'
      - 'curl '
      - 'wget '
      - '-enc'
      - '-encodedcommand'
      - 'base64'
      - 'chmod +x'
  selection_path_image:
    Image|contains:
      - 'node_modules'
      - '.npm'
      - '.pnpm'
      - '\Temp\'
      - '/tmp/'
      - 'workspace'
      - 'actions-runner'
      - '_work'
  selection_path_cmd:
    CommandLine|contains:
      - 'node_modules'
      - '.npm'
      - '.pnpm'
      - 'workspace'
      - 'actions-runner'
      - '_work'
  condition: (selection_parent_image or selection_parent_cmd) and (selection_child or selection_cmd or selection_path_image or selection_path_cmd)
fields:
  - UtcTime
  - Computer
  - User
  - Image
  - CommandLine
  - ParentImage
  - ParentCommandLine
  - CurrentDirectory
falsepositives:
  - Legitimate package lifecycle scripts
  - Approved build automation
  - Developer tooling that uses shell, Node, Bun, or archive utilities during dependency installation
level: high
tags:
  - attack.t1059
  - attack.t1059.004
  - attack.t1195
  - attack.t1552
  - attack.t1105
  - attack.execution
  - attack.credential_access

SIGMA Rule 2

Bun or Node Execution from Dependency, Cache, Temporary, or CI Workspace Path

Rule Status

Production detection rule.

Rule Format

SIGMA rule format.

Detection Objective

Detect Bun or Node execution from dependency, package-cache, temporary, user-profile, or CI workspace paths where runtime execution is inconsistent with approved developer or build workflows.

Detection Logic

This rule detects abnormal runtime execution consistent with malicious dependency payload activity. It focuses on runtime execution from suspicious paths and package-install context rather than specific package names or hashes.

Required Telemetry

·        Endpoint process creation telemetry.

·        Process name.

·        Process command line.

·        Process executable path.

·        Parent process name.

·        Parent command line.

·        Working directory where available.

·        User identity.

·        Host identity.

·        Asset role or endpoint group where available.

Engineering Implementation Instructions

Engineers should baseline approved Bun and Node usage before production deployment. In environments where Bun is not approved, Bun execution from dependency, temporary, user-profile, or CI workspace paths should be treated as higher priority. In environments where Bun or Node usage is common, production alerting should require suspicious path context, package-manager ancestry, CI/CD runner context, or follow-on credential access in the backend SIEM.

Tiering Data

·        Tier 1: Hunt for Bun or Node execution from dependency, temporary, or CI workspace paths.

·        Tier 2: Add host role and approved runtime baselines.

·        Tier 3: Correlate translated SIGMA matches with credential-access telemetry, package-install logs, proxy logs, GitHub audit logs, and npm registry activity.

·        Tier 4: Add repository-specific runtime baselines, approved build-image context, runner identity, and release workflow context.

DRI Assessment

Detection Robustness Index

·        8.3

DRI Justification

The rule is anchored on abnormal runtime execution path and package-install context rather than static payload indicators. It remains resilient against package-name, filename, hash, and infrastructure changes, but it requires environment-specific baselining where Bun or Node usage is common.

TCR Assessment

Operational TCR

·        Moderate

Operational TCR Justification

Operational confidence depends on endpoint process telemetry, command-line logging, executable path visibility, and backend normalization. Confidence is reduced in environments where runtime usage is broad and asset role context is weak.

Full-Telemetry TCR

·        High

Full-Telemetry TCR Justification

With full process, command-line, executable path, parent-process, host-role, and runner-context telemetry, this rule provides strong portable detection of abnormal runtime execution from dependency and CI paths.

Limitations

·        Legitimate Node or Bun tooling may run from project or build directories.

·        Approved Bun environments require stronger baselines.

·        The rule should be correlated with credential access, package-install activity, or suspicious egress where available.

·        Backend mapping and path normalization are required before production deployment.

Detection Code

title: Bun or Node Execution from Dependency Cache Temporary or CI Workspace Path
id: 399c45ce-ef1c-4c18-8f35-75f49e119d43
status: experimental
description: Detects Bun or Node execution from dependency, cache, temporary, user-profile, or CI workspace paths associated with suspicious npm package execution behavior.
author: CyberDax
date: 2026/04/30
logsource:
  category: process_creation
detection:
  selection_runtime:
    Image|endswith:
      - '\bun.exe'
      - '\node.exe'
      - '/bun'
      - '/node'
  selection_path_image:
    Image|contains:
      - 'node_modules'
      - '.npm'
      - '.pnpm'
      - '\Temp\'
      - '/tmp/'
      - 'workspace'
      - 'actions-runner'
      - '_work'
      - '.cache'
  selection_path_cmd:
    CommandLine|contains:
      - 'setup.mjs'
      - 'preinstall'
      - 'postinstall'
      - 'node_modules'
      - '.npm'
      - '.pnpm'
      - '_work'
      - 'workspace'
  selection_parent_image:
    ParentImage|endswith:
      - '\npm.exe'
      - '\npm.cmd'
      - '\pnpm.exe'
      - '\pnpm.cmd'
      - '\yarn.exe'
      - '\yarn.cmd'
      - '/npm'
      - '/pnpm'
      - '/yarn'
  selection_parent_cmd:
    ParentCommandLine|contains:
      - 'npm install'
      - 'npm ci'
      - 'pnpm install'
      - 'yarn install'
      - 'preinstall'
      - 'postinstall'
  condition: selection_runtime and (selection_path_image or selection_path_cmd or selection_parent_image or selection_parent_cmd)
fields:
  - UtcTime
  - Computer
  - User
  - Image
  - CommandLine
  - ParentImage
  - ParentCommandLine
  - CurrentDirectory
falsepositives:
  - Approved Bun or Node usage in development workflows
  - Build tooling that executes from dependency or workspace paths
  - CI/CD jobs using approved runtime images
level: high
tags:
  - attack.t1059
  - attack.t1059.004
  - attack.t1195
  - attack.execution

SIGMA Rule 3

Credential File Access or Local Secret Staging by Package-Manager Descended Runtime

Rule Status

Conditional production detection rule.

Rule Format

SIGMA rule format.

Detection Objective

Detect suspicious access to developer, package-registry, cloud, repository, SSH, Kubernetes, Docker, or CI/CD credential material by package-manager-descended runtime or shell processes.

Detection Logic

This rule detects credential-access and local staging behavior after suspicious npm-related execution. It focuses on sensitive file paths and secret-like staging artifacts accessed or created by Bun, Node, shell, Python, or package-manager-descended processes.

This rule is conditional because production-quality precision depends on file events containing process context such as process image, process command line, parent image, or process GUID. Where file events lack process linkage, this rule should remain a hunt or should be correlated with recent process events in the backend SIEM.

Required Telemetry

·        Endpoint file access or file creation telemetry.

·        Process name associated with file event.

·        Process command line where available.

·        Parent process name where available.

·        File path.

·        User identity.

·        Host identity.

·        Asset role or endpoint group where available.

·        Process GUID or equivalent process linkage where available.

Engineering Implementation Instructions

Engineers should validate whether the backend log source supports process-linked file events. This rule is strongest where file events include process name, process command line, parent process, or process GUID context. Where file events lack process linkage, this rule should be deployed as a hunt or correlated with recent process events in the backend SIEM.

The rule should be scoped to developer endpoints, self-hosted CI/CD runners, release systems, and package-publishing systems. It should not alert on credential file access alone without suspicious process context or high-risk asset context.

Tiering Data

·        Tier 1: Deploy as a hunt for sensitive credential-path access on developer and CI/CD systems.

·        Tier 2: Enable conditional production alerting only where file events include process context.

·        Tier 3: Correlate with package lifecycle execution, GitHub audit activity, npm registry activity, proxy logs, and identity telemetry.

·        Tier 4: Add process GUID correlation, asset role context, repository context, approved tooling exceptions, and runner identity.

DRI Assessment

Detection Robustness Index

·        7.8

DRI Justification

The rule is anchored on credential-access and local staging behavior by suspicious package-manager-descended or runtime processes. It is resilient to package-name, filename, hash, and infrastructure changes, but its strength is conditional because reliable detection depends on process-linked file telemetry and high-risk asset scoping.

TCR Assessment

Operational TCR

·        Moderate when process-linked file telemetry is available.

·        Low to Moderate when file events are not process-linked.

Operational TCR Justification

Operational confidence depends on file access or creation telemetry with process context. Confidence is reduced when file events do not include process name, command line, parent process, or process GUID, or when secrets are exposed through environment variables without file access.

Full-Telemetry TCR

·        High

Full-Telemetry TCR Justification

With process-linked file events, command-line context, parent-process context, host role, and user identity, this rule can provide strong evidence of credential access or local staging after suspicious npm-related execution.

Limitations

·        This rule should not be enabled as a production detection unless process-linked file telemetry is validated.

·        Legitimate developer tools may read credential files.

·        File-event visibility and process linkage vary by backend and operating system.

·        Environment-variable-only credential access may not generate file events.

·        This rule should be correlated with lifecycle execution, runtime activity, or suspicious egress when available.

Detection Code

title: Credential File Access or Secret Staging by Package Manager Descended Runtime
id: 05d78369-85d8-4c04-a7a6-17c36f2ec8af
status: experimental
description: Detects access to developer, package-registry, cloud, repository, SSH, Kubernetes, Docker, or CI/CD credential material by package-manager-descended runtime or shell processes. Enable as production only where file events include reliable process context.
author: CyberDax
date: 2026/04/30
logsource:
  category: file_event
detection:
  selection_file_sensitive:
    TargetFilename|contains:
      - '.npmrc'
      - '.ssh'
      - 'id_rsa'
      - 'id_ed25519'
      - '.aws/credentials'
      - '.azure'
      - '.config/gcloud'
      - '.kube/config'
      - 'docker/config.json'
      - 'environment.json'
      - 'cloud.json'
      - 'data.json'
      - 'secrets'
      - 'token'
      - 'credential'
  selection_process_image:
    Image|endswith:
      - '\bun.exe'
      - '\node.exe'
      - '\npm.exe'
      - '\npm.cmd'
      - '\pnpm.exe'
      - '\pnpm.cmd'
      - '\yarn.exe'
      - '\yarn.cmd'
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\python.exe'
      - '/bun'
      - '/node'
      - '/npm'
      - '/pnpm'
      - '/yarn'
      - '/sh'
      - '/bash'
      - '/zsh'
      - '/python'
      - '/python3'
  selection_process_path:
    Image|contains:
      - 'node_modules'
      - '.npm'
      - '.pnpm'
      - '\Temp\'
      - '/tmp/'
      - 'workspace'
      - 'actions-runner'
      - '_work'
  selection_process_cmd:
    CommandLine|contains:
      - 'setup.mjs'
      - 'preinstall'
      - 'postinstall'
      - 'node_modules'
      - '.npm'
      - '.pnpm'
      - 'GITHUB_TOKEN'
      - 'npm_TOKEN'
      - 'AWS_ACCESS_KEY'
      - 'SECRET'
      - 'TOKEN'
  selection_parent:
    ParentImage|endswith:
      - '\npm.exe'
      - '\npm.cmd'
      - '\pnpm.exe'
      - '\pnpm.cmd'
      - '\yarn.exe'
      - '\yarn.cmd'
      - '/npm'
      - '/pnpm'
      - '/yarn'
  condition: selection_file_sensitive and selection_process_image and (selection_process_path or selection_process_cmd or selection_parent)
fields:
  - UtcTime
  - Computer
  - User
  - Image
  - CommandLine
  - ParentImage
  - ParentCommandLine
  - TargetFilename
falsepositives:
  - Legitimate developer tools reading local credential files
  - Approved cloud CLI, Kubernetes, Docker, Git, or package publishing workflows
  - Security scanners and secret-management tooling
level: high
tags:
  - attack.t1552
  - attack.t1552.001
  - attack.t1005
  - attack.t1195
  - attack.credential_access
  - attack.collection

YARA

Detection Viability Assessment

YARA is viable as a supplemental artifact-scanning layer for this incident, but it should not be treated as the primary detection mechanism.

The SAP-related npm package poisoning activity is best detected through behavior: package-manager lifecycle execution, runtime execution, credential access, GitHub and npm token abuse, cloud credential misuse, and suspicious egress. YARA can support repository scanning, package-cache review, artifact inspection, malware triage, internal npm mirror review, and retrospective exposure analysis.

YARA should be used to identify suspicious npm package artifacts that combine install-time execution logic, loader-style JavaScript behavior, runtime bootstrap behavior, developer or CI/CD secret-targeting indicators, and stronger exfiltration or staging context.

YARA Rule 1

Suspicious npm Package Loader with Developer Secret Targeting Indicators

Rule Status

Supplemental artifact detection rule.

Rule Format

YARA rule format.

Detection Objective

Detect suspicious npm package artifacts or extracted package contents containing install-time loader behavior and developer-secret targeting indicators consistent with npm supply-chain credential theft.

Detection Logic

This rule identifies suspicious package artifacts by combining npm lifecycle-script context, loader-style JavaScript behavior, runtime bootstrap indicators, developer or CI/CD secret-targeting strings, and stronger staging or exfiltration indicators.

The rule is intentionally supplemental. It should support exposure review and artifact triage, not replace endpoint, CI/CD, GitHub, npm registry, cloud, identity, or network detections.

Historical staging filenames such as environment.json, cloud.json, and data.json are included only as lineage and context indicators. They should not be treated as required current-campaign artifacts.

Required Telemetry and Data Sources

·        Extracted npm package contents.

·        Internal npm mirror contents.

·        Dependency cache contents.

·        CI/CD workspace artifacts.

·        Build artifacts.

·        Repository snapshots.

·        Package tarballs.

·        Malware triage samples.

·        Quarantined endpoint files where available.

Engineering Implementation Instructions

Engineers should run this rule against extracted package contents, package tarballs, internal npm mirrors, dependency caches, CI/CD workspaces, and build artifacts. The rule should be deployed as a scanning and triage control, not as a standalone production alert.

The rule should not be used to declare compromise by itself. A match should trigger package review, dependency exposure analysis, endpoint and CI/CD telemetry review, secret rotation assessment, and GitHub, npm, and cloud activity review.

Tiering Data

·        Tier 1: Use for manual triage of suspicious package artifacts, developer workspaces, and exposed dependency caches.

·        Tier 2: Add scheduled scanning of internal npm mirrors, dependency caches, and CI/CD artifact stores.

·        Tier 3: Correlate YARA matches with endpoint, CI/CD, GitHub, npm registry, proxy, DNS, and identity telemetry.

·        Tier 4: Integrate YARA scanning into package intake, internal mirror validation, build artifact review, and malware triage workflows.

DRI Assessment

Detection Robustness Index

·        7.5

DRI Justification

The rule has practical artifact-triage value because it requires multiple behavior-related indicator groups, including lifecycle execution, loader behavior, developer-secret targeting, and staging or stronger exfiltration context. Its robustness remains lower than behavior-based endpoint, SIEM, and cloud-control-plane detections because artifact strings and loader structure can change across variants.

TCR Assessment

Operational TCR

·        Moderate as an artifact-scanning control.

Operational TCR Justification

Operational confidence depends on access to extracted packages, package caches, internal mirrors, build artifacts, or suspicious files. YARA visibility is limited when malicious code executes only transiently, when artifacts are removed before scanning, or when payload content is fetched dynamically at runtime.

Full-Telemetry TCR

·        High for available artifacts.

Full-Telemetry TCR Justification

When extracted package contents, dependency caches, mirrors, and build artifacts are available for scanning, YARA can reliably support artifact triage and exposure review. It still cannot determine execution, credential theft, or downstream abuse without corroborating telemetry.

Limitations

·        YARA is static and variant-sensitive.

·        A match does not prove execution or credential theft.

·        Non-matching artifacts may still be malicious if strings are obfuscated, generated dynamically, encrypted, or fetched at runtime.

·        Historical staging filenames are lineage indicators only.

·        YARA should not replace endpoint, CI/CD, GitHub, npm registry, cloud, identity, or network detections.

·        This rule should be tuned against known legitimate internal packages to avoid false positives from benign secret-scanning, CI/CD, or build tooling.

Detection Code

rule CyberDax_SUP_SAP_npm_Suspicious_Loader_Secret_Targeting
{
    meta:
        description = "Detects suspicious npm package artifacts with install-time loader behavior and developer or CI/CD secret targeting indicators"
        author = "CyberDax"
        date = "2026-04-30"
        report_type = "SUP"
        scope = "supplemental artifact triage"
        severity = "medium"

    strings:
        $npm_lifecycle_1 = "\"preinstall\"" ascii nocase
        $npm_lifecycle_2 = "\"postinstall\"" ascii nocase
        $npm_lifecycle_3 = "npm_lifecycle_event" ascii nocase
        $npm_lifecycle_4 = "setup.mjs" ascii nocase
        $npm_lifecycle_5 = "\"scripts\"" ascii nocase

        $runtime_1 = "Bun.write" ascii nocase
        $runtime_2 = "bun install" ascii nocase
        $runtime_3 = "bun run" ascii nocase
        $runtime_4 = "curl " ascii nocase
        $runtime_5 = "wget " ascii nocase
        $runtime_6 = "chmod +x" ascii nocase

        $loader_1 = "child_process" ascii nocase
        $loader_2 = "execSync" ascii nocase
        $loader_3 = "spawnSync" ascii nocase
        $loader_4 = "import(" ascii nocase
        $loader_5 = "Buffer.from" ascii nocase
        $loader_6 = "atob(" ascii nocase
        $loader_7 = "base64" ascii nocase
        $loader_8 = "require(\"fs\")" ascii nocase
        $loader_9 = "require('fs')" ascii nocase

        $secret_1 = "GITHUB_TOKEN" ascii nocase
        $secret_2 = "npm_TOKEN" ascii nocase
        $secret_3 = "AWS_ACCESS_KEY_ID" ascii nocase
        $secret_4 = "AWS_SECRET_ACCESS_KEY" ascii nocase
        $secret_5 = "AZURE_CLIENT_SECRET" ascii nocase
        $secret_6 = "GOOGLE_APPLICATION_CREDENTIALS" ascii nocase
        $secret_7 = "KUBECONFIG" ascii nocase
        $secret_8 = ".npmrc" ascii nocase
        $secret_9 = "id_rsa" ascii nocase
        $secret_10 = "id_ed25519" ascii nocase
        $secret_11 = ".kube/config" ascii nocase
        $secret_12 = "docker/config.json" ascii nocase
        $secret_13 = ".aws/credentials" ascii nocase
        $secret_14 = ".config/gcloud" ascii nocase

        $staging_1 = "environment.json" ascii nocase
        $staging_2 = "cloud.json" ascii nocase
        $staging_3 = "data.json" ascii nocase
        $staging_4 = "truffleSecrets.json" ascii nocase
        $staging_5 = "JSON.stringify(process.env" ascii nocase
        $staging_6 = "process.env" ascii nocase

        $exfil_strong_1 = "api.github.com/user/repos" ascii nocase
        $exfil_strong_2 = "/user/repos" ascii nocase
        $exfil_strong_3 = "Authorization" ascii nocase
        $exfil_strong_4 = "Bearer " ascii nocase
        $exfil_strong_5 = "createCipheriv" ascii nocase
        $exfil_strong_6 = "crypto.subtle" ascii nocase
        $exfil_strong_7 = "encrypt(" ascii nocase

        $exfil_weak_1 = "api.github.com" ascii nocase
        $exfil_weak_2 = "webhook" ascii nocase
        $exfil_weak_3 = "fetch(" ascii nocase

    condition:
        uint16(0) != 0x5a4d and
        filesize < 5MB and
        (
            1 of ($npm_lifecycle_*) and
            2 of ($loader_*) and
            3 of ($secret_*) and
            (
                1 of ($runtime_*) or
                1 of ($staging_*) or
                2 of ($exfil_strong_*) or
                (
                    1 of ($exfil_strong_*) and
                    1 of ($exfil_weak_*)
                )
            )
        )
}

YARA Final Disposition

YARA is selected for S25 as one supplemental artifact detection rule.

YARA should be used for package artifact triage, internal npm mirror review, dependency-cache scanning, repository inspection, build artifact review, and malware sample analysis. It should not be used as a standalone production detection for execution, credential theft, exfiltration, or downstream token abuse.

AWS

Detection Viability Assessment

AWS is viable for S25 as a downstream credential-abuse detection layer.

AWS should not be used to detect the initial npm package execution path. AWS telemetry will not directly observe package-manager lifecycle execution, Bun or Node runtime behavior, local credential access, or developer workstation staging. AWS detection should instead focus on post-compromise use of stolen cloud credentials, access keys, workload identities, CI/CD deployment identities, and secret-management privileges.

The strongest AWS detections for this incident are cloud-native rules that identify sensitive IAM, STS, Secrets Manager, SSM Parameter Store, ECR, CodeBuild, CodePipeline, Lambda, S3 artifact, and KMS activity by identities connected to developer, CI/CD, package-publishing, build, release, or deployment workflows.

The identity filters shown in the AWS queries are placeholders. Production deployment must replace broad ARN string matching with organization-specific identity mappings such as IAM paths, principal tags, account tags, role inventory, CI/CD role lists, deployment-role lists, package-publishing identities, workload identity mappings, or SIEM lookup tables.

AWS Rule 1

Developer or CI/CD Identity Performs Sensitive IAM or Access-Key Activity

Rule Status

Production detection rule.

Rule Format

AWS CloudTrail Lake SQL detection query.

Detection Objective

Detect sensitive IAM, access-key, role, policy, or privilege-modification activity performed by developer, CI/CD, package-publishing, build, release, automation, or deployment identities that may have been exposed through poisoned npm package execution.

Detection Logic

This rule detects downstream cloud-control-plane activity consistent with stolen credential use, privilege expansion, persistence setup, role manipulation, or access-key abuse. It focuses on sensitive IAM and STS actions by identities commonly connected to developer workflows, CI/CD pipelines, package publishing, release systems, or deployment automation.

This rule does not claim visibility into local npm package execution. It detects suspicious AWS control-plane behavior that may follow developer or CI/CD credential exposure.

Required Telemetry

·        AWS CloudTrail management events.

·        IAM events.

·        STS events.

·        Access-key events.

·        User identity fields.

·        Source IP address.

·        User agent.

·        AWS account identifier.

·        Role ARN, user ARN, or assumed-role ARN.

·        Session issuer context where available.

·        Event source and event name.

·        Error code and result status.

·        Identity tags, account tags, IAM path context, or external identity inventory where available.

Engineering Implementation Instructions

Engineers should deploy this rule against AWS accounts connected to development, CI/CD, package publishing, artifact handling, release automation, staging, and production deployment workflows.

The placeholder identity filters in the query must be replaced with customer-specific identity scoping. Acceptable scoping inputs include approved developer roles, CI/CD roles, package-publishing roles, deployment roles, workload identities, IAM paths, IAM principal tags, account tags, AWS Organizations account metadata, or SIEM lookup tables.

Production alerting should prioritize sensitive IAM and access-key activity from unexpected source IPs, unusual user agents, unusual regions, unusual session contexts, new role sessions, identities outside approved release windows, or identities recently associated with developer or CI/CD exposure.

Tiering Data

·        Tier 1: Hunt for sensitive IAM and access-key activity by developer, CI/CD, package-publishing, and deployment identities after package exposure.

·        Tier 2: Add identity role tagging for developers, automation users, CI/CD roles, package-publishing roles, build roles, release roles, and deployment roles.

·        Tier 3: Correlate CloudTrail findings with endpoint, CI/CD, GitHub, npm registry, identity, DNS, and proxy telemetry.

·        Tier 4: Add normal source IP, user-agent, release-window, workload identity, account-criticality, repository, artifact, and deployment-environment baselines.

DRI Assessment

Detection Robustness Index

·        8.3

DRI Justification

The rule is behaviorally anchored on sensitive AWS identity and access-management actions that are relevant to downstream credential misuse. It does not depend on npm package names, payload filenames, hashes, or attacker infrastructure. It remains useful when attackers change package artifacts because stolen cloud credentials still require AWS API use to modify access, create persistence, assume roles, retrieve session credentials, or escalate privileges.

TCR Assessment

Operational TCR

·        Moderate to High

Operational TCR Justification

Operational confidence depends on CloudTrail coverage, management-event retention, identity tagging, account coverage, source IP visibility, user-agent visibility, and whether developer or CI/CD identities are distinguishable from normal cloud automation. Confidence is reduced when CloudTrail is incomplete or identities are not mapped to development and deployment workflows.

Full-Telemetry TCR

·        High

Full-Telemetry TCR Justification

With complete CloudTrail management events, identity context, account coverage, source IP, user agent, IAM path or tag mapping, and role-session metadata, AWS can reliably detect sensitive IAM and access-key activity by exposed or suspicious developer and CI/CD identities.

Limitations

·        This rule detects downstream AWS credential abuse, not initial npm package execution.

·        Legitimate cloud administration may perform IAM and access-key operations.

·        Placeholder identity matching must be replaced with organization-specific identity mapping.

·        Identity role tagging, source context, and release-window context are required to reduce noise.

·        The original credential-theft method may not be provable from AWS telemetry alone.

Detection Code

-- AWS CloudTrail Lake SQL
-- Detect sensitive IAM, STS, and access-key activity by mapped developer, CI/CD,
-- package-publishing, build, release, automation, or deployment identities.
-- Replace <event_data_store_id> and placeholder identity filters with environment-specific
-- identity mappings such as IAM paths, principal tags, account tags, approved role lists,
-- AWS Organizations account metadata, or SIEM lookup-table joins.

SELECT
  eventTime,
  recipientAccountId,
  awsRegion,
  eventSource,
  eventName,
  userIdentity.type,
  userIdentity.arn,
  userIdentity.sessionContext.sessionIssuer.arn,
  sourceIPAddress,
  userAgent,
  errorCode,
  errorMessage,
  requestParameters
FROM <event_data_store_id>
WHERE
  eventSource IN ('iam.amazonaws.com', 'sts.amazonaws.com')
  AND eventName IN (
    'CreateAccessKey',
    'UpdateAccessKey',
    'DeleteAccessKey',
    'CreateUser',
    'CreateRole',
    'UpdateAssumeRolePolicy',
    'PutUserPolicy',
    'PutRolePolicy',
    'AttachUserPolicy',
    'AttachRolePolicy',
    'CreatePolicy',
    'CreatePolicyVersion',
    'SetDefaultPolicyVersion',
    'AddUserToGroup',
    'CreateLoginProfile',
    'UpdateLoginProfile',
    'AssumeRole',
    'GetSessionToken'
  )
  AND (
    -- Placeholder identity scoping. Replace with customer-specific identity mappings.
    LOWER(userIdentity.arn) LIKE '%developer%'
    OR LOWER(userIdentity.arn) LIKE '%ci%'
    OR LOWER(userIdentity.arn) LIKE '%cd%'
    OR LOWER(userIdentity.arn) LIKE '%build%'
    OR LOWER(userIdentity.arn) LIKE '%deploy%'
    OR LOWER(userIdentity.arn) LIKE '%release%'
    OR LOWER(userIdentity.arn) LIKE '%package%'
    OR LOWER(userIdentity.sessionContext.sessionIssuer.arn) LIKE '%developer%'
    OR LOWER(userIdentity.sessionContext.sessionIssuer.arn) LIKE '%ci%'
    OR LOWER(userIdentity.sessionContext.sessionIssuer.arn) LIKE '%cd%'
    OR LOWER(userIdentity.sessionContext.sessionIssuer.arn) LIKE '%build%'
    OR LOWER(userIdentity.sessionContext.sessionIssuer.arn) LIKE '%deploy%'
    OR LOWER(userIdentity.sessionContext.sessionIssuer.arn) LIKE '%release%'
    OR LOWER(userIdentity.sessionContext.sessionIssuer.arn) LIKE '%package%'
  )
  AND (
    errorCode IS NULL
    OR errorCode = ''
  )
ORDER BY eventTime DESC;

AWS Rule 2

Developer or CI/CD Identity Accesses Secrets, Artifacts, Registry, or Build Services from Suspicious Context

Rule Status

Conditional production detection rule.

Rule Format

AWS CloudTrail Lake SQL detection query.

Detection Objective

Detect suspicious access to AWS Secrets Manager, Systems Manager Parameter Store, ECR, CodeBuild, CodePipeline, Lambda, S3 artifact locations, or KMS by developer, CI/CD, package-publishing, build, release, automation, or deployment identities after potential developer ecosystem compromise.

Detection Logic

This rule detects downstream use of stolen AWS credentials to access secrets, retrieve deployment material, modify build or deployment paths, interact with container registries, decrypt protected material, or access cloud artifacts.

This rule is conditional because many of the observed services and API actions are normal in legitimate CI/CD and release workflows. Production use requires suspicious context such as unusual source IP, unusual user agent, unexpected region, unexpected release window, unapproved role session, sensitive account, sensitive resource, new identity behavior, or recent developer or CI/CD exposure context.

This rule does not claim visibility into local npm package execution. It detects suspicious AWS service use that may follow credential theft from a developer workstation, CI/CD runner, package-publishing system, or poisoned dependency execution path.

Required Telemetry

·        AWS CloudTrail management events.

·        AWS CloudTrail data events where enabled for S3, Secrets Manager, KMS, and other critical services.

·        Secrets Manager events.

·        Systems Manager Parameter Store events.

·        ECR events.

·        CodeBuild and CodePipeline events.

·        Lambda events.

·        S3 object-level events for artifact buckets where enabled.

·        KMS events.

·        Source IP address.

·        User agent.

·        Identity ARN and session issuer ARN.

·        Resource ARN or request parameters.

·        Account and region context.

·        Identity tags, account tags, resource tags, or external identity inventory where available.

Engineering Implementation Instructions

Engineers should deploy this rule across AWS accounts connected to CI/CD, artifact storage, package publishing, container registry, staging, and production deployment. Data events should be enabled for critical artifact buckets, secret stores, and encryption workflows where feasible.

The placeholder identity filters in the query must be replaced with customer-specific identity scoping. Production enablement also requires suspicious context baselines. These should include approved source networks, expected user agents, normal regions, release windows, deployment windows, sensitive accounts, sensitive resources, role-session patterns, repository-to-role mappings, artifact-bucket mappings, and package-publishing workflows.

This rule should remain a hunt or conditional production detection until those context fields and baselines are validated.

Tiering Data

·        Tier 1: Hunt for secret access, artifact access, registry access, and build-service activity by exposed developer or CI/CD identities.

·        Tier 2: Add tagging for artifact buckets, secret stores, CI/CD roles, deployment roles, build roles, release roles, and package-publishing roles.

·        Tier 3: Correlate AWS findings with endpoint, CI/CD, GitHub, npm registry, identity, DNS, proxy, and artifact telemetry.

·        Tier 4: Add approved release-window, source-network, user-agent, workload identity, repository, artifact, deployment-environment, and account-criticality baselines.

DRI Assessment

Detection Robustness Index

·        7.8

DRI Justification

The rule is behaviorally anchored on sensitive AWS service access that may follow developer or CI/CD credential theft. It detects access to secrets, artifact repositories, build services, encryption services, and deployment pathways rather than relying on static payload indicators. The score is lower than AWS Rule 1 because production precision depends heavily on suspicious source context, release-process baselines, resource tagging, and data-event coverage.

TCR Assessment

Operational TCR

·        Moderate when suspicious source, identity, resource, and release-context baselines are available.

·        Low to Moderate when those baselines or data events are unavailable.

Operational TCR Justification

Operational confidence depends on CloudTrail management-event coverage, data-event enablement for relevant services, identity context, source IP visibility, user-agent visibility, resource tagging, and release-process baselines. Confidence is reduced where S3 object-level logging, secret-store data events, KMS context, or build-service audit visibility is incomplete.

Full-Telemetry TCR

·        High

Full-Telemetry TCR Justification

With complete CloudTrail management and data events, identity tagging, resource tagging, source IP context, user-agent context, CI/CD workflow mapping, and release-process baselines, AWS can reliably detect suspicious secret, artifact, registry, encryption, and build-service access after developer or CI/CD exposure.

Limitations

·        This rule detects downstream AWS activity, not local npm package execution.

·        Legitimate CI/CD and deployment automation may access secrets, registries, artifacts, KMS, and build services.

·        Service-specific logging and data events may not be enabled by default.

·        This rule should not be enabled as unconditional production alerting without suspicious context baselines.

·        Account-specific release and deployment baselines are required to reduce false positives.

Detection Code

-- AWS CloudTrail Lake SQL
-- Conditional production detection for sensitive secrets, artifact, registry,
-- encryption, and build/deployment activity by mapped developer, CI/CD, package-publishing,
-- build, release, automation, or deployment identities.
-- Replace <event_data_store_id>, identity filters, source-context filters, and resource
-- patterns with environment-specific mappings and baselines before production deployment.

SELECT
  eventTime,
  recipientAccountId,
  awsRegion,
  eventSource,
  eventName,
  userIdentity.type,
  userIdentity.arn,
  userIdentity.sessionContext.sessionIssuer.arn,
  sourceIPAddress,
  userAgent,
  requestParameters,
  resources,
  errorCode,
  errorMessage
FROM <event_data_store_id>
WHERE
  eventSource IN (
    'secretsmanager.amazonaws.com',
    'ssm.amazonaws.com',
    'ecr.amazonaws.com',
    'codebuild.amazonaws.com',
    'codepipeline.amazonaws.com',
    'lambda.amazonaws.com',
    's3.amazonaws.com',
    'kms.amazonaws.com'
  )
  AND eventName IN (
    'GetSecretValue',
    'BatchGetSecretValue',
    'PutSecretValue',
    'CreateSecret',
    'UpdateSecret',
    'DeleteSecret',
    'GetParameter',
    'GetParameters',
    'GetParametersByPath',
    'PutParameter',
    'BatchGetImage',
    'GetAuthorizationToken',
    'PutImage',
    'StartBuild',
    'UpdateProject',
    'CreateProject',
    'StartPipelineExecution',
    'UpdatePipeline',
    'CreatePipeline',
    'UpdateFunctionCode',
    'CreateFunction',
    'PutObject',
    'GetObject',
    'CopyObject',
    'Decrypt',
    'GenerateDataKey'
  )
  AND (
    -- Placeholder identity scoping. Replace with customer-specific identity mappings.
    LOWER(userIdentity.arn) LIKE '%developer%'
    OR LOWER(userIdentity.arn) LIKE '%ci%'
    OR LOWER(userIdentity.arn) LIKE '%cd%'
    OR LOWER(userIdentity.arn) LIKE '%build%'
    OR LOWER(userIdentity.arn) LIKE '%deploy%'
    OR LOWER(userIdentity.arn) LIKE '%release%'
    OR LOWER(userIdentity.arn) LIKE '%package%'
    OR LOWER(userIdentity.sessionContext.sessionIssuer.arn) LIKE '%developer%'
    OR LOWER(userIdentity.sessionContext.sessionIssuer.arn) LIKE '%ci%'
    OR LOWER(userIdentity.sessionContext.sessionIssuer.arn) LIKE '%cd%'
    OR LOWER(userIdentity.sessionContext.sessionIssuer.arn) LIKE '%build%'
    OR LOWER(userIdentity.sessionContext.sessionIssuer.arn) LIKE '%deploy%'
    OR LOWER(userIdentity.sessionContext.sessionIssuer.arn) LIKE '%release%'
    OR LOWER(userIdentity.sessionContext.sessionIssuer.arn) LIKE '%package%'
  )
  AND (
    -- Suspicious context placeholder. Replace with customer-specific baselines.
    -- Examples include non-approved source networks, unusual user agents,
    -- unexpected regions, sensitive accounts, sensitive resources, off-window activity,
    -- or identities recently associated with developer or CI/CD exposure.
    sourceIPAddress NOT LIKE '10.%'
    OR userAgent NOT LIKE '%aws-cli%'
    OR awsRegion NOT IN ('us-east-1', 'us-west-2')
  )
  AND (
    errorCode IS NULL
    OR errorCode = ''
  )
ORDER BY eventTime DESC;

Cloud-Native Detection Opportunities

Conditional

AWS may also support conditional cloud-native detection opportunities when additional context is available.

Examples include:

·        CloudTrail activity by developer or CI/CD identities from new source networks, new geographies, unusual user agents, or unexpected AWS regions.

·        Access-key use shortly after developer endpoint, CI/CD runner, GitHub, or npm exposure indicators.

·        Secrets Manager, SSM Parameter Store, ECR, CodeBuild, CodePipeline, Lambda, S3, KMS, or deployment activity outside approved release windows.

·        IAM, STS, or Secrets Manager events correlated with GitHub workflow changes, npm publishing activity, or exposed package-install windows.

These opportunities should be implemented only when identity, source, workflow, release-process, account, and resource context are available.

Azure

Detection Viability Assessment

Azure is viable for S25 as a downstream credential-abuse and identity-control-plane detection layer.

Azure should not be used to detect the initial npm package execution path. Azure telemetry will not directly observe package-manager lifecycle execution, Bun or Node runtime behavior, local developer credential access, or CI/CD runner staging unless those systems also forward endpoint or pipeline telemetry into the same analytics environment. Azure detection should instead focus on post-compromise use of stolen cloud credentials, service principals, workload identities, app credentials, CI/CD deployment identities, Key Vault access, and control-plane privileges.

The strongest Azure detections for this incident are cloud-native rules that identify sensitive Microsoft Entra ID, service principal, app credential, role assignment, Key Vault, container registry, build, deployment, and workload identity activity by identities connected to developer, CI/CD, package-publishing, build, release, or deployment workflows.

The identity and context filters shown in the Azure queries are placeholders. Production deployment must replace broad identity string matching and watchlist names with organization-specific identity mappings such as Entra group membership, service principal inventory, workload identity mappings, managed identity inventory, app registration ownership, subscription tags, resource group tags, CI/CD identity lists, deployment-role lists, or Microsoft Sentinel watchlists.

Azure Rule 1

Developer or CI/CD Identity Performs Sensitive Entra ID, App Credential, or Role Assignment Activity

Rule Status

Production detection rule.

Rule Format

Microsoft Sentinel KQL detection query.

Detection Objective

Detect sensitive Microsoft Entra ID, app credential, service principal, managed identity, role assignment, or privilege-modification activity performed by developer, CI/CD, package-publishing, build, release, automation, or deployment identities that may have been exposed through poisoned npm package execution.

Detection Logic

This rule detects downstream Azure identity and control-plane activity consistent with stolen credential use, privilege expansion, persistence setup, app credential manipulation, service principal abuse, managed identity manipulation, or role assignment abuse.

This rule focuses on sensitive Entra ID and Azure Resource Manager actions by identities commonly connected to developer workflows, CI/CD pipelines, package publishing, release systems, or deployment automation. It does not claim visibility into local npm package execution.

Required Telemetry

·        Microsoft Entra ID audit logs.

·        Microsoft Entra ID sign-in logs where available.

·        Azure Activity logs.

·        Service principal and app registration events.

·        Role assignment and role definition events.

·        Managed identity events where available.

·        User and service principal identity fields.

·        Initiating user or app context.

·        Source IP address.

·        User agent where available.

·        Tenant, subscription, and resource group context.

·        Operation name and result status.

·        Conditional Access, sign-in, and authentication context where available.

·        Identity tags, group membership, app ownership, or external identity inventory where available.

Engineering Implementation Instructions

Engineers should deploy this rule against Azure tenants, subscriptions, and management groups connected to development, CI/CD, package publishing, artifact handling, release automation, staging, and production deployment workflows.

The placeholder identity filters in the query must be replaced with customer-specific identity scoping. Acceptable scoping inputs include approved developer groups, CI/CD service principals, managed identities, workload identities, package-publishing identities, deployment roles, app registration ownership, Entra group membership, subscription tags, resource group tags, or Microsoft Sentinel watchlists.

Production alerting should prioritize sensitive Entra ID, app credential, service principal, managed identity, and role-assignment activity from unexpected source IPs, unusual user agents, unusual tenants or subscriptions, unusual sign-in contexts, off-window release timing, or identities recently associated with developer or CI/CD exposure.

Tiering Data

·        Tier 1: Hunt for sensitive Entra ID, app credential, service principal, and role-assignment activity by developer, CI/CD, package-publishing, and deployment identities after package exposure.

·        Tier 2: Add identity role tagging for developers, automation users, CI/CD service principals, managed identities, package-publishing identities, build roles, release roles, and deployment roles.

·        Tier 3: Correlate Azure findings with endpoint, CI/CD, GitHub, npm registry, identity, DNS, and proxy telemetry.

·        Tier 4: Add normal source IP, user-agent, Conditional Access, release-window, workload identity, subscription-criticality, repository, artifact, and deployment-environment baselines.

DRI Assessment

Detection Robustness Index

·        8.3

DRI Justification

The rule is behaviorally anchored on sensitive Azure identity and access-management actions that are relevant to downstream credential misuse. It does not depend on npm package names, payload filenames, hashes, or attacker infrastructure. It remains useful when attackers change package artifacts because stolen Azure credentials, app credentials, service principal credentials, or managed identity access still require control-plane use to create persistence, add credentials, modify privileges, assign roles, or alter identity access.

TCR Assessment

Operational TCR

·        Moderate to High

Operational TCR Justification

Operational confidence depends on Entra ID audit logs, Azure Activity logs, sign-in context, identity tagging, tenant and subscription coverage, source IP visibility, user-agent visibility, and whether developer or CI/CD identities are distinguishable from normal automation. Confidence is reduced when identity logs are incomplete or service principals and managed identities are not mapped to development and deployment workflows.

Full-Telemetry TCR

·        High

Full-Telemetry TCR Justification

With complete Entra ID audit logs, Azure Activity logs, identity context, tenant and subscription coverage, source IP, user agent, Conditional Access context, and service principal or managed identity mapping, Azure can reliably detect sensitive identity and role activity by exposed or suspicious developer and CI/CD identities.

Limitations

·        This rule detects downstream Azure credential or identity abuse, not initial npm package execution.

·        Legitimate cloud administration may perform app credential, service principal, managed identity, and role-assignment operations.

·        Placeholder identity matching must be replaced with organization-specific identity mapping.

·        Identity role tagging, source context, Conditional Access context, tenant context, subscription context, and release-window context are required to reduce noise.

·        The original credential-theft method may not be provable from Azure telemetry alone.

Detection Code

// Microsoft Sentinel KQL
// Detect sensitive Entra ID, app credential, service principal, managed identity,
// and Azure role-assignment activity by mapped developer, CI/CD, package-publishing,
// build, release, automation, or deployment identities.
// Replace placeholder identity filters with organization-specific mappings such as
// Entra groups, service principal inventory, managed identity inventory, subscription tags,
// resource group tags, deployment-role lists, or Sentinel watchlists.

let SensitiveAadOps = dynamic([
    "Add service principal credentials",
    "Update application",
    "Add app role assignment to service principal",
    "Add delegated permission grant",
    "Consent to application",
    "Add owner to application",
    "Add owner to service principal",
    "Add member to role",
    "Add member to group",
    "Update service principal",
    "Add application",
    "Add service principal"
]);
let SensitiveAzureOps = dynamic([
    "Microsoft.Authorization/roleAssignments/write",
    "Microsoft.Authorization/roleDefinitions/write",
    "Microsoft.ManagedIdentity/userAssignedIdentities/write",
    "Microsoft.ManagedIdentity/userAssignedIdentities/assign/action",
    "Microsoft.Resources/deployments/write"
]);
let IdentityScopeTerms = dynamic([
    "developer",
    "dev",
    "ci",
    "cd",
    "build",
    "deploy",
    "release",
    "package",
    "pipeline",
    "automation"
]);
let AADSignals =
    AuditLogs
    | where TimeGenerated > ago(1h)
    | where OperationName in~ (SensitiveAadOps)
    | extend InitiatingIdentity = tostring(coalesce(
        InitiatedBy.user.userPrincipalName,
InitiatedBy.app.displayName,
InitiatedBy.app.servicePrincipalId
      ))
    | extend TargetResourcesText = tostring(TargetResources)
    | extend SourceIP = tostring(InitiatedBy.user.ipAddress)
    | extend UserAgent = tostring(AdditionalDetails)
    | where Result =~ "success" or isempty(Result)
    | where InitiatingIdentity has_any (IdentityScopeTerms)
        or TargetResourcesText has_any (IdentityScopeTerms)
    | project
        TimeGenerated,
        Source = "EntraID",
        OperationName,
        InitiatingIdentity,
        SourceIP,
        UserAgent,
        TargetResourcesText,
        Result;
let AzureActivitySignals =
    AzureActivity
    | where TimeGenerated > ago(1h)
    | where OperationNameValue in~ (SensitiveAzureOps)
    | extend InitiatingIdentity = tostring(coalesce(Caller, CallerIpAddress))
    | extend SourceIP = tostring(CallerIpAddress)
    | where ActivityStatusValue =~ "Success" or ActivityStatus =~ "Succeeded"
    | where InitiatingIdentity has_any (IdentityScopeTerms)
        or ResourceGroup has_any (IdentityScopeTerms)
        or Resource has_any (IdentityScopeTerms)
        or SubscriptionId has_any (IdentityScopeTerms)
    | project
        TimeGenerated,
        Source = "AzureActivity",
        OperationName = OperationNameValue,
        InitiatingIdentity,
        SourceIP,
        UserAgent = tostring(Claims),
        TargetResourcesText = strcat(ResourceGroup, "/", Resource, "/", ResourceId),
        Result = ActivityStatusValue;
AADSignals
| union AzureActivitySignals
| order by TimeGenerated desc

Azure Rule 2

Developer or CI/CD Identity Accesses Key Vault, Registry, Artifact, or Deployment Services from Suspicious Context

Rule Status

Conditional production detection rule.

Rule Format

Microsoft Sentinel KQL detection query.

Detection Objective

Detect suspicious access to Azure Key Vault, Azure Container Registry, storage artifacts, managed identities, build resources, or deployment infrastructure by developer, CI/CD, package-publishing, build, release, automation, or deployment identities after potential developer ecosystem compromise.

Detection Logic

This rule detects downstream use of stolen Azure credentials, service principal credentials, managed identities, or workload identity material to access secrets, retrieve deployment material, modify build or deployment paths, interact with container registries, manipulate managed identities, or access cloud artifacts.

This rule is conditional because many of the observed Azure services and operations are normal in legitimate CI/CD and release workflows. Production use requires suspicious context such as unapproved source network, unapproved automation identity, sensitive subscription, sensitive resource group, sensitive resource, recent developer or CI/CD exposure context, or validated release-process deviation.

This rule does not claim visibility into local npm package execution. It detects suspicious Azure service use that may follow credential theft from a developer workstation, CI/CD runner, package-publishing system, or poisoned dependency execution path.

Required Telemetry

·        Azure Activity logs.

·        Microsoft Entra ID sign-in logs.

·        Microsoft Entra ID audit logs.

·        Azure Key Vault diagnostic logs.

·        Azure Container Registry logs.

·        Azure DevOps or GitHub Actions logs where available.

·        Storage account logs for artifact locations where enabled.

·        Managed identity and workload identity events where available.

·        Source IP address.

·        User agent.

·        Identity, app, service principal, managed identity, or workload identity context.

·        Resource ID, resource group, subscription, tenant, and region context.

·        Resource tags, account tags, or external identity inventory where available.

·        Customer-defined Microsoft Sentinel watchlists for approved source networks, approved automation identities, approved release windows, sensitive subscriptions, sensitive resource groups, sensitive resources, and recent developer or CI/CD exposure.

Engineering Implementation Instructions

Engineers should deploy this rule across Azure tenants, subscriptions, and resource groups connected to CI/CD, artifact storage, package publishing, container registry, staging, and production deployment. Diagnostic logs should be enabled for critical Key Vaults, container registries, storage accounts, and deployment resources where feasible.

The placeholder identity and suspicious-context filters in the query must be replaced with customer-specific identity scoping and Microsoft Sentinel watchlists. Production enablement requires validated baseline inputs, including approved source networks, approved automation identities, approved user agents where available, normal regions, approved release windows, deployment windows, sensitive subscriptions, sensitive resource groups, sensitive Key Vaults, sensitive registries, managed identity mappings, repository-to-identity mappings, and package-publishing workflows.

This rule should remain a hunt or conditional production detection until those context fields and baselines are validated.

Tiering Data

·        Tier 1: Hunt for Key Vault access, registry access, artifact access, managed identity activity, and build or deployment activity by exposed developer or CI/CD identities.

·        Tier 2: Add watchlists for approved source networks, automation identities, release windows, sensitive subscriptions, sensitive resource groups, Key Vaults, registries, and package-publishing identities.

·        Tier 3: Correlate Azure findings with endpoint, CI/CD, GitHub, npm registry, identity, DNS, proxy, and artifact telemetry.

·        Tier 4: Add repository-to-identity mapping, workload identity mapping, deployment environment context, Conditional Access context, and recent developer or CI/CD exposure context.

DRI Assessment

Detection Robustness Index

·        7.8

DRI Justification

The rule is behaviorally anchored on sensitive Azure service access that may follow developer or CI/CD credential theft. It detects access to secrets, registries, deployment resources, managed identities, storage artifacts, and build pathways rather than relying on static payload indicators. The score is lower than Azure Rule 1 because production precision depends heavily on suspicious source context, release-process baselines, resource tagging, Conditional Access context, and diagnostic log coverage.

TCR Assessment

Operational TCR

·        Moderate when suspicious source, identity, resource, Conditional Access, and release-context baselines are available.

·        Low to Moderate when those baselines or diagnostic logs are unavailable.

Operational TCR Justification

Operational confidence depends on Azure Activity coverage, Key Vault diagnostic logging, container registry logging, storage logging, Entra ID sign-in and audit context, identity mapping, source IP visibility, user-agent visibility, resource tagging, Conditional Access context, watchlist quality, and release-process baselines. Confidence is reduced where Key Vault diagnostics, storage logs, registry logs, build/deployment audit visibility, or baseline watchlists are incomplete.

Full-Telemetry TCR

·        High

Full-Telemetry TCR Justification

With complete Azure Activity, Entra ID, Key Vault, container registry, storage, identity, and CI/CD telemetry, plus validated watchlists for approved source networks, approved automation identities, sensitive resources, Conditional Access context, and release-process baselines, Azure can reliably detect suspicious secret, registry, artifact, identity, and build/deployment access after developer or CI/CD exposure.

Limitations

·        This rule detects downstream Azure activity, not local npm package execution.

·        Legitimate CI/CD and deployment automation may access Key Vaults, registries, storage artifacts, managed identities, and deployment resources.

·        Service-specific diagnostic logging may not be enabled by default.

·        This rule should not be enabled as unconditional production alerting without suspicious context baselines and validated watchlists.

·        Watchlist names, schemas, and join keys must be adapted to each Microsoft Sentinel environment.

·        Subscription-specific release and deployment baselines are required to reduce false positives.

Detection Code

// Microsoft Sentinel KQL
// Conditional production detection for sensitive Key Vault, container registry,
// artifact, identity, and build/deployment activity by mapped developer, CI/CD,
// package-publishing, build, release, automation, or deployment identities.
//
// This query uses Sentinel watchlist arrays and membership/IP-range checks.
// Replace watchlist names, schemas, and join keys with environment-specific mappings
// before production deployment.

let IdentityScopeTerms = dynamic([
    "developer",
    "dev",
    "ci",
    "cd",
    "build",
    "deploy",
    "release",
    "package",
    "pipeline",
    "automation"
]);
let SensitiveAzureActivityOps = dynamic([
    "Microsoft.KeyVault/vaults/secrets/read",
    "Microsoft.KeyVault/vaults/secrets/write",
    "Microsoft.KeyVault/vaults/keys/read",
    "Microsoft.KeyVault/vaults/keys/write",
    "Microsoft.ContainerRegistry/registries/write",
    "Microsoft.ContainerRegistry/registries/pull/read",
    "Microsoft.ContainerRegistry/registries/push/write",
    "Microsoft.ManagedIdentity/userAssignedIdentities/write",
    "Microsoft.ManagedIdentity/userAssignedIdentities/assign/action",
    "Microsoft.Resources/deployments/write",
    "Microsoft.Web/sites/write",
    "Microsoft.Web/sites/functions/write",
    "Microsoft.Storage/storageAccounts/listKeys/action",
    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read",
    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write"
]);

// Customer-defined Sentinel watchlists.
// Expected SearchKey examples:
// - ApprovedAzureSourceNetworks: CIDR ranges such as 203.0.113.0/24.
// - ApprovedAzureAutomationIdentities: UPNs, app IDs, service principal IDs, or display names.
// - SensitiveAzureSubscriptions: subscription IDs.
// - SensitiveAzureResourceGroups: resource group names.
// - SensitiveAzureResources: resource IDs.
// - RecentDeveloperOrCICDExposure: identities recently associated with developer or CI/CD exposure.
let ApprovedSourceNetworks =
    toscalar(_GetWatchlist("ApprovedAzureSourceNetworks")
    | summarize make_set(tostring(SearchKey)));
let ApprovedAutomationIdentities =
    toscalar(_GetWatchlist("ApprovedAzureAutomationIdentities")
    | summarize make_set(tostring(SearchKey)));
let SensitiveSubscriptions =
    toscalar(_GetWatchlist("SensitiveAzureSubscriptions")
    | summarize make_set(tostring(SearchKey)));
let SensitiveResourceGroups =
    toscalar(_GetWatchlist("SensitiveAzureResourceGroups")
    | summarize make_set(tostring(SearchKey)));
let SensitiveResources =
    toscalar(_GetWatchlist("SensitiveAzureResources")
    | summarize make_set(tostring(SearchKey)));
let RecentDeveloperOrCICDExposure =
    toscalar(_GetWatchlist("RecentDeveloperOrCICDExposure")
    | summarize make_set(tostring(SearchKey)));

AzureActivity
| where TimeGenerated > ago(1h)
| where OperationNameValue in~ (SensitiveAzureActivityOps)
| extend InitiatingIdentity = tostring(coalesce(Caller, Claims["appid"], Claims["upn"]))
| extend SourceIP = tostring(CallerIpAddress)
| extend UserAgent = tostring(Claims)
| extend ResourceContext = strcat(ResourceGroup, "/", Resource, "/", ResourceId)
| where ActivityStatusValue =~ "Success" or ActivityStatus =~ "Succeeded"
| where InitiatingIdentity has_any (IdentityScopeTerms)
    or ResourceGroup has_any (IdentityScopeTerms)
    or Resource has_any (IdentityScopeTerms)
    or ResourceContext has_any (IdentityScopeTerms)
| extend IsApprovedAutomationIdentity =
    InitiatingIdentity in (ApprovedAutomationIdentities)
| extend IsSensitiveSubscription =
    SubscriptionId in (SensitiveSubscriptions)
| extend IsSensitiveResourceGroup =
    ResourceGroup in (SensitiveResourceGroups)
| extend IsSensitiveResource =
    ResourceId in (SensitiveResources)
| extend HasRecentExposureContext =
    InitiatingIdentity in (RecentDeveloperOrCICDExposure)
| extend HasApprovedSourceNetwork =
    ipv4_is_in_any_range(SourceIP, ApprovedSourceNetworks)
| extend HasSuspiciousContext = iff(
      HasRecentExposureContext
      or IsSensitiveSubscription
      or IsSensitiveResourceGroup
      or IsSensitiveResource
      or not(IsApprovedAutomationIdentity)
      or not(HasApprovedSourceNetwork),
      true,
      false
  )
| where HasSuspiciousContext == true
| project
    TimeGenerated,
    SubscriptionId,
    ResourceGroup,
    Resource,
    ResourceId,
    OperationNameValue,
    InitiatingIdentity,
    SourceIP,
    UserAgent,
    ActivityStatusValue,
    ResourceContext,
    IsApprovedAutomationIdentity,
    IsSensitiveSubscription,
    IsSensitiveResourceGroup,
    IsSensitiveResource,
    HasRecentExposureContext,
    HasApprovedSourceNetwork
| order by TimeGenerated desc

Cloud-Native Detection Opportunities

Conditional

Azure may also support conditional cloud-native detection opportunities when additional context is available.

Examples include:

·        Entra ID, Azure Activity, or Key Vault activity by developer or CI/CD identities from new source networks, new geographies, unusual user agents, unexpected tenants, or unexpected subscriptions.

·        Service principal or managed identity activity shortly after developer endpoint, CI/CD runner, GitHub, or npm exposure indicators.

·        Key Vault, Azure Container Registry, Storage, managed identity, deployment, or build activity outside approved release windows.

·        App credential, service principal, role assignment, or Key Vault events correlated with GitHub workflow changes, npm publishing activity, or exposed package-install windows.

These opportunities should be implemented only when identity, source, workflow, release-process, subscription, tenant, and resource context are available.

Azure Final Disposition

Azure is selected for S25 with one production detection rule and one conditional production detection rule.

Azure detections are downstream credential-abuse and identity-control-plane detections. They should be used to identify suspicious Azure activity following developer or CI/CD exposure, not to prove the initial npm package execution path.

GCP

Detection Viability Assessment

GCP is viable for S25 as a downstream credential-abuse, service-account, workload-identity, secret-access, artifact, and build-control-plane detection layer.

GCP should not be used to detect the initial npm package execution path. GCP telemetry will not directly observe package-manager lifecycle execution, Bun or Node runtime behavior, local developer credential access, or CI/CD runner staging unless those systems also forward endpoint or pipeline telemetry into the same analytics environment. GCP detection should instead focus on post-compromise use of stolen cloud credentials, service accounts, workload identities, CI/CD deployment identities, Secret Manager access, Artifact Registry activity, Cloud Build activity, IAM policy changes, and deployment-path manipulation.

The strongest GCP detections for this incident are cloud-native rules that identify sensitive IAM, service-account, service-account-key, workload-identity, Secret Manager, Artifact Registry, Cloud Build, Cloud Run, Cloud Functions, GKE, storage, and deployment activity by identities connected to developer, CI/CD, package-publishing, build, release, or deployment workflows.

The identity and context filters shown in the GCP queries are placeholders. Production deployment must replace broad identity string matching and placeholder context with organization-specific mappings such as IAM principal inventories, service-account inventories, workload-identity mappings, project labels, folder labels, organization labels, CI/CD identity lists, deployment-role lists, repository-to-identity mappings, approved source networks, sensitive resource inventories, or SIEM lookup tables.

GCP Rule 1

Developer or CI/CD Identity Performs Sensitive IAM or Service Account Activity

Rule Status

Production detection rule.

Rule Format

Google Cloud Logging query.

Detection Objective

Detect sensitive IAM, service-account, service-account-key, workload-identity, or privilege-modification activity performed by developer, CI/CD, package-publishing, build, release, automation, or deployment identities that may have been exposed through poisoned npm package execution.

Detection Logic

This rule detects downstream GCP identity and control-plane activity consistent with stolen credential use, privilege expansion, persistence setup, service-account abuse, service-account-key creation, workload-identity modification, or IAM policy manipulation.

This rule focuses on sensitive GCP IAM and service-account actions by identities commonly connected to developer workflows, CI/CD pipelines, package publishing, release systems, or deployment automation. It does not claim visibility into local npm package execution.

Required Telemetry

·        GCP Admin Activity audit logs.

·        IAM audit events.

·        Service Account audit events.

·        Service Account Key audit events.

·        Workload Identity and IAM policy events where available.

·        Principal email.

·        Service account email.

·        Project, folder, and organization context.

·        Method name.

·        Resource name.

·        Authentication info.

·        Caller IP where available.

·        User agent where available.

·        Request metadata where available.

·        Project labels, folder labels, organization labels, identity inventory, or external identity mapping where available.

Engineering Implementation Instructions

Engineers should deploy this rule across GCP organizations, folders, and projects connected to development, CI/CD, package publishing, artifact handling, release automation, staging, and production deployment workflows.

The placeholder identity filters in the query must be replaced with customer-specific identity scoping. Acceptable scoping inputs include approved developer groups, CI/CD service accounts, workload identities, package-publishing identities, deployment identities, service-account inventories, IAM principal inventories, project labels, folder labels, organization labels, repository-to-identity mappings, or SIEM lookup tables.

Production alerting should prioritize sensitive IAM, service-account, service-account-key, and workload-identity activity from unexpected source IPs, unusual user agents, unusual projects or folders, unusual authentication contexts, off-window release timing, or identities recently associated with developer or CI/CD exposure.

Tiering Data

·        Tier 1: Hunt for sensitive IAM, service-account, service-account-key, and workload-identity activity by developer, CI/CD, package-publishing, and deployment identities after package exposure.

·        Tier 2: Add identity role tagging for developers, automation identities, CI/CD service accounts, workload identities, package-publishing identities, build identities, release identities, and deployment identities.

·        Tier 3: Correlate GCP findings with endpoint, CI/CD, GitHub, npm registry, identity, DNS, and proxy telemetry.

·        Tier 4: Add normal source IP, user-agent, release-window, workload identity, project-criticality, repository, artifact, and deployment-environment baselines.

DRI Assessment

Detection Robustness Index

·        8.3

DRI Justification

The rule is behaviorally anchored on sensitive GCP identity and access-management actions that are relevant to downstream credential misuse. It does not depend on npm package names, payload filenames, hashes, or attacker infrastructure. It remains useful when attackers change package artifacts because stolen GCP credentials, service-account credentials, or workload identity access still require control-plane use to create persistence, add keys, modify IAM policy, manipulate service accounts, or alter identity access.

TCR Assessment

Operational TCR

·        Moderate to High

Operational TCR Justification

Operational confidence depends on GCP Admin Activity audit logs, identity mapping, project and folder coverage, caller IP visibility, user-agent visibility, and whether developer or CI/CD identities are distinguishable from normal automation. Confidence is reduced when audit logs are incomplete or service accounts and workload identities are not mapped to development and deployment workflows.

Full-Telemetry TCR

·        High

Full-Telemetry TCR Justification

With complete GCP Admin Activity audit logs, identity context, project and folder coverage, caller IP, user agent, service-account inventory, workload-identity mapping, and project or folder labels, GCP can reliably detect sensitive identity and IAM activity by exposed or suspicious developer and CI/CD identities.

Limitations

·        This rule detects downstream GCP credential or identity abuse, not initial npm package execution.

·        Legitimate cloud administration may perform IAM, service-account, key, and workload-identity operations.

·        Placeholder identity matching must be replaced with organization-specific identity mapping.

·        Identity role tagging, source context, project context, folder context, and release-window context are required to reduce noise.

·        The original credential-theft method may not be provable from GCP telemetry alone.

Detection Code

-- Google Cloud Logging query
-- Detect sensitive IAM, service-account, service-account-key, and workload-identity
-- activity by mapped developer, CI/CD, package-publishing, build, release,
-- automation, or deployment identities.
-- Replace placeholder identity filters with organization-specific mappings such as
-- service-account inventories, IAM principal inventories, project labels, folder labels,
-- repository-to-identity mappings, or SIEM lookup tables.

logName:"cloudaudit.googleapis.com%2Factivity"
protoPayload.serviceName=("iam.googleapis.com" OR "cloudresourcemanager.googleapis.com")
protoPayload.methodName=(
  "google.iam.admin.v1.CreateServiceAccount" OR
  "google.iam.admin.v1.DeleteServiceAccount" OR
  "google.iam.admin.v1.UpdateServiceAccount" OR
  "google.iam.admin.v1.CreateServiceAccountKey" OR
  "google.iam.admin.v1.DeleteServiceAccountKey" OR
  "google.iam.admin.v1.EnableServiceAccount" OR
  "google.iam.admin.v1.DisableServiceAccount" OR
  "SetIamPolicy" OR
  "google.iam.admin.v1.SetIamPolicy"
)
(
  protoPayload.authenticationInfo.principalEmail:"developer" OR
  protoPayload.authenticationInfo.principalEmail:"dev" OR
  protoPayload.authenticationInfo.principalEmail:"ci" OR
  protoPayload.authenticationInfo.principalEmail:"cd" OR
  protoPayload.authenticationInfo.principalEmail:"build" OR
  protoPayload.authenticationInfo.principalEmail:"deploy" OR
  protoPayload.authenticationInfo.principalEmail:"release" OR
  protoPayload.authenticationInfo.principalEmail:"package" OR
  protoPayload.authenticationInfo.principalEmail:"pipeline" OR
  protoPayload.authenticationInfo.principalEmail:"automation" OR
  protoPayload.resourceName:"developer" OR
  protoPayload.resourceName:"ci" OR
  protoPayload.resourceName:"build" OR
  protoPayload.resourceName:"deploy" OR
  protoPayload.resourceName:"release" OR
  protoPayload.resourceName:"package"
)
NOT protoPayload.status.code:*

GCP Rule 2

Developer or CI/CD Identity Accesses Secrets, Artifacts, Build, or Deployment Services from Suspicious Context

Rule Status

Conditional production detection rule.

Rule Format

Google Cloud Logging candidate query with SIEM or Security Command Center enrichment requirement.

Detection Objective

Detect suspicious access to GCP Secret Manager, Artifact Registry, Cloud Build, Cloud Run, Cloud Functions, GKE, Cloud Storage artifact locations, or deployment services by developer, CI/CD, package-publishing, build, release, automation, or deployment identities after potential developer ecosystem compromise.

Detection Logic

This rule detects downstream use of stolen GCP credentials, service-account credentials, or workload identity material to access secrets, retrieve deployment material, modify build or deployment paths, interact with registries, manipulate deployment services, or access cloud artifacts.

This rule is conditional because many of the observed GCP services and operations are normal in legitimate CI/CD and release workflows. The Cloud Logging query below identifies candidate sensitive service activity. Production alerting requires enrichment and correlation in a SIEM, Security Command Center workflow, or equivalent analytics layer using customer-defined baselines.

Production use requires suspicious context such as unapproved source network, unapproved automation identity, sensitive project, sensitive folder, sensitive resource, unexpected region, unexpected release window, recent developer or CI/CD exposure context, or validated release-process deviation.

This rule does not claim visibility into local npm package execution. It detects suspicious GCP service use that may follow credential theft from a developer workstation, CI/CD runner, package-publishing system, or poisoned dependency execution path.

Required Telemetry

·        GCP Admin Activity audit logs.

·        GCP Data Access audit logs where enabled.

·        Secret Manager audit logs.

·        Artifact Registry audit logs.

·        Cloud Build audit logs.

·        Cloud Run and Cloud Functions audit logs.

·        GKE audit logs where available.

·        Cloud Storage data access logs for artifact locations where enabled.

·        Principal email.

·        Service account email.

·        Caller IP where available.

·        User agent where available.

·        Project, folder, organization, and region context.

·        Resource name and method name.

·        Project labels, folder labels, resource labels, or external identity inventory where available.

·        Customer-defined lookup tables for approved source networks, approved automation identities, approved release windows, sensitive projects, sensitive folders, sensitive resources, repository-to-identity mappings, and recent developer or CI/CD exposure.

Engineering Implementation Instructions

Engineers should deploy this rule across GCP organizations, folders, and projects connected to CI/CD, artifact storage, package publishing, container registry, staging, and production deployment. Data Access audit logs should be enabled for critical Secret Manager resources, Artifact Registry repositories, Cloud Storage artifact buckets, and deployment resources where feasible.

The Cloud Logging query should be used to identify candidate sensitive service activity. Production alerting must occur only after enrichment confirms suspicious context through customer-specific identity scoping and lookup tables. Required enrichment inputs include approved source networks, approved automation identities, approved user agents where available, normal regions, approved release windows, sensitive projects, sensitive folders, sensitive resources, service-account mappings, repository-to-identity mappings, and package-publishing workflows.

This rule should remain a hunt or conditional production detection until those context fields and baselines are validated.

Tiering Data

·        Tier 1: Hunt for Secret Manager access, registry access, artifact access, service-account use, and build or deployment activity by exposed developer or CI/CD identities.

·        Tier 2: Add lookup tables for approved source networks, automation identities, release windows, sensitive projects, sensitive folders, Secret Manager resources, Artifact Registry repositories, Cloud Storage artifact buckets, and package-publishing identities.

·        Tier 3: Correlate GCP findings with endpoint, CI/CD, GitHub, npm registry, identity, DNS, proxy, and artifact telemetry through SIEM or Security Command Center enrichment.

·        Tier 4: Add repository-to-identity mapping, workload-identity mapping, deployment environment context, project/folder criticality, and recent developer or CI/CD exposure context.

DRI Assessment

Detection Robustness Index

·        7.8

DRI Justification

The rule is behaviorally anchored on sensitive GCP service access that may follow developer or CI/CD credential theft. It detects access to secrets, registries, deployment resources, service accounts, storage artifacts, and build pathways rather than relying on static payload indicators. The score is lower than GCP Rule 1 because production precision depends heavily on suspicious source context, release-process baselines, resource labeling, SIEM or Security Command Center enrichment, and Data Access audit log coverage.

TCR Assessment

Operational TCR

·        Moderate when suspicious source, identity, resource, project, folder, and release-context baselines are available.

·        Low to Moderate when those baselines, enrichment, or Data Access audit logs are unavailable.

Operational TCR Justification

Operational confidence depends on Admin Activity coverage, Data Access audit logging, Secret Manager logging, Artifact Registry logging, Cloud Storage logging, identity mapping, caller IP visibility, user-agent visibility, resource labels, lookup quality, enrichment quality, and release-process baselines. Confidence is reduced where Secret Manager Data Access logs, storage logs, registry logs, build/deployment audit visibility, or baseline lookup tables are incomplete.

Full-Telemetry TCR

·        High

Full-Telemetry TCR Justification

With complete GCP Admin Activity, Data Access, Secret Manager, Artifact Registry, Cloud Storage, identity, and CI/CD telemetry, plus validated lookup tables for approved source networks, approved automation identities, sensitive resources, project/folder context, and release-process baselines, GCP can reliably detect suspicious secret, registry, artifact, identity, and build/deployment access after developer or CI/CD exposure.

Limitations

·        This rule detects downstream GCP activity, not local npm package execution.

·        The Cloud Logging query identifies candidate sensitive service activity and should not generate production alerts without enrichment.

·        Legitimate CI/CD and deployment automation may access Secret Manager, Artifact Registry, Cloud Storage artifacts, service accounts, and deployment resources.

·        Data Access audit logging may not be enabled by default for all required services.

·        This rule should not be enabled as unconditional production alerting without suspicious context baselines and validated lookup tables.

·        Project-specific release and deployment baselines are required to reduce false positives.

Detection Code

-- Google Cloud Logging candidate query
-- Conditional production detection for sensitive Secret Manager, Artifact Registry,
-- Cloud Storage, build, service-account, and deployment activity by mapped developer,
-- CI/CD, package-publishing, build, release, automation, or deployment identities.
--
-- This query identifies candidate sensitive service activity only.
-- Production alerting requires enrichment in a SIEM, Security Command Center workflow,
-- or equivalent analytics layer using customer-defined lookup tables for:
-- approved automation identities, approved source networks, approved release windows,
-- sensitive projects, sensitive folders, sensitive resources, repository-to-identity
-- mappings, and recent developer or CI/CD exposure context.
--
-- Replace placeholder identity and resource filters with environment-specific mappings.

(logName:"cloudaudit.googleapis.com%2Factivity" OR logName:"cloudaudit.googleapis.com%2Fdata_access")
protoPayload.serviceName=(
  "secretmanager.googleapis.com" OR
  "artifactregistry.googleapis.com" OR
  "cloudbuild.googleapis.com" OR
  "run.googleapis.com" OR
  "cloudfunctions.googleapis.com" OR
  "container.googleapis.com" OR
  "storage.googleapis.com"
)
protoPayload.methodName=(
  "google.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion" OR
  "google.cloud.secretmanager.v1.SecretManagerService.AddSecretVersion" OR
  "google.devtools.artifactregistry.v1.ArtifactRegistry.UploadArtifact" OR
  "google.devtools.artifactregistry.v1.ArtifactRegistry.DownloadArtifact" OR
  "google.devtools.cloudbuild.v1.CloudBuild.CreateBuild" OR
  "google.devtools.cloudbuild.v1.CloudBuild.UpdateBuildTrigger" OR
  "google.cloud.run.v1.Services.CreateService" OR
  "google.cloud.run.v1.Services.UpdateService" OR
  "google.cloud.functions.v1.CloudFunctionsService.CreateFunction" OR
  "google.cloud.functions.v1.CloudFunctionsService.UpdateFunction" OR
  "io.k8s.authorization.rbac.v1.roles.create" OR
  "io.k8s.authorization.rbac.v1.rolebindings.create" OR
  "storage.objects.get" OR
  "storage.objects.create"
)
(
  -- Placeholder identity scoping only. Replace with customer-specific identity mappings.
  protoPayload.authenticationInfo.principalEmail:"developer" OR
  protoPayload.authenticationInfo.principalEmail:"dev" OR
  protoPayload.authenticationInfo.principalEmail:"ci" OR
  protoPayload.authenticationInfo.principalEmail:"cd" OR
  protoPayload.authenticationInfo.principalEmail:"build" OR
  protoPayload.authenticationInfo.principalEmail:"deploy" OR
  protoPayload.authenticationInfo.principalEmail:"release" OR
  protoPayload.authenticationInfo.principalEmail:"package" OR
  protoPayload.authenticationInfo.principalEmail:"pipeline" OR
  protoPayload.authenticationInfo.principalEmail:"automation"
)
NOT protoPayload.status.code:*

Required Production Enrichment for Rule 2

Production alerting for Rule 2 requires the candidate Cloud Logging match to be enriched with customer-defined context and to satisfy at least one validated suspicious condition.

Required enrichment sources include:

·        Approved automation identities.

·        Approved source networks.

·        Approved release windows.

·        Sensitive projects.

·        Sensitive folders.

·        Sensitive Secret Manager resources.

·        Sensitive Artifact Registry repositories.

·        Sensitive Cloud Storage artifact buckets.

·        Repository-to-service-account mappings.

·        Workload identity mappings.

·        Recent developer or CI/CD exposure context.

Validated suspicious conditions include:

·        Candidate activity by an identity not approved for the service or resource.

·        Candidate activity against a sensitive project, folder, or resource.

·        Candidate activity from an unapproved source network.

·        Candidate activity outside an approved release window.

·        Candidate activity by an identity recently associated with developer endpoint, CI/CD runner, GitHub, or npm exposure.

·        Candidate activity involving a repository, package, workload identity, or service account that does not match expected deployment mappings.

Cloud-Native Detection Opportunities

Conditional

GCP may also support conditional cloud-native detection opportunities when additional context is available.

Examples include:

·        GCP IAM, service-account, Secret Manager, Artifact Registry, or Cloud Build activity by developer or CI/CD identities from new source networks, unusual user agents, unexpected projects, unexpected folders, or unusual regions.

·        Service-account or workload-identity activity shortly after developer endpoint, CI/CD runner, GitHub, or npm exposure indicators.

·        Secret Manager, Artifact Registry, Cloud Storage, Cloud Build, Cloud Run, Cloud Functions, or GKE activity outside approved release windows.

·        IAM policy, service-account-key, Secret Manager, or Artifact Registry events correlated with GitHub workflow changes, npm publishing activity, or exposed package-install windows.

These opportunities should be implemented only when identity, source, workflow, release-process, project, folder, organization, and resource context are available.

S26 — Threat-to-Rule Traceability Matrix

Traceability Objective

This section maps the threat behaviors from the SAP-related npm package poisoning incident to the validated S25 detection rules. The purpose is to provide a clear traceability mapping across the attack chain without implying that any single system provides full compromise confirmation.

Traceability Scope

·        Detection coverage is mapped to behavior, not static package names, hashes, filenames, or infrastructure.

·        Endpoint and SIEM rules provide primary coverage for package-manager execution, runtime behavior, credential access, and local staging.

·        Cloud rules provide downstream coverage for credential abuse, identity manipulation, secret access, artifact access, registry activity, build activity, and deployment-path manipulation.

·        Elastic Rule 3 and QRadar Rule 2 require normalized SaaS, package-registry, cloud, identity, endpoint, and CI/CD telemetry with validated pivots before they can support downstream abuse correlation.

·        YARA provides supplemental artifact triage only and does not prove execution or compromise.

·        Cross-source correlation remains required to reconstruct the full attack chain.

Threat Behavior 1

Poisoned npm package install-time execution

Mapped Detection Rules

·        Suricata: No production rule selected.

·        SentinelOne Rule 1: npm Lifecycle Execution Spawning Suspicious Runtime or Shell Activity.

·        Splunk Rule 1: npm Lifecycle Execution Followed by Suspicious Runtime and Credential Access.

·        Elastic Rule 1: npm Lifecycle Execution Followed by Suspicious Runtime or Shell Execution.

·        QRadar Rule 1: npm Lifecycle Execution with Suspicious Runtime or Credential Access Indicators.

·        SIGMA Rule 1: Suspicious npm Lifecycle Execution Spawning Runtime, Shell, or Downloader.

·        YARA Rule 1: Suspicious npm Package Loader with Developer Secret Targeting Indicators.

Coverage Rationale

·        Primary coverage comes from process lineage, package-manager parentage, lifecycle-script context, command-line telemetry, and suspicious follow-on runtime or shell execution.

·        YARA supports package artifact triage when package contents, caches, mirrors, or build artifacts are available.

·        Cloud platforms do not directly observe this behavior unless endpoint or CI/CD telemetry is forwarded into the cloud analytics environment.

Coverage Disposition

·        Strong endpoint and SIEM coverage.

·        Supplemental artifact coverage through YARA.

·        No direct cloud-native coverage.

Threat Behavior 2

Suspicious runtime, shell, downloader, archive, or encoded-command execution

Mapped Detection Rules

·        SentinelOne Rule 1: npm Lifecycle Execution Spawning Suspicious Runtime or Shell Activity.

·        Splunk Rule 1: npm Lifecycle Execution Followed by Suspicious Runtime and Credential Access.

·        Elastic Rule 1: npm Lifecycle Execution Followed by Suspicious Runtime or Shell Execution.

·        QRadar Rule 1: npm Lifecycle Execution with Suspicious Runtime or Credential Access Indicators.

·        SIGMA Rule 1: Suspicious npm Lifecycle Execution Spawning Runtime, Shell, or Downloader.

·        SIGMA Rule 2: Bun or Node Execution from Dependency, Cache, Temporary, or CI Workspace Path.

Coverage Rationale

·        Rules detect suspicious execution transitions from package-manager activity into Bun, Node, shell, PowerShell, curl, wget, archive utilities, Python, encoded commands, or abnormal execution paths.

·        Detection strength is highest where full command-line, parent-child lineage, process path, working directory, and asset role context are available.

Coverage Disposition

·        Strong endpoint coverage.

·        Strong SIEM correlation coverage where process telemetry is normalized.

·        Requires tuning for legitimate lifecycle scripts and approved build tooling.

Threat Behavior 3

Bun or Node execution from dependency, cache, temporary, user-profile, or CI workspace paths

Mapped Detection Rules

·        SentinelOne Rule 2: Bun or Node Execution from Dependency or CI Workspace Path with Credential Access Indicators.

·        Elastic Rule 2: Bun or Node Execution from Dependency or CI Workspace Path with Process-Linked Secret Access.

·        SIGMA Rule 2: Bun or Node Execution from Dependency, Cache, Temporary, or CI Workspace Path.

·        Splunk Rule 1: npm Lifecycle Execution Followed by Suspicious Runtime and Credential Access.

·        QRadar Rule 1: npm Lifecycle Execution with Suspicious Runtime or Credential Access Indicators.

Coverage Rationale

·        Coverage focuses on runtime execution from locations associated with package caches, dependencies, temporary directories, developer workspaces, CI/CD runners, and build directories.

·        Elastic Rule 2 and SIGMA Rule 3 remain dependent on process-linked file telemetry when credential access is part of the detection condition.

·        Approved Bun or Node-heavy environments require stronger baselines.

Coverage Disposition

·        Strong coverage where endpoint process telemetry includes executable path and process ancestry.

·        Conditional precision where file activity must be tied back to a specific runtime process.

Threat Behavior 4

Credential-file access, secret discovery, and local staging

Mapped Detection Rules

·        SentinelOne Rule 2: Bun or Node Execution from Dependency or CI Workspace Path with Credential Access Indicators.

·        SentinelOne Rule 3: Linux CI Runner Memory and Environment Harvesting from Suspicious Runtime Process.

·        Splunk Rule 1: npm Lifecycle Execution Followed by Suspicious Runtime and Credential Access.

·        Elastic Rule 2: Bun or Node Execution from Dependency or CI Workspace Path with Process-Linked Secret Access.

·        QRadar Rule 1: npm Lifecycle Execution with Suspicious Runtime or Credential Access Indicators.

·        SIGMA Rule 3: Credential File Access or Local Secret Staging by Package-Manager Descended Runtime.

·        YARA Rule 1: Suspicious npm Package Loader with Developer Secret Targeting Indicators.

Coverage Rationale

·        Detection coverage maps to access or staging of npm tokens, GitHub tokens, cloud credentials, SSH keys, Kubernetes configuration, Docker configuration, package registry tokens, environment material, and secret-like local artifacts.

·        SentinelOne Rule 3 provides targeted Linux runner coverage for environment and memory harvesting patterns.

·        YARA coverage remains artifact-triage only and does not confirm credential theft.

Coverage Disposition

·        Strong where file access, process context, and command-line telemetry are available.

·        Conditional where file events are not process-linked.

·        Requires corroboration from identity, cloud, GitHub, npm, proxy, DNS, and CI/CD logs.

Threat Behavior 5

Linux CI runner environment, memory, or /proc/self harvesting

Mapped Detection Rules

·        SentinelOne Rule 3: Linux CI Runner Memory and Environment Harvesting from Suspicious Runtime Process.

·        Splunk Rule 1: npm Lifecycle Execution Followed by Suspicious Runtime and Credential Access.

·        Elastic Rule 2: Bun or Node Execution from Dependency or CI Workspace Path with Process-Linked Secret Access.

·        SIGMA Rule 3: Credential File Access or Local Secret Staging by Package-Manager Descended Runtime.

Coverage Rationale

·        Coverage targets suspicious access to environment, memory, maps, or secret-bearing local material from runtime or package-manager-descended processes.

·        SentinelOne provides the most direct system-specific rule for this behavior.

·        SIEM and portable rules require process-linked file telemetry or strong endpoint enrichment.

Coverage Disposition

·        Strongest on self-hosted Linux CI/CD runners and release systems.

·        Weaker on managed runners, short-lived containers, or hosts without file-access telemetry.

Threat Behavior 6

GitHub workflow, repository, deploy-key, webhook, secret, or token abuse

Mapped Detection Rules

·        Splunk Rule 2: GitHub Workflow or Repository Abuse Following Local Compromise Signals.

·        Elastic Rule 3: Local Developer or CI/CD Compromise Signal Followed by Sensitive SaaS or Cloud Control-Plane Activity.

·        QRadar Rule 2: Sensitive GitHub, npm, or Cloud Activity Following Local Compromise Signals.

Coverage Rationale

·        Coverage detects downstream abuse after local compromise signals, including workflow modification, repository creation, deploy-key changes, webhook changes, secret changes, token activity, or sensitive repository control-plane actions.

·        Splunk Rule 2 directly maps to GitHub workflow and repository abuse when GitHub audit telemetry is available.

·        Elastic Rule 3 and QRadar Rule 2 require GitHub audit telemetry ingestion, normalized actor and source context, and validated pivots to local compromise indicators.

Coverage Disposition

·        Strong in SIEM environments with GitHub audit log ingestion and identity correlation.

·        Not covered by endpoint-only SIGMA or YARA.

·        Requires validated actor, source, repository, token, or automation identity pivots.

Threat Behavior 7

npm registry publishing, maintainer, token, ownership, or metadata abuse

Mapped Detection Rules

·        Splunk Rule 3: npm Registry Publishing or Token Abuse Following Credential Exposure Signals.

·        Elastic Rule 3: Local Developer or CI/CD Compromise Signal Followed by Sensitive SaaS or Cloud Control-Plane Activity.

·        QRadar Rule 2: Sensitive GitHub, npm, or Cloud Activity Following Local Compromise Signals.

Coverage Rationale

·        Coverage detects suspicious package publishing, maintainer changes, token use, package access changes, owner changes, and package metadata changes after local credential exposure signals.

·        Splunk Rule 3 directly maps to npm registry abuse when npm registry audit telemetry is available.

·        Elastic Rule 3 and QRadar Rule 2 require npm registry telemetry ingestion, normalized package and maintainer context, and validated pivots to local compromise indicators.

Coverage Disposition

·        Strong where npm registry telemetry is centralized and normalized.

·        Weaker where package publishing occurs through external accounts or unmanaged maintainers.

·        Requires release-window and maintainer baseline context.

Threat Behavior 8

AWS downstream credential abuse, identity manipulation, secret access, artifact access, registry activity, build activity, or deployment-path manipulation

Mapped Detection Rules

·        AWS Rule 1: Developer or CI/CD Identity Performs Sensitive IAM or Access-Key Activity.

·        AWS Rule 2: Developer or CI/CD Identity Accesses Secrets, Artifacts, Registry, or Build Services from Suspicious Context.

·        Elastic Rule 3: Local Developer or CI/CD Compromise Signal Followed by Sensitive SaaS or Cloud Control-Plane Activity.

·        QRadar Rule 2: Sensitive GitHub, npm, or Cloud Activity Following Local Compromise Signals.

Coverage Rationale

·        AWS Rule 1 provides production coverage for sensitive IAM, STS, access-key, role, and policy actions by mapped developer, CI/CD, package-publishing, build, release, automation, or deployment identities.

·        AWS Rule 2 provides conditional production coverage for sensitive service access where identity, source, account, resource, user-agent, release-window, and exposure baselines are available.

·        Elastic Rule 3 and QRadar Rule 2 only support this behavior when AWS CloudTrail or equivalent cloud telemetry is ingested, normalized, and correlated with validated endpoint, CI/CD, identity, or source pivots.

Coverage Disposition

·        Strong downstream cloud-control-plane coverage through AWS-native rules.

·        Conditional precision for service-access behavior due to normal CI/CD and release automation.

·        Elastic and QRadar coverage is correlation-dependent, not standalone AWS-native coverage.

·        Cannot prove initial npm package execution without endpoint or CI/CD evidence.

Threat Behavior 9

Azure downstream credential abuse, service principal activity, app credential modification, Key Vault access, registry activity, artifact access, managed identity activity, or deployment-path manipulation

Mapped Detection Rules

·        Azure Rule 1: Developer or CI/CD Identity Performs Sensitive Entra ID, App Credential, or Role Assignment Activity.

·        Azure Rule 2: Developer or CI/CD Identity Accesses Key Vault, Registry, Artifact, or Deployment Services from Suspicious Context.

·        Elastic Rule 3: Local Developer or CI/CD Compromise Signal Followed by Sensitive SaaS or Cloud Control-Plane Activity.

·        QRadar Rule 2: Sensitive GitHub, npm, or Cloud Activity Following Local Compromise Signals.

Coverage Rationale

·        Azure Rule 1 provides production coverage for sensitive Entra ID, app credential, service principal, managed identity, and role-assignment activity by mapped developer, CI/CD, package-publishing, build, release, automation, or deployment identities.

·        Azure Rule 2 provides conditional production coverage for Key Vault, registry, artifact, managed identity, and deployment activity when watchlists and suspicious-context baselines are validated.

·        Elastic Rule 3 and QRadar Rule 2 only support this behavior when Azure Activity, Entra ID, Key Vault, registry, identity, and related telemetry are ingested, normalized, and correlated with validated pivots.

Coverage Disposition

·        Strong downstream identity-control-plane coverage through Azure-native rules.

·        Conditional precision for service-access behavior due to legitimate CI/CD automation.

·        Elastic and QRadar coverage is correlation-dependent, not standalone Azure-native coverage.

·        Cannot prove initial npm package execution without endpoint or CI/CD evidence.

Threat Behavior 10

GCP downstream credential abuse, IAM policy modification, service-account activity, Secret Manager access, Artifact Registry activity, Cloud Build activity, artifact access, or deployment-path manipulation

Mapped Detection Rules

·        GCP Rule 1: Developer or CI/CD Identity Performs Sensitive IAM or Service Account Activity.

·        GCP Rule 2: Developer or CI/CD Identity Accesses Secrets, Artifacts, Build, or Deployment Services from Suspicious Context.

·        Elastic Rule 3: Local Developer or CI/CD Compromise Signal Followed by Sensitive SaaS or Cloud Control-Plane Activity.

·        QRadar Rule 2: Sensitive GitHub, npm, or Cloud Activity Following Local Compromise Signals.

Coverage Rationale

·        GCP Rule 1 provides production coverage for sensitive IAM, service-account, service-account-key, workload-identity, and IAM policy activity.

·        GCP Rule 2 provides conditional production coverage for Secret Manager, Artifact Registry, Cloud Build, Cloud Run, Cloud Functions, GKE, Cloud Storage, and deployment-service activity when enriched through SIEM, Security Command Center, or equivalent analytics with validated customer context.

·        Elastic Rule 3 and QRadar Rule 2 only support this behavior when GCP Admin Activity, Data Access, Secret Manager, Artifact Registry, Cloud Build, storage, identity, and related telemetry are ingested, normalized, and correlated with validated pivots.

Coverage Disposition

·        Strong downstream cloud-control-plane coverage for identity and IAM activity through GCP-native rules.

·        Conditional precision for service-access behavior because legitimate CI/CD workflows may perform the same actions.

·        Elastic and QRadar coverage is correlation-dependent, not standalone GCP-native coverage.

·        Cannot prove initial npm package execution without endpoint or CI/CD evidence.

System Traceability Summary

Suricata

·        0 production rules.

·        No S25 rule selected because available network indicators are insufficiently durable for a high-confidence production detection.

·        Coverage must come from endpoint, SIEM, registry, identity, cloud, and artifact telemetry.

SentinelOne

·        3 production rules.

·        Covers package-manager execution, suspicious runtime behavior, credential access, local staging, and Linux CI runner environment or memory harvesting.

Splunk

·        3 production rules.

·        Covers endpoint execution chains, GitHub downstream abuse, and npm registry abuse through sequence-based correlation.

·        Does not provide a dedicated AWS, Azure, or GCP cloud-control-plane rule in this S25 set.

Elastic

·        2 production rules.

·        1 conditional production rule.

·        Covers endpoint execution, suspicious runtime behavior, process-linked secret access where supported, and cross-source downstream abuse when SaaS, registry, cloud, identity, endpoint, and CI/CD telemetry are normalized with validated pivots.

QRadar

·        2 production rules.

·        Covers QRadar AQL hunt logic with CRE correlation for local compromise and downstream GitHub, npm, or cloud activity.

·        Requires validated CRE pivots and normalized platform or cloud telemetry for downstream abuse coverage.

SIGMA

·        2 production rules.

·        1 conditional production rule.

·        Covers portable endpoint behavior, abnormal runtime execution, and process-linked credential access where backend telemetry supports it.

YARA

·        1 supplemental artifact rule.

·        Supports package artifact triage only.

·        Does not prove execution, credential theft, exfiltration, or downstream abuse.

AWS

·        1 production rule.

·        1 conditional production rule.

·        Covers downstream AWS identity, IAM, access-key, secret, artifact, registry, build, KMS, and deployment abuse.

Azure

·        1 production rule.

·        1 conditional production rule.

·        Covers downstream Azure identity, Entra ID, app credential, service principal, role assignment, Key Vault, registry, artifact, managed identity, and deployment abuse.

GCP

·        1 production rule.

·        1 conditional production rule.

·        Covers downstream GCP IAM, service-account, service-account-key, Secret Manager, Artifact Registry, Cloud Build, Cloud Storage, and deployment abuse.

Coverage Gaps and Constraints

·        Initial malicious package installation cannot be reliably confirmed by cloud-native telemetry alone.

·        Managed CI/CD runners may not expose endpoint process or file telemetry.

·        Credential theft through environment variables may not always produce file-access evidence.

·        GitHub, npm, AWS, Azure, and GCP detections require identity, actor, source IP, user-agent, resource, repository, package, token, and release-process context.

·        Elastic Rule 3 and QRadar Rule 2 require normalized cross-source telemetry and validated pivots before they can support downstream SaaS, registry, or cloud abuse coverage.

·        YARA artifact matches support triage and exposure review but do not establish execution or compromise.

·        Suricata was not selected for production rules because durable, low-noise network detection opportunities were not sufficient for the S25 threshold.

Traceability Disposition

The S25 rule set provides strong behavior-driven coverage across the local execution, credential access, downstream SaaS abuse, package-registry abuse, and cloud-control-plane abuse phases of the incident. The highest-confidence coverage comes from endpoint and SIEM correlation for local execution and credential access, combined with cloud-native and platform-specific telemetry for downstream credential misuse. Full attack-chain confirmation requires correlation across endpoint, CI/CD, GitHub, npm registry, identity, proxy, DNS, artifact, and cloud telemetry.

S27 — Behavior and Log Artifacts

Artifact Objective

This section identifies the observable behavior and log artifacts required to support the S25 detection rules and S26 traceability mapping. The objective is to define what defenders should expect to see across endpoint, CI/CD, source-code platform, package-registry, cloud, identity, network, and artifact telemetry when investigating SAP-related npm package poisoning and Shai-Hulud-style developer credential theft.

Primary Behavior Artifact Categories

Package-manager execution artifacts

·        npm, pnpm, or yarn execution on developer endpoints, release systems, package-publishing systems, or self-hosted CI/CD runners.

·        Lifecycle-script execution associated with preinstall, postinstall, setup scripts, package-cache paths, dependency paths, or workspace paths.

·        Parent-child process chains where a package manager launches Bun, Node, shell, PowerShell, Python, curl, wget, tar, unzip, archive tools, or encoded-command execution.

·        Process execution from node_modules, npm cache paths, pnpm paths, temporary directories, user-profile directories, CI workspaces, actions-runner, _work, or build directories.

Relevant Log Sources

·        Endpoint process creation telemetry.

·        EDR process lineage.

·        CI/CD runner telemetry.

·        Build job logs.

·        Package-manager logs where available.

·        SIEM-normalized process telemetry.

Detection Relevance

·        Supports SentinelOne Rule 1.

·        Supports Splunk Rule 1.

·        Supports Elastic Rule 1.

·        Supports QRadar Rule 1.

·        Supports SIGMA Rule 1 and SIGMA Rule 2.

Runtime and loader artifacts

·        Bun or Node execution from dependency, cache, temporary, workspace, or CI/CD paths.

·        JavaScript loader behavior using dynamic import, file-system access, process execution, encoded payload handling, or runtime bootstrap logic.

·        Command lines referencing setup.mjs, node_modules, .npm, .pnpm, curl, wget, base64, encoded command flags, or executable permission changes.

·        Runtime execution by package-manager-descended processes.

Relevant Log Sources

·        Endpoint process telemetry.

·        EDR Deep Visibility or equivalent event search.

·        Elastic endpoint events.

·        SIEM process logs.

·        CI/CD runner logs.

·        Artifact and package-cache inspection.

Detection Relevance

·        Supports SentinelOne Rule 1 and Rule 2.

·        Supports Splunk Rule 1.

·        Supports Elastic Rule 1 and Rule 2.

·        Supports QRadar Rule 1.

·        Supports SIGMA Rule 1 and Rule 2.

·        Supports YARA artifact triage.

Credential access and secret discovery artifacts

·        Access to .npmrc, GitHub token material, npm tokens, SSH private keys, AWS credentials, Azure service principal material, GCP credentials, Kubernetes configuration, Docker configuration, environment files, and secret-like local files.

·        Runtime or shell processes interacting with credential paths after package-manager lifecycle execution.

·        Environment-variable discovery using suspicious runtime or package-manager-descended processes.

·        Linux CI runner activity involving /proc/self/environ, /proc/self/maps, /proc/self/mem, environment harvesting, memory inspection, or process-context discovery.

·        Local staging of environment, cloud, token, credential, secret, JSON, archive, encoded, or compressed material.

Relevant Log Sources

·        Endpoint file access telemetry.

·        Endpoint file creation telemetry.

·        EDR process-to-file telemetry.

·        Linux audit logs where deployed.

·        CI/CD runner telemetry.

·        Secret-scanning or artifact-scanning output.

·        SIEM-normalized file events.

Detection Relevance

·        Supports SentinelOne Rule 2 and Rule 3.

·        Supports Splunk Rule 1.

·        Supports Elastic Rule 2.

·        Supports QRadar Rule 1.

·        Supports SIGMA Rule 3.

·        Supports YARA artifact triage.

GitHub and source-code platform artifacts

·        Repository creation, visibility changes, workflow creation or modification, deploy-key creation, webhook creation or update, secret updates, OAuth authorization changes, personal access token use, or unusual API activity.

·        GitHub activity following suspicious developer endpoint or CI/CD runner behavior.

·        Actor, source IP, user-agent, repository, organization, workflow path, token type, and automation identity context.

·        Workflow changes involving sensitive release, package-publishing, or deployment paths.

Relevant Log Sources

·        GitHub audit logs.

·        GitHub enterprise audit events.

·        Source-code platform audit logs.

·        CI/CD workflow logs.

·        Identity provider logs.

·        SIEM-normalized SaaS audit telemetry.

Detection Relevance

·        Supports Splunk Rule 2.

·        Supports Elastic Rule 3 when GitHub telemetry is normalized and correlated.

·        Supports QRadar Rule 2 when CRE pivots are validated.

npm registry and package-publishing artifacts

·        Package publication, package version creation, token creation, token use, token validation, maintainer changes, owner changes, package access updates, package metadata updates, or unusual package-publishing behavior.

·        npm registry activity following local credential exposure signals.

·        Package name, package version, npm account, token identifier, source IP, user-agent, maintainer context, and release-window context.

Relevant Log Sources

·        npm registry audit logs.

·        Package-publishing platform logs.

·        CI/CD package-publish logs.

·        Identity provider logs.

·        SIEM-normalized package-registry telemetry.

Detection Relevance

·        Supports Splunk Rule 3.

·        Supports Elastic Rule 3 when npm telemetry is normalized and correlated.

·        Supports QRadar Rule 2 when CRE pivots are validated.

AWS cloud artifacts

·        IAM user, role, policy, access-key, STS, and privilege-modification activity by mapped developer, CI/CD, package-publishing, build, release, automation, or deployment identities.

·        Secrets Manager, SSM Parameter Store, ECR, CodeBuild, CodePipeline, Lambda, S3 artifact, KMS, or deployment activity from suspicious source, identity, account, region, user-agent, resource, or release-window context.

·        CloudTrail events involving sensitive IAM, access-key, secret, artifact, registry, build, encryption, or deployment actions.

Relevant Log Sources

·        AWS CloudTrail management events.

·        AWS CloudTrail data events where enabled.

·        IAM logs.

·        STS events.

·        Secrets Manager and SSM events.

·        ECR, CodeBuild, CodePipeline, Lambda, S3, and KMS logs.

·        SIEM cloud telemetry.

Detection Relevance

·        Supports AWS Rule 1.

·        Supports AWS Rule 2 when identity, source, account, resource, and release-process baselines are validated.

·        Supports Elastic Rule 3 and QRadar Rule 2 only when AWS telemetry is ingested, normalized, and correlated with validated pivots.

Azure cloud artifacts

·        Entra ID app credential changes, service principal updates, managed identity activity, role assignments, delegated permission grants, application consent, group or role membership changes, and Azure Resource Manager privilege actions.

·        Key Vault, Azure Container Registry, storage artifact, managed identity, build, deployment, and release activity from suspicious source, identity, subscription, tenant, resource, user-agent, Conditional Access, or release-window context.

·        Azure Activity and Entra ID events involving mapped developer, CI/CD, package-publishing, build, release, automation, or deployment identities.

Relevant Log Sources

·        Microsoft Entra ID audit logs.

·        Microsoft Entra ID sign-in logs.

·        Azure Activity logs.

·        Key Vault diagnostic logs.

·        Azure Container Registry logs.

·        Storage account logs where enabled.

·        Managed identity and workload identity events.

·        Microsoft Sentinel watchlists.

Detection Relevance

·        Supports Azure Rule 1.

·        Supports Azure Rule 2 when identity, source, resource, tenant, subscription, Conditional Access, and release-process baselines are validated.

·        Supports Elastic Rule 3 and QRadar Rule 2 only when Azure telemetry is ingested, normalized, and correlated with validated pivots.

GCP cloud artifacts

·        IAM policy modification, service-account creation or update, service-account-key creation or deletion, workload identity changes, and sensitive GCP identity activity.

·        Secret Manager, Artifact Registry, Cloud Build, Cloud Run, Cloud Functions, GKE, Cloud Storage, and deployment activity requiring SIEM or Security Command Center enrichment before production alerting.

·        Principal email, service account, project, folder, organization, resource, caller IP, user-agent, method name, and release-context artifacts.

Relevant Log Sources

·        GCP Admin Activity audit logs.

·        GCP Data Access audit logs where enabled.

·        Secret Manager audit logs.

·        Artifact Registry audit logs.

·        Cloud Build logs.

·        Cloud Run and Cloud Functions audit logs.

·        GKE audit logs where available.

·        Cloud Storage data access logs where enabled.

·        SIEM or Security Command Center enrichment sources.

Detection Relevance

·        Supports GCP Rule 1.

·        Supports GCP Rule 2 when Cloud Logging candidate activity is enriched with validated customer context.

·        Supports Elastic Rule 3 and QRadar Rule 2 only when GCP telemetry is ingested, normalized, and correlated with validated pivots.

Network, DNS, and proxy artifacts

·        Outbound HTTP or HTTPS activity from developer endpoints, CI/CD runners, package-publishing systems, or release systems shortly after package installation or suspicious runtime execution.

·        DNS lookups, proxy requests, or TLS connections associated with suspicious runtime processes where process-to-network attribution is available.

·        Egress to GitHub API, npm registry, cloud APIs, package mirrors, artifact stores, or unknown external endpoints during suspicious execution windows.

Relevant Log Sources

·        DNS logs.

·        Proxy logs.

·        Web gateway logs.

·        EDR network telemetry.

·        Firewall logs.

·        TLS metadata.

·        Process-to-network telemetry where available.

Detection Relevance

·        Supports SIEM enrichment and investigation.

·        Supports correlation with endpoint, GitHub, npm, and cloud rules.

·        Does not support a locked Suricata production rule for this report because durable, low-noise network indicators were not sufficient.

Artifact-scanning and package triage artifacts

·        Suspicious extracted package contents.

·        npm package tarballs.

·        Internal npm mirror contents.

·        Dependency cache contents.

·        CI/CD workspace artifacts.

·        Repository snapshots.

·        Build artifacts.

·        Quarantined endpoint files.

Relevant Log Sources and Data Sources

·        YARA scan results.

·        Package-cache inspection.

·        Internal npm mirror scans.

·        Repository and artifact review.

·        Malware triage output.

·        CI/CD artifact storage.

Detection Relevance

·        Supports YARA Rule 1 as supplemental artifact triage only.

·        Supports exposure review and package analysis.

·        Does not prove execution, credential theft, exfiltration, or downstream abuse.

Artifact Reliability Considerations

·        Process telemetry is strongest when parent-child lineage, command-line arguments, executable path, working directory, user, host, and asset role are available.

·        File telemetry is strongest when process-linked file events include process name, command line, parent process, or process GUID.

·        CI/CD telemetry is strongest when runner identity, repository, workflow, job, build image, workspace, and artifact context are retained.

·        Cloud telemetry is strongest when identity, source IP, user-agent, account, subscription, project, tenant, resource, release-window, and exposure context are available.

·        Artifact triage is useful for exposure review but must be corroborated by runtime and platform telemetry.

Key Artifact Summary

The most important artifacts for this incident are process lineage, suspicious runtime execution, credential-access events, CI/CD runner context, GitHub audit events, npm registry audit events, cloud-control-plane events, and package artifact evidence. Endpoint and CI/CD artifacts provide the strongest evidence of initial execution and credential access. GitHub, npm, AWS, Azure, and GCP artifacts provide downstream evidence of credential misuse and propagation. YARA artifacts support triage only and must not be treated as proof of compromise.

S28 — Detection Strategy and SOC Implementation Guidance

Figure 5

Detection Strategy Objective

This section defines how SOC and detection engineering teams should operationalize the S25 rule set. The strategy prioritizes behavior-driven detection, telemetry validation, correlation readiness, and staged deployment across endpoint, SIEM, source-code platform, package-registry, cloud, identity, network, and artifact telemetry.

Strategic Detection Approach

·        Prioritize endpoint and CI/CD telemetry for initial execution and credential-access detection.

·        Use SIEM correlation to connect local compromise signals to GitHub, npm registry, cloud, identity, proxy, DNS, and artifact telemetry.

·        Use cloud-native rules for downstream credential misuse, identity manipulation, secret access, artifact access, registry activity, build activity, and deployment-path manipulation.

·        Use YARA only for package artifact triage, internal mirror review, dependency-cache scanning, and malware sample analysis.

·        Do not rely on Suricata for this report because durable, low-noise network detection opportunities did not meet the S25 production threshold.

Implementation Phase 1

Telemetry Validation

Required Actions

·        Confirm endpoint coverage for developer endpoints, self-hosted CI/CD runners, release systems, and package-publishing systems.

·        Validate process creation telemetry, parent-child lineage, command-line arguments, process path, working directory, user identity, host identity, and asset role.

·        Confirm file telemetry for credential paths, package-cache paths, workspace paths, and process-linked file events where possible.

·        Validate CI/CD runner logs, workflow logs, repository context, build image context, job identity, runner identity, and artifact retention.

·        Confirm GitHub audit log ingestion, npm registry audit log ingestion, identity logs, proxy logs, DNS logs, and cloud logs.

·        Validate AWS CloudTrail, Azure Activity, Entra ID, GCP Admin Activity, and GCP Data Access coverage where required.

·        Confirm YARA scanning access to package caches, internal npm mirrors, build artifacts, repository snapshots, and suspicious package tarballs.

SOC Outcome

·        SOC teams can distinguish available detection coverage from theoretical coverage.

·        Conditional production rules can be enabled only where required telemetry and mappings exist.

·        Detection confidence is grounded in actual data availability.

Implementation Phase 2

Rule Deployment and Tuning

Required Actions

·        Deploy SentinelOne, Splunk, Elastic, QRadar, SIGMA, AWS, Azure, and GCP rules according to locked S25 status.

·        Keep Suricata at zero production rules for this report unless future durable network indicators emerge.

·        Deploy YARA as supplemental artifact triage only.

·        Treat Elastic Rule 2, SIGMA Rule 3, AWS Rule 2, Azure Rule 2, and GCP Rule 2 according to their conditional requirements.

·        Replace placeholder identity filters with organization-specific identity mappings, watchlists, service-account inventories, IAM paths, principal tags, project labels, subscription tags, and approved automation identity lists.

·        Validate backend-specific field mappings before production alerting.

·        Tune rules against approved lifecycle scripts, build tools, Bun or Node usage, CI/CD workflows, release windows, package-publishing workflows, and cloud automation.

SOC Outcome

·        Production rules are deployed only where telemetry and field mappings support reliable detection.

·        Conditional production rules are not over-promoted.

·        Noise is reduced without weakening evidence requirements.

Implementation Phase 3

Correlation and Enrichment

Required Actions

·        Correlate endpoint lifecycle execution with suspicious runtime execution and credential access.

·        Correlate local compromise signals with GitHub workflow, repository, webhook, deploy-key, secret, and token activity.

·        Correlate credential-exposure signals with npm registry publishing, token use, maintainer changes, ownership changes, and metadata changes.

·        Correlate local compromise and identity signals with AWS, Azure, and GCP downstream control-plane activity.

·        Enrich alerts with asset role, repository, package name, package version, CI/CD runner, build job, release window, source IP, user-agent, cloud account, subscription, project, resource, and identity context.

·        Prioritize alerts involving package-publishing identities, release systems, privileged CI/CD runners, cloud deployment identities, and sensitive repositories.

SOC Outcome

·        Alerts are linked into investigation-ready behavior chains.

·        Analysts can identify whether the event is isolated, local-only, platform-abuse, registry-abuse, or cloud-control-plane abuse.

·        Escalation is based on behavior sequence and asset sensitivity, not isolated indicators.

Implementation Phase 4

Alert Triage and Investigation Workflow

Initial Triage Questions

·        Did npm, pnpm, or yarn execute lifecycle scripts on a developer endpoint, release system, package-publishing system, or CI/CD runner?

·        Did a package-manager-descended process launch Bun, Node, shell, PowerShell, Python, curl, wget, archive utilities, or encoded-command execution?

·        Did the process access credential files, token material, SSH keys, cloud credentials, Kubernetes configuration, Docker configuration, environment material, or package-registry tokens?

·        Did GitHub activity follow the local compromise signal?

·        Did npm registry publishing, token use, maintainer changes, ownership changes, or metadata changes follow credential exposure?

·        Did AWS, Azure, or GCP activity follow the local signal or identity exposure?

·        Did YARA identify suspicious package artifacts requiring exposure review?

Escalation Triggers

·        Package-manager lifecycle execution followed by credential access.

·        Suspicious runtime activity on self-hosted CI/CD runners.

·        /proc/self environment or memory harvesting from suspicious runtime processes.

·        GitHub workflow, deploy-key, webhook, secret, or token activity after local compromise signals.

·        npm publishing, maintainer, ownership, token, or metadata changes after credential exposure.

·        Cloud IAM, access-key, service principal, service-account, Key Vault, Secret Manager, Artifact Registry, ECR, build, or deployment activity from suspicious identity or source context.

·        YARA artifact match plus endpoint, CI/CD, GitHub, npm, or cloud corroboration.

Containment Actions

·        Isolate affected developer endpoints or self-hosted CI/CD runners.

·        Disable affected CI/CD jobs and rotate runner registration tokens where applicable.

·        Revoke exposed GitHub tokens, npm tokens, cloud access keys, app credentials, service principal credentials, service-account keys, and deployment secrets.

·        Review and revert suspicious GitHub workflow changes, deploy keys, webhooks, and repository permissions.

·        Review and revert suspicious npm package publishing, maintainer, owner, access, and metadata changes.

·        Disable or rotate affected AWS, Azure, and GCP identities.

·        Rebuild CI/CD runners and release systems from trusted images.

·        Purge poisoned package versions and validate dependency lockfiles.

·        Preserve package artifacts, CI/CD logs, endpoint telemetry, and cloud logs for investigation.

SOC Reporting Guidance

·        Report the event as a developer ecosystem supply-chain compromise when install-time execution and credential-access behavior are confirmed.

·        Report downstream GitHub or npm activity as platform abuse only when audit telemetry and validated pivots support the link.

·        Report cloud activity as downstream credential misuse only when cloud telemetry and identity context support the link.

·        Do not claim credential theft from YARA matches alone.

·        Do not claim initial npm execution from AWS, Azure, or GCP telemetry alone.

Implementation Summary

The SOC strategy should deploy the locked production rules first, hold conditional rules behind telemetry validation gates, and use cross-source correlation to reconstruct the attack chain. The strongest operational model is endpoint-first detection, SIEM correlation for GitHub and npm abuse, and cloud-native detection for downstream credential misuse. Production alerting must preserve evidence requirements and avoid forcing visibility where telemetry cannot support the claim.

S29 — Detection Coverage Summary

Coverage Summary Objective

This section summarizes the detection coverage achieved by the S25 rule set and identifies remaining detection gaps. Coverage is assessed by behavior phase, telemetry domain, and rule maturity.

Coverage by Attack Phase

Initial Package Execution

·        Coverage Level: Strong.

·        Primary Systems: SentinelOne, Splunk, Elastic, QRadar, SIGMA.

·        Supplemental Systems: YARA.

·        Coverage Basis: Package-manager lifecycle execution, suspicious runtime execution, parent-child lineage, process command line, and abnormal execution path.

·        Key Constraint: Managed CI/CD runners and uninstrumented developer systems may not expose required process telemetry.

Suspicious Runtime and Loader Activity

·        Coverage Level: Strong.

·        Primary Systems: SentinelOne, Splunk, Elastic, QRadar, SIGMA.

·        Supplemental Systems: YARA.

·        Coverage Basis: Bun, Node, shell, downloader, archive utility, Python, encoded-command, and loader-style activity from dependency, cache, temporary, workspace, or CI/CD paths.

·        Key Constraint: Approved build tooling and normal lifecycle scripts require tuning.

Credential Access and Secret Discovery

·        Coverage Level: Moderate to Strong.

·        Primary Systems: SentinelOne, Splunk, Elastic, QRadar, SIGMA.

·        Supplemental Systems: YARA.

·        Coverage Basis: Credential-file access, token access, environment material, SSH keys, cloud credentials, package registry credentials, Kubernetes and Docker configuration, and local staging.

·        Key Constraint: Confidence depends on process-linked file telemetry and visibility into environment-variable access.

Linux CI Runner Environment and Memory Harvesting

·        Coverage Level: Moderate to Strong.

·        Primary System: SentinelOne.

·        Supporting Systems: Splunk, Elastic, SIGMA where telemetry supports process-linked file or environment access.

·        Coverage Basis: Suspicious runtime access to /proc/self environment, maps, memory, or related Linux runner material.

·        Key Constraint: Managed runners, ephemeral containers, and limited file telemetry reduce coverage.

GitHub Workflow and Repository Abuse

·        Coverage Level: Moderate to Strong.

·        Primary Systems: Splunk, Elastic, QRadar.

·        Coverage Basis: GitHub workflow changes, repository changes, deploy-key activity, webhook activity, secret changes, OAuth activity, and token use following local compromise signals.

·        Key Constraint: Requires GitHub audit log ingestion, actor normalization, source IP, user-agent, repository context, and validated pivots.

npm Registry Abuse

·        Coverage Level: Moderate to Strong.

·        Primary Systems: Splunk, Elastic, QRadar.

·        Coverage Basis: npm package publishing, token use, maintainer changes, owner changes, access changes, and metadata changes following credential exposure signals.

·        Key Constraint: Requires npm registry audit telemetry, package context, token context, maintainer context, and release-window baselines.

AWS Downstream Credential Abuse

·        Coverage Level: Moderate to Strong.

·        Primary System: AWS.

·        Supporting Systems: Elastic and QRadar when AWS telemetry is ingested and correlated.

·        Coverage Basis: IAM changes, STS activity, access-key activity, Secrets Manager, SSM, ECR, CodeBuild, CodePipeline, Lambda, S3, KMS, artifact, and deployment activity.

·        Key Constraint: AWS Rule 2 is conditional and requires identity, source, account, resource, user-agent, release-process, and exposure baselines.

Azure Downstream Credential Abuse

·        Coverage Level: Moderate to Strong.

·        Primary System: Azure.

·        Supporting Systems: Elastic and QRadar when Azure telemetry is ingested and correlated.

·        Coverage Basis: Entra ID changes, service principal activity, app credential changes, role assignments, Key Vault access, registry activity, artifact access, managed identity activity, and deployment activity.

·        Key Constraint: Azure Rule 2 is conditional and requires Sentinel watchlists, identity mapping, source context, tenant, subscription, resource, Conditional Access, and release-process baselines.

GCP Downstream Credential Abuse

·        Coverage Level: Moderate to Strong.

·        Primary System: GCP.

·        Supporting Systems: Elastic and QRadar when GCP telemetry is ingested and correlated.

·        Coverage Basis: IAM policy changes, service-account activity, service-account-key activity, Secret Manager access, Artifact Registry activity, Cloud Build activity, Cloud Storage activity, and deployment activity.

·        Key Constraint: GCP Rule 2 is conditional and requires SIEM or Security Command Center enrichment with validated identity, project, folder, resource, source, and release-process context.

Network Detection

·        Coverage Level: Limited.

·        Primary System: None selected for production.

·        Coverage Basis: DNS, proxy, firewall, TLS, and process-to-network telemetry should be used for enrichment and investigation.

·        Key Constraint: Suricata was not assigned production rules because durable, low-noise network indicators were insufficient for S25 gating.

Artifact Triage

·        Coverage Level: Supplemental.

·        Primary System: YARA.

·        Coverage Basis: Suspicious package artifacts containing lifecycle, loader, secret-targeting, staging, or stronger exfiltration indicators.

·        Key Constraint: YARA does not prove execution, credential theft, exfiltration, or downstream abuse.

Coverage by System

Suricata

·        Production Coverage: None.

·        Conditional Coverage: None.

·        Supplemental Coverage: None.

·        Summary: No production rule selected due to insufficient durable, low-noise network detection opportunity.

SentinelOne

·        Production Coverage: Strong.

·        Conditional Coverage: None.

·        Summary: Strong endpoint detection coverage for lifecycle execution, suspicious runtime behavior, credential access, and Linux CI runner environment or memory harvesting.

Splunk

·        Production Coverage: Strong.

·        Conditional Coverage: None.

·        Summary: Strong SIEM correlation coverage for local execution chains, GitHub abuse, and npm registry abuse.

Elastic

·        Production Coverage: Strong.

·        Conditional Coverage: Moderate.

·        Summary: Strong endpoint and cross-source coverage where telemetry is normalized. Elastic Rule 2 remains conditional on process-linked secret access.

QRadar

·        Production Coverage: Moderate to Strong.

·        Conditional Coverage: None.

·        Summary: Strong when AQL hunt logic is converted into CRE correlation with validated pivots and normalized platform or cloud telemetry.

SIGMA

·        Production Coverage: Moderate to Strong.

·        Conditional Coverage: Moderate.

·        Summary: Strong portable endpoint logic for process behaviors. SIGMA Rule 3 is conditional on process-linked file telemetry.

YARA

·        Production Coverage: None.

·        Conditional Coverage: None.

·        Supplemental Coverage: Moderate.

·        Summary: Useful for artifact triage and exposure review only.

AWS

·        Production Coverage: Strong.

·        Conditional Coverage: Moderate.

·        Summary: Strong downstream IAM and access-key coverage. Conditional service-access coverage requires validated context.

Azure

·        Production Coverage: Strong.

·        Conditional Coverage: Moderate.

·        Summary: Strong downstream identity-control-plane coverage. Conditional service-access coverage requires Sentinel watchlists and validated context.

GCP

·        Production Coverage: Strong.

·        Conditional Coverage: Moderate.

·        Summary: Strong downstream IAM and service-account coverage. Conditional service-access coverage requires enrichment and validated context.

Primary Coverage Strengths

·        Strong behavior-led coverage for npm lifecycle execution and suspicious runtime behavior.

·        Strong endpoint and SIEM coverage for credential-access paths when process and file telemetry are available.

·        Strong SIEM correlation opportunities for GitHub and npm registry abuse.

·        Strong cloud-native downstream detection for IAM, identity, and control-plane abuse.

·        Clear conditional handling for service-access behaviors that can overlap with legitimate CI/CD automation.

·        Clear separation between artifact triage and compromise confirmation.

Primary Coverage Gaps

·        No production Suricata coverage due to lack of durable network indicators.

·        Managed CI/CD runners may reduce process and file visibility.

·        Environment-variable-only credential theft may not produce file-access evidence.

·        File telemetry may not always include process linkage.

·        SaaS, npm, and cloud detections require normalized identity, source, actor, user-agent, resource, repository, package, token, and release context.

·        YARA matches remain static and variant-sensitive.

·        Cloud telemetry cannot prove initial package execution.

Coverage Summary

The S25 rule set provides strong detection coverage for endpoint execution, suspicious runtime behavior, credential access, GitHub abuse, npm registry abuse, and downstream cloud-control-plane abuse. Coverage is strongest when endpoint, CI/CD, SIEM, GitHub, npm, identity, and cloud telemetry are normalized and correlated. Remaining gaps are primarily telemetry-driven and should be addressed through runner instrumentation, process-linked file telemetry, registry audit ingestion, cloud data-event enablement, and validated identity or release-process baselines.

S30 — Intelligence Maturity Assessment

Assessment Objective

This section evaluates the maturity of the intelligence and detection model supporting the SAP-related npm package poisoning report. The assessment focuses on intelligence quality, telemetry readiness, detection engineering maturity, cross-source correlation, and operational deployment maturity.

Intelligence Maturity Level

·        Overall Assessment: Moderate to High.

·        Detection Engineering Maturity: High for endpoint and SIEM behavior detection.

·        Cloud Detection Maturity: Moderate to High where cloud audit logs and identity mappings are mature.

·        Artifact Triage Maturity: Moderate.

·        Network Detection Maturity: Limited for production rule deployment.

Intelligence Strengths

·        The report is behavior-led rather than IOC-led.

·        The detection model does not rely on static package names, hashes, payload filenames, or attacker infrastructure.

·        S25 rules cover the major observable phases of the attack chain: install-time execution, suspicious runtime behavior, credential access, GitHub abuse, npm registry abuse, and cloud-control-plane abuse.

·        Conditional production rules are clearly distinguished from unconditional production detections.

·        YARA is correctly limited to supplemental artifact triage.

·        Suricata is correctly left without production rules rather than forcing low-confidence network logic.

·        DRI and TCR scoring remain separated and tied to rule design and telemetry conditions.

Telemetry Maturity Assessment

Endpoint and EDR Telemetry

·        Maturity: High where developer endpoints and self-hosted CI/CD runners are instrumented.

·        Strengths: Process lineage, command-line telemetry, executable path, parent-child process context, and process-to-file visibility support strong detection.

·        Gaps: Managed CI/CD runners, ephemeral containers, missing command-line logging, and missing file telemetry can reduce confidence.

CI/CD Telemetry

·        Maturity: Moderate.

·        Strengths: Runner identity, workflow context, build logs, repository context, and artifact retention support investigation and correlation.

·        Gaps: Managed runners may not expose endpoint telemetry. Build logs may not retain process-level detail. Runner rebuild, token rotation, and artifact preservation processes may vary.

GitHub and npm Registry Telemetry

·        Maturity: Moderate to High where audit logs are centralized.

·        Strengths: GitHub workflow changes, deploy-key changes, webhook changes, secret activity, npm publishing, token activity, maintainer changes, and ownership changes provide strong downstream evidence.

·        Gaps: External maintainer accounts, personal repositories, limited audit retention, and inconsistent token lineage can reduce attribution confidence.

Cloud Telemetry

·        Maturity: Moderate to High.

·        Strengths: AWS, Azure, and GCP provide strong downstream visibility for identity and control-plane abuse.

·        Gaps: Cloud service-access detections depend on data-event enablement, diagnostic logs, watchlists, lookup tables, identity mappings, resource tags, release-window baselines, and enrichment quality.

Network Telemetry

·        Maturity: Limited for primary detection.

·        Strengths: DNS, proxy, firewall, TLS, and process-to-network data support enrichment and investigation.

·        Gaps: Network indicators are not sufficiently durable or low-noise for production Suricata detection in this report.

Artifact Intelligence

·        Maturity: Moderate.

·        Strengths: YARA supports package artifact triage, internal mirror review, package-cache inspection, and retrospective exposure analysis.

·        Gaps: Static artifacts are variant-sensitive. Matches do not prove execution, credential theft, exfiltration, or downstream abuse.

Detection Engineering Maturity

Rule Quality

·        Maturity: High.

·        Basis: Rules are behavior-driven, system-native, scoped to telemetry capability, and hardened against overclaiming.

·        Constraint: Conditional rules require validated environment-specific telemetry and mappings before production alerting.

Correlation Maturity

·        Maturity: Moderate to High.

·        Basis: Splunk, Elastic, QRadar, and cloud-native detections support correlation across endpoint, GitHub, npm, identity, and cloud events.

·        Constraint: Cross-source correlation depends on normalized identities, source IPs, user agents, repositories, packages, tokens, cloud accounts, subscriptions, projects, and release-process context.

Deployment Maturity

·        Maturity: Moderate.

·        Basis: Production rules are clearly separated from conditional and supplemental detections.

·        Constraint: Customer-specific baselines, watchlists, lookup tables, role mappings, and field normalization are required before full deployment maturity.

Operational Readiness

Ready for Production Deployment

·        SentinelOne Rule 1.

·        SentinelOne Rule 2.

·        SentinelOne Rule 3.

·        Splunk Rule 1.

·        Splunk Rule 2.

·        Splunk Rule 3.

·        Elastic Rule 1.

·        Elastic Rule 3 with source-specific mapping.

·        QRadar Rule 1 with CRE implementation.

·        QRadar Rule 2 with two-stage CRE implementation.

·        SIGMA Rule 1.

·        SIGMA Rule 2.

·        AWS Rule 1.

·        Azure Rule 1.

·        GCP Rule 1.

Ready for Conditional Production Deployment

·        Elastic Rule 2.

·        SIGMA Rule 3.

·        AWS Rule 2.

·        Azure Rule 2.

·        GCP Rule 2.

Ready for Supplemental Triage

·        YARA Rule 1.

Not Selected for Production

·        Suricata.

Maturity Improvement Priorities

·        Expand endpoint instrumentation to all developer endpoints, self-hosted CI/CD runners, release systems, and package-publishing systems.

·        Enable or validate process-linked file telemetry for credential-access detection.

·        Centralize GitHub and npm registry audit telemetry.

·        Enable AWS, Azure, and GCP audit logging required for conditional service-access detections.

·        Build identity inventories for developer, CI/CD, package-publishing, build, release, automation, and deployment identities.

·        Build watchlists or lookup tables for approved source networks, approved automation identities, sensitive resources, release windows, repositories, packages, and exposure context.

·        Preserve package artifacts, dependency caches, internal mirror snapshots, build artifacts, and CI/CD logs for retrospective analysis.

·        Implement routine detection validation using benign lifecycle scripts, approved CI/CD workflows, and controlled suspicious-behavior tests.

Analytical Confidence

·        Confidence is high that behavior-based endpoint and SIEM detection is the correct primary model.

·        Confidence is high that cloud detections should be scoped to downstream credential abuse rather than initial package execution.

·        Confidence is moderate to high that GitHub and npm registry abuse can be detected where audit telemetry is centralized and normalized.

·        Confidence is moderate that artifact triage can support exposure review.

·        Confidence is low that network-only production detection can provide durable coverage for this incident without stronger infrastructure or protocol indicators.

Maturity Summary

The intelligence and detection model is mature enough for production deployment across endpoint, SIEM, and cloud-control-plane domains, provided conditional rules are gated behind validated telemetry and customer-specific baselines. The strongest maturity position is behavior-led detection supported by cross-source correlation, not static IOC matching. Remaining maturity improvements should focus on telemetry completeness, identity normalization, runner visibility, registry audit ingestion, process-linked file events, cloud data-event enablement, and validated watchlist or lookup-table governance.

S31 — Mitigation and Remediation

Mitigation and Remediation Objective

Contain exposure from SAP-related npm package poisoning, prevent credential reuse, remove poisoned dependency paths, validate developer and CI/CD trust, and confirm that internal mirrors, caches, build outputs, containers, and release artifacts did not preserve or propagate the compromise. Remediation must not stop at package removal because the governing risk is install-time execution, credential theft, token abuse, package-registry abuse, cloud credential exposure, and downstream software-integrity uncertainty.

Immediate Containment Actions

·        Identify all repositories, workstations, CI/CD jobs, build images, internal npm mirrors, dependency caches, containers, and artifacts that referenced affected SAP-related package versions.

·        Freeze or restrict package publishing from identities, runners, or workflows that installed affected package versions until credential exposure is resolved.

·        Remove affected package versions from dependency files, lockfiles, internal mirrors, build caches, and artifact repositories.

·        Rebuild affected environments from known-good dependency sets rather than reusing potentially exposed caches.

·        Disable or tightly restrict npm lifecycle script execution in high-risk CI/CD workflows where operationally feasible.

·        Preserve endpoint, CI/CD, GitHub, npm, cloud, identity, DNS, proxy, and artifact telemetry before log expiration or runner destruction.

·        Treat exposed privileged developer systems, release hosts, package-publishing systems, and self-hosted CI/CD runners as high-priority investigation targets.

Credential Remediation Actions

·        Rotate GitHub personal access tokens, fine-grained tokens, GitHub App credentials, deploy keys, and automation secrets associated with exposed systems.

·        Revoke and recreate npm tokens associated with exposed users, maintainers, automation identities, and publishing workflows.

·        Rotate SSH keys present on exposed developer or build systems.

·        Rotate cloud access keys, service-account keys, workload identity credentials, deployment secrets, and secret-manager credentials present on exposed systems.

·        Rotate Kubernetes configuration, Docker registry credentials, artifact repository credentials, and package-registry tokens present on exposed systems.

·        Invalidate active sessions for exposed developer, maintainer, package-publishing, and automation identities.

·        Reduce credential scope before issuing replacement credentials.

Developer Endpoint Remediation

·        Identify developer systems that installed affected package versions during the exposure window.

·        Review package-manager process ancestry, command-line history, runtime execution, credential-file access, local staging, and outbound activity.

·        Investigate first-seen or abnormal Bun execution on developer systems where Bun is not approved.

·        Review access to .npmrc, SSH keys, Git credential stores, cloud credential files, Kubernetes configuration, Docker credentials, and CI/CD environment material.

·        Contain or rebuild endpoints where malicious lifecycle execution, credential access, suspicious staging, or outbound transfer is observed.

·        Re-baseline remediated developer systems to confirm package caches, temporary files, local dependencies, and credentials have been cleaned.

CI/CD and Build Environment Remediation

·        Identify CI/CD jobs, runners, workflows, build containers, release workflows, and package-publishing jobs that installed affected package versions.

·        Preserve build logs, workflow logs, package-install logs, cache restore logs, artifact upload logs, and runner records.

·        Clear dependency caches, package caches, and build caches that may retain affected package tarballs.

·        Rebuild runner images and build containers from known-good base images.

·        Rotate CI/CD secrets exposed to affected jobs, including repository tokens, package-publishing tokens, cloud deployment credentials, artifact credentials, signing credentials, and environment variables.

·        Review workflow files for unauthorized changes, secret dumping, external callbacks, package publication logic, or unapproved artifact handling.

·        Suspend affected release workflows until credentials, dependencies, runner images, artifacts, and workflow integrity are validated.

Source-Code and GitHub Remediation

·        Review repository creation, workflow creation, workflow modification, deploy-key changes, webhook changes, repository visibility changes, secret changes, branch protection changes, and unusual API activity after exposure.

·        Review commits, releases, tags, workflow runs, and package-publishing automation associated with exposed identities.

·        Validate repository ownership, organization membership, app integrations, OAuth authorizations, personal access tokens, fine-grained tokens, and GitHub App permissions.

·        Remove unauthorized deploy keys, webhooks, workflows, secrets, or app grants.

·        Revoke exposed tokens and replace them with scoped, short-lived, least-privilege credentials.

·        Review high-value repositories and SAP-related development repositories for unauthorized workflow or dependency changes.

npm Registry and Package-Publishing Remediation

·        Review npm token creation, token validation, token use, token revocation, package publication, version creation, maintainer changes, owner changes, access changes, and package metadata updates after exposure.

·        Validate that package publication occurred only from approved release workflows, approved maintainers, approved source locations, and expected user agents.

·        Revoke exposed npm tokens and migrate publishing to trusted publishing or equivalent short-lived identity-based publishing where feasible.

·        Restrict package-publishing authority to dedicated automation identities with least privilege.

·        Review internal packages and downstream package versions published during the exposure window.

·        Validate package provenance and release records for packages published by exposed identities.

Cloud, Secrets, and Deployment Remediation

·        Review AWS, Azure, GCP, secret-manager, key-vault, container registry, artifact repository, IAM, service-account, workload identity, and deployment activity associated with exposed identities.

·        Rotate access keys, service-account keys, deployment tokens, and secret-manager credentials present on exposed systems.

·        Review unusual cloud API activity, secret access, role assumption, access-key creation, policy changes, service-account changes, container-registry pushes, storage access, and deployment-path changes.

·        Validate that production, staging, and development deployments were not modified through exposed credentials.

·        Re-scope cloud permissions for developer, CI/CD, package-publishing, and deployment identities.

·        Enforce conditional access, MFA, just-in-time access, workload identity federation, and short-lived credentials where available.

Artifact, Mirror, and Release Remediation

·        Search internal npm mirrors, package caches, artifact repositories, containers, build images, SBOMs, and release outputs for affected package versions.

·        Remove affected versions from internal mirrors and dependency caches.

·        Rebuild artifacts created from exposed dependency sets where integrity cannot be verified.

·        Review artifact signatures, provenance records, source commits, build identifiers, release metadata, and deployment records.

·        Validate customer-facing releases, SAP-related integrations, and internal packages produced during the exposure window.

·        Document whether affected package versions were present only in dependency records or were actually installed and executed in build or release environments.

Remediation Disposition

Remediation should be treated as complete only when dependency exposure is removed, exposed credentials are rotated, affected developer and CI/CD systems are validated, source-code and package-registry activity is reviewed, cloud-control-plane activity is checked, and internal mirrors, caches, artifacts, containers, and releases are cleared or rebuilt. Package removal alone is not sufficient.

S32 — Security Control Recommendations

Security Control Recommendation Objective

Strengthen controls that prevent, detect, contain, and recover from trusted-dependency compromise in developer and CI/CD environments. Controls should reduce the likelihood that malicious npm lifecycle execution can access reusable credentials, publish packages, modify repositories, abuse cloud resources, or influence release artifacts.

Dependency and Package-Control Recommendations

·        Enforce dependency pinning and lockfile governance for SAP-related npm projects and high-risk development repositories.

·        Require review and approval for dependency changes in repositories with access to package publishing, production deployment, or sensitive source code.

·        Monitor package.json lifecycle script changes, especially preinstall, install, postinstall, prepare, prepack, and publish-related hooks.

·        Restrict install-time scripts in CI/CD workflows where packages do not require lifecycle execution.

·        Use npm ignore-scripts or equivalent controls in build paths where lifecycle scripts are not operationally required.

·        Validate internal npm mirrors before synchronizing newly published package versions.

·        Quarantine newly released package versions for high-value build environments until package metadata, lifecycle scripts, provenance, and maintainer context are reviewed.

·        Require SBOM generation for build artifacts, containers, internal packages, and release outputs.

Developer Endpoint Control Recommendations

·        Ensure endpoint process telemetry, command-line logging, parent-child process lineage, file activity, and network-by-process telemetry are enabled on developer systems.

·        Monitor package-manager execution that spawns unexpected runtimes, shells, download utilities, archive utilities, encoded commands, or loader files.

·        Monitor Bun or Node execution from dependency, cache, temporary, user-profile, or CI workspace paths.

·        Monitor access to .npmrc, SSH keys, Git credential stores, cloud credential files, Kubernetes configuration, Docker credentials, and token-like files.

·        Apply endpoint role tagging for developer workstations, release engineering systems, package-publishing systems, and self-hosted CI/CD runners.

·        Restrict long-lived credentials on developer endpoints and prefer short-lived identity-based access.

CI/CD and Build Security Recommendations

·        Use ephemeral, isolated build runners with controlled egress, restricted secrets, and minimal default permissions.

·        Separate dependency restoration jobs from release, deployment, package-publishing, and signing jobs.

·        Avoid exposing high-privilege secrets to untrusted pull request builds, dependency installation jobs, or non-release workflows.

·        Scope GitHub Actions tokens, CI/CD tokens, package-registry tokens, cloud deployment credentials, and artifact credentials to the minimum required permissions.

·        Require approval gates before package publishing, production deployment, artifact signing, or release promotion.

·        Capture and retain package-install logs, workflow logs, runner logs, cache logs, artifact logs, and outbound egress logs.

·        Rebuild self-hosted runners from clean images after suspected package execution exposure.

Source-Code Platform Control Recommendations

·        Require least-privilege GitHub tokens, GitHub App permissions, deploy keys, and automation identities.

·        Monitor repository creation, workflow creation, workflow modification, deploy-key changes, webhook changes, repository visibility changes, and secrets-related activity.

·        Require approval for workflow file changes in high-value repositories.

·        Protect .github/workflows/ paths using CODEOWNERS or equivalent repository governance.

·        Restrict GitHub Actions permissions by default and elevate only for approved workflows.

·        Review OAuth app grants, GitHub App grants, personal access tokens, fine-grained tokens, and deploy keys on a recurring basis.

·        Alert on source-code platform activity from unusual systems, source IPs, user agents, geographies, or automation contexts.

npm Registry and Publishing Control Recommendations

·        Replace long-lived npm tokens with trusted publishing or short-lived publishing mechanisms where available.

·        Restrict npm publishing to dedicated release workflows and approved automation identities.

·        Require MFA or equivalent strong authentication for maintainer and publishing accounts.

·        Monitor npm token creation, token validation, token use, package publication, maintainer changes, owner changes, access changes, and metadata changes.

·        Validate package provenance before publication and after dependency incidents.

·        Separate human maintainer accounts from automation publishing identities.

·        Maintain an emergency package-publishing freeze procedure for suspected credential theft.

Cloud and Secrets Control Recommendations

·        Replace static cloud keys with workload identity federation, short-lived credentials, or managed identity patterns where feasible.

·        Restrict cloud deployment credentials to specific workflows, repositories, branches, environments, and approval gates.

·        Monitor secret-manager, key-vault, IAM, service-account, workload identity, container registry, artifact registry, and deployment activity after developer supply-chain exposure.

·        Enforce conditional access, MFA, device trust, and source restrictions for developer, maintainer, and cloud-administrator identities.

·        Detect cloud metadata access from developer endpoints or CI/CD jobs without approved metadata-service dependency.

·        Remove broad cloud privileges from developer endpoints and default CI/CD contexts.

·        Maintain an emergency credential-rotation runbook for GitHub, npm, cloud, SSH, Kubernetes, Docker, artifact, and deployment secrets.

Network and Egress Control Recommendations

·        Restrict CI/CD runner egress to required package registries, source-code platforms, artifact systems, cloud APIs, and approved services.

·        Monitor outbound upload-like traffic from package-manager, Node, Bun, shell, or CI runner process trees.

·        Alert on egress to webhook services, raw-content hosts, paste-like services, file-sharing endpoints, unfamiliar infrastructure, or unusual GitHub API paths after package installation.

·        Use proxy, DNS, firewall, EDR network, and CI/CD egress logs to connect outbound activity to process, user, host, repository, and runner context.

·        Apply stricter egress controls to package-publishing systems, release workflows, and artifact-signing environments.

Security Control Recommendation Disposition

The recommended control set prioritizes credential minimization, lifecycle script control, CI/CD secret scoping, source-code platform governance, package-publishing restriction, cloud identity hardening, internal mirror validation, artifact assurance, and behavior-based detection. Controls should reduce both initial execution risk and downstream propagation risk.

S33 — Strategic Defensive Improvement

Strategic Defensive Improvement Objective

Improve the organization’s ability to withstand trusted-dependency compromise by reducing credential concentration, limiting install-time execution risk, increasing developer and CI/CD visibility, and strengthening software release assurance.

Strategic Improvement 1 — Treat Developer Environments as High-Value Attack Surfaces

Developer endpoints and build systems should be managed as privileged environments because they may hold source-code access, package-registry credentials, cloud credentials, deployment secrets, and artifact access. Security strategy should move beyond workstation malware prevention and include developer credential governance, package-install monitoring, runtime baselining, dependency-cache control, and release-path assurance.

Required Improvement

·        Classify developer workstations, release hosts, package-publishing systems, and CI/CD runners as high-value assets.

·        Apply stronger logging, endpoint protection, credential handling, and network controls to those systems.

·        Remove unnecessary long-lived credentials from developer endpoints.

·        Require evidence-based validation after dependency compromise events.

Strategic Improvement 2 — Reduce CI/CD Secret Exposure by Design

CI/CD workflows should be designed so dependency installation does not automatically expose broad secrets. The strongest long-term improvement is separating dependency restoration from privileged release actions.

Required Improvement

·        Split build, test, publish, sign, and deploy stages into separate trust zones.

·        Avoid injecting package-publishing, cloud deployment, signing, or production secrets into dependency installation jobs.

·        Use short-lived, scoped, identity-bound credentials.

·        Require approval and provenance checks before privileged release stages.

Strategic Improvement 3 — Build Package Trust Gates

Organizations should establish package trust gates for high-risk ecosystems and critical development stacks. Newly published package versions, lifecycle script changes, maintainer changes, and dependency updates should be reviewed before they reach privileged build or release environments.

Required Improvement

·        Gate newly published package versions before synchronization into internal mirrors.

·        Flag package lifecycle script additions or changes.

·        Require metadata, maintainer, provenance, and package-content review for critical dependencies.

·        Maintain emergency quarantine workflows for compromised package versions.

Strategic Improvement 4 — Normalize Cross-Control-Plane Telemetry

Supply-chain incidents cross endpoint, CI/CD, source-code, package-registry, cloud, identity, and network layers. The organization should normalize telemetry around shared pivots such as user, host, repository, runner, package, token, source IP, user agent, cloud identity, and artifact.

Required Improvement

·        Normalize endpoint, CI/CD, GitHub, npm, cloud, identity, artifact, DNS, proxy, and network logs into a common investigation model.

·        Preserve package-install events, workflow events, token events, cloud events, and artifact events long enough for post-exposure investigation.

·        Build correlation paths from package installation to runtime execution, credential access, egress, token use, and artifact production.

·        Validate detection logic against real developer and CI/CD workflows.

Strategic Improvement 5 — Strengthen Software Integrity Assurance

The organization should treat software release integrity as a business control, not only an engineering function. After supply-chain exposure, leaders need evidence that source code, workflows, dependencies, build outputs, containers, artifacts, and customer-facing releases remain trustworthy.

Required Improvement

·        Enforce artifact provenance, SBOM generation, signing, and build traceability.

·        Record dependency versions, build images, source commits, runner identity, workflow identity, and artifact lineage.

·        Require artifact review when dependency exposure overlaps with release windows.

·        Maintain a customer assurance playbook for software supply-chain exposure.

Strategic Defensive Improvement Disposition

Strategic improvement should focus on reducing the blast radius of trusted-dependency compromise. The durable goal is to ensure that package installation cannot easily become credential theft, credential theft cannot easily become repository or cloud abuse, and repository or build compromise cannot easily become downstream release integrity failure.

S34 — Defensive Architecture Overview

Figure 6

Defensive Architecture Objective

Define a layered defensive architecture for SAP-related npm package poisoning and Shai-Hulud-style developer credential theft. The architecture must support prevention, detection, containment, credential assurance, artifact assurance, and business-level release confidence.

Layer 1 — Dependency Intake and Package Trust

This layer governs how external npm packages enter the organization.

Required Controls

·        Internal npm mirror validation.

·        Package version quarantine for critical dependency stacks.

·        Lifecycle script review.

·        Dependency pinning and lockfile governance.

·        Package provenance validation.

·        Maintainer and metadata monitoring.

·        SBOM generation and dependency inventory.

·        Emergency package denylisting and cache purge capability.

Layer 2 — Developer Endpoint Protection

This layer detects malicious package behavior on developer workstations and release systems.

Required Controls

·        Endpoint process telemetry.

·        Full command-line logging.

·        Parent-child process lineage.

·        File access telemetry for sensitive credential paths.

·        Runtime baselining for Bun, Node, shell, PowerShell, curl, wget, archive utilities, and Python.

·        Network-by-process telemetry where available.

·        Developer endpoint role tagging.

·        Credential minimization and local secret reduction.

Layer 3 — CI/CD Runner and Workflow Security

This layer limits package-installation risk inside automation.

Required Controls

·        Separate dependency installation from privileged publish, sign, and deploy stages.

·        Minimal CI/CD token permissions.

·        Secret injection only for approved privileged stages.

·        Restricted runner egress.

·        Package-install log retention.

·        Workflow and runner identity logging.

·        Clean runner image rebuild capability.

·        Build cache and dependency cache governance.

·        Approval gates for package publishing, signing, and deployment.

Layer 4 — Source-Code Platform Governance

This layer controls GitHub or equivalent source-code platform abuse.

Required Controls

·        Workflow path protection.

·        CODEOWNERS or equivalent approval for CI/CD workflow changes.

·        Repository permission review.

·        Deploy-key governance.

·        Webhook governance.

·        App and OAuth grant review.

·        Personal access token and fine-grained token monitoring.

·        Repository creation, workflow modification, secret change, and visibility change alerting.

Layer 5 — Package Registry and Publishing Governance

This layer prevents stolen credentials from propagating compromise through package publication.

Required Controls

·        Trusted publishing or short-lived publishing credentials.

·        MFA or strong authentication for maintainers.

·        Dedicated release automation identities.

·        Package publication approval gates.

·        Maintainer and owner change monitoring.

·        Package metadata change monitoring.

·        Token creation, validation, use, and revocation monitoring.

·        Emergency publishing freeze procedures.

Layer 6 — Cloud, Secrets, and Deployment Control Plane

This layer prevents stolen credentials from becoming cloud or deployment compromise.

Required Controls

·        Workload identity federation or short-lived cloud credentials.

·        Secret-manager and key-vault access monitoring.

·        IAM, service-account, role, and policy change monitoring.

·        Container registry and artifact registry monitoring.

·        Deployment-path approval gates.

·        Conditional access and MFA for privileged identities.

·        Cloud audit log retention.

·        Emergency key rotation and deployment credential revocation.

Layer 7 — Network and Egress Control

This layer detects and restricts suspicious outbound transfer.

Required Controls

·        DNS, proxy, firewall, TLS, EDR network, and CI/CD egress telemetry.

·        Process-attributed egress where available.

·        CI/CD runner egress allowlisting.

·        Monitoring for upload-like traffic after package installation.

·        Monitoring for GitHub API, webhook, raw-content, paste-like, file-sharing, cloud-storage, and unfamiliar destinations after credential access.

·        Destination novelty and source-role analysis.

Layer 8 — Artifact and Release Assurance

This layer validates whether compromised dependencies influenced released software.

Required Controls

·        Artifact provenance.

·        SBOM records.

·        Build-to-source traceability.

·        Container image digest tracking.

·        Artifact signing and verification.

·        Release approval records.

·        Internal mirror and dependency-cache review.

·        Customer-facing release validation after exposure.

Defensive Architecture Disposition

The defensive architecture must treat dependency installation, developer credentials, CI/CD secrets, source-code platforms, package registries, cloud resources, egress paths, and release artifacts as one connected trust system. Strong posture requires visibility and control at every layer because the attack chain can shift from package execution to credential reuse and downstream software-integrity uncertainty.

S35 — Security Hardening Guidance

Security Hardening Objective

Provide implementation-ready hardening guidance that reduces future exposure to npm package poisoning, developer credential theft, CI/CD secret exposure, and downstream propagation.

Dependency and npm Hardening

·        Pin critical dependencies and require lockfile review for SAP-related npm projects.

·        Use npm audit, package metadata review, package provenance checks, and dependency intelligence for critical packages.

·        Monitor package lifecycle scripts and alert on new or modified preinstall, install, postinstall, prepare, prepack, or publish hooks.

·        Disable lifecycle scripts in CI/CD jobs where they are not required.

·        Require approval before synchronizing newly published critical package versions into internal mirrors.

·        Purge affected package tarballs from internal mirrors, dependency caches, and build caches.

·        Maintain a denylist process for compromised packages and versions.

·        Require SBOM generation for builds involving SAP-related packages.

Developer Endpoint Hardening

·        Enable full process creation, command-line, parent-child lineage, file activity, and network-by-process telemetry.

·        Alert on package managers spawning unexpected runtimes, shells, downloaders, archive utilities, Python, or encoded commands.

·        Alert on Bun execution where Bun is not approved.

·        Restrict storage of long-lived GitHub, npm, SSH, cloud, Kubernetes, Docker, deployment, and CI/CD credentials on developer endpoints.

·        Use credential managers, short-lived access, device-bound tokens, and conditional access.

·        Enforce least privilege for developer access to repositories, package registries, cloud environments, and deployment systems.

·        Review developer endpoint software inventory for unapproved runtime tooling.

CI/CD Hardening

·        Run dependency restoration in low-privilege jobs without package-publishing, deployment, signing, or production credentials.

·        Use isolated runners for untrusted builds, pull requests, package installation, publishing, signing, and deployment.

·        Restrict workflow token permissions by default.

·        Avoid exposing secrets to pull request builds from untrusted or less-trusted contexts.

·        Use short-lived credentials for package publishing and cloud deployment.

·        Require approval before privileged release stages.

·        Retain workflow logs, package-install logs, cache logs, artifact logs, and runner records.

·        Rebuild self-hosted runners regularly and after suspected exposure.

GitHub and Source-Code Platform Hardening

·        Protect .github/workflows/ or equivalent CI/CD configuration paths with mandatory review.

·        Require CODEOWNERS or equivalent approval for workflow changes.

·        Restrict repository administration permissions to approved roles.

·        Review deploy keys, webhooks, GitHub Apps, OAuth Apps, personal access tokens, and fine-grained tokens.

·        Alert on repository creation, visibility changes, deploy-key changes, webhook changes, workflow changes, and secrets-related activity.

·        Enforce branch protection and signed commits where appropriate.

·        Use least-privilege automation identities for repository and workflow operations.

npm Publishing Hardening

·        Replace long-lived npm tokens with trusted publishing or short-lived identity-based publishing where available.

·        Require MFA or equivalent strong authentication for package maintainers.

·        Separate maintainer accounts from automation publishing identities.

·        Restrict package publishing to approved workflows and source locations.

·        Monitor package publication, maintainer changes, ownership changes, access changes, metadata changes, and token events.

·        Require package provenance and release approval for critical packages.

·        Maintain an emergency publishing freeze and token revocation procedure.

Cloud and Secret Hardening

·        Replace static cloud keys with workload identity federation, managed identities, or short-lived credentials.

·        Restrict cloud deployment credentials to specific repositories, workflows, branches, and environments.

·        Monitor secret-manager access, key-vault access, service-account changes, access-key creation, IAM changes, and role assignment activity.

·        Limit developer endpoint access to production cloud credentials.

·        Enforce conditional access, MFA, device posture, and source restrictions for privileged cloud and developer identities.

·        Review Kubernetes, Docker, artifact registry, and container registry credentials after exposure.

·        Maintain automated credential inventory for developer and CI/CD secrets.

Network and Egress Hardening

·        Restrict CI/CD runner outbound access to required services.

·        Alert on new or unusual egress from build systems to webhook, raw-content, paste-like, file-sharing, cloud-storage, or unfamiliar destinations.

·        Monitor upload-like traffic after package installation, credential access, or local staging.

·        Capture DNS, proxy, firewall, TLS, and EDR network telemetry with source host, user, process, runner, repository, and destination context.

·        Apply stricter outbound controls for package-publishing systems, release systems, and artifact-signing systems.

Artifact and Release Hardening

·        Require artifact signing and provenance records for release outputs.

·        Generate and retain SBOMs for packages, containers, and release artifacts.

·        Track source commit, dependency set, build image, runner identity, workflow identity, and artifact digest for each release.

·        Validate artifacts created during dependency exposure windows.

·        Rebuild artifacts when provenance cannot be trusted.

·        Maintain a customer assurance process for software supply-chain incidents.

Security Hardening Disposition

Security hardening should focus on reducing credential exposure, restricting install-time execution, improving telemetry, limiting CI/CD privilege, governing package publishing, and preserving release integrity. The goal is not only to stop this incident type, but to reduce the business blast radius when trusted dependencies are compromised again.

S36 — Security Program Maturity Assessment

Security Program Maturity Objective

Assess the maturity of controls needed to prevent, detect, respond to, and recover from npm package poisoning and developer credential theft. Maturity is measured by dependency visibility, credential governance, CI/CD isolation, package-publishing control, source-code platform monitoring, cloud-control-plane oversight, telemetry correlation, and artifact assurance.

Initial Maturity

Organizations at this level can identify limited package exposure but cannot reliably determine whether installation led to execution, credential access, token reuse, or artifact impact.

Characteristics

·        Dependency inventory is incomplete or limited to selected repositories.

·        Internal mirrors, dependency caches, and build artifacts are not centrally searchable.

·        CI/CD runners lack process-level visibility.

·        Developer endpoint command-line and file-access telemetry are incomplete.

·        GitHub, npm, cloud, identity, and artifact logs are not centrally correlated.

·        Long-lived credentials are common on developer endpoints and CI/CD systems.

·        Artifact provenance and SBOM coverage are limited.

Risk Posture

High residual risk because the organization may identify exposure but remain unable to confirm or disprove execution, credential theft, downstream abuse, or release impact.

Developing Maturity

Organizations at this level can scope dependency exposure and review some developer, CI/CD, source-code, package-registry, cloud, and artifact data, but investigation remains manually coordinated and uneven across environments.

Characteristics

·        Dependency and lockfile review exists for critical repositories.

·        Endpoint process telemetry is available for many developer systems.

·        CI/CD logs, GitHub audit logs, npm events, and cloud audit logs are retained for some environments.

·        Credential rotation procedures exist but are not consistently automated or centrally tracked.

·        Package-publishing controls exist but may still rely on long-lived tokens.

·        Artifact provenance exists for selected release paths.

·        Supply-chain response playbooks exist but require manual coordination across teams.

Risk Posture

Moderate to High residual risk because response capability exists, but telemetry gaps, manual correlation, and inconsistent credential governance can delay containment and assurance.

Managed Maturity

Organizations at this level can correlate dependency exposure, package execution, credential access, source-code activity, registry activity, cloud activity, egress, and artifact production across critical development and release environments.

Characteristics

·        Critical dependency inventory and SBOM coverage are maintained.

·        Internal mirrors, dependency caches, and build artifacts are searchable.

·        Developer endpoints and self-hosted CI/CD runners have strong process and command-line telemetry.

·        GitHub, npm, cloud, identity, DNS, proxy, and artifact logs are centrally available.

·        CI/CD secrets are scoped and separated from dependency installation jobs.

·        Package publishing uses controlled workflows and least-privilege automation identities.

·        Artifact provenance and release traceability exist for high-value releases.

·        Supply-chain incident response is rehearsed and role-based.

Risk Posture

Moderate residual risk because exposure can be scoped and contained, but managed runners, ephemeral workloads, encrypted egress, third-party dependencies, and incomplete token lineage can still create uncertainty.

Optimized Maturity

Organizations at this level operate supply-chain security as an integrated trust program across developer endpoints, CI/CD, package registries, source-code platforms, cloud environments, artifacts, and business assurance.

Characteristics

·        Dependency intake, package provenance, SBOM, and artifact assurance are integrated into development and release workflows.

·        CI/CD workflows separate dependency restoration from privileged publish, sign, and deploy stages.

·        Long-lived developer and CI/CD credentials are minimized or eliminated.

·        Package publishing uses trusted publishing, short-lived credentials, and strong approval controls.

·        Source-code platform, npm, cloud, identity, endpoint, and network telemetry are normalized and correlated.

·        Internal mirrors and caches support rapid quarantine and purge.

·        Release artifacts are traceable to source commit, dependency set, build image, runner, workflow, and signer.

·        Supply-chain incident response includes customer assurance, legal, governance, and executive escalation procedures.

Risk Posture

Lower residual risk because compromise can still occur, but blast radius is constrained, credential exposure is minimized, detection is faster, and release integrity can be validated with higher confidence.

Security Program Maturity Disposition

Managed maturity should be the minimum target posture for organizations with SAP development, package-publishing authority, CI/CD automation, or cloud deployment workflows tied to npm dependencies. Optimized maturity is recommended where customer-facing releases, regulated data, production cloud access, or downstream software assurance obligations are material.

S37 — Residual Risk and Forward Outlook

Figure 7

Residual Risk Objective

Define the remaining risk after mitigation, remediation, hardening, and security-control improvements. Residual risk remains because dependency ecosystems, developer credentials, CI/CD automation, package publishing, cloud deployment, and artifact production continue to rely on trusted third-party and open-source components.

Residual Risk Assessment

Residual risk remains Moderate to High until the organization confirms whether affected package versions were installed, whether lifecycle execution occurred, whether credentials were accessible, whether tokens were reused, whether source-code or package-registry activity changed, whether cloud-control-plane activity occurred, and whether artifacts or releases were influenced by exposed dependency sets.

Primary Residual Risks

·        Affected package versions may persist in internal mirrors, dependency caches, build images, containers, or artifacts.

·        Credential theft may have occurred without direct file-read telemetry.

·        Stolen tokens may be reused after malicious package removal.

·        Managed runners and ephemeral build containers may prevent complete forensic reconstruction.

·        GitHub, npm, cloud, and identity logs may not fully preserve token lineage or source context.

·        Encrypted egress may prevent content-level confirmation of stolen material.

·        Package-publishing authority may remain overprivileged.

·        Release artifacts may require assurance even when direct tampering is not confirmed.

·        Customer-facing impact may remain uncertain until artifact provenance and release history are validated.

Residual Risk Reduction Requirements

·        Complete dependency, lockfile, cache, mirror, SBOM, artifact, and release review.

·        Complete credential rotation and token revocation for exposed systems and identities.

·        Validate GitHub, npm, cloud, identity, CI/CD, artifact, and network activity after exposure.

·        Confirm that affected package versions are removed from internal mirrors and caches.

·        Rebuild or revalidate artifacts created during the exposure window.

·        Implement package lifecycle controls and CI/CD secret scoping.

·        Strengthen telemetry across developer endpoints, CI/CD runners, source-code platforms, npm, cloud, identity, and egress.

·        Document assurance outcomes for executive, legal, customer, and board-level stakeholders.

Forward Outlook

npm package poisoning and developer credential theft will remain a recurring supply-chain risk because modern software development depends on external packages, package registries, automated builds, reusable developer credentials, CI/CD secrets, and cloud deployment automation. Shai-Hulud-style tradecraft demonstrates that supply-chain actors can use package ecosystems not only for initial execution, but also for credential theft, propagation, and downstream software-trust disruption.

Executive Forward View

Organizations should expect future campaigns to vary package names, loader files, runtime choices, infrastructure, and exfiltration methods while retaining the same high-value behaviors: trusted dependency execution, developer credential discovery, token theft, package-registry abuse, source-code platform abuse, and conditional cloud or release-path compromise. Durable defense depends on behavior-based detection, least-privilege credentials, controlled package publishing, CI/CD secret isolation, internal mirror governance, and release artifact assurance.

Residual Risk Disposition

Residual risk can be reduced to Moderate or Low only after exposure scoping, credential assurance, package-cache cleanup, source-code and npm audit review, cloud validation, artifact review, and telemetry improvements are complete. Until then, the organization should treat privileged developer and CI/CD exposure as a material software supply-chain risk requiring executive oversight.

S38 — Intelligence Confidence Assessment

Intelligence Confidence Objective

Assess confidence in the analytical conclusions for the SAP-related npm package poisoning and Shai-Hulud-style developer credential theft report. Confidence is based on public reporting consistency, alignment with the completed detection model, affected package details, reported malicious behavior, and the limits of organization-specific exposure validation.

Overall Intelligence Confidence

High.

Confidence Basis

·        Multiple current public reports consistently identify compromise of SAP-related npm packages.

·        Reporting consistently describes malicious install-time package behavior, including a package.json preinstall hook, setup.mjs loader behavior, Bun runtime execution, credential theft, encrypted handling, and Mini Shai-Hulud or TeamPCP-style supply-chain activity.

·        The completed Block 4 detection model aligns with the reported behavior chain: npm lifecycle execution, unexpected Bun or Node execution, developer and CI/CD credential access, GitHub and npm abuse review, cloud-control-plane review, suspicious egress, and artifact or dependency-cache validation.

·        MITRE ATT&CK mapping is limited to an evidence-aligned chain and avoids unnecessary speculative techniques.

·        The report treats propagation, cloud misuse, artifact compromise, and downstream customer impact as conditional unless validated by telemetry.

High-Confidence Judgments

·        The incident should be governed as a supply-chain trusted-dependency compromise, not as a CVE-led vulnerability report.

·        The primary enterprise risk is developer and CI/CD credential theft following malicious package installation.

·        Package presence alone does not prove compromise; execution context and credential exposure determine business impact.

·        npm lifecycle execution is a critical detection and containment pivot.

·        Bun or Node execution from dependency, cache, temporary, user-profile, or CI workspace paths is a high-value behavioral signal where not approved.

·        GitHub, npm, cloud, identity, CI/CD, artifact, and network telemetry are required to determine whether exposure progressed into credential reuse or downstream abuse.

·        Package removal alone is not sufficient remediation because stolen credentials may remain valid after the malicious package is removed.

·        Internal mirrors, dependency caches, build images, SBOMs, containers, and release artifacts may preserve exposure after public registry remediation.

Moderate-Confidence Judgments

·        Credential theft risk is materially elevated where affected package versions were installed on developer systems, self-hosted CI/CD runners, release systems, or package-publishing systems.

·        Encrypted exfiltration and developer-platform abuse may reduce visibility unless process, file, network, identity, and source-code platform telemetry are correlated.

·        Organizations using SAP CAP, SAP cloud development workflows, MTA build processes, S/4HANA extensions, Fiori application backends, or SAP-related JavaScript development are more likely to require exposure review.

·        Downstream propagation risk exists where stolen GitHub or npm credentials have sufficient repository, workflow, or package-publishing scope.

·        Cloud-control-plane exposure is plausible where affected environments held cloud credentials, service-account keys, deployment tokens, workload identity credentials, or secret-manager access.

Lower-Confidence / Conditional Judgments

·        Confirmed cloud abuse cannot be assumed without cloud audit evidence.

·        Confirmed repository, workflow, or package propagation cannot be assumed without GitHub, npm, CI/CD, or artifact evidence.

·        Confirmed release artifact compromise cannot be assumed without build, artifact, SBOM, provenance, or release validation evidence.

·        Confirmed customer-facing impact cannot be assumed without release-path and distribution evidence.

·        Precise financial impact requires organization-specific exposure, credential scope, artifact lineage, regulatory context, and response-cost data.

Telemetry Confidence Assessment

Endpoint and Developer Workstation Telemetry

Moderate to High where process creation, command line, parent-child lineage, file access, runtime path, and network-by-process telemetry are enabled. Confidence is reduced where developer systems lack command-line logging, sensitive file-access telemetry, or process-linked egress.

CI/CD and Build Telemetry

Moderate where workflow logs, package-install logs, runner identity, cache logs, artifact logs, and job history are retained. Confidence is reduced for managed runners, ephemeral build containers, and workflows without process-level visibility.

GitHub and Source-Code Platform Telemetry

Moderate to High where enterprise audit logs, repository events, workflow changes, token activity, deploy-key activity, webhook changes, user-agent, and source-IP context are retained. Confidence is reduced where personal repositories, external maintainer accounts, incomplete audit depth, or short retention periods limit visibility.

npm Registry and Package-Publishing Telemetry

Moderate where npm package-publication, token, maintainer, owner, access, provenance, and metadata events are centrally retained. Confidence is reduced where token attribution, source IP, user agent, or release automation context is incomplete.

Cloud and Secrets Telemetry

Moderate where AWS, Azure, GCP, identity, secret-manager, key-vault, IAM, service-account, workload identity, container registry, and deployment logs are available. Confidence is reduced where credentials are reusable but not strongly attributable to source systems or workflows.

Network and Egress Telemetry

Moderate where DNS, proxy, TLS, firewall, EDR network, and CI/CD egress logs can be tied to source host, process, user, runner, repository, and timing. Confidence is reduced where TLS encryption, common developer destinations, and missing process attribution limit exfiltration assessment.

Artifact and Release Telemetry

Moderate to High where SBOMs, build provenance, artifact signatures, source commits, dependency sets, build images, runner identity, workflow identity, and release metadata are retained. Confidence is reduced where build provenance is incomplete or artifacts cannot be traced to dependency state.

Intelligence Confidence Disposition

The overall intelligence confidence is High for the report’s governing conclusion: this is a trusted-dependency supply-chain compromise with developer and CI/CD credential-theft risk. Confidence is Moderate for organization-specific impact until dependency exposure, lifecycle execution, credential access, token reuse, cloud activity, GitHub activity, npm activity, artifact lineage, and release integrity are validated in the affected environment.

S39 — Economic Impact & Organizational Exposure

Organizational Exposure Overview

npm package poisoning and Shai-Hulud-style developer credential theft create organizational exposure by turning trusted dependency installation into attacker-controlled execution, developer credential access, CI/CD secret exposure, source-code platform abuse, package-registry abuse, cloud-control-plane risk, artifact-integrity uncertainty, and downstream software-trust disruption.

Exposure rises when compromised, suspicious, cached, mirrored, or restored packages are installed or executed on developer workstations, CI/CD runners, build images, release systems, package-publishing systems, internal package mirrors, artifact repositories, container-build systems, SAP development environments, AI application-development environments, or cloud-connected software-delivery workflows.

The business risk is not limited to one package name, affected version, namespace, loader file, runtime name, hash, infrastructure indicator, actor label, campaign label, or package ecosystem. The strategic exposure is that adversaries can convert trusted dependency execution into credential theft, GitHub or npm token abuse, cloud credential misuse, repository modification, workflow abuse, package publication, internal mirror persistence, poisoned build outputs, release-integrity uncertainty, and executive concern over whether software delivery systems remain trustworthy.

Prior Coverage and Supersedence Context

Prior Shai-Hulud and Mini Shai-Hulud coverage should be treated as historical lineage and campaign-context coverage, not as the current definitive CyberDax coverage package. The current report modernizes that coverage by framing npm package poisoning as a trusted-dependency execution and developer credential-theft problem with direct implications for CI/CD, source-code platforms, package registries, cloud credentials, dependency caches, internal mirrors, build artifacts, and customer-facing software assurance.

The current report should remain the modernized SUP coverage anchor for npm lifecycle execution abuse, Shai-Hulud-style developer credential theft, SAP npm package poisoning, Mini Shai-Hulud and TeamPCP-style package compromise behavior, AI-framework npm namespace compromise, package-manager lifecycle abuse, developer and CI/CD secret access, GitHub and npm token abuse, cloud credential exposure, conditional propagation, and downstream release-integrity uncertainty.

This does not mean every future package compromise is automatically covered. Future npm, PyPI, Packagist / Composer, AI-framework, SAP-development, or developer-tooling supply-chain activity should be evaluated against this behavior-led detection model before deciding whether it needs a new report, an amendment, or Already Covered / Track Only handling.

Estimated Economic Exposure

Estimated exposure should be treated as scenario-based rather than fixed. The most defensible estimate depends on whether activity remains limited to dependency presence or internal mirror retention, progresses into confirmed or suspected install-time execution on developer or CI/CD systems, or expands into credential theft, GitHub or npm abuse, cloud-control-plane activity, package-publishing abuse, repository modification, poisoned artifacts, customer-facing release uncertainty, legal review, cyber-insurance scrutiny, executive reporting, or board-level software-trust governance.

Low Impact Scenario

Estimated $250K - $1M.

This scenario applies when exposure is limited to dependency presence, internal mirror retention, package-cache retention, lockfile presence, SBOM presence, or a small number of non-privileged developer systems, and investigation confirms no malicious lifecycle execution, no credential access, no suspicious egress, no GitHub abuse, no npm abuse, no cloud-control-plane activity, no CI/CD compromise, and no affected release artifact.

Response remains limited to exposure scoping, dependency cleanup, internal mirror review, package-cache cleanup, limited endpoint review, narrow credential validation, detection tuning, and executive assurance that affected dependency sets did not execute in privileged developer, CI/CD, package-publishing, cloud-connected, or customer-facing release contexts.

Moderate Impact Scenario

Estimated $1.5M - $8M.

This scenario applies when one or more developer systems, build environments, release workflows, dependency caches, internal package mirrors, AI development environments, SAP development environments, or CI/CD systems were exposed to compromised package versions and the organization cannot immediately prove whether lifecycle execution, credential access, local staging, suspicious egress, GitHub activity, npm activity, cloud activity, or artifact impact occurred.

Response may require broader endpoint investigation, CI/CD log review, GitHub audit review, npm registry review, source-code platform review, cloud-control-plane review, token revocation, credential rotation, package-cache cleanup, internal mirror validation, build-image review, artifact provenance review, SBOM review, detection tuning, legal consultation, customer-assurance preparation, and executive incident coordination.

High Impact Scenario

Estimated $10M - $75M+.

This scenario applies when malicious package execution results in confirmed or strongly suspected theft of GitHub tokens, npm tokens, SSH material, cloud keys, package-publishing credentials, CI/CD secrets, deployment credentials, LLM API keys, SaaS API keys, or artifact-signing authority, enabling repository modification, workflow abuse, package publication, cloud-control-plane activity, source-code exposure, poisoned artifacts, downstream customer exposure, or prolonged software-integrity uncertainty.

The organization may need to assume that developer credentials, CI/CD secrets, package-registry authority, cloud deployment paths, source-code repositories, build systems, internal package mirrors, release artifacts, and customer-facing software integrity were exposed until validated through telemetry and provenance evidence. Response may require enterprise credential rotation, source-code review, package-publishing audit, cloud activity review, artifact rebuild, release pause, customer assurance, legal and regulatory notification analysis, cyber-insurance engagement, executive communications, and board-level reporting.

Annualized Risk Exposure

Estimated $3M - $20M+ for materially exposed enterprise environments with active software development, centralized CI/CD, privileged developer identities, internal package mirrors, cloud-connected release workflows, SAP development activity, AI application development, package-publishing authority, broad GitHub or npm token use, artifact-signing authority, or customer-facing release obligations.

Exposure may exceed $20M - $75M+ where malicious package execution results in confirmed or strongly suspected credential theft, GitHub abuse, npm package publication, repository modification, CI/CD workflow compromise, cloud-control-plane access, source-code exposure, poisoned build outputs, customer-facing software-integrity uncertainty, regulatory review, cyber-insurance scrutiny, or board-level governance.

Operational Dependency

Operational dependency is high where software development, CI/CD automation, package restoration, source-code management, package publishing, cloud deployment, artifact signing, internal package mirrors, build images, containers, release workflows, SAP application development, AI application development, or customer-facing software delivery support normal business operations.

Dependency increases when affected systems support production deployment, customer-facing software, regulated workflows, financial systems, supply-chain systems, healthcare systems, manufacturing operations, identity workflows, cloud environments, SaaS integrations, LLM-enabled services, customer data, source-code repositories, or release artifacts.

Control Trust

Control trust is reduced when the organization cannot prove that package-manager activity, lifecycle-script execution, runtime execution, credential access, file staging, outbound transfer, GitHub activity, npm activity, CI/CD workflow activity, cloud-control-plane activity, internal mirror synchronization, build-image creation, artifact signing, and release promotion remained authorized during the exposure window.

Control trust is further reduced when exposed developer or CI/CD systems held reusable credentials, package-publishing authority, source-code write access, cloud deployment credentials, LLM API keys, SaaS tokens, artifact-signing authority, or customer-facing release permissions.

Visibility Confidence

Visibility confidence is highest when endpoint process telemetry, command-line logging, file-access telemetry, package-manager logs, CI/CD job logs, GitHub audit logs, npm registry logs, cloud audit logs, identity telemetry, DNS logs, proxy logs, EDR network telemetry, NDR telemetry, dependency-cache records, internal mirror logs, SBOM records, artifact metadata, and release provenance can be correlated reliably.

Visibility confidence is reduced where managed CI/CD runners are ephemeral, command lines are missing, file-access telemetry is unavailable, package-install logs are incomplete, npm audit depth is limited, GitHub audit retention is short, cloud logs are not centrally retained, proxy visibility is weak, egress is encrypted, or internal package mirrors and build caches lack historical records.

Change-Control Confidence

Change-control confidence is high when package updates, dependency restoration, lockfile changes, package-publishing actions, CI/CD workflow changes, GitHub repository changes, npm maintainer changes, cloud deployment activity, internal mirror synchronization, build-image updates, artifact signing, release promotion, and emergency response actions are documented and attributable.

Confidence is reduced when approved dependency changes are poorly documented, package-publishing authority is overprivileged, CI/CD secrets are broadly scoped, GitHub workflow changes are not reviewed, npm maintainer activity is not baselined, internal mirrors synchronize automatically without review, or incident-response actions cannot be separated from suspicious activity.

Downstream Dependency

Downstream dependency is high when affected developer systems, CI/CD runners, package-publishing workflows, internal mirrors, artifact repositories, source-code repositories, cloud resources, SAP workloads, AI services, customer-facing software, container registries, release artifacts, or deployment workflows depend on the same credentials or automation paths that may have been exposed.

These dependencies increase the impact of even limited package exposure when the organization cannot quickly prove whether lifecycle execution occurred, whether credentials were accessible, whether credentials were reused, whether package publication changed, whether workflows were modified, whether cloud resources were accessed, whether build outputs were affected, or whether customer-facing releases were built from exposed dependency sets.

Customer and Regulatory Exposure

Customer and regulatory exposure increases when malicious package execution may affect customer-facing software, regulated data, proprietary source code, production cloud resources, software releases, package integrity, artifact provenance, deployment workflows, customer integrations, financial systems, healthcare systems, supply-chain systems, or AI-enabled services.

Exposure also increases when incomplete telemetry prevents timely confirmation of whether credential theft, source-code exposure, package-publishing abuse, cloud-control-plane access, artifact tampering, or downstream customer impact occurred.

Residual Economic Risk

Residual economic risk remains after package removal if the organization cannot prove that exposed credentials were rotated, tokens were revoked, GitHub activity was reviewed, npm activity was reviewed, cloud activity was validated, package caches were cleaned, internal mirrors were cleared, affected build images were rebuilt, artifacts were validated, CI/CD workflows were reviewed, source-code repositories were checked, and release outputs were confirmed trustworthy.

Residual risk is highest where endpoint telemetry, CI/CD telemetry, GitHub audit logs, npm audit logs, cloud audit logs, identity logs, proxy logs, NDR visibility, internal mirror records, package-cache records, artifact metadata, SBOMs, release records, or incident-response records are incomplete.

Supply-Chain Behavioral Coverage Assessment

This report’s behavioral detection model directly covers trusted package compromise activity that aligns with npm lifecycle execution abuse, package-manager-spawned runtime execution, unexpected Bun or Node execution, developer credential discovery, CI/CD secret exposure, local staging, suspicious egress, GitHub token abuse, npm token abuse, cloud credential exposure, conditional package propagation, internal mirror persistence, artifact provenance risk, and downstream software-integrity uncertainty.

The report is behavior-led and should not be interpreted as limited to one SAP package, one npm namespace, one malicious dependency, one loader filename, one runtime name, one actor label, one public report, one registry event, one package version, one hash, one IP address, one domain, or one IOC.

CVE / Vulnerability Coverage Assessment

No CVE is counted as direct coverage for this report.

This report is not governed by exploitation of a conventional software vulnerability. The governing exposure is abuse of trusted package publishing, dependency resolution, package-manager lifecycle behavior, developer credential concentration, CI/CD secret exposure, source-code platform trust, package-registry authority, and cloud-connected release automation.

Known Exploited Vulnerability Coverage Assessment

No CISA KEV item is counted as direct coverage from the current source set for this SUP report.

KEV status should remain a remediation, urgency, exposure-management, and prioritization signal when relevant to a future related access path. KEV status is not detection proof by itself and should not be used to represent coverage unless the vulnerability produces behavior that aligns with the report’s trusted-dependency execution, credential-theft, CI/CD exposure, package-registry abuse, or software-integrity detection model.

CVEs Covered With Adaptation

No CVEs are counted as covered with adaptation in this report.

Future CVEs affecting package registries, package managers, source-code platforms, CI/CD platforms, artifact repositories, internal mirrors, cloud secret stores, or software-build systems should only be added after source validation and behavior-to-telemetry alignment with this report’s detection model.

Named Malware / Tooling / PhaaS Coverage

Shai-Hulud

Direct coverage. Latest source date: 2026.

Covered where observable activity aligns with malicious package publication, lifecycle-script execution, developer credential discovery, GitHub token theft, npm token theft, cloud credential exposure, local staging, exfiltration, GitHub workflow abuse, npm propagation, or downstream package compromise.

Mini Shai-Hulud

Direct coverage. Latest source date: 2026.

Covered where observable activity aligns with package ecosystem compromise, install-time execution, Bun or Node runtime execution, developer and CI/CD secret access, GitHub or npm token abuse, suspicious egress, and conditional propagation through package or repository trust paths.

SAP npm package poisoning

Direct coverage. Latest source date: 2026.

Covered where observable activity aligns with compromised SAP-related npm package versions, package-manager lifecycle execution, setup.mjs-style loader behavior, Bun or Node execution, developer credential theft, CI/CD secret exposure, GitHub or npm activity, cloud-control-plane review, package-cache exposure, internal mirror retention, artifact provenance review, or release-integrity uncertainty.

Bun runtime abuse in package-install context

Direct coverage. Latest source date: 2026.

Covered where observable activity aligns with Bun launched by npm, pnpm, yarn, shell, or CI/CD runner processes during dependency installation, especially when followed by credential discovery, file staging, outbound transfer, GitHub activity, npm activity, or cloud activity.

GitHub token abuse following package execution

Direct coverage. Latest source date: stable public technique reference.

Covered where observable activity aligns with repository creation, workflow modification, deploy-key changes, webhook changes, repository visibility changes, unusual API use, secret-related activity, suspicious exfiltration to GitHub, or source-code platform access following package lifecycle execution or developer credential exposure.

npm token and package-publishing abuse

Direct coverage. Latest source date: stable public technique reference.

Covered where observable activity aligns with token validation, package publication, package metadata modification, maintainer changes, ownership changes, access changes, provenance anomalies, or unusual publishing activity following compromised package installation or credential exposure.

Cloud credential exposure following developer or CI/CD package execution

Direct coverage. Latest source date: stable public technique reference.

Covered where observable activity aligns with AWS, Azure, GCP, Kubernetes, Docker, secret-manager, container-registry, storage, IAM, deployment, or service-account activity following package lifecycle execution, developer credential discovery, CI/CD secret exposure, or suspicious egress.

Named APT / Actor / Campaign Activity Coverage

Sapphire Sleet / BlueNoroff

Coverage with adaptation as Microsoft attribution context. Latest source date: 17 June 2026.

Covered with adaptation where observable activity aligns with the Mastra AI npm supply-chain compromise, malicious dependency insertion, install-time or postinstall execution, credential theft, LLM API-key exposure, cloud credential exposure, CI/CD secret access, or package-registry abuse. Actor attribution is not required for detection and should not be asserted in a local event without supporting incident-specific evidence.

TeamPCP

Coverage with adaptation as reported developer supply-chain activity context. Latest source date: 2026.

Covered with adaptation where observable behavior aligns with Mini Shai-Hulud-style multi-ecosystem package compromise, package lifecycle execution, developer credential theft, GitHub-hosted payload retrieval, temporary-path execution, CI/CD runner exposure, or source-code and package-registry abuse. TeamPCP naming should remain enrichment unless supported by incident-specific evidence.

Associated Context Not Counted as Coverage

These items are relevant to intelligence context, source tracking, ecosystem expansion, or possible future amendment scoping, but they are not counted as direct coverage unless behavior aligns with the report’s detection model and source validation supports inclusion.

Unrelated npm typosquatting without install-time execution or credential access

Associated context only.

Cryptocurrency-wallet-only package theft without developer, CI/CD, package-registry, cloud, or release-path behavior

Associated context only.

Package reputation findings without execution evidence

Associated context only.

Generic vulnerable dependency inventory

Associated context only.

Unrelated SaaS token theft not linked to package execution

Associated context only.

Unrelated cloud-control-plane anomalies without upstream package-execution or credential-exposure context

Associated context only.

Non-Coverage Conditions

Non-coverage applies where related activity does not produce observable trusted-dependency execution, package-manager lifecycle abuse, runtime execution from dependency or build paths, developer credential access, CI/CD secret exposure, local staging, suspicious egress, GitHub token abuse, npm token abuse, package-publishing abuse, cloud credential exposure, internal mirror persistence, artifact uncertainty, or validated incident-response evidence aligned with this report’s detection model.

Activity limited to unrelated phishing, unrelated endpoint malware, unrelated SaaS abuse, network-only anomalies, package reputation alerts, static package naming, isolated dependency inventory, generic typosquatting, unrelated cryptocurrency theft, unrelated webshell activity, unrelated CVE exploitation, unrelated actor reporting, or unrelated malware naming should not be represented as covered by this report.

A package ecosystem, malware name, actor name, campaign label, namespace, affected package list, or public reporting label should not be counted when coverage depends only on branding, infrastructure indicators, static IOCs, package names, hashes, actor attribution, vendor naming, scanner labels, or victim reports rather than observable behavior aligned with the report’s detection model.

Detection Engineering Coverage Interpretation

The S25 detection content provides direct behavioral coverage for package-manager lifecycle execution abuse, unexpected Bun or Node execution, developer and CI/CD secret discovery, GitHub token abuse, npm token abuse, cloud credential exposure, suspicious egress, package-registry abuse, internal mirror exposure, package-cache persistence, artifact provenance risk, and conditional propagation where observable activity aligns with the report’s S21 through S25 strategy.

Coverage with adaptation applies to additional package ecosystems, AI-framework ecosystems, package managers, actor-attributed incidents, and future supply-chain events when observable behavior aligns with trusted-dependency execution, credential theft, CI/CD exposure, package-registry abuse, cloud-control-plane risk, or software-integrity uncertainty.

Named malware, tooling, actor, and campaign coverage should remain behavior-led. Names should not be used as detection inputs unless they are locally approved enrichment fields supporting triage.

Direct Coverage

Direct behavioral coverage applies to the report’s first-class detection lanes and items that can be detected by the S21 through S25 strategy without requiring a separate detection model.

SAP npm package poisoning

Directly covered.

Shai-Hulud-style npm developer credential theft

Directly covered.

Mini Shai-Hulud-style npm package lifecycle execution and propagation behavior

Directly covered.

Bun runtime abuse in package-install context

Directly covered.

GitHub token abuse following package execution

Directly covered.

npm token and package-publishing abuse following package execution

Directly covered.

Cloud credential exposure following developer or CI/CD package execution

Directly covered.

Coverage With Adaptation

Coverage with adaptation applies to related package ecosystems, actor labels, tooling names, campaign labels, or activity that shares parts of the report’s trusted-dependency execution, credential-theft, CI/CD exposure, package-registry abuse, cloud-credential, or artifact-assurance model but requires local tuning for ecosystem, platform, package manager, runtime, telemetry source, package name, namespace, actor context, or implementation environment.

Mastra AI npm supply-chain compromise / easy-day-js

Covered with adaptation.

Sapphire Sleet / BlueNoroff Mastra attribution context

Covered with adaptation.

TeamPCP-style developer supply-chain tradecraft

Covered with adaptation.

Packagist / Composer cross-manifest package.json lifecycle abuse

Covered with adaptation.

PyPI developer supply-chain compromise

Covered with adaptation.

AI-framework npm namespace compromise

Covered with adaptation.

LLM API-key or AI-service token exposure from developer or CI/CD package execution

Covered with adaptation.

Future npm namespace compromises involving malicious lifecycle execution and credential theft

Covered with adaptation after source validation and behavior-to-telemetry alignment.

Future PyPI, Packagist / Composer, RubyGems, Cargo, Go module, or other developer package ecosystem activity involving trusted-dependency execution and credential theft

Covered with adaptation after source validation and behavior-to-telemetry alignment.

Current Coverage Count

Directly covered CVEs

0

CVEs covered with adaptation

0

Known Exploited Vulnerabilities represented in this coverage set

0

Directly covered named malware / tooling / tradecraft patterns

7

Named malware / tooling / tradecraft patterns covered with adaptation

5

APT / actor / campaign activity names covered with adaptation

2

Directly covered core behavior classes

4 core behavior classes: trusted-dependency install-time execution, developer and CI/CD credential theft, source-code and package-registry token abuse, and downstream software-integrity assurance exposure.

Coverage Qualification

This count is a living analytical note, not a universal npm, PyPI, Packagist, Composer, AI-framework, SAP-development, package-registry, source-code platform, CI/CD, cloud, malware, actor, campaign, or software supply-chain coverage claim. A related package compromise, actor report, malicious dependency, package namespace, ecosystem event, proof-of-concept, or advisory should only be added when it shares enough observable behavior with the report’s detection model to support credible detection or detection-readiness coverage.

Direct coverage should remain limited to the report’s first-class detection lanes, including trusted package execution, package-manager lifecycle abuse, unexpected runtime execution, developer credential discovery, CI/CD secret exposure, GitHub token abuse, npm token abuse, cloud credential exposure, suspicious egress, conditional propagation, internal mirror persistence, package-cache exposure, build-image exposure, artifact provenance review, and release-integrity uncertainty.

Covered-with-adaptation items should remain counted only when the activity can be correlated through endpoint process telemetry, command-line logging, file-access telemetry, package-manager logs, CI/CD logs, GitHub audit logs, npm registry logs, cloud audit logs, identity logs, DNS logs, proxy logs, EDR network telemetry, NDR telemetry, internal mirror records, package-cache records, SBOMs, artifact metadata, release records, approved workflow baselines, and incident-response evidence.

Actor attribution should be treated as enrichment and intelligence context, not as a detection requirement. Sapphire Sleet, BlueNoroff, TeamPCP, Shai-Hulud, Mini Shai-Hulud, Mastra, easy-day-js, SAP npm, Packagist, Composer, PyPI, or any future ecosystem label should only affect coverage when the observable behavior aligns to the report’s S21 through S25 detection strategy.

A related package compromise, malware family, actor cluster, package ecosystem, namespace, dependency, advisory, or campaign report should not be counted when it depends on unrelated exploitation mechanics, lacks aligned telemetry, affects only unrelated package reputation, produces no trusted-dependency execution, produces no developer or CI/CD credential exposure, produces no source-code or package-registry abuse, produces no cloud-control-plane risk, and requires a separate detection model.

Executive Exposure Statement

The organization’s economic exposure is highest when compromised package installation creates uncertainty around whether developer credentials, CI/CD secrets, source-code repositories, package registries, cloud deployment paths, internal package mirrors, build images, release artifacts, and customer-facing software remain trustworthy.

The strategic risk is not one SAP package, one Mastra package, one malicious dependency, one package namespace, one loader file, one runtime name, one GitHub repository, one npm token, one actor label, one campaign name, one public IOC, or one ecosystem. The strategic risk is the possibility that adversaries can convert trusted dependency execution into developer credential theft, CI/CD secret exposure, repository abuse, package-registry abuse, cloud access, artifact uncertainty, customer assurance requirements, legal and regulatory review, and executive uncertainty about whether software delivery and release integrity remain safe.

S40 — References

Primary Package and Platform Sources

npm Package Registry — mbt package record

·        hxxps://www[.]npmjs[.]com/package/mbt

npm Package Registry — @cap-js/db-service package record

·        hxxps://www[.]npmjs[.]com/package/@cap-js/db-service

npm Package Registry — @cap-js/postgres package record

·        hxxps://www[.]npmjs[.]com/package/@cap-js/postgres

npm Package Registry — @cap-js/sqlite package record

·        hxxps://www[.]npmjs[.]com/package/@cap-js/sqlite

SAP CAP Documentation — Plugins and @cap-js package ecosystem context

·        hxxps://cap[.]cloud.sap/docs/plugins/

Mastra Documentation / Project Context

·        hxxps://mastra[.]ai/

·        hxxps://github[.]com/mastra-ai/mastra

Incident Reporting and Security Analysis

BleepingComputer — Official SAP npm packages compromised to steal credentials

·        hxxps://www[.]bleepingcomputer[.]com/news/security/official-sap-npm-packages-compromised-to-steal-credentials/

The Hacker News — SAP-related npm packages compromised in credential-stealing supply-chain attack

·        hxxps://thehackernews[.]com/2026/04/sap-npm-packages-compromised-by-mini.html

SecurityWeek — SAP npm packages targeted in supply-chain attack

·        hxxps://www[.]securityweek[.]com/sap-npm-packages-targeted-in-supply-chain-attack/

Microsoft Security Blog — From package to postinstall payload: Inside the Mastra npm supply-chain compromise

·        hxxps://www[.]microsoft[.]com/en-us/security/blog/2026/06/17/postinstall-payload-inside-mastra-npm-supply-chain-compromise/

StepSecurity — Mastra npm packages compromised using easy-day-js

·        hxxps://www[.]stepsecurity[.]io/blog/mastra-npm-packages-compromised-using-easy-day-js

The Hacker News — Mastra npm packages compromised via hijacked contributor account

·        hxxps://thehackernews[.]com/2026/06/144-mastra-npm-packages-compromised-via.html

Threat Tradecraft Context

BleepingComputer — Shai-Hulud malware infects npm packages and leaks secrets on GitHub

·        hxxps://www[.]bleepingcomputer[.]com/news/security/shai-hulud-malware-infects-500-npm-packages-leaks-secrets-on-github/

CISA — Widespread supply chain compromise impacting npm ecosystem

·        hxxps://content[.]govdelivery.com/accounts/USDHSCISA/bulletins/3f408db

The Hacker News — Packagist supply-chain attack infects packages using GitHub-hosted Linux malware

·        hxxps://thehackernews[.]com/2026/05/packagist-supply-chain-attack-infects-8.html

Packagist Blog — An update on Composer and Packagist supply-chain security

·        hxxps://blog.packagist[.]com/an-update-on-composer-packagist-supply-chain-security/

Analytical Framework

MITRE ATT&CK Framework — Enterprise Matrix / Techniques Catalog

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