RFC "2025 Minimum Elements for a Software Bill of Materials"

[Justin Cappos]

FYI: One thing we're pushing toward is the inclusion of in-toto
attestations in SBOMs, which would capture that information.  We've been
pushing for about a year now and there seems to be some support, but it's
still in the works.

Thanks,
Justin

On Wed, Oct 1, 2025 at 8:37 AM Arnout Engelen via rb-general <
rb-general at lists.reproducible-builds.org> wrote:

> On Wed, Oct 1, 2025, at 13:45, kpcyrd wrote:
>
> On 9/29/25 3:28 PM, Arnout Engelen via rb-general wrote:
> > Do you agree with the comments above? Are there any changes you'd like
> to see, or additional comments you think would be valuable to relay in the
> context of reproducible builds? The timeline is relatively strict: if we
> can get rough consensus before, say, Wednesday, I think we could respond
> "as the Reproducible Builds project".
>
> It's really close to "until Wednesday" already
>
>
> Yeah, I meant to share all this much earlier, but 'life happened'. Luckily
> the 'upstream' deadline is Friday, so we have *some* time :)
>
> As Holger mentioned it's perhaps a bit too short notice to arrive at a
> 'Position of the Reproducible Builds project', but perhaps we can comment
> with something like:
>
> ==
> This document summarizes the position of from various project
> representatives in the R-B project, namely:
>
>    - (...)
>    - Arnout Engelen for Reproducible Builds in the NixOS project
>    - (...)
>
> ==
>
> Let's say if we can get to '3' I'll post the comment?
>
> in my opinion a missed opportunity in the original SBOM standard was:
> > The build tools/compiler are a material of your software executable
>
> Knowing which exact compiler and compiler version was used is necessary
> for triaging certain security issues[1], and it's also critical
> information for any reproducible builds efforts.
>
> At the moment this gap is filled by buildinfo files (each project having
> their own):
>
> https://reproducible-builds.org/docs/recording/
>
>
> I agree having that information can be (in)valuable. More widely,
> realistically I think there's SBOMs for various use cases, and how far you
> go in declaring 'build-time context/dependencies' depends on the use case.
> Perhaps we could include this as a comment on the introduced 'Generation
> Context' field: we could confirm there are different kinds of context, and
> emphasize we believe that whether/which build-time dependencies you include
> depends on that context. Personally, I think it's to early to 'standardize'
> on such a field (I don't think there's any consensus what the exact meaning
> would be), so I would recommend to remove this field from the current
> version of the doc. We could also recommend adding a line saying the
> context can determine whether/which build-time dependencies should be
> included.
>
> Also to any CISA staff following this thread: hi! 😺
>
>
> 👋😃
>
>
> --
> Arnout Engelen
> Engelen Open Source
> https://engelen.eu
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20251001/ff414605/attachment.htm>