The SAP CAP supply chain attack: what the April 2026 npm incident reveals about change governance

1. What a supply chain attack in SAP development is

A software supply chain attack does not target the production system, but rather the tools and dependencies used to build software. Instead of exploiting a vulnerability in a running system, the attacker injects malicious code into a component that developers are already using: a library, a build tool, or a package from a public registry. The code then enters the development environment through legitimate channels, often before any security gate in the traditional change process is triggered.

In the SAP context, this has become relevant because modern SAP development is no longer just about ABAP in a closed system. The SAP Cloud Application Programming Model (CAP) is a framework for developing business applications on the SAP Business Technology Platform. CAP projects use Node.js and pull their dependencies via npm, the package manager for the Node.js ecosystem. As a result, part of SAP development is now dependent on the same public supply chain as the rest of the JavaScript world.

The incident at the end of April 2026 highlighted this dependency. Official SAP CAP packages in the npm registry were tampered with. The attack did not affect the production system, but rather developer workstations and build pipelines—exactly the layer that traditionally receives little attention in classic SAP change management.

1. Why the distinction is important. For most organizations, the classic SAP change process begins with a transport. The transport is created, checked, released, and imported. However, there is a zone preceding this that the ITIL change process often fails to capture: the development environment where the code is created in the first place. In CAP and BTP development, this zone includes npm packages, build tools like the MTA Build Tool, local caches, CI/CD runners, and developer laptops. A supply chain attack targets exactly this area, i.e., before the first transport and before the first quality gate.

2. The Mini-Shai-Hulud incident of April 2026

1. Chronology and findings. At the end of April 2026, a coordinated campaign against the SAP development ecosystem was made public. Several official SAP CAP npm packages were injected with malicious code and published in tampered versions. Security researchers attributed the attack to a variant of the well-known Shai-Hulud worm and named it Mini-Shai-Hulud. The primary goal of the malware was the automated theft of cloud access credentials, service tokens, and private keys.

The tampered package versions were available for only a short window of time—according to consistent analyses, about two to four hours on April 29, 2026. Subsequently, clean versions were published to replace the infected ones. Anyone who downloaded an affected version during this window may be compromised, even if the package is clean again now.

SAP responded on April 30, 2026, with HotNews security note 3747787, which addresses the affected open-source packages. The note should be classified as an urgent supply chain warning for organizations that use SAP CAP, BTP development pipelines, the MTA Build Tool, or npm-based SAP development workflows.

2. How the malicious code works. The technical functionality is relevant to the governance discussion because it explains why the attack is so difficult to catch with classic change controls. The tampered packages contained an additional lifecycle hook that is executed automatically during every installation, i.e., before the actual application code is ever called. The loader was identical across the affected packages and downloaded further components at runtime. The actual goal was to extract login credentials and tokens from the developer's or build runner's environment.

The crucial point is: execution occurs at installation time, not at application runtime. A security check that only triggers during transport release or deployment is too late. The damage—the theft of credentials—has already occurred by then.

3. What is at stake. The attack targets high-value assets. Developer and CI/CD credentials open the door to cloud tenants, source code repositories, and deployment permissions. A compromised pipeline can theoretically be used to inject further malicious code into legitimate builds, extending the chain. From a compliance perspective, this shifts the risk boundary: it is no longer just the production system, but the development workstation itself that becomes part of the landscape requiring protection.

3. Extending the change lifecycle forward

The central lesson of the incident is organizational, not just technical. The controls that apply to transports in classic SAP change management must be supplemented with controls that apply to the development toolchain. The following approaches are not a reaction to a single incident, but rather building blocks of end-to-end supply chain governance.

1. Pin dependencies and build reproducibly. Lockfiles such as package-lock.json define the exact version of a package to be installed. Builds based on a fixed state are reproducible and prevent a newly released, malicious version from being introduced unnoticed. The requirement to build against lockfiles should be mandatory for all CI/CD pipelines, not optional.

2. Use a private registry or proxy. Instead of installing directly from the public npm registry, organizations can operate an internal proxy or a private registry. Packages are vetted, approved, and cached there. A new version only enters the approved inventory after a cooling-off period and a security check. This exact cooling-off period would have limited the damage during the short availability window of the Mini-Shai-Hulud attack.

3. Isolate build environments. CI/CD runners should run in isolated environments without persistent access to production credentials. If lifecycle hooks are executed during installation, they will not find any valuable tokens. Separating the build environment from production permissions is a fundamental measure that remains effective regardless of any specific incident.

4. Software Bill of Materials and provenance. A Software Bill of Materials, or SBOM, documents which components and versions were included in a build. In the event of an incident, an SBOM helps answer the critical question quickly: Did we ever pull an affected version, and if so, where? Without this record, the answer remains a time-consuming manual search.

4. Where traditional change controls fall short

1. The control gap before transport. The most significant risk finding: The traditional SAP change process has a blind spot before transport. The four-eyes principle, CAB approval, and downgrade protection begin at the transport stage. They are effective for what they cover, but they do not see what happens in the development environment before a transport even exists. Credential theft during an npm installation leaves no trace in the transport log.

2. Persistence and incomplete remediation. Simply removing or downgrading the affected package may not be enough if persistence files remain or stolen credentials remain valid. A serious response includes rotating all potentially exposed credentials, not just correcting the package version. Anyone who only swaps the package while keeping the tokens is closing the door but leaving the key in the lock.

3. Shared responsibility as a risk factor. CAP and BTP development distribute responsibility across teams that were previously separated in traditional SAP operations. SAP Basis, development, cloud operations, and security work on different layers. A supply chain attack falls exactly into the gaps between these responsibilities. Without clear accountability for the development toolchain, the gap remains open because no one feels clearly responsible. If you do not actively exercise control over your own supply chain, you leave it to those who inject the malicious code.

4. Speed versus diligence. The pressure to deliver quickly is in direct conflict with the diligence required for a vetted supply chain. Pipelines that pull every new package version immediately are fast but exposed. A cooling-off period costs speed but reduces the window of time in which a malicious package can cause damage. This trade-off is a conscious governance decision, not a technical side issue.

5. A control framework for the development supply chain

The following practices summarize the solutions into a framework that builds upon existing SAP change governance rather than replacing it.

1. Include the toolchain in the scope. Change management scope does not end at transport. Development workstations, package registries, build tools, and CI/CD pipelines must be documented and controlled.

2. Mandate fixed dependencies. Lockfiles are mandatory, not optional. Builds must run reproducibly against an approved baseline.

3. Implement a grace period and approval stage. New package versions must pass through a private registry with verification and a waiting period before they can be used in production builds.

4. Minimize and rotate credentials. Build environments should only be granted the minimum necessary, short-lived permissions. If a compromise is suspected, all exposed credentials must be rotated.

5. Ensure provenance is verifiable. An SBOM for every release allows for quick identification of whether and where an affected component was used. This links supply chain control with the end-to-end audit trail required by compliance regimes such as SOX, NIS2, and the EU AI Act.

6. Define an incident response path. A documented process must exist for supply chain incidents: identify affected packages, correct versions, rotate credentials, check for persistence, and log the incident.

6. Tool Landscape

The following table categorizes which tool class covers which part of the lifecycle. It demonstrates that no single tool covers the entire chain and that supply chain control and transport governance are distinct, complementary layers.

¹ Solutive AG is the initiator of the Change Orchestration Institute. The assessment in the table is a self-declaration by the provider and is not part of an editorially independent validation. The columns for npm and dependency scanning as well as build environment isolation are intentionally outside the scope of change and transport governance and are covered by dedicated supply chain tools.

The table highlights the article's core message: Transport governance tools, including ChaRM and an orchestration layer, are strong in controlling transports and maintaining an end-to-end audit trail. However, by design, they are not intended to scan npm packages for malicious code. This task belongs to dedicated supply chain tools and npm-native methods. Robust governance combines both layers.

7. Operational consequences for SAP organizations

The incident necessitates concrete operational steps that apply regardless of the platform being used.

The first consequence concerns inventory assessment. Organizations should determine whether an affected CAP package version was pulled during the relevant timeframe across all developer workstations and build runners, not just on a central server. Without an SBOM or a central registry, answering this question is time-consuming, which in itself is a finding.

The second consequence concerns credential hygiene. Tokens and keys that were in potentially exposed environments must be rotated. This includes service tokens for BTP tenants, repository access credentials, and deployment permissions.

The third consequence concerns process integration. SAP Note 3747787 should not be treated as an isolated security task, but rather as an opportunity to permanently incorporate the development toolchain into the change and release process. A one-time cleanup only closes the gap in the short term.

The fourth consequence concerns accountability. There is a need for designated responsibility for the security of the development supply chain, bridging the gaps between Basis, development, cloud operations, and security.