Sounds good! I'll get those times to you! On Tue, Apr 5, 2022 at 9:21 AM Kate Stewart <[email protected]> wrote:
> Hi Brandon, > > Invitation was sent directly to those who filled in the participation > survey. It's in addition to our regular meeting, with a specific purpose > to help close the 3.0 model punchlist with key stakeholders being present > to make progress. > > I suggest we aim for a spot later that day, or the following week as > it may be a different audience interested in the topic. Send me 1:1 > some options that work for you and I'll start a doodle off on a separate > thread, and we can collect those interested in working on the build profile > definition, then set up an initial meeting. > That work as a plan? > > Thanks, > Kate > > > On Tue, Apr 5, 2022 at 7:58 AM Brandon Lum via lists.spdx.org <lumb= > [email protected]> wrote: > >> Ah - I somehow am missing these calendar events! >> >> Would you propose that we can discuss this during the 3.0 meeting or try >> and find a new day to chat about this? >> >> On Tue, Apr 5, 2022 at 8:54 AM Martin, Robert A <[email protected]> >> wrote: >> >>> Brandon, >>> >>> There is already an SPDX 3.0 working session scheduled for the 15th of >>> April (11am-2pm eastern). >>> >>> Bob >>> >>> Robert (Bob) Martin >>> Sr. Software and Supply Chain Assurance Principal Eng. >>> Cross Cutting Solutions and Innovation Dept >>> Cyber Solutions Innovation Center >>> MITRE Labs >>> MITRE Corporation >>> 781-271-3001o >>> 781-424-4095c >>> >>> On 4/4/22 2:28 PM, Brandon Lum via lists.spdx.org wrote: >>> >>> Hi William, >>> >>> We don't have a brainstorming session planned yet - but we should!! I >>> believe Steve and Kate have been working through some of this as well. Let >>> me find some time for us to get together and put something together! *How >>> are folks for 15 April (Friday) for a discussion? * >>> >>> I am in agreement with you 100% on making sure this is aligned with SLSA >>> and in-toto! (I am actually writing a blog post on some synergies as we >>> speak!) >>> >>> I like the BuildRun idea (and maybe that's also orthogonal to the build >>> profiles that Nisha mentioned). Also, I do appreciate your specificity in >>> laying out the idea concretely :). >>> >>> One thing that I was thinking to add is also the Builder information/URI >>> (or maybe that's already encodable in the env/metadata). Think its worth >>> calling out since that's the identifier for attestations. Since the >>> BuildRun document may not necessarily be generated by the organization that >>> asked for the build - i.e. calling out to github actions/travisCI, it would >>> allow us to also reason about compromises. >>> >>> Another thought that was brought up in some conversations is that we >>> could also point to/reference certain documents where appropriate. Still >>> very half baked, but along the lines of thinking about leveraging some >>> SLSA/intoto efforts out there without potentially duplicating efforts. >>> >>> On Mon, Apr 4, 2022 at 1:53 PM William Bartholomew (CELA) < >>> [email protected]> wrote: >>> >>>> Hey Brandon and Nisha, >>>> >>>> >>>> >>>> There are people from Microsoft that would probably be interested in >>>> participating in this discussion, are you considering doing some >>>> brainstorming sessions? >>>> >>>> >>>> >>>> In my mind I’ve always imagined the pedigree information (which build >>>> would be a part of) as defining new both new element types and potentially >>>> new relationship types (although I think we might have most of these >>>> covered already). I’d also want to ensure that anything we do here can >>>> integrate with in-toto/SLSA attestations. >>>> >>>> >>>> >>>> If I take an example in SPDX today (bar-0.1 is a static library >>>> consumed to consume the foo-1.0 package): >>>> >>>> (File:foo.c, File:foo.h, File:bar.lib, File:bar.h)--[:GENERATES]--> >>>> File:foo >>>> >>>> (File:bar.c, File:bar.h)--[:GENERATES]-->File:bar.lib >>>> >>>> (File:bar.lib, File:bar.h)--[:CONTAINED_IN]-->File:bar-0.1.tgz >>>> >>>> Package:bar-0.1--[:DISTRIBUTION_ARTIFACT]-->File:bar0.1.tgz >>>> >>>> Package:bar-0.1--[:BUILD_DEPENDENCY_OF]-->Package:foo-1.0 >>>> >>>> (File:foo)--[:CONTAINED_IN]-->File:foo-1.0.tgz >>>> >>>> Package:foo-1.0--[:DISTRIBUTION_ARTIFACT]-->File:foo-1.0.tgz >>>> >>>> >>>> >>>> I can trace the integrity of all of the build artifacts (based on their >>>> hashes) but I don’t know anything about the build environment or build >>>> environments that produced them. I don’t know if bar and foo were built in >>>> the same build process or by different build processes and, if the builds >>>> were fully reproducible, I may not even know which instance of a build >>>> produced them (because the input and output hashes would be the same). I >>>> may be able to assume some of this information based on the pedigree of the >>>> SPDX document (such as who created it and signed it) but that’s an >>>> inference and still lacks interesting detail. >>>> >>>> >>>> >>>> In SLSA attestation there is a statement (made up of a subject and a >>>> predicate) and an envelope (made up of the statement and a signature). The >>>> predicate is a claim that the signer is making about the subject, such as, >>>> this artifact was built by a specific instance of a build process that has >>>> these attributes and used these inputs. This model maps quite nicely on to >>>> SPDX where subjects are references to an SPDX element (typically something >>>> derived from Artifact), the predicate is a subclass of Element that >>>> describes the claim being made, and we have a signature over the document >>>> (or in the future individual elements). We also have the ability to track >>>> creator independently of signer using the “createdBy” from Element to >>>> Identity. >>>> >>>> >>>> >>>> Some of the content in SPDX is already an attestation (or more meta it >>>> *all* is), for example, an Annotation is a predicate containing a type >>>> and a textual statement and it is linked to a subject by the “subject” >>>> property. Similarly, license and vulnerability information are attestations >>>> about artifacts. More meta, relationships are also attestations (this is >>>> one of the reasons I wanted them to inherit from Element), they are a >>>> predicate that describes the type of relationship and what the relationship >>>> is to (the From is the subject of the statement in this case). >>>> >>>> >>>> >>>> So going back to the example above what we want is a predicate that >>>> describes an instance of a build, so we can define a new BuildRun or >>>> BuildInstance class, that inherits from Element (or possibly Artifact, I’d >>>> have to think about that some more – somewhere that Sean’s definitions >>>> would help 😊). That would then let us extend the graph above: >>>> >>>> (File:foo.c, File:foo.h, File:bar.lib, File:bar.h)--[:GENERATES]--> >>>> File:foo >>>> >>>> (File:bar.c, File:bar.h)--[:GENERATES]-->File:bar.lib >>>> >>>> (File:bar.lib, File:bar.h)--[:CONTAINED_IN]-->File:bar-0.1.tgz >>>> >>>> Package:bar-0.1--[:DISTRIBUTION_ARTIFACT]-->File:bar0.1.tgz >>>> >>>> Package:bar-0.1--[:BUILD_DEPENDENCY_OF]-->Package:foo-1.0 >>>> >>>> (File:foo)--[:CONTAINED_IN]-->File:foo-1.0.tgz >>>> >>>> Package:foo-1.0--[:DISTRIBUTION_ARTIFACT]-->File:foo-1.0.tgz >>>> >>>> >>>> >>>> # I chose to include both the Package and the package’s distribution >>>> artifact to establish a stronger link to the physical files consumed and >>>> produced, but there’s other ways this could be modeled. For example, if >>>> this was consuming a git repository containing foo.c and foo.h then the >>>> commit can be modeled as a Package which the build DEPENDS_ON. >>>> >>>> BuildRun:run_123--[:DEPENDS_ON]-->(Package:bar-01, File:bar-0.1.tgz, >>>> File:foo.c, File:foo.h) >>>> >>>> BuildRun:run_123--[:GENERATES]-->(Package:foo-1.0, File:foo-1.0.tgz) >>>> >>>> Package:gcc-9.4.0--[:BUILD_TOOL_OF]-->BuildRun:run_123 >>>> >>>> >>>> >>>> # We could add properties to BuildRun to capture any necessary >>>> information (this needs to be modeled to have the right level of >>>> abstraction and flexibility) >>>> >>>> BuildRun: >>>> >>>> environment: Map<string, string> >>>> >>>> command_line: String >>>> >>>> stdout: String >>>> >>>> stderr: String >>>> >>>> >>>> >>>> In this example we can see that the BuildRun:run_123 consumed a >>>> pre-build bar package and used gcc 9.4.0 so we have additional context we >>>> didn’t have before, if bar was built from source from the repo in the same >>>> build as foo we’d see a graph more like this: >>>> >>>> BuildRun:run_123--[:DEPENDS_ON]-->(File:bar.c, File:bar.h, File:foo.c, >>>> File:foo.h) >>>> >>>> BuildRun:run_123--[:GENERATES]-->(Package:foo-1.0, File:foo-1.0.tgz) >>>> >>>> Package:gcc-9.4.0--[:BUILD_TOOL_OF]-->BuildRun:run_123 >>>> >>>> >>>> >>>> >>>> >>>> Regards, >>>> >>>> >>>> >>>> William Bartholomew (he/him) – Let’s chat >>>> <https://outlook.office.com/findtime/[email protected]&anonymous&ep=plink> >>>> >>>> Principal Security Strategist >>>> >>>> Global Cybersecurity Policy – Microsoft >>>> >>>> >>>> >>>> *My working day may not be your working day. Please don’t feel obliged >>>> to reply to this e-mail outside of your normal working hours.* >>>> >>>> >>>> >>>> *From:* [email protected] <[email protected]> *On Behalf >>>> Of *Brandon Lum via lists.spdx.org >>>> *Sent:* Saturday, April 2, 2022 12:49 PM >>>> *To:* Nisha Kumar <[email protected]> <[email protected]> >>>> *Cc:* [email protected] >>>> *Subject:* [EXTERNAL] Re: [spdx-tech] Adding Build SBOM relationships >>>> for S3C resiliency >>>> >>>> >>>> >>>> You don't often get email from [email protected]. Learn >>>> why this is important <http://aka.ms/LearnAboutSenderIdentification> >>>> >>>> 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 >>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.spdx.org%2F&data=04%7C01%7Cwillbar%40microsoft.com%7Cbbca7b884a574f49227e08da14e1ce27%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637845257327869976%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=i51a0OaJZnH0WiN3PZDk8MTYw%2FVGaV3NOft1QdbDpI8%3D&reserved=0> >>>> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fslsa.dev%2F&data=04%7C01%7Cwillbar%40microsoft.com%7Cbbca7b884a574f49227e08da14e1ce27%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637845257327869976%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8Wct%2B620KkVi3DyDLXi%2FFFr0ea57y8l%2BUqv0J23zMcg%3D&reserved=0> >>>> : >>>> >>>> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fspdx.github.io%2Fspdx-spec%2Frelationships-between-SPDX-elements%2F&data=04%7C01%7Cwillbar%40microsoft.com%7Cbbca7b884a574f49227e08da14e1ce27%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637845257327869976%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ckGxOGqZP20DXzxgGPuUt5g3J5uitWtTtR4T3hPU8gk%3D&reserved=0>) >>>> 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/ >>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fspdx.github.io%2Fspdx-spec%2Frelationships-between-SPDX-elements%2F&data=04%7C01%7Cwillbar%40microsoft.com%7Cbbca7b884a574f49227e08da14e1ce27%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637845257327869976%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ckGxOGqZP20DXzxgGPuUt5g3J5uitWtTtR4T3hPU8gk%3D&reserved=0>, >>>> 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 (#4447): https://lists.spdx.org/g/Spdx-tech/message/4447 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]] -=-=-=-=-=-=-=-=-=-=-=-
