Hey Nisha, Yes - exactly!! Curious to hear what some ideas are around a "build profile"! Would this be along the lines of another element/document that would be referenced? or maybe kind of like the defects vulnerability ref documents?
Another aspect that I'm hoping to explore - is being able to put together SBOM documents which are not directly linked to each other. I.e. in the situation where there is a known unknown that a build was using Package ABC with hash XYZ, would it be possible to fill in the gaps by finding the SBOM document with the binary hash XYZ, and adding references to the document (or composing the documents). Cheers Brandon On Tue, Mar 29, 2022 at 11:18 AM Nisha Kumar <[email protected]> wrote: > Hi Brandon, > > Sorry for getting back to you so late. I've been thinking of an SPDX 3.0 > profile that would contain software build information like what you have > described in 1., but it seems to me from previous conversations that the > information could be covered using relationships such as BUILD_TOOL_OF and > GENERATED_FROM. However, things like "build environment" (like VMs and > containers) and build flags are not part of relationships. I think it would > be useful to define some new relationships based on these considerations as > part of a "build profile". > > Thoughts? > > -Nisha > On 3/17/22 07:41, Brandon Lum via lists.spdx.org wrote: > > Hi All, > > I've been exploring ideas in the build provenance realm, and I think there > are some ideas there that could be useful to incorporate into SPDX. I > wanted to get a sense if folks are interested, and would love to work on > something for this! > > Some of the ideas from build provenance (I'm going to frame it around the > security use case since that's what I'm most familiar with). These are > mostly orthogonal concepts to those of the SLSA framework > <https://slsa.dev/>: > 1. What is the toolchain used to build this binary/artifact (in the event > where a compromised compiler, build container, etc. is detected) > 2. What/who is the builder that was used to build this binary/artifact (in > the event where a build system gets compromised - e.g. CI/CD like github > actions, travis, circle CI is compromised), with the ability to respond to > breach. > 3. (Already part of SPDX relationship between elements > <https://spdx.github.io/spdx-spec/relationships-between-SPDX-elements/>) > What are the materials that were used to build this binary/artifact > 4. (Already covered by proposed canonicalisation committee) Integrity > validation/provenance of claims of binary/artifact > > I think there could potentially be a place to define some of these in > SPDX, maybe through adding more relationships to > https://spdx.github.io/spdx-spec/relationships-between-SPDX-elements/, or > otherwise. > > Would like to hear thoughts/interest from folks! > > On a side note: I am also interested in getting more into the tooling side > of Build SBOMs (and distribution/resolution of). Would love to chat with > anyone that's working on it - I'm hoping to define some projects around > this! > > Cheers > Brandon > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4435): https://lists.spdx.org/g/Spdx-tech/message/4435 Mute This Topic: https://lists.spdx.org/mt/89846631/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
