Episode 807 transcript

FLOSS-807

Jonathan: Hey folks, this week Dan joins me and we talk with Josh Bressers about ANCOR and open source security. We talk about the kernel and its many CVEs, the state of the CVE system in general, what an SBOM is and why you should care, and more. You don't want to miss it, so stay tuned. This is Floss Weekly, episode 807, recorded Wednesday, October 29th, bitten by the penguin.

It's time for Floss Weekly. Floss Weekly. That's the show about free Libre and open source software. I'm your host, Jonathan Bennett, and it's going to be a lot of fun today. We're talking about Angkor and security and open source. Surely that's not a thing anybody has to worry about. Uh, that said a little tongue in cheek for those of you that don't realize.

Uh, first off, we've got. A great co host today. The wonderful, the original Linux outlaw, Mr. Uh, Dan Lynch, Dan, welcome to the show. Hey Jonathan, how are you doing? I am, I'm doing great. We were talking just before we started that, uh, this was kind of an early morning for me. So one of two things are going to happen.

Either I'm going to get tired and kind of get a little loopy and punch up happy during the end of the show, or my energy level is going to drop and it's going to be real draggy. So we'll, we'll see. I'm feeling pretty good at the moment. I've. Got the go juice, the coffee to keep me going. So

Dan: that's good stuff.

Yeah. And, uh, I managed to make it on time, even though the hours different here, our clocks have changed in the UK. It's an hour earlier. I once on, uh, on plus weekly with Randall years ago, a long time ago, I turned up an hour late because I didn't realize that the U S clocks changed differently to the UK ones.

Jonathan: I remember that. That was fun. So when we were setting up, when we were setting up for the show, um, In the past week, I made sure and sent both of you guys an email saying, Don't forget, time change is a different weekend in the US and the UK. Yeah, it's, it's no fun to, it's no fun to show up to do the show and not have everybody here.

No, no. Uh, Dan, this is actually a guest that you sort of brought to us, isn't it?

Dan: Yeah, so I was at odd camp recently, which a guest of the show only a few weeks ago now you had Gary on to talk about that with Simon as well and I was at camp and I met my old friend Alan Pope, a poppy as he's known online and he he kind of hooked things up and suggested, you know, the guest for today and I'm really pleased that he did because it's going to be a great show.

Thank you

Jonathan: Yeah, so we've got Josh Bressers, who is the VP of security at ANCOR. And from what I understand, ANCOR does a lot with open source tooling, security tooling around open source, which, I mean, this is sort of a match made in heaven for me. There's a couple of things I really care about, and so I am super interested to hearing about it.

Uh, let's just, let's go ahead and bring him on. Um, let me push the right buttons to make that happen. There we go. Josh, welcome to the show. Awesome. Thank you so much. I'm super excited. Yeah, it's gonna, it's gonna be fun. Now, you are the, you have a VP of security at Anchor. What, let's start with this. What is, what is Anchor?

Like, what is the, the, the, the problem space that you guys as a company are in?

Josh: Yeah, for sure, for sure. So, we have a product, an enterprise product, built on a foundation of open source. We call ourselves, like, Next Generation Software Composition Analysis. Everyone has Tons of open source today in their environment.

And so we have tools that help you scan into your stuff, basically, figure out what the packages are, and then you can do vulnerability scanning. You can do, like, policy management and enforcement, things like that, plug it into your CI system. You know, there's, we, we, the, the, the US federal space runs us a lot.

There's tons of compliance in that universe, and they're running open source absolutely everywhere. It's everywhere. Mm hmm. Mm hmm. And so you've probably heard of things like, you know, like SSDF and STIG like, we have a FedRAMP webinar in a couple of days to talk about all this stuff. And it's just, it's a, it's a strange universe.

And I've been in open source just literally forever at this point. I mean, more than 20 years. And so it's super fun. We've got these two open source projects, SIFT and GRIPE, that get quite, quite a lot of attention. SIFT is an SBOM scanner. You can point it at containers and directories and whatever you have.

It will generate a software bill of materials for. Kind of whatever and then you can take that software bill of materials, and that's the thing that you can then, you know, look at for policy enforcement you can scan it for vulnerabilities. You can just ferreted away for later like that. The famous example is log for J right where we all we are.

Everyone has battle scars from that. And if you had. A catalog of all your open source, you know, do I have log for J means you go to the search box and type log for J and you're like, oh, there it is over here. Let's go look and see what's going on versus saying, do we have log for J? Like, I don't know if we have log for J.

Someone should go find out. Yeah, it, it, so it's, it's been wild. And in fact, it's funny because I started at anchor, I think like a month before the log for J incident happened. And so like it was trial

Jonathan: by fire.

Josh: It was amazing.

Jonathan: Yeah. Yeah. Yeah. So, so SIFT is the S Bomb finder. What is, what is GRIPE then?

Josh: Uh, vulnerabilities.

So you can either point it at the same artifacts, be it directories, containers, whatever, or you can just hand it an S Bomb and the, the, the magic there. Is so you scan something for an S bomb, right? And your software bill of materials theoretically doesn't change because you've got your container or your release or whatever, but the vulnerabilities do because there's new vulnerabilities found every day, every week, whatever.

And so you need to keep re scanning things for vulnerabilities over and over again. And if you have to scan, let's say like, you know, a multi hundred megabyte container that can take, you know, 30 seconds, a minute, whatever, depending upon your hardware. Versus if you've already done the scan and you have like your software bill of materials.

You can usually scan those in milliseconds. And so there's like a huge advantage just hanging onto those documents and their JSON, right? Like maybe a couple of megabytes max.

Jonathan: And so gripe is, is mainly just going out and looking at known CVEs and comparing it to the software and the versions in your, in your S bomb.

Exactly, exactly that, yes. Yeah, it seems like the world kind of woke up to the idea of, boy, we really need to know what software we're running. I think Log4j was really, yeah, like you say, it was the point where everybody said, oh hey, SBOMs might be a good idea.

Josh: Yeah, yeah, for sure. And well, so I think what happened in Log4j is, so I'm, You can imagine I've spoken with many people in corporations and open source, like all over the place.

And I think what happened is a lot of organizations didn't realize how much open source they actually had in the log for J incident happens. And they, you know, send out the minions to go figure out where, what our open source is. And then they're like, holy crap, where did all this stuff come from?

Because, you know, any, any open source nerd. We knew open source had been taking over the world for literally decades, and we knew it was running everything. But I don't think a lot of the, we'll say, business folk had quite figured out what was going on until log4j. And so I feel like that is truly the moment all of the businesses, all of the people were like, holy crap, this is just literally everywhere.

And that's the moment. I knew some people that were like, can we stop using it? And they were just laughed at because like at this point, no, it's completely out of the question. Right.

Jonathan: And unless you want to turn all of your logging off for your product,

Josh: all of your everything. I mean, it's wild because there's all these surveys that keep coming out.

I mean, I think I read one from red hat not too long ago, where they said 80 to 90 percent of all enterprise applications. Our open source underneath and honestly, I have no doubt, no doubt at all that that's the case.

Jonathan: Yeah, yeah, it seems like all the, all the compliance of, you know, you, you mentioned this sort of almost like an alphabet soup of the compliance things.

Some of those I have heard of and some of them I haven't because that's, I'm not in the enterprise or federal space really. Um, but it almost seems like that's just. That's the price that we pay for having made it. We're here and open source is not going away. So it's time to play the game the big boys play.

Josh: Well, okay, so that's a really good point. So there's a famous blog post. It's called, I am not a supplier. A fellow named Tomas de Pierre wrote it back in the log for JDAs. It's been almost, I think it's been two years now since he wrote it, which is like blowing my mind because I feel like he wrote it a week ago.

But. In that he talks about the fact that he was getting these like questionnaires from companies saying, you know, oh, you're my supplier Do you do you have log4j and your stuff and he's like, I'm not your supplier Like I'm some dude who put some software on the internet Like that's not the relationship and I think that's another really wild aspect of this is the open source developers Like they technically don't owe anyone anything, right?

But if I'm an enterprise using open source I'm the one responsible for that because, I mean, if you think about open source, I often say it's more like a natural resource, right? We're like, you're going to harvest lumber from the forest. You don't ask the forest for things, right? Like you're responsible for the things you'd get.

That's a,

Jonathan: that's an interesting analogy. This is something that I know the Europeans are having to sort of wrestle with as they're, they're looking at making some legislation about security and software and wrestling with trying to, trying to fix that in law. That's right.

Josh: And they have two things in Europe that we're keeping our eye on.

And like the compliance universe is there's the CRA, which is, I do not remember what it stands for anymore. I apologize. But that's the one that's talking about, like, you need to track yourself or you need S bombs. You kind of need all that stuff. And then there's another directive called NIST 2, which is more of a, you know, you're an organization, you're a company and you have to follow certain cybersecurity requirements.

And like, Knowing what you're shipping and providing security updates and things like that are part of that. And one of the challenges in the open source world has been the EU directives initially just said like all software and the open source people were like, Whoa, hold on there. Like you can't have this work.

Yeah, right, right. Exactly. And so, I mean, places like the Apache foundation and the eclipse foundation and like the Linux foundation, they really did a nice job of fixing a lot of those problems. So now there are. You know, there, there's sections carved out that say like everyone except open source type things, which is good.

Cause that's what we want.

Jonathan: Yeah. I mean, our, our own Simon Phipps was actually part of that. He would keep, he's in UK, but obviously he would. Several times went to Brussels and was talking to the people making the laws and trying to educate them on you know Here's how this thing called open source works And here's why what you have written this this piece of what you have written in this law just does not reflect reality at all That's right.

That's right. It's some of the you know, I I I Did I read the entire CR? It's the Cyber Resilience Act.

Ah, that's it. Thank

you. At one point, I read either parts of it or the whole thing. I can't remember which for some coverage of it. And like, there's some really good stuff in there.

Yeah. There's actually

some really good stuff in there.

Like, you know, if you are making software, like if you are a company that is making software, if you're putting your name on it, you are required to have a security contact. It's, it's mind blowing how many companies just Don't. It's like, Oh, I found a security vulnerability. How do I tell them? They don't know.

You don't know. Nobody knows. Might as well just drop it on Twitter because there's no better place to do it. You can, you can, you can email their contact at email address, but you'll know, you'll probably never hear back. If you do hear back, what you hear back will be written by Chad GPT in today's world.

I'm experiencing that. Or a lawyer. Well, or a lawyer. Cease and desist. Trying to hack our product. Exactly. Yeah, it's, it's a little, um, so what, uh, You guys, the, the Anchor Company, um, let's turn back to that for just a second. What's sort of the, the space that you're primarily focused in? Because it seems like everybody that is in this space has their own niche.

Um, we, we talked with, uh, we talked with the guys from Workbrew, which that's actually the commercial offering now attached to Homebrew, and they were cool. Like that was, that was a great project to talk about, but they've got a, they've got a very narrow niche, and that is. People running open source stuff from Homebrew on Macs at their workplace.

And they want to be the guys that own that. We've talked with some other people that are all about, you know, uh, JavaScript, you know, the, the, the, the full stack JavaScript, and they want to be able to catch those kinds of patch or watch for CVEs in those packages. Um, and you know, there's some places that kind of seem to get left behind, like the actual.

Linux binaries and packages. There's not as many people working on that, which might be a problem. Uh, but what, what is sort of the niche where Anchor fits in here?

Josh: Yeah. So I would say we're a little to the right. You don't hear the word shift, right? Very often, right? It's always shift left everybody. But the thing we like to do is we work with, we'll say the operation side of DevOps.

Cause we also, it's like, Oh, it's the DevSecOps everybody, but there's still people who are, we'll say a little more operations than dev in every organization. And so what we do is imagine you acquire software from somewhere. It could be internally developed. It could be an external thing, who knows? And you need to deploy it.

And so you scan it when you bring it in and then you know what you have, right? You, you've got your S bomb, you know what it is. And then. There is the vulnerability aspect, which obviously is important these days, because, you know, vulnerabilities are in everything, and then also there's the policy. So the intent being that you have all this software kind of flowing into your organization, and then using the tool Anchor has, Anchor Enterprise, it gets scanned, and then there's policy gates, for example.

So you can say, like, everything looks good, we can just keep flowing it through the system. Or you can say, oh, something is weird. Like, We're going to stop the train here and someone's got to go figure out what's going on and so it's kind of that. And then the other aspect is once you have things like deployed in kubernetes will say again that whole security vulnerability piece.

You can say like I see all of these containers running in my kubernetes cluster. Now, let's reapply the policy continuously, right? That's like you always hear about, you know, continuous compliance and things like that. And this is kind of one of those examples where you can, you can get a report every day, every hour, every whatever.

And you can look at it and be like, okay, all of my stuff is passing our policy. Or you can be like, Oh, holy crap, a bunch of stuff just failed. What's going on? And then the intent is, you know, humans get involved and, um, Kind of figure out what's, what's

Jonathan: up. So is, is Anchor mainly aimed at, uh, the, the container world then?

So can it, could I say, here's my, here's my Linux server that runs my website. I'm going to, you know, point either, uh, either the open source tool or the Anchor enterprise at it and say, I want to catalog every package and every binary that's installed on that Linux server. And I want to know when a CVE hits, is that in scope?

It is not

Josh: for the enterprise product, but with SIFT you could do that, yeah, SIFT can scan just, you can point it at slash and it'll find all the binaries, it'll find the packages, it'll find, I mean, so this is actually one of the really interesting points in this whole universe that doesn't get talked about a lot is there's no such thing as we'll say like just a node application, right?

You've got like the node. js binary that runs it all. You have supporting libraries usually that help with that. To work. You've got your packages on the system. You've got maybe some random binary crap. Someone installed in their direct home directory somewhere. You know, there's like all this random stuff.

And so we like SIFT does a pretty good job of finding a lot of there's still some things that can't identify because like, for example, if you build your own binary, like Maybe we can't catalog that, it just depends how we're detecting it. And so we also have this concept that we're working on. We call it known unknowns, where it's like, I found a thing, but I don't know what it is.

So, maybe someone should go look at that thing and see, like, is it something we care about, or is it something we can be like, Eh, whatever, it's just some random trash someone threw in a

Jonathan: directory. You're almost, that's really interesting, you're almost into the realm of threat detection then, with that sort of a capability.

Interesting.

Josh: A little bit. I mean, I would say there's, there's some strange overlaps in that regard, you know, everything from like observability and you've got threat detection and kind of same. It's one of those. I have all this data. Now, what do I do with it? Right? And in fact, there's a lot of people that take the output of these kind of tools and they just throw them into their Splunk server, their elastic server, whatever.

And then they use it as part of their whole, like, detection process, where they can say, like, Oh, I've got this evidence, then I can follow it around and, and see, like, it started out over here and, you know, that file ended up over there, or whatever.

Jonathan: I could, I could see somebody taking these, these unknown files and just, let's do a mass upload of all of them to, like, Total Virus and see if we get any hits.

Exactly. For sure. Super interesting. So, uh, you're detecting CVEs. We touched on this briefly before the show started, and I think it will be real interesting to get your take on this. So you wear a couple of different hats. You're not just the anchor security guy. You're also the open source security guy.

You've got a couple of podcasts, I think, that cover this. That's right. That's right. I have a podcast called the

Josh: open source security podcast actually today. And we're, I mean, we're like seven years into that one. I mean, we're 400 episodes and change at this point. So yeah, I've been doing it for a while. I love it.

It's a lot of fun.

Jonathan: Yeah. So. You have thoughts, I'm sure, on the, um, the absolute flood of CVEs coming out of the Linux kernel then.

Josh: Yes, I do. In fact, I, so Greg KH was a guest on my show shortly after he started doing this. And I am a massive fan of the work they're doing. I think the Linux kernel is a great example of kind of doing this right.

And it is creating a ton of work and it's a lot of effort on their part and of the people who receive it. So like, if you're on the receiving end of this, I'm I, I, I totally get it. You're overworked. It's ridiculously hard to sort through all this stuff. But at the same time, the reality is these are potential problems.

And that's fundamentally what we're dealing with when we're talking about like vulnerabilities in software. It's like, this is a, a risk that we have to understand. And as Greg, you know, so eloquently puts it, when he talks about this is a Linux kernel is run on everything from like milking machines to literal rocket ships.

And so they can't say, we know exactly how the software is being used. So we can say this bug doesn't matter. They don't know. And so that's okay. But this is where. As the security people on the receiving end, we need better tools that help us categorize and understand what we're getting. And now there's like 7, 000 layers in this.

There's everything from the data in the CVE program is absolute crap and anyone who's ever worked with it will that's not No, one's going to argue with me over that point. Like we need better data. We need better tools. I mean, this is part of what I'm doing is I'm trying to help build better tools to let us deal with all this data and information in a more coherent way.

Like we can't humans have to get as. Far out of this process is possible. We're talking about now this year, we're going to see a little over 40, 000 CVEs across the industry, and that's probably way too low. I have another thing. I think I sent you guys a link to my blog post where I talk about the size of open source.

Like there are 4 million NPM packages, 40, 000 CVEs in 4 million packages. And that's just NPM. Like that feels a little low, you know what I mean? And so it's quite likely that if we. Had good data and we had more research and we had the ability, imagine a world where we had 500, 000, a million CVEs per year, and like all the security people just like, you know, had an accident, but like, that's what we need to think about is like, that's the scale of what we're dealing with.

Like open source is absolutely gigantic. The Linux kernel is absolutely gigantic. And there, there are a lot of vulnerabilities in this stuff, but we have to learn how to deal with it better. Better. That is our new challenge. Now it's not the whole, Oh, I'm going to read every CVE and figure out how it affects me.

Like, no, no, we need tools to be able to say like, this is the CVE. You need to look at today, these other, you know, 7, 000 that came out. Don't matter. Don't worry about those. And that, it's a really hard problem.

Jonathan: Yeah, so I've, I've mused just a little bit that with the kernel, and so you, you touched on it, so what, for those that don't know, what's happened is in the Linux kernel, there's been a push to better report CVEs.

And they have essentially come to the point now to where they consider more or less every bug to be a CVE. And they've got a valid point to this, like, because any bug running in the kernel space, because it's so tightly ingrained with the system, there's a really good chance that it can be used maliciously.

And so, like, that's a fair point. Um, I, I have mused that this might be just a little bit of malicious compliance. I, I, do you think, do you think maybe just a little bit there, there's a little bit of, of, of, uh, would, would that be schoenfreude? Um, So I,

Josh: I, I thought so at first actually, but after talking to Greg, I decided no.

I think like this is like actually legitimately, The right thing to do, which makes me a little sad. Cause the malicious compliance angle like abused me. Exactly. Yes. Uh,

Dan: so with this kind of increased, um, I don't even have a good word verbosity. I'm going to say, which makes me sound clever, but increased verbosity, I suppose, of, of reporting of CVS and stuff.

Is there a danger that people become less. Um, sensitized to them, if you know what I mean, so like the, the, the, the boy that cried wolf or something, do people then start to say, well these guys are always saying there's something going on, and, you know, is, do you think that ever happens, that, that the sheer volume of them now is, is kind of making people think, oh, you know, this is probably nothing?

Josh: I don't think it will because of compliance. I think when you're in any sort of regulated environment, you have auditors that care, and they don't have to do the work, so it's no skin off their back, right? If they, if they have to say, oh, you have to deal with 7, 000 of these things a day, like, whatever. So, I, I think your point could be valid if it wasn't for regulated industry, because yes, you could easily say, like, the Linux kernel is releasing, you know, hundreds of CVEs per week, and actually, I think it's more than hundreds, it's, it's two or three hundred.

Um, but yeah, all these CVEs per week and none of them matter. So I'm just going to completely ignore it. But at the same time, I guess this is actually part of Greg's talking points is if you just follow current, you don't have to care. Right. And I know that's easy to say of, Oh, just upgrade your kernel.

It's not that simple, but if you're trying to follow. More closely than we maybe did in the past, that does make a lot of these problems go away. And I think that's part of his intent, is by just having so many and saying like, just, just follow upstream. Don't try to figure this crap out, because it really doesn't matter as long as you upgrade.

Dan: That kind of goes back to Jonathan's point about malicious compliance a little bit. Is it a good way of forcing people to follow the latest current kernel and say, or more people to kind of go? And, and isn't to get up with.

Jonathan: And is it related to the dropping of all of the long term support kernels?

Because nobody used them anyways.

Josh: Right, right. Well, I mean, that was, that's the business model of the distros, right? Is we're going to support the software for decades. And everything will be fine, except, oh, we can't do it with the kernel now, because it's too big and it's too fast and there's nothing we can do.

So, yeah, I don't, I mean, so dropping the LTS, That's something I watched quite a bit, and I mean, it fundamentally just came down to no one wanted to do the work, right? And I think that's just your classic supply and demand. Like, if there's a demand, then find some money or find some people and make it happen, you know?

And it's also open source, so you can't be like, oh, those darn Linux developers. Like, no, just go do it, right? That's how it works. Yeah.

Dan: Yeah, that's true. That's very true. Okay. So, uh, so josh, I want to back up a little bit and talk cause I, I'm not, I know a little bit about security, but I'm not really up on a lot of this stuff.

So I, for the benefit of some of our listeners, I know we have a very technical crowd who listened to this show, but some of the layman, I suppose. Um, can you tell us exactly what an S bomb is and how it works? So it's a, it's a, it's a, am I right in thinking it's a bill of, uh, what is it now? Well, in fact, why am I trying to answer my own question?

I don't know what I'm doing there. Can you tell us exactly what an S bomb is and why

Josh: it's important? Yeah, I mean, so, it's a software bill of materials, right? The idea is, all of your software has stuff in it. And some of the stuff you wrote, most of the stuff you didn't. And so you have Like you might have NPM packages, you might have Rust crates in there, you might have Go, whatever.

And so basically what a software bill of materials is meant to be is on any system, any application, it catalogs all the stuff in it. So like if you do an NPM install and it installs 100 things, those 100 packages would show up in the software bill of materials. And you can also imagine that you can have like different Kind of pieces of software where you have a, a container image and then you have your software and those, those are two different software bill of materials.

Now you put them together. Now you have a third software bill of materials that is functionally the other two pasted together. And so the idea is just like, it's imagined when you, when you buy something from Ikea. Right. They always have that list of all of the parts that should be in the box. And in fact, I don't think he has ever screwed me over on missing parts, but you know, that's the intent here is if I get a piece of software, what are all the pieces in the box essentially?

And then we can start asking questions about those pieces. And like, one of the really interesting things I like to do is, so if I get an S bomb from somebody, I'll, I can, Look at it and understand it. No, I shouldn't, I should use the word look at loosely because there's usually thousands and thousands of packages of this stuff.

Like I'm, I'm kind of an armchair data nerd. So I just put everything in elastic search and then I do stuff from there, which is not, I know that's not how normal people work and that's okay. That's why we need tooling to help us do this. But anyway, someone gives me an S bomb and says, here's the S bomb for the thing I built.

And then I scan it. And then I say, what's, what do I see? Are they the same? Are there things different? Like, did stuff get added somehow no one knows about? Did stuff get removed? How did that happen? And this is like one of the really cool things you can do, is you can watch your software as it kind of traverses from the left to the right.

And you can be like, why did this file get put here? How did that happen? Or why did we remove these packages over here? I don't understand why, why we did that. And so there's, there's just all this weird stuff you can start doing and asking questions about your software, because, I mean, let's face it for the last, what, 30, 40, 50 years, the vast majority of software has been kind of YOLO.

We're like, we type make and we get something out the other end and we're like, I guess that's it. Like go run that in production.

Jonathan: Yeah.

Josh: It's, it's funny when you think about it, but at the same time, it's like this stuff is like running the world. I mean, I feel like we should know a little more about

Dan: it.

Yeah. Is there a standard format for S bombs? Could I take an S bomb that was generated by SIFT for example, and ingest it into, uh, into another. You know, program another, another, another company's tool or another project's tool? In theory,

Josh: yes. So, Okay. So we are kind of early days still. There are two primary S bomb formats.

There's something called SPDX and Cycle and DX. And They're they basically do the same thing. I mean, I know you can nitpick over Oh, this one does, you know, it records dates a little different or whatever, but what it doesn't matter fundamentally they're the same thing and the intention being that you have interoperability between tools and and whatever and Some of the tools can do this.

Okay, not all of them can because like any good standard nothing makes sense So there's tons of wiggle room And they're working on fixing it, like they're on, I mean, SPDX is I think 2. 6 now, SPD, no, SPDX I think is version 2. 6, and they keep adding changes to this stuff, and they're constantly trying to, I guess, bring the, the formats a little closer together so they work better, like one of the things SIFT does, so, SIFT, if you run SIFT, the default output format is something we call SIFT JSON, And it's funny because the S bomb people like, Oh my goodness, did you make a third format?

I'm like, no, no, we did not make a third format. We are basically just, we just take whatever SIFT has in memory and we dump it out to JSON with the intent. There is more data in that than either CycleNDX or SPDX collect with the intention being you can convert between CycleNDX or SPDX because like if you have an SPDX document you can't today convert it to a CycleNDX document You will lose information because there are those little niggles back and forth So you kind of it's kind of imagine Google Translate where you know, you you can You keep translating something back and forth and you end up with a hilarious output at the end, same sort of problem today where it's being worked on, but I mean, you have to remember too, like these formats are not like, it's not old, right?

We're, we're still very early days here and it's getting better. It's getting better. Thank goodness.

Dan: So you mentioned that the sheer amount of data and so on, is there, I'm going to, I'm sorry to have to invoke this, but I'm going to, um, is there an application for AI in this where you could use something like an LLM or something and train it with some of this data?

I mean, there's people

Josh: looking into that for sure. I, I think it is an excellent question. What can we do with them? Like, I, I haven't seen anything I would say is particularly compelling yet. Just because I feel like this data is kind of boring and There's not a lot of wiggle room. Like if an LLM gives you a, a, a weird version or a weird package name, that's potentially bad, but I know there's, there's interest today in doing things like saying, okay, I've got this S bomb, I've got all these vulnerabilities in it.

You know, what, what should I start working on first? How can we look at this data and maybe unwind it a little bit using something like an LLM to maybe understand the vulnerabilities And your product is like a really good example is so let's say I have a container image and it has a website open to the Internet, right?

That is going to have a very different threat model than if I have an application that is. Downloading a CSV file from a website and then parsing it and uploading it somewhere else, right? And so this is, that's one of the places I've seen some of the LLM efforts look interesting because you can say, like, this is what my application does.

Now, you know, based on this information, look at these vulnerability details and tell me which ones sound like they are going to affect me in a very bad way.

Jonathan: You know, I'm, I'm aware because I cover this stuff for Hackaday that, um, people are using AI in security. Research and it's not necessarily going well.

It's actually, it's actually a real problem for open source projects. They are getting particularly those that have bug bounties. They are getting vulnerability reports that have been generated by AI. And the problem with that, and this is sort of just in general, this is the problem with AI today, Um, they sound very plausible.

And these vulnerability reports, they are like, very well done, well written, very plausible sounding reports, that are totally hallucinated. Yes. Is that something that you're seeing more broadly? Is that something that, uh, I guess you guys are hooked into? To even observe it?

Josh: Not I I'm not affected by that in any way I know some people that have dealt with it and they've they put the hammer down pretty hard because it really really annoyed him a lot However, there is some really cool security research I've seen in the LLM universe where you have Researchers training up models, you know the code models and they're saying like here is a description of a vulnerability I want you to write an exploit for this vulnerability Against this application right here, and that's been reasonably successful, which is a little terrifying sometimes because most vulnerable, like what's the stat?

I think like 3 percent of vulnerabilities are actually exploited, but with some of this technology that could even if it doubled. The workload probably quadruples, right? I don't think we're talking about linear scaling here between the vulnerability rate and the work that the security analysts have to do.

And so that's kind of a weird, scary part. And then there's also people doing research where they're basically saying, I want you to just take this application and find a cross site scripting flaw in it. And that works surprisingly well also, which they are there. We start getting into, you know, the whole like 500, 000 million CVEs per year.

If we have. automated discovery, obviously, you're going to have, you know, a huge influx of vulnerabilities, which we are not at all prepared for in any reasonable way today.

Jonathan: Yeah, boy, you could imagine, uh, uh, you can imagine a scheme where you take a, uh, you take an LLM and you write the prompt that says, you know, find this kind of vulnerability and write an exploit for it.

And then you hook that into on the backend, a fuzzer. That actually tests what it could, what it spit out. And then if you were to feed that output back into the LLM, and I imagine there are people trying to do this right now, but you actually get a positive reinforcement loop that actually works, because it'll tell the, it'll tell the LLM, that one worked, that one didn't, and particularly as you start scaling up the speed in which it can churn through that loop.

Yeah, that's going to find real vulnerabilities. Of course it will. So

Josh: that happened. DARPA had, uh, like basically a security capture the flag event. And there was a, an AI, it was originally done by Carnegie Mellon. It was called mayhem. Um, David Brumley's behind it. He has a company now and he just changed his name.

I can't, it used to be for all secure. I don't remember what they changed it to, but anyway, mayhem was designed to basically look at like a binary. Find problems in the binary. So we're talking about like just operating on straight up binaries. Like we're not even looking at code here. Find problems in binaries, fuzz it, find out how to exploit it, write the exploit, then also write a patch in the binary.

So the other team can't exploit it against you and then going and attacking them with the thing you just found, which is like all automated. It's like, holy crap. This is ridiculous.

Jonathan: Yeah. Well, so that's, I guess that's the next stage of this. When we, when we finally reached security nirvana, you've also got, so you would have to write it, you'd have to write a really good test suite to make sure your program is working correctly.

You run through this process I just described to find the vulnerabilities, and then you also tell the LLM to fix the vulnerabilities, and you feed that back into it as well. And as soon as you fix the vulnerability and still pass your test suite, Might have good code on the other end of it. Hopefully. We can dream.

Yeah, right, right. Okay, so, the many, many, many vulnerabilities found, lots of CVEs. Um, how are the various organizations and agencies that are responsible for Tracking and catalog, cataloging these, you know, you've got NIST, you've got MITRE, you've got the NVD. How, how are they doing with it? Oh my goodness.

So it's, it's

Josh: been a rough year. So, so anyone not in this space might not know this, but in February or March of this year, I forget when it was, NIST runs a database called NVD, which stands for National Vulnerability Database. And what they used to do is. MITRE, which is a government contractor, runs the CVE program, right?

And so people who, like, get CVEs, you get them through MITRE. You can have a company that can assign their own CVEs, but they go through MITRE. Or, like, security researchers can just go to MITRE and ask for a CVE. So those all go into MITRE's data set. And that data is very bad. As anyone who's ever looked at it knows.

So NIST had a program called NVD, and they would take the MITRE data, And they would add, they would enrich it. They would add some version information, some like package information. They would add like severity. They would guess at severity. Their severity scores were often very bad. And they would kind of add this information.

And then they just stopped one day, like no word or warning, no nothing. And, and I, in fact, uh, uh, there's a handful of us security nerds who like, look at this data. And I remember we were like, Do you guys like didn't stop and we're like exchanging notes and being like, holy crap, like they stopped. There's, there's no new data.

What's going on. And then of course we'd email them and crickets. No one knew. And so they just like literally fell off the face of the planet for probably six months almost goodness. And then at the same time you have Sisa. starts a new program, they're calling Vuln enrichment. So now CISA started doing some enrichment.

NVD has sort of come back and they're doing some enrichment, not everything, but some, there's still a giant black hole in the middle where they didn't do anything. And then you also have MITRE trying to ask the CNAs to do a better job of providing nicer data. So now instead of having one, And a half, we'll say organizations providing not good data.

We have three organizations all providing, we'll say incomplete and difficult to use data. And so for, for vulnerability nerds right now, it's like, it's a mess. It's really hard to figure out what to do. It's really hard to understand. I mean, this is a huge challenge we have, because obviously we have gripe at anchor and gripe means vulnerability data, and so we've got, you know, a team of people that are doing their best to try to unwind all this and make sense of it.

And it's. It's not, it's not the most fun, not the most fun at all. We've ever had, but you got to do what you got to do.

Jonathan: So I don't know.

Josh: It just kind of is what it is today.

Jonathan: There's, there's several different directions. I want to go with that first. You mentioned CNA is what's a CNA. They call that a

Josh: CVE numbering authority.

That is where, and this, this is like such a fricking mess too sometimes. So, um, yes, curl, which we've all heard of. So, so the guy behind it, Daniel, um, baggery goes by online. There were all of these CVEs being filed against curl. And he was upset with them because they were kind of garbage and they shouldn't have been filed and he tried to get rid of them, but working with NIST and MITRE is like an impossibility for the most part.

They just, they don't have to listen like their, their, their customer is the U. S. government. So, haha, no. So anyway, CURL has become a CNA. A CVE numbering authority with the sole intent of being able to get rid of these crap CVEs and just not have to file them at all, which is a super heavy handed way to just like match reality.

And, and the thing is like, Daniel's way brighter than a lot of people and like he works on curl full time. So he can pull this off. But like, if you're an open source project that you work on an hour a week.

Jonathan: Yeah,

Josh: there's no way you can do this kind of thing. And so that's one of the complaints I have is just the fact that all of this, all of these organizations, all this data, it's just like such a one way black hole that no one knows how it works.

No one knows what's going on. I mean, I've been complaining forever that this is exactly the sort of thing. That should, like, exist in some sort of open source foundation

Jonathan: and

Josh: have, like, proper bylaws and, you know, proper governance and we understand how everything works and all of that, but I've been screaming into that void for more than 10 years now.

And put it

Jonathan: on

Josh: the

Jonathan: blockchain, right?

Josh: I'm sorry,

Jonathan: I couldn't resist. That will solve everything. Um, you've got a few companies out there that are trying to pick up some of the, like, GitHub really comes to mind. I've been, I've been involved with a couple of CVEs now that, uh, GIF, GitHub has been the CNA for, and they've, they've got a lot of automated tools with that.

I think they do have some human review in there as well. And that's actually been a really good experience. Um, they do.

Josh: So GitHub's doing some very clever things here, actually. Mm-Hmm. So they, they are a CNA, they will assign CVEs. Yeah. But they also have their own data set. They have the GitHub advisory database.

Mm-Hmm. and, no, I'm sorry, . They, they kept yelling at me about this. It's the GitHub vulnerability database holds GitHub advisories. . That's how that works. Okay. It's very important to get this, but they have a team of people that what they do. So actually, I said there were three organizations, there's kind of four, if you consider GitHub, where they have a team of people that look at all of the CVEs that affect the, the ecosystems GitHub cares about.

They focus on things like, like Maven and NPM and Python and Go. And there's a couple of others. I can't, Ruby is one of them. And what they do then is they. Do a really nice job of kind of teasing out what is the ecosystem, what is the package and what version fixes it. And what I love though is if, if you find an error, you just submit a pull request and then they either say, yep, that's it.

Perfect. It'll be like, I don't think this is right. Like. I think this is the thing, and then you can have like an actual discussion in the issue and you can come to a conclusion and everyone can see it because it's, you know, just GitHub and all in the open and their data, quite frankly, is the best vulnerability data that exists today.

But unfortunately, it's just a subset because obviously they do not have infinite resources to do this. So they purposely constrain themselves. But because of that, it is just so good. It's amazing.

Jonathan: Yeah. So I have tried, by the way. I cover vulnerabilities and I've found typos. When in particular comes to mind, I found a typo in a CVE on, I forget whether this is before or after the switchover.

So, you know, maybe it was at MITRE or maybe it was at NIST, you know, things have moved around a little bit over the last couple of years. I found a, a, a, a typo in what version fixed a vulnerability. Like you go to the vendor's website and they say one thing, you go to the CVE and it says something else.

So like, Oh, Hey, I'll get this fixed here. Shoot an email off real quick. Surely they'll get it fixed. I still haven't heard back. I bet it's still wrong.

Josh: Yes. So I've, I used to do this all the time where I would, I would try to get things fixed and I have quite frankly, just given up because what it usually is, is you say, Hey, MITRE.

And yes, you have, like, you can look at the website, you can see the version, right? Like, I have definitive proof this version is wrong.

Jonathan: Yeah.

Josh: And I remember the, the one, like, blazing into my mind when I just threw my hands in the air and gave up is I emailed MITRE, and I'm like, hey, look at this, like, here it is, and they said, oh, no, you have to go to the CNA that filed that, but who's that?

Like, and I, you couldn't tell you now they're putting the CNA details in the CVE data. Thank goodness. But at that time it wasn't there. So I'm like, who's the fricking CNA? And they're like, oh, it's so and so. It's like, so I have to go call, like email this person. And I sent them an email and they never replied.

And I'm like, you know what? This is ridiculous. I'm just, I'm out. So now when I see problems, I just go to GitHub. I make sure it's correct there. And like, I'm happy. And that works.

Jonathan: Yeah. So one of the, one of the other things that has been a big problem for the industry is the, um, the CVSS system, the numbering system, like how, how severe a problem is.

And there's this, what, what, how shall we say it? Um, it's almost a conflict of interest because like the vulnerability researcher is looking for the highest score they can get. Because sometimes they get more payout, right? Like sometimes you get a higher payout because you're working on a bug bounty. So if you find a CVSS 10, you're going to make thousands of dollars.

Whereas if you find a CVSS 5. 5, you'll get a couple of hundred dollars. So like they are, they are, um, there's an incentive. They are incentivized to get a higher. CVSS. And then on the other side of it, you've got, in some cases, the vendors that it's like, they do not want to make the news for having a CVSS of a 10.

0. They want that to be a 5. something. And, oh, getting those fixed when they're wrong has been such a problem over the years, because sometimes they are wildly wrong. Yes.

Josh: Yes, you're exactly correct. And you have researchers will, they'll, they'll mis describe the, the vulnerability. And, and the thing is like NIST has a very limited window into what things should be rated.

And additionally, we're like using CVSS completely wrong. It's not meant to be a, a just like raw way to score this stuff and then rank it. There's, you're supposed to add in other information. Like, how am I using it in my environment? Like, you know what I mean? Yeah. What is, what does it look like? Is it, is it being exploited?

There's actually a system that's newer ish called EPSS, Exploit Prediction Security System. EPSS is really cool. What they do is they, uh, it's part of, um, first. org is where they, they kind of, that's where their home is. And they're collecting like all of this data. And it's not all public data, which, It's like all of this threat data is super expensive and the fact that they're getting threat data for free is amazing.

So I'm not going to harp on that, but they're kind of getting all this threat data. And what the EPSS score is meant to be is it's meant to be like, what are the odds this vulnerability will be exploited in the next 30 days? And so the intent being things with higher odds, those are things you should look at.

And now that's an example where you can like, if it has a high CVSS and a high EPSS, now we're, now we're talking like that's something to look at. But if it has a high CVSS and a low EPSS, it's like, eh, we should probably double check what's going on here. Cause this is weird. And so EPSS, I think has a lot of.

I have a lot of hope for it, and they're on, I think, version 2 of the model, version 3 is coming out very soon, I believe, I might be wrong, version 3 or 4, I can't remember, but they have graphs that show how accurate it's been, and when it started out, it kind of sucked, as all things do. Do when they begin, but they're actually doing a really good job now where their, their prediction models are quite good.

And they update it once a day. This is the same idea of like, you can scan your S bomb for vulnerabilities every day, and it could be different. The EPSS score is going to change every day just because like the threat landscape is constantly changing out there in the universe. And so this is one of those things, like you can look at your EPSS score functionally every day, and you can get a better idea of like, what do I need to work on?

What do I need to worry about? Whereas like, again, CVSS. Once you have a CVSS score, it's kind of set in stone, right? Cause that's just how it works. And that doesn't always make sense. Things change. The universe changes around us and we have to try to adapt to that.

Jonathan: I was, I was pretty excited to see the new CVSS 4.

0, the new revision of it. That's supposed to be a little smarter and, you know, supposed to not give you 10. 0 scores for things that are really, really trivial and not actually that serious. And so every time I go to cover a CVE, I go on, Oh, what's the, what's the CVSS 4. 0 score? Surely, by now, it's been out long enough that somebody's using it.

I have not seen, I have not seen anybody use. The CVS has 4. 0 scoring for anything. So like it, it theoretically exists.

Josh: So the vendors hate it, actually. The secret there is, so for, for we'll say low and moderate things, it definitely bump, it kind of, it brings everything to the middle is what I would say.

The high things are coming down, but the low things are coming up. So the vendors hate it because now things that might've been low or moderate are being bumped into moderate or importance. And like you said, The vendors have an incentive to lower the severity of things. So from their perspective, CVSS4 is an anti feature.

Because it's going to actually create more work for them and their customers.

Dan: Makes sense.

Josh: Yeah, yeah.

Dan: Yeah, so, so Josh, how many people are working on, on SIFT and, and GRIPE? What I'm interested in is the community engagement. Are you getting code in from outside of, of the company? Uh, are you getting pull requests, are you taking pull requests, that sort of thing?

Yeah,

Josh: Yeah, oh for sure. We definitely are like we love pull requests. We love the community. We've got a discourse We've got it's all a github. We've got community meetup every other week I think it is the the open source team with with popy They do like a live stream once a week where they kind of do like some of their bug You know, wrangling to figure out what to, what to do.

I mean, we've got a team of, so I think we have a dedicated team of, I don't know, is it five people, six people? I can't remember exactly what it is, but then obviously you've got more anchor involved as well. And then, yeah, I think we have like hundreds of contributors. I don't remember the number off the top of my head.

I'm, I'm ill prepared for that question, but it's, It's, it, it's pretty impressive, honestly. And there's, we're, we're seeing more and more community involvement, which is a double edged sword though, right? Because you get more bugs, you get more pull requests and it's not like, I always love this. Oh, open source.

We'll give, do our free work for us, but like, it's free, like a puppy. Cause you have to, you know, you have to read the bugs. You have to triage of the bugs. You have to. look at the pull requests and be like, Oh, we'd like to do it this way instead, whatever. And, you know, it's, it's a lot of work, but it's really cool because yeah, we're seeing, we're seeing some pretty cool contributions.

In fact, where there's, um, uh, there's a thing called Bitnami, which is like a container runtime universe. Like there's, they just submitted a, a giant patch to SIFT to properly catalog and index their containers, which is amazing, you know, like that's exactly what we want. We've seen a couple other organizations, you know, Give us, um, we call them catalogers in SIFT, which is where we have the ability to be like, oh, this is Like, um, I think it was just a NET that got added where it's like, this is, you know, a NuGet repository.

So figure out what to do, NuGet cataloger. And, and yeah, like we're, we're pretty pleased with, with how it's going. And, and like, that's the dream, right? Is you start an open source project and ideally you want a community to build up around it, which makes us very excited and very happy.

Dan: Hmm. And I, I know I don't have, I shouldn't have, I shouldn't really have to ask this question on an open source podcast, but I want to anyway.

'cause I think it's always great to get people's opinions. What's the benefits to, uh, Ancor in releasing these things as open source? Because we, we preach it all the time here, but we've, we'd like to. So let you preach it, I suppose. All

Josh: right, all right. So I've got, I spent a decade at Red Hat

Jonathan: and

Josh: I, I spent time at a little Linux startup called Progeny Linux Systems before that, which the, uh, Ian Murdoch, the founder of Debian created a startup and we'll say it wasn't real successful, but, uh, But anyway, so I spent a lot of time at Red Hat.

So like, my career is steeped in open source. And I remember my first job out of college was at a company that wrote life insurance software in COBOL. And this was like right after the dot com crash, so it was dire. I'm like, I will literally take any job. And And I did, but I remember they, like, I'll never forget it.

You know, there were people there that were like, this open source stuff is stupid and it's crap and it's never going to catch on and you're wasting your life on it. And of course being young and, and filled with, you know, optimism, I was like, Oh no, no, it's, it's the future. It's going to win. And like, thank goodness it did.

Cause I'd be, you know, probably broken homeless otherwise, but, but, so the thing is like, Angkor has a bunch of red hat DNA in its blood. Like there's a bunch of red hat folks that are at the company. And so it's. Thank goodness, not something we had to like educate or understand, but fundamentally. So the idea is we've got the, like the, the bottom of the pyramid is open source.

We have sift and gripe and we have a bunch of like this tool called grant. We've got a whole bunch of other like open source libraries that kind of drive all of this stuff. And then, The intent being by making a tool like sift and a tool like gripe open source, you, you get community contributions are awesome and we'd love that, but you also get a certain amount of just kind of engagement in the wider universe, right?

Where you have people running these tools, you have open source projects running these tools. You've got, um, we just had a Allen actually webinar with Google where Google is scanning. Like all of their stuff with SIFT, they're literally scanning, you know, millions and millions of things every day with SIFT.

Like, that's really cool. They have good feedback, obviously, as well. And that's like the power of open source. Right. And then what we did is we took kind of those. Core functions and we built product on top of that because it's easy to say, Oh, you're going to run SIFT across your entire infrastructure.

And if you're Google, you can do that because you have an army of engineers. But if you're a small company working on something or even a medium or even large company working on something, you have to ask, like, is it worth just buying a solution that will do all of the plumbing and all of the monitoring and all of the policy and all that stuff?

Or. Should I hire an army of people that are going to do this as well that will probably cost somewhere between three and ten times as much as just buying a product. And so that's kind of like that very red hat model of there's like that core base functionality and then there's things, there's value added to the top and we've got, you know, we've got support, you've got services, there's, we can help you figure this stuff out because it's weird and hard and, and if there's a problem with your data, like, Open and support issue.

And it's going to come to my team and we're going to tell you what's going on. And often we just fix it because it's like, oh yeah, that data is bad. We'll go fix it. And so that's kind of the beauty of that. And yeah, that's what. It's been a treat being there because I don't have to fight for whether they should or shouldn't be open source or whether this is or isn't a good idea, like everyone totally gets it.

It's awesome.

Dan: That is very cool. Um, so I always like to, to, to ask people how they got involved in, in all of this. How did you get into what you do now? How did you get into open source initially? And how did you get into computing even? How far can we go back with this? You can go pretty far back,

Josh: man. I mean, I've been, I mean, I'm, I'm old.

I've been doing this for a long time. You know, I, I grew up without a computer in the house. Punch cards, was it? No, not quite, not quite that far. Not the punch cards. No, no, I don't. I didn't have access to punch cards. I would have gladly used them if I could have. But no, I mean, the first computer that came into my house was like a, it was a 386 running MS DOS.

Right. So, I mean, we're talking like early nineties, somewhere in there. And I just, it was, I loved computers. I've always loved computers and I'll never forget like my. You'd go to school and you know us old geezers We had like a couple Apple twos at the school and we do things with them and stuff And I remember my my parents came home from a teacher conference one time and they were started yelling at me And I'm like what and they were like you have to stop helping them with the computers because you don't know what you're doing I'm like, what do you mean?

I know what I'm doing. It's like I knew more about the Apple two than the teachers did. Cause like I would read anything I could get my hands on. It talked about computers. Right. And I mean, I remember people laughing when I tell this story, but like, I used to write down basic programs on a notebook paper and I would like, I would run the program in my head.

I didn't have a computer. So I'd be like, what was this program going to do if we run it? And you know, I'd write it out and figure out what the program would do. Which nothing long, of course. course, but like, I, I just always loved it. And so, you know, computing will say for a while, and then this Linux thing you start hearing about, and it's like, wait, I can get free stuff.

Like, well, I mean, we'll say a lot of software was free back then, if you knew the right people, but this is like, you know, free compilers, I can get, you know, a nice. Uh, a Unix terminal that doesn't cost any money and it works and it's awesome. And then I think the real thing that tipped me over the edge was I go to college and they've got sun workstations everywhere, right?

Cause I'm an engineer. It's just sun gear every like the sun, a sun workstation, like 45, 000, right? They were crazy expensive. It was 45, 000 in nineties money. So we're talking a lot of money today and I'll never forget. It was like, there was this. This stuff I wanted to do where there were programs I wanted to run, you had the ability to, you know, do like X windows between systems where you could like run something on the server and you get the X windows.

Window on your system. And I was like, Linux, let's me do all this for nothing. Like this is a no brainer. And so it was really, I mean, I mean, honestly, it was just, I was too poor to buy a sun workstation. That's kind of what really got me into it. If I, if I had a ton of money, I'd be running sun gear at the time, but it was Linux, but then the, you know, the thing is it just, it, it, it gets you, right.

You get that bug of like, oh, I can talk to the people who do this. I can send patches. I can work with them. I can build my own kernel and. You know, completely trash my machine and learn more than I can imagine in the process. And, and it just, I don't know, I caught that bug and it's just, I love the community.

I love how it works. I love everyone helping each other. It's just everything about this universe has been a treat. And like, I, I've built my life and my career around it. And I've, it's been lovely. I, I have absolutely no complaints or regrets and I love open source. It's, it's absolutely amazing. And. Every day I just think like what's the next crazy thing that's going to happen and I'm never disappointed.

We'll say that but yeah, it's fabulous.

Dan: Awesome. So, uh, I just came up when you were saying that you got bitten by the bug. I was thinking bitten by the penguin by a penguin. The penguins don't have teeth though, do they? So I don't know how quite that would work, but

Josh: they have like sharp. Barbs, I saw a picture one time inside of a penguin's mouth.

It's like a Lovecraftian horror.

Jonathan: Oh, that's great. All right. We are, boy, we're starting to run out of time here. Um, is there anything that we didn't ask you about that you want to want to cover and make sure folks know about? Many

Josh: things.

Jonathan: Yeah, I'm sure.

Josh: No, it's, I mean, I think the one thing I would say is, so I, I adore, this universe, like the open source security, all that stuff.

And if like anything I've talked about catches your interest and it's a topic you'd want to discuss or, or learn more about or anything, like reach out. I love talking about this stuff. I will talk your ear off if I can. I mean, I have a podcast just cause I love it. I've actually have two podcasts. We talked about the open source security podcast.

My other one, I call Hacker History, where I just take like old people and I say, tell me your hacker story and that's it. And then that's it. We learn about crazy things from the days of yore. And it's, that was super fun. It's, it's, it's, it's tough to find guests, but I'm always looking for guests. So if anyone wants to tell their story, like hit me up there too.

And yeah, it's just, that's kind of the biggest thing is just, if you want to have a chat ever reach out, I would absolutely love to, cause there's so much going on, there's so much interesting stuff and it's just so much fun to talk about, I love it.

Jonathan: I was going to have you make sure and plug your podcast, but I think you just snuck that in there, didn't you?

I did.

Josh: I did. I'm pretty shameless like that, so.

Jonathan: A skilled, a skilled commentator.

Dan: That's

Jonathan: right.

Dan: In security speak, it was the payload in the, uh. That's right. Yes, exactly. Quickly run off the end of my security knowledge there. I went payload. Yeah. Okay. Show code has been executed. Yeah, that's right.

Jonathan: All right.

So, uh, what's your, what's your favorite then, uh, scripting language and, uh, editor?

Josh: Okay. So I, I was alive for the VI versus Emacs wars and I still run VI all the time. It is. Probably my favorite editor. I think I use VS code, we'll say for anything remotely difficult, but VI still is like, that's where it's at.

It's amazing.

Jonathan: It's amazing. How many people answer VS code to that question either directly or indirectly. It's so good,

Josh: but it works. It does what I need.

Dan: Yeah. It's a good tool.

Josh: And then scripting language. So I, I know many of your guests, because I, I listened to the show. There's always a, is Python a scripting language?

And I, I, I've been thinking about this like since we, you booked me, I'm like, should I say Python? I'm like, I gotta say Python. Cause the thing is, every problem I have at this point. Ends up with a Python script to do it, you know, like I'd love to say shell or like bash or whatever, but it's Python. Like it's funny.

It's it's become like the, you know, Swiss army sledgehammer of programming. I think it little things are big things that it all works. It's it's kind of a replacing Pearl

Dan: for that position.

Josh: Oh, yeah,

Dan: for sure. Somewhere. Randall just exploded. I thought I had a faint explosion in the background. Yeah. Yeah,

Jonathan: that was

Dan: Randall.

Jonathan: We have discovered recently that any language could be a scripting language if you really want it too badly enough. We had somebody doing the Java for scripting, for system scripting. There

Josh: you

Jonathan: go. I remember C

Josh: Shell, right?

Jonathan: Yeah. Yeah. Yeah. It exists. It does. I, man, I am, I am in a group right now that, uh, one of the guys is a huge C sharp fan and I'm sure he, he does.

No, he actually, he does. I'm sure he uses that C

Josh: sharp C shell. There was a shell from long ago that had a C syntax, but it was a shell. I know. Right? Like I remember that too. Yeah. We'll say corn shell and flood us all with horrible memories of each like some pain with your pain.

Jonathan: Oh, that's right. All right, this has been this has been great. I don't want to let you go. It's been so much fun We'll have to head back. I actually wrote a note in our back channel Like next time we need a uh, we need to we need to do a roundtable because a guest flakes on us I'll have to reach out to to this guy and I think our guest from last week.

We also made that note about so Maybe we'll do that, maybe we'll have a running list of guests and co hosts and when we have to scramble we'll just shoot a mass email out. So this is what we're doing, this is where we're doing it. Awesome. Uh, it'll be fun. Alright, thank you man, I appreciate it so much, it's been glad to, it's been really good to talk to you, uh, Josh Bressers everybody, thanks for being here.

Thank you much. Alright. Uh, what do you think, uh,

Dan: what do you think Dan? I thought it was great. What a great discussion. As you said, uh, we, we could, we, we seem to say this on every show, but we could have kept going for a long time now talking about all kinds. I really thought we're going to get into penguins at the end there and whether, you know, with the whole penguins and teeth and all that, I was, I could have gone in that direction.

Um, I was, yeah, I was interested. Something I'll, I'll ask, I'll have to ask Josh when he's talking, I'll check his podcast out, the hacker history one, because I'm really interested in the whole phone freak thing and from the seventies and the sixties and all of that original. Audio hacking of, of phone switches and so on.

So, so I'll ask him if he's got any, had any of those kind of people on Yeah. Uh, yeah. Fascinating guest. Fascinating guest.

Jonathan: Yeah. That, that is, that is really interesting history. And if he hasn't, we'll have to make sure and request some. Um, there are, there are still some people out there that are active. Um, right, right.

That, uh, one guy that I've, I follow on Twitter and he, he. Evan Dorbel is what he goes by and just some great stuff. The cool thing about Evan is that he, he was also like an audio, he was a phone nerd, but also an audio nerd. And so he has recordings of the phone system from way back in the day. And so like, he's got these narrated clips of.

He, this is, this is what you hear when you do this and this is what the equipment on the other end is actually doing. And it's, it's really cool. So we'll have clear all clips from like all the different exchanges and like, here's how this one sounds different from this one. That's why. So Josh, I know he's still listening to us.

Josh, if you haven't had him on yet, see about Evan Doorbell and some of those guys. That'd be a lot of fun. Uh, alright, uh, do you wanna plug anything Dan?

Dan: Um, I want to, yeah, I mean, uh, go to my website, danlynch. org, if you want to find out what I'm up to, and, um, I'm going to do a community style plug, because, um, I run our, I'm one of the people who run our Linux user group in this area, and I think everyone should, you know, uh, the whole Linux user group movement kind of has lost, you know, Momentum in the U.

K. And I'd like to say, you know, if you're interested in Linux, have a look, look dot org dot U. K. Find out where your local log is. Or if you're near the northwest, come to Liverpool. We run Liverpool log. We have stuff on every month. So check that out.

Jonathan: The Linux user group scene has just moved online. It's still, it's still alive and well, it's just It happens in Slack and Discord and a little bit in the IRC and Telegram and

Dan: Signal.

I have been to Linux user group meetings with people all like 10 people sat in a room all hunched over computers like this talking to each other online and I think, why are you here? You could have done this from anywhere, you know, you're not even talking to each other, you know, anyway, that's just my own personal gripe.

Jonathan: Yeah, we, we nerds are, we're a weird breed sometimes. All right. Well, thank you, man, for being here. I have a couple of things that I want to plug, and, uh, of course, the first off is Hackaday. We've got my security column. If, if this is not enough security for you, you can get even more of it, week to week coverage there.

It goes live every Friday, uh, and we also sure appreciate Hackaday being the home for Floss Weekly. Um, there's also the Untitled Linux Show over at Twit. If Linux is more your thing, you can find our weekly musings about that over there. Uh, we do not yet have a guest for this upcoming week. on the 5th, but on November the 12th, we're talking with Frank Delaporte about Pi4j, which is another Java thing, but it's, it's doing, uh, it's doing Java on the Raspberry Pi, and specifically, it's about being able to access all of those peripherals, you know, GPIO and SPI and I2C and UART with, with Java bindings.

And so that, that sort of, that sort of tickles my, my interest, interested bone I've been working with. Some of that stuff myself here recently. Um, and then one other thing that I will let folks know about is, uh, later today in my time, I don't know when all of this will go live, but, uh, I'm going to be interviewing with Brody over.

He's got a, the YouTube channel. Um, is it just Brody Brody talks Linux? I don't, I forget what his channel is actually called. You can search for Brody. You'll find him. One of the other things he does though, is he does tech over T where he interviews folks. And I. commented on something on, on Twitter slash X and he sent me a PM.

He's like, Oh, by the way, I've been meaning to invite you to come to this. So that is happening later today. So watch for that. If that's something that you will find interesting. Uh, we sure appreciate everybody that's here. Those that caught us live, those in the discord, making notes and commenting back and forth and all of y'all that get us on the download.

Sure. Appreciate it. We will see you next week on Floss Weekly.