-
-
Notifications
You must be signed in to change notification settings - Fork 93
Embedded Systems build-systems such as Buildroot, Yocto or OpenWRT all have their own definition of a an 'external layer':
- Buildroot has 'externals'
- OpenWRT has 'feeds'
- Yocto has 'layers'
These external layers act as extensions that group together packages (translated into components in the sbom) and build metadata.
Multiple 'external layers' are composed together to provide the different 'component' and build a final firmware. When generating a CycloneDX SBOMs of the final image we want to be able to reference which 'external layer' provided a component.
After reading multiple time the spec I don't see any property of the component that could fit this description.
What we would do usually is define the build system under the metadata property and the layer that compose it under the metadata:components property:
{
"metadata": {
"type": "firmware",
"bom-ref": "buildroot",
"name": "buildroot",
"components": [
{
"type": "firmware",
"bom-ref": "layer1",
"name": "layer1",
},
{
"type": "firmware",
"bom-ref": "layer2",
"name": "layer2",
},
]
}
...
}What would be the proper way for a component to reference with a bom-link the layer that provided it ? I thought about supplier maybe but seems to fit more hardware stuff in general since we don't have any address to provide or maybe externalReferences but this would require an addition of a new type to suits the definiton of an 'external layer'.
All reactions
-
👀 1
Replies: 3 comments 1 reply
On note that may be important: The packages (components) from the external layer aren't necessarily packages developed by whoever is supplying the external layer. Of course they could be, but the external layer may simply package 3rd party software needed for the firmware, or as an in-between case custom patched versions of 3rd party software. Or a mix of all those.
The equivalent in traditional Linux distros would be to build a VM or container image and install things from additional (custom/3rd-party) package repositories.
All reactions
This could maybe be defined with distribution-intake https://cyclonedx.org/docs/1.7/json/#components_items_externalReferences_items_type
The location where a component was published to. This is often the same as "distribution" but may also include specialized publishing processes that act as an intermediary.
... "components": [ { "bom-ref": "pkg:a" "name": "a", "externalReferences": [ { "type": "distribution-intake", "url": "urn:cdx:<serial>/<number>#layer1" } ] ] ...
The distribution-intake definition could be extended or another externalReferences:type could be added to suit this use case better.
All reactions
I will research the Buildroot content of the idea of "externals". From a vulnerability management perspective what really counts is the ability to track that some developer's package somewhere in the world has reported a vulnerability for . Any complexity that gets in the way is to be eliminated. So for example if Buildroot declares my firmware uses "custom-package-XYZ" and the vulnerability is in the libxz library then vulnerability scanners will report on the vulnerability with libxz. We need to be certain that Buildroot will additionally report the defect in that specific custom-package-XYZ for matching in vulnerability scanners. This discussion 720 must recognize the multi level vulnerability reporting to be effective. Comments most welcome because I am not yet deeply familiar with the use of these "package" additions into a Buildroot targeted board support package.
All reactions
I will research the Buildroot content of the idea of "externals"
'externals' can be seen as what Debian would call 'PPA'. It's a way for users to provides packages that are not part of the core repository.
From a vulnerability management perspective what really counts is the ability to track that some developer's package somewhere in the world has reported a vulnerability for.
Yes this is already supported. See https://gitlab.com/buildroot.org/buildroot/-/blob/master/utils/generate-cyclonedx
Any complexity that gets in the way is to be eliminated.
This 'additional complexity' is a feature Buildroot users actually want to see inside the generated SBOM. It makes the traceability of the packages possible for consumers of the SBOM. The infra to trace this is already present (see https://patchwork.ozlabs.org/project/buildroot/list/?series=471490). But since this kind of mechanism is not only related to the Buildroot project, I just want to make sure we place it in the correct location in accordance to what the CycloneDX spec provides.
So again this is not really related to vulnerability reporting since it's already in place, more about provinding the package metadata at the correct place.
All reactions
-
👍 1