All right, packed room. People are excited by S-bombs. That's good. We're getting there.
Let me as pre-fix this entire conversation with I am Neuloyer. Speak to you earlier. We're
going to talk about CRI, so there is legal implications. I'm wasn't going to say before I
David's Dr. Talk. I'm going to do what the talk is not about. This is not a complete
CRA compliance guide. That's a lot more complicated than you could post to squeeze into
30 minutes. The second thing is, this is not going to be a theoretical exercise. I think
a lot of talks and it's good that we talk about a theoretical thing. What can be done
and cannot be done. But this talk is not about that. This is actual action of all what
you can do today using existing tools. It's not about achieving perfection. It's achieving
something from nothing. I think that's an important distinction. We don't try to overwhelm
users coming into this thinking about CRI or trying to be a CRA compliance. A lot of talks
have been about perfection achieving everything. This is not for that audience. This is for
99% of all the users out there that are going to be compliant or need to be compliant
with CRA. This is for them. We like to talk about S-bombs and intricate deeds of S-bombs.
And that's great. We need to have those conversations. That's perfect. That's what a lot of
us in this room are really excited about. But let's be real. The vast majority of customers
or people that need to be compliant with CRA, they don't care. They have this is need
and they absorb it. That's what this talk is about. Zero to something. What we look at the
areas, what's that easy button? How do you go from nothing to something that is getting in
the right direction? We get assume that the vast majority of these users don't care about S-bombs.
They don't care about the intricate details about the various details in S-bombs. We might
find super exciting and super interesting if we're attacking the exercise. But the reality is,
most users will not care about that. And like Anthony spoke this morning, it's really good about
diving into the exact perfect, perfect, perfect run by S-bombs. That's great. We need that too.
But let's not lose track of that. The vast majority of users just want this tick box.
I'm going to paraphrase S-bombs who was born on the CRA Technical Committee. When you talk
what I talked to her about S-bombs, her point was, it's about showing effort. It's not about
perfect. I think that's an important sentiment going into this. We don't need the perfect
S-bombs, the capitalist, everything. It would be fantastic if we could get it up. We shouldn't
lose track of trying to get that. But we need to go from zero to something. I think that's
really thing. So I'm fully cognizant that this is the board proof and there are a lot of variables
in there that are complicated. But let's just focus on getting you something from nothing.
Now we talk about CRA, reading legislation, that's a bit theoretical. The most practical
implementation of or interpretation of the CRA is to be a side. They publish the documentation
there's now the 2.1, which is relatively recently. It talks about what they expect from
S-bombs. I'm sure you can barely read this if you can. But a lot of this is simple. It talks
about it's your machine readable. It's your using certain formats. It should be using what
else that they have in there. It depends on the graphs of all those things. But they're one
thing that is somewhat problematic. One of the things they say is you should have sure 5 or 2
hashes or your components. Well, no package voucher out there to my knowledge. It does that.
Maybe something. But it's very, very rare. You still see MD5s, right? So yeah, you have any comments?
Okay. So there's maybe one, but I would say that it's a very much an edge case, right?
The vast mirrors will not do that. That's what you're going to have hashes if you look at
the lock files, right? So most of this stuff is not crazy complicated. But this is the exact
definition they have. Again, this is probably not readable. But this is kind of a way in
me for, right? We aim for like a depends on the graph. Good port S-bombs, really, right? So
how did I even get into this? So two years ago, I was in a company who was doing
security design, security design, managed S-bombs, so we can't get into this curve.
Me going into this assume that S-bombs generation was going to solve problem two years ago.
Well, turns out it really wasn't. You can generate an S-bombs really easily. That's not hard.
The plenty of tools out there with General S-bombs generate high-quality S-bombs that meets
entire minimum elements back then is a lot more difficult. So I did something about that. I joined
S-is working group and we create this group about S-bombs generation. And we worked for six or eight
months on developing a blueprint for how you generate high-quality S-bombs. So we came up with
this blueprint, which is a four-step process for how you bake a good port S-bombs. And the first
one is creation, so there are plenty of tools out there to do creation, usually from the
lock far, but it can be food, Docker, imagery, etc. But that part is kind of the most solved problem
generating S-bombs, right? The plenty of tools out there. The next part, we call the augmentation
phase. And the augmentation phase where you take that S-bombs that you generated. But you
ejected it then with relevant information that you as a company would only have. What's the
life cycle this? Who are you as a company? What's the supplier? All these things that anti-minimelments
require. That essentially none of the S-bombs generators will actually do for you because they
don't have the information simply. The information is not your lock far, therefore they can't do it.
The next phase we did then was the enrichment. That's when you look at S-bombs and the core of the
core of the S-bombs directly correlates to the core of the lock far, which is that's usually
a source here. So then you take the lock far, and then you try to take that information and
make it better by enriching it using ecosystem data. Back then, we were using parlay from
the sneak. That was kind of the best tool by the time. Which in turn is really if the thin layer
in front of ecosystem.ms. So it takes that data and enrich it and tries to produce a better
port S-bombs and then the last phase is designing. So like this runs your CI, you should
sign it to your CI and that's your sort of truth. So those were the building blocks that would
be designed. And when we did this work, it was kind of hack-ish. A lot of it was like you
had to parse your S-bombs using JQ and inject data and it was really, really like hack-ish.
So why do I bring this up in a CRA discussion? Well, if you're looking at the CRA and you
look at the NTA or a system now in a moment, it kind of shift the Venn diagram. They asked for
slightly different things, but there's a lot of overlap, right? But if they can generate a good
port S-bombs, we can kind of knock both out in the same gap. But again, the constraint is,
we need to make this easy for users because we have to assume that users, they do not care
about intricate details of the various formats. They just want something like, they can solve the
problem. They're a business problem. They were solved for it and therefore then they want to move on,
right? So we're aiming for solving both these problems in one gap. So pretty ball, I would say.
And then I think to make it with no complicated, Martha's sort of, because morning can't
outline this, right? S-bombs are not one thing. S-bombs are complicated, because the real
world is complicated. Yes, in a small open-source project, it's kind of simple because your
scope is kind of narrow. The real world is a lot more complicated than that. You have, you're
smart thermostat, has maybe like a back-in component, it has a firmware, it gets complicated
so you need to release like a management for all of that. And we need to remind of that when we
talk about this debate as far as when does end of life and all that stuff affect, because these
components are probably shared across other products, which makes it even more complicated. Right?
And then I'm going to add one more constraint, which is, we're going to do all of this in CI.
And that's really, really important, because if you got trust S-bombs for like legal reasons,
you need to have a station back to S, but to CI pipeline, so you get your trust what's going
in there. Right? So here's desperation. Can we, with five lines? Well, I guess seven.
Lines of YAML, saw this problem. That's the thesis. Can we do this? Because it's actually
not trivial. And when we come up with this, it's probably called Spomive Action. And it's
open source, and I would say it's more glue than tool. Yes, there's some tooling in there,
but it's more glue. And it's opinionated tool that is format agnostic. And we try to be full agnostic,
so that use can build whether I need to build. Right? So essentially, we try to build a unicorn here.
Right? It's not, it's, we try to take away all the complicated stuff from the user and just
do it for them. Right? So what does that look like? So in the generation face,
we have the usual suspects. All right? So we pack a job, actually,
safe, see the x-gen, all these tools we have out there, and we cut Packers them into one container,
so that when the user presents an unlock file, which is often time is, we pick the best tool for the job.
Right? So from a core to perspective, the native tools, such as cycling the x-pipe of the
library, tend to generate a lot better S-bombs or high-court S-bombs than to say the generic tools
like Sift. So we pick that. So it's an opinionated piece of software that we make the decisions
on the off the user to optimize for the best core of the output. And this is an ongoing thing.
If we find tools to score better and do better S-bombs, we can just default about. It's, it's
a volume evolution really, right? And a bit nudged to the S-bodex community, the
cyclone tools are a lot better. So there are very few S-bodex tools out there for actually
generating S-bombs from lock files, where the cyclone has a lot of tools for that.
For S-bodex, tend to have to go for the generic tools. So just, that'll be good to see more tools for that.
All right, so the next phase, the next phase is enrichment. So we start out using just parlay.
That's what we started with. It's just a working group. We use parlay. Quickly realize that
ecosystem is really good, but we can do better. So now we have native integrations with
crates, darts, rapporty, clear define. We basically try to do the best integrations we can to
pry the best output as possible, which usually means going directly to a database as originally.
We also have added some stuff like native integration for licensees. We parse all like a
dabbing and Python and few other distros licensees so we can kind of do license parsing
of that, so the bills are called license DB, and then we do life cycle database as well. So
a major framework and upper insistence, we can enrich this automatically to give the user a really
good high quality. S-bomb, rather than even know what's going on. Show, don't tell. Let's see how
this actually goes. So in order to start, we need to gather information that we caught in fair.
So we've prayed this little tool that in this example, we're using a Python log file as the
PyProtiq file, right? So we're using UV and PyProtiq as a sample example, but we're not in the
gather information that we can't actually infer at all. So we're written this all tool. Let's
spot the Sponeman Faction module, which is available as a Docker image, or as a Python package,
or Docker image is usually the best way, because then you can get what's with package.
But we need to fill our information like, who's the supplier? What's the supplier you're
out? So this is kind of anti-menom element things that we need to get in there. Again, we
aim for the Vendai program to cover both, right? Conflict information, component emails,
this fills you out, then you need to fill out the manufacturer, another requirement,
oftentimes the manufacturer is the same as the supplier, but not always. So we need to consider
both environment, right? So then we need to add the manufacturer, and then, oops, got some
type as in there, sorry. Yeah, you get an idea, though. So we now fill out the organization,
now we fill out, now we need to fill out the author, which is another example of some of the
required anti-menom element framework, right? So we're filling out the author, and then now we
need to add license information, sometimes you can further that, some of those you can not, right?
So let's ask. So in this case, we used to have a drop down, so you use to like, it's a patchy to cool.
Let's take that in. Now we need to inform about security. This is something that's CRA requires.
How do you contact the vendor about security issue? Well, in this example, we is going to use a
requirement of security or texty file. We take that data that we ask to use a kennel to be person.
To your point down to me about build cycles, here we ask the people about the build cycle,
you also ask about life cycle phases, sorry, life cycle phase rules, but release dates, and all those things,
when is the whole thing in the life, right? These are things we can't infer at all. We need
to ask to use about these things because you can't figure it out, like there's literally no
way to automatically figure this out, right? So now we've done, we take all the data,
we stack the JSON file, call this one file JSON. Now, we've done use this information
in the further build steps, and you can either commit this file to your repo. You can also use
our API, you can build that there, so you can have the same thing that shared across multiple
projects, but for the sake of this demo, I'm going to use it in the JSON file, right?
So again, we had a basic Python package, we used a spun of action module to build this JSON file
by just looking through a wizard, and then we had a life cycle data and so forth, right?
Great, so far so good, now we've added the generation. So, in the generation, let me see the
Python example here, right? I have the Python library installed, I'm running it, and I'm just
pointing to the left file, and you can see a bunch of information here, right? So not only did
run the tool, we all just started doing other things, so what we realized when we started doing this,
that most of the generators will not write hatches to your smart. Now that's a requirement,
right? So we need to have hatches. So we take that, we enrich it with hatches, because we have to
assume that we don't know, in this phase, we don't know how it was generated, right? Because we
use multiple tools, we can't make assumptions about that, so we need to validate. So if using
sifter-trivial, you may not have all the information that a native tool would give you, right?
So we make, we make some assumptions there, we chuck the data in there, and I'm not sure you're
still about the very end, but I used, just to be independent, I used smqs to be scoring that
s-mo. So we've got a score of 6.3, okay, not terrible, but we're not done yet, right?
Now augmentation. Remember that JSON file we created? This is where that comes into play. So it takes
the s-spawn that we generated in step one, and just for clarity. In the real world,
you wouldn't use smqss, you would do all in one go, right? It would take the entire all three steps
that we have here, and do them in one go. But just for illustrative purposes, I broke in them up to
really show what each phase does, right? So as you can see here, it adds a bunch of data, like,
for instance, we know the author, we supply a real life cycle, and we know all this information
now, because we built s-pum with that tool, right? So augmentation, rather that, right? All the
data we have from the wizard. This would get interesting. This is the enrichment part. This is where
the interesting data happens, right? So we can now look at that s-pum, and let me go in the
ecosystem and look to fill in all the blanks that are missing, right? So we are, in this example,
operating the Python work as the Django package. So we are now looking at Python. What they
does is Python, right? So we pull in all the Python data, we are pulling in life cycle data from
our database, so we know it's Django, we know the version of Django. Well, because we know the
version of Django, we also know in that version of Django we see well. So we have a life cycle
database, we just chucked it in there. So that when you inspect the s-pum, you can see exactly
when this particular component is end of life. The same goes for an off-brain system, and for
a lot of various packages that we have. So you can see from the audit trail here is doing a lot of
things. It also adds description, homepage, all these things that CRA requires you to have,
what all your packages, it kind of fetches that from Python is example. We then do some other
nice things like we normalize the data and so forth. And then, one interesting thing we discovered
and we saw looking at the data scale was there's a lot of normalization needs to happen because
you pull in data from across ecosystems and various data sources, things like URL structures
are very inconsistent, right? Because we try to populate things like where the source code from
this package form, that is all parsed and normalized. And then we clean up all the pearls and
all that stuff to make it really good for this one. So this is essentially what we did in this
fix, right? And again, bear in mind, several lines of the animal in your Docker hub, in your Docker,
sorry, in your GitHub action pipeline. So this does not require you to be an export S-bomb,
which generates a high-port S-bomb, right? So when from 6.2 to 8.5, which I think is a pretty good jump
into terms of completeness. And if you're going to compare that to what actually CRA requires,
we've ticked most of the boxes here. We haven't ticked the Shaw 512 box because Python doesn't
do that or UV doesn't do that. So unless we're going to go re-back and re-calculate those hatches,
we can't quite do that. But again, we can't want to raise the bar and we want to do
one of the show effort. The goal is not perfect. The goal is zero to high-quality with minimum
left work. So they work. Well, this is the output from S-bomb QS. If you're scoring the input
with the output here, and I'd say we've done pretty well, given that again, set the lines of
the animal in your GitHub action pipeline or rather pipeline using, we have built essentially
high-port S-bomb from a loop file and I think the reality is that's what 99% of the users
out there will be looking for when they need to look into CRA. So I hope that's helpful and that's
essentially my talk. I'm very happy to take it a question. If you go army, that's the link to the,
well, I'll put a link to the talk later, but that's the GitHub action module on GitHub. And yeah,
now questions. First of all, hey, so you talk about the manual, the movement of data like
manufacturers, if you're concerned with it, that is part of the context of this, the programming
content. They have no idea on what's the idea of what the JSON UI looks like, of course they're
in there. My engineers know that, not those things are, but they don't know what they're
talking about. So you're talking about commercial projects, more than open source projects.
So the question is, when you do all this stuff and not so much for open source, but when you're
talking about commercial items, I think that's a lies in unsolved problems, right? Now how you
the format's supported, both cyclone and in aspects they support it, right? But I think it's large,
like, I haven't seen any large-scale implementation that, I'm sure other people have,
but I haven't actually seen that because most of the things I've been exposed to has been
commercial project built on top of open source, and that's kind of like what's in scope there.
I'm sure other people have, but I don't have a good opinion about that, if I'm being honest,
I know it can be done, but I haven't seen much about around that. Yes, question back.
Would your output into that format more like open authentication or not?
So S1QS does BSI 2.0? Typical one I haven't seen anyone yet, because I was relatively
recent report. We are probably going to write one. So we have automated checks on our
back end. So when you push that to this one of our platform, which is also available, you can
run yourself and self-asself as then you can then be write plugins to check that. So the idea is to
have a plugin for BSI 2, but one, where you do that, not being in say thumbs up, you
pass all the checks, but you have to be written yet. This is more about the generation piece,
not to what the validation piece yet. I'll get there. Anthony?
I have a tool to take back, because both that do a HTML and page.
Oh nice, nice. Yes. Mr. Tools himself, got a tool.
Can you ask me how many HTML questions? Yeah, one here.
Whenever people produce their S-bombs, like where do they typically store them?
Hmm. I like people produce them.
Love that question, because there's something that we never really talk about.
The question is, you've generated your S-bombs. What do you store it?
Literally the reason why I got excited about this space in the first place. Because a lot of people
come from a resource angle, let's say chuck and get up, and that's part of the release.
Great. Works great for an open source project, not for the real world.
That is literally what the back end component is does. It shipped S-bombs to the back end.
You could do release management across, I mean, if you go back to the slide with the tree,
that you could do release on top of the level, the points store that are hard.
So grab me afterwards, I can explain that in details, but that's literally the other piece to the
puzzle that I haven't even talked about in this talk, because too much ground to cover.
But yes. So, sorry, we're after that.
Well, it's time for it. Thanks so much. Thanks very much. Thanks very much.