search

hughsie / uefi-sbom-best-practices

UEFI SBOM Best Practices
Creative Commons Attribution 4.0 International
1 stars 0 forks source link

General Best Practices #3

Open robert-ami opened 7 months ago

robert-ami commented 7 months ago

In the first sentence, it says that all component vendors SHOULD embed and that they MAY create a more detailed detached SBoM.

It goes on to then say firmware vendors MUST ensure embedded SBoM metadata is included. The wording here implies that the Component vendor doesn't have to provide SBoM info, but the Firmware Vendor has to provide the SBoM info for the component. This should require the Component to provide the SBoM data, whether embedded or not and then the FV can scrape or use that information to form the Firmware SBoM

I was playing with the wording, but haven't landed on the correct combination here. But, here is my first try:

All component vendors SHOULD embed an SBoM in the component image, formatted as described below ", but they MUST provide SBoM information for their Component. "

hughsie commented 7 months ago

I think what that was saying, perhaps in a roundabout way, was that if the component vendor didn't provide SBoM metadata for one reason or another then it was up to the firmware vendor to provide it. i.e. from an implementation practicality point of view not everyone is going to be embedding SBoM in components right from day 1, and it's up to the layer "above" to fix that and pass the displeasure back down for the next product revision.

robert-ami commented 7 months ago

I can understand that. But as you have said before, let's not let the Component Vendors off the hook. Because if you do, then they will avoid it. We all know that there will be a time of transition that will be painful for everyone. Let's make sure to put the onus on the right person here. Which is the Component owner for this item.

There will be times when they will not embed the data, maybe because it's an old binary, maybe they just don't want to, in those cases the information must still be provided.

hughsie commented 7 months ago

So maybe we push that onto the component vendor completely? e.g. 

-All *component vendors* **SHOULD** embed an SBoM in the component
+All *component vendors* **MUST** embed an SBoM in the component

... the should was originally when I figured that Intel wouldn't want to embed metadata in microcode, and now everyone (including the ucode team!) seems to want to embed it.

robert-ami commented 7 months ago

I think that whether we choose to make the information embedded or not is immaterial to me. But I think the Component Vendor MUST provide SBoM information. There should not be a case, once all this is commonplace, that the Firmware Vendor has to create the information. It should already be there in some fashion.

hughsie commented 7 months ago

But I think the Component Vendor MUST provide SBoM information.

Ideologically I agree with you.

that the Firmware Vendor has to create the information

Lets take an example. Lets say one OEM says "I'll give you $1M to produce an SBoM for this firmware so I can sell it to the US government" -- the platform was designed in 2022, and has been shipping for 2 quarters already. Intel hasn't committed to embedding the component SBoM in the ucode or FSP for platforms shipping this year -- and certainly won't be for near-EOL platforms -- so do we honestly ship an SBoM without the microcode and FSP components and throw our hands in the air and say "we did our best"?

I think the answer to that is no. Where the component vendor hasn't provided the data, or where the platform generation is using components that are too old to have an embedded component, the firmware vendor has to "fill in" the missing details. It's more work certainly, but I don't think we can say we've delivered a SBoM with literally 25% of the ingredients missing.

robert-ami commented 7 months ago

In your example, the component vendor has created code that doesn't have an SBoM embedded. I agree that they cannot go back and embed it. But they can provide SBoM information to the Firmware Vendor. And they should. It would be in some sort of file that is not part of the binary, but so would anything that the firmware vendor would create. This all goes back to who owns the component and therefore who should own the SBoM information for that Component. It is not the Firmware Vendor. They just provide a means for the SBoM information of the components to be available. And of course to provide SBoMs for any components that they own.

hughsie commented 7 months ago

But they can provide SBoM information to the Firmware Vendor

What if they say "no, the component is EOL"?

robert-ami commented 7 months ago

Then they have broken the chain. If they provide a component that is a binary, how is the FV to know what to put in the SBoM. The FV has no way to reliably know that what is used in that Component and therefore the SBoM is essentially useless if the FV has to create it for the Component owner. To use your term, it becomes just Theater.

hughsie commented 7 months ago

how is the FV to know what to put in the SBoM

In some cases, it's "ask the component vendor via email". In that case the tag-creator entity will be the firmware vendor, and the software-creator will be the component vendor for that specific identity. We know who wrote the SBoM entry, and we know it was a different entity to the creator.