[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,
August 20, 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 and adjacent developer-workspace execution paths, including npm lifecycle execution, suspicious runtime staging, IDE task autorun abuse, developer secret discovery, encrypted exfiltration, and Shai-Hulud-style propagation tradecraft. The threat posture is elevated because affected packages and related developer supply-chain activity can execute inside developer workstations, IDE-trusted workspaces, 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, inspect workspace task configuration and IDE-launched runtime activity where applicable, 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, package-install workflow, or adjacent developer-workspace execution path may execute attacker-controlled code, collect developer or automation secrets, and enable unauthorized access to repositories, package registries, CI/CD workflows, cloud environments, or downstream release artifacts. Recent adjacent npm supply-chain reporting reinforces that developer trust can be abused not only through npm lifecycle scripts, but also through repository-local IDE task configuration and workspace-open execution paths that may launch runtime activity after a developer opens or trusts a project. If exposure cannot be scoped quickly, response may expand into broad credential rotation, dependency-cache review, internal package mirror validation, IDE workspace task review, 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, trusted workspace, 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.

·        New adjacent npm supply-chain reporting shows that malicious packages can also abuse developer workspace trust through hidden IDE task configuration, including repository-local VS Code task autorun behavior that executes when a trusted project folder is opened.

·        This matters because developer trust boundaries now include not only npm lifecycle execution and CI/CD dependency restoration, but also IDE-trusted workspaces, repository-local automation, workspace task configuration, and IDE-launched runtime activity.

·        The affected trust path is high value because compromised npm packages may be used across SAP application development, AI application frameworks, agentic AI tooling, integration flows, build pipelines, CI/CD runners, IDE-trusted developer workspaces, and release automation.

·        The primary enterprise concern is not only package exposure; the primary concern is whether installation, workspace opening, task autorun, or related execution 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 and adjacent developer-workspace autorun behavior should be treated as high-risk software supply-chain pathways because trusted package or repository handling 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, workspace task names, and infrastructure are useful for scoping, but they are not sufficient as the durable detection or risk model.

·        Organizations without endpoint process telemetry, IDE parent-child process visibility, workspace task-file review, 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 or adjacent developer-workspace execution.

·        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 or IDE/workspace task autorun 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.

·        VS Code, Cursor, or related IDE parent processes spawning unexpected Node, Python, shell, PowerShell, curl, wget, npm, or runtime activity from newly opened repositories or workspace paths should be treated as a high-value adjacent signal when paired with suspicious task configuration, credential access, staging, or outbound activity.

·        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, workspace task names, hashes, infrastructure, and exfiltration paths may change quickly.

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

·        Artifact, lockfile, workspace task-file, 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, workspace task review where applicable, 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 or related developer-workspace execution occurred on developer endpoints, IDE-trusted workspaces, 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, with adjacent developer supply-chain reporting showing that malicious packages can also abuse repository-local IDE task configuration and workspace-open execution paths. 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. Newer adjacent npm reporting also shows hidden VS Code task autorun behavior being used to launch multi-stage JavaScript and Python runtime activity from trusted developer workspaces.

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. IDE-trusted workspaces increase this risk when repository-local task configuration can launch runtime activity from a project that a developer believes is safe to open.

Executive Decision Requirement

Executives must require immediate exposure scoping across dependency files, lockfiles, package caches, build logs, internal npm mirrors, workspace task files where applicable, 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, IDE-launched runtime review where applicable, and confirmation that behavior-based detection is in place for malicious package lifecycle execution, workspace-task abuse, 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, workspace task visibility where applicable, 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, IDE-trusted repository workflows, or customer-facing release responsibilities.

Low Impact Scenario

Exposure is limited to dependency presence, internal mirror retention, workspace task-file presence without execution, or a small number of non-privileged developer systems, and investigation confirms no malicious lifecycle execution, no IDE-launched runtime 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, IDE-trusted workspaces, build environments, release workflows, dependency caches, or internal npm mirrors were exposed to compromised package versions or related suspicious developer-workspace execution paths, requiring credential rotation, endpoint investigation, workspace task-file review, 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 or workspace-task-driven 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, IDE-trusted workspaces, CI/CD runners, release systems, package-publishing systems, and SAP-related development environments.

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

·        Whether repository-local task configuration, including .vscode/tasks.json or similar IDE task files, was present, modified, trusted, or executed in developer environments.

·        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, installation, workspace opening, or task execution to detection, containment, and credential rotation.

·        Ability to confirm package-manager lifecycle execution, IDE-launched runtime 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, IDE parent-child 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, workspace task files, build images, containers, software bills of materials, or artifacts retained poisoned package versions or suspicious developer-workspace automation.

·        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, workspace trust review where applicable, 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 IDE-launched runtime 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, trusted IDE workspaces, 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 or adjacent developer-workspace 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 or adjacent developer-workspace execution paths 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, IDE-trusted workspace exposure, 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.

·        Adjacent developer-workspace execution through repository-local IDE task configuration, including hidden or unexpected workspace task autorun behavior.

·        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, Kubernetes, Docker, or deployment credentials.

·        IDE-trusted workspaces containing repository-local automation that can launch Node, Python, shell, PowerShell, curl, wget, npm, or other runtime activity from project paths.

·        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 IDE process-lineage 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, blockchain-related services, or unfamiliar infrastructure.

·        Over-reliance on package names, hashes, filenames, workspace task names, 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. Recent adjacent npm supply-chain activity reinforces that developer trust can also be abused through IDE-trusted workspace automation, making repository-local task configuration and IDE-launched runtime activity relevant to exposure scoping where applicable. 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, workspace task review where applicable, and behavior-based detection for lifecycle execution, workspace-task abuse, 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 or adjacent developer-workspace execution paths 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, workspace task configuration was reviewed where applicable, 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, IDE workspace trust, 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, CI/CD automation, and downstream software-delivery trust.

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.

Adjacent npm supply-chain reporting also shows that trusted developer workflows can be abused through IDE-trusted workspace configuration, not only through npm lifecycle execution. In that model, a malicious or hijacked package can include repository-local task configuration that executes when a developer opens or trusts a workspace. This does not replace the SAP npm incident’s reported lifecycle-script execution path, but it expands the durable CyberDax detection model for developer supply-chain compromise.

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.

·        Adjacent developer supply-chain activity shows that repository-local IDE task configuration can also move trusted package or project handling into local runtime execution when a workspace is opened or trusted.

·        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, workspace task files, 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. Adjacent IDE workspace-task abuse reinforces that developer trust boundaries include package managers, CI/CD runners, repository-local automation, and trusted workspaces.

S11 — Affected Product / Trust Dependency Overview

Affected Trust Dependency

The affected trust dependency is the npm package distribution and software-development workflow path used by enterprise development teams. This includes package maintainers, npm package publishing, package integrity, dependency resolution, lockfile integrity, internal package mirrors, dependency caches, developer installation, CI/CD dependency restoration, build images, release automation, and downstream software-delivery workflows.

The adjacent trust dependency is developer workspace trust. This includes VS Code, Cursor, and related IDE workflows where repository-local task configuration can execute commands when a project folder is opened or trusted. Workspace task execution should be treated as adjacent to package-manager lifecycle execution because both can turn normal developer activity into attacker-controlled runtime execution.

Affected Package Context

The originally reported 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.

This trust-dependency risk also extends to AI application framework ecosystems where npm packages are used to build agentic AI applications, retrieval-augmented generation workflows, LLM-connected services, AI SaaS products, and developer automation. The Mastra AI npm compromise demonstrates that the same durable risk model can affect high-volume AI development packages, where install-time execution may expose developer credentials, GitHub tokens, npm tokens, cloud credentials, LLM API keys, CI/CD secrets, and downstream release authority.

Recent adjacent npm package abuse involving hidden IDE task autorun demonstrates that package trust can also intersect with repository-local workspace configuration. This means exposure review should consider not only package installation and lifecycle execution, but also whether package contents, cloned repositories, extracted projects, or dependency material introduced workspace task files capable of launching runtime activity from a trusted developer workspace.

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.

·        Multiple @mastra npm packages publicly reported as compromised during the Mastra AI supply-chain incident.

·        Malicious dependency insertion involving easy-day-js in the Mastra AI supply-chain incident.

·        Adjacent hijacked npm packages using hidden IDE task autorun should be tracked as Coverage With Adaptation rather than direct SAP incident coverage unless organization-specific evidence links them to the same exposure set.

Trust Dependency Exposure

Exposure may exist where affected packages were installed, cached, mirrored, restored, opened or evaluated in trusted developer workspaces where workspace task execution is permitted, or included during the malicious publication window. Risk is higher when affected packages were installed or executed on systems with privileged developer access, CI/CD secrets, package-publishing authority, production deployment access, cloud credentials, LLM or SaaS API keys, 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.

·        IDE workspace and repository-local task 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.

·        LLM, AI-service, and SaaS API-key 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, package-publishing authority, artifact integrity, CI/CD runner trust, IDE workspace trust, AI-service credential exposure, 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 SAP npm incident 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.

Adjacent developer supply-chain activity shows that equivalent execution can also occur through repository-local workspace automation, including IDE task configuration that runs when a trusted project folder is opened. This does not change the reported SAP execution path, but it expands the detection and exposure model for related npm package compromise.

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.

A related exposure path exists when malicious package content or a related project introduces repository-local IDE task configuration that launches runtime activity after a developer opens or trusts the workspace. In that scenario, the package or project may not rely solely on npm lifecycle execution. The execution boundary shifts to developer workspace trust, IDE process behavior, and local task configuration.

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 workspaces and IDEs are trusted by users and may be allowed to launch repository-local automation.

·        Hidden or unexpected IDE task autorun can turn project opening into an execution path.

·        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, workspace task files, and artifacts may retain affected package versions or suspicious automation.

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

·        Lack of file-access telemetry and IDE process-lineage visibility can make credential theft difficult to confirm or disprove.

Exposure Determination Requirements

·        Identify whether affected package versions were present in package.json, package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, yarn.lock, 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 repository-local task configuration, including .vscode/tasks.json or equivalent IDE task files, was present in affected package or project material.

·        Determine whether workspace task autorun or IDE-launched runtime execution occurred.

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

·        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, IDE-launched runtime, 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. Related developer-workspace execution paths should be reviewed as Coverage With Adaptation where package or project material includes suspicious IDE task configuration or IDE-launched runtime behavior.

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.

The compromised Joyfill releases @joyfill/layouts@0.1.2-2773.beta.0 and @joyfill/components@4.0.0-rc24-2773-beta.4 expand this exposure beyond lifecycle-script execution. Malicious code embedded in the published package bundles executed when an affected package was imported into a Node.js process. Because execution did not depend on an npm installation hook, disabling lifecycle scripts or using npm --ignore-scripts would not have prevented execution when the compromised package was later loaded.

The Joyfill implant used Solana transaction memo data to resolve attacker-controlled infrastructure and ultimately delivered a remote-access payload linked to DEV#POPPER activity. This remains within the report’s trusted-package poisoning and developer-compromise behavior family but requires adaptation because the execution path occurred during package import rather than through the install-time lifecycle behavior emphasized by the original SAP activity.

For adjacent IDE task abuse, exploitability depends on whether malicious package or project material is opened in a trusted workspace and whether task autorun behavior is permitted. This is not the primary SAP or Joyfill execution path, but it remains relevant because workspace trust can create an execution boundary with consequences similar to install-time or import-time package execution.

The Jscrambler incident further confirms that upstream developer-workstation compromise can expose GitHub SSH material and repository write access, enabling workflow modification, npm publishing-token exfiltration, unauthorized publication of malicious package versions, and downstream preinstall lifecycle execution.

New Shai-Hulud-style trusted-publishing activity expands this exposure path further because compromise of an authorized repository or release workflow can allow attacker-modified source to execute through the legitimate CI/CD release process, obtain OIDC-backed publishing authorization, and publish a malicious package through the trusted publishing path. In this condition, valid provenance or signing may confirm that the authorized workflow produced the package without proving that the underlying source state, workflow configuration, triggering event, or release intent was benign.

Exploitability Drivers

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

·        Package installation can automatically execute lifecycle scripts.

·        Malicious code embedded in a published package bundle may execute when the package is imported, even when lifecycle scripts are disabled.

·        Compromised beta, release-candidate, or other prerelease packages may be consumed by development, testing, integration, or CI/CD environments.

·        Developer and CI/CD systems commonly install and load dependencies as routine workflow activity.

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

·        Trusted-publishing identities and CI/CD OIDC relationships may provide package-publication authority through approved release workflows.

·        Compromise of an authorized release workflow may allow malicious package publication while preserving valid provenance or signing associated with the legitimate publishing path.

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

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

·        Solana transaction memo data may be used to resolve attacker-controlled infrastructure outside the package itself.

·        Adjacent developer-workspace abuse may execute through IDE task configuration when a project folder is opened or trusted.

·        Package-launched or IDE-launched runtime activity may blend into normal development behavior unless process lineage and package context are retained.

Patch and Remediation Status

Public reporting indicates the compromised SAP-related versions were deprecated, removed, or superseded after discovery. The compromised Joyfill releases @joyfill/layouts@0.1.2-2773.beta.0 and @joyfill/components@4.0.0-rc24-2773-beta.4 must likewise be removed or superseded wherever they remain referenced or retained in dependency manifests, lockfiles, caches, internal npm mirrors, build images, deployment artifacts, or previously generated release outputs.

Exposure management should not rely only on upgrading or removing affected package versions. Because the reported activity targets credentials and developer workflow trust and may execute during package installation, workspace interaction, or package import, remediation also requires credential rotation, token revocation, GitHub and npm audit review, cloud-control-plane review, CI/CD validation, dependency-cache cleanup, runtime review, workspace task review where applicable, and artifact assurance.

Where trusted publishing is used, remediation must also validate the authorized release workflow, repository and ref scope, triggering event, OIDC trust relationship, publishing identity, and provenance context. Valid provenance or signing should not by itself be treated as proof that the originating source state or release workflow was uncompromised.

Required Exposure Management Actions

·        Remove or supersede @joyfill/layouts@0.1.2-2773.beta.0, @joyfill/components@4.0.0-rc24-2773-beta.4, and other affected package versions from dependency files and lockfiles.

·        Identify repositories, endpoints, build systems, test environments, and CI/CD workflows that installed or imported the compromised Joyfill releases.

·        Clear dependency caches that may retain affected package tarballs or extracted package content.

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

·        Review developer endpoints and CI/CD runners that installed, imported, tested, built, or executed affected packages.

·        Investigate unexpected Node, Bun, Python, shell, PowerShell, curl, wget, npm, or other runtime activity associated with package installation, package import, testing, or build execution.

·        Review repository-local task files, including .vscode/tasks.json or equivalent IDE task configuration, where affected package or project material may have been opened in trusted developer workspaces.

·        Investigate IDE-launched runtime activity following package exposure or workspace opening.

·        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 trusted-publishing identities, release workflows, repository and ref restrictions, triggering events, and CI/CD OIDC trust relationships associated with package publication.

·        Review npm token use, package publication, maintainer changes, package ownership changes, access changes, metadata changes, distribution-tag changes, prerelease publication activity, and package provenance.

·        Correlate package publication and provenance records with the originating workflow identity, repository, ref, triggering event, OIDC publishing subject, and preceding workflow changes where telemetry is available.

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

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

·        Disable or restrict install-time scripts in high-risk CI/CD workflows where operationally feasible, while recognizing that this control does not prevent import-time execution.

·        Restrict or require additional review for beta, release-candidate, or other prerelease dependencies in production-oriented workflows.

·        Restrict or monitor IDE workspace task autorun in high-risk developer environments where operationally feasible.

·        Monitor unexpected process creation, outbound communication, credential access, or file modification associated with package installation or import.

·        Enforce package provenance, trusted publishing restrictions, workflow scoping, OIDC trust scoping, dependency-version governance, and least-privilege release credentials.

Exploitability and Exposure Management Disposition

Exploitability is high where affected package versions were installed with lifecycle scripts enabled or where compromised package code was subsequently loaded through package import.

The compromised Joyfill npm prerelease packages and the resulting remote-access activity linked to DEV#POPPER are Coverage With Adaptation. The activity preserves the report’s core trusted-package poisoning, developer-system compromise, credential exposure, and downstream intrusion model while expanding the execution condition from install-time lifecycle behavior to malicious code embedded in package bundles and activated when the package is imported.

Shai-Hulud-style trusted-publishing abuse is also Coverage With Adaptation. It preserves the report’s existing repository compromise, workflow manipulation, package-publication abuse, and downstream propagation model while adding the condition that a compromised legitimate release workflow may obtain OIDC-backed publishing authorization and produce a malicious package with valid provenance or signing.

Exposure management must combine package remediation with credential assurance, CI/CD review, source-code platform review, trusted-publishing and OIDC trust validation, cloud validation, cache cleanup, import-time runtime review, workspace task review where applicable, provenance-context validation, and artifact integrity review

S14 — Sectors / Countries Affected

Sectors Affected

Observed and likely exposed sectors include organizations that use npm packages in developer workstations, IDE-trusted workspaces, 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, workspace trust, credential exposure, and downstream software-delivery authority.

Most Likely Exposed Sectors

·        Technology and software development.

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

·        SAP development, SAP CAP, S/4HANA extension, Fiori backend, and SAP Business Technology Platform teams.

·        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, workspace opening, or dependency restoration 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, developer workspace use, 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, opened or evaluated related project material in trusted workspaces, 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, encrypted exfiltration, and developer workflow trust. The tradecraft is consistent with a developer-ecosystem intrusion model rather than commodity endpoint-only malware.

Adjacent npm supply-chain activity involving hidden IDE task autorun demonstrates additional capability to abuse developer workspace trust. This capability allows malicious package or project content to move from repository or dependency handling into local execution through IDE-managed task configuration.

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.

·        Adjacent capability to hide execution inside repository-local IDE task configuration.

·        Adjacent capability to launch JavaScript, Python, shell, or runtime activity from trusted developer workspaces.

·        Adjacent capability to use dead-drop infrastructure, backdoor-style runtime communication, and infostealer behavior in developer-targeted package 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.

·        Can abuse developer IDE trust and repository-local automation where workspace task execution is permitted.

·        Benefits from ephemeral infrastructure and limited runner telemetry.

·        Benefits from limited IDE process-lineage visibility on developer endpoints.

·        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, package consumption, or equivalent trusted developer-workspace interaction by target environments.

·        Requires lifecycle script execution or equivalent developer-workspace execution path 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, IDE process-lineage, CI/CD, GitHub, npm, cloud, identity, and network telemetry are correlated.

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

·        Internal mirrors, build logs, lockfiles, workspace task files, 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. Adjacent IDE workspace-task abuse reinforces that developer endpoint trust, project trust, and local automation must be treated as part of the software supply-chain attack surface.

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.

Adjacent IDE workspace-task abuse remains dependency- and workflow-driven. For that related behavior, probability increases when developers open or trust malicious package or project material in IDE environments that permit task autorun or broad local automation.

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.

·        Related package or project material introduced repository-local IDE task configuration capable of autorun behavior.

·        Developer systems opened or trusted affected project material in IDE environments that permit task execution.

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

·        GitHub, npm, cloud, identity, artifact, endpoint, IDE process-lineage, 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.

·        Related workspace task files were present but autorun or execution has not been confirmed.

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

·        Workspace task autorun was blocked, disabled, or not present in affected project material.

·        Installation or workspace opening 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, workspace autorun was not present or not permitted, 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

Function in this threat

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

·        Adjacent developer supply-chain activity shows that malicious package or project content may also carry repository-local workspace configuration that becomes relevant after a package or project is opened in a trusted developer environment.

Technique IDs

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

Stage 2 — Developer or CI/CD Dependency Installation

Function in this threat

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

·        For adjacent IDE task abuse, the equivalent exposure event may be opening or trusting project material that contains suspicious repository-local task configuration.

Technique IDs

·        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

Function in this threat

·        The compromised SAP-related 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.

·        Adjacent IDE workspace task abuse should be treated as Coverage With Adaptation within this execution stage because it also converts trusted developer activity into local script or runtime execution, but through repository-local task configuration rather than npm lifecycle execution.

·        This stage should preserve npm lifecycle execution as the primary SAP incident behavior.

Technique IDs

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

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

Stage 4 — Runtime Bootstrapping and Payload Execution

Function in this threat

·        The loader stages or invokes runtime execution to run credential-stealing and propagation payloads.

·        In the reported SAP npm incident, public reporting identifies Bun runtime execution as part of the malicious install-time flow.

·        In adjacent developer-workspace abuse, runtime activity may involve IDE-spawned JavaScript, Node, Python, shell, or related execution launched from project paths.

·        Runtime bootstrapping remains a durable behavior signal because package names, task names, filenames, infrastructure, and payload details can change.

Technique IDs

·        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

Function in this threat

·        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 or workspace execution to enterprise exposure.

·        Credential access remains the most important operational signal because package removal does not revoke stolen secrets.

Technique IDs

·        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

Function in this threat

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

·        Adjacent developer supply-chain activity may stage data through JavaScript or Python runtime components before exfiltration or backdoor-style communication.

Technique IDs

·        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

Function in this threat

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

·        Adjacent dead-drop or backdoor-style network behavior should remain conditional and should not be treated as direct SAP incident behavior unless supported by organization-specific telemetry.

·        Network destinations should be interpreted with process lineage and timing context because developer systems commonly access GitHub, registries, cloud services, and collaboration platforms.

Technique IDs

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

Stage 8 — Credential Reuse and Control-Plane Abuse

Function in this threat

·        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 or workspace execution to broader control-plane compromise.

·        Credential reuse should be validated through audit logs rather than assumed from package exposure alone.

Technique IDs

·        MITRE ATT&CK: T1078 — Valid Accounts.

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

Stage 9 — Repository, Workflow, or Package Propagation

Function in this threat

·        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, repository, or CI/CD evidence confirms it.

·        Adjacent developer-workspace abuse may support similar downstream propagation if stolen credentials provide repository or package-publishing authority.

Technique IDs

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

Stage 10 — Downstream Software Integrity Exposure

Function in this threat

·        The final business-impact stage occurs when poisoned dependencies, modified repositories, malicious workflow outputs, stolen credentials, suspicious workspace automation, 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.

Technique IDs

·        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 dependency installation, install-time JavaScript execution, runtime execution, credential discovery, local staging, encrypted handling, exfiltration, token theft, credential reuse, and potential downstream package or repository propagation. Adjacent IDE workspace-task abuse adds a related execution path in which trusted project handling can trigger runtime activity through repository-local task configuration, but it should remain Coverage With Adaptation rather than a replacement for the SAP npm lifecycle execution model. The most important defensive conclusion is that exposure review must not stop at package inventory. It must extend into execution telemetry, IDE process-lineage review where applicable, 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

Describe the likely execution flow from trusted package exposure through credential theft, possible control-plane abuse, propagation risk, and downstream software-integrity uncertainty. This section aligns the narrative to observable signals rather than package names alone. The SAP npm lifecycle execution path remains the primary report behavior. Adjacent IDE workspace-task abuse should be treated as Coverage With Adaptation where repository-local task configuration or IDE-launched runtime activity is present.

Stage 1 — Trusted Dependency Exposure

The attack begins when trusted SAP-related npm package versions enter a dependency set used by developer systems, CI/CD workflows, release automation, package-publishing environments, internal package mirrors, or dependency caches. Exposure may occur through direct dependency declaration, transitive dependency resolution, lockfile use, cached package retrieval, internal mirror synchronization, or build image reuse.

Adjacent developer supply-chain activity shows that package or project material may also introduce repository-local workspace configuration. This does not replace npm package exposure as the primary SAP incident path, but it expands scoping when affected package or project material is opened, evaluated, or trusted inside developer IDE workflows.

Primary Signals

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

·        SAP-related package versions resolved or installed during the malicious publication window.

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

·        Build logs showing dependency restoration from npm, internal mirrors, or cached package sources.

·        Repository-local task configuration, including .vscode/tasks.json or equivalent IDE task files, present in package or project material where workspace task execution is permitted.

·        Lack of reliable package provenance, trusted publishing validation, dependency admission control, or internal mirror quarantine.

Stage 2 — Install-Time Lifecycle Execution

The primary SAP incident execution path occurs when package installation triggers malicious npm lifecycle behavior. The reported package.json preinstall hook and setup.mjs loader move the exposure from package presence to local execution. This stage is the key distinction between inventory exposure and active compromise risk.

Adjacent IDE workspace-task abuse should be handled as an adapted execution variant at this stage. In that path, trusted project handling may trigger runtime activity through repository-local task configuration rather than npm lifecycle execution. The adapted behavior should be scoped only where workspace task files, IDE process lineage, or workspace-open execution evidence exists.

Primary Signals

·        npm, node, bun, shell, PowerShell, curl, wget, archive utility, or runtime execution from package installation paths.

·        package.json lifecycle scripts invoking setup.mjs, loader files, shell commands, runtime staging, downloader behavior, or suspicious child processes.

·        npm install, npm ci, yarn, pnpm, or CI/CD dependency restoration followed by unexpected runtime activity.

·        IDE parent processes such as VS Code, Cursor, or related developer tools spawning Node, Python, shell, PowerShell, curl, wget, npm, or runtime activity from project paths.

·        Workspace task configuration using autorun, folder-open behavior, hidden presentation settings, unusual command paths, or benign-looking project assets to launch runtime activity.

·        Command-line, parent-child process, file-path, and working-directory evidence linking execution to dependency installation or trusted workspace activity.

Stage 3 — Runtime Bootstrapping

After execution begins, the loader stages or invokes runtime components used for credential discovery, collection, exfiltration, or propagation. In the primary SAP npm path, public reporting identifies setup.mjs and Bun runtime execution as important runtime behaviors. In adapted IDE workspace-task activity, runtime behavior may involve IDE-spawned JavaScript, Node, Python, shell, or related interpreter activity from project paths.

Runtime bootstrapping is a durable detection focus because package names, filenames, hashes, infrastructure, task names, and payload details may change. The strongest signal is unexpected runtime activity from dependency, cache, temporary, workspace, or CI/CD paths that do not normally launch those tools.

Primary Signals

·        Bun, Node, JavaScript, shell, Python, curl, wget, archive utility, or downloader activity launched from dependency, cache, temporary, workspace, package, or CI/CD directories.

·        setup.mjs or similarly named loader behavior invoking runtime execution, staging files, reading local configuration, or initiating outbound activity.

·        Runtime execution from project assets, font paths, public directories, hidden directories, or other locations that appear inconsistent with normal build behavior.

·        IDE-launched runtime activity where the IDE is the parent process and the child process accesses project paths, credential locations, or network destinations.

·        Runtime or loader behavior that occurs immediately after dependency restoration, workspace opening, project trust, or package extraction.

·        Process activity inconsistent with approved package installation, build, test, release, or developer automation baselines.

Stage 4 — Developer and CI/CD Secret Discovery

The payload searches for secrets that may be present on developer endpoints, CI/CD runners, release systems, package-publishing hosts, or cloud-connected build environments. This stage is the primary transition from local execution to enterprise risk. Package removal, project cleanup, or build reversion does not revoke credentials that may already have been accessed.

Primary Signals

·        Access to GitHub tokens, npm tokens, SSH keys, cloud CLI credentials, Kubernetes configuration, Docker credentials, environment files, credential stores, package registry authentication, CI/CD variables, or deployment secrets.

·        File reads from .ssh, .npmrc, .gitconfig, cloud configuration directories, kubeconfig paths, Docker configuration paths, environment files, repository secrets, or CI/CD secret material.

·        Process-linked access to developer credential locations after npm lifecycle execution or IDE-launched runtime activity.

·        Suspicious enumeration of home directories, repository directories, credential files, package-manager configuration, cloud configuration, or build environment variables.

·        CI/CD runner activity that reads environment material, injected secrets, temporary files, build variables, or package-publishing tokens.

·        Endpoint or EDR telemetry gaps that prevent confirmation of whether credential files were accessed.

Stage 5 — Local Collection, Staging, and Encrypted Handling

Collected material may be staged locally, serialized, encoded, compressed, encrypted, or prepared for transfer. Public reporting describes encrypted handling of exfiltrated data in the SAP-related npm activity. Adapted developer-workspace activity may also stage collected material through JavaScript, Node, Python, shell, or related runtime components.

Primary Signals

·        Creation or modification of temporary files, archives, encoded blobs, encrypted files, staged credential bundles, or unusual output files after credential discovery.

·        Runtime processes reading credential material and writing to temporary, cache, workspace, project, dependency, or hidden directories.

·        Use of compression, encoding, encryption, serialization, or archive utilities shortly after package or workspace-triggered execution.

·        Local staging followed by outbound network activity to GitHub, raw-content services, webhooks, cloud storage, unfamiliar infrastructure, or attacker-abused developer services.

·        Short-lived files created and deleted during install-time or workspace-triggered execution.

·        Weak file telemetry preventing defenders from proving whether sensitive material was staged.

Stage 6 — Exfiltration Through Developer-Adjacent Channels

The attack may transfer collected material through developer-adjacent services or web-accessible infrastructure. GitHub and similar developer services are high-risk because they are normally allowed in developer and CI/CD environments. This stage should be validated through process lineage, timing, destination context, and correlation with credential discovery or staging activity.

Adjacent dead-drop or backdoor-style network behavior should remain Coverage With Adaptation unless organization-specific telemetry confirms that behavior in the environment being reviewed. It should not be treated as direct SAP incident behavior without supporting evidence.

Primary Signals

·        Outbound connections from npm, node, bun, shell, PowerShell, curl, wget, Python, IDE child processes, or loader-related processes after dependency installation or workspace execution.

·        Connections to GitHub, raw-content services, webhook services, cloud storage, paste-like services, blockchain-related services, unfamiliar domains, or newly observed infrastructure after credential discovery.

·        Network activity from CI/CD runners or developer systems outside normal build, package retrieval, repository, or release behavior.

·        DNS, proxy, EDR network, or firewall logs showing outbound activity temporally linked to install-time or IDE-launched execution.

·        Encrypted egress that prevents content-level confirmation of stolen material.

·        GitHub or cloud destinations accessed in a suspicious sequence after credential discovery, staging, or local collection.

Stage 7 — Credential Reuse and Control-Plane Abuse

If stolen credentials are valid and sufficiently privileged, the adversary may reuse them against source-code platforms, package registries, cloud environments, deployment systems, CI/CD workflows, or automation platforms. This stage materially increases enterprise impact because it moves the incident from local package or workspace execution to broader control-plane exposure.

Credential reuse should be validated through audit logs rather than assumed from exposure alone. Absence of suspicious audit activity reduces likelihood but does not fully eliminate risk where logging is incomplete, retention is limited, or token lineage is weak.

Primary Signals

·        GitHub repository creation, repository visibility changes, workflow creation, workflow modification, deploy-key changes, webhook changes, secret-related activity, OAuth 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 or workspace-triggered execution.

·        Audit activity that appears legitimate in isolation but is suspicious when correlated with prior package execution, credential discovery, staging, or egress.

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, repository, or cloud evidence. Historical Shai-Hulud-style activity demonstrates propagation through npm packages and source-code platform abuse, 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, package metadata changes, maintainer changes, ownership changes, or token activity 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.

·        Repository-local automation or workspace task files added to projects in a way that could support adapted developer-workspace execution.

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, suspicious workspace automation, 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, promoted release outputs, or internal package repositories.

·        Build or release activity from exposed developer systems, CI/CD runners, package-publishing hosts, or release workflows during the exposure window.

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

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

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

·        Executive, legal, customer, regulatory, or board-level assurance requirements triggered by unresolved software-trust uncertainty.

Attack Path Narrative Disposition

The attack path moves from trusted dependency exposure to install-time lifecycle execution, runtime bootstrapping, credential discovery, local staging, encrypted handling, exfiltration, credential reuse, possible propagation, and software-integrity uncertainty. Adjacent IDE workspace-task abuse fits this same signal-aligned flow as Coverage With Adaptation because it can convert trusted developer workspace handling into local execution and credential exposure. The strongest investigative priority is to determine whether affected package installation or adapted workspace-triggered execution 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 and related developer-workspace activity occur 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 and Workspace 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. Adjacent developer supply-chain activity shows that trusted workspace handling may also become an execution path when repository-local task configuration launches runtime activity from an IDE-trusted project. This reduces the chance that the initial activity is treated as suspicious unless telemetry connects package-manager or IDE activity 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.

·        Trusted workspace handling can become an adapted execution path where workspace task autorun is permitted.

·        Static package inventory does not prove whether execution occurred.

·        Package removal or project cleanup 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, local repository access, and sometimes deployment material. 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, Kubernetes, Docker, and deployment credentials may require rotation.

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

·        IDE-trusted workspace execution may increase uncertainty when process-lineage telemetry is limited.

·        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, production release paths, and internal package mirrors.

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.

·        Build output may require provenance review if affected dependencies were restored during the exposure window.

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, OAuth activity, 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, OAuth applications, and secrets may require audit.

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

·        Repository-local automation and workspace task files may require review where adapted IDE execution is in scope.

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.

·        Package provenance and trusted publishing controls may need immediate validation.

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, artifact repositories, 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.

·        Cloud and deployment trust may remain uncertain until audit logs, identity context, and release history are correlated.

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

Compromised packages may remain in internal npm mirrors, dependency caches, build images, containers, lockfiles, artifact repositories, software bills of materials, workspace material, or release outputs 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.

·        Workspace task files or project material may preserve adapted execution risk where IDE task execution is permitted.

·        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 IDE process-lineage visibility, 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, IDE telemetry, CI/CD, GitHub, npm, cloud, identity, network, workspace configuration, and artifact systems.

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

·        Customer, legal, regulatory, or board-level assurance may be required even without confirmed downstream compromise.

Risk Amplification Disposition

The attack chain amplifies because npm package trust intersects with developer credentials, IDE workspace trust, 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. Adjacent workspace-task abuse should remain Coverage With Adaptation, but it reinforces the same business conclusion: developer trust boundaries must be treated as part of the enterprise supply-chain attack surface.

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 or compromised authorized release workflows 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.

Adjacent trusted-publishing activity expands this propagation path because compromise of a legitimate repository or release workflow may allow attacker-modified source to execute through an authorized CI/CD workflow, obtain OIDC-backed publishing authorization, and publish a malicious package through the trusted publishing relationship. The publication may retain valid provenance or signing because the legitimate workflow and publishing identity performed the release.

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, trusted-publishing, and publication history should be validated.

·        Trusted publication should be correlated with the originating workflow identity, repository, ref, triggering event, OIDC trust relationship, and preceding workflow changes.

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. Shai-Hulud-style trusted-publishing abuse is Coverage With Adaptation because it preserves the report’s existing repository compromise, workflow manipulation, package-publication abuse, and downstream propagation model while adding the behavior chain of compromised workflow → OIDC-backed publishing authorization → trusted publication → malicious package 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.

Adjacent Shai-Hulud-style trusted-publishing activity shows that the same trust model can be abused upstream when an attacker compromises an authorized repository or release workflow. In that condition, attacker-modified source may pass through the legitimate CI/CD release process, obtain OIDC-backed publishing authorization, and reach downstream consumers through the approved package-publishing path.

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.

·        Compromised authorized release workflows may publish malicious package content through legitimate trusted-publishing identities and OIDC relationships.

·        Valid provenance or signing may remain present when the authorized workflow itself processes attacker-modified source.

·        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, package-publishing rights, or control of an authorized release workflow.

·        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, OIDC trust scoping, workflow restrictions, and install-script controls reduce propagation opportunity but do not establish benign release intent when the authorized workflow itself is compromised.

·        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 authorized release workflows or trusted-publishing relationships were abused, whether cloud access occurred, and whether release artifacts require assurance.

Valid provenance or signing should be interpreted as evidence about the authenticated build and publication path, not as standalone evidence that the source state, workflow behavior, or release intent was benign.

Business Interpretation

The primary business issue is software trust. Affected organizations may need to prove that developer credentials, CI/CD workflows, source-code repositories, trusted-publishing relationships, 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, provenance-context validation, and executive governance.

Adversary Tradecraft Disposition

The adversary tradecraft is high leverage because it turns trusted package installation into execution and credential theft while allowing compromised trusted release automation to enable malicious package publication and downstream propagation. The highest-risk outcomes occur when affected package installation or compromised release workflows intersect with privileged developer identities, CI/CD secrets, OIDC-backed 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.

Priority 6 — IDE Workspace Task Autorun Abuse

Add detection coverage for repository-local IDE task configuration that can turn trusted workspace handling into local runtime execution. This is Coverage With Adaptation, not direct SAP incident behavior. Detection should focus on hidden or unexpected workspace task files, folder-open task execution, IDE parent processes spawning runtimes or shell interpreters, and follow-on credential access or outbound activity from project paths.

·        Identify .vscode/tasks.json or equivalent IDE task files that define autorun, folder-open execution, hidden presentation behavior, unexpected shell commands, runtime launch activity, downloader activity, or suspicious execution from project-controlled paths.

·        Detect VS Code, Cursor, or related IDE parent processes spawning Node, npm, Bun, Python, shell, PowerShell, curl, wget, archive utilities, or other runtime activity from newly opened, untrusted, cloned, extracted, or dependency-derived workspace paths.

·        Correlate IDE-launched runtime activity with access to credential locations, environment files, GitHub tokens, npm credentials, SSH keys, cloud configuration, Kubernetes configuration, Docker credentials, or CI/CD-related files.

·        Prioritize alerts where workspace task execution is followed by local staging, encoded or encrypted file creation, suspicious outbound connections, GitHub activity, npm activity, cloud activity, or repository modification.

Treat this priority as an adapted developer-supply-chain signal that extends the report’s behavior model beyond npm lifecycle scripts without replacing the SAP npm preinstall and setup.mjs execution path.

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

Developer Endpoint and Process Execution Telemetry

·        Developer endpoint and process telemetry should be collected from workstations, release engineering systems, package-publishing systems, administrative systems, and developer environments that install, restore, inspect, open, test, or build SAP-related npm packages.

·        Process telemetry should capture process creation, parent-child process lineage, command-line execution, working directory, process user, process path, process hash, package-manager execution, runtime execution, interpreter execution, shell execution, command-processor execution, file retrieval, archive extraction, downloader behavior, and network utility execution.

·        Package-manager process telemetry should identify npm, yarn, pnpm, node, bun, shell, PowerShell, curl, wget, archive utility, and script execution activity that originates from dependency installation, package-cache paths, node_modules paths, temporary directories, build workspaces, or project-controlled directories.

·        Developer IDE telemetry should capture VS Code, Cursor, and related IDE processes spawning Node, npm, Bun, Python, shell, PowerShell, curl, wget, archive utilities, downloader behavior, or unexpected runtime activity from project paths where technically available.

·        Workspace task telemetry should capture creation, modification, or execution context for .vscode/tasks.json or equivalent IDE task files when repository-local workspace automation is present.

·        Endpoint telemetry should identify execution from developer users, release engineering users, package-maintainer users, privileged users, local administrator context, CI/CD-adjacent accounts, and systems used to authenticate to GitHub, npm, cloud platforms, or deployment services.

·        Process telemetry should support differentiation between approved dependency installation, normal build activity, developer testing, package inspection, security research, vulnerability management, incident response, and unauthorized package-triggered or workspace-triggered execution.

·        Detection logic must not require endpoint or process telemetry as a universal prerequisite because managed developer environments, hosted build systems, contractor systems, ephemeral runners, or telemetry-limited endpoints may not expose complete host-level visibility.

Memory and Runtime Execution Telemetry

·        Memory and runtime telemetry is useful where EDR, host security agents, operating-system telemetry, runtime monitoring, developer endpoint telemetry, or CI/CD diagnostics provide execution visibility.

·        Runtime telemetry should identify unusual Bun, Node, JavaScript, Python, shell, PowerShell, downloader, archive utility, or command-processor activity tied to package installation, lifecycle scripts, setup.mjs execution, dependency restoration, or IDE-spawned workspace activity.

·        Runtime telemetry should increase confidence when package-manager execution or IDE-launched execution is followed by credential-file access, environment-variable enumeration, local staging, encoded or encrypted file creation, suspicious outbound communication, GitHub activity, npm activity, cloud activity, or repository modification.

·        Memory telemetry should capture suspicious runtime behavior, credential-access behavior, process injection, security-control interference, unusual module loading, and sensitive process access when technically available.

·        Runtime telemetry should not be required to identify initial exposure because package presence may first appear through dependency files, lockfiles, package caches, internal mirrors, build logs, package-manager logs, workspace task files, or artifact records.

·        Environments without memory or runtime telemetry should preserve detection coverage through package-manager logs, endpoint process logs, CI/CD logs, source-code platform logs, npm audit logs, cloud audit logs, network telemetry, package-cache review, workspace task-file review, and artifact validation.

File, Workspace, and Credential-Access Telemetry

·        File telemetry should capture creation, modification, deletion, rename, download, extraction, execution, permission changes, ownership changes, and timestamp anomalies involving package files, JavaScript files, setup.mjs, package.json, lockfiles, package caches, dependency directories, temporary files, staged output, archives, encrypted blobs, environment files, and developer credential locations where visible.

·        Workspace telemetry should capture creation, modification, and review of repository-local automation files, including .vscode/tasks.json, workspace settings, project scripts, package scripts, CI/CD workflow files, and other task definitions capable of launching runtime activity.

·        Credential-access telemetry should capture reads or enumeration involving .npmrc, .ssh, .gitconfig, cloud CLI configuration, kubeconfig paths, Docker configuration, environment files, credential stores, package-registry authentication files, CI/CD secret material, and deployment configuration where technically available.

·        Developer workstation and CI/CD environments should collect file telemetry from home directories, repository directories, project directories, dependency directories, package caches, temporary directories, build workspaces, package-publishing workspaces, internal mirror paths, artifact staging paths, and release directories where customer-managed telemetry is available.

·        Sensitive credential access should be treated as higher risk when correlated with npm lifecycle execution, setup.mjs activity, unexpected Bun or Node execution, IDE-spawned runtime activity, local staging, suspicious outbound communication, GitHub activity, npm activity, cloud activity, or repository modification.

·        File telemetry should not be required for initial package-exposure detection because exposure may be established through dependency files, lockfiles, internal mirrors, package-manager logs, build logs, SBOMs, containers, or artifact records.

·        Missing file-read telemetry should reduce confidence and increase credential-rotation requirements rather than force unsupported conclusions about credential theft.

CI/CD and Build-System Telemetry

·        CI/CD telemetry should be collected from self-hosted runners, managed runners where available, build containers, release workflows, package-publishing workflows, deployment workflows, artifact-building workflows, and artifact-signing workflows.

·        Build telemetry should capture workflow name, job name, step name, runner identity, repository, branch, ref, commit, pull request, triggering actor, triggering event, package-install commands, dependency restoration output, lifecycle-script execution output where available, build image metadata, cache restore events, cache write events, artifact creation, and release promotion.

·        Where OIDC-backed trusted publishing is used, CI/CD telemetry should capture the workflow identity, repository, ref, triggering event, publishing subject or workload identity, OIDC issuance or exchange context where available, and the trusted-publishing relationship used to authorize package publication.

·        CI/CD telemetry should identify npm, yarn, pnpm, node, bun, shell, PowerShell, curl, wget, archive utility, downloader, and runtime execution activity that occurs during dependency restoration, package installation, test execution, build execution, package publication, or deployment.

·        CI/CD telemetry should capture environment context, secret injection context where available, repository permissions, package-publishing permissions, deployment permissions, cloud access, artifact access, and runner privilege boundaries.

·        Build logs should support differentiation between approved build behavior, legitimate dependency installation, release automation, security testing, incident response, package inspection, and suspicious lifecycle-script or runtime behavior.

·        Managed runners and ephemeral build containers may not expose full process, file, memory, or network telemetry; in those cases, build logs, workflow logs, dependency-cache records, artifact records, source-code platform logs, package-registry logs, and credential audit logs become more important.

·        CI/CD telemetry should not be used alone to prove credential theft, token reuse, propagation, or artifact compromise without supporting endpoint, package-manager, source-code platform, npm, cloud, identity, network, or artifact evidence.

Package-Manager, npm Registry, and Dependency Telemetry

·        Package-manager telemetry should capture package.json history, package-lock.json history, npm-shrinkwrap.json history, pnpm-lock.yaml history, yarn.lock history, dependency manifests, package-install commands, lifecycle-script execution, package-cache contents, package tarballs, and dependency restoration sources.

·        npm registry telemetry should capture authentication events, token creation, token validation, token revocation, token use, package publication, package version changes, maintainer changes, ownership changes, access changes, metadata changes, provenance changes, trusted publishing status, and trusted-publishing identity or publication context where available.

·        Package-publication telemetry should support correlation of the published package and version with the originating repository, ref, workflow identity, triggering event, publishing identity, provenance or signing context, and trusted-publishing relationship where available.

·        Internal npm mirrors, dependency caches, package repositories, build images, container layers, SBOMs, and artifact repositories should be reviewed for affected package versions and retained malicious package material after public registry remediation.

·        Package-manager telemetry should support differentiation between package presence, package restoration, package installation, lifecycle-script execution, dependency caching, internal mirror retention, package publication, and package-registry abuse.

·        Package presence should be treated as exposure, not confirmed execution, unless correlated with install logs, lifecycle-script execution, process telemetry, credential access, staging, egress, token reuse, or downstream activity.

·        npm token and package-publishing telemetry should receive higher priority when affected package installation or suspicious runtime activity occurred on systems with maintainer authority, publication permissions, automation tokens, trusted-publishing authority, or release workflow access.

·        Incomplete npm telemetry should increase reliance on lockfile review, internal mirror review, package-cache review, maintainer review, token rotation, provenance validation, and GitHub or source-code platform audit review.

Source-Code Platform and Repository Telemetry

·        Source-code platform telemetry should capture GitHub or equivalent repository activity, workflow changes, branch changes, commit activity, release activity, deploy-key changes, webhook changes, repository visibility changes, repository settings changes, organization membership changes, permission changes, OAuth activity, GitHub App activity, and API use.

·        Repository telemetry should capture creation, modification, and removal of workflow files, package scripts, project automation files, repository-local task files, workspace configuration, package-publishing workflows, and release automation.

·        Repository and workflow telemetry should retain repository, ref, triggering event, workflow identity, workflow-file change history, and actor context sufficient to determine whether trusted package publication followed an unexpected or unauthorized workflow change.

·        GitHub audit logs should be reviewed for activity by developer identities, maintainer identities, automation identities, package-publishing identities, service accounts, CI/CD identities, and administrative users associated with exposed systems.

·        Source-code platform telemetry should support differentiation between normal development, approved release activity, automated workflows, maintainer activity, incident response, and suspicious token reuse after package or workspace-triggered exposure.

·        Repository-local task files should be reviewed where affected package, project, cloned, extracted, cached, or dependency-derived material may have introduced workspace automation capable of launching runtime activity.

·        Source-code platform telemetry alone should not be treated as proof of package-triggered compromise unless correlated with package exposure, lifecycle execution, credential access, suspicious egress, token abuse, npm activity, cloud activity, or artifact impact.

·        Missing or incomplete source-code platform telemetry should increase investigation requirements around token rotation, deploy-key review, webhook review, workflow validation, branch-protection review, repository history, and package-publishing authority.

Cloud, Identity, Token, and Secrets Telemetry

·        Cloud telemetry should capture AWS CloudTrail, Azure Activity Logs, Microsoft Entra ID logs, GCP Cloud Audit Logs, and equivalent platform audit events for accounts, subscriptions, projects, tenants, identities, service accounts, access keys, workload identities, container registries, secret stores, deployment paths, and artifact repositories connected to development or CI/CD workflows.

·        Identity telemetry should capture SSO authentication, MFA events, conditional-access decisions, OAuth authorizations, personal access token activity, fine-grained token activity, service-account activity, automation identity activity, SSH key changes, deploy key activity, and credential rotation or revocation records.

·        Secrets telemetry should capture secret-manager access, key-vault access, CI/CD secret injection where available, cloud key use, npm token use, GitHub token use, deployment-token use, package-publishing credential use, and cloud credential use.

·        Cloud, identity, token, and secrets telemetry should support differentiation between legitimate automation, approved deployment, normal developer access, package-publishing activity, emergency response, and suspicious credential reuse after package or workspace-triggered execution.

·        Credential reuse should be validated through audit logs rather than assumed from package exposure alone.

·        Higher priority should be assigned when credential use occurs from new source IPs, unusual user agents, unfamiliar geographies, unexpected automation contexts, abnormal service accounts, unusual runner identities, or identities tied to exposed developer or CI/CD systems.

·        Missing cloud, identity, token, or secrets telemetry should reduce confidence and increase the need for precautionary token revocation, credential rotation, access review, package-publishing validation, deployment review, and cloud-control-plane assurance.

Network and Outbound Communication Telemetry

·        Network telemetry should capture DNS queries, HTTP and HTTPS proxy logs, TLS metadata, firewall egress logs, NetFlow or equivalent flow logs, EDR network events by process where available, CI/CD runner egress, cloud egress, artifact upload events, and external destination context.

·        Network telemetry should identify outbound activity from npm, yarn, pnpm, node, bun, shell, PowerShell, Python, curl, wget, IDE child processes, loader-related processes, build runners, release systems, package-publishing systems, and cloud-connected developer environments.

·        Egress telemetry should capture connections to GitHub, raw-content services, webhook services, cloud storage, paste-like services, blockchain-related services, package repositories, npm registries, unfamiliar domains, newly observed infrastructure, and destinations inconsistent with the host or workflow role.

·        Network telemetry should support differentiation between legitimate package retrieval, repository access, build artifact upload, cloud deployment, developer testing, approved integration traffic, suspicious egress, and potential exfiltration.

·        Network telemetry should receive higher priority when outbound activity follows package installation, lifecycle-script execution, IDE-launched runtime activity, credential-file access, local staging, encoded output, encrypted file creation, GitHub activity, npm activity, or cloud activity.

·        Encrypted egress may prevent content-level confirmation of stolen material; process lineage, timing, working directory, credential access, staging, and destination context should be used to strengthen or reduce confidence.

·        Network telemetry alone should not be treated as proof of credential theft, exfiltration, token reuse, actor attribution, or artifact compromise without supporting endpoint, file, package-manager, source-code platform, npm, cloud, identity, or incident-response evidence.

Artifact, Container, Cache, and Release Telemetry

·        Artifact telemetry should capture build artifact creation, artifact signing, artifact promotion, artifact download, artifact deployment, release output, package provenance, SBOM generation, and deployment-path activity associated with exposed dependency sets.

·        Container telemetry should capture image build, image push, image pull, image digest, build context, base image, layer metadata, registry authentication, repository, source commit, and deployment target where available.

·        Cache and mirror telemetry should capture dependency-cache contents, cache restore events, cache write events, internal npm mirror synchronization, retained package versions, package tarballs, extracted package content, and package-source records.

·        Release telemetry should capture package-publishing workflows, release approvals, deployment approvals, signing identity, provenance records, source commit, runner identity, artifact repository activity, and production or customer-facing promotion events.

·        Where trusted publishing is used, provenance and release telemetry should retain sufficient repository, ref, workflow identity, triggering event, publishing identity, and build context to validate whether a package was produced through the expected release workflow.

·        Artifact and cache telemetry should support differentiation between package exposure, package installation, build output creation, internal mirror retention, artifact promotion, container release, and customer-facing software-integrity impact.

·        Workspace task-file presence in archived project material, extracted dependency material, or build context should be reviewed where IDE workspace-task abuse is in scope.

·        Artifact, container, cache, and release telemetry should not be treated as proof of compromise by itself, but it is required to determine whether affected dependency sets or suspicious workspace material entered internal packages, containers, SBOMs, releases, or customer-facing outputs.

Telemetry Availability Requirements

·        Asset inventory must identify developer workstations, release engineering systems, package-publishing systems, self-hosted CI/CD runners, managed runner usage, internal npm mirrors, dependency caches, artifact repositories, container registries, source-code platforms, cloud accounts, secret stores, package-maintainer identities, deployment workflows, and release systems.

·        Endpoint and process telemetry should be available from developer systems and self-hosted build systems that expose those signals.

·        IDE process-lineage and workspace task-file telemetry should be available where developer environments permit repository-local workspace automation.

·        Package-manager telemetry should be available from developer systems, CI/CD jobs, package caches, internal mirrors, build images, lockfiles, package manifests, and artifact records.

·        Source-code platform telemetry should be available for repository activity, workflow changes, token use, deploy keys, webhooks, branch protections, secrets-related activity, OAuth activity, GitHub App activity, and organization-level administrative events.

·        npm registry telemetry should be available for package publication, package metadata changes, maintainer changes, ownership changes, token activity, provenance status, trusted-publishing context where available, and organization-level package access.

·        Cloud, identity, token, and secrets telemetry should be available for accounts, projects, subscriptions, tenants, identities, service accounts, access keys, secret stores, deployment workflows, and automation identities connected to development or release activity.

·        Network telemetry should cover developer endpoints, CI/CD runners, release systems, package-publishing systems, artifact repositories, package mirrors, build networks, cloud build environments, and outbound communication from developer or automation systems.

·        Artifact, container, SBOM, cache, internal mirror, and release telemetry should be retained long enough to reconstruct whether exposed dependencies, suspicious package material, or workspace task files entered build outputs or customer-facing releases.

·        Incident-response records, vulnerability management records, package exposure records, credential rotation records, token revocation records, and change-management records should be available to separate exposure, execution, suspected credential theft, remediation, and post-remediation validation.

Telemetry Limitations and Gaps

·        Managed CI/CD runners, ephemeral build containers, hosted developer workspaces, contractor systems, or third-party-supported environments may not expose full endpoint, file, process, memory, network, or IDE telemetry to the customer.

·        Developer endpoints may not consistently retain full command-line logging, parent-child process lineage, file-read telemetry, network-by-process telemetry, workspace-open telemetry, or IDE task-execution telemetry.

·        IDE telemetry may show parent-child process behavior but not directly record why a task executed, whether workspace trust was granted, or which task file triggered the process.

·        Package-install logs may be absent, truncated, overwritten, or unavailable for historical dependency restoration events.

·        npm, GitHub, source-code platform, cloud, identity, and CI/CD audit logs may be incomplete, unavailable, license-limited, retention-limited, or not centrally collected.

·        Trusted-publishing or OIDC records may not preserve the workflow identity, repository, ref, triggering event, publishing subject, or trust relationship at the level required to reconstruct an authorized but compromised publication path.

·        Network telemetry may identify suspicious egress but may not prove credential theft, data exfiltration, token reuse, package propagation, or actor attribution by itself.

·        TLS encryption may prevent content-level validation of outbound transfer.

·        File telemetry may not capture reads from sensitive credential paths, temporary staging, short-lived files, deleted files, archive creation, or encrypted output.

·        Internal mirrors, dependency caches, build images, containers, and artifact stores may retain affected package versions even after public registry remediation.

·        Artifact records may not preserve package provenance, source commit, runner identity, build context, workspace material, or dependency source at the level needed for high-confidence reconstruction.

·        Missing change-management context may increase false positives around developer testing, release automation, package publishing, dependency updates, CI/CD changes, IDE tasks, incident response, and security research.

·        Telemetry gaps should reduce confidence ratings, shift detections toward hunt mode, increase investigation requirements, or trigger precautionary credential rotation rather than force unsupported compromise conclusions.

Telemetry Requirements Disposition

Telemetry requirements for this report should be organized around developer supply-chain reconstruction rather than static package inventory alone. The highest-confidence posture connects package exposure, npm lifecycle execution, IDE-spawned runtime activity where applicable, unexpected runtime bootstrapping, credential access, local staging, suspicious egress, token reuse, GitHub activity, npm registry activity, trusted-publishing context, cloud-control-plane activity, artifact records, and release assurance.

The primary SAP npm lifecycle execution model remains the governing detection path. IDE workspace-task abuse and Shai-Hulud-style trusted-publishing abuse should be retained as Coverage With Adaptation within existing developer endpoint, repository, package-publishing, and telemetry-gap coverage, not as separate report-driving telemetry architectures. Where direct process, file, IDE, CI/CD, or audit visibility is incomplete, organizations should compensate with package-cache review, lockfile review, internal mirror review, workspace task-file review, credential rotation, GitHub and npm audit review, trusted-publishing validation, cloud audit review, artifact validation, and release-provenance assurance.

S24 — Detection Opportunities and Gaps

Figure 4

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.

·        Detecting package-publishing workflow changes shortly before an authorized trusted-publication event.

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 or automation identity, repository action, source location, workflow modification, sensitive secret behavior, or proximity to suspicious endpoint, CI/CD, or package-publishing activity.

Detection Opportunity 5 — npm Registry and Package-Publishing Abuse

npm registry activity is a high-impact detection opportunity because stolen npm credentials or compromised trusted-publishing workflows 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, release windows, workflow identities, repositories, refs, or triggering events.

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

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

·        Correlating trusted publication with the originating workflow identity, repository, ref, triggering event, OIDC publishing subject or workload identity, trusted-publishing relationship, provenance or build context, and preceding workflow changes.

Primary Gap

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

Valid provenance or signing does not prove benign intent when the legitimate repository or release workflow itself has been compromised. A malicious package may be built and published through an authorized workflow and therefore retain valid provenance associated with that trusted release path.

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, workflow identities, repository and ref scope, triggering events, OIDC trust relationships, package provenance, preceding workflow changes, and recent suspicious developer or CI/CD activity. Provenance validity should be treated as one contextual signal rather than a standalone benign verdict.

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.

·        Trusted publication where workflow identity, repository, ref, triggering event, OIDC trust relationship, provenance context, or preceding workflow changes are inconsistent with the approved release path.

·        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, trusted-publishing, provenance, and package-publication telemetry may be incomplete or inconsistently retained.

Impact:

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

·        Exposure review may require package history, package metadata, provenance records, workflow context, 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 or workflow abuse may be visible only as API activity, repository changes, workflow execution, or package publication without full credential or workflow 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, workflow manipulation, trusted-publishing 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, trusted-publishing, provenance, and metadata changes after exposure.

·        Review trusted package publication against the originating workflow identity, repository, ref, triggering event, OIDC trust relationship, provenance context, and preceding workflow changes.

·        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, workflow modification, trusted publication, and downstream propagation. The most significant gaps are managed runner visibility, ephemeral build retention, developer endpoint variability, limited registry audit depth, encrypted egress, weak credential attribution, and incomplete trusted-publishing or provenance context. Where those gaps exist, exposure review, secret rotation, workflow validation, trusted-publishing review, artifact review, provenance-context validation, and post-exposure control-plane auditing are required to reduce residual risk.

S25 — Ultra-Tuned Detection Engineering Rules

NDR / Network Behavioral Analytics

Detection Viability Assessment

·        NDR / Network Behavioral Analytics is viable for detecting suspicious network behavior associated with SAP-related npm package poisoning, Shai-Hulud-style developer credential theft, suspicious developer-service egress, outbound communication from developer or CI/CD environments, and network activity following package-manager, IDE, runtime, credential-access, staging, GitHub, npm, cloud, or identity signals.

·        NDR / Network Behavioral Analytics is strongest where network-flow telemetry, DNS telemetry, TLS telemetry, HTTP metadata, proxy telemetry, firewall telemetry, secure access telemetry, NDR asset inventory, developer endpoint inventory, CI/CD runner inventory, approved-destination baselines, source-role baselines, repository context, package context, and SIEM correlation can be combined.

·        NDR / Network Behavioral Analytics can identify suspicious sequencing between package exposure, npm lifecycle execution, IDE workspace-triggered execution, unexpected runtime activity, credential-access indicators, local staging, upload-like traffic, rare developer-service destinations, newly observed external destinations, GitHub API access, raw-content access, webhook access, cloud-storage access, paste-like service access, blockchain-related service access, and downstream token or control-plane activity.

·        NDR / Network Behavioral Analytics is not a standalone source for confirming npm lifecycle execution, setup.mjs execution, IDE workspace task autorun, VS Code or Cursor parent-child process lineage, local credential-file access, local staging, credential theft, package-registry abuse, cloud-control-plane compromise, or actor attribution because network telemetry may not observe local process lineage, file access, package-manager context, workspace task files, local execution state, or attacker intent.

·        NDR / Network Behavioral Analytics detections must be correlated with endpoint telemetry, CI/CD telemetry, package-manager telemetry, IDE process-lineage telemetry where available, GitHub audit logs, npm registry logs, cloud audit logs, identity logs, file telemetry, artifact telemetry, change-management records, and incident-response evidence before activity is classified as probable compromise.

·        NDR / Network Behavioral Analytics detection content should be treated as high-value behavioral coverage for suspicious egress detection, exfiltration triage, developer-service misuse review, rare destination analysis, post-exposure scoping, and SIEM correlation, not direct confirmation of malicious package execution or workspace-task execution.

·        NDR / Network Behavioral Analytics rules should not generate high-confidence alerting from package exposure alone, GitHub access alone, npm registry access alone, cloud storage access alone, webhook access alone, raw-content access alone, isolated DNS requests alone, isolated TLS anomalies alone, isolated rare destination access alone, or ordinary developer egress alone.

Rule

Suspicious Developer or CI/CD Egress Following Package or Workspace Execution Behavior

Rule Format

Vendor-neutral NDR behavioral analytics rule template suitable for network-flow telemetry, DNS telemetry, TLS telemetry, HTTP telemetry, proxy telemetry, firewall telemetry, secure access telemetry, NDR asset inventory, developer endpoint inventory, CI/CD runner inventory, approved-destination baselines, source-role baselines, destination-category enrichment, TLS fingerprint enrichment, DNS enrichment, repository context, package context, workflow context, identity context, and SIEM correlation after local schema mapping, timing-window tuning, and environment-specific allowlisting.

Detection Purpose

·        Detect suspicious outbound communication from developer endpoints, CI/CD runners, release systems, package-publishing systems, build systems, artifact systems, or cloud-connected developer environments following package execution, IDE workspace-triggered execution, credential-access indicators, local staging, or post-exposure token activity.

·        Identify outbound activity to newly observed domains, rare destinations, unusual ASNs, hosting-provider destinations, raw-content services, webhook services, cloud-storage services, paste-like services, file-sharing services, blockchain-related services, package repositories, GitHub API destinations, npm-related destinations, or uncategorized external destinations that are inconsistent with approved developer or build workflows.

·        Prioritize activity where suspicious network behavior and suspicious local execution or exposure context occur together rather than treating normal developer access to GitHub, npm, cloud platforms, package repositories, or collaboration services as compromise evidence.

·        Support escalation when suspicious egress follows npm lifecycle execution, setup.mjs activity, IDE-spawned runtime execution, .vscode/tasks.json or equivalent workspace task activity, runtime execution from dependency or workspace paths, credential access, local staging, GitHub token activity, npm token activity, cloud credential activity, or artifact-impact signals.

·        Preserve separation between suspicious outbound behavior and confirmed compromise by requiring supporting endpoint, CI/CD, package-manager, IDE, file, identity, GitHub, npm, cloud, artifact, or incident-response evidence before classifying activity as probable credential theft, exfiltration, propagation, or downstream compromise.

·        This rule does not prove successful npm package execution, IDE workspace task execution, credential theft, exfiltration, cloud compromise, package-registry abuse, or actor attribution without supporting telemetry and investigation evidence.

Detection Logic

·        Identify network, DNS, TLS, HTTP, proxy, firewall, secure access, or NDR flow events originating from verified developer endpoints, CI/CD runners, release systems, package-publishing systems, build systems, artifact systems, or cloud-connected developer environments.

·        Prioritize outbound destinations that are newly observed, rare for the source, rare for the asset role, rare for the repository or runner, inconsistent with approved workflow context, associated with raw-content services, webhook services, paste-like services, cloud-storage services, file-sharing services, blockchain-related services, uncategorized external services, suspicious ASNs, unusual hosting providers, or newly observed TLS/SNI patterns.

·        Prioritize outbound activity with upload-like behavior, abnormal byte volume, abnormal upload-to-download ratio, repeated outbound attempts, unusual connection frequency, new TLS fingerprint, new SNI, unusual DNS pattern, role-inconsistent destination category, or source behavior inconsistent with approved package retrieval, build automation, deployment, monitoring, security tooling, or developer testing.

·        Increase confidence when suspicious outbound activity occurs after package-manager lifecycle execution, setup.mjs activity, package-manager child-process execution, IDE-spawned runtime activity, workspace task-file creation or modification, runtime execution from dependency or workspace paths, credential-file access, local staging, GitHub activity, npm activity, cloud activity, identity activity, or artifact-impact signals.

·        Increase confidence when the source host is associated with package exposure, affected lockfiles, affected dependency caches, internal npm mirror retention, package installation during the exposure window, CI/CD runner activity, release workflow activity, package-publishing authority, maintainer identity, cloud deployment authority, or artifact-signing authority.

·        Reduce severity when outbound activity aligns with approved package retrieval, normal GitHub access, approved npm registry access, approved cloud deployment, approved monitoring, approved artifact upload, approved release automation, approved security testing, approved incident response, approved developer testing, documented package inspection, or normal CI/CD workflow behavior.

·        Do not classify GitHub access, npm access, cloud access, raw-content access, webhook access, DNS novelty, TLS novelty, upload volume, or rare destination access as compromise evidence by itself.

·        Do not treat network-visible egress as proof of credential theft, exfiltration, token abuse, package propagation, cloud-control-plane compromise, or actor attribution without supporting endpoint, file, CI/CD, source-code, package-registry, cloud, identity, artifact, or incident-response evidence.

Required Telemetry

·        Network-flow telemetry.

·        DNS telemetry.

·        HTTP metadata.

·        HTTPS metadata.

·        TLS SNI where available.

·        TLS certificate metadata where available.

·        JA3 or JA4 fingerprints where available.

·        Proxy telemetry where available.

·        Firewall egress telemetry.

·        Secure access telemetry where available.

·        NDR asset inventory.

·        Source IP.

·        Source host.

·        Source asset role.

·        Source subnet.

·        Destination IP.

·        Destination domain.

·        Destination host.

·        Destination port.

·        Protocol.

·        Application or service classification.

·        Destination category.

·        Destination ASN.

·        Destination hosting provider.

·        Destination geography.

·        Request path where available.

·        HTTP method where available.

·        User agent where available.

·        Byte volume.

·        Bytes out.

·        Bytes in.

·        Upload-to-download ratio.

·        Connection count.

·        Connection frequency.

·        Directionality.

·        First-seen destination context.

·        Rare destination context.

·        Newly observed domain context.

·        TLS fingerprint context.

·        SNI baseline context.

·        User identity where available.

·        Process attribution where available.

·        Developer endpoint inventory.

·        CI/CD runner inventory.

·        Release system inventory.

·        Package-publishing system inventory.

·        Build system inventory.

·        Artifact system inventory.

·        Repository context where available.

·        Package context where available.

·        Workflow context where available.

·        Approved destination inventory.

·        Approved package-repository inventory.

·        Approved GitHub and npm workflow records.

·        Approved cloud deployment records.

·        Approved release-window records.

·        Endpoint compromise signals where available.

·        CI/CD compromise signals where available.

·        GitHub audit signals where available.

·        npm registry signals where available.

·        Cloud audit signals where available.

·        Identity signals where available.

·        Change-management records.

·        Approved security-testing records.

·        Approved incident-response records.

Engineering Implementation Instructions

·        Build source asset groups covering developer endpoints, self-hosted CI/CD runners, managed runner egress where attributable, release systems, package-publishing systems, build systems, artifact systems, internal npm mirrors, dependency caches, container registries, and cloud-connected developer environments.

·        Build approved destination groups covering GitHub, npm, package repositories, internal artifact repositories, internal npm mirrors, approved cloud storage, approved deployment services, approved monitoring destinations, approved security tooling, approved webhook endpoints, approved raw-content dependencies, approved build dependencies, and approved release automation destinations.

·        Build suspicious or review-required destination groups covering newly observed domains, first-seen destinations, rare destinations, uncategorized services, paste-like services, file-sharing services, webhook services outside approved inventory, raw-content services outside approved inventory, blockchain-related services, unusual ASNs, unusual hosting providers, unusual geographies, and destinations inconsistent with the source role.

·        Build local compromise signal groups covering npm lifecycle execution, setup.mjs execution, package-manager child-process activity, IDE-spawned runtime activity, .vscode/tasks.json or equivalent workspace task-file activity, runtime execution from dependency or workspace paths, credential-file access, local staging, GitHub token activity, npm token activity, cloud credential activity, and artifact-impact signals.

·        Build upload and transfer anomaly groups covering unusual bytes out, unusual upload-to-download ratio, repeated outbound attempts, new TLS fingerprints, new SNI values, unusual DNS timing, role-inconsistent connection frequency, and outbound activity shortly after suspicious local execution.

·        Validate whether NDR, DNS, TLS, HTTP, proxy, firewall, secure access, endpoint, CI/CD, GitHub, npm, cloud, identity, artifact, and SIEM telemetry can reliably join on source host, source IP, user identity, runner identity, repository context, package context, destination domain, destination IP, event timestamp, asset role, and workflow context.

·        Use short correlation windows for outbound activity following package-manager execution, IDE-spawned runtime activity, credential-file access, local staging, or suspicious runtime execution.

·        Use moderate correlation windows for outbound activity following GitHub token activity, npm token activity, cloud credential activity, package-publishing activity, artifact activity, or identity-control-plane activity.

·        Use longer correlation windows only when repeated destination access, incident-response evidence, token-use evidence, artifact evidence, or downstream cloud or repository activity supports delayed linkage.

·        Add severity weighting for rare destinations, first-seen destinations, role-inconsistent destinations, raw-content destinations, webhook destinations, cloud-storage destinations, paste-like destinations, blockchain-related destinations, suspicious ASNs, unusual upload volume, abnormal upload-to-download ratio, and lack of approved workflow context.

·        Treat suspicious egress as a confidence amplifier, not standalone proof of npm package execution, IDE workspace task execution, credential theft, exfiltration, token abuse, or downstream compromise.

·        Use approved destination records, approved package-repository records, approved GitHub workflow records, approved npm workflow records, approved cloud deployment records, release-window records, vulnerability-management records, security-testing records, incident-response records, and change-management records as triage evidence.

·        Validate all environment variables, source asset groups, approved destination groups, suspicious destination groups, local compromise signal groups, transfer anomaly groups, timing windows, enrichment fields, exception logic, parser behavior, join logic, and local schema mappings before production deployment.

·        Do not enable alert mode until field availability, destination-category quality, TLS metadata quality, DNS visibility, source attribution, asset inventory, approved-destination quality, local-signal correlation, false-positive rate, query performance, SOC triage workflow, enrichment availability, exception handling, and incident-response evidence requirements are validated.

DRI Assessment

·        The rule is behaviorally anchored to suspicious outbound behavior from developer and CI/CD environments following package-manager execution, IDE-spawned runtime activity, credential-access indicators, local staging, or post-exposure token activity rather than static package names, hashes, fixed domains, fixed IP addresses, proof-of-concept labels, or known actor infrastructure.

·        The rule remains useful if an adversary changes package names, staging filenames, exfiltration infrastructure, user agents, destination domains, request paths, TLS certificates, request timing, or outbound service selection.

·        The score is supported by the durability of rare destination analysis, first-seen destination analysis, role-inconsistent egress, upload-like behavior, unusual TLS or SNI behavior, suspicious developer-service destinations, and correlation with local execution or credential-access signals.

·        The score is constrained by missing source attribution, missing process attribution, weak destination baselines, normal developer access to external services, TLS encryption, unmanaged developer systems, managed runner visibility limits, and incomplete local compromise correlation.

·        The rule is durable as a suspicious egress and post-exposure scoping detector but should not be treated as standalone proof of package execution, workspace-task execution, credential theft, exfiltration, token abuse, or actor attribution.

DRI

7.9 / 10

TCR Assessment

·        Operational confidence depends on reliable source asset inventory, developer endpoint inventory, CI/CD runner inventory, destination categorization, DNS visibility, TLS metadata, flow telemetry, approved-destination baselines, source-role baselines, and SIEM correlation quality.

·        Operational confidence is reduced where developer endpoints frequently access GitHub, npm, cloud storage, raw-content hosts, webhook services, package repositories, or collaboration platforms without strong repository, workflow, destination, and user context.

·        Operational confidence is reduced where managed runners, contractor systems, hosted workspaces, personal repositories, or unmanaged endpoints lack reliable source attribution or local compromise telemetry.

·        Full-telemetry confidence improves when suspicious egress is enriched with endpoint telemetry, CI/CD logs, package-manager logs, IDE process-lineage telemetry where available, file telemetry, GitHub audit logs, npm registry logs, cloud audit logs, identity logs, artifact records, change-management records, and incident-response evidence.

·        Even under full telemetry conditions, this rule should support suspicious egress escalation, triage, and scoping rather than standalone confirmation of credential theft or exfiltration.

Operational TCR

7.4 / 10

Full-Telemetry TCR

8.5 / 10

Limitations

·        This rule detects suspicious outbound network behavior following package or workspace execution context, not confirmed malicious execution by itself.

·        NDR may not observe npm lifecycle execution, setup.mjs execution, VS Code or Cursor process lineage, .vscode/tasks.json execution, local credential-file access, local staging, package-registry activity, cloud-control-plane action details, or local attacker intent without enrichment.

·        Normal developer and CI/CD workflows may generate GitHub, npm, cloud-storage, package-repository, webhook, raw-content, artifact-upload, monitoring, and security-tooling traffic.

·        Missing DNS visibility, TLS metadata, destination categorization, approved-destination baselines, source attribution, user mapping, asset inventory, or process attribution can reduce confidence.

·        The rule may miss exfiltration or staging traffic that uses approved destinations, expected developer services, approved cloud paths, low-volume transfer, delayed transfer, encrypted channels, or traffic that blends into normal release automation.

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

·        The rule should not be enabled as high-confidence standalone alerting without correlation to endpoint, CI/CD, IDE, package-manager, credential-access, GitHub, npm, cloud, identity, artifact, or incident-response evidence.

Detection Query Pattern

Vendor-neutral NDR correlation rule pattern for suspicious developer or CI/CD egress following package or workspace execution behavior. This pattern requires target-platform syntax conversion, asset validation, destination-category validation, TLS and DNS field validation, timing-window tuning, source-role validation, local-signal correlation, and environment-specific allowlisting before production deployment.

NetworkEvent AS DeveloperOrCICDEgress

WHERE DeveloperOrCICDEgress.SourceAsset IN ASSET_GROUP (

"Developer Endpoints",

"Self-Hosted CI/CD Runners",

"Attributable Managed Runner Egress",

"Release Engineering Systems",

"Package Publishing Systems",

"Build Systems",

"Artifact Systems",

"Internal npm Mirrors",

"Dependency Cache Systems",

"Container Registry Systems",

"Cloud Connected Developer Environments"

)

AND DeveloperOrCICDEgress.Direction IN ANY (

"OUTBOUND",

"EGRESS",

"EXTERNAL_DESTINATION"

)

AND (

DeveloperOrCICDEgress.DestinationCategory IN ANY (

"github_api",

"raw_content_service",

"webhook_service",

"paste_service",

"cloud_storage",

"file_sharing",

"blockchain_related",

"package_repository",

"npm_registry",

"uncategorized_external_service",

"newly_observed_domain"

)

OR DeveloperOrCICDEgress.DestinationContext IN ANY (

"first_seen_for_source",

"rare_for_source",

"rare_for_asset_role",

"rare_for_repository",

"rare_for_runner",

"destination_not_in_approved_workflow",

"unusual_asn",

"unusual_hosting_provider",

"unusual_geography",

"new_sni_for_source",

"new_tls_fingerprint_for_source"

)

OR DeveloperOrCICDEgress.TransferPattern IN ANY (

"unusual_bytes_out",

"abnormal_upload_to_download_ratio",

"repeated_outbound_attempts",

"upload_like_behavior",

"role_inconsistent_connection_frequency",

"outbound_after_local_staging_window"

)

)

AND DeveloperOrCICDEgress.Destination NOT IN ASSET_GROUP (

"Approved GitHub Workflow Destinations",

"Approved npm Registry Destinations",

"Approved Package Repository Destinations",

"Approved Cloud Deployment Destinations",

"Approved Artifact Upload Destinations",

"Approved Monitoring Destinations",

"Approved Security Tooling Destinations",

"Approved Build Dependency Destinations",

"Approved Release Automation Destinations",

"Approved Developer Testing Destinations"

)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_LOCAL_EXECUTION_TO_EGRESS_WINDOW (

EndpointOrCIEvent AS LocalExecutionSignal

WHERE LocalExecutionSignal.Asset IN SAME_SOURCE (

DeveloperOrCICDEgress.SourceAsset

)

AND LocalExecutionSignal.EventPattern IN ANY (

"npm_lifecycle_execution",

"setup_mjs_execution",

"package_manager_child_process_execution",

"ide_spawned_runtime_execution",

"workspace_task_file_created_or_modified",

"runtime_execution_from_dependency_path",

"runtime_execution_from_workspace_path",

"runtime_execution_from_ci_working_directory",

"credential_file_access",

"local_staging_behavior"

)

)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_TOKEN_OR_CONTROL_PLANE_WINDOW (

SaaSCloudIdentityEvent AS DownstreamSignal

WHERE DownstreamSignal.ActorContext IN SAME_USER_OR_SOURCE (

DeveloperOrCICDEgress.SourceUser,

DeveloperOrCICDEgress.SourceIP

)

AND DownstreamSignal.EventPattern IN ANY (

"github_token_activity",

"github_repository_change",

"github_workflow_change",

"npm_token_activity",

"npm_package_publish_activity",

"cloud_secret_access",

"cloud_control_plane_activity",

"identity_control_plane_activity",

"artifact_or_release_activity"

)

)

AND OPTIONAL_CONFIDENCE_INCREASE WITHIN ENV_ARTIFACT_CONTEXT_WINDOW (

ArtifactOrPackageEvent AS ExposureSignal

WHERE (

ExposureSignal.RepositoryContext IN SAME_REPOSITORY (

DeveloperOrCICDEgress.RepositoryContext

)

OR ExposureSignal.PackageContext IN SAME_PACKAGE (

DeveloperOrCICDEgress.PackageContext

)

)

AND ExposureSignal.EventPattern IN ANY (

"affected_package_in_lockfile",

"affected_package_in_dependency_cache",

"affected_package_in_internal_mirror",

"affected_package_in_build_artifact",

"workspace_task_file_in_project_material",

"artifact_created_during_exposure_window",

"release_created_during_exposure_window"

)

)

AND NOT ChangeContext IN ANY (

"approved_dependency_update",

"approved_release_automation",

"approved_package_publish",

"approved_cloud_deployment",

"approved_artifact_upload",

"approved_security_testing",

"approved_vulnerability_management",

"approved_incident_response",

"approved_developer_testing",

"approved_package_inspection"

)

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, local staging behavior, process-environment access, or Linux runtime material access.

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, local staging artifacts, process-environment data, or Linux runtime material.

The rule preserves coverage for suspicious /proc/self/environ, /proc/self/maps, /proc/self/mem, printenv, and environment-token access behavior without keeping the older Linux CI runner harvesting behavior as a separate SentinelOne rule.

The rule should not alert on Bun or Node execution alone. It should require abnormal runtime location, dependency-path context, cache-path context, CI workspace context, package-manager ancestry, credential-path access, local staging behavior, sensitive environment access, or follow-on outbound activity.

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.

·        Linux path visibility where available.

·        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, cache, 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, process-environment access, local staging behavior, or follow-on outbound activity.

Engineers should treat /proc/self/environ, /proc/self/maps, /proc/self/mem, printenv, and token-related command-line access as high-confidence context when observed from Bun, Node, package-manager-descended processes, dependency paths, cache paths, temporary paths, user-profile paths, or CI workspace paths.

The rule should not alert on all /proc access, all environment-variable access, all Node execution, or all Bun execution. It should require suspicious runtime context plus credential, environment, staging, dependency, or CI workspace indicators.

Tiering Data

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

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

·        Tier 3: Correlate with package-install logs, GitHub audit activity, npm registry events, proxy logs, DNS logs, identity telemetry, NDR egress context, and CI job identity.

·        Tier 4: Add repository-specific runtime baselines, approved build-image context, runner baseline, internal dependency-cache context, package-manager ancestry, and known developer tooling exceptions.

DRI Assessment

Detection Robustness Index

8.5 / 10

DRI Justification

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

The score is supported by the combination of abnormal Bun or Node execution path, dependency or CI workspace context, credential-path access, environment-access indicators, and local staging signals. The score is constrained by environments where Bun, Node, package managers, and developer tooling are heavily used across approved workflows.

TCR Assessment

Operational TCR

7.7 / 10

Operational TCR Justification

Operational confidence depends on SentinelOne file-access visibility, process-lineage visibility, command-line capture, Linux path visibility, runner context, and whether sensitive path or /proc/self interactions are captured consistently. Process telemetry alone provides useful signal, but file-access, staging, environment-access, and network-by-process telemetry materially improve confidence.

Full-Telemetry TCR

8.6 / 10

Full-Telemetry TCR Justification

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

Limitations

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

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

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

·        The rule is strongest where developer endpoints, release systems, and self-hosted CI/CD runners have strong process-lineage, file-access, path, and network-by-process visibility.

·        This rule detects suspicious runtime and credential-access behavior and should not be treated as standalone proof of credential theft, exfiltration, package propagation, cloud compromise, or actor attribution.

Detection Code

// SentinelOne Deep Visibility Query

// Detect Bun or Node from abnormal dependency, cache, temporary, user-profile,

// or CI paths with credential-access, environment-access, or staging indicators.

(

  TgtProcName In Contains AnyCase (

    "bun",

    "bun.exe",

    "node",

    "node.exe"

  )

)

AND

(

  TgtProcImagePath In Contains AnyCase (

    "node_modules",

    ".npm",

    ".pnpm",

    ".cache",

    "tmp",

    "temp",

    "workspace",

    "actions-runner",

    "_work"

  )

  OR

  TgtProcCmdLine In Contains AnyCase (

    "setup.mjs",

    "preinstall",

    "postinstall",

    "node_modules",

    ".npm",

    ".pnpm",

    ".cache",

    "_work",

    "actions-runner",

    "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",

    "/proc/self/environ",

    "/proc/self/maps",

    "/proc/self/mem",

    "cat /proc/self/environ",

    "printenv",

    "process.env"

  )

  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",

    "/proc/self/environ",

    "/proc/self/maps",

    "/proc/self/mem"

  )

)

SentinelOne Rule 3

IDE Workspace Task or Developer Tool Execution Spawning Suspicious Runtime Activity

Rule Format

SentinelOne Deep Visibility Query with STAR deployment candidate.

Detection Objective

Detect suspicious developer-tool execution where VS Code, Cursor, or related IDE processes spawn Node, npm, Bun, Python, shell, PowerShell, downloader, archive, or command-execution utilities from project, repository, workspace, dependency, extracted archive, or CI/CD working paths.

Detection Logic

This rule detects adapted developer-workspace execution behavior where trusted IDE activity becomes the parent process for suspicious runtime execution. It focuses on IDE parent processes spawning child processes commonly used for loader execution, script execution, dependency execution, credential discovery, staging, downloader activity, archive handling, or outbound preparation.

The rule is designed for Coverage With Adaptation. It does not replace the report’s primary SAP npm lifecycle execution model. Instead, it extends endpoint coverage to a related developer-supply-chain execution path where repository-local workspace configuration, IDE task behavior, folder-open task execution, or project-controlled paths can trigger local runtime activity.

The rule should not alert on IDE activity alone. It should require suspicious child-process execution, workspace or repository path context, task-file context, downloader behavior, encoded-command behavior, credential-access indicators, staging indicators, or follow-on outbound activity.

Required Telemetry

·        Process creation.

·        Parent-child process lineage.

·        Full command-line arguments.

·        Process path.

·        Working directory.

·        File creation or file modification telemetry where available.

·        File access telemetry where available.

·        User identity.

·        Host identity.

·        Endpoint group or site context.

·        Developer workstation tagging where available.

·        CI/CD runner tagging where available.

·        Network telemetry by process where available.

Engineering Implementation Instructions

Engineers should scope this rule to developer endpoints, release engineering systems, package-publishing systems, build systems, and self-hosted CI/CD runners where IDE activity, repository access, package development, or release workflow activity occurs.

Engineers should baseline approved IDE behavior before production deployment. Expected IDE-spawned terminals, language servers, extension hosts, build tasks, test runners, linters, debuggers, package managers, and repository-specific tooling should be documented before alert mode is enabled.

Production alerting should require IDE parent-process activity plus suspicious child-process behavior and at least one context amplifier such as project-path execution, workspace-path execution, .vscode/tasks.json or equivalent task-file activity, dependency-path execution, downloader invocation, encoded command behavior, credential-path access, local staging, or suspicious outbound activity.

This rule should not suppress all VS Code, Cursor, Node, npm, Bun, Python, shell, PowerShell, curl, wget, archive utility, or terminal activity. Suppression should be limited to approved repositories, approved extensions, approved task definitions, expected build workflows, known developer tooling, and documented release automation.

Tiering Data

·        Tier 1: Deploy as a hunt on developer endpoints and self-hosted CI/CD runners with known repository, package, or IDE workflow exposure.

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

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

·        Tier 4: Add repository, workspace, runner, build-image, approved extension, approved task-file, approved runtime, release workflow, dependency-cache, internal mirror, and package-publishing context to reduce noise and support higher-confidence escalation.

DRI Assessment

Detection Robustness Index

8.4 / 10

DRI Justification

The rule is behaviorally anchored on IDE parent-process execution, suspicious child-process behavior, workspace or repository path context, and follow-on credential, staging, or egress indicators rather than static package names, filenames, hashes, or infrastructure. It remains useful across task-file changes, package-name changes, loader-name changes, staging-name changes, and exfiltration-infrastructure changes because it detects the local execution transition from trusted developer tooling into suspicious runtime or command activity.

The score is slightly lower than the primary npm lifecycle rule because IDE environments commonly spawn terminals, language servers, test runners, package managers, and build tools. Production precision depends on repository context, approved-task baselines, child-process behavior, path context, and follow-on telemetry.

TCR Assessment

Operational TCR

7.8 / 10

Operational TCR Justification

Operational confidence depends on SentinelOne coverage across developer endpoints, release systems, package-publishing systems, and self-hosted CI/CD runners with full command-line, parent-child process, working-directory, file, and network telemetry enabled. Confidence is reduced where IDE telemetry is incomplete, developers frequently use custom task files, or endpoint policies do not capture file access, working directory, or network-by-process context.

Full-Telemetry TCR

8.7 / 10

Full-Telemetry TCR Justification

With full endpoint telemetry, SentinelOne can capture IDE parent processes, child process names, command lines, process paths, file access, task-file activity, staging behavior, and process-linked outbound activity. When correlated with repository, GitHub, npm, identity, cloud, and NDR telemetry, this rule can provide strong evidence of suspicious developer-workspace execution.

Limitations

·        Legitimate IDE usage may spawn terminals, shells, Node, npm, Python, Bun, test runners, linters, debuggers, language servers, package managers, or build tools.

·        VS Code and Cursor extensions may legitimately create or execute workspace tasks.

·        Developer workstations with broad scripting and custom automation require repository, extension, task-file, and workflow baselines.

·        File-access visibility may vary by operating system, endpoint policy, and SentinelOne configuration.

·        Managed or hosted developer environments may not provide full SentinelOne process telemetry.

·        This rule detects suspicious developer-tool execution behavior and should not be treated as standalone proof of credential theft, exfiltration, package propagation, cloud compromise, or actor attribution.

Detection Code

// SentinelOne Deep Visibility Query

// Detect suspicious IDE or developer-tool parent processes spawning runtime,

// shell, downloader, archive, or command-execution utilities from workspace,

// repository, dependency, extracted archive, or CI/CD working paths.

(

  SrcProcName In Contains AnyCase (

    "code",

    "code.exe",

    "Code.exe",

    "cursor",

    "cursor.exe",

    "Cursor.exe"

  )

  OR

  SrcProcCmdLine In Contains AnyCase (

    "Visual Studio Code",

    "Microsoft VS Code",

    "Code.exe",

    "Cursor",

    "cursor"

  )

)

AND

(

  TgtProcName In Contains AnyCase (

    "node",

    "node.exe",

    "npm",

    "npm.cmd",

    "npx",

    "npx.cmd",

    "pnpm",

    "pnpm.cmd",

    "yarn",

    "yarn.cmd",

    "bun",

    "bun.exe",

    "python",

    "python.exe",

    "python3",

    "sh",

    "bash",

    "zsh",

    "cmd.exe",

    "powershell.exe",

    "pwsh.exe",

    "curl",

    "curl.exe",

    "wget",

    "wget.exe",

    "tar",

    "tar.exe",

    "unzip",

    "unzip.exe",

    "7z",

    "7z.exe"

  )

)

AND

(

  TgtProcCmdLine In Contains AnyCase (

    ".vscode",

    "tasks.json",

    "runOn",

    "folderOpen",

    "node_modules",

    ".npm",

    ".pnpm",

    ".cache",

    "workspace",

    "repository",

    "repo",

    "actions-runner",

    "_work",

    "package.json",

    "preinstall",

    "postinstall",

    "setup.mjs",

    "curl ",

    "wget ",

    "-enc",

    "-encodedcommand",

    "base64",

    "chmod +x",

    "socket.io-client"

  )

  OR

  TgtProcImagePath In Contains AnyCase (

    ".vscode",

    "node_modules",

    ".npm",

    ".pnpm",

    ".cache",

    "workspace",

    "repository",

    "repo",

    "actions-runner",

    "_work",

    "tmp",

    "temp"

  )

)

AND

(

  TgtProcCmdLine In Contains AnyCase (

    ".npmrc",

    ".ssh",

    "id_rsa",

    "id_ed25519",

    ".aws/credentials",

    ".azure",

    ".config/gcloud",

    ".kube/config",

    "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 (

    ".vscode/tasks.json",

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

  TgtProcCmdLine In Contains AnyCase (

    "curl ",

    "wget ",

    "http://",

    "https://",

    "api.github.com",

    "raw.githubusercontent.com",

    "gist.githubusercontent.com",

    "webhook",

    "paste",

    "socket.io-client"

  )

)

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. Splunk should also correlate adapted IDE or workspace-triggered runtime execution where developer tooling, workspace task behavior, or project-controlled paths are followed by credential access, local staging, GitHub activity, npm registry activity, identity activity, or suspicious outbound behavior. 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. Local compromise signals may also include adapted IDE or workspace-triggered runtime execution where VS Code, Cursor, workspace task behavior, or project-controlled paths are followed by credential access, local staging, or suspicious developer-service activity.

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 GitHubaudit 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. Local compromise or credential-access indicators may also include adapted IDE or workspace-triggered runtime execution where VS Code, Cursor, workspace task behavior, or project-controlled paths are followed by credential access, local staging, npm token exposure, package-publishing activity, or suspicious registry-related behavior.

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. Elastic should also correlate adapted IDE or workspace-triggered runtime execution where developer tooling, workspace task behavior, or project-controlled paths are followed by credential access, local staging, SaaS activity, cloud activity, or suspicious outbound behavior.7.9 / 10 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

·        7.9/10

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

·        8.8 / 10

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.

This rule may also support Coverage With Adaptation where Bun or Node execution is triggered from developer workspace, IDE task, repository, cache, temporary, or CI workspace context and is followed by credential-file access, process-environment discovery, or local staging behavior.

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

·        7.4/10

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

·        8.6/10

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, developer workspace, IDE task, repository,

  or CI workspace paths followed by credential access, process-environment

  access, Linux runtime material 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*", "*.cache*",

          "*.vscode*", "*tasks.json*", "*runOn*", "*folderOpen*",

          "*socket.io-client*"

        )

      )

    ]

    [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*",

          "*/proc/self/environ*", "*/proc/self/maps*", "*/proc/self/mem*"

        ) or

file.name : (

          ".npmrc", "id_rsa", "id_ed25519", "environment.json",

          "cloud.json", "data.json", "environ", "maps", "mem"

        )

      )

    ]

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,

  adapted IDE or workspace-triggered runtime execution, credential-access indicators,

  or local staging behavior 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*", "*.vscode*", "*tasks.json*", "*runOn*", "*folderOpen*",

            "*socket.io-client*"

          )

        )

      ) or

      (

        event.category == "file" and event.type in ("access", "change", "creation") and

        file.path : (

          "*.npmrc*", "*.ssh*", "*.aws/credentials*", "*.kube/config*",

          "*secrets*", "*token*", "*credential*", "*.vscode/tasks.json*"

        )

      )

    ]

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

QRadar should also correlate adapted IDE or workspace-triggered runtime execution where developer tooling, workspace task behavior, or project-controlled paths are followed by credential access, local staging, suspicious egress, GitHub activity, npm registry activity, identity 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.

Stage 1 local compromise signals may also include adapted IDE or workspace-triggered runtime execution where VS Code, Cursor, workspace task behavior, or project-controlled paths are followed by credential access, local staging, suspicious egress, GitHub activity, npm registry activity, identity activity, or cloud-control-plane activity.

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("ProcessCommandLine") LIKE '%visual studio code%'

    OR LOWER("ProcessCommandLine") LIKE '%cursor%'

    OR LOWER("ProcessCommandLine") LIKE '%.vscode%'

    OR LOWER("ProcessCommandLine") LIKE '%tasks.json%'

    OR LOWER("ProcessCommandLine") LIKE '%runon%'

    OR LOWER("ProcessCommandLine") LIKE '%folderopen%'

    OR LOWER("ProcessCommandLine") LIKE '%socket.io-client%'

    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 '%.vscode%'

    OR LOWER("ProcessCommandLine") LIKE '%tasks.json%'

    OR LOWER("ProcessCommandLine") LIKE '%runon%'

    OR LOWER("ProcessCommandLine") LIKE '%folderopen%'

    OR LOWER("ProcessCommandLine") LIKE '%socket.io-client%'

    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 '%.vscode/tasks.json%'

    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 also cover adapted IDE or workspace-triggered runtime execution where developer tooling, workspace task behavior, or project-controlled paths are followed by suspicious runtime execution, credential access, local staging, or suspicious process behavior.activity, identity activity, or cloud-control-plane activity.

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

·        7.8/10

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

·        8.6/10

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

·        7.1/10

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

·        8.2/10

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'
      - '.vscode'
  selection_process_cmd:
    CommandLine|contains:
      - 'setup.mjs'
      - 'preinstall'
      - 'postinstall'
      - 'node_modules'
      - '.npm'
      - '.pnpm'
      - 'GITHUB_TOKEN'
      - 'npm_TOKEN'
      - 'AWS_ACCESS_KEY'
      - 'SECRET'
      - 'TOKEN'
      - '.vscode'
      - 'tasks.json'
      - 'runOn'
      - 'folderOpen'
      - 'socket.io-client'
  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

·        6.8/10

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

·        7.8/10

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

        $workspace_task_1 = ".vscode/tasks.json" ascii nocase

        $workspace_task_2 = "tasks.json" ascii nocase

        $workspace_task_3 = "runOn" ascii nocase

        $workspace_task_4 = "folderOpen" ascii nocase

        $workspace_task_5 = "presentation" ascii nocase

        $workspace_task_6 = "reveal" ascii nocase

        $workspace_task_7 = "hidden" ascii nocase

        $workspace_task_8 = "dependsOn" ascii nocase

        $workspace_task_9 = "socket.io-client" 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

                1 of ($workspask_*) or

                2 of ($exfil_strong_*) or

                (

                    1 of ($exfil_strong_*) and

                    1 of ($exfil_weak_*)

                )

            )

        )

}

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 Purpose

This section maps the SAP-related npm package poisoning and Shai-Hulud-style developer credential theft behavior model to the finalized S25 detection-rule inventory. The traceability model is behavior-led and separates suspicious package-manager lifecycle execution, adapted IDE or workspace-triggered runtime execution, abnormal Bun or Node activity, credential access, local secret staging, suspicious egress, GitHub activity, npm registry activity, downstream cloud activity, and artifact-level package triage.

Package names, proof-of-concept labels, scanner output, dependency exposure, repository presence, isolated package-install activity, isolated IDE task artifacts, isolated cloud-control events, isolated YARA matches, and actor naming are not treated as standalone confirmation of compromise.

Primary Threat Behaviors Covered

·        npm, pnpm, or yarn lifecycle execution involving preinstall, postinstall, setup.mjs, dependency-install, package-cache, workspace, release, package-publishing, or CI/CD execution context.

·        Adapted IDE or workspace-triggered runtime execution where developer tooling, workspace task behavior, project-controlled paths, VS Code, Cursor, .vscode, tasks.json, runOn, folderOpen, or socket.io-client context is followed by suspicious runtime, credential, staging, egress, GitHub, npm registry, identity, or downstream control-plane activity.

·        Bun or Node execution from dependency, package-cache, temporary, user-profile, developer workspace, IDE task, repository, CI workspace, actions-runner, or _work paths.

·        Suspicious runtime, shell, downloader, archive utility, Python, PowerShell, encoded-command, loader-style JavaScript, process-environment access, Linux runtime material access, or process-linked staging behavior following package-manager, developer-tool, or workspace execution context.

·        Access to developer, CI/CD, package-registry, repository, cloud, SSH, Kubernetes, Docker, npm, process-environment, or local credential material.

·        Local staging behavior involving environment files, cloud credential files, secret-like files, token-like files, JSON artifacts, compressed artifacts, encoded content, temporary staging paths, or suspicious package artifact material.

·        Suspicious outbound communication, callback behavior, API interaction, webhook use, repository-facing traffic, package-registry activity, raw-content access, cloud-storage access, paste-like service access, file-sharing access, blockchain-related service access, or external destination access following suspicious local execution.

·        GitHub activity involving repository creation, workflow modification, Actions secret modification, deploy-key creation, hook modification, OAuth authorization, personal-access-token use, or repository-control changes after local compromise indicators.

·        npm registry activity involving package publishing, token creation, token validation, token use, package-owner changes, maintainer changes, access changes, or metadata changes after local compromise indicators.

·        AWS downstream credential abuse involving IAM, STS, access-key, Secrets Manager, Systems Manager Parameter Store, ECR, CodeBuild, CodePipeline, Lambda, S3 artifact, KMS, identity, or deployment-path activity.

·        Azure downstream credential abuse involving Entra ID, app credential, service principal, managed identity, role assignment, Key Vault, registry, artifact, storage, or deployment-path activity.

·        GCP downstream credential abuse involving IAM, service account, service-account key, workload identity, Secret Manager, Artifact Registry, Cloud Build, Cloud Run, Cloud Functions, GKE, Cloud Storage, or deployment-path activity.

·        Artifact-level package content containing install-time execution logic, loader behavior, developer-secret targeting, staging strings, exfiltration context, or IDE/workspace task indicators requiring package, cache, repository, internal mirror, or build artifact review.

NDR / Network Behavioral Analytics Traceability

Rule

Suspicious Developer or CI/CD Egress Following Package or Workspace Execution Behavior

Mapped Threat Behavior

·        Suspicious outbound communication from developer endpoints, CI/CD runners, release systems, package-publishing systems, build systems, artifact systems, or cloud-connected developer environments following package execution, IDE workspace-triggered execution, credential-access indicators, local staging, or post-exposure token activity.

·        Outbound activity to newly observed domains, rare destinations, unusual ASNs, hosting-provider destinations, raw-content services, webhook services, cloud-storage services, paste-like services, file-sharing services, blockchain-related services, package repositories, GitHub API destinations, npm-related destinations, or uncategorized external destinations that are inconsistent with approved developer or build workflows.

·        Suspicious egress following npm lifecycle execution, setup.mjs activity, IDE-spawned runtime execution, .vscode/tasks.json or equivalent workspace task activity, runtime execution from dependency or workspace paths, credential access, local staging, GitHub token activity, npm token activity, cloud credential activity, or artifact-impact signals.

·        Network-visible behavior requiring correlation with endpoint, CI/CD, package-manager, IDE, file, GitHub, npm, cloud, identity, artifact, change-management, or incident-response evidence.

Coverage Role

This rule provides network-side behavioral coverage for suspicious developer or CI/CD egress following package or workspace execution context.

Coverage Boundary

This rule does not prove successful npm package execution, IDE workspace task execution, credential theft, exfiltration, cloud compromise, package-registry abuse, or actor attribution without supporting telemetry and investigation evidence. It should be used as suspicious egress coverage, enrichment, triage, and post-exposure scoping, not standalone compromise confirmation.

SentinelOne Traceability

Rule

npm Lifecycle Execution Spawning Suspicious Runtime or Shell Activity

Mapped Threat Behavior

·        npm, pnpm, or yarn lifecycle execution involving install-time or post-install activity.

·        Package-manager child process spawning Bun, Node, shell, PowerShell, downloader, archive utility, Python, or encoded-command execution.

·        Suspicious runtime, command execution, downloader behavior, archive utility behavior, or encoded-command behavior following package-install context.

·        Endpoint-visible activity consistent with npm package poisoning or Shai-Hulud-style developer credential theft behavior.

Coverage Role

This rule provides endpoint-side behavioral coverage for suspicious package-manager lifecycle execution and follow-on local runtime or shell activity.

Coverage Boundary

This rule does not identify a malicious package by name, prove credential theft, prove exfiltration, prove downstream GitHub or npm registry abuse, or attribute activity to a specific actor. Confirmation requires correlation with file, network, identity, registry, repository, cloud, CI/CD, package artifact, or incident-response evidence.

Rule

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

Mapped Threat Behavior

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

·        Credential-file access, process-environment discovery, Linux runtime material access, or local staging behavior tied to suspicious runtime execution.

·        Developer or CI/CD secret exposure involving npm, GitHub, SSH, cloud, Kubernetes, Docker, process-environment, or repository credential material.

·        Suspicious /proc/self/environ, /proc/self/maps, /proc/self/mem, printenv, process.env, or token-related command-line access from suspicious runtime context.

Coverage Role

This rule provides endpoint-side coverage for abnormal Bun or Node execution paired with credential-access, environment-access, Linux runtime material access, or local staging indicators.

Coverage Boundary

This rule requires strong process, file, command-line, host-role, user, runner, and path context. It does not confirm downstream token use, repository manipulation, package publishing, cloud abuse, or data exfiltration without supporting telemetry.

Rule

IDE Workspace Task or Developer Tool Execution Spawning Suspicious Runtime Activity

Mapped Threat Behavior

·        Adapted IDE or workspace-triggered runtime execution involving VS Code, Cursor, workspace task behavior, .vscode, tasks.json, runOn, folderOpen, socket.io-client, or project-controlled path context.

·        Suspicious runtime, shell, package-manager, downloader, archive, Python, PowerShell, or command-execution behavior launched from developer-tool or workspace context.

·        Workspace-driven execution followed by credential access, local staging, package-manager behavior, suspicious developer-service activity, or process-linked outbound activity.

·        Endpoint-visible behavior consistent with abuse of developer workflow trust boundaries.

Coverage Role

This rule provides endpoint-side behavioral coverage for adapted IDE/workspace-triggered execution patterns that may supplement or bypass traditional package-manager lifecycle visibility.

Coverage Boundary

This rule should not alert on IDE usage alone. It requires suspicious child-process behavior, workspace or repository path context, task-file context, credential indicators, staging indicators, downloader behavior, encoded-command behavior, or follow-on outbound activity.

Splunk Traceability

Rule

npm Lifecycle Execution Followed by Suspicious Runtime and Credential Access

Mapped Threat Behavior

·        npm, pnpm, or yarn lifecycle execution followed by suspicious runtime, shell, downloader, encoded-command, credential-access, or staging behavior.

·        Package-manager ancestry combined with suspicious child-process behavior or abnormal execution paths.

·        Developer endpoint, CI/CD runner, release system, or package-publishing system activity requiring SIEM-side correlation.

·        Local compromise indicators that may precede GitHub, npm registry, identity, cloud, or suspicious egress activity.

Coverage Role

This rule provides Splunk correlation coverage for suspicious npm lifecycle execution and follow-on local compromise behavior.

Coverage Boundary

This rule depends on local Splunk indexes, sourcetypes, field mapping, process telemetry, file telemetry, host-role mapping, macros, lookups, and exception handling. It should not alert on package-manager activity alone.

Rule

GitHub Workflow or Repository Abuse Following Local Compromise Signals

Mapped Threat Behavior

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

·        Repository creation, workflow creation, workflow modification, Actions secret modification, deploy-key creation, hook modification, OAuth authorization, or personal-access-token use after local compromise indicators.

·        Adapted IDE or workspace-triggered runtime execution followed by credential access, local staging, or suspicious developer-service activity.

·        Potential transition from local credential access to repository-control impact.

Coverage Role

This rule provides Splunk correlation coverage linking suspicious local execution, credential access, or staging behavior to downstream GitHub activity.

Coverage Boundary

This rule requires normalized GitHub audit telemetry, source IP, actor, user-agent, repository, token, runner, identity, and endpoint pivots. It should not treat ordinary repository administration or release automation as compromise without local compromise linkage.

Rule

npm Registry Publishing or Token Abuse Following Credential Exposure Signals

Mapped Threat Behavior

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

·        Potential use of stolen npm tokens or compromised maintainer credentials.

·        Adapted IDE or workspace-triggered execution followed by npm token exposure, package-publishing activity, or suspicious registry-related behavior.

·        Suspicious transition from developer or CI/CD compromise to package-registry abuse.

Coverage Role

This rule provides Splunk correlation coverage for linking local credential-exposure indicators to downstream npm registry activity.

Coverage Boundary

This rule requires npm registry telemetry, package context, maintainer context, token context, source IP, user-agent, identity mapping, and local compromise pivots. It should not treat ordinary publishing, ownership changes, or automation as compromise without supporting evidence.

Elastic Traceability

Rule

npm Lifecycle Execution Followed by Suspicious Runtime or Shell Execution

Mapped Threat Behavior

·        Package-manager lifecycle execution followed by suspicious runtime, shell, downloader, archive utility, encoded-command, package-cache, dependency-path, or CI workspace behavior.

·        Suspicious transition from dependency installation to attacker-controlled local execution.

·        Endpoint process activity requiring ECS or local-schema mapping.

·        Developer endpoint, package-publishing, release, or CI/CD execution context.

Coverage Role

This rule provides Elastic endpoint-rule coverage for suspicious npm lifecycle execution followed by local runtime or shell behavior.

Coverage Boundary

This rule depends on Elastic data views, ECS mapping, endpoint telemetry, process ancestry, command-line capture, host-role enrichment, exception lists, and environment-specific tuning. It should not alert on npm, pnpm, or yarn activity alone.

Rule

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

Mapped Threat Behavior

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

·        Process-linked credential-file access, process-environment access, Linux runtime material access, or local staging behavior.

·        Developer or CI/CD secret targeting associated with suspicious package or workspace execution.

·        Runtime behavior requiring process.entity_id or equivalent process GUID linkage to file activity.

Coverage Role

This rule provides Elastic EQL sequence coverage for suspicious runtime execution followed by credential-access, process-environment, Linux runtime material, or staging behavior tied to the same process entity.

Coverage Boundary

This rule is conditional because production precision depends on reliable process-to-file linkage. Where file events lack process.entity_id or equivalent process context, it should remain a hunt or be backed by transform or SIEM correlation.

Rule

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

Mapped Threat Behavior

·        Local developer or CI/CD compromise indicators followed by GitHub, npm registry, identity, AWS, Azure, or GCP activity.

·        Sensitive downstream actions involving repository control, package publishing, token use, identity changes, secrets access, service-account activity, build activity, artifact activity, or control-plane impact.

·        Adapted IDE or workspace-triggered runtime execution followed by downstream developer-service or cloud activity.

·        Multi-source sequencing across endpoint, file, GitHub, npm registry, identity, cloud, and CI/CD telemetry.

Coverage Role

This rule provides Elastic correlation-template coverage for linking local compromise signals to sensitive downstream SaaS, package-registry, identity, or cloud-control-plane activity.

Coverage Boundary

This rule requires source-specific mapping before production deployment. It should not treat cloud-only, GitHub-only, npm-only, or identity-only events as package compromise without local compromise linkage and validated pivots.

QRadar Traceability

Rule

npm Lifecycle Execution with Suspicious Runtime or Credential Access Indicators

Mapped Threat Behavior

·        npm, pnpm, or yarn lifecycle execution followed by suspicious runtime, shell, downloader, archive utility, Python, encoded-command, credential-access, or local-staging behavior.

·        Package-manager ancestry and suspicious follow-on behavior on the same host and user.

·        Developer endpoint, release system, package-publishing system, or CI/CD runner activity.

·        Local compromise behavior requiring CRE correlation rather than single-event alerting.

Coverage Role

This rule provides QRadar CRE coverage for suspicious package-manager lifecycle behavior and local follow-on activity.

Coverage Boundary

This rule requires DSM parsing, custom properties, user identity, host identity, asset role, CI/CD runner context, and CRE sequence validation. Broad AQL matching should remain hunt logic until CRE conditions are validated.

Rule

Sensitive GitHub, npm, or Cloud Activity Following Local Compromise Signals

Mapped Threat Behavior

·        Local developer or CI/CD compromise signal followed by sensitive GitHub, npm registry, identity, or cloud activity.

·        Adapted IDE or workspace-triggered runtime execution followed by credential access, local staging, suspicious egress, repository activity, package-registry activity, identity activity, or cloud-control-plane activity.

·        Two-stage downstream impact behavior requiring validated pivots between local compromise signals and sensitive downstream actions.

·        Potential transition from local credential exposure to token, repository, package, identity, or cloud abuse.

Coverage Role

This rule provides QRadar CRE correlation coverage for linking local compromise signals to sensitive downstream developer-service, package-registry, identity, or cloud activity.

Coverage Boundary

This rule requires normalized endpoint, GitHub, npm, cloud, identity, and CI/CD events. It should only generate an offense when Stage 1 and Stage 2 both occur and share a validated pivot.

SIGMA Traceability

Rule

Suspicious npm Lifecycle Execution Spawning Runtime, Shell, or Downloader

Mapped Threat Behavior

·        npm, pnpm, or yarn lifecycle execution spawning suspicious runtime, shell, downloader, archive utility, Python, or encoded-command behavior.

·        Portable endpoint process behavior associated with install-time package execution.

·        Package-manager ancestry plus suspicious child-process execution.

·        Event-level behavior requiring backend conversion and enrichment.

Coverage Role

This rule provides portable SIGMA event-template coverage for suspicious package-manager lifecycle execution and child-process behavior.

Coverage Boundary

This rule does not perform multi-source correlation by itself. Backend SIEM conversion, local field mapping, enrichment, exception handling, and SIEM-native correlation are required.

Rule

Bun or Node Execution from Dependency, Cache, Temporary, or CI Workspace Path

Mapped Threat Behavior

·        Bun or Node execution from dependency, package-cache, temporary, user-profile, developer workspace, CI workspace, actions-runner, or _work paths.

·        Runtime behavior that may indicate malicious dependency payload execution.

·        Suspicious execution from dependency, cache, temporary, or CI paths where runtime execution is inconsistent with approved developer or build workflows.

·        Endpoint process behavior requiring backend mapping and baselining.

Coverage Role

This rule provides portable SIGMA event-template coverage for suspicious Bun or Node execution from dependency, cache, temporary, user-profile, or CI workspace paths.

Coverage Boundary

This rule requires backend-specific conversion, field mapping, asset role context, approved runtime baselines, and tuning for legitimate developer and build workflows. It does not perform downstream GitHub, npm registry, cloud, or identity correlation by itself.

Rule

Credential File Access or Local Secret Staging by Package-Manager Descended Runtime

Mapped Threat Behavior

·        Access to developer, package-registry, cloud, repository, SSH, Kubernetes, Docker, or CI/CD credential material.

·        Local secret staging by package-manager-descended runtime, shell, Python, or suspicious process context.

·        Workspace or task context supporting credential-access investigation.

·        Process-linked file behavior requiring file telemetry with process context.

Coverage Role

This rule provides portable SIGMA file-event template coverage for credential-file access or local secret staging tied to suspicious runtime or package-manager context.

Coverage Boundary

This rule is conditional. It should not be enabled as production detection unless file events include reliable process context. Where process linkage is unavailable, it should remain a hunt or be correlated with recent process events in the backend SIEM.

YARA Traceability

Rule

Suspicious npm Package Loader with Developer Secret Targeting Indicators

Mapped Threat Behavior

·        Extracted npm package artifacts containing install-time lifecycle context, loader-style JavaScript behavior, runtime bootstrap behavior, developer-secret targeting strings, staging indicators, workspace-task indicators, or stronger exfiltration context.

·        Suspicious package, dependency-cache, CI/CD workspace, internal mirror, repository, build artifact, or quarantined file content requiring artifact triage.

·        Artifact-level indicators involving setup.mjs, preinstall, postinstall, child_process, execSync, spawnSync, Buffer.from, process.env, credential strings, token strings, or workspace-task strings.

·        Static content that may support exposure review, package-cache review, internal mirror review, malware triage, or retrospective investigation.

Coverage Role

This rule provides supplemental artifact-scanning coverage for suspicious npm package contents and related developer-secret targeting indicators.

Coverage Boundary

This rule does not prove execution, credential theft, token theft, exfiltration, registry abuse, repository compromise, cloud compromise, or actor attribution by itself. YARA matches require package review, file-path context, endpoint telemetry, CI/CD telemetry, GitHub telemetry, npm registry telemetry, network telemetry, identity telemetry, and analyst validation.

AWS Traceability

Rule

Developer or CI/CD Identity Performs Sensitive IAM or Access-Key Activity

Mapped Threat Behavior

·        Sensitive AWS IAM, STS, access-key, role, policy, or privilege-modification activity by developer, CI/CD, package-publishing, build, release, automation, or deployment identities.

·        Downstream cloud-control-plane activity that may follow developer, CI/CD, package-publishing, or deployment credential exposure.

·        Role assumption, access-key creation, policy modification, privilege expansion, persistence setup, or sensitive identity activity requiring upstream local compromise linkage.

·        Activity from identities connected to developer workflows, CI/CD pipelines, package publishing, release systems, or deployment automation.

Coverage Role

This rule provides AWS-native downstream identity and access-management coverage for suspected credential misuse after local developer or CI/CD compromise indicators.

Coverage Boundary

This rule does not detect initial npm package execution, IDE workspace execution, local credential access, or endpoint staging. AWS-only events must not be attributed to npm package compromise without upstream local compromise, identity, CI/CD, artifact, source, change-management, or incident-response evidence.

Rule

Developer or CI/CD Identity Accesses Secrets, Artifacts, Registry, or Build Services from Suspicious Context

Mapped Threat Behavior

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

·        Downstream access to secrets, artifacts, registries, build services, encryption services, deployment services, or release-path resources after suspected credential exposure.

·        Conditional service-access behavior requiring 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.

·        Cloud activity requiring upstream local compromise or exposure linkage before attribution to this threat model.

Coverage Role

This rule provides conditional AWS service-access, secret-access, artifact, registry, build, KMS, storage, and deployment-path coverage when identity, source, account, resource, user-agent, release-process, and exposure baselines are available.

Coverage Boundary

This rule is conditional because legitimate CI/CD and release automation may access the same services. It should not be treated as proof of npm package compromise without upstream local compromise linkage and validated suspicious context.

Azure Traceability

Rule

Developer or CI/CD Identity Performs Sensitive Entra ID, App Credential, or Role Assignment Activity

Mapped Threat Behavior

·        Sensitive Microsoft Entra ID, app credential, service principal, managed identity, role assignment, role definition, delegated permission, application consent, group membership, role membership, or privilege-related activity by mapped developer, CI/CD, package-publishing, build, release, automation, or deployment identities.

·        Downstream identity-control-plane behavior that may follow developer, CI/CD, package-publishing, or deployment credential exposure.

·        App credential modification, service principal activity, managed identity activity, role-assignment activity, or privilege modification requiring upstream local compromise linkage.

·        Azure activity connected to developer, CI/CD, package-publishing, build, release, automation, or deployment workflows.

Coverage Role

This rule provides Azure-native downstream identity and privilege-change coverage for suspected credential misuse after local developer or CI/CD compromise indicators.

Coverage Boundary

This rule does not detect initial npm package execution, IDE workspace execution, local credential access, or endpoint staging. Azure-only events must not be attributed to npm package compromise without upstream local compromise, identity, CI/CD, artifact, source, change-management, or incident-response evidence.

Rule

Developer or CI/CD Identity Accesses Key Vault, Registry, Artifact, or Deployment Services from Suspicious Context

Mapped Threat Behavior

·        Suspicious access to Azure Key Vault, Azure Container Registry, artifact locations, managed identity resources, deployment services, storage, or release-path resources from mapped developer, CI/CD, package-publishing, build, release, automation, or deployment identities.

·        Downstream access to secrets, registry artifacts, build or deployment paths, managed identity resources, or storage resources after suspected credential exposure.

·        Conditional service-access behavior requiring suspicious source, identity, tenant, subscription, resource, user-agent, Conditional Access, release-window, or exposure context.

·        Azure service activity requiring upstream local compromise or exposure linkage before attribution to this threat model.

Coverage Role

This rule provides conditional Azure service-access, secret-access, registry, artifact, managed identity, storage, and deployment-path coverage when validated customer context and watchlists are available.

Coverage Boundary

This rule is conditional because legitimate CI/CD and release automation may perform similar actions. It should not be treated as proof of npm package compromise without upstream local compromise linkage and validated suspicious context.

GCP Traceability

Rule

Developer or CI/CD Identity Performs Sensitive IAM or Service Account Activity

Mapped Threat Behavior

·        Sensitive GCP IAM, service account, service-account key, workload identity, IAM policy, impersonation, or privilege-related activity by mapped developer, CI/CD, package-publishing, build, release, automation, or deployment identities.

·        Downstream cloud-control-plane behavior that may follow developer, CI/CD, package-publishing, or deployment credential exposure.

·        IAM policy changes, service-account key creation, service-account impersonation, workload identity changes, or sensitive GCP identity activity requiring upstream local compromise linkage.

·        GCP identity activity connected to developer, CI/CD, package-publishing, build, release, automation, or deployment workflows.

Coverage Role

This rule provides GCP-native downstream IAM and service-account coverage for suspected credential misuse after local developer or CI/CD compromise indicators.

Coverage Boundary

This rule does not detect initial npm package execution, IDE workspace execution, local credential access, or endpoint staging. GCP-only events must not be attributed to npm package compromise without upstream local compromise, identity, CI/CD, artifact, source, change-management, or incident-response evidence.

Rule

Developer or CI/CD Identity Accesses Secrets, Artifacts, Build, or Deployment Services from Suspicious Context

Mapped Threat Behavior

·        Suspicious access to GCP Secret Manager, Artifact Registry, Cloud Build, Cloud Run, Cloud Functions, GKE, Cloud Storage, or deployment services by mapped developer, CI/CD, package-publishing, build, release, automation, or deployment identities.

·        Downstream access to secrets, artifacts, build services, deployment services, storage, or release-path resources after suspected credential exposure.

·        Conditional service-access behavior requiring suspicious source, identity, project, folder, organization, resource, user-agent, method name, release-process, or exposure context.

·        GCP service activity requiring upstream local compromise or exposure linkage before attribution to this threat model.

Coverage Role

This rule provides conditional GCP secret-access, artifact, build, storage, and deployment-path coverage when Cloud Logging, SIEM, Security Command Center, or equivalent enrichment with validated customer context is available.

Coverage Boundary

This rule is conditional because legitimate CI/CD and release automation may perform similar actions. It should not be treated as proof of npm package compromise without upstream local compromise linkage and validated suspicious context.

Coverage Consolidation

The S25 rule inventory provides direct or conditional traceability across network, endpoint, SIEM, event-template, artifact-scanning, developer-service, package-registry, identity, and cloud-control-plane telemetry. The strongest direct coverage appears in SentinelOne, Splunk, Elastic, QRadar, SIGMA, AWS Rule 1, Azure Rule 1, and GCP Rule 1 where endpoint, CI/CD, registry, repository, identity, or cloud audit telemetry is available.

NDR provides network behavioral analytics and enrichment for suspicious egress following package or workspace execution context. YARA provides supplemental artifact triage for suspicious package contents, internal npm mirror review, dependency-cache scanning, repository inspection, build artifact review, and retrospective exposure analysis.

AWS Rule 2, Azure Rule 2, GCP Rule 2, Elastic Rule 2, and SIGMA Rule 3 remain conditional because they require validated telemetry linkage, customer-specific baselines, watchlists, process-linked file events, cloud data or diagnostic logs, SIEM enrichment, or suspicious-context validation before production alerting.

Cloud-native AWS, Azure, and GCP coverage is downstream-only. These systems do not provide direct visibility into npm lifecycle execution, IDE workspace task execution, local credential-file access, or endpoint staging. Cloud-only events are not treated as evidence of npm package compromise without upstream local compromise, identity, CI/CD, artifact, source, change-management, or incident-response linkage.

Non-Coverage Conditions

·        Managed developer platforms, hosted CI/CD runners, third-party package infrastructure, or SaaS-only environments without endpoint, process, file, artifact, registry, repository, identity, cloud, proxy, DNS, NDR, or audit telemetry may have limited detection coverage.

·        Package names, dependency exposure, scanner output, repository presence, package-cache presence, or package-install activity are not treated as compromise confirmation by themselves.

·        IDE usage, VS Code activity, Cursor activity, .vscode content, tasks.json content, runOn, folderOpen, or socket.io-client indicators are not treated as compromise confirmation without suspicious runtime, credential, staging, egress, repository, registry, identity, or cloud activity.

·        NDR-visible egress, rare destination access, GitHub API access, npm registry access, cloud-storage access, raw-content access, webhook access, DNS novelty, TLS novelty, upload volume, or unusual ASN context is not treated as compromise evidence by itself.

·        Cloud-only identity, secrets, storage, build, artifact, registry, service-account, role, policy, KMS, deployment, or control-plane events are not treated as npm package compromise without upstream local compromise linkage.

·        YARA artifact matches are not treated as active execution, credential theft, token theft, registry abuse, repository compromise, cloud compromise, or exfiltration without supporting telemetry and analyst validation.

·        The rule set does not attribute activity to a specific actor, campaign, exploit kit, malware family, package maintainer, developer account, repository owner, or package publisher without external evidence.

·        The rule set does not prove credential theft, token theft, successful exfiltration, GitHub compromise, npm registry compromise, durable persistence, downstream cloud compromise, or successful package execution without supporting telemetry and investigation evidence.

System Traceability Summary

NDR / Network Behavioral Analytics

·        1 behavioral analytics rule.

·        Covers suspicious developer or CI/CD egress following package or workspace execution context.

·        Provides network-side enrichment, suspicious egress detection, developer-service misuse review, rare destination analysis, post-exposure scoping, and SIEM correlation.

·        Does not provide standalone confirmation of malicious package execution, workspace-task execution, credential theft, exfiltration, or downstream compromise.

SentinelOne

·        3 production rules.

·        Covers npm lifecycle execution, suspicious runtime behavior, credential access, local staging, process-environment access, Linux runtime material access, and adapted IDE/workspace-triggered execution.

·        Provides the strongest endpoint-native coverage where developer endpoints, release systems, package-publishing systems, and self-hosted CI/CD runners are instrumented.

Splunk

·        3 production rules.

·        Covers endpoint execution chains, GitHub downstream abuse, and npm registry abuse through sequence-based correlation.

·        Requires local field mapping, CIM or local sourcetype validation, host and user normalization, and validated correlation pivots.

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 using CRE implementation.

·        Covers local compromise and downstream GitHub, npm, identity, or cloud activity through AQL hunt logic and CRE correlation.

·        Requires validated DSM parsing, custom properties, reference data, building blocks, and CRE pivots before production offense generation.

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.

·        Does not provide native SaaS, registry, identity, or cloud correlation by itself.

YARA

·        1 supplemental artifact rule.

·        Supports package artifact triage, internal npm mirror review, dependency-cache scanning, repository inspection, build artifact review, and malware sample analysis.

·        Does not prove execution, credential theft, exfiltration, registry abuse, repository compromise, cloud compromise, or downstream abuse.

AWS

·        1 production rule.

·        1 conditional production rule.

·        Covers downstream AWS IAM, STS, access-key, Secrets Manager, Systems Manager Parameter Store, ECR, CodeBuild, CodePipeline, Lambda, S3 artifact, KMS, and deployment abuse.

·        Does not detect the initial npm package execution path.

Azure

·        1 production rule.

·        1 conditional production rule.

·        Covers downstream Entra ID, app credential, service principal, managed identity, role assignment, Key Vault, registry, artifact, storage, and deployment abuse.

·        Does not detect the initial npm package execution path.

GCP

·        1 production rule.

·        1 conditional production rule.

·        Covers downstream GCP IAM, service-account, service-account-key, Secret Manager, Artifact Registry, Cloud Build, Cloud Run, Cloud Functions, GKE, Cloud Storage, and deployment abuse.

·        Does not detect the initial npm package execution path.

Traceability Conclusion

The finalized S25 rule inventory provides broad, behavior-led coverage for SAP-related npm package poisoning and Shai-Hulud-style developer credential theft behavior. The rules trace suspicious package-manager lifecycle execution, adapted IDE or workspace-triggered execution, abnormal Bun or Node activity, credential access, local secret staging, suspicious egress, GitHub activity, npm registry activity, downstream cloud activity, and artifact-level package triage to the appropriate telemetry sources.

The traceability model preserves a strict distinction between exposure, suspicious package activity, local execution, credential-access behavior, downstream developer-service activity, conditional cloud-impact behavior, artifact-level indicators, and confirmed compromise.

S27 — Behavior and Log Artifacts

Artifact Objective

This section identifies the behavior and log artifacts required to support the finalized S25 detection rule inventory and S26 traceability mapping. The objective is to define the observable evidence defenders should collect, correlate, and preserve when investigating SAP-related npm package poisoning, Shai-Hulud-style developer credential theft, and related developer supply-chain execution paths.

S27 does not treat package presence, artifact matches, suspicious egress, cloud activity, GitHub activity, npm activity, IDE task-file presence, or cloud audit activity as standalone proof of compromise. These artifacts support exposure scoping, detection validation, triage, enrichment, and investigation. Confirmation requires correlation across endpoint execution telemetry, CI/CD telemetry, credential-access evidence, GitHub audit activity, npm registry activity, cloud audit logs, network telemetry, artifact review, and incident-response findings.

Primary Behavior Artifact Categories

Package-Manager Execution Artifacts

·        npm, pnpm, or yarn execution on developer endpoints, release systems, package-publishing systems, build systems, or self-hosted CI/CD runners.

·        Lifecycle-script execution associated with preinstall, postinstall, setup scripts, package-cache paths, dependency paths, workspace paths, or CI/CD working directories.

·        Parent-child process chains where a package manager launches Bun, Node, shell, PowerShell, Python, curl, wget, 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 paths, _work paths, build directories, or dependency extraction locations.

·        Package-install activity followed by credential-path access, environment-variable enumeration, local staging, suspicious egress, GitHub activity, npm activity, or downstream cloud activity.

Relevant Log Sources

·        Endpoint process creation telemetry.

·        EDR process lineage.

·        CI/CD runner telemetry.

·        Build job logs.

·        Package-manager logs where available.

·        Package-install command history where retained.

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

·        Provides the primary artifact set for distinguishing package exposure from active install-time execution.

Runtime and Loader Artifacts

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

·        JavaScript loader behavior involving setup.mjs, file-system access, process execution, encoded payload handling, runtime bootstrap logic, downloader behavior, or local staging.

·        Command lines referencing setup.mjs, node_modules, .npm, .pnpm, preinstall, postinstall, curl, wget, base64, encoded command flags, archive utilities, or executable permission changes.

·        Runtime execution launched by package-manager-descended processes.

·        Runtime activity followed by credential discovery, environment-variable enumeration, local file staging, outbound network activity, GitHub API activity, npm registry activity, or cloud-control-plane activity.

·        First-seen or abnormal Bun activity on developer endpoints, build systems, release systems, package-publishing systems, or self-hosted CI/CD runners where Bun is not approved.

Relevant Log Sources

·        Endpoint process telemetry.

·        EDR Deep Visibility or equivalent event search.

·        Elastic endpoint events.

·        SIEM process logs.

·        CI/CD runner logs.

·        Build job logs.

·        Artifact and package-cache inspection.

·        Runtime inventory or software inventory where available.

Detection Relevance

·        Supports SentinelOne Rule 1 and SentinelOne Rule 2.

·        Supports Splunk Rule 1.

·        Supports Elastic Rule 1 and Elastic Rule 2.

·        Supports QRadar Rule 1.

·        Supports SIGMA Rule 1 and SIGMA Rule 2.

·        Provides the primary artifact set for identifying suspicious runtime bootstrap behavior after package installation or dependency restoration.

IDE Workspace Task Artifacts

·        VS Code, Cursor, or related developer tool parent processes spawning Node, npm, Bun, Python, shell, PowerShell, curl, wget, archive utilities, command interpreters, package managers, or runtime activity from project-controlled paths.

·        Repository-local task configuration involving .vscode/tasks.json or equivalent IDE task files.

·        Task definitions using runOn, folderOpen, hidden presentation behavior, unexpected shell commands, downloader invocation, encoded command behavior, or project-controlled runtime launch paths.

·        IDE-launched runtime activity from newly opened, cloned, extracted, dependency-derived, or recently trusted workspaces.

·        IDE-spawned runtime activity followed by credential-path access, environment-variable access, local staging, suspicious egress, GitHub activity, npm activity, or cloud-control-plane activity.

Relevant Log Sources

·        Endpoint process telemetry.

·        EDR process lineage.

·        Developer endpoint telemetry.

·        IDE process telemetry where available.

·        File telemetry for workspace task files.

·        Repository snapshots.

·        CI/CD workspace telemetry where applicable.

·        SIEM-normalized endpoint telemetry.

Detection Relevance

·        Supports SentinelOne Rule 3.

·        Supports Elastic Rule 2 where endpoint telemetry captures parent-child process lineage and working-directory context.

·        Supports QRadar Rule 1 when endpoint telemetry is normalized into QRadar with validated custom properties.

·        Supports SIGMA Rule 3 where backend telemetry supports IDE parent-child process mapping.

·        Represents Coverage With Adaptation, not direct proof of SAP npm lifecycle execution.

Credential Access and Local Staging Artifacts

·        Access to .npmrc, npm tokens, GitHub token material, Git credential stores, SSH keys, cloud credential files, Kubernetes configuration, Docker configuration, environment files, CI/CD secret material, package-registry credentials, deployment credentials, or repository configuration files.

·        Access to /proc/self/environ, process.env, printenv, env, or similar runtime environment sources from suspicious package-manager, Bun, Node, shell, Python, PowerShell, IDE child, or CI/CD runner context.

·        File discovery across home directories, repository roots, package caches, CI/CD workspaces, build directories, release directories, and credential storage paths after suspicious package execution or IDE-spawned runtime activity.

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

·        Local staging followed by outbound network activity, GitHub activity, npm registry activity, cloud-control-plane activity, package publication, or repository modification.

Relevant Log Sources

·        Endpoint file-access telemetry.

·        EDR sensitive-file access events.

·        Endpoint process telemetry.

·        Command-line telemetry.

·        CI/CD runner telemetry.

·        CI/CD job logs.

·        File creation, modification, rename, and deletion events.

·        SIEM-normalized endpoint and CI/CD telemetry.

·        Identity and secrets telemetry where available.

Detection Relevance

·        Supports SentinelOne Rule 2.

·        Supports Splunk Rule 1.

·        Supports Elastic Rule 2.

·        Supports QRadar Rule 1.

·        Supports SIGMA Rule 2.

·        Supports SIGMA Rule 3 when credential access follows IDE-spawned runtime activity.

·        Provides the highest-value artifact set for determining whether local execution created credential-risk exposure.

·        Does not prove credential theft unless correlated with staging, exfiltration, token validation, platform activity, or incident-response evidence.

GitHub and Source-Code Platform Artifacts

·        GitHub repository creation, repository visibility changes, repository metadata changes, branch changes, release activity, workflow creation, workflow modification, deploy-key changes, webhook changes, OAuth activity, GitHub App activity, token activity, or unusual API use after suspicious package or IDE execution.

·        New or modified .github/workflows content outside approved release or change-management windows.

·        Workflow logic attempting to access broad secrets, dump environment variables, publish packages, call external endpoints, upload artifacts, or alter release paths.

·        GitHub API activity from developer endpoints, build containers, CI/CD runners, package-publishing systems, or automation identities outside expected release patterns.

·        Token use from new systems, source IPs, user agents, geographies, autonomous systems, automation contexts, or identities with prior exposure indicators.

Relevant Log Sources

·        GitHub Enterprise audit logs.

·        GitHub organization audit logs.

·        Repository event history.

·        Workflow run logs.

·        Workflow file history.

·        GitHub App and OAuth logs.

·        Deploy-key and webhook audit events.

·        Identity provider logs.

·        SIEM source-code platform telemetry.

Detection Relevance

·        Supports Splunk Rule 2.

·        Supports Elastic Rule 3 when GitHub telemetry is normalized and correlated with endpoint, CI/CD, identity, npm, cloud, and network pivots.

·        Supports QRadar Rule 2 when DSM parsing, custom properties, reference sets, and CRE pivots are validated.

·        Supports downstream investigation of credential reuse, workflow abuse, repository manipulation, and propagation risk.

·        Does not prove initial npm package execution without supporting endpoint, CI/CD, package-manager, or artifact evidence.

npm Registry and Package-Publishing Artifacts

·        npm token validation, token use, token creation, token revocation, package publication, package version changes, maintainer changes, ownership changes, access changes, provenance changes, package metadata changes, or lifecycle-script changes after suspicious local execution or credential-access activity.

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

·        New package versions created outside expected release windows or without approved change context.

·        Registry activity following suspicious package installation, credential access, GitHub workflow modification, local staging, or unusual outbound network activity.

·        Internal package mirror, dependency-cache, or artifact-repository activity showing retained or redistributed affected package material.

Relevant Log Sources

·        npm organization logs.

·        npm package audit history.

·        npm token logs where available.

·        Package publication records.

·        Package metadata and maintainer history.

·        Internal npm mirror logs.

·        Artifact repository logs.

·        CI/CD release logs.

·        SIEM registry telemetry.

Detection Relevance

·        Supports Splunk Rule 3.

·        Supports Elastic Rule 3 when npm telemetry is normalized and correlated with endpoint, CI/CD, GitHub, identity, cloud, and network pivots.

·        Supports QRadar Rule 2 when npm telemetry is parsed and mapped into validated reference data and CRE correlation.

·        Supports detection of downstream package-registry abuse after suspected credential exposure.

·        Does not prove credential theft, registry compromise, or package propagation without supporting identity, endpoint, CI/CD, source-code, and incident-response evidence.

Suspicious Egress and Network Artifacts

·        Outbound communication from developer endpoints, CI/CD runners, release systems, package-publishing systems, build systems, artifact systems, or cloud-connected developer environments following package execution, IDE workspace-triggered execution, credential-access indicators, local staging, or post-exposure token activity.

·        DNS, proxy, TLS, firewall, NetFlow, or EDR network events involving newly observed domains, rare destinations, unusual autonomous systems, hosting-provider destinations, raw-content services, webhook services, cloud-storage services, paste-like services, file-sharing services, blockchain-related services, package repositories, GitHub API destinations, npm-related destinations, or uncategorized external destinations.

·        Upload-like traffic from npm, Node, Bun, shell, PowerShell, Python, curl, wget, IDE child processes, package-manager-descended processes, CI runner processes, or loader-related processes.

·        Network activity temporally linked to setup.mjs activity, npm lifecycle execution, IDE-spawned runtime execution, workspace task activity, runtime execution from dependency or workspace paths, credential access, local staging, GitHub token activity, npm token activity, cloud credential activity, or artifact-impact signals.

Relevant Log Sources

·        DNS logs.

·        Proxy logs.

·        Firewall logs.

·        Secure web gateway logs.

·        TLS metadata.

·        NetFlow or equivalent flow telemetry.

·        EDR network telemetry.

·        CI/CD egress telemetry.

·        Cloud egress telemetry.

·        NDR / Network Behavioral Analytics telemetry.

·        SIEM-normalized network telemetry.

Detection Relevance

·        Supports NDR / Network Behavioral Analytics suspicious egress detection where deployed.

·        Supports Splunk, Elastic, and QRadar correlation when network telemetry is normalized with endpoint, CI/CD, identity, GitHub, npm, cloud, and artifact pivots.

·        Supports enrichment, scoping, exfiltration triage, rare destination analysis, and post-exposure investigation.

·        Does not prove npm lifecycle execution, IDE workspace task execution, credential theft, exfiltration, registry abuse, repository compromise, cloud compromise, downstream compromise, or actor attribution without supporting telemetry.

·        Should not generate high-confidence findings from GitHub access alone, npm registry access alone, cloud storage access alone, webhook access alone, raw-content access alone, isolated DNS requests alone, isolated TLS anomalies alone, isolated rare destination access alone, or ordinary developer egress alone.

AWS Cloud Artifacts

·        IAM user, role, policy, access-key, STS, privilege-modification, or role-assumption 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, deployment, storage, registry, or build 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, deployment, or privilege actions after suspected developer or CI/CD exposure.

·        AWS activity from identities, access keys, source IPs, user agents, or automation contexts tied to exposed systems or suspicious package-execution timelines.

Relevant Log Sources

·        AWS CloudTrail management events.

·        AWS CloudTrail data events where enabled.

·        IAM logs.

·        STS events.

·        Secrets Manager events.

·        SSM Parameter Store events.

·        ECR logs.

·        CodeBuild logs.

·        CodePipeline logs.

·        Lambda logs.

·        S3 data events where enabled.

·        KMS logs.

·        SIEM cloud telemetry.

Detection Relevance

·        Supports AWS Rule 1.

·        Supports AWS Rule 2 when identity, source, account, resource, user-agent, release-process, and deployment-context baselines are validated.

·        Supports Elastic Rule 3 and QRadar Rule 2 only when AWS telemetry is ingested, normalized, and correlated with validated pivots.

·        Provides downstream AWS credential-abuse coverage only.

·        Does not detect the initial npm package execution path.

Azure Cloud Artifacts

·        Microsoft Entra ID app credential changes, service principal updates, managed identity activity, role assignments, delegated permission grants, application consent, group or role membership changes, Conditional Access deviations, or Azure Resource Manager privilege actions.

·        Key Vault, Azure Container Registry, storage artifact, managed identity, build, deployment, release, registry, or artifact 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 after suspected package-execution exposure.

·        Azure activity from identities, tokens, service principals, managed identities, source IPs, user agents, or automation contexts tied to exposed systems or suspicious developer workflow timelines.

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.

·        Conditional Access logs.

·        Microsoft Sentinel watchlists.

·        SIEM cloud telemetry.

Detection Relevance

·        Supports Azure Rule 1.

·        Supports Azure Rule 2 when identity, source, resource, tenant, subscription, Conditional Access, release-process, and deployment-context baselines are validated.

·        Supports Elastic Rule 3 and QRadar Rule 2 only when Azure telemetry is ingested, normalized, and correlated with validated pivots.

·        Provides downstream Azure credential-abuse coverage only.

·        Does not detect the initial npm package execution path.

GCP Cloud Artifacts

·        IAM policy modification, service-account creation or update, service-account-key creation or deletion, workload identity changes, sensitive GCP identity activity, or privilege changes involving mapped developer, CI/CD, package-publishing, build, release, automation, or deployment identities.

·        Secret Manager, Artifact Registry, Cloud Build, Cloud Run, Cloud Functions, GKE, Cloud Storage, deployment, registry, or artifact 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, region, and release-context artifacts.

·        GCP activity from principals, service accounts, source IPs, user agents, or automation contexts tied to exposed systems or suspicious package-execution timelines.

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 audit logs.

·        Cloud Functions audit logs.

·        GKE audit logs where available.

·        Cloud Storage data access logs where enabled.

·        Security Command Center enrichment sources.

·        SIEM cloud telemetry.

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.

·        Provides downstream GCP credential-abuse coverage only.

·        Does not detect the initial npm package execution path.

Artifact Triage and Dependency-Cache Artifacts

·        Extracted npm package contents showing suspicious lifecycle-script logic, loader-style JavaScript, runtime bootstrap indicators, developer-secret targeting strings, staging indicators, or exfiltration-adjacent strings.

·        Package tarballs from npm cache, internal npm mirrors, artifact repositories, dependency caches, CI/CD workspaces, build artifacts, repository snapshots, quarantined endpoint files, or malware triage samples.

·        package.json, package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, yarn.lock, SBOM records, container layers, build images, internal mirrors, dependency caches, and release artifacts showing affected package versions or suspicious package material.

·        Historical staging names, suspicious strings, loader names, and package artifacts used as lineage context, not mandatory proof of current-campaign execution.

·        Artifact matches requiring correlation with endpoint execution, CI/CD telemetry, GitHub activity, npm registry activity, cloud activity, identity telemetry, network telemetry, and incident-response evidence.

Relevant Log Sources 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.

·        Artifact repository records.

·        Container registry metadata.

·        SBOM and provenance records.

Detection Relevance

·        Supports YARA Rule 1.

·        Supports package artifact triage, internal npm mirror review, dependency-cache scanning, repository inspection, build artifact review, malware sample analysis, and retrospective exposure review.

·        Does not prove execution, credential theft, exfiltration, registry abuse, repository compromise, cloud compromise, downstream compromise, or attribution.

·        Should trigger package review, dependency exposure analysis, endpoint and CI/CD telemetry review, secret rotation assessment, and GitHub, npm, cloud, identity, and network activity review.

Artifact Reliability Considerations

·        Package presence in dependency files, lockfiles, caches, mirrors, SBOMs, containers, or artifacts identifies exposure scope, not confirmed execution.

·        npm lifecycle execution, setup.mjs execution, Bun execution, IDE-launched runtime activity, credential access, local staging, suspicious egress, GitHub activity, npm activity, and cloud activity must be interpreted as a sequence rather than isolated findings.

·        Cloud rules are downstream-only and do not detect initial npm package execution, IDE workspace execution, package-manager lifecycle behavior, setup.mjs activity, Bun runtime launch, or local credential access.

·        YARA is supplemental artifact triage and should not be used as a standalone compromise declaration.

·        NDR / Network Behavioral Analytics supports suspicious egress detection, enrichment, triage, scoping, and SIEM correlation but does not confirm local execution, credential theft, exfiltration, registry compromise, cloud compromise, or attribution.

·        Credential theft should not be claimed from file access alone unless supported by staging, outbound transfer, token validation, downstream platform activity, or incident-response evidence.

·        Exfiltration should not be claimed from encrypted outbound traffic alone unless supported by execution, credential-access, staging, destination, timing, and investigation context.

·        GitHub compromise should not be claimed from GitHub API access alone unless supported by repository, workflow, token, identity, source, user-agent, timing, and change-context evidence.

·        npm registry compromise should not be claimed from npm activity alone unless supported by token, maintainer, package, publication, source, user-agent, timing, and change-context evidence.

·        Cloud compromise should not be claimed from isolated AWS, Azure, or GCP activity unless supported by mapped identity, credential, source, user-agent, resource, release-window, and exposure-context evidence.

·        Attribution should not be claimed from Shai-Hulud-style behavior alone. The report should describe behavioral alignment, tradecraft similarity, or campaign-style overlap only where evidence supports that wording.

Key Artifact Summary

The highest-value S27 artifacts are package-manager execution chains, unexpected Bun or Node runtime activity, IDE workspace task execution where applicable, process-linked credential access, local staging, suspicious egress, GitHub activity, npm registry activity, downstream AWS activity, downstream Azure activity, downstream GCP activity, and package artifact findings from YARA-supported triage.

Endpoint and CI/CD artifacts provide the strongest evidence for initial package execution and local credential-access behavior. GitHub, npm, identity, cloud, and artifact telemetry provide downstream validation and scoping. NDR provides suspicious egress, enrichment, and investigation context. YARA provides artifact triage and exposure-review support.

S27 preserves the distinction between exposure, suspicious execution, credential-access behavior, suspicious egress, downstream platform activity, cloud-control-plane activity, artifact indicators, and confirmed compromise. The final investigative position should be based on correlated evidence, not isolated package presence, isolated artifact matches, isolated GitHub access, isolated npm activity, isolated cloud events, isolated network traffic, or attribution assumptions.

S28 — Detection Strategy and SOC Implementation Guidance

Figure 5

Detection Strategy Objective

This section provides implementation guidance for operationalizing the S25 detection rule set and S26 traceability model across NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA, YARA, AWS, Azure, GCP, CI/CD, package-manager, IDE, GitHub, npm registry, identity, artifact-triage, SIEM, SOAR, change-management, and incident-response workflows.

The detection strategy is sequence-based. It prioritizes correlated behavior over single-event alerting and avoids treating package presence, package names, file names, setup.mjs references, Bun activity, IDE task-file presence, GitHub access, npm registry activity, cloud activity, suspicious egress, YARA matches, or NDR / Network Behavioral Analytics findings as standalone proof of compromise.

Strategic Detection Approach

The SOC should operationalize this detection model as a developer supply-chain compromise workflow, not as a conventional vulnerability alert. The highest-value detection logic is the sequence created when trusted package installation, IDE workspace activity, or CI/CD dependency restoration is followed by unexpected runtime execution, credential access, local staging, suspicious egress, GitHub activity, npm registry activity, downstream cloud-control-plane activity, or artifact-integrity concerns.

Detection should be deployed in layered stages:

·        Dependency exposure and affected package scoping first.

·        Endpoint and CI/CD package-manager execution telemetry second.

·        Runtime, loader, Bun, Node, shell, Python, and IDE-spawned process telemetry third.

·        Developer, package-registry, source-code, cloud, SSH, Kubernetes, Docker, deployment, and CI/CD credential-access telemetry fourth.

·        GitHub and npm registry audit telemetry fifth.

·        NDR / Network Behavioral Analytics, DNS, proxy, firewall, TLS, NetFlow, EDR network, CI/CD egress, and cloud egress telemetry sixth.

·        AWS, Azure, and GCP downstream credential-abuse and control-plane correlation seventh.

·        YARA-supported artifact triage, dependency-cache review, internal npm mirror review, package tarball review, build artifact review, and SBOM review eighth.

·        Alert promotion only after telemetry validation, false-positive baselining, field mapping, suppression governance, and triage playbook alignment.

Implementation Phase 1

Required Actions

·        Identify affected SAP-related npm packages, affected versions, dependency manifests, lockfiles, package caches, internal npm mirrors, package tarballs, build images, containers, SBOM records, and release artifacts.

·        Map developer endpoints, CI/CD runners, release systems, package-publishing systems, build systems, IDE-trusted workspaces, internal npm mirrors, artifact repositories, and cloud-connected deployment workflows.

·        Identify which systems had GitHub tokens, npm tokens, SSH keys, cloud credentials, Kubernetes configuration, Docker credentials, deployment credentials, CI/CD secrets, package-publishing authority, or release authority.

·        Identify where npm lifecycle scripts were enabled and where package installation occurred during the exposure window.

·        Identify where IDE workspace task execution is permitted and where repository-local task configuration may have been opened, trusted, or executed.

·        Confirm whether NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA-converted backends, YARA workflows, AWS, Azure, GCP, endpoint, CI/CD, GitHub, npm, identity, DNS, proxy, firewall, artifact, SOAR, change-management, and incident-response telemetry are available for the relevant exposure window.

SOC Outcome

The SOC should establish exposure scope before promoting alerts. Phase 1 should identify where affected package material existed, where execution could have occurred, which systems held high-value credentials, and which telemetry sources can support or limit confidence.

Implementation Phase 2

Required Actions

·        Deploy SentinelOne detections for package-manager lifecycle execution, unexpected runtime behavior, suspicious Bun or Node activity, IDE-spawned runtime behavior, credential-path access, local staging, and process-linked network behavior where endpoint telemetry is available.

·        Deploy Splunk correlations for endpoint, CI/CD, GitHub, npm, identity, AWS, Azure, GCP, NDR / Network Behavioral Analytics, network, YARA, artifact, change-management, and incident-response telemetry where indexes, sourcetypes, macros, lookups, summary datasets, and sequence logic are validated.

·        Deploy Elastic detections where endpoint, file, process, network, GitHub, npm, AWS, Azure, GCP, identity, NDR / Network Behavioral Analytics, YARA, artifact, and CI/CD telemetry are normalized into ECS-compatible or locally mapped fields.

·        Deploy QRadar correlations where DSM parsing, custom properties, reference sets, reference maps, building blocks, event ordering, offense grouping, and CRE logic are validated.

·        Deploy SIGMA logic only where backend translation quality, field mappings, sequence support, wildcard behavior, case handling, enrichment-field creation, and local event-source coverage are validated.

·        Validate endpoint, CI/CD, package-manager, IDE, credential-access, GitHub, npm, identity, NDR / Network Behavioral Analytics, network, artifact, and SIEM field mappings before alert promotion.

SOC Outcome

The SOC should create a reliable local-execution and correlation layer that can distinguish package exposure from suspicious execution and credential-risk behavior. This phase provides the strongest evidence for whether the incident remained an exposure concern or escalated into active execution risk.

Implementation Phase 3

Required Actions

·        Deploy NDR / Network Behavioral Analytics for suspicious developer or CI/CD egress following package or workspace execution context.

·        Use NDR / Network Behavioral Analytics for suspicious egress detection, network-side enrichment, developer-service misuse review, rare-destination analysis, post-exposure scoping, and SIEM correlation.

·        Do not treat NDR / Network Behavioral Analytics as standalone proof of npm lifecycle execution, setup.mjs execution, IDE workspace task execution, credential theft, exfiltration, registry compromise, repository compromise, cloud compromise, downstream compromise, or attribution.

·        Deploy GitHub audit detections for unusual repository creation, workflow creation, workflow modification, deploy-key changes, webhook changes, repository visibility changes, OAuth activity, GitHub App activity, token activity, and unusual API use after suspicious package or IDE execution.

·        Deploy npm registry detections for token validation, token use, token creation, package publication, package version changes, maintainer changes, ownership changes, access changes, provenance changes, metadata changes, or lifecycle-script changes after suspicious local execution or credential-access activity.

·        Deploy YARA-supported artifact triage against extracted npm package contents, internal npm mirrors, dependency caches, package tarballs, CI/CD workspaces, build artifacts, repository snapshots, quarantined files, and malware triage samples.

·        Correlate endpoint, CI/CD, GitHub, npm, identity, NDR / Network Behavioral Analytics, network, YARA, artifact, and incident-response context before raising compromise conclusions.

SOC Outcome

The SOC should establish downstream validation for suspicious egress, token abuse, package-registry abuse, repository abuse, artifact exposure, and software-integrity risk. Phase 3 should not overstate compromise. It should identify whether suspicious local execution was followed by broader registry, repository, network, cloud-control-plane, or artifact-risk behavior.

Implementation Phase 4

Required Actions

·        Deploy AWS detections only as downstream credential-abuse and control-plane correlation where AWS activity can be mapped to exposed developer or CI/CD identities, access keys, source IPs, user agents, accounts, resources, regions, repositories, build jobs, package-execution timelines, or incident-response context.

·        Deploy Azure detections only as downstream credential-abuse and control-plane correlation where Azure activity can be mapped to exposed developer or CI/CD identities, service principals, managed identities, source IPs, user agents, tenants, subscriptions, resources, repositories, build jobs, package-execution timelines, or incident-response context.

·        Deploy GCP detections only as downstream credential-abuse and control-plane correlation where GCP activity can be mapped to exposed developer or CI/CD principals, service accounts, source IPs, user agents, projects, resources, repositories, build jobs, package-execution timelines, or incident-response context.

·        Do not treat AWS, Azure, or GCP detections as initial npm package execution coverage.

·        Tune correlation windows around package installation, IDE workspace opening, runtime execution, credential access, local staging, suspicious egress, NDR / Network Behavioral Analytics findings, GitHub activity, npm registry activity, and cloud activity.

·        Use tighter windows for high-volume developer and CI/CD environments and longer windows only when source identity, host, repository, package, token, workflow, cloud principal, artifact, NDR / Network Behavioral Analytics context, or incident-response evidence supports continuity.

·        Create analyst playbooks that separate exposure, suspicious execution, credential-access behavior, suspicious egress, downstream platform activity, cloud-control-plane activity, artifact indicators, and confirmed compromise.

·        Assign alert-routing ownership across SOC, detection engineering, DevSecOps, cloud security, identity, CI/CD owners, developer platform owners, source-code platform owners, package-registry owners, and incident response.

SOC Outcome

The SOC should move from detection deployment into operational response readiness. Phase 4 should produce validated alert routing, triage decision points, containment triggers, ownership boundaries, and escalation logic.

Telemetry Normalization Requirements

Implementation requires normalized entity and time correlation across NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA-converted backends, YARA workflows, AWS, Azure, GCP, endpoint, CI/CD, package-manager, IDE, GitHub, npm, identity, network, artifact, SIEM, SOAR, change-management, and incident-response telemetry.

Minimum Normalization Requirements

·        Endpoint hostname.

·        Developer identity.

·        CI/CD runner identifier.

·        Build job identifier.

·        Repository identifier.

·        Package name.

·        Package version.

·        Dependency path.

·        Package-cache path.

·        Workspace path.

·        CI/CD working directory.

·        Package-manager process name.

·        Parent process.

·        Child process.

·        Command line.

·        Process path.

·        Working directory.

·        File path.

·        File hash where available.

·        Runtime name.

·        IDE parent process where available.

·        Workspace task-file path where available.

·        Credential path.

·        Environment-file path.

·        GitHub actor.

·        GitHub organization.

·        GitHub repository.

·        GitHub event action.

·        npm user.

·        npm organization.

·        npm package.

·        npm event action.

·        Identity provider user.

·        Source IP.

·        Source ASN.

·        Source geography.

·        User agent.

·        Destination hostname.

·        Destination IP.

·        DNS query.

·        Proxy action.

·        Firewall action.

·        TLS metadata where available.

·        Network-flow context where available.

·        NDR / Network Behavioral Analytics event context where available.

·        AWS principal, account, resource, event name, and region where applicable.

·        Azure tenant, subscription, caller, resource, operation name, and region where applicable.

·        GCP principal, project, resource, method name, caller IP, and region where applicable.

·        YARA rule name where applicable.

·        YARA match path where applicable.

·        Artifact identifier.

·        Build artifact identifier.

·        SBOM identifier.

·        Change ticket ID.

·        Approved workflow context.

·        SOAR case ID.

·        Incident-response case ID.

·        Event timestamp.

·        Event source.

Correlation Requirements

Rules should use bounded correlation windows that reflect the relationship between package exposure, local execution, credential access, suspicious egress, downstream platform activity, cloud activity, and artifact risk.

Recommended Starting Windows

·        Package installation, dependency restoration, or workspace opening to suspicious runtime execution within 30 minutes.

·        Suspicious package-manager, runtime, or IDE-spawned execution to credential access within 60 minutes.

·        Credential access to local staging, encoded output, archive creation, encrypted file creation, or temporary file creation within 60 minutes.

·        Credential access or local staging to suspicious egress within 2 hours.

·        Suspicious execution, credential access, or staging to NDR / Network Behavioral Analytics findings within 2 hours.

·        Suspicious execution or credential access to GitHub activity within 4 hours.

·        Suspicious execution or credential access to npm registry activity within 4 hours.

·        Suspicious execution, credential access, token activity, or egress to AWS, Azure, or GCP control-plane activity within 24 hours.

·        Suspicious package or artifact findings to endpoint, CI/CD, GitHub, npm, cloud, NDR / Network Behavioral Analytics, network, or incident-response evidence within the exposure investigation window.

These windows should be tightened in high-volume environments and extended only when host, user, repository, package, token, source IP, user-agent, CI/CD job, artifact, cloud principal, NDR / Network Behavioral Analytics context, SOAR case, incident-response case, or change-management evidence supports continuity.

Alert Promotion Guidance

Do not promote a hunt or correlation search into alert mode until the following conditions are met:

·        Required telemetry is present and normalized.

·        Required field mappings are validated.

·        Entity resolution is reliable.

·        Event timing and ordering are reliable.

·        Developer endpoint and CI/CD runner roles are mapped.

·        Package-manager, runtime, IDE, credential-path, package-cache, and workspace-path fields are mapped.

·        NDR / Network Behavioral Analytics, GitHub, npm, identity, AWS, Azure, GCP, DNS, proxy, firewall, network-flow, artifact, YARA, and SIEM context are mapped where applicable.

·        Approved developer workflows are baselined.

·        Approved CI/CD workflows are baselined.

·        Approved package-publishing workflows are baselined.

·        Approved GitHub workflow changes are baselined.

·        Approved npm publication activity is baselined.

·        Approved cloud deployment and automation workflows are baselined.

·        Approved IDE task usage is baselined where applicable.

·        Approved developer and CI/CD egress patterns are baselined.

·        False-positive sources are reviewed.

·        High-volume expected workflows are suppressed or downgraded.

·        Query performance is tested.

·        YARA scanning scope and known-good package baselines are documented.

·        NDR / Network Behavioral Analytics rare-destination, approved-destination, and source-role baselines are documented.

·        Analyst review criteria are established.

·        Local severity logic is calibrated.

·        Alert-routing ownership is assigned.

False-Positive Control

False-positive control should use allowlists, reference sets, approved workflow baselines, known developer and CI/CD source ranges, expected VPN paths, approved jump hosts, approved package-manager behavior, approved runtime behavior, approved IDE task behavior, approved release windows, approved package-publishing windows, approved GitHub automation, approved npm automation, approved cloud automation, approved infrastructure-as-code identities, approved artifact workflows, approved developer egress patterns, approved CI/CD egress patterns, approved security-testing workflows, approved monitoring workflows, approved incident-response exceptions, and known-good package baselines.

Common False-Positive Sources

·        Approved npm install, npm ci, yarn, pnpm, build, test, lint, release, or package-restore activity.

·        Approved Bun, Node, Python, shell, PowerShell, curl, wget, archive, or runtime usage by repository or build image.

·        Approved package lifecycle scripts.

·        Approved developer IDE task execution.

·        Approved CI/CD automation.

·        Approved package-publishing workflows.

·        Approved GitHub workflow changes.

·        Approved npm publication activity.

·        Approved dependency-cache activity.

·        Approved internal npm mirror synchronization.

·        Approved artifact repository activity.

·        Approved developer egress to GitHub, npm, package repositories, cloud services, collaboration tools, raw-content services, or webhook services.

·        Approved CI/CD egress to package repositories, GitHub, npm, artifact stores, deployment targets, and cloud services.

·        Approved security scanning.

·        Approved software composition analysis.

·        Approved malware triage.

·        Approved YARA scanning.

·        Approved cloud deployment activity.

·        Approved cloud secret access.

·        Approved infrastructure-as-code workflows.

·        Approved service-account activity.

·        Approved incident-response collection.

·        Approved credential rotation.

·        Approved break-glass administration.

·        Approved vendor-support activity.

·        Approved managed-service provider activity.

Triage Guidance

Initial triage should determine whether suspicious activity forms a coherent sequence rather than a single-event anomaly.

Initial Triage Questions

·        Was an affected SAP-related npm package version present in dependency files, lockfiles, package caches, internal npm mirrors, package tarballs, build images, containers, SBOM records, or release artifacts?

·        Was the affected package installed or restored during the exposure window?

·        Were npm lifecycle scripts enabled?

·        Did package-manager activity launch Bun, Node, shell, PowerShell, Python, curl, wget, archive tools, loader files, or encoded-command behavior?

·        Was setup.mjs or similar loader behavior observed?

·        Was Bun activity expected for the host, repository, build image, or workflow?

·        Did VS Code, Cursor, or another IDE parent process spawn suspicious runtime, shell, downloader, package-manager, or command-interpreter activity from project-controlled paths?

·        Was .vscode/tasks.json or equivalent workspace task configuration present, modified, hidden, or executed?

·        Did suspicious execution access .npmrc, GitHub tokens, SSH keys, cloud credentials, Kubernetes configuration, Docker configuration, environment files, CI/CD secret material, package-registry credentials, or deployment credentials?

·        Was local staging, encoding, compression, encryption, archive creation, temporary file creation, or short-lived file behavior observed after credential access?

·        Was suspicious egress observed after package-manager, runtime, IDE, credential-access, or local-staging activity?

·        Did NDR / Network Behavioral Analytics identify rare destination access, unusual upload-like behavior, developer-service misuse, suspicious external infrastructure, or abnormal developer / CI/CD egress after exposure?

·        Did GitHub repository, workflow, deploy-key, webhook, OAuth, token, or unusual API activity occur after exposure?

·        Did npm token, maintainer, owner, package, publication, access, provenance, metadata, or version activity occur after exposure?

·        Did AWS, Azure, or GCP activity occur from identities, source IPs, user agents, resources, accounts, tenants, subscriptions, projects, or automation contexts tied to exposed systems?

·        Did YARA identify suspicious package artifact behavior, and does the match path align with dependency, cache, mirror, package, build, artifact, or repository exposure?

·        Is the activity explained by approved development, CI/CD, package publishing, GitHub automation, npm automation, IDE task usage, approved developer egress, approved CI/CD egress, cloud deployment, security testing, monitoring, vendor support, managed-service activity, or incident response?

Escalation Triggers

Escalate when multiple behavior classes align in sequence, especially when package installation or IDE workspace activity is followed by unexpected runtime execution, credential-path access, local staging, suspicious egress, NDR / Network Behavioral Analytics findings, GitHub activity, npm registry activity, downstream cloud-control-plane activity, or artifact-integrity risk.

Higher-Priority Escalation Conditions

·        Affected package versions were installed on systems with GitHub tokens, npm tokens, SSH keys, cloud credentials, Kubernetes configuration, Docker credentials, deployment credentials, package-publishing authority, CI/CD secrets, or release authority.

·        Package-manager lifecycle execution launched unexpected Bun, Node, shell, PowerShell, Python, curl, wget, archive tools, loader files, or encoded-command behavior.

·        setup.mjs or loader-like JavaScript executed from package, cache, dependency, temporary, workspace, CI/CD, or build paths.

·        Bun executed where Bun is not approved for the host, repository, build image, or workflow.

·        IDE parent processes launched runtime or shell activity from project-controlled paths.

·        Workspace task configuration included autorun, folder-open behavior, hidden presentation behavior, downloader behavior, encoded commands, or unusual runtime launch paths.

·        Credential files, environment variables, cloud configuration, package-registry credentials, CI/CD secrets, or deployment material were accessed after suspicious execution.

·        Local staging, encoded output, encrypted files, archive files, compressed files, or short-lived temporary files appeared after credential access.

·        Suspicious egress followed credential access or local staging.

·        NDR / Network Behavioral Analytics findings aligned with package-manager, runtime, IDE, credential-access, staging, GitHub, npm, identity, or cloud context.

·        GitHub workflow, repository, deploy-key, webhook, OAuth, token, or unusual API activity followed exposure.

·        npm token, package publication, maintainer, ownership, provenance, metadata, access, or version activity followed exposure.

·        AWS, Azure, or GCP privileged activity followed exposure and mapped to affected users, systems, automation identities, access keys, service principals, service accounts, source IPs, user agents, resources, or release windows.

·        YARA artifact matches align with package exposure and supporting endpoint, CI/CD, NDR / Network Behavioral Analytics, network, GitHub, npm, cloud, or incident-response evidence.

·        Multiple telemetry sources independently show aligned behavior.

·        Activity is not explained by approved development, CI/CD, package-publishing, GitHub automation, npm automation, IDE task, developer egress, CI/CD egress, cloud deployment, security testing, monitoring, vendor support, managed-service, or incident-response workflows.

Containment Actions

·        Preserve endpoint, CI/CD, GitHub, npm, identity, cloud, DNS, proxy, firewall, NDR / Network Behavioral Analytics, artifact, YARA, SIEM, SOAR, change-management, and incident-response evidence before cleanup where operationally feasible.

·        Isolate or restrict systems showing suspicious package-manager, runtime, IDE-spawned, credential-access, local-staging, or suspicious egress behavior.

·        Revoke and rotate GitHub tokens, npm tokens, SSH keys, cloud keys, Kubernetes credentials, Docker credentials, deployment credentials, CI/CD secrets, and package-publishing credentials from exposed systems.

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

·        Review npm tokens, package publications, maintainer changes, ownership changes, access changes, provenance changes, metadata changes, and version history.

·        Review AWS, Azure, and GCP activity for downstream credential abuse where exposed identities or systems had cloud access.

·        Remove affected package versions from dependency files and lockfiles.

·        Purge or quarantine affected package material from dependency caches, internal npm mirrors, build images, package tarballs, CI/CD workspaces, containers, and artifact repositories.

·        Review build artifacts, SBOM records, containers, internal packages, and release outputs created during the exposure window.

·        Restrict npm lifecycle scripts, package-publishing authority, IDE task autorun, and CI/CD secret exposure where operationally feasible.

SOC Reporting Guidance

SOC reporting should separate exposure, suspicious execution, credential-access behavior, suspicious egress, downstream platform activity, cloud-control-plane activity, artifact indicators, and confirmed compromise.

Do not report credential theft, exfiltration, registry compromise, repository compromise, cloud compromise, downstream compromise, or attribution unless supported by corroborating telemetry and incident-response validation.

Implementation Summary

The implementation strategy is production-viable when deployed as a layered, behavior-led correlation model. The SOC should prioritize package-manager execution, unexpected runtime activity, credential-access behavior, suspicious egress, NDR / Network Behavioral Analytics enrichment, GitHub activity, npm registry activity, downstream cloud activity, and artifact triage as related evidence categories rather than isolated proof points. The strongest operational outcomes come from normalized NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA, YARA, AWS, Azure, GCP, endpoint, CI/CD, GitHub, npm, identity, artifact, SIEM, and incident-response telemetry aligned into bounded sequences.

S29 — Detection Coverage Summary

Coverage Summary Objective

This section summarizes the detection coverage achieved by the finalized S25 rule set and identifies remaining detection gaps. Coverage is assessed by attack phase, telemetry domain, system contribution, and rule maturity.

Coverage Summary

The S25 detection set provides broad behavior-led coverage for SAP-related npm package poisoning, Shai-Hulud-style developer credential theft, suspicious package-manager lifecycle execution, unexpected runtime activity, adapted IDE workspace-triggered execution, credential access, local secret staging, suspicious egress, GitHub audit activity, npm registry activity, downstream AWS activity, downstream Azure activity, downstream GCP activity, NDR / Network Behavioral Analytics enrichment, and package artifact triage.

Coverage is strongest when NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA, YARA, AWS, Azure, GCP, endpoint, CI/CD, package-manager, IDE, GitHub, npm registry, cloud, identity, DNS, proxy, firewall, network-flow, artifact, SIEM, SOAR, change-management, and incident-response telemetry are normalized and correlated into bounded sequences.

The report’s detection model intentionally avoids relying on package names, file names, hashes, infrastructure, actor branding, campaign labels, or single-event conclusions. It focuses on durable activity patterns that remain useful across trusted-dependency execution, install-time lifecycle abuse, runtime staging, developer credential access, token abuse, suspicious egress, package-registry abuse, repository abuse, downstream cloud credential misuse, and software-integrity uncertainty.

Coverage by Attack Phase

Initial Package Execution

Coverage is strong across SentinelOne, Splunk, Elastic, QRadar, and SIGMA where package-manager lifecycle execution, suspicious runtime execution, parent-child lineage, process command line, working-directory context, dependency paths, package-cache paths, CI/CD workspace paths, and abnormal execution paths are available. YARA can support exposure and artifact review, but it does not prove execution.

Coverage is limited where package installation occurred on managed CI/CD runners, ephemeral build containers, hosted build services, or unmonitored developer systems with limited command-line, process-lineage, and file-access telemetry.

Suspicious Runtime and Loader Activity

Coverage is strong across SentinelOne, Splunk, Elastic, QRadar, and SIGMA where Bun, Node, shell, PowerShell, Python, curl, wget, archive utility, loader-style JavaScript, setup.mjs, encoded command, or runtime activity is visible from dependency, cache, temporary, workspace, package, user-profile, CI/CD, or build paths.

Coverage requires local baselines for approved Bun, Node, Python, shell, downloader, archive, build, test, release, and CI/CD behavior.

IDE Workspace Task Execution

Coverage is moderate to strong across SentinelOne, Splunk, Elastic, QRadar, and SIGMA where endpoint telemetry captures IDE parent-child process behavior, working-directory context, command-line data, repository-local task-file context, and follow-on credential or egress activity.

This is Coverage With Adaptation and does not prove direct SAP npm lifecycle execution. Coverage is limited where endpoint telemetry does not preserve IDE process lineage, workspace-open timing, task execution details, or file-access context.

Credential Access and Secret Discovery

Coverage is strong across SentinelOne, Splunk, Elastic, QRadar, and SIGMA where endpoint and CI/CD telemetry captures access to .npmrc, GitHub token material, SSH keys, cloud credentials, Kubernetes configuration, Docker configuration, environment files, CI/CD secret material, package-registry credentials, deployment credentials, repository configuration files, and related sensitive paths after suspicious execution.

AWS, Azure, and GCP provide downstream validation only where exposed credentials are later used against cloud control planes. Environment-variable-only secret exposure, injected CI/CD variables, memory-only access, managed secret stores, short-lived containers, and ephemeral runners may not leave durable file-access evidence.

Local Staging and Encrypted Handling

Coverage is moderate to strong across SentinelOne, Splunk, Elastic, QRadar, and SIGMA where file creation, file modification, rename, deletion, archive creation, encoded output, encrypted file creation, compressed output, JSON output, temporary-file behavior, and process lineage are available after credential access.

Coverage is limited when staging occurs only in memory, when files are short-lived, when file telemetry is unavailable, or when content inspection is unavailable.

Suspicious Egress and Network Activity

Coverage is moderate to strong across NDR / Network Behavioral Analytics, Splunk, Elastic, and QRadar, with supporting context from SentinelOne, AWS, Azure, and GCP where process, endpoint, or cloud egress context exists.

Coverage includes suspicious developer or CI/CD egress following package or workspace execution context, rare destination access, unusual upload-like behavior, developer-service misuse, newly observed destinations, suspicious external infrastructure, GitHub API access, npm-related destinations, raw-content services, webhook services, cloud storage, paste-like services, and abnormal developer or CI/CD egress after execution, credential access, or staging.

NDR / Network Behavioral Analytics does not independently prove npm lifecycle execution, setup.mjs execution, IDE workspace task execution, credential theft, exfiltration, GitHub compromise, npm registry compromise, cloud compromise, downstream compromise, or attribution. It requires correlation with endpoint, CI/CD, package-manager, IDE, GitHub, npm, cloud, identity, artifact, change-management, or incident-response evidence.

GitHub and Source-Code Platform Abuse

Coverage is strong across Splunk, Elastic, and QRadar where GitHub audit telemetry is available and normalized. Supporting context may come from SentinelOne, NDR / Network Behavioral Analytics, and SIGMA-converted backends where relevant telemetry is present.

Coverage includes repository creation, workflow creation, workflow modification, deploy-key changes, webhook changes, OAuth activity, GitHub App activity, token activity, branch protection changes, repository visibility changes, unusual API use, actor context, source IP, user-agent, and repository context after exposure.

GitHub activity does not prove initial npm package execution, credential theft, repository compromise, or actor attribution without supporting endpoint, CI/CD, package-manager, IDE, artifact, identity, network, or incident-response evidence.

npm Registry Abuse

Coverage is strong across Splunk, Elastic, and QRadar where npm registry telemetry is available and normalized. Supporting context may come from NDR / Network Behavioral Analytics, SentinelOne, and SIGMA-converted backends where relevant telemetry is present.

Coverage includes npm token validation, token use, package publication, package version changes, maintainer changes, ownership changes, access changes, provenance changes, metadata changes, publication context, source IP, user-agent, and package context.

npm activity does not prove credential theft, registry compromise, package propagation, or actor attribution without supporting identity, endpoint, CI/CD, source-code, registry, network, artifact, and incident-response evidence.

AWS Downstream Credential Abuse

Coverage is conditional and downstream-only across AWS, Splunk, Elastic, and QRadar, with supporting context from SentinelOne, NDR / Network Behavioral Analytics, identity telemetry, and incident-response evidence.

Coverage includes CloudTrail, IAM, STS, Secrets Manager, SSM Parameter Store, ECR, CodeBuild, CodePipeline, Lambda, S3, KMS, identity, resource, source IP, user-agent, account, region, and release-context telemetry correlated with exposed developer or CI/CD identities.

AWS rules do not detect initial npm package execution and do not independently prove SAP npm compromise, credential theft, cloud compromise, downstream compromise, or attribution.

Azure Downstream Credential Abuse

Coverage is conditional and downstream-only across Azure, Splunk, Elastic, and QRadar, with supporting context from SentinelOne, NDR / Network Behavioral Analytics, identity telemetry, and incident-response evidence.

Coverage includes Microsoft Entra ID audit logs, Entra sign-in logs, Azure Activity logs, Key Vault logs, Azure Container Registry logs, storage logs, managed identity events, Conditional Access context, tenant context, subscription context, source IP, user-agent, resource, and release-context telemetry correlated with exposed developer or CI/CD identities.

Azure rules do not detect initial npm package execution and do not independently prove SAP npm compromise, credential theft, cloud compromise, downstream compromise, or attribution.

GCP Downstream Credential Abuse

Coverage is conditional and downstream-only across GCP, Splunk, Elastic, and QRadar, with supporting context from SentinelOne, NDR / Network Behavioral Analytics, identity telemetry, and incident-response evidence.

Coverage includes Admin Activity audit logs, Data Access audit logs, Secret Manager audit logs, Artifact Registry logs, Cloud Build logs, Cloud Run logs, Cloud Functions logs, GKE audit logs, Cloud Storage logs, Security Command Center enrichment, project context, principal context, service-account context, caller IP, user-agent, resource, method name, and release-context telemetry correlated with exposed developer or CI/CD identities.

GCP rules do not detect initial npm package execution and do not independently prove SAP npm compromise, credential theft, cloud compromise, downstream compromise, or attribution.

Artifact Triage

Coverage is moderate to strong through YARA, with supporting context from SentinelOne, Splunk, Elastic, QRadar, incident-response workflows, artifact repositories, SBOM systems, and package repositories.

Coverage includes extracted npm package contents, internal npm mirror contents, dependency caches, package tarballs, CI/CD workspace artifacts, build artifacts, repository snapshots, quarantined endpoint files, malware triage samples, artifact repository records, container metadata, SBOM records, and provenance records.

YARA supports artifact triage and exposure review. It does not independently prove execution, credential theft, exfiltration, registry abuse, repository compromise, cloud compromise, downstream compromise, or attribution.

Coverage by System

NDR / Network Behavioral Analytics

NDR / Network Behavioral Analytics provides behavioral coverage for suspicious developer or CI/CD egress following package or workspace execution context. It supports suspicious egress detection, network-side enrichment, developer-service misuse review, rare-destination analysis, post-exposure scoping, and SIEM correlation.

NDR / Network Behavioral Analytics coverage is strongest where DNS, TLS, HTTP metadata, proxy, firewall, secure-access, network-flow, source-role, approved-destination, developer endpoint, CI/CD runner, repository, package, and SIEM correlation context are available.

NDR / Network Behavioral Analytics does not independently prove npm lifecycle execution, setup.mjs execution, IDE workspace task execution, credential theft, exfiltration, GitHub compromise, npm registry compromise, cloud compromise, downstream compromise, or actor attribution. It should be treated as suspicious egress and enrichment coverage that requires correlation with endpoint, CI/CD, package-manager, IDE, GitHub, npm, cloud, identity, artifact, change-management, or incident-response evidence.

SentinelOne

SentinelOne provides strong endpoint coverage for package-manager execution, unexpected runtime behavior, suspicious Bun or Node activity, IDE-spawned runtime behavior, credential-path access, local staging, and process-linked network behavior where endpoint telemetry is available.

SentinelOne does not independently cover GitHub, npm registry, cloud, or artifact outcomes without external telemetry correlation.

Splunk

Splunk provides strong correlation coverage when endpoint, CI/CD, GitHub, npm, identity, AWS, Azure, GCP, DNS, proxy, firewall, NDR / Network Behavioral Analytics, YARA, artifact, change-management, and incident-response telemetry are normalized into reliable indexes, sourcetypes, macros, lookups, summary datasets, and sequence logic.

Splunk coverage depends on local field mappings, correlation windows, lookup quality, index performance, and suppression governance.

Elastic

Elastic provides strong endpoint and SIEM correlation coverage when endpoint, file, process, network, GitHub, npm, AWS, Azure, GCP, identity, NDR / Network Behavioral Analytics, YARA, artifact, and CI/CD telemetry are normalized into ECS-compatible or locally mapped fields with reliable sequencing, enrich policies, transforms, value lists, and exceptions.

Elastic coverage depends on ECS mapping quality, event-source completeness, correlation design, and enrichment quality.

QRadar

QRadar provides strong correlation coverage when DSM parsing, custom properties, reference sets, reference maps, building blocks, event ordering, offense grouping, and CRE logic are validated across endpoint, CI/CD, GitHub, npm, identity, network, NDR / Network Behavioral Analytics, AWS, Azure, GCP, YARA, artifact, and incident-response telemetry.

QRadar coverage depends on local DSM quality, custom-property extraction, reference-data quality, and CRE implementation fidelity.

SIGMA

SIGMA provides portable event-rule template logic for package-manager lifecycle execution, unexpected runtime activity, IDE-spawned runtime behavior, credential-path access, and related suspicious behavior.

SIGMA production value depends on backend translation quality, field mappings, sequence support, wildcard behavior, case handling, enrichment-field creation, and local event-source coverage.

YARA

YARA provides supplemental artifact-behavior coverage for suspicious npm package contents, loader-style JavaScript, lifecycle-script logic, runtime bootstrap indicators, developer-secret targeting strings, staging indicators, and exfiltration-adjacent strings.

YARA does not independently prove execution, credential theft, exfiltration, registry compromise, repository compromise, cloud compromise, downstream compromise, or attribution.

AWS

AWS provides conditional downstream cloud credential-abuse coverage when suspicious AWS activity is correlated with exposed developer or CI/CD identities, access keys, source IPs, user agents, accounts, resources, regions, repositories, build jobs, package-execution timelines, or incident-response context.

AWS does not independently prove SAP npm package execution.

Azure

Azure provides conditional downstream cloud credential-abuse coverage when suspicious Azure activity is correlated with exposed developer or CI/CD identities, service principals, managed identities, source IPs, user agents, tenants, subscriptions, resources, repositories, build jobs, package-execution timelines, or incident-response context.

Azure does not independently prove SAP npm package execution.

GCP

GCP provides conditional downstream cloud credential-abuse coverage when suspicious GCP activity is correlated with exposed developer or CI/CD principals, service accounts, source IPs, user agents, projects, resources, repositories, build jobs, package-execution timelines, or incident-response context.

GCP does not independently prove SAP npm package execution.

Primary Coverage Strengths

·        Behavior-led coverage that does not depend on package names alone.

·        Strong endpoint and CI/CD coverage for suspicious package-manager execution.

·        Strong runtime coverage for unexpected Bun, Node, shell, PowerShell, Python, curl, wget, archive, and loader behavior.

·        Strong adapted IDE workspace coverage where process lineage and workspace task context exist.

·        Strong credential-risk coverage where sensitive-file access and command-line telemetry exist.

·        Strong suspicious egress coverage where NDR / Network Behavioral Analytics and network telemetry are correlated with endpoint, CI/CD, package-manager, IDE, credential-access, staging, GitHub, npm, identity, cloud, artifact, or incident-response evidence.

·        Strong GitHub and npm downstream coverage where audit logs are available.

·        Strong cloud downstream coverage where AWS, Azure, and GCP logs are normalized and tied to exposed identities.

·        Strong artifact triage where package contents, internal mirrors, dependency caches, package tarballs, build artifacts, SBOMs, and YARA scanning are available.

·        Strong SOC utility when telemetry categories align in sequence.

Primary Coverage Gaps

·        Managed CI/CD runners and ephemeral build containers may limit execution and file-access reconstruction.

·        Developer endpoints may lack file-access telemetry, command-line logging, or IDE parent-child process visibility.

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

·        GitHub and npm audit logs may lack sufficient token lineage, source IP, user-agent, or retention.

·        Cloud events may not map cleanly to exposed developer or CI/CD credentials.

·        Encrypted egress may prevent content-level confirmation.

·        NDR / Network Behavioral Analytics may identify suspicious egress without proving credential theft or exfiltration.

·        YARA matches may identify suspicious artifact content without proving execution.

·        Package presence may identify exposure without proving install-time execution.

·        Attribution cannot be established from behavior alignment alone.

Non-Covered Areas

The S25 rule set does not directly prove:

·        Successful credential theft.

·        Successful exfiltration.

·        Successful GitHub compromise.

·        Successful npm registry compromise.

·        Successful cloud compromise.

·        Successful downstream artifact compromise.

·        Persistent access.

·        Lateral movement.

·        Customer data exposure.

·        Actor attribution.

·        Campaign attribution.

·        Malware-family attribution.

These outcomes require investigation, corroborating telemetry, and incident-specific validation.

Coverage Conclusion

The detection set provides strong practical coverage for observable enterprise behavior associated with SAP-related npm package poisoning and Shai-Hulud-style developer credential theft. It is strongest when multiple telemetry classes align in sequence and weakest where endpoint visibility is unavailable, CI/CD telemetry is ephemeral, GitHub or npm audit data is incomplete, cloud identity linkage is weak, NDR / Network Behavioral Analytics context cannot be correlated to local execution, artifact retention is limited, or suspicious egress cannot be tied to credential-access behavior.

S30 — Intelligence Maturity Assessment

Assessment Objective

This section assesses the intelligence maturity of the SAP npm package poisoning and Shai-Hulud-style developer credential theft detection model. The assessment evaluates behavioral maturity, telemetry maturity, network maturity, cloud maturity, artifact maturity, adversary-resilience maturity, operationalization maturity, attribution maturity, and maturity improvement priorities.

Intelligence Maturity Level

High for behavior-led detection strategy.

Moderate to high for operational detection where NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA, YARA, AWS, Azure, GCP, endpoint, CI/CD, GitHub, npm, cloud, identity, network, artifact, and incident-response telemetry are normalized.

Moderate for direct compromise confirmation.

Low to moderate for attribution.

Maturity Assessment Summary

The intelligence maturity level for this report is high for behavior-led detection strategy because the model focuses on durable relationships between package-manager execution, unexpected runtime activity, credential access, local staging, suspicious egress, GitHub activity, npm registry activity, downstream cloud activity, and artifact-risk evidence.

Direct compromise confirmation remains moderate because many environments do not retain complete endpoint file-access telemetry, IDE parent-child process context, CI/CD runner telemetry, GitHub token lineage, npm token lineage, cloud credential lineage, process-to-network mapping, NDR / Network Behavioral Analytics correlation context, or artifact-retention evidence. Most environments will infer suspected compromise through correlated behavior and then validate conclusions through incident response.

Behavioral Intelligence Maturity

Behavioral maturity is high.

The report identifies repeatable behaviors that can be detected across NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA-converted backends, YARA workflows, AWS, Azure, GCP, developer endpoints, CI/CD runners, package-manager logs, IDE process telemetry, GitHub audit logs, npm registry logs, identity logs, DNS logs, proxy logs, firewall logs, network-flow telemetry, artifact repositories, SBOM records, SIEM platforms, SOAR systems, and incident-response workflows.

The behaviors are durable across package-name changes, file-name changes, hash changes, infrastructure changes, runtime changes, attacker-controlled repository changes, actor branding, campaign labels, and cloud-provider variation.

Strong Behavioral Anchors

·        SAP-related npm package exposure and dependency restoration.

·        npm, pnpm, or yarn lifecycle execution.

·        setup.mjs or loader-style JavaScript execution.

·        Unexpected Bun, Node, shell, PowerShell, Python, curl, wget, archive, or downloader activity.

·        IDE parent processes launching runtime or shell activity from project-controlled paths where applicable.

·        Access to .npmrc, GitHub token material, SSH keys, cloud credentials, Kubernetes configuration, Docker configuration, environment files, CI/CD secrets, package-registry credentials, and deployment credentials.

·        Local staging, encoded output, compressed files, encrypted files, temporary files, or short-lived files after credential access.

·        Suspicious egress after package-manager, runtime, IDE, credential-access, or staging behavior.

·        NDR / Network Behavioral Analytics findings tied to rare destination access, developer-service misuse, unusual upload-like behavior, or abnormal developer / CI/CD egress after exposure.

·        GitHub repository, workflow, deploy-key, webhook, OAuth, token, or unusual API activity after exposure.

·        npm token, package publication, maintainer, owner, access, provenance, metadata, or version activity after exposure.

·        AWS, Azure, or GCP control-plane activity following developer or CI/CD exposure.

·        YARA-supported artifact findings tied to package, cache, mirror, build, repository, or artifact evidence.

Telemetry Maturity Assessment

Telemetry maturity is moderate to high.

Telemetry maturity is high where NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA-converted backends, YARA workflows, AWS, Azure, GCP, endpoint, CI/CD, package-manager, IDE, GitHub, npm, identity, DNS, proxy, firewall, network-flow, artifact, SIEM, SOAR, change-management, and incident-response telemetry are available and normalized.

Telemetry maturity decreases when developer endpoints lack file-access telemetry, CI/CD runners are ephemeral, package-manager logs are unavailable, IDE process lineage is missing, NDR / Network Behavioral Analytics context cannot be tied to source roles or process activity, GitHub audit depth is limited, npm token lineage is incomplete, cloud identity mapping is weak, process-to-network attribution is unavailable, or artifact retention is incomplete.

Endpoint and EDR Telemetry

Endpoint and EDR maturity is high when process creation, parent-child process lineage, command-line logging, working-directory context, file access, file creation, file deletion, process-linked network telemetry, and sensitive-path monitoring are available.

Endpoint maturity is moderate where process execution is visible but sensitive-file access, IDE lineage, short-lived file activity, or process-to-network mapping is incomplete.

Endpoint maturity is low where developer systems are unmanaged, EDR coverage is absent, command-line logging is disabled, or file-access telemetry is unavailable.

CI/CD Telemetry

CI/CD maturity is high when runner identity, job identity, repository, branch, workflow, command logs, dependency restoration, package-manager execution, environment-variable handling, secret access, build workspace, package-publishing activity, artifact output, and egress telemetry are retained.

CI/CD maturity is moderate where build logs and workflow metadata exist but runner-level endpoint telemetry is incomplete.

CI/CD maturity is low where managed or ephemeral runners do not preserve execution, file-access, network, or artifact context.

GitHub and npm Registry Telemetry

GitHub and npm registry maturity is high when audit logs capture actor, token, source IP, user-agent, repository, organization, workflow, deploy-key, webhook, OAuth, package, maintainer, owner, publication, access, provenance, metadata, and timestamp context.

Maturity is moderate where audit records exist but token lineage, source IP, user-agent, or identity linkage is incomplete.

Maturity is low where audit retention is short, organization logging is unavailable, or package publication and token activity cannot be tied to exposed systems or users.

Network and NDR Maturity

Network and NDR maturity is moderate to high.

Network maturity is high when DNS, proxy, firewall, TLS, NetFlow, EDR network, CI/CD egress, cloud egress, NDR / Network Behavioral Analytics telemetry, process-to-network mapping, source identity, source role, destination context, approved-destination baselines, rare-destination baselines, and SIEM correlation are available.

Network maturity is moderate where destination and flow metadata exist without process attribution or where NDR / Network Behavioral Analytics can identify suspicious egress but cannot identify the local execution cause.

Network maturity is low where encrypted egress, common developer services, GitHub traffic, npm traffic, cloud storage traffic, webhooks, raw-content services, and package repositories cannot be distinguished from normal developer or CI/CD behavior.

NDR / Network Behavioral Analytics is mature as suspicious egress, enrichment, scoping, rare-destination review, developer-service misuse review, and SIEM-correlation support. It is not mature as standalone proof of npm lifecycle execution, credential theft, exfiltration, registry compromise, cloud compromise, downstream compromise, or attribution.

Cloud Telemetry

Cloud maturity is moderate.

AWS, Azure, and GCP provide useful downstream credential-abuse visibility when cloud activity can be correlated with exposed developer or CI/CD identities, access keys, service principals, service accounts, source IPs, user agents, resources, accounts, tenants, subscriptions, projects, repositories, workflows, build jobs, NDR / Network Behavioral Analytics context, and incident-response findings.

Cloud telemetry does not independently prove SAP npm package execution. Its strongest value comes from correlation with prior package exposure, suspicious local execution, credential access, suspicious egress, GitHub activity, npm activity, identity context, artifact context, and incident-response validation.

Artifact Intelligence

Artifact intelligence maturity is moderate to high.

Artifact maturity is high where package tarballs, internal npm mirrors, dependency caches, CI/CD workspaces, build artifacts, repository snapshots, quarantined files, SBOMs, container metadata, artifact repositories, and YARA scanning are available.

Artifact maturity is moderate where package material can be inspected but endpoint execution, CI/CD execution, credential access, or network telemetry is incomplete.

Artifact maturity is low where affected packages, caches, build workspaces, mirrors, or artifacts were purged before preservation.

Detection Engineering Maturity

Detection engineering maturity is high.

The S25 rules are behavior-led, platform-scoped, and structured to avoid overclaiming. The model separates endpoint execution coverage, CI/CD coverage, NDR / Network Behavioral Analytics coverage, source-code platform coverage, package-registry coverage, cloud downstream coverage, SIEM correlation, and artifact triage.

Rule Quality

Rule quality is strong because the rule set focuses on sequence-based behavior rather than static indicators alone. It separates direct package execution coverage from downstream cloud coverage, treats YARA as supplemental artifact triage, treats NDR / Network Behavioral Analytics as suspicious egress, enrichment, and scoping, and avoids unsupported claims of credential theft, exfiltration, registry compromise, cloud compromise, downstream compromise, or attribution.

Correlation Maturity

Correlation maturity is moderate to high.

Correlation is strongest where SIEM platforms can link user, host, process, repository, package, CI/CD job, token, source IP, user-agent, cloud principal, destination, NDR / Network Behavioral Analytics finding, artifact, YARA match, change ticket, SOAR case, and incident-response case context.

Correlation maturity decreases when identities, hosts, repositories, package names, tokens, service accounts, network sources, destinations, NDR / Network Behavioral Analytics findings, and cloud principals cannot be reliably mapped.

Deployment Maturity

Deployment maturity is moderate.

The S25 rules are implementation-ready detection patterns, but production deployment requires validation of schemas, index names, sourcetypes, DSM fields, custom properties, ECS mappings, package-manager fields, endpoint fields, CI/CD fields, GitHub fields, npm fields, NDR / Network Behavioral Analytics fields, AWS fields, Azure fields, GCP fields, identity mappings, enrichment sources, exception lists, false-positive baselines, query performance, triage logic, and alert-routing decisions.

Operational Readiness

Ready for Production Deployment

·        SentinelOne endpoint detections for package-manager execution, unexpected runtime behavior, credential-path access, local staging, IDE-spawned runtime behavior, and process-linked network behavior where EDR telemetry, command-line logging, parent-child process lineage, working-directory context, and false-positive baselines are available.

·        Splunk correlations where endpoint, CI/CD, GitHub, npm, identity, AWS, Azure, GCP, NDR / Network Behavioral Analytics, network, YARA, artifact, change-management, and incident-response telemetry are normalized and field mappings are validated.

·        Elastic detections where endpoint, file, process, network, GitHub, npm, AWS, Azure, GCP, identity, NDR / Network Behavioral Analytics, YARA, artifact, and CI/CD telemetry are normalized into ECS-compatible or locally mapped fields.

·        QRadar correlations where DSM parsing, custom properties, reference sets, reference maps, building blocks, event ordering, offense grouping, and CRE logic are validated.

·        SIGMA-converted detections where backend translation quality, field mappings, sequence support, wildcard behavior, case handling, enrichment-field creation, and local event-source coverage are validated.

·        NDR / Network Behavioral Analytics suspicious egress enrichment where destination baselines, source-role context, approved-destination context, developer / CI/CD role context, and correlation pivots are validated.

·        AWS downstream detections where AWS activity can be mapped to exposed developer or CI/CD identities, source IPs, user agents, accounts, resources, repositories, build jobs, package-execution timelines, and incident-response context.

·        Azure downstream detections where Azure activity can be mapped to exposed developer or CI/CD identities, source IPs, user agents, tenants, subscriptions, resources, repositories, build jobs, package-execution timelines, and incident-response context.

·        GCP downstream detections where GCP activity can be mapped to exposed developer or CI/CD principals, source IPs, user agents, projects, resources, repositories, build jobs, package-execution timelines, and incident-response context.

Ready for Conditional Production Deployment

·        IDE workspace task detections where endpoint telemetry captures IDE parent-child process behavior, working-directory context, task-file context, and follow-on credential or egress behavior.

·        Cloud downstream detections where identity linkage, exposed credential context, source IP continuity, user-agent continuity, and incident-response context are incomplete but sufficient for hunting or lower-severity alerting.

·        NDR / Network Behavioral Analytics detections where rare-destination, source-role, and approved-destination baselines are still maturing but sufficient for enrichment, scoping, and triage.

Ready for Supplemental Triage

·        YARA artifact scanning of extracted package contents, internal npm mirrors, dependency caches, package tarballs, CI/CD workspaces, build artifacts, repository snapshots, quarantined files, and malware triage samples.

·        SBOM, build artifact, container, internal package, release output, and package-cache review.

·        Historical package and artifact review where execution telemetry is incomplete.

Not Selected for Production as Standalone Proof

·        Package presence alone.

·        YARA match alone.

·        NDR / Network Behavioral Analytics finding alone.

·        GitHub access alone.

·        npm registry activity alone.

·        Cloud activity alone.

·        Suspicious egress alone.

·        IDE task-file presence alone.

·        setup.mjs reference alone.

·        Bun execution alone where Bun is approved.

·        Shai-Hulud-style behavior alone as attribution.

Attribution Maturity

Attribution maturity is low to moderate.

The rule set supports detection of behavior consistent with SAP npm package poisoning, Shai-Hulud-style developer credential theft, Mini Shai-Hulud-style lifecycle execution, TeamPCP-style developer supply-chain tradecraft, and adapted IDE workspace-task abuse. It should not be used by itself to attribute activity to a specific adversary, campaign, malware family, infrastructure provider, exploit developer, or named threat group without external evidence and incident-specific validation.

Attribution requires corroborating evidence such as package publication timeline, maintainer account activity, source infrastructure, payload evidence, repository changes, token use, npm activity, GitHub activity, cloud activity, victimology, actor tradecraft, and threat-intelligence reporting.

Maturity Limitations

Primary Maturity Limitations

·        Limited direct visibility into credential theft.

·        Limited direct visibility into exfiltration contents.

·        Limited direct visibility into environment-variable-only secret exposure.

·        Variable developer endpoint telemetry.

·        Variable CI/CD runner telemetry.

·        Variable IDE parent-child process telemetry.

·        Variable file-access telemetry.

·        Variable package-manager log retention.

·        Variable GitHub audit retention.

·        Variable npm audit depth.

·        Variable NDR / Network Behavioral Analytics source-role and process-correlation context.

·        Variable token lineage.

·        Variable identity mapping.

·        Variable cloud identity mapping.

·        Variable process-to-network mapping.

·        Variable artifact retention.

·        Variable internal npm mirror history.

·        Variable package-cache preservation.

·        Variable SBOM and provenance coverage.

·        Variable change-management, SOAR, and incident-response integration.

·        High false-positive potential when detections are deployed without local tuning.

Maturity Improvement Priorities

Priority Improvements

·        Improve endpoint process creation, command-line, file-access, and process-to-network telemetry on developer systems.

·        Improve CI/CD runner telemetry, build job retention, workspace retention, and secret-access visibility.

·        Improve package-manager logging for npm, pnpm, yarn, lifecycle scripts, dependency restoration, and package-cache activity.

·        Improve IDE process-lineage visibility and workspace task-file review for VS Code, Cursor, and related developer tools.

·        Improve GitHub audit logging, token lineage, workflow-change tracking, deploy-key tracking, webhook tracking, OAuth tracking, and repository-change monitoring.

·        Improve npm registry audit logging, token-use visibility, maintainer-change tracking, owner-change tracking, publication tracking, package metadata history, and provenance validation.

·        Improve NDR / Network Behavioral Analytics source-role mapping, developer egress baselines, CI/CD egress baselines, approved-destination baselines, rare-destination detection, and SIEM correlation pivots.

·        Improve AWS, Azure, and GCP identity mapping for developer and CI/CD credentials.

·        Improve DNS, proxy, firewall, TLS, NetFlow, EDR network, CI/CD egress, cloud egress, and NDR / Network Behavioral Analytics correlation.

·        Improve internal npm mirror retention, dependency-cache retention, package-tarball preservation, artifact-repository retention, SBOM quality, container metadata, and release provenance.

·        Improve YARA scanning scope and known-good package baselines.

·        Improve asset inventory for developer endpoints, CI/CD runners, package-publishing systems, release systems, build systems, internal mirrors, artifact repositories, and cloud-connected workflows.

·        Improve approved workflow baselines for development, CI/CD, package publishing, GitHub automation, npm automation, IDE task usage, developer egress, CI/CD egress, cloud deployment, infrastructure-as-code, security testing, vendor support, managed-service access, break-glass use, and incident response.

·        Test detection logic against realistic benign and suspicious sequences before alert promotion.

Analytical Confidence

Analytical confidence is high for the behavior-led detection model and moderate for environment-specific confirmation.

Confidence is highest when package execution, runtime activity, credential access, local staging, suspicious egress, NDR / Network Behavioral Analytics findings, GitHub activity, npm activity, cloud activity, artifact evidence, and incident-response findings align in sequence.

Confidence is lower when evidence is isolated, telemetry is incomplete, execution cannot be proven, token lineage is unclear, cloud activity cannot be mapped to exposed credentials, egress cannot be tied to a process, NDR / Network Behavioral Analytics findings cannot be tied to local execution, or artifact findings cannot be connected to execution.

Final Intelligence Maturity Assessment

The report’s intelligence maturity is strong for behavior-led detection engineering, strong for executive risk framing, moderate to strong for telemetry-driven operational detection, moderate to strong for SIEM and artifact correlation, moderate to strong for NDR / Network Behavioral Analytics suspicious egress enrichment, moderate for AWS, Azure, and GCP downstream cloud correlation, and low to moderate for attribution.

The S25 through S30 detection model is best used as an implementation-ready threat-to-detection framework for suspicious package-manager execution, runtime bootstrapping, IDE workspace execution where applicable, credential-access behavior, local staging, suspicious egress, NDR / Network Behavioral Analytics enrichment, GitHub activity, npm registry activity, cloud-control-plane activity, and artifact triage. It should not be used as a standalone proof model for credential theft, exfiltration, repository compromise, registry compromise, cloud compromise, downstream artifact compromise, or actor attribution without corroborating telemetry and incident-specific validation.

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, inspect repository-local workspace automation, and confirm that internal mirrors, caches, build outputs, containers, workspace task files, and release artifacts did not preserve or propagate compromise. Remediation must not stop at package removal because the governing risk is install-time execution, IDE-trusted workspace execution, credential exposure, token abuse, package-registry abuse, cloud credential exposure, and downstream software-integrity uncertainty.

Immediate Containment Actions

·        Identify all repositories, developer endpoints, IDE-trusted workspaces, CI/CD jobs, build images, internal npm mirrors, dependency caches, containers, artifacts, and release workflows that referenced affected SAP-related package versions.

·        Freeze or restrict package publishing from identities, workstations, IDE-trusted workspaces, runners, or workflows that installed, opened, cached, mirrored, or evaluated affected package versions until credential exposure is resolved.

·        Remove affected package versions from dependency files, lockfiles, internal mirrors, build caches, dependency caches, and artifact repositories.

·        Inspect repository-local task configuration, including .vscode/tasks.json or equivalent IDE task files, where affected package or project material may have been opened in trusted developer workspaces.

·        Remove hidden, unexpected, unauthorized, downloader, encoded-command, credential-access, or autorun workspace task behavior from repositories, extracted packages, dependency caches, and developer workspaces.

·        Rebuild affected environments from known-good dependency sets rather than reusing potentially exposed caches, workspaces, or build material.

·        Disable or tightly restrict npm lifecycle script execution in high-risk CI/CD workflows where operationally feasible.

·        Restrict or govern IDE workspace task autorun in high-risk developer environments where operationally feasible.

·        Preserve endpoint, CI/CD, GitHub, npm, cloud, identity, DNS, proxy, NDR / Network Behavioral Analytics, artifact, IDE process-lineage, workspace task-file, and repository telemetry before log expiration or runner destruction.

·        Treat exposed privileged developer systems, IDE-trusted workspaces, 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.

·        Rotate credentials from developer endpoints or IDE-trusted workspaces where suspicious workspace task execution, IDE-launched runtime activity, credential access, local staging, or suspicious egress occurred.

·        Invalidate active sessions for exposed developer, maintainer, package-publishing, repository, cloud, 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.

·        Identify developer systems that opened or trusted repositories, extracted packages, package contents, or project material containing .vscode/tasks.json or equivalent IDE task configuration.

·        Review VS Code, Cursor, and related IDE activity for unexpected Node, Bun, Python, shell, PowerShell, curl, wget, npm, package-manager, downloader, archive, or runtime execution launched from project-controlled paths.

·        Review endpoint process lineage for IDE parent processes spawning interpreters, package managers, shells, downloaders, archive tools, or encoded-command behavior.

·        Review file-access telemetry for .npmrc, GitHub tokens, SSH keys, cloud credentials, Kubernetes configuration, Docker credentials, environment files, CI/CD secrets, deployment credentials, and package-registry credentials after package or workspace execution.

·        Review local staging, archive creation, encoded output, encrypted files, temporary files, and suspicious egress following package-manager or IDE-launched runtime behavior.

·        Remove affected package material, suspicious task files, unexpected workspace automation, and cached dependency content from developer systems.

·        Reimage or rebuild developer systems where suspicious execution, credential access, staging, or egress cannot be confidently ruled out.

·        Validate that endpoint EDR coverage, command-line logging, parent-child process telemetry, file-access telemetry, and process-linked network telemetry are enabled on developer systems.

CI/CD and Build Environment Remediation

·        Identify CI/CD jobs, self-hosted runners, managed runners, release workflows, build systems, and package-publishing workflows that installed affected packages.

·        Review build logs, workflow logs, dependency restoration logs, package-install logs, environment-variable exposure, secret injection, and artifact production during the exposure window.

·        Remove affected dependency caches, build caches, package tarballs, container layers, and internal mirror entries.

·        Rebuild runner images, build containers, and release environments from known-good dependency sets.

·        Separate dependency installation from privileged publish, sign, deploy, and release stages.

·        Restrict secret injection into dependency installation jobs.

·        Preserve runner logs, workflow metadata, build artifacts, and dependency-cache evidence before cleanup.

Source-Code and GitHub Remediation

·        Review repositories that referenced, cached, mirrored, or built affected package versions.

·        Review repository-local task files, including .vscode/tasks.json or equivalent IDE task configuration, for hidden, unexpected, autorun, folder-open, downloader, encoded-command, runtime, or credential-access behavior.

·        Remove unauthorized repository-local automation, suspicious workspace task configuration, hidden autorun behavior, and unexpected IDE task definitions.

·        Review GitHub repository creation, workflow changes, deploy-key changes, webhook changes, OAuth activity, GitHub App activity, token activity, branch protection changes, repository visibility changes, and unusual API activity after exposure.

·        Confirm that repository changes, workflow changes, and task-file changes are explained by approved development activity.

·        Require owner review for source-code platform changes that occurred during the exposure window.

npm Registry and Package-Publishing Remediation

·        Review npm token creation, validation, use, revocation, package publication, version changes, maintainer changes, ownership changes, access changes, provenance changes, metadata changes, and lifecycle-script changes after exposure.

·        Freeze or restrict package publishing for exposed identities and workflows until credential rotation and registry review are complete.

·        Reissue package-publishing credentials using least privilege and short-lived credential models where available.

·        Validate package provenance, publishing workflow integrity, and maintainer account security.

·        Confirm no unauthorized packages, versions, lifecycle scripts, or metadata changes were introduced after exposure.

Cloud, Secrets, and Deployment Remediation

·        Review AWS, Azure, and GCP audit logs for unusual identity use, secret access, service-account changes, access-key changes, role changes, policy changes, container registry activity, storage activity, deployment-path activity, and control-plane activity tied to exposed systems or identities.

·        Revoke and rotate exposed or potentially exposed cloud credentials.

·        Review deployment workflows that used affected developer systems, CI/CD runners, repository credentials, package-publishing identities, or cloud identities.

·        Validate secret-manager, key-vault, container-registry, artifact-registry, and deployment-system access during the exposure window.

·        Confirm cloud activity is explainable by approved automation, approved release workflows, or validated incident-response activity.

Artifact, Mirror, and Release Remediation

·        Review internal npm mirrors, dependency caches, package tarballs, build images, containers, software bills of materials, artifact repositories, and release outputs for affected packages or suspicious workspace task files.

·        Review build artifacts and release outputs generated during the exposure window.

·        Validate artifact provenance, source commit, dependency set, build image, runner identity, workflow identity, and signing context.

·        Quarantine or rebuild artifacts where package exposure, workspace task execution, credential access, or suspicious egress cannot be confidently excluded.

·        Confirm customer-facing release artifacts were not produced from exposed dependency sets or compromised workspace automation.

Remediation Disposition

Remediation should treat package removal, repository-local task inspection, IDE workspace review, credential rotation, CI/CD validation, GitHub review, npm registry review, cloud-control-plane review, NDR / Network Behavioral Analytics scoping, and artifact assurance as one connected response path. The organization should not declare remediation complete until affected packages, suspicious workspace task files, exposed credentials, downstream platform activity, and release artifacts have been reviewed with sufficient telemetry confidence.

S32 — Security Control Recommendations

Security Control Recommendation Objective

Reduce future exposure to trusted-dependency compromise, IDE workspace task abuse, developer credential theft, CI/CD secret exposure, package-registry abuse, cloud credential misuse, and downstream software-integrity uncertainty. Controls should reduce both initial execution risk and downstream propagation risk.

Dependency and Package-Control Recommendations

·        Pin critical dependencies and require lockfile review for SAP-related npm projects.

·        Require package provenance review for critical dependencies.

·        Monitor package lifecycle scripts and alert on new or modified preinstall, install, postinstall, prepare, prepack, or publish hooks.

·        Gate newly published package versions before synchronization into internal mirrors.

·        Require review of package contents before high-risk dependency updates enter privileged build or release workflows.

·        Scan package contents, extracted repositories, dependency caches, and package tarballs for repository-local IDE task files, including .vscode/tasks.json or equivalent workspace automation.

·        Maintain emergency denylisting, quarantine, mirror purge, and cache purge capability for compromised packages and versions.

·        Require SBOM generation and dependency inventory for builds involving SAP-related packages.

Developer Endpoint Control Recommendations

·        Require endpoint EDR coverage for developer workstations, release engineering systems, package-publishing systems, and build systems.

·        Enable full process creation, command-line, parent-child process, working-directory, file-access, and process-linked network telemetry on developer endpoints.

·        Monitor package managers spawning unexpected runtimes, shells, downloaders, archive utilities, Python, PowerShell, or encoded commands.

·        Monitor IDE parent processes, including VS Code, Cursor, and related developer tools, spawning unexpected Node, Bun, Python, shell, PowerShell, curl, wget, npm, package-manager, downloader, archive, or runtime activity from project-controlled paths.

·        Enforce workspace trust policy controls for VS Code, Cursor, and related IDEs.

·        Restrict or govern automatic task execution from repository-local workspace configuration.

·        Alert on hidden, unexpected, or newly introduced .vscode/tasks.json behavior in repositories that handle sensitive code, credentials, package publishing, CI/CD, or cloud deployment.

·        Tag developer endpoints by role, repository access, package-publishing authority, release authority, and cloud access.

·        Remove unnecessary long-lived GitHub, npm, SSH, cloud, Kubernetes, Docker, deployment, and CI/CD credentials from developer endpoints.

·        Use credential managers, short-lived access, device-bound tokens, and conditional access for developer workflows.

CI/CD and Build Security Recommendations

·        Separate dependency installation from privileged publish, sign, deploy, and release stages.

·        Avoid injecting package-publishing, cloud deployment, signing, or production secrets into dependency installation jobs.

·        Require minimal CI/CD token permissions.

·        Restrict CI/CD runner egress.

·        Retain package-install logs, runner logs, workflow logs, build logs, and artifact records.

·        Rebuild runner images and build containers from known-good dependency sets after exposure.

·        Govern build caches and dependency caches as security-sensitive assets.

·        Require approval gates for package publishing, signing, and deployment.

·        Validate whether CI/CD workflows can ingest repository-local IDE task files or project automation that may influence build behavior.

Source-Code Platform Control Recommendations

·        Require CODEOWNERS or equivalent review for CI/CD workflow changes.

·        Require review for repository-local task configuration that can execute code, including .vscode/tasks.json or equivalent IDE task files.

·        Monitor repository creation, workflow modification, deploy-key changes, webhook changes, OAuth grants, GitHub App changes, secret changes, branch protection changes, and repository visibility changes.

·        Require approval for changes to repository-local automation that can launch interpreters, package managers, downloaders, shells, or deployment tooling.

·        Review repository permissions and remove stale or excessive access.

·        Govern deploy keys, webhooks, GitHub Apps, OAuth applications, personal access tokens, and fine-grained tokens.

·        Alert on source-code platform activity occurring after suspicious package execution, IDE-launched runtime activity, credential access, suspicious egress, or package-registry activity.

npm Registry and Publishing Control Recommendations

·        Use trusted publishing or short-lived publishing credentials where available.

·        Require strong authentication for maintainers and publishing identities.

·        Use dedicated release automation identities with least privilege.

·        Require package publication approval gates.

·        Monitor maintainer changes, owner changes, access changes, package metadata changes, lifecycle-script changes, provenance changes, token creation, token validation, token use, and token revocation.

·        Maintain emergency publishing freeze procedures.

·        Separate package publication authority from routine developer dependency installation.

Cloud and Secrets Control Recommendations

·        Use workload identity federation or short-lived cloud credentials where feasible.

·        Monitor secret-manager, key-vault, IAM, service-account, role, access-key, policy, container-registry, artifact-registry, storage, and deployment-path activity.

·        Enforce conditional access and MFA for privileged identities.

·        Reduce long-lived developer and CI/CD cloud credentials.

·        Require cloud audit log retention sufficient for post-exposure investigation.

·        Maintain emergency key rotation and deployment credential revocation procedures.

·        Correlate cloud activity with exposed developer endpoints, CI/CD jobs, repository activity, npm registry activity, suspicious egress, and incident-response context.

Network and Egress Control Recommendations

·        Centralize DNS, proxy, firewall, TLS, EDR network, CI/CD egress, cloud egress, and NDR / Network Behavioral Analytics telemetry.

·        Use NDR / Network Behavioral Analytics for suspicious egress enrichment, developer-service misuse review, rare-destination analysis, source-role analysis, post-exposure scoping, and SIEM correlation.

·        Monitor upload-like traffic after package installation, IDE-launched runtime behavior, credential access, or local staging.

·        Monitor unusual access to GitHub API, webhook services, raw-content services, paste-like services, file-sharing services, cloud-storage services, package repositories, and unfamiliar external destinations.

·        Baseline developer and CI/CD egress by role, repository, runner, build image, source network, approved destination, and expected workflow.

·        Do not treat network or NDR / Network Behavioral Analytics findings as standalone proof of credential theft or exfiltration.

Security Control Recommendation Disposition

Security controls should treat dependency intake, developer endpoint protection, IDE workspace trust, CI/CD secret exposure, source-code platform governance, package-registry governance, cloud credential control, NDR / Network Behavioral Analytics enrichment, and artifact assurance as one connected trust system. The control model should prevent trusted package or workspace handling from becoming unobserved execution on systems that hold privileged credentials.

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, governing IDE workspace trust, increasing developer and CI/CD visibility, and strengthening software release assurance.

Strategic Improvement 1 — Treat Developer Environments as High-Value Attack Surfaces

Developer endpoints, IDE-trusted workspaces, release systems, package-publishing systems, and build systems should be managed as privileged environments because they may hold source-code access, package-registry credentials, cloud credentials, deployment secrets, artifact access, and local repository automation that can execute code. Security strategy should move beyond workstation malware prevention and include developer credential governance, package-install monitoring, IDE workspace trust, task autorun governance, runtime baselining, dependency-cache control, and release-path assurance.

Required Improvement

·        Classify developer workstations, release hosts, package-publishing systems, IDE-trusted workspaces, and CI/CD runners as high-value assets.

·        Apply stronger logging, endpoint protection, credential handling, network controls, and workspace trust controls to those systems.

·        Remove unnecessary long-lived credentials from developer endpoints.

·        Restrict or govern repository-local IDE task execution.

·        Require evidence-based validation after dependency compromise or suspicious workspace automation 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.

·        Validate that CI/CD workflows cannot silently inherit unsafe repository-local automation.

Strategic Improvement 3 — Build Package and Workspace Trust Gates

Organizations should establish trust gates for high-risk ecosystems, critical development stacks, package contents, and repository-local automation. Newly published package versions, lifecycle script changes, maintainer changes, dependency updates, and IDE task configuration changes should be reviewed before they reach privileged developer, build, or release environments.

Required Improvement

·        Gate newly published package versions before synchronization into internal mirrors.

·        Flag package lifecycle script additions or changes.

·        Flag repository-local IDE task configuration, including .vscode/tasks.json or equivalent files, when introduced or modified in sensitive repositories.

·        Require metadata, maintainer, provenance, package-content, and workspace automation review for critical dependencies.

·        Maintain emergency quarantine workflows for compromised package versions, suspicious workspace task files, and affected dependency caches.

Strategic Improvement 4 — Normalize Cross-Control-Plane Telemetry

Supply-chain incidents cross endpoint, IDE, CI/CD, source-code, package-registry, cloud, identity, network, and artifact layers. The organization should normalize telemetry around shared pivots such as user, host, repository, workspace, runner, package, token, source IP, user agent, cloud identity, NDR / Network Behavioral Analytics context, and artifact.

Required Improvement

·        Normalize endpoint, IDE, CI/CD, GitHub, npm, cloud, identity, artifact, DNS, proxy, NDR / Network Behavioral Analytics, and network logs into a common investigation model.

·        Preserve package-install events, IDE parent-child process events, workspace task-file events, workflow events, token events, cloud events, network events, and artifact events long enough for post-exposure investigation.

·        Build correlation paths from package installation and workspace opening to runtime execution, credential access, staging, egress, token use, cloud activity, and artifact production.

·        Validate detection logic against real developer, IDE, CI/CD, and release 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, workspace automation, 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, workspace automation context, and artifact lineage.

·        Require artifact review when dependency exposure, workspace task execution, or suspicious developer endpoint activity overlaps with release windows.

·        Maintain a customer assurance playbook for software supply-chain exposure.

Strategic Defensive Improvement Disposition

Strategic improvement should expand the definition of developer trust. Developer trust is not limited to package managers and CI/CD runners. It also includes IDE configuration, workspace trust, repository-local task automation, local developer credentials, source-code platform authority, package-publishing authority, and downstream release integrity. Organizations that govern only package installation but ignore IDE workspace trust remain exposed to adjacent developer supply-chain execution paths.

S34 — Defensive Architecture Overview

Figure 5

Defensive Architecture Objective

Define a layered defensive architecture that reduces exposure from trusted-dependency compromise, IDE workspace task abuse, developer credential theft, CI/CD secret exposure, package-registry abuse, cloud credential misuse, suspicious egress, and downstream software-integrity uncertainty.

Layer 1 — Dependency Intake and Package Trust

This layer controls which dependencies, package versions, package contents, lifecycle scripts, and repository-local automation are allowed into developer, CI/CD, and release environments.

Required Controls

·        Dependency inventory.

·        Lockfile governance.

·        Package provenance validation.

·        Package lifecycle script review.

·        Package-content inspection.

·        Repository-local task-file inspection, including .vscode/tasks.json or equivalent IDE task configuration.

·        Maintainer and metadata monitoring.

·        SBOM generation and dependency inventory.

·        Internal mirror approval gates.

·        Emergency package denylisting and cache purge capability.

·        Quarantine workflows for suspicious package contents or workspace automation.

Layer 2 — Developer Endpoint Protection

This layer detects and constrains malicious package behavior, IDE-launched runtime activity, credential access, local staging, and suspicious egress on developer workstations and release systems.

Required Controls

·        Endpoint process telemetry.

·        Full command-line logging.

·        Parent-child process lineage.

·        IDE parent-process telemetry for VS Code, Cursor, and related developer tools.

·        Working-directory and workspace-path context.

·        File access telemetry for sensitive credential paths.

·        Runtime baselining for Bun, Node, shell, PowerShell, curl, wget, archive utilities, npm, package managers, and Python.

·        Alerting on IDE-spawned interpreters, shells, package managers, downloaders, archive utilities, or encoded-command behavior from project-controlled paths.

·        Workspace trust policy enforcement.

·        Task autorun governance.

·        Repository-local .vscode/tasks.json review.

·        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 and prevents dependency restoration from automatically exposing privileged secrets.

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.

·        Validation that repository-local automation does not silently alter build or release behavior.

Layer 4 — Source-Code Platform Governance

This layer controls GitHub or equivalent source-code platform abuse and governs repository-local automation that can become an execution path.

Required Controls

·        Workflow path protection.

·        CODEOWNERS or equivalent approval for CI/CD workflow changes.

·        CODEOWNERS or equivalent approval for repository-local IDE task configuration in sensitive repositories.

·        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, task-file modification, secret change, and visibility change alerting.

·        Review of .vscode/tasks.json or equivalent workspace task files when package compromise or developer endpoint exposure is suspected.

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.

·        Lifecycle-script change monitoring.

·        Token creation, validation, use, and revocation monitoring.

·        Emergency publishing freeze procedures.

Layer 6 — Cloud, Secrets, and Deployment Control Plane

This layer reduces the risk that exposed or stolen credentials become 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.

·        Correlation of cloud activity with exposed developer endpoints, CI/CD jobs, repositories, package activity, IDE-launched runtime activity, and incident-response context.

Layer 7 — Network and Egress Control

This layer detects and restricts suspicious outbound transfer.

Required Controls

·        DNS, proxy, firewall, TLS, EDR network, CI/CD egress, cloud egress, and NDR / Network Behavioral Analytics telemetry.

·        Process-attributed egress where available.

·        CI/CD runner egress allowlisting.

·        Developer endpoint egress baselining.

·        Monitoring for upload-like traffic after package installation, IDE-launched runtime activity, credential access, or local staging.

·        Monitoring for GitHub API, webhook, raw-content, paste-like, file-sharing, cloud-storage, npm-related, package repository, and unfamiliar destinations after credential access.

·        Destination novelty and source-role analysis.

·        SIEM correlation for NDR / Network Behavioral Analytics findings.

Layer 8 — Artifact and Release Assurance

This layer validates whether compromised dependencies, workspace automation, or exposed build workflows 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.

·        Workspace task-file review for build inputs and repository snapshots.

·        Customer-facing release validation after exposure.

Defensive Architecture Disposition

The defensive architecture must treat dependency installation, IDE workspace trust, 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 IDE-launched runtime activity, credential reuse, registry abuse, cloud-control-plane activity, 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, IDE workspace task abuse, developer credential theft, CI/CD secret exposure, package-registry abuse, cloud credential misuse, 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.

·        Scan package contents and extracted package material for repository-local IDE task configuration, including .vscode/tasks.json or equivalent task files.

Developer Endpoint Hardening

·        Enable full process creation, command-line, parent-child lineage, working-directory, 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.

·        Alert on VS Code, Cursor, or related IDE parent processes spawning unexpected Node, Bun, Python, shell, PowerShell, curl, wget, npm, package-manager, downloader, archive, or encoded-command behavior from project-controlled paths.

·        Enforce VS Code, Cursor, and related IDE workspace trust policies.

·        Restrict automatic task execution from repository-local workspace configuration.

·        Require review of .vscode/tasks.json or equivalent IDE task files in sensitive repositories and exposed workspaces.

·        Block or alert on hidden, unexpected, folder-open, autorun, downloader, encoded-command, credential-access, or suspicious runtime behavior in workspace task files.

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

·        Tag developer endpoints by repository access, package-publishing authority, release authority, cloud access, and CI/CD access.

CI/CD Hardening

·        Separate dependency restoration from package publishing, signing, deployment, and release stages.

·        Disable lifecycle scripts where dependency installation does not require them.

·        Restrict injected secrets during dependency installation jobs.

·        Use least-privilege CI/CD tokens.

·        Use short-lived credentials for release automation.

·        Rebuild runners and build images from known-good baselines after exposure.

·        Restrict runner egress to approved destinations.

·        Preserve package-install logs, runner logs, build logs, workflow logs, and artifact records.

·        Review whether repository-local automation can influence build or release behavior.

GitHub and Source-Code Platform Hardening

·        Require approval for CI/CD workflow changes.

·        Require approval for repository-local workspace task-file changes in sensitive repositories.

·        Protect workflow paths, release paths, and task-configuration paths.

·        Monitor deploy keys, webhooks, OAuth grants, GitHub Apps, repository secrets, branch protections, repository visibility, and unusual API activity.

·        Monitor .vscode/tasks.json or equivalent task-file additions, deletions, or modifications in high-value repositories.

·        Alert when task-file changes introduce autorun behavior, hidden presentation behavior, downloader activity, encoded commands, interpreter launches, package-manager execution, or credential-path references.

·        Review repository access for users, automation identities, and package-publishing identities after dependency exposure.

npm Publishing Hardening

·        Use trusted publishing or short-lived publishing credentials.

·        Require strong authentication for package maintainers.

·        Use dedicated automation identities for package publication.

·        Separate maintainer activity from routine development activity.

·        Monitor token creation, token validation, token use, token revocation, package publication, maintainer changes, ownership changes, access changes, metadata changes, lifecycle-script changes, and provenance changes.

·        Maintain emergency package publication freeze procedures.

·        Require provenance review before restoring normal publishing workflows after exposure.

Cloud and Secret Hardening

·        Replace long-lived developer and CI/CD cloud keys with workload identity federation or short-lived credentials where feasible.

·        Monitor IAM, service-account, role, policy, access-key, secret-manager, key-vault, container-registry, artifact-registry, storage, and deployment activity.

·        Enforce conditional access and MFA for privileged cloud identities.

·        Limit cloud credentials available to developer endpoints and dependency installation jobs.

·        Rotate cloud credentials after suspicious package execution, IDE-launched runtime execution, credential access, or suspicious egress.

·        Correlate cloud activity with exposed developer systems, CI/CD jobs, GitHub activity, npm activity, NDR / Network Behavioral Analytics findings, and incident-response context.

Network and Egress Hardening

·        Centralize DNS, proxy, firewall, TLS, EDR network, CI/CD egress, cloud egress, and NDR / Network Behavioral Analytics telemetry.

·        Baseline developer endpoint and CI/CD runner egress by role, repository, workflow, build image, package ecosystem, and approved destination.

·        Alert on upload-like traffic after package installation, IDE-launched runtime activity, credential access, or local staging.

·        Alert on rare or newly observed destinations after package-manager, runtime, IDE, credential-access, or staging behavior.

·        Monitor traffic to GitHub API, webhooks, raw-content services, paste-like services, file-sharing services, cloud-storage services, npm-related destinations, and unfamiliar infrastructure.

·        Use NDR / Network Behavioral Analytics for suspicious egress enrichment, scoping, rare-destination review, and SIEM correlation.

·        Do not treat NDR / Network Behavioral Analytics findings as standalone proof of credential theft or exfiltration.

Artifact and Release Hardening

·        Require artifact provenance, signing, verification, and build-to-source traceability.

·        Require SBOM records for high-value builds.

·        Track source commit, dependency set, build image, runner identity, workflow identity, signer, and artifact lineage.

·        Review internal mirrors, dependency caches, package tarballs, containers, build outputs, and release artifacts after package exposure.

·        Review repository snapshots and build inputs for workspace task files that may have influenced developer or release behavior.

·        Quarantine or rebuild artifacts when affected dependencies, suspicious workspace automation, credential access, suspicious egress, or release-path uncertainty overlaps with build or release windows.

·        Maintain customer assurance procedures for software supply-chain exposure.

Security Hardening Disposition

Hardening should reduce the chance that trusted package installation, trusted workspace opening, repository-local task automation, or dependency restoration becomes unobserved execution on systems with privileged credentials. The strongest hardening posture combines package trust gates, IDE workspace trust controls, developer endpoint telemetry, CI/CD secret separation, package-publishing governance, cloud credential minimization, NDR / Network Behavioral Analytics enrichment, and artifact assurance into one software supply-chain control model.

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

This section assesses confidence in the intelligence judgments, behavioral alignment, detection assumptions, and amendment-specific conclusions used in this report. Confidence is based on the strength of observed tradecraft, public reporting alignment, technical behavior consistency, telemetry requirements, and the degree of local validation required before making compromise-specific conclusions.

Overall Confidence

Confidence is high that the JFrog-reported chain reflects developer supply-chain credential-theft tradecraft involving trusted package ecosystems, developer tooling, local execution paths, credential exposure risk, and downstream source-code, package-registry, or cloud impact potential.

Confidence is moderate that the same tradecraft directly applies to SAP-related npm exposure unless local telemetry validates comparable behavior, including affected package installation, lifecycle script execution, setup.mjs or loader-style execution, IDE-launched runtime activity, credential-path access, suspicious egress, GitHub activity, npm registry activity, cloud activity, or artifact impact.

High-Confidence Judgments

·        Developer supply-chain compromise remains a credible threat model for SAP-related npm exposure because the affected trust path involves package installation, developer environments, CI/CD workflows, and credentials that may support source-code, package-registry, or cloud access.

·        The JFrog-reported chain is strongly aligned with broader developer credential-theft tradecraft because it emphasizes trusted package handling, local execution, developer environment exposure, and downstream credential-risk conditions.

·        Detection should focus on behavior sequences rather than package names, actor labels, infrastructure, or static indicators alone.

·        Package presence alone is not sufficient to confirm compromise.

·        YARA matches alone are not sufficient to confirm execution, credential theft, exfiltration, registry compromise, repository compromise, cloud compromise, downstream compromise, or attribution.

·        NDR / Network Behavioral Analytics findings alone are not sufficient to confirm execution, credential theft, exfiltration, registry compromise, repository compromise, cloud compromise, downstream compromise, or attribution.

·        AWS, Azure, and GCP detections provide downstream cloud credential-abuse correlation only and do not detect initial npm package execution.

·        IDE workspace trust, repository-local task automation, and developer endpoint visibility are material to the amended detection and control model.

Moderate-Confidence Judgments

·        Direct applicability to SAP-related npm exposure is moderate unless local telemetry confirms comparable execution behavior.

·        IDE workspace task execution should be treated as a relevant adapted coverage path when repository-local task files, trusted workspaces, IDE parent-child process telemetry, or IDE-launched runtime behavior are observed.

·        Suspicious egress increases confidence when it occurs after package-manager execution, IDE-launched runtime activity, credential access, or local staging, but it does not independently prove credential theft or exfiltration.

·        GitHub or npm registry activity increases confidence when it follows suspicious local execution or credential-access behavior, but it does not independently prove credential theft, repository compromise, registry compromise, or propagation.

·        Cloud-control-plane activity increases confidence when it maps to exposed developer or CI/CD identities, source IPs, user agents, repositories, workflows, or incident-response context, but it does not independently prove SAP npm compromise.

Low-Confidence or Unsupported Judgments

·        Attribution to a specific adversary, campaign, malware family, infrastructure operator, or named threat group is not supported without additional corroborating evidence.

·        Successful credential theft is not supported without credential-access telemetry, token use, suspicious downstream activity, or incident-response validation.

·        Successful exfiltration is not supported without correlated staging, process-linked egress, destination context, transfer evidence, or incident-response validation.

·        GitHub compromise is not supported by GitHub activity alone.

·        npm registry compromise is not supported by npm activity alone.

·        Cloud compromise is not supported by cloud activity alone.

·        Downstream artifact compromise is not supported without artifact, provenance, build, repository, or release validation.

Confidence Drivers

·        Publicly reported developer supply-chain credential-theft tradecraft.

·        Behavioral similarity between package execution, developer environment exposure, credential-risk behavior, suspicious egress, repository activity, registry activity, and cloud downstream risk.

·        Availability of behavior-led detection logic across NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA, YARA, AWS, Azure, and GCP.

·        Availability of correlation paths across endpoint, CI/CD, IDE, GitHub, npm registry, cloud, identity, network, artifact, and incident-response telemetry.

·        Stronger confidence when multiple telemetry sources align within bounded time windows.

Confidence Constraints

·        Local compromise cannot be inferred from package exposure alone.

·        SAP-specific applicability requires local validation of package installation, execution, workspace trust, credential access, suspicious egress, source-code activity, package-registry activity, cloud activity, or artifact impact.

·        Managed CI/CD runners, ephemeral containers, incomplete endpoint telemetry, limited IDE process lineage, incomplete GitHub audit records, incomplete npm token lineage, weak cloud identity mapping, incomplete NDR / Network Behavioral Analytics context, and limited artifact retention may reduce confidence.

·        Encrypted egress, common developer-service traffic, approved automation, approved IDE tasks, approved package-publishing workflows, approved cloud deployments, and approved security testing may create false-positive pressure.

·        Attribution remains constrained unless supported by infrastructure, payload, token-use, publication, victimology, or external intelligence evidence.

Local Validation Requirements

·        Confirm whether affected SAP-related npm package versions were present in dependency manifests, lockfiles, package caches, internal npm mirrors, package tarballs, build images, containers, SBOM records, or release artifacts.

·        Confirm whether affected package versions were installed or restored during the exposure window.

·        Confirm whether npm lifecycle scripts were enabled during installation or CI/CD execution.

·        Confirm whether setup.mjs, loader-style JavaScript, Bun, Node, shell, PowerShell, Python, curl, wget, archive tools, or encoded-command behavior executed from package, cache, dependency, workspace, temporary, CI/CD, or build paths.

·        Confirm whether VS Code, Cursor, or related IDE processes launched unexpected runtimes, shells, package managers, downloaders, archive utilities, or encoded-command behavior from project-controlled paths.

·        Confirm whether .vscode/tasks.json or equivalent repository-local task configuration contained hidden, unexpected, autorun, downloader, encoded-command, runtime, or credential-access behavior.

·        Confirm whether credential paths, environment files, GitHub tokens, npm tokens, SSH keys, cloud credentials, Kubernetes configuration, Docker credentials, CI/CD secrets, package-registry credentials, or deployment credentials were accessed after suspicious execution.

·        Confirm whether local staging, encoded output, encrypted files, archives, temporary files, or short-lived files appeared after credential access.

·        Confirm whether NDR / Network Behavioral Analytics, DNS, proxy, firewall, TLS, NetFlow, or EDR network telemetry shows suspicious egress after package-manager, runtime, IDE, credential-access, or staging behavior.

·        Confirm whether GitHub, npm registry, AWS, Azure, or GCP activity occurred after exposure and maps to exposed identities, systems, repositories, tokens, source IPs, user agents, workflows, cloud principals, or incident-response context.

·        Confirm whether YARA, artifact review, SBOM review, internal mirror review, dependency-cache review, package-tarball review, container review, or release review identifies suspicious package or workspace automation artifacts.

Analytic Confidence Conclusion

The amendment has high confidence as a developer supply-chain credential-theft tradecraft update and moderate confidence as a direct SAP-specific applicability update until local telemetry validates comparable behavior. The correct analytic posture is to treat the JFrog chain as a high-value behavioral comparison and detection-hardening driver, not as standalone proof that SAP-related npm exposure resulted in execution, credential theft, exfiltration, repository compromise, registry compromise, cloud compromise, downstream compromise, or attribution.

S39 — Economic Impact & Organizational Exposure

npm package poisoning and Shai-Hulud-style developer credential theft expand organizational exposure by creating uncertainty over whether a developer endpoint, source-code repository, CI/CD workflow, package-publishing identity, package namespace, dependency installation, package import, internal mirror, build image, release artifact, cloud environment, or customer-facing software-delivery path was compromised; whether GitHub, npm, SSH, cloud, deployment, or automation credentials were exposed; whether unauthorized package versions were published or installed; and whether repository modification, workflow abuse, malicious lifecycle execution, import-time execution, credential reuse, artifact tampering, or downstream compromise followed.

The governing risk is not limited to one SAP-related, Jscrambler, Joyfill, or other npm package, npm namespace, malicious version, loader file, runtime, workflow, token, hash, domain, campaign, actor, or public incident. The material question is whether adversaries converted developer-endpoint access or trusted package-distribution authority into repository control, workflow manipulation, publishing-token theft, unauthorized package publication, install-time or import-time execution, developer or CI/CD credential exposure, cloud activity, poisoned build outputs, or broader software-integrity compromise before containment.

Economic exposure increases when affected development environments support centralized CI/CD, package publishing, cloud deployment, artifact signing, internal package mirrors, customer-facing releases, SAP development, AI application development, regulated services, proprietary source code, privileged identities, or broadly connected enterprise systems. Exposure is highest when defenders cannot join the initiating developer, repository, workflow, token, registry, package installation, or package-import activity to the resulting package publication, dependency installation, lifecycle execution, import-time execution, credential access, network session, cloud action, artifact creation, or downstream release event.

Estimated Economic Exposure

Estimated exposure should be treated as scenario-based rather than fixed. The most defensible enterprise estimate depends on whether activity remains limited to package presence, blocked installation, prevented lifecycle execution, internal mirror retention, or focused investigation; progresses into developer-workstation compromise, repository access, workflow modification, publishing-token exposure, malicious package installation, credential access, or constrained downstream reach; or results in broad source-code exposure, cloud compromise, unauthorized package publication, poisoned release artifacts, customer impact, regulatory exposure, or prolonged disruption to software-delivery operations.

Economic exposure grows when the organization cannot determine which developer systems were compromised, which SSH keys or tokens were exposed, whether repository write access was abused, whether CI/CD workflows accessed or exfiltrated secrets, which package versions were published or installed, whether lifecycle hooks or malicious package code executed, whether credentials were reused, whether internal mirrors or caches retained malicious versions, and whether repository, workflow, registry, cloud, artifact, and downstream software trust can be restored.

Low Impact Scenario

Estimated $250K–$1M

This scenario applies when rapid investigation confirms that exposure was limited to package presence, lockfile or SBOM references, internal mirror or cache retention, blocked installation, prevented lifecycle execution, or a small number of non-privileged development systems without evidence of credential access, repository abuse, workflow modification, unauthorized publication, suspicious egress, cloud activity, artifact impact, or downstream compromise.

Available evidence supports a failed, prevented, contained, approved, or non-impacting event. Response remains limited to dependency scoping, package removal, cache and mirror cleanup, focused endpoint review, narrow credential validation, workflow comparison, logging improvement, short-term monitoring, and executive assurance that privileged developer, CI/CD, package-publishing, cloud-connected, and customer-facing release environments were not materially affected.

Moderate Impact Scenario

Estimated $1.5M–$8M

This scenario applies when confirmed or strongly suspected activity affects one or more developer workstations, repositories, workflows, publishing identities, package namespaces, CI/CD runners, build environments, dependency caches, internal mirrors, SAP development environments, AI development environments, or release systems and produces repository access, workflow modification, publishing-token exposure, malicious package publication, lifecycle execution, credential access, local staging, suspicious egress, or constrained downstream reach.

Evidence may include compromise of a developer workstation containing GitHub SSH material or publishing credentials; unauthorized repository write access; creation or modification of a GitHub Actions workflow; workflow access to an npm publishing token; publication of unapproved package versions; package-manager execution of a preinstall or related lifecycle hook; malicious package-code execution when a command-line tool is run; suspicious runtime activity; credential discovery; or abnormal GitHub, npm, cloud, network, cache, mirror, build, or artifact activity.

Response may require developer-system isolation, source-code and workflow review, token revocation, credential rotation, GitHub and npm audit review, CI/CD validation, package and namespace remediation, dependency-cache cleanup, internal mirror review, build-image validation, artifact provenance review, enterprise hunting, legal or compliance assessment, customer-assurance preparation, executive reporting, and extended post-remediation monitoring.

High Impact Scenario

Estimated $10M–$75M+

This scenario applies when confirmed or strongly suspected developer-endpoint or software-supply-chain compromise becomes an enterprise-impact event involving broad source-code access, durable repository control, privileged GitHub or npm credential exposure, CI/CD workflow compromise, unauthorized publication across multiple packages or namespaces, cloud or deployment access, artifact-signing exposure, poisoned build outputs, customer-facing release impact, regulated-data exposure, ransomware enablement, destructive activity, or widespread disruption to software-delivery operations.

The organization may need to treat affected developer workstations, SSH keys, GitHub identities, repositories, workflows, publishing tokens, package namespaces, CI/CD runners, build systems, dependency caches, internal mirrors, cloud identities, container registries, release artifacts, deployment paths, customer environments, and dependent business processes as exposed or unreliable until evidence proves otherwise.

Response may require emergency suspension of package publication and software releases, developer and CI/CD isolation, enterprise credential and session invalidation, repository and workflow reconstruction, source-code review, cloud containment, internal mirror and cache purging, artifact rebuilding, provenance and signing validation, downstream customer or partner assessment, privacy and regulatory escalation, cyber-insurance engagement, communications planning, executive and board reporting, and formal restoration of developer, repository, workflow, registry, cloud, artifact, and release trust.

Annualized Risk Exposure

Estimated annualized exposure of $3M–$20M+ for materially exposed enterprise environments where software development, centralized CI/CD, package publishing, cloud deployment, artifact signing, internal package mirrors, SAP development, AI application development, privileged developer identities, or customer-facing software releases support normal business operations.

Exposure may exceed $10M–$75M+ when compromise results in durable repository access, widespread credential misuse, unauthorized package publication, CI/CD workflow abuse, cloud-control-plane access, source-code exposure, poisoned build outputs, customer-facing software-integrity uncertainty, prolonged release suspension, regulatory review, litigation, communications response, or board-level intervention.

Operational Dependency

Operational dependency is high where software development, package restoration, source-code management, CI/CD automation, package publishing, cloud deployment, container creation, artifact signing, internal package mirrors, release engineering, SAP application development, AI application development, or customer-facing software delivery support business-critical operations.

One affected developer workstation, SSH key, repository identity, workflow, npm token, package namespace, CI/CD runner, internal mirror, build image, or release workflow can create broad investigation and recovery requirements when multiple products, customers, business units, repositories, packages, or dependent services rely on the same development and publishing trust path.

Dependency increases when the affected environment cannot be suspended, isolated, rebuilt, rotated, or disconnected from repositories, registries, cloud services, deployment platforms, artifact stores, customer environments, or internal systems without disrupting essential software-delivery functions.

Control Trust

Control trust is reduced when the organization cannot prove that developer endpoint activity, repository access, workflow creation and modification, secret use, package-manager behavior, package publication, lifecycle-script execution, runtime execution, credential access, outbound transfer, cloud activity, internal mirror synchronization, build-image creation, artifact signing, and release promotion remained authorized during the exposure window.

Trust is further reduced when malicious activity occurs through an expected developer identity, approved GitHub SSH key, legitimate repository, normal GitHub Actions workflow, authorized npm publishing account, trusted package namespace, standard package manager, approved CI/CD runner, or normal release path, or when unexplained activity cannot be reconciled with authorized development, release engineering, package recovery, security testing, or incident response.

Removing malicious package versions, deleting a workflow, revoking one token, replacing one SSH key, publishing a clean version, or rebuilding one developer system reduces future exposure but does not independently prove that pre-remediation repository access, token exfiltration, package publication, lifecycle execution, malicious CLI execution, credential theft, cached package retention, artifact impact, or downstream activity did not occur.

Visibility Confidence

Visibility confidence is highest when complete developer endpoint telemetry, process lineage, command-line logging, file-access history, GitHub audit events, SSH-key use, repository changes, GitHub Actions workflow history, CI/CD job logs, secret-access evidence, npm token events, package-publication records, package-manager logs, cloud audit activity, identity events, DNS and proxy logs, process-attributed network telemetry, internal mirror records, package-cache history, SBOMs, build metadata, artifact provenance, change control, incident-response actions, and remediation evidence can be correlated through stable host, user, repository, workflow, token, package, version, runner, identity, destination, artifact, and timestamp mappings.

Visibility confidence is reduced when the initial developer workstation was unmonitored, SSH-key activity lacks attribution, GitHub audit retention is incomplete, workflow history was overwritten, secret access is not logged, npm publishing events lack token or source context, CI/CD runners are ephemeral, package-install logs are missing, file-access telemetry is unavailable, egress is encrypted, package caches and mirrors lack historical records, or downstream consumers cannot determine whether affected versions were installed or executed.

S25 provides independent endpoint, package-manager, CI/CD, GitHub, npm, identity, cloud, network, cache, mirror, and artifact detection paths. Splunk, Elastic, and QRadar provide local-compromise and downstream developer-service correlation. SentinelOne provides package-manager, runtime, credential-access, staging, and network-linked endpoint coverage. SIGMA provides portable process and credential-access coverage. YARA provides supplemental artifact triage where package contents or retained malicious material are available.

Change-Control Confidence

Change-control confidence is high when developer access, SSH-key registration, repository permissions, workflow changes, secret access, package updates, dependency restoration, publishing-token use, package publication, maintainer activity, internal mirror synchronization, build-image updates, artifact signing, release promotion, emergency remediation, and incident-response actions are recorded with validated actors, systems, approvals, timestamps, expected objects, and post-change verification.

Confidence is reduced when developers retain long-lived SSH or publishing credentials, repository write access is broadly assigned, workflow paths lack mandatory review, secrets can be exposed to untrusted jobs, package publishing is not restricted to approved workflows, maintainer and token activity is not baselined, internal mirrors synchronize automatically, emergency changes are poorly documented, or incident-response actions cannot be separated from attacker-driven repository, workflow, token, or registry activity.

Downstream Dependency

Downstream dependency is high when affected developer systems, repositories, CI/CD workflows, package namespaces, internal mirrors, package caches, artifact repositories, build images, container registries, cloud environments, customer-facing software, release artifacts, or deployment paths depend on the same identities, tokens, workflows, and automation paths that may have been exposed.

The organization must distinguish suspicious package installation, GitHub authentication, repository access, workflow execution, npm token use, package publication, cloud access, artifact creation, payload retrieval, internal connections, file transfer, and credential reuse from confirmed downstream compromise. Such activity becomes materially relevant when evidence ties it to an affected developer workstation, identity, SSH key, repository, workflow, token, package, version, runner, artifact, source, destination, or bounded investigation window.

A package cache, internal mirror, pinned dependency, lockfile, build image, container layer, artifact repository, or automated release workflow may preserve or distribute an affected version after the public package is deprecated or removed. Public registry remediation therefore does not independently establish downstream containment.

Customer and Regulatory Exposure

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

Exposure also increases when telemetry gaps prevent timely confirmation of whether source code was accessed, workflows were modified, publishing credentials were stolen, malicious versions were installed, lifecycle scripts or malicious package code executed, customer releases were affected, credentials were reused, cloud resources were reached, or containment was complete.

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

Residual Economic Risk

Residual economic risk remains after package removal, token revocation, SSH-key replacement, workflow deletion, package deprecation, clean-version publication, developer-system rebuilding, credential rotation, mirror cleanup, artifact replacement, or incident-response closure when the pre-remediation activity window cannot be reconstructed.

Removing a malicious package version or publishing a clean replacement does not prove that repository access, workflow modification, token exfiltration, package publication, lifecycle execution, malicious CLI execution, credential theft, cloud access, cached package retention, or downstream activity did not occur before remediation. Rebuilding a developer workstation does not prove that stolen SSH keys, active sessions, repository permissions, publishing credentials, modified workflows, compromised artifacts, or downstream persistence were removed.

Residual risk should remain elevated until historical developer endpoint, GitHub, workflow, CI/CD, npm, package-manager, file, process, identity, cloud, network, mirror, cache, artifact, release, change-control, incident-response, and remediation evidence has been assessed and the organization can demonstrate that developer, repository, workflow, registry, credential, cloud, artifact, and downstream trust have been restored.

Supply-Chain Behavioral Coverage Assessment

The current report directly covers the governing behavior family of trusted-package compromise, malicious package-manager lifecycle execution, unexpected runtime execution, developer and CI/CD credential discovery, GitHub and npm token abuse, package-publishing abuse, suspicious egress, cloud credential exposure, conditional propagation, internal mirror persistence, artifact-integrity uncertainty, and downstream software-trust disruption.

The expanded OSINT-to-S25 assessment also identifies related developer supply-chain activity involving developer-workstation compromise, GitHub SSH-key exposure, unauthorized repository write access, malicious GitHub Actions workflow activity, npm publishing-token exfiltration, unauthorized publication of legitimate package versions, IDE task autorun, import-time package execution, Tron, Aptos, and BNB Smart Chain transaction data used to resolve attacker-controlled code and infrastructure, DEV#POPPER-linked activity, AI-framework dependency compromise, cross-ecosystem package abuse, Nx self-hosted remote-cache archive-extraction and path-containment failure, Shai-Hulud-style abuse of legitimate release workflows and OIDC-backed trusted publishing, and associated developer-service or cloud activity.

Direct coverage applies where the material observable behavior is already represented by an existing S25 endpoint, package-manager, credential-access, GitHub, npm, cloud, network, cache, mirror, or artifact rule without substantive modification. Coverage with adaptation applies where S25 can identify substantial portions of the activity but requires additional package, repository, workflow, identity, token, ecosystem, runtime, import-time execution, archive-extraction, path-containment, workspace-write, downstream-execution, or telemetry mappings to detect and investigate the documented chain reliably.

CVE and KEV status remain urgency and remediation signals when a related software vulnerability contributes to initial access. They do not independently establish detection coverage for this report’s package-publishing and trusted-dependency behavior family.

Detection Engineering Coverage Interpretation

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

· npm, pnpm, or yarn lifecycle execution followed by suspicious runtime, shell, downloader, scripting, credential-access, staging, or network behavior

· Unexpected Bun, Node, Python, shell, PowerShell, curl, wget, archive, or related execution from dependency, cache, temporary, workspace, build, release, or CI/CD paths

· Access to GitHub, npm, SSH, cloud, Kubernetes, Docker, deployment, CI/CD, package-registry, or other developer credential material

· Suspicious environment-variable discovery, file collection, archive creation, encoding, encryption, compression, local staging, or outbound transfer

· GitHub repository creation, workflow creation or modification, deploy-key changes, webhook changes, permission changes, visibility changes, secret-related activity, or unusual API use following local compromise signals

· npm token validation, package publication, maintainer changes, ownership changes, access changes, metadata changes, provenance changes, or trusted-publishing deviations

· AWS, Azure, GCP, Kubernetes, Docker, secret-manager, registry, storage, IAM, deployment, or service-account activity following developer or CI/CD compromise

· Internal mirror retention, package-cache persistence, affected build images, altered artifact lineage, SBOM exposure, or release-integrity uncertainty

· Multi-source sequencing across developer endpoint, file, package-manager, GitHub, CI/CD, npm, identity, cloud, network, cache, mirror, artifact, and incident-response telemetry

The S25 rules intentionally avoid dependence on one package, namespace, version, loader, runtime, workflow, token, repository, source address, domain, hash, actor, campaign, or infrastructure indicator. Package names, affected versions, helper-package relationships, repository paths, workflow names, identities, token types, import-time execution context, and incident timestamps may improve investigation and prioritization without changing the governing detection behavior.

Direct Coverage

Direct coverage applies where documented activity produces material trusted-package execution, runtime activity, credential access, source-code platform abuse, package-registry abuse, cloud activity, suspicious egress, propagation, cache persistence, or artifact-integrity behavior already detected by the current S25 rules without substantive changes to rule logic.

· SAP npm package poisoning involving compromised SAP-related package versions, malicious lifecycle execution, setup.mjs-style loading, Bun or Node execution, developer credential theft, GitHub or npm activity, cloud exposure, cache retention, internal mirror persistence, artifact review, or release-integrity uncertainty

· Shai-Hulud-style npm developer credential theft involving package execution followed by GitHub, npm, SSH, cloud, deployment, or CI/CD credential discovery, staging, exfiltration, token reuse, repository abuse, or package propagation

· Mini Shai-Hulud-style npm lifecycle execution and propagation involving install-time execution, Bun or Node runtime activity, developer and CI/CD secret access, suspicious egress, GitHub or npm token abuse, and conditional propagation

· Bun runtime abuse in a package-install context where Bun is launched by npm, pnpm, yarn, shell, or CI/CD processes and is followed by credential access, staging, outbound communication, GitHub activity, npm activity, or cloud activity

· GitHub token abuse following package execution where local compromise signals are followed by repository creation, workflow changes, deploy-key changes, webhook changes, permission changes, visibility changes, secret-related activity, or unusual API use

· npm token and package-publishing abuse following package execution where credential-exposure signals are followed by token validation, package publication, maintainer changes, ownership changes, access changes, metadata changes, provenance anomalies, or unusual publishing behavior

· Cloud credential exposure following developer or CI/CD package execution where credential discovery is followed by AWS, Azure, GCP, Kubernetes, Docker, secret-manager, container-registry, storage, IAM, deployment, or service-account activity

The direct-coverage entries align with S25’s package-manager, runtime, credential-access, GitHub, npm, cloud, suspicious-egress, cache, mirror, and artifact-assurance rules.

Coverage With Adaptation

Coverage with adaptation applies where S25 contains relevant upstream, downstream, or correlated coverage but the documented incident requires additional package, ecosystem, repository, workflow, runtime, identity, token, import-time execution, archive-extraction, path-containment, workspace-write, downstream-execution, or telemetry mappings to detect the material chain reliably.

· Rust/crates.io arrayref supply-chain compromise involving malicious releases arrayref 0.3.10, internment 0.8.7, and append-only-vec 0.1.9; malicious proc-macro1 dependency execution through Cargo build-time behavior; and related malicious-crate incident context including proc-macro-en, aovine, arone, aronenao, and tinymember. Existing S25 package-manager, process, developer-endpoint, CI/CD, credential-access, network, cache, mirror, and artifact coverage provides substantial behavioral visibility, but reliable implementation requires Cargo/crates.io package and version mapping, Cargo dependency-resolution and build-script telemetry, malicious helper-crate relationships, local Cargo-cache visibility, affected publishing context, and correlation of build-time execution to resulting process, network, credential-access, cloud, repository, package-registry, or artifact activity. Presence of an affected crate version, Cargo.lock entry, cached crate, or helper-crate name is exposure-scoping evidence only and must not be counted as compromise without aligned evidence of malicious dependency resolution, build-time execution, payload activity, or other material downstream behavior.

· CVE-2026-71476 — Nx self-hosted remote-cache path traversal / zip-slip involving retrieval and extraction of a crafted remote-cache archive whose entries can escape the intended cache directory, write to arbitrary locations accessible to the Nx process, and potentially enable downstream code execution. Existing S25 cache, file, process, developer-endpoint, CI/CD, artifact, and downstream-execution coverage provides relevant behavioral visibility, but reliable implementation requires Nx/self-hosted remote-cache identification, archive-extraction telemetry, path-containment validation, workspace-write mapping, and correlation to downstream developer, build, test, package, CI/CD, or other execution. Cache presence, self-hosted remote-cache configuration, or an affected Nx version is exposure-scoping evidence only and must not be counted as compromise without aligned evidence of malicious archive retrieval or extraction, path escape, out-of-boundary file modification, downstream execution, artifact impact, or other material behavior.

· Shai-Hulud-style trusted-publishing and provenance-valid malicious publication involving compromise of a legitimate repository or release workflow, attacker-modified source processed by an authorized CI/CD workflow, OIDC-backed trusted-publishing authorization, malicious package publication through the expected release path, and valid provenance or signing associated with that authorized workflow. Existing S25 GitHub workflow, npm publication, CI/CD, identity, and package-provenance coverage provides substantial behavioral visibility, but reliable implementation requires correlation of package publication with the originating workflow identity, repository, ref, triggering event, OIDC publishing subject or workload identity, trusted-publishing relationship, provenance or build context, and preceding workflow changes.

· Compromised Joyfill npm beta releases involving @joyfill/layouts@0.1.2-2773.beta.0 and @joyfill/components@4.0.0-rc24-2773-beta.4, malicious code embedded in the published package bundles, execution when an affected package was imported rather than through an npm lifecycle hook, use of Tron, Aptos, and BNB Smart Chain transaction data to resolve attacker-controlled code and infrastructure, and remote-access activity linked to DEV#POPPER

· Jscrambler npm package compromise involving developer-workstation compromise, exposure of a GitHub SSH key and npm publishing credentials, unauthorized repository write access, use of a GitHub Actions workflow to exfiltrate an npm publishing token, unauthorized publication of malicious versions of the legitimate jscrambler package, execution through an npm preinstall lifecycle hook in earlier versions, and malicious package-code execution when the CLI was run in later versions

· Mastra AI npm supply-chain compromise and easy-day-js activity involving malicious dependency insertion, lifecycle execution, credential theft, LLM API-key exposure, cloud credential exposure, CI/CD secret access, or package-registry abuse

· JFrog-reported VS Code task autorun involving repository-local IDE automation, workspace trust, IDE-launched runtime execution, credential exposure, suspicious egress, source-code platform activity, package-registry activity, cloud activity, or artifact risk

· Packagist or Composer cross-manifest package.json lifecycle abuse involving trusted package restoration followed by npm-compatible lifecycle execution, runtime activity, credential access, suspicious egress, or downstream developer-service abuse

· PyPI developer supply-chain compromise involving Python package installation or build behavior followed by developer or CI/CD credential access, repository abuse, package-registry activity, cloud risk, or artifact-integrity uncertainty

· AI-framework npm namespace compromise involving malicious lifecycle execution, LLM API-key exposure, cloud credential exposure, CI/CD secret access, package-registry abuse, or downstream artifact risk

· Sapphire Sleet / BlueNoroff Mastra attribution context where observable activity aligns with malicious dependency insertion, lifecycle execution, developer or CI/CD credential theft, LLM API-key exposure, cloud credential exposure, or package-registry abuse; attribution remains enrichment unless supported by incident-specific evidence

· TeamPCP-style developer supply-chain activity where observable behavior aligns with 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 remains enrichment unless supported by incident-specific evidence

The nine named malware, tooling, or tradecraft entries remain covered with adaptation. Sapphire Sleet / BlueNoroff and TeamPCP remain two actor or campaign names covered with adaptation. CVE-2026-71476 is separately counted as one CVE covered with adaptation.

These entries remain under adaptation because reliable implementation requires incident-specific package and version scope, repository and workflow identifiers, identity and token mapping, ecosystem-specific installation or import-time execution telemetry, approved publishing baselines, and validated correlations between upstream compromise and downstream package, cloud, or artifact activity. The Rust/crates.io arrayref incident additionally requires Cargo/crates.io package and version mapping, Cargo dependency-resolution and build-script telemetry, malicious helper-crate relationships, local Cargo-cache visibility, affected publishing context, and correlation of build-time execution to downstream process, network, credential-access, repository, package-registry, cloud, or artifact behavior. Shai-Hulud-style trusted-publishing activity additionally requires workflow identity, repository and ref, triggering event, OIDC publishing identity or subject, trusted-publishing relationship, provenance or build context, and preceding workflow-change mappings. Reliable implementation for CVE-2026-71476 additionally requires Nx/self-hosted remote-cache, archive-extraction, path-containment, workspace-write, and downstream execution mappings.

Non-Coverage Conditions

Non-coverage applies where activity does not produce observable package-manager lifecycle execution, suspicious runtime activity, developer credential access, CI/CD secret exposure, repository or workflow abuse, GitHub or npm token misuse, unauthorized package publication, suspicious egress, cloud activity, cache or mirror persistence, artifact uncertainty, or downstream activity aligned with this report’s detection model.

Non-coverage applies when activity remains limited to:

· Package, namespace, version, repository, workflow, dependency, lockfile, SBOM, cache, mirror, helper-package, affected Nx version, or self-hosted remote-cache presence without local behavioral evidence

· Download counts, package statistics, version deprecation, package removal, or public exposure estimates without evidence of local installation or execution

· Package names, malicious-version lists, workflow names, filenames, hashes, domains, IP addresses, source addresses, user agents, campaign names, actor attribution, or static indicators without aligned local behavior

· Developer-workstation compromise that cannot be tied to relevant repository, workflow, package-registry, cloud, artifact, or release activity

· GitHub authentication, repository access, or workflow modification that cannot be distinguished from authorized development, release engineering, package recovery, security testing, or incident response

· npm token use or package publication that cannot be distinguished from approved publishing workflows, authorized maintainers, or remediation activity

· Package installation without evidence of lifecycle execution, suspicious runtime behavior, malicious package-code execution, credential access, staging, egress, token reuse, cloud activity, or downstream impact

· Internal mirror, package-cache, self-hosted remote-cache, build-image, container-layer, or artifact presence without evidence of malicious archive retrieval or extraction, path-containment failure, out-of-boundary workspace writes, installation, execution, promotion, deployment, or affected release output

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

· Unrelated phishing, unrelated endpoint malware, unrelated SaaS abuse, generic typosquatting, cryptocurrency-wallet-only theft, unrelated webshell activity, unrelated CVE exploitation, or unrelated package-reputation findings

· Credential theft, source-code compromise, customer impact, cloud compromise, artifact tampering, actor attribution, campaign attribution, or malware attribution inferred solely from package presence or behavior covered by S25

· Environments where required endpoint, package-manager, GitHub, CI/CD, npm, identity, cloud, network, cache, mirror, archive-extraction, path-containment, workspace-write, artifact, timestamp, retention, asset-role, approved-workflow, or incident-response context is unavailable

Current Coverage Count

The current coverage disposition is:

Directly Covered CVEs

0

CVEs Covered With Adaptation

1

CVE-2026-71476

Current CVE Coverage Count

1

CVE-2026-71476 is counted as Coverage With Adaptation because S25 provides relevant cache, file, process, developer-endpoint, CI/CD, artifact, and downstream-execution visibility, but reliable implementation requires Nx/self-hosted remote-cache, archive-extraction, path-containment, workspace-write, and downstream execution mappings.

Current KEV Count

0

No CISA Known Exploited Vulnerability is represented in the current coverage set.

Directly Covered Named Malware / Tooling / Tradecraft Patterns

7

Named Malware / Tooling / Tradecraft Patterns Covered With Adaptation

9

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.

The updated coverage disposition retains CVE-2026-71476 as one CVE covered with adaptation, retains Shai-Hulud-style trusted-publishing and provenance-valid malicious publication as one named tradecraft pattern covered with adaptation, and adds the Rust/crates.io arrayref supply-chain compromise as one named tradecraft pattern covered with adaptation. It does not add a directly covered CVE, KEV entry, actor or campaign attribution, or new core behavior class.

Coverage Qualification

Coverage is strongest where developer-endpoint activity can be joined with repository access, workflow modification, secret use, package publication, lifecycle execution, import-time package execution, malicious package-code execution, credential access, suspicious egress, cloud activity, cache or mirror retention, artifact creation, or downstream release activity.

For the Rust/crates.io arrayref supply-chain compromise, coverage is strongest where affected-crate resolution or installation can be joined to Cargo build-script execution, resulting process or payload activity, outbound communication, credential access, repository or package-registry activity, cloud activity, cache retention, CI/CD activity, artifact creation, or other downstream behavior. Reliable implementation requires Cargo/crates.io package and version mapping, Cargo dependency-resolution and build-script telemetry, malicious helper-crate relationships, local Cargo-cache visibility, affected publishing context, and downstream process and network correlation rather than new generic S25 rules.

For CVE-2026-71476, coverage is strongest where Nx self-hosted remote-cache retrieval can be joined to archive extraction, path normalization and containment, writes outside the intended cache or workspace boundary, resulting workspace or project-file modification, and subsequent developer, build, test, package, CI/CD, or other process execution. Reliable implementation requires Nx/self-hosted remote-cache, archive-extraction, path-containment, workspace-write, and downstream execution mappings rather than new generic S25 rules.

Coverage is weaker for package presence without execution evidence, developer compromise without repository or package-registry linkage, workflow changes without secret-access evidence, package publication without token or source attribution, installation or package import without process telemetry, Nx/self-hosted remote-cache presence or an affected version without archive-extraction and path-containment evidence, short-lived or ephemeral CI/CD environments, missing GitHub or npm audit history, encrypted egress, internal mirrors without synchronization history, deleted package artifacts, incomplete identity lineage, and cloud or artifact activity without validated upstream linkage.

The report does not claim universal npm compromise detection, universal developer-endpoint compromise detection, universal package-publishing detection, universal credential-theft detection, universal GitHub or CI/CD abuse detection, universal Nx self-hosted remote-cache exploitation detection, universal cloud detection, complete visibility across every package ecosystem, registry, repository platform, workflow engine, build system, developer tool, cloud environment, or release process, or standalone package, actor, campaign, malware, vulnerability, or impact attribution.

Detection confidence depends on telemetry completeness, asset and identity validation, developer-system inventories, repository and workflow mapping, package and namespace inventories, package-manager visibility, package-import context, GitHub and npm audit retention, token attribution, CI/CD job history, Nx/self-hosted remote-cache identification, archive-extraction telemetry, path-containment validation, workspace-write telemetry, downstream process lineage, file and process telemetry, process-to-network attribution, cache and mirror records, artifact provenance, approved publishing baselines, timestamp alignment, retention, rule validation, performance testing, false-positive testing, and SOC triage readiness.

Executive Exposure Statement

The organization’s economic exposure is highest when developer-endpoint or trusted-package activity creates uncertainty over whether developer credentials, GitHub SSH keys, source-code repositories, CI/CD workflows, package-publishing tokens, npm namespaces, cloud deployment paths, internal package mirrors, build images, release artifacts, and customer-facing software remained trustworthy.

The strategic risk is not only that one SAP-related, Jscrambler, Joyfill, Mastra, or other npm package was compromised. The material risk is that an adversary may convert one developer workstation, SSH key, repository permission, workflow, publishing token, trusted dependency, or routine package import into repository control, secret exfiltration, unauthorized package publication, malicious lifecycle, import-time, or CLI execution, credential exposure, cloud access, artifact uncertainty, customer impact, operational disruption, or broader software-supply-chain compromise before containment.

S40 — References

The following references support the package-platform scope, incident descriptions, coverage classifications, current coverage counts, and detection-engineering interpretation in this report.

Vendor / Platform Documentation

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 and Framework Context

hxxps://mastra[.]ai/

Mastra GitHub Repository

hxxps://github[.]com/mastra-ai/mastra

Incident Records — Coverage With Adaptation

Rust Security Response Team — Supply Chain Attack on arrayref

hxxps://blog[.]rust-lang[.]org/2026/08/20/supply-chain-attack-on-arrayref/

Nx GitHub Security Advisory — Zip-Slip in the Nx Self-Hosted Remote Cache — CVE-2026-71476 / GHSA-vp3h-ghgh-jr7g

hxxps://github[.]com/nrwl/nx/security/advisories/GHSA-vp3h-ghgh-jr7g

NVD — CVE-2026-71476

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

Socket — Popular npm Packages in the keyv and Cacheable Namespaces Compromised in Active Supply Chain Attack

hxxps://socket[.]dev/blog/popular-npm-packages-in-the-keyv-and-cacheable-namespaces-compromised-in-active-supply-chain

Sygnia — Shai-Hulud Returns: When Software Trust Becomes the Attack Surface

hxxps://www[.]sygnia[.]co/threat-reports-and-advisories/shai-hulud-returns-software-supply-chain-attack-npm-keyv/

Socket — Two Joyfill npm Beta Releases Compromised to Deliver DEV#POPPER Remote Access Trojan

hxxps://socket[.]dev/blog/joyfill-npm-beta-releases-compromised

Jscrambler — Security Incident Postmortem: Malicious Versions of the jscrambler npm Package

hxxps://jscrambler[.]com/blog/security-incident-postmortem-jscrambler

Jscrambler — Security Advisory: Unauthorized Publication of a Malicious npm Package affecting the product Code Integrity

hxxps://jscrambler[.]com/blog/security-advisory-malicious-npm-package

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

JFrog Security Research — Hijacked npm Packages Use Novel VS Code Autorun and Blockchain Dead Drops to Deploy a Credential/Crypto Stealer

hxxps://research[.]jfrog[.]com/post/hijacked-npm-vscode-tasks-blockchain/

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/

Incident Records — Direct Behavioral Coverage

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/

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 the npm Ecosystem

hxxps://content[.]govdelivery[.]com/accounts/USDHSCISA/bulletins/3f408db

Threat Tradecraft and Intrusion Patterns

MITRE ATT&CK Framework — Enterprise Matrix

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