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 (#4418): https://lists.spdx.org/g/Spdx-tech/message/4418 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]] -=-=-=-=-=-=-=-=-=-=-=-
