-
Notifications
You must be signed in to change notification settings - Fork 20
Description
It is clear that pkg://my@1.2.3?arch=amd64 means just the amd64 variation of package my@1.2.3, but what does pkg://my@1.2.3 means? Instinctively, no qualifiers means all possible variations of the package, but since PURL specifiers are optional, we don't know if the user omitted the qualifiers intentionally in order to widen the scope, or neglected to include them for another reason (since they are optional).
This is relevant to VEX because when matching the product id PURLs, we need to assume that the PURL in both locations followed the same choices as to which specifiers to use.
Example:
Let there be package pkg://npm/libA that has only amd64 architecture variation. SBOM-tool-A generated SBOM with package pkg://npm/libA@1.2.3 while SBOM-tool-B generated SBOM with pkg://npm/libA@1.2.3?arch=amd64. Note that Both SBOM tools produced correct results.
Since libA has only one architecture variation, maintainers of libA issued VEX with product id: pkg://npm/libA@1.2.3. What should the VEX consumer do?
Possible approaches:
- Ignore qualifiers and compare just base package - in this case it would mismatch if another qualifiers was used in the VEX (maintainers decide to add
?file_name=libA, or if the same qualifier will be used in a another VEX (maintainers later added support forarm64). - Compare all qualifiers - in this case scanner would not apply VEX to SBOM generated by
SBOM-tool-B. - Compare common qualifiers and ignore the rest - This is likely the most reasonable compromise (although not perfect).