CycloneDX SBOM components > scope field

[nigellh]

Question

In generating an SBOM, specifically a CDX one do you also generate the components with the scope field set. See

https://cyclonedx.org/docs/1.6/json/#components_items_scope

Or the equivalent for other SBOMs. As in required, optional or excluded.

My understanding is that when a package is included in a product, but is not part of the product such as test or build, it should be marked as excluded in the scope field.

The default for this field is required so, technically, it is an optional field.

Target

Filesystem

Scanner

License

Output Format

CycloneDX

Mode

Standalone

Operating System

Does not matter

Version

Not applicable. Generic question on CDX Schema usage.

[DmitriyLewen]

Hello @nigellh
Thanks for your interest to Trivy.

In most cases, Trivy detects only runtime dependencies (for example, it skips test dependencies from pom.xml files or *.deps.json).
Therefore, all detected dependencies are required dependencies.
According to the documentation, “Specifies the scope of the component. If the scope is not specified, the consumer of the BOM SHOULD assume the ‘required’ scope.”
So the CycloneDX reports are correct.

Regards, Dmitriy

[nigellh]

@DmitriyLewen

Thanks for getting back to me. If you are skipping items and not including them in the SBOM, it is my understanding that you are creating an incomplete SBOM. There are various documents around that indicate that everything that is shipped to the customer, forms part of the deliverable or however you would like to define it Should be included in the SBOM, CoO and, if needed, the Notices file.

For example in the currrent NTIA SBOM Minimum Elements Report which is due to be updated soon, it has a number of relevant points:

• It states on page 6 paragraph 3 "SBOMs offer advantages to producers such as ensuring that components are up to date and allowing a quick response to new vulnerabilities. SBOMs also offer benefits beyond security such as supporting greater efficiency and effectiveness through visibility, which in turn enables prioritization and better management. For example, they assist the producer with knowing and complying with license obligations."
• It states on page 8 section IV paragraph 2 "A piece of software can be represented as a hierarchical tree, made up of components that can, in turn, have subcomponents, and so on. Components are often “third party,” from another source, but might also be “first party,” that is, from the same supplier but able to be uniquely identified as a freestanding, trackable unit of software."
• It states on page 12 paragraph 2 "Depth. An SBOM should contain all primary (top level) components, with all their transitive dependencies listed."

In the case of any items such as test that you are missing out, you might be failing to comply with the license and/or copyright by not listing them.

A little simplistic, but it would only take the customer to look at the code in the product and ask why these packages are not listed in the SBOM.

My department analyses our companies products to ensure that we are complying with all the licenses and copyrights. It does prove a challenge when the development team argue that it is not used by the product so should not be there, particularly if it has a vulnerability.

My understanding is that this is what the Scope field in the SBOM components section is for. It allows the package to be listed in the SBOM and marked as Excluded as it is not used by the product.

I'd be interested in your thoughts on this. Cheers, N.

[DmitriyLewen]

Hi @nigellh,

Thanks a lot for the detailed follow-up and for the links to the NTIA document and the CycloneDX scope explanation.

First of all, Trivy is and always has been primarily a vulnerability scanner. SBOM generation was added later and is strongly aligned with that use case. For historical reasons, this means we focus on runtime dependencies – the ones that are actually present in the artifact at runtime and relevant for vulnerability scanning.

Today Trivy’s SBOM generation is therefore intentionally runtime-focused. For most ecosystems we only keep runtime dependencies and skip development / test / build dependencies (for example in pom.xml, *.deps.json, etc.), and we don’t currently populate the CycloneDX component.scope field. When scope is omitted, the CycloneDX spec says that consumers SHOULD assume required, so our current output is still valid from the CycloneDX point of view.

There is also a practical limitation on our side: in a number of scan modes the input we see (container images, file systems, certain lockfiles and metadata) simply does not contain enough information to reconstruct the full dependency graph. We can’t always reliably determine parent relationships between components, and even less whether a particular dependency is strictly required, optional, or only used in dev/test/build. In those cases, automatically assigning a precise scope would be more guesswork than fact.

I completely understand your use case, especially from a license and compliance perspective: if you treat “everything that is shipped to the customer” (including tests, tools, fixtures, etc.) as part of the deliverable, then you either
• want those components to appear in the SBOM with an appropriate scope such as excluded, or
• you want a separate SBOM that covers the wider build/test environment.

Right now Trivy does not distinguish component scopes in the SBOM and does not aim to be a complete “design/build SBOM” for the whole development environment – it’s closer to a deployment/runtime SBOM for the scanned artifact. For organizations that need the broader picture you may currently need to complement Trivy with additional tooling (for example, language-specific CycloneDX generators that include dev/test deps) or post-process Trivy’s output and enrich it with scope information from your build system.

At the same time, we already support a Dev field (and the --include-dev-deps flag) for some of the files we parse. For those cases it would indeed make sense to reflect that information via the CycloneDX scope field. We can also look at extending this and adding scope for other ecosystems as we broaden dev-dependency support.

Best regards,
Dmitriy

[nigellh]

Hi @DmitriyLewen

Wow thank you for the detailed answer and it helps greatly to understand this. It might be worth keeping in mind the Minimum elements report as the people who are using Trivy to generate an SBOM will be expecting it to match what this is requiring.

Thank you for the fantastic and quick responses. Much better than some other SBOM generating tools! ;-)