[CDX1.7] guide for "component.isExternal"

[jkowalleck]

based on CycloneDX/specification#321

enhance the SBOM guide on when to mark compoennts as "isExternal".

• use cases are in the ticket
• section followup in the ticket
• additional questions are in [DRAFT] extraneous components and version range constraints specification#326 & feat: support for external components with version-ranges specification#586

also discuss the following:

• transitive dependencies and hashes still make sense for external components -- as they may be version-pinned -> may also hash-pinned
• dont use component's "isExternal"/"versionRange" in VEX/VDR -- in this case we require specific versions
• dont use component's "isExternal"/"versionRange" in OBOM -- in this case all belongs to the system(universe)
  make it clear in the OBOM guide, that there must not be any runtime components with a version range - it just makes no sense
• dont use component's "isExternal"/"versionRange" in MBOM -- in this case all belongs to the build system(universe)
  make it clear in the MBOM guide, that there must not be any build-components with a version range - it just makes no sense

[ppkarwasz]

@jkowalleck,

Should we have per-ecosystem guides on when to use "isExternal"? This would allow to map the "isExternal" term to precise techniques used in the various ecosystems.

I can create a draft of what isExternal means for the Java ecosystem.

[jkowalleck]

Should we have per-ecosystem guides on when to use "isExternal"?

not sure what this is and thy to use it. I might understand when i see it.
Please draft a PR to showcase this.

[ppkarwasz]

not sure what this is and thy to use it. I might understand when i see it.

Java developers might misinterpret external as an equivalent of the provided scope, which is used for some specific dependencies that must be provided by the runtime environment. In reality, IMHO, external is a much larger concept for "normal" libraries (90% of the ecosystem) every dependency is external, since it is not included in the JAR packaging. The external property should only be false:

• for "shaded" JARs, which contain the classes from their dependencies.
• "executable" JARs, which contain the original JARs of their dependencies.
• packaging type like WAR or EAR that contain most of their dependencies (except the provided ones).

[raboof]

dont use component's "isExternal"/"versionRange" in VEX/VDR -- in this case we require specificversions

This is not yet obvious to me: in the case where product A depends on a library B which dynamically depends on transitive dependency C, and an advisory exist for certain versions of C, it might be valuable if B could publish a VEX conveying it is or isn't affected by that advisory without pinning the version of C. Ideally that VEX could then consumed by whoever analyses A, where the version of C is known, to help determine if A is affected.

[jkowalleck]

working on it