When following the documentation for microservices in a monorepository with npm workspaces, this will cause one huge issue:
There is no guarantee for the used versions of transitive dependencies!
Especially because of recent supply chain attacks, this should be handled critical.
The reason is the following:
- in npm workspaces, there is only one global package-lock.json file, storing all exact versions of all transitive dependencies.
- This means there is no package-lock.json inside the workspace folders.
- When running cds build in the workspace folder, this will only use the package-json and will only pin the direct dependencies in the gen/srv folder.
- This means the versions of transitive dependencies are determined at the execution time of the npm install command for the module.
Results:
- Versions in deployed modules of the MTA might be different than the ones captured in the root package-lock.json
- This might break applications (Code only tested against dependencies from package-lock)
- The SBOM might not be correct
- Vulnerable to supply chain attacks.
A mechanism is needed to get the node_modules into the gen/srv folder, with the versions captured in the root package-lock.json.
When following the documentation for microservices in a monorepository with npm workspaces, this will cause one huge issue:
There is no guarantee for the used versions of transitive dependencies!
Especially because of recent supply chain attacks, this should be handled critical.
The reason is the following:
Results:
A mechanism is needed to get the node_modules into the gen/srv folder, with the versions captured in the root package-lock.json.