All right, thank you. So welcome everybody. Yeah, there is not much more left. I also have
a couple of slides for you still. About as bombs. And about what the open chain tackle
as bomb a guide is covering and what the open chain tackle working group is working on.
This presentation was supposed to be given by my colleague who is actually leading the open
chain tackle working group, but unfortunately he got six. So I am jumping in and I'm basically
power point karaoke the slides, but I'm happy to take any comments and questions of course also.
Let's talk first about the open chain project. Maybe it's not clear for everybody what the
open chain project is doing. The open chain project is building let's say a set of rules
how different actors of the supply chain should let's state about themselves that they are
following compliance process and it is an ISO standard and you can have a certification and
you can look and say that you are compliant with the open chain specifications. And this is a
very good way to show that the organization has like solid compliant processes and as we are
publishing or or compliance it's a very good way to see that your partners are actually having
a comprehensive process. The open chain project also hosts a couple of working groups which are
working on different topics than the actual pension specification and one of these working groups
is the tackle working group. We have other working groups like automation and as one working
group we have an AI working group so the list is very long. If you are interested in an
open source compliance or S-bombs and such things I would highly recommend to check out
open chain and join the communities which are interesting for you there. But now I will focus
on the work of the the the tackle working group and this working group was started by EME
who is in yes in the room so thanks for that and the aim was to sit together members of the
tech industry as specify an S-bombs format for ourselves. Why do we need that? It was presented
I think two talks ago that everybody asks a different type of S-bombs from us and that is a
problem because we don't want to send a different type of S-bombs to each and every
customer and each and every country we would like to have like a consolidated set of requirements
what an S-bombs should fulfill and we would like to use that as a basis so this is actually the
the minimal set what was mentioned in that previous presentation that's what we are aiming to do in
this open chain tackle working group. Yes it's an open source community we have mailing list we do
poor requests and all of that so the consensus is made using the GitHub GitHub process
so it's not it's it's a public specification group basically using open source
methodologies and actually we're using also open source license so it's an open source specification
group again if you're interested in this work join the the mailing list we have regular meetings
we discussed things on the mailing list and so on so it's like it is a commodity
and as a result of the work of this group we created the specifications so we wanted to have
something and this is already out there we have the version 1.0 of the specification out
and we have
we translated it into several languages and so on and so on but like we can you can check it from
the link which is provided in the presentation and you can read it but I will now outline
couple of points here what is specified in the in the guide and of course like as this is a
specification of of a specific format this is an opportunity to think so we have decisions made here
and of course some people have different opinions and that's totally okay for example we decided on
SPDX and 2.3 version of SPDX because like we had like to also discussions about this but that's the
that's what the the questions was became in the group and we are following the couple of like
other guidelines like the NTA, the minimum requirements and we are also following the CSI S bomb dice
which we were also discussed here before in the in the room and just couple of examples which kind of
things are defined here I don't want to go through all of the things but for example for the whole
for the whole S bomb we need to know like which organization created the S bomb so who is
that's responsible for the S bomb we also require a dimensioning of the tool and the version which was used
to create the the S bomb and we have this like CSI S bomb type like we discussed this for the
in a previous presentation like if it's the source S bomb or or this is coming by normalizing the
artifacts so there are several types six types defined by CSI and you have to define that also
in the in the creation information of the of the S bomb and for each and every package you also
have a couple of things which we require and like we discussed this again in a previous presentation
that the package URL is is something what everybody would like to have in an S bomb so we we have
it as a requirement that that we should have the package URL as a part of the of the S bomb but
we also require a couple of method data most of them are coming from the anti i requirements so
we try to keep the requirements minimal which are added on top of other requirements how complete
S bomb should be and all the commandation is that it should be a complete S bomb I know that the
requires only the top level of the dependencies and so on but eventually everybody will need
the whole package and this nice figure what I put here by the way it's a it's a different representation
of what Gawork showed us in his presentation this is the the Q and S dependency 3 I got it from
that's on dev that's dot dev but you have to have everything and I also wish that we would have
the known unknowns it's not in this specs yet but I think we also should have that and that was also
discussed in a previous presentation okay so yeah of course we are requiring that the S bomb should be
signed and the guide allows you to construct your S bomb from different S bomb files so you can
like have different pieces and you can define relationships between these these files there's
BDX standard allows you to to do that and we also allow that the S bomb are handled as a
confidential information it's not a format thing but it's more like an agreement between between
companies because the S bomb is actually exposing a high level information of the structure of a
product and the vulnerabilities of product so it's not very good if like somebody publishes
this list and the work is ongoing so we are now working on the one point one version of the
of the specification after using 1.0 we got lots of feedback from the industry so we are now
incorporating that feedback and of course like we are also like trying to move forward
we do not plan to move as with the X3 yet we feel that there is not enough industry adoption yet
so we are still waiting with that step but we plan to have like a couple of small fixes in in 1.1
basically and the S cell like if you do not agree on the on the specs I know that some people
have come as that is totally okay this is why we created this whole work like to have a space
to discuss and agree on on what kind of S bomb we would like to have of course you can join
to the community you can be part of the of the of the discussion or if you don't want to spend
the time on on on meetings and all of that you can just file an issue and start discussion on
it are both of them are totally okay and then we started to think okay now we have this nice
set of rules but how do we know if an S bomb is compliant with this like do we ask people to
go through unlike I don't know hundreds of megabytes of of SPD accent and check and we decided
now it's not a nice way to spend people's time so we created a small Python program which
validates an S bomb against these rules this really data is working in a way that it's a library
and it is it has a sealer interface also so if you would like to use it in a CSD pipeline and
use it as part of another Python script it's also possible but if you are just from a
use it from the CLI then you can do that plus it has features to extend the rules so if you would
like to have additional rules on top of the the open-chain tech or specs you can write your own
additional validation rules as functions and you can just add them to the valid data and it will
execute your rules also as part of the of devolidation again if you try it out and you think that
it's it's not working correctly then you can file an issue and of course all contribution
contributions are welcome it's is written in Python and it's heavy relies on of course
the anti-evilidator and it also relies on the on the SPDX Python library
yeah and it looks like this maybe we can even have a short demo if time alone is this visible
then somebody have to tell me how to make this bigger now like this okay cool now I learned
all right so yes and I think I mentioned also that it's beep installable so you can now you can
get it via a pip install so now I have a test as boom here and like this is this kind of result
what you get via the CLI so it does you like what kind of errors you have like we have six
categories of errors it gives you the SPDX ID where the problem is and it gives you a description
what what the problem is a big look for an okay execution
like it is it's basically a method test because we are now running it against its own SPDX
then then it says that it's it's just okay and of course we will add the the logic to the
very data case one dot one once the specification for one dot one is is released
now I should remember how do I jump like this okay that is it any questions or comments
so I was aware of this and my comment was why had he chosen a format rather than a content
and I think we saw that with talk early this afternoon is I think we need to be focusing
on content well and another reason he chose SPDX was because it was nice so standard
well he's also an act with standard as well for cycling dx so but nationally we want back
flexibility because and we interrupt a ability of s-bombs is crucial for the adoption
and we saw that with t as well so I think going forward I think I'd only find what attributes
the minimum requirements you have find will keep away from it being particular format
and because the content if the content is important not whether it's JSON or tag or whatever
yes it's a very point the comment was that or the question maybe that why did we decide
to select a format instead of defining the content and it's a very valid point and there
is now a work ongoing in open chain in the s-bombs working group to define exactly that like
elevating it to one higher up social level and what I think will happen but it's we didn't
discuss it yet in the tech working group is that we will join to that work and define the content
but eventually we will need a format so we will need to send files
absolutely yes yeah what we need to sort of both that's the that's the point yes but that's a very
valid point we should yeah I'm part of the group so I can understand yeah help yeah there's a lot
of stuff already there so maybe maybe stick yeah yes but that's that's where it's point I think
work work we're continuing so as I said like it was started just to address these issues and
discuss about them and I think this is one discussion point what we should like use to
make the work more more useful there is one question there yes the tool and how you answer to this
the tool does not evaluate completeness very good question we discussed this in the tooling workshop
on Friday currently there is no tool which analyzes completeness of fashpom I just learned
that there there was a plug fest to test stuff for computationalized tools and they
provided a set of artifacts and you could drive your tool against them so there is now some
work on going to figure out like which tool is better than the other in terms of like completeness of
the espom but it's not not a thing what you can objectively measure without comparing the tools
to each other so the purpose of the plug fest was not to say two layers better than two be
because actually the one as many tools as possible but are all as good as the each other
yeah I think what purpose are they just finding out giving it content how easy was it for
it depending on which language ecosystem what's that content readily available and we saw
as we put earlier on this seems very poor yes it was very good jar of a script was in the
middle type of thing so it's more about where we are with the languages at the moment I think what
we need to start having the discussion about is polyglot because increasingly we have projects
that are multiple languages or and products on multiple languages so rather than just pulling the
Python aspects we need to see aspects and the worst aspects at the same time the tools are there
yet yeah absolutely so there is a data set yeah yeah so the question also I forgot to repeat
the question the question was that if the tool is testing for completeness of this one
thus there is no the tool is checking only the like syntax and semantics of the expeditions file
and we discussed also that there is a data set available but it's more about the different
ecosystems not about the tools themselves and the other comments or questions
this is a pet pee but I see so many presentations and presentations about
that's poem saying oh we need a digital signature and my question is with what and how do
we validate by data I want to give the digital singer to your person this is like in the web
to one single company or where are we going so the question was that there are
requirements for digital signatures in his poems and like the question is that like with what
and who can validate them it's again like a valid question I do not have an answer
but we somehow have to ensure that that the the his poems are not compromised and that's the
tool for that but this is something we as an industry need to start discussing
we we have to do something and I guess we we know what's got to get the poll taking but
we need to figure out how to be trusted from something yes and and the open as a
self is doing great work here with cosine and six stores so there are like there are tools
yeah it's not not a complete system yeah yeah yeah but that's a lot of work
but there's still need to establish trust them for my own CA and trust I mean there's a lot
of stuff to be done and we need to start this discussion before the morning it goes point to
something and say you are to pay two thousand five hundred dollar per open source project
because not
you don't want that
no
you
customer. What do they cost? You don't kind of want to use them, and it's recommended
that you have data, but ultimately how it's all trust is that it needs to be a
thing for this time of that. That might forever grab that matter then. Then Jimi,
we, I would love everyone to have their OCA inside their own circuit, but then we
just have to trust across the supply chain and those procedures on there, and
yeah, just repeat, Jimi's comment that in the guide, it is recommendation to
have the digital signature because it's more like it depends on the
relationship of the actors, if we require that or not.
All right, thank you very, very much.
Thank you.