cdx:npm:package:path - #35
Merged
Merged
Conversation
Signed-off-by: Jan Kowalleck <jan.kowalleck@gmail.com>
Member
Author
|
@stevespringett @coderpatros @nscuro may i ask for your opinion? an example for the usage can be seen in the example data generated by https://github.com/CycloneDX/cyclonedx-node-npm/pull/308/files |
Member
|
IMO, path or location make sense to me |
Member
Author
|
@stevespringett @coderpatros please merge this. |
7 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
caused by CycloneDX/cyclonedx-node-npm#305
NodeJS's module system is file-system based. It works regardless of package dependencies,
When code in module "foo" tries to use/require/access code from a different module "bar", then node will look in "foo";s own/direct "node_module" folder (depth 1). if it did not find any "bar" there, then node traverses all folders upwards and does the same lookup there, until it finds any "bar".
This file-based loading behavior happens regardless of components' "dependency graph"
To make this loader-environment visible in an SBOM, a property should reflect a modules install path.
It could even happen that an SBOM's component is installed in multiple places.
Therefore, a property should indicate all install locations. This meansthe property could appear multiple times with different values
This way it is possible to answer the question "is this component 'A' actually using component 'B1' or does it load 'B2' instead?"
An alternative would be to have the actual file tree represented as sub-components.
But component flattening or component de-duplication might change these prepared structures, which could lead to information loss.
So a property is preferred.
property value should be a representation of the install-path relative to the root directory of the project under analysis.
no absolute paths, so private data (internal file path structures or mountpoints) are not published.
property value should be posix-like path, regardless of the actual runtime nor input nor detected path-patterns.
to represent the same dir as the root dir, an empty string is expected.