Skip to content

Navigation Menu

Sign in
Sign up

How to record OPTIONAL dynamic dependencies in an SBOM? #712

Discussion options

I can see the recent addition of the 'isExternal' flag, allowing documentation of external/extraneous dependencies: issue,PR.

However, I am confused since an external component "is expected to be provided by the environment regardless of the component's .scope". Is there any provision for optional external components?

I am writing an SBOM for a product, which by default does not require any external dependencies to operate. However, the product offers optional features, where an administrator configures the application to load a dynamic library, enabling extra abilities (For example, IODBC can be provided, and thus a feature is enabled to connect to an external database via ODBC). Each of these features is used by a minority of our customers.

Given these are dynamic dependencies, they should have 'isExternal' set true. However, this would indicate to all customers these are expected, and the product would fail to operate without them, but this is not accurate and is not how most of our customers use the product -- in fact without a number of configuration options and environment variables being set, the product won't even try to connect to such dynamic dependencies.

What is the intended way to denote such an optional dependency, since 'scope' seems to be ignored once 'isExternal' is set?

You must be logged in to vote

the spec:

isExternal - https://cyclonedx.org/docs/1.7/json/#components_items_scope

Determine whether this component is external.
An external component is one that is not part of an assembly, but is expected to be provided by the environment, regardless of the component's .scope. This setting can be useful for distinguishing which components are bundled with the product and which can be relied upon to be present in the deployment environment.
This may be set to true for runtime components only. For $.metadata.component, it must be set to false.

scope - https://cyclonedx.org/docs/1.7/json/#components_items_scope

Specifies the scope of the component. If scope is not specified, 'required' ...

Replies: 2 comments 3 replies

Comment options

I think that would be scope https://cyclonedx.org/docs/1.6/json/#components_items_scope

is_external is for stuff like jvm, or interpreters i think.

You must be logged in to vote
1 reply
Comment options

is_external is for stuff like jvm, or interpreters i think.

true, but it is not limited to this.
see the use cases in the original ticket: #321

Comment options

the spec:

isExternal - https://cyclonedx.org/docs/1.7/json/#components_items_scope

Determine whether this component is external.
An external component is one that is not part of an assembly, but is expected to be provided by the environment, regardless of the component's .scope. This setting can be useful for distinguishing which components are bundled with the product and which can be relied upon to be present in the deployment environment.
This may be set to true for runtime components only. For $.metadata.component, it must be set to false.

scope - https://cyclonedx.org/docs/1.7/json/#components_items_scope

Specifies the scope of the component. If scope is not specified, 'required' scope SHOULD be assumed by the consumer of the BOM.

  • "required" - The component is required for runtime
  • "optional" - The component is optional at runtime. Optional components are components that are not capable of being called due to them not being installed or otherwise accessible by any means. Components that are installed but due to configuration or other restrictions are prohibited from being called must be scoped as 'required'.
  • "excluded" - Components that are excluded provide the ability to document component usage for test and other non-runtime purposes. Excluded components are not reachable within a call graph at runtime.

Let's examine the different parts:

  • An external component is one that is not part of an assembly, but is expected to be provided by the environment [...]

    The case described by @AndrewStamper-OST clearly matches this requirement: the component is intended to be supplied by the administrator at runtime.

  • [...] regardless of the component's .scope

    This simply means the component is not shipped with a specific product—regardless of what "scope" refers to.

  • Attention to detail: while "is to be provided" does not imply any obligation—such as may/must/etc. —
    the .scope does. It indicates whether a component MAY be provided ("optional") or MUST be provided ("required").


conclusion - as it was intended by the authors of the spec:

optional extetnal dependencies are expressed by combining isExternal is set to true and scope is set to optional.

You must be logged in to vote
2 replies
Comment options

Thank you @jkowalleck, my mistake was in misunderstanding the "regardless of the component's .scope" line (I wrongly belived it meant that scope was overriden and thus to always be interpreted as required). Your comment has cleared that up!

Comment options

hm, do you have suggestions how the phrasing/wording could be improved to make this more clear and prevent such misunderstandings for future readers?
Feel free to pull request improvements.

Answer selected by AndrewStamper-OST
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

AltStyle によって変換されたページ (->オリジナル) /