Fix Critical Compromise of Multitenant CAP apps

[akgarg06]

Describe your changes

CI/deploy workflows that build the CAP sample apps need @sap/cds-mtxs@3.9.7 and @sap/cds-dk@9.9.5, which don't exist on public npm (public maxes at 3.9.6 / 9.9.4) and only live on SAP's internal registries. The int repo has them but requires VPN (unavailable in CI); the commons repo is public-facing but doesn't host all @sap packages. Additionally, BlackDuck was reporting a stale @sap/cds-mtxs@3.9.5 from the sample apps.

How

• @sap scope → public npm, with the two internal-only packages pinned to direct commons tarball URLs (a URL dependency bypasses the scope-registry rule, since npm allows only one registry per scope).
• Tarball URLs + auth token are injected at runtime from GitHub secrets (SAP_CDS_MTXS_TARBALL, SAP_CDS_DK_TARBALL, NPM_AUTH_TOKEN) — never committed, masked in logs. The committed package.json files stay on clean exact versions (3.9.7 / 9.9.5) so BlackDuck can match them to its knowledge base.
• A setup step generates .npmrc and uses jq (guarded — only rewrites keys that already exist) to inject the tarball URLs into the relevant package.json files before npm install / mbt build.
• Added overrides["@sap/cds-mtxs"] to force the transitive cds-mtxs@3.9.5 (pulled in by cds-dk's own "^3" dependency) up to 3.9.7 — this is what fixed the version BlackDuck was reporting.
• In blackduck.yml, package.json is restored via git checkout after install, so the scan reads clean version strings against the correctly-resolved node_modules tree.
• legacy-peer-deps=true to resolve CAP peer-dependency conflicts.

Workflows changed

Applied to every workflow that runs npm install / mbt build inside a sample-app directory:

• blackduck.yml — Node setup + install loop over all 4 multi-tenant dirs + restore for clean scan
• multiTenancyDeployLocal.yml — multi-tenant (personal-space) mbt build
• multiTenant_deploy_and_Integration_test.yml — multi-tenant (central-space) mbt build
• multiTenant_deploy_and_Integration_test_LatestVersion.yml — multi-tenant (central-space) mbt build
• cfdeploy.yml — single-tenant deploy (defensive .npmrc; jq is a no-op here since single-tenant doesn't declare the internal packages)

Not changed (with reasons)

• Single-tenant integration/deploy (singleTenant_deploy_and_Integration_test*.yml, singleTenant_integration_test.yml) and multi tenancy_Integration.yml — either run mvn verify against already-deployed CF apps (no npm build), or build the single-tenant app, which resolves cds-dk from public npm and doesn't declare the internal-only packages.
• Plugin-only builds (main-build*.yml, pull-request-build.yml, unit.tests.yml, sonarqube.yml, codeql.yml, deploy-central-snapshot.yml, demo-build.yml, internalArticatory.yml, new_wokflow_test.yml, SAPUI5_Version_Monitoring.yml) — the root pom.xml reactor contains only <module>sdm</module>, so mvn clean install builds just the plugin and never enters app/** or triggers cds build/npm for the sample apps.

Required secrets

Set the following in environments (or at repo level):

Secret	Value
SAP_CDS_MTXS_TARBALL	<URL>/@sap/cds-mtxs/-/@sap/cds-mtxs-3.9.7.tgz
SAP_CDS_DK_TARBALL	<URL>/@sap/cds-dk/-/@sap/cds-dk-9.9.5.tgz
NPM_AUTH_TOKEN	commons auth token

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)

Checklist before requesting a review

• I follow Java Development Guidelines for SAP
• I have tested the functionality on my cloud environment.
• I have provided sufficient automated/ unit tests for the code.
• I have increased or maintained the test coverage.
• I have ran integration tests on my cloud environment.
• I have validated blackduck portal for any vulnerability after my commit.

Single Tenant Integration test : https://github.com/cap-java/sdm/actions/runs/33757057322
Multi Tenant Integration test : https://github.com/cap-java/sdm/actions/runs/33757094896

[vibhutikumar07]

LGTM but need to revert once required version available on npm