You know, actually, hey, I'm Mike, I'm doing a lot of stuff with S-bombs over the past
few years.
I'm going to talk a little bit about what do we do with all these S-bombs?
So, again, I have a couple of demos, but it appears that something has gone very wrong.
So, if it comes back in a couple of seconds, I'll show some of that off real quickly,
but if it isn't, then it is what it is.
And if folks are interested, they can hit me up outside the room at some point and I'll show
off some of the demos there.
All right, take away is here, one S-bombs is good, more S-bombs are better, why is this?
Well, hold on one second, let's see, is it coming up?
No.
All right, it doesn't seem to want to.
Yeah.
All right, I will just talk to Mike Slides here in a second.
Well, it's actually interactive, which is up the challenge, but I will deal with it.
So, once I can hear, I'll go quickly.
Yeah.
All right.
So, I'll just talk to Mike Slides and folks are interested in who are on the front row,
they can see this.
Otherwise, I apologize to you.
So, with one S-bombs, what can I do?
Identify vulnerabilities, I can identify license issues, I can do all sorts of things like that.
If I have more S-bombs, I can do that across time and space.
I can do that across time and space here.
So, S-bombs are generally a snapshot in time.
They're sort of a static thing, usually done at build time, usually done.
So, like that, this makes them sort of perfect for changes between versions of software.
We can look at what's actually happening as I release a new piece of software.
What have licenses change, have dependencies change, have any of those things or things?
Change.
And they also make it good for understanding commonalities across my environments.
So, if I have 100 pieces of software and is there like a log for shell in five of them,
ten of them, all of them, if you're actually looking at all your S-bombs,
you can actually start to tell, be able to start to answer those questions.
And so, where to start?
Start with simple existing tools, do not over-complicate it.
One of the things that we found as being a huge issue for a really, really, really long time was
people would over-complicate things, trying to use all sorts of custom tools on day one.
They have a handful of S-bombs.
They want to use a bunch of complicated tools.
Don't over-complicate it.
So, right, you have a handful of S-bombs.
Use JQ, diff, shell scripting, whatever.
You know, both the S-bombs nowadays are coming in JSON format.
And that sort of thing.
You know, if you have a few more S-bombs, let's say, 50, 100.
Jump, DB, right.
You don't need to spin up a whole database, sequel database and start to ingest them all that way.
You can start right now, duct DB, and throw them in there.
And then if you have lots of S-bombs, yes, okay.
Start to look at tools like dependency track, tools like guac.
But don't start that on day one.
You're going to find yourself super frustrated.
When you're like, hey, I need to spin up all this infrastructure.
I have five S-bombs.
I don't want to spin up a whole bunch of infrastructure to kind of figure all this stuff out.
You could just start simple there.
So the case study that I was a bit contrived is I have a little open source project called WTF,
or the Whiskey Tasting Foundation.
It's just an MPM project.
It has a couple of different versions in there, but it's using MPM S-bombs.
And I know for folks can't see this, but pretty much it is a, you know, you can essentially just
jq.packages.external refs, two S-bombs, and you know, pipe them, you know, create files,
and then just dip them.
And, you know, that's really about it.
And again, I apologize.
I can't show that off to everybody.
And you can also do the same thing with, you know, not just dipping S-bombs.
But hey, if folks are familiar with OSV, the tools like that, right?
I can run OSV scanner against those two tools.
And just to, I know that this is most folks probably cannot see this, and I apologize.
But as you can see here, there's differences between the two versions of software.
We updated a bunch of pieces of those software, right?
So you were using version in this case, let's see, as using ES build 0.20.2 in the first version,
and then switch to ES build 0.21.5, for example.
Right?
And that's just, I have pretty much everybody has those tools today on their laptop.
They don't need to go and download a bunch of stuff and whatever.
Now, the same thing kind of goes with folks if you're familiar with OSV scanner, which is an open source of vulnerability scanner.
You know, I can run OSV scanner on my laptop.
I can go, oh, here's version one.
I have all these vulnerabilities.
I do the same thing on the version two.
And, oh, no issues found.
Hey, I actually went out.
I updated the packages.
I can see that those things are different.
I can output that as JSON format.
I can keep that, you know, and so on.
But just to start off, I could just do that today without having to go and set up a whole bunch of stuff.
And so what did we learn?
Right?
We learned, hey, I was able to version one had some volumes.
Version two, fix those volumes.
I can do that with the software today.
Analysis doesn't have to be complicated.
Right?
Differences and esplons and scans can just be dipped.
Right?
Making it visually pleasing is just a pipe and are script away.
Hey, pipe it into bat and whatever else other tools you want to use.
Start with simple questions you need answers to.
Don't start off with super complicated questions like, hey, do I have an
AGPL license and what exactly transit dependency this might live on?
Right?
Start simple and then kind of move on.
And then correlate this data with stuff like a vulnerability scans or inventory data.
So where does where's the software living?
You can actually correlate that.
You know, when you have more response, right?
What do we start to do?
Hey, look at something like ductDB for folks who aren't familiar with ductDB.
Like an OLAP style database, so an analytics sort of database.
And what's great about it is, and I know again, you can't see this.
But you can just throw JSON on it and it will just, you can use pretty much
SQL against it, right?
So I could just throw my JSON.
Don't need to create a schema.
Don't need to do anything.
I just say, hey, here's a gigabyte of my S-bombs and start to do stuff with that.
And yeah, so that's going to take too long from even to run.
But pretty much the basic idea is I can run a query like select distinct package dot
Unrest as package name for my S-bombs.
And right there is a single query that will get me all distinct packages across all the S-bombs I sent it.
Okay, what else have we learned so far?
Well, we understand that software makes up our environments holistically.
What common packages are used?
Do I have stuff like version sprawl?
Am I using 12 different versions of the same package?
Where are my vulnerabilities and where are they actually living?
Am I using software in a way that breaks the terms of its license?
I can start to answer those questions.
And I don't need to send up spend week setting up a complicated architecture for this.
I could just start doing that right now.
Okay, so where do we go from here?
So there's a couple of issues with everything I've shown.
One is, hey, it could be slow, right?
DuckDB can take several seconds just to sort of parse some of those S-bombs.
It could be hard to scale.
Hey, this sort of thing is not something that is super easy to just,
is not super easy to run at scale, right?
Like you're, you know, it's a duckDB is something that you can throw into a file.
But for the most part, it's just in memory, so once you shut it down, that's it.
It's hard to keep track of results.
Everything I showed off so far is, hey, you're just getting that output to your, your terminal.
And a lot of shell scripts are, and commands can be hard to manage long term.
So more holistic solutions.
Well, one is stuff like dependency track.
Another one is Glock, disclosure I'm a maintainer of Glock.
And so Glock, I'll talk a little bit about that.
Glock can go in and take in things like your S-bombs and, you know,
PsychoDXSPDX formats, you know, various other open source supply chain metadata,
like OpenSeptSportCard, like OSV information,
depth.dev information, various intodo adaptations, and those sorts of things.
And then help correlate all that data.
So you're actually getting some of the deeper insights there.
And so, and the goals of that right are to correlate the metadata,
create a graph based software supply chain data model,
and then help you sort of aggregate all that information to then answer questions.
And so we can do things like, for example, more complicated queries like patch planning,
like, hey, a log for J, a double log for J sort of situation came out.
Where does it live and what packages do I actually need to update?
Hey, there's a bunch of different pieces of software.
Some of them might be a common library.
Well, great. You need to now update it in the common library and then update everything else
that uses that common library, right?
And Glock can help answer those sorts of questions.
And then, you know, so, yep.
And then, I'll just kind of talk a bit more about some other tools real quick.
I don't know too much time.
So, so other tools that you can start to look at
with sort of exploring with the S-bombs and using S-bombs,
oh, it's pretty, right?
You know, tools like OSP, where I can just get a dump of all the software that's on my machine.
Cool, take that correlated with your S-bombs,
understand where do I have actual the software that is potentially vulnerable
or has a license issue where it's actually running.
Cube CTL or K-9s if you're using Kubernetes, right?
Just dump what is your running and then correlate it with your S-bombs.
Using security tools, like there's the new Google open source security tool,
a scaler for example, or something like CubeScape.
You know, integrate this in your build system so that you get
start to answer questions in the build systems at policy time, right?
Where, hey, fail a build, if version two didn't fix the,
you know, didn't fix the vulnerabilities from version one and
check that with your vulnerability.
You can do the same thing again with, like,
a deployment system, like flux or R-go.
And so a couple of learnings when that I learned is,
so when desirializing S-bombs only include the field you need.
Desirializing every field can be very slow,
whereas you just have a handful of fields you want to desirialize.
I could be very, very fast.
S-bombs are in a much better state around consistency than they were a few years ago,
but still optional fields can be quite complicated.
And then check if the S-bombs is valid first.
Don't go down a rabbit hole.
It's spending hours and hours trying to debug while your results are weird.
When it turned out you got something that looked like an S-bombs,
but was missing some key field and is not actually an S-bombs.
And yeah, that's it.