Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add more documentation around components[].scope #293

Closed
noqcks opened this issue Sep 10, 2023 · 4 comments
Closed

Add more documentation around components[].scope #293

noqcks opened this issue Sep 10, 2023 · 4 comments
Assignees
Milestone

Comments

@noqcks
Copy link

noqcks commented Sep 10, 2023

The CycloneDX standard includes a scope attribute for each component:

image

I am confused about when one should use required, optional or excluded when generating an entry for a component. Are there any examples? Could the description be altered to make this more clear?

@stevespringett stevespringett added this to the 1.6 milestone Sep 11, 2023
@stevespringett stevespringett self-assigned this Sep 11, 2023
@prabhu
Copy link
Contributor

prabhu commented Dec 24, 2023

This attribute can be deprecated in favor of evidence. The presence of an occurrence or a call stack evidence is proof that the component is definitely required. All other components could be treated as unknown to keep it safe.

Example:

consider CVE-2023-4910. Typically unit test files would be treated as a dev dependency and therefore as scope optional. However, there is direct occurrence evidence (even with an SBOM with a post-build lifecycle) so this component must be considered as required. However, the evidence alone is enough instead of setting another redundant attribute.

https://www.malwarebytes.com/blog/news/2023/11/owncloud-vulnerability-can-be-used-to-extract-admin-passwords

@stevespringett
Copy link
Member

scope is a way to include a component but not assert that that component is delivered or included in the inventory. For example, you may want to include Windows XP Embedded as a component, mark the scope as excluded, as a way to indicate that the entire stack will include the OS, but that the supplier does not provide it with the software. There is ongoing discussions within CISA on how to specify runtime requirements. Expect this capability to expand in the future.

@stevespringett
Copy link
Member

With that said, we will expand the documentation for v1.6. Thanks for the suggestion.

@jkowalleck
Copy link
Member

jkowalleck commented Feb 8, 2024

JSON was fixed via d92e58e

XML and ProtoBuf already had the needed docs,
see

<xs:simpleType name="scope">
<xs:restriction base="xs:string">
<xs:enumeration value="required">
<xs:annotation>
<xs:documentation>The component is required for runtime</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="optional">
<xs:annotation>
<xs:documentation>The component is optional at runtime. Optional components are components that
are not capable of being called due to them not be 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'.</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="excluded">
<xs:annotation>
<xs:documentation>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.</xs:documentation>
</xs:annotation>
</xs:enumeration>
</xs:restriction>
</xs:simpleType>

@jkowalleck jkowalleck reopened this Feb 8, 2024
@jkowalleck jkowalleck mentioned this issue Feb 8, 2024
stevespringett added a commit that referenced this issue Apr 9, 2024
## Added

* Core enhancement: Attestation
([#192](#192) via
[#348](#348))
* Core enhancement: Cryptography Bill of Materials — CBOM
([#171](#171),
[#291](#291) via
[#347](#347))
* Feature to express the URL to source distribution
([#98](#98) via
[#269](#269))
* Feature to express the URL to RFC 9116 compliant documents
([#380](#380) via
[#381](#381))
* Feature to express tags/keywords for services and components (via
[#383](#383))
* Feature to express details for component authors
([#335](#335) via
[#379](#379))
* Feature to express details for component and BOM manufacturer
([#346](#346) via
[#379](#379))
* Feature to express communicate concluded values from observed
evidences ([#411](#411)
via [#412](#412))
* Features to express license acknowledgement
([#407](#407) via
[#408](#408))
* Feature to express environmental consideration information for model
cards ([#396](#396) via
[#395](#395))
* Feature to express the address of organizational entities (via
[#395](#395))
* Feature to express additional component identifiers: Universal Bill Of
Receipts Identifier and Software Heritage persistent IDs
([#413](#413) via
[#414](#414))

## Fixed

* Allow multiple evidence identities by XML/JSON schema
([#272](#272) via
[#359](#359))
  This was already correct via ProtoBuff schema.
* Prevent empty `license` entities by XML schema
([#288](#288) via
[#292](#292))
  This was already correct in JSON/ProtoBuff schema.
* Prevent empty or malformed `property` entities by JSON schema
([#371](#371) via
[#375](#375))
  This was already correct in XML/ProtoBuff schema.
* Allow multiple `licenses` in `Metadata` by ProtoBuff schema
([#264](#264) via
[#401](#401))
  This was already correct in XML/JSON schema.

## Changed

* Allow arbitrary `$schema` values by JSON schema
([#402](#402) via
[#403](#403))
* Increased max length of `versionRange` (via
[`3e01ce6`](3e01ce6))
* Harmonized length of `version` (via
[#417](#417))

## Deprecated

* Data model "Component"'s field `author` was deprecated. (via
[#379](#379))
  Use field `authors` or field `manufacturer` instead.
* Data model "Metadata"'s field `manufacture` was deprecated.
([#346](#346) via
[#379](#379))
  Use "Metadata"'s field `component`'s field `manufacturer` instead. 
  - for XML: `/bom/metadata/component/manufacturer`
  - for JSON: `$.metadata.component.manufacturer`
  - for ProtoBuf: `Bom:metadata.component.manufacturer`

## Documentation

* Centralize version and version-range (via
[#322](#322))
* Streamlined SPDX expression related descriptions (via
[#327](#327))
* Enhanced descriptions of `bom-ref`/`refType`
([#336](#336) via
[#344](#344))
* Enhanced readability of enum documentation in JSON schema
([#361](#361) via
[#362](#362))
* Fixed typo "compliment" -> "complement" (via
[#369](#369))
* Added documentation for enum "ComponentScope"'s values in JSON schema
([#293](#293) via
[`d92e58e`](d92e58e))
  Texts were a taken from the existing ones in XML/ProtoBuff schema.
* Added documentation for enum "TaskType"'s values
([#245](#245) via
[#377](#377))
* Improve documentation for data model "Metadata"'s field `licenses`
([#273](#273) via
[#378](#378))
* Added documentation for enum "MachineLearningApproachType"'s values
([#351](#351) via
[#416](#416))
* Rephrased some texts here and there.

## Test data

* Added test data for newly added use cases
* Added quality assurance for our ProtoBuf schemas
([#384](#384) via
[#385](#385))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants