WEBVTT 00:00.000 --> 00:14.480 All right, thank you. So welcome everybody. Yeah, there is not much more left. I also have 00:14.480 --> 00:24.320 a couple of slides for you still. About as bombs. And about what the open chain tackle 00:24.320 --> 00:29.600 as bomb a guide is covering and what the open chain tackle working group is working on. 00:33.360 --> 00:39.120 This presentation was supposed to be given by my colleague who is actually leading the open 00:39.120 --> 00:46.160 chain tackle working group, but unfortunately he got six. So I am jumping in and I'm basically 00:46.160 --> 00:54.000 power point karaoke the slides, but I'm happy to take any comments and questions of course also. 00:54.720 --> 00:58.320 Let's talk first about the open chain project. Maybe it's not clear for everybody what the 00:58.320 --> 01:08.080 open chain project is doing. The open chain project is building let's say a set of rules 01:08.080 --> 01:16.240 how different actors of the supply chain should let's state about themselves that they are 01:16.240 --> 01:26.160 following compliance process and it is an ISO standard and you can have a certification and 01:26.160 --> 01:34.320 you can look and say that you are compliant with the open chain specifications. And this is a 01:34.320 --> 01:41.200 very good way to show that the organization has like solid compliant processes and as we are 01:41.200 --> 01:46.640 publishing or or compliance it's a very good way to see that your partners are actually having 01:47.680 --> 01:54.320 a comprehensive process. The open chain project also hosts a couple of working groups which are 01:54.320 --> 02:00.880 working on different topics than the actual pension specification and one of these working groups 02:00.880 --> 02:07.120 is the tackle working group. We have other working groups like automation and as one working 02:07.200 --> 02:12.560 group we have an AI working group so the list is very long. If you are interested in an 02:12.560 --> 02:18.880 open source compliance or S-bombs and such things I would highly recommend to check out 02:19.680 --> 02:26.640 open chain and join the communities which are interesting for you there. But now I will focus 02:26.640 --> 02:38.000 on the work of the the the tackle working group and this working group was started by EME 02:38.000 --> 02:47.120 who is in yes in the room so thanks for that and the aim was to sit together members of the 02:47.120 --> 02:55.840 tech industry as specify an S-bombs format for ourselves. Why do we need that? It was presented 02:55.840 --> 03:03.600 I think two talks ago that everybody asks a different type of S-bombs from us and that is a 03:03.600 --> 03:07.920 problem because we don't want to send a different type of S-bombs to each and every 03:09.040 --> 03:15.600 customer and each and every country we would like to have like a consolidated set of requirements 03:15.600 --> 03:22.480 what an S-bombs should fulfill and we would like to use that as a basis so this is actually the 03:24.320 --> 03:31.040 the minimal set what was mentioned in that previous presentation that's what we are aiming to do in 03:31.040 --> 03:44.080 this open chain tackle working group. Yes it's an open source community we have mailing list we do 03:45.040 --> 03:53.440 poor requests and all of that so the consensus is made using the GitHub GitHub process 03:54.000 --> 03:59.040 so it's not it's it's a public specification group basically using open source 03:59.040 --> 04:04.240 methodologies and actually we're using also open source license so it's an open source specification 04:04.240 --> 04:12.240 group again if you're interested in this work join the the mailing list we have regular meetings 04:13.200 --> 04:18.400 we discussed things on the mailing list and so on so it's like it is a commodity 04:21.760 --> 04:26.640 and as a result of the work of this group we created the specifications so we wanted to have 04:26.640 --> 04:32.400 something and this is already out there we have the version 1.0 of the specification out 04:34.560 --> 04:36.320 and we have 04:37.280 --> 04:42.720 we translated it into several languages and so on and so on but like we can you can check it from 04:42.720 --> 04:54.000 the link which is provided in the presentation and you can read it but I will now outline 04:54.560 --> 05:01.600 couple of points here what is specified in the in the guide and of course like as this is a 05:01.600 --> 05:10.160 specification of of a specific format this is an opportunity to think so we have decisions made here 05:10.160 --> 05:16.240 and of course some people have different opinions and that's totally okay for example we decided on 05:16.240 --> 05:26.720 SPDX and 2.3 version of SPDX because like we had like to also discussions about this but that's the 05:27.440 --> 05:39.600 that's what the the questions was became in the group and we are following the couple of like 05:39.600 --> 05:46.640 other guidelines like the NTA, the minimum requirements and we are also following the CSI S bomb dice 05:46.640 --> 05:55.840 which we were also discussed here before in the in the room and just couple of examples which kind of 05:55.920 --> 06:04.480 things are defined here I don't want to go through all of the things but for example for the whole 06:04.480 --> 06:12.400 for the whole S bomb we need to know like which organization created the S bomb so who is 06:12.400 --> 06:19.600 that's responsible for the S bomb we also require a dimensioning of the tool and the version which was used 06:19.600 --> 06:28.800 to create the the S bomb and we have this like CSI S bomb type like we discussed this for the 06:28.800 --> 06:37.120 in a previous presentation like if it's the source S bomb or or this is coming by normalizing the 06:37.120 --> 06:42.080 artifacts so there are several types six types defined by CSI and you have to define that also 06:42.720 --> 06:49.280 in the in the creation information of the of the S bomb and for each and every package you also 06:49.280 --> 06:56.720 have a couple of things which we require and like we discussed this again in a previous presentation 06:56.720 --> 07:03.920 that the package URL is is something what everybody would like to have in an S bomb so we we have 07:03.920 --> 07:09.760 it as a requirement that that we should have the package URL as a part of the of the S bomb but 07:09.760 --> 07:16.480 we also require a couple of method data most of them are coming from the anti i requirements so 07:16.480 --> 07:28.240 we try to keep the requirements minimal which are added on top of other requirements how complete 07:28.240 --> 07:35.440 S bomb should be and all the commandation is that it should be a complete S bomb I know that the 07:36.000 --> 07:41.920 requires only the top level of the dependencies and so on but eventually everybody will need 07:41.920 --> 07:47.440 the whole package and this nice figure what I put here by the way it's a it's a different representation 07:47.440 --> 07:56.400 of what Gawork showed us in his presentation this is the the Q and S dependency 3 I got it from 07:56.480 --> 08:05.680 that's on dev that's dot dev but you have to have everything and I also wish that we would have 08:05.680 --> 08:12.160 the known unknowns it's not in this specs yet but I think we also should have that and that was also 08:12.160 --> 08:26.160 discussed in a previous presentation okay so yeah of course we are requiring that the S bomb should be 08:26.480 --> 08:40.240 signed and the guide allows you to construct your S bomb from different S bomb files so you can 08:40.240 --> 08:46.080 like have different pieces and you can define relationships between these these files there's 08:46.080 --> 08:56.160 BDX standard allows you to to do that and we also allow that the S bomb are handled as a 08:56.160 --> 09:01.120 confidential information it's not a format thing but it's more like an agreement between between 09:01.120 --> 09:08.640 companies because the S bomb is actually exposing a high level information of the structure of a 09:08.640 --> 09:13.200 product and the vulnerabilities of product so it's not very good if like somebody publishes 09:13.840 --> 09:27.440 this list and the work is ongoing so we are now working on the one point one version of the 09:27.440 --> 09:34.960 of the specification after using 1.0 we got lots of feedback from the industry so we are now 09:35.520 --> 09:41.600 incorporating that feedback and of course like we are also like trying to move forward 09:42.560 --> 09:50.800 we do not plan to move as with the X3 yet we feel that there is not enough industry adoption yet 09:50.800 --> 09:58.960 so we are still waiting with that step but we plan to have like a couple of small fixes in in 1.1 09:58.960 --> 10:07.680 basically and the S cell like if you do not agree on the on the specs I know that some people 10:08.320 --> 10:13.840 have come as that is totally okay this is why we created this whole work like to have a space 10:13.840 --> 10:21.840 to discuss and agree on on what kind of S bomb we would like to have of course you can join 10:21.840 --> 10:28.240 to the community you can be part of the of the of the discussion or if you don't want to spend 10:28.240 --> 10:35.120 the time on on on meetings and all of that you can just file an issue and start discussion on 10:35.120 --> 10:45.440 it are both of them are totally okay and then we started to think okay now we have this nice 10:45.440 --> 10:50.400 set of rules but how do we know if an S bomb is compliant with this like do we ask people to 10:50.400 --> 10:56.720 go through unlike I don't know hundreds of megabytes of of SPD accent and check and we decided 10:56.720 --> 11:05.520 now it's not a nice way to spend people's time so we created a small Python program which 11:06.320 --> 11:15.120 validates an S bomb against these rules this really data is working in a way that it's a library 11:15.120 --> 11:26.080 and it is it has a sealer interface also so if you would like to use it in a CSD pipeline and 11:26.160 --> 11:31.760 use it as part of another Python script it's also possible but if you are just from a 11:31.760 --> 11:39.360 use it from the CLI then you can do that plus it has features to extend the rules so if you would 11:39.360 --> 11:48.800 like to have additional rules on top of the the open-chain tech or specs you can write your own 11:48.800 --> 11:55.200 additional validation rules as functions and you can just add them to the valid data and it will 11:55.200 --> 12:04.480 execute your rules also as part of the of devolidation again if you try it out and you think that 12:04.480 --> 12:12.720 it's it's not working correctly then you can file an issue and of course all contribution 12:12.720 --> 12:19.200 contributions are welcome it's is written in Python and it's heavy relies on of course 12:21.280 --> 12:27.840 the anti-evilidator and it also relies on the on the SPDX Python library 12:30.400 --> 12:39.680 yeah and it looks like this maybe we can even have a short demo if time alone is this visible 12:43.600 --> 12:50.960 then somebody have to tell me how to make this bigger now like this okay cool now I learned 12:53.040 --> 13:00.720 all right so yes and I think I mentioned also that it's beep installable so you can now you can 13:00.720 --> 13:09.040 get it via a pip install so now I have a test as boom here and like this is this kind of result 13:09.040 --> 13:16.320 what you get via the CLI so it does you like what kind of errors you have like we have six 13:16.320 --> 13:24.320 categories of errors it gives you the SPDX ID where the problem is and it gives you a description 13:24.320 --> 13:30.320 what what the problem is a big look for an okay execution 13:30.960 --> 13:39.280 like it is it's basically a method test because we are now running it against its own SPDX 13:40.320 --> 13:46.320 then then it says that it's it's just okay and of course we will add the the logic to the 13:46.320 --> 13:51.440 very data case one dot one once the specification for one dot one is is released 13:51.840 --> 14:07.840 now I should remember how do I jump like this okay that is it any questions or comments 14:11.040 --> 14:19.280 so I was aware of this and my comment was why had he chosen a format rather than a content 14:19.280 --> 14:27.040 and I think we saw that with talk early this afternoon is I think we need to be focusing 14:27.040 --> 14:33.280 on content well and another reason he chose SPDX was because it was nice so standard 14:34.000 --> 14:39.280 well he's also an act with standard as well for cycling dx so but nationally we want back 14:39.280 --> 14:48.320 flexibility because and we interrupt a ability of s-bombs is crucial for the adoption 14:48.400 --> 14:54.640 and we saw that with t as well so I think going forward I think I'd only find what attributes 14:54.640 --> 15:00.080 the minimum requirements you have find will keep away from it being particular format 15:01.920 --> 15:09.120 and because the content if the content is important not whether it's JSON or tag or whatever 15:09.120 --> 15:16.640 yes it's a very point the comment was that or the question maybe that why did we decide 15:16.640 --> 15:22.080 to select a format instead of defining the content and it's a very valid point and there 15:22.080 --> 15:27.040 is now a work ongoing in open chain in the s-bombs working group to define exactly that like 15:27.840 --> 15:33.920 elevating it to one higher up social level and what I think will happen but it's we didn't 15:33.920 --> 15:42.080 discuss it yet in the tech working group is that we will join to that work and define the content 15:43.040 --> 15:48.400 but eventually we will need a format so we will need to send files 15:56.560 --> 16:02.640 absolutely yes yeah what we need to sort of both that's the that's the point yes but that's a very 16:02.640 --> 16:11.200 valid point we should yeah I'm part of the group so I can understand yeah help yeah there's a lot 16:11.200 --> 16:21.440 of stuff already there so maybe maybe stick yeah yes but that's that's where it's point I think 16:21.440 --> 16:26.560 work work we're continuing so as I said like it was started just to address these issues and 16:26.560 --> 16:32.160 discuss about them and I think this is one discussion point what we should like use to 16:32.800 --> 16:39.920 make the work more more useful there is one question there yes the tool and how you answer to this 16:41.200 --> 16:46.240 the tool does not evaluate completeness very good question we discussed this in the tooling workshop 16:46.240 --> 16:55.440 on Friday currently there is no tool which analyzes completeness of fashpom I just learned 16:55.440 --> 17:02.000 that there there was a plug fest to test stuff for computationalized tools and they 17:02.800 --> 17:10.320 provided a set of artifacts and you could drive your tool against them so there is now some 17:10.320 --> 17:17.440 work on going to figure out like which tool is better than the other in terms of like completeness of 17:17.440 --> 17:23.600 the espom but it's not not a thing what you can objectively measure without comparing the tools 17:23.680 --> 17:28.960 to each other so the purpose of the plug fest was not to say two layers better than two be 17:30.160 --> 17:35.200 because actually the one as many tools as possible but are all as good as the each other 17:36.000 --> 17:42.880 yeah I think what purpose are they just finding out giving it content how easy was it for 17:42.880 --> 17:48.880 it depending on which language ecosystem what's that content readily available and we saw 17:48.960 --> 17:58.000 as we put earlier on this seems very poor yes it was very good jar of a script was in the 17:58.000 --> 18:03.280 middle type of thing so it's more about where we are with the languages at the moment I think what 18:03.280 --> 18:09.120 we need to start having the discussion about is polyglot because increasingly we have projects 18:09.120 --> 18:16.880 that are multiple languages or and products on multiple languages so rather than just pulling the 18:16.880 --> 18:21.840 Python aspects we need to see aspects and the worst aspects at the same time the tools are there 18:21.840 --> 18:34.000 yet yeah absolutely so there is a data set yeah yeah so the question also I forgot to repeat 18:34.000 --> 18:38.000 the question the question was that if the tool is testing for completeness of this one 18:38.080 --> 18:44.880 thus there is no the tool is checking only the like syntax and semantics of the expeditions file 18:45.440 --> 18:52.160 and we discussed also that there is a data set available but it's more about the different 18:52.160 --> 18:59.040 ecosystems not about the tools themselves and the other comments or questions 18:59.040 --> 19:10.560 this is a pet pee but I see so many presentations and presentations about 19:10.560 --> 19:18.960 that's poem saying oh we need a digital signature and my question is with what and how do 19:18.960 --> 19:25.440 we validate by data I want to give the digital singer to your person this is like in the web 19:25.600 --> 19:32.880 to one single company or where are we going so the question was that there are 19:32.880 --> 19:38.160 requirements for digital signatures in his poems and like the question is that like with what 19:38.160 --> 19:44.160 and who can validate them it's again like a valid question I do not have an answer 19:45.760 --> 19:52.640 but we somehow have to ensure that that the the his poems are not compromised and that's the 19:52.640 --> 19:59.360 tool for that but this is something we as an industry need to start discussing 20:01.440 --> 20:07.440 we we have to do something and I guess we we know what's got to get the poll taking but 20:08.400 --> 20:14.320 we need to figure out how to be trusted from something yes and and the open as a 20:14.320 --> 20:20.480 self is doing great work here with cosine and six stores so there are like there are tools 20:20.480 --> 20:43.760 yeah it's not not a complete system yeah yeah yeah but that's a lot of work 20:43.760 --> 20:53.600 but there's still need to establish trust them for my own CA and trust I mean there's a lot 20:53.600 --> 20:58.080 of stuff to be done and we need to start this discussion before the morning it goes point to 20:58.080 --> 21:02.720 something and say you are to pay two thousand five hundred dollar per open source project 21:03.480 --> 21:06.180 because not 21:06.300 --> 21:08.920 you don't want that 21:09.080 --> 21:18.840 no 21:23.200 --> 21:25.920 you 21:32.720 --> 21:38.320 customer. What do they cost? You don't kind of want to use them, and it's recommended 21:38.320 --> 21:42.820 that you have data, but ultimately how it's all trust is that it needs to be a 21:42.820 --> 21:48.320 thing for this time of that. That might forever grab that matter then. Then Jimi, 21:48.320 --> 21:53.920 we, I would love everyone to have their OCA inside their own circuit, but then we 21:53.920 --> 21:59.720 just have to trust across the supply chain and those procedures on there, and 22:00.720 --> 22:06.720 yeah, just repeat, Jimi's comment that in the guide, it is recommendation to 22:06.720 --> 22:11.720 have the digital signature because it's more like it depends on the 22:11.720 --> 22:17.720 relationship of the actors, if we require that or not. 22:17.720 --> 22:20.720 All right, thank you very, very much. 22:20.720 --> 22:21.720 Thank you.