Matt, Izar, and Chris have a lively discussion about how security experts perceive open-source software. Referencing a post that described open source as a 'hive of scum and villainy,' the team dissects the misconceptions about open source software and challenges the narrative around its security. They explore the complexities of the software supply chain, the notion of 'inheritance' when it comes to security vulnerabilities, and the impact of transitive dependencies. They also discuss reputation systems, dependency injection, and the reality of accepting responsibility for incorporated software packages and their security issues. Tune in for these and other thoughtful insights about the interplay between open source solutions and security aspects in software development.
FOLLOW OUR SOCIAL MEDIA:
➜Twitter: @SecTablePodcast
➜LinkedIn: The Security Table Podcast
➜YouTube: The Security Table YouTube Channel
Thanks for Listening!
Matt, Izar, and Chris have a lively discussion about how security experts perceive open-source software. Referencing a post that described open source as a 'hive of scum and villainy,' the team dissects the misconceptions about open source software and challenges the narrative around its security. They explore the complexities of the software supply chain, the notion of 'inheritance' when it comes to security vulnerabilities, and the impact of transitive dependencies. They also discuss reputation systems, dependency injection, and the reality of accepting responsibility for incorporated software packages and their security issues. Tune in for these and other thoughtful insights about the interplay between open source solutions and security aspects in software development.
FOLLOW OUR SOCIAL MEDIA:
➜Twitter: @SecTablePodcast
➜LinkedIn: The Security Table Podcast
➜YouTube: The Security Table YouTube Channel
Thanks for Listening!
Villainy.
Chris Romeo:that's going to get added to the, that's going to get added to the recording right there. Hey folks, welcome to another episode of The Security Table. I'm Chris Romeo, joined by Izar Tarandach and Matt Coles. We are the People of the security table. I don't know what to call us. I'm kind of working on nicknames and things like that. And that one was terrible, but it was off the cuff. So, um, we got an issue today that we want to talk about. So I did a podcast interview on the AppSec podcast talking about software supply chain. And, uh, there was another LinkedIn post that made reference to it. And it pointed to an issue about how security people love dumping on open source as a challenging thing, or as something that's the villains,
Izar Tarandach:No, no, no, no, wait, wait, use the whole thing.
Chris Romeo:Okay.
Izar Tarandach:Dumping on open source as a hive of scum and villainy. Wait,
Chris Romeo:As a hive of scum and villainy. I mean The only problem is that, like, it's the open source that's being attributed to the hive of scum and villainy. Cause I thought if we're saying security people are of a hive of scum and villainy, then I can pick like a Batman villain that I can be, and I can have a whole persona and
Izar Tarandach:wait, wait, has anybody checked the calendar if it's talk like a pirate day? Hahahahahahahah
Chris Romeo:recording this episode. So, um, but yeah, so the, but let's, let's talk about the issue. We don't, I mean, what, what was put into the LinkedIn message isn't really the, the important part here. The important part is how does security people perceive open source? That's where I want to start our discussion today. So Matt, you're nodding your head, which means I get to call on you first.
Matt Coles:Sure, why not? What else is new? Uh, so what does security people think of open source?
Chris Romeo:Yeah. What, how do we, how do we, what do we, what does security people think about it?
Matt Coles:As a security person, I think of open source as, uh, a part of doing business today. Many systems are built from it, and, uh, and a realization or rather a lost realization or missing realization that consumption of open source does not. Uh, remove any obligation for its use or inheritance, right? So, obviously when you, when you build something, I want to be careful, uh, when you build something with open source, you're inheriting what comes with it. So you get both the good and the bad. We've talked about this in other, other episodes about responsibility. You know, this is, this goes back to, um, Bob Lord and his, his statement around civic responsibility for when you find vulnerabilities, right? Same thing. Um, you know, when you, when you use an open source component, you inherit both the functionality that you want, as well as the issues that come along with it, whether they're security, functional, or otherwise. Um, if you're building open source and, and, you know, just for, for, you know, listeners benefit, right? Izar and I, of course, both are involved with, with an open source project. Um, and, and we've, we've worked with open source developers on other things and, um. I think there's sometimes a misunderstanding or lack of understanding around security.
Chris Romeo:Just in case you're listening on audio, Izar just changed his video feed to be like
Izar Tarandach:No, I didn't! Hahahahahahahahaha I didn't touch a thing! Sorry.
Chris Romeo:Oh, so Matt, please, please continue.
Matt Coles:Where was, where was I? That's how, that's how, that's gonna be hard to continue from. Um, so, so if you're building open source, I think, you know, sometimes security gets lost in the shuffle because, you know, A lot of open source, a lot of open source is written by one person or a couple of people, you know, and they're, they're sort of doing it on the side. It's not a professional job for a lot of, for most people. And so their primary goal is to get something out that works, that people might find of interest, right? Either they're trying to build a resume or they're, you know, they, they have something that they just want to share with the community. Uh, and sometimes, you know, that means corners are cut. I don't think I've, I don't think I have heard in my travels with other security professionals of referring to open source as being a, a pit of danger, right? I think that there, like I said, I, I think that there's an, an understanding, at least now, that there's an inheritance, concern of inheritance, and that There's stuff to be handled, uh, and the world is waking up to that, but I don't think I s I question that statement. Uh,
Chris Romeo:And, and since I was one of the people that was attributed to, um, it's sources is the backbone of everything, then every product that exists today, show me a product that doesn't consist primarily of open source. I would love to find one and I'm sure there are some out there, but I'd love examples of it because everything runs on top of open source. And so by no means, do I consider. Open source to be this, uh, pit of despair or, um, any other analogies
Izar Tarandach:Hive of scum and villainy.
Chris Romeo:Hive of scum and villainy. I don't, I don't consider it to be that at all. Like, it, it is for one thing, it's a reality. It is how software and products and applications are built today. There is no, could you imagine if someone, if somebody came in as a leader, a, a new CTO to a startup, there's a sigh in the play there, but a new CTO comes into a, a startup and says, okay. Uh, we're not going to use open source, so we need to rip all of our open source. Like, it wouldn't even be possible. Like, it would be impossible to do that.
Izar Tarandach:Look, look,
Matt Coles:No, it would be, it would be possible, it would be possible. It just would be very painful.
Chris Romeo:And expensive, because you'd have to
Izar Tarandach:Yeah.
Chris Romeo:all of that. Like, oh, we're going to write our own framework for our JavaScript front end apps, so that we can, like, I mean, it's, it's just not even a
Izar Tarandach:I'm sorry. You would have to start by writing your own compiler. You have to start by writing your own kernel,
Matt Coles:well, we lost Izar.
Izar Tarandach:You did?
Chris Romeo:Go ahead, keep going. Just say, repeat what you said.
Izar Tarandach:That, uh, can, can you hear me now? Can you hear me now? Yeah. So, uh, you would have to write your own compiler, your own kernel, your own, uh, everything,
Chris Romeo:Oh, I even see, I didn't even get there. You went, yeah, that's, you're right. Your own operating, yeah, kernel
Izar Tarandach:to, to, to paraphrase, uh, uh, Danny Rojas, open source is life. right?
Chris Romeo:That's
Izar Tarandach:And, uh, and, uh, you know, I can't even grasp the, the, the, the question itself. How, and I have heard that episode, how could it have been perceived that both of you were talking about open source in the view of security professionals as a hive of scum and villainy? I mean, the security industry would not be what it is today if it wasn't for open source. And I don't think I'm exaggerating.
Matt Coles:Well, okay. So I just, can we just roll back for just a sec? We didn't define open source. I think we've talked about it in the past. So just, uh, just a quick sidetrack, right? Open source versus free software, right? Versus commercial or closed packages. So,
Izar Tarandach:let someone in the room?
Matt Coles:Microsoft Windows, for example, is closed source, right, is a closed source component, and people have successfully built applications on top of, with, with Microsoft as an operating system, and Microsoft tools, which are closed source, right, for decades, right, before that it was Unix, which was not open source. And now, uh, you know, could you do that again? Yes. Yes, you could. Would it be cheap? No. Would it be hard? Yes. Would it be efficient? No. Uh, probably not. Um, so, and you'd have to basically reinvent the wheel for almost everything that the platform didn't provide. Open source versus free software, right? There may be closed source that is, that is still available. That is not, you know, commercial. Um, those exist as well, but most of them, I think by and large, we're talking about, we're talking about things for which the source code is available. And that people can either choose to use as is or modify freely. That's what we're talking about here. And, and you're right, you, you, the world runs on it, whether we like it or not, and we deal with it, and security relies on it. Most of our tools are open source, or at least based on open source. All of our technologies that we, you know, Kubernetes, or, uh, Spring, or Java, is, you know, is for the most part open source.
Chris Romeo:And
Matt Coles:Python, et cetera, right? So...
Chris Romeo:The fact that open source normally means you have access to the source code. It should mean that it makes AppSec easier. Unfortunately, that isn't how, that isn't how it's played out, and how the AppSec industry, and we could say the, the, those that are building software, it's, it isn't how it's been, it hasn't resulted in moving the security needle forward because it's, because you have access to the code. But technically, it should make things easier, because you could actually look at the code if you want to.
Matt Coles:You could, if you want to.
Izar Tarandach:Yeah, it's the eyeballs argument. But the thing is, I think that it can be argued that in those cases where it's necessary, where it's actually important, perhaps we don't get the direct number of eyeballs in there, but To go back to an example that we have used in past episodes, OpenSSL, they have this huge security apparatus, framework, scaffold, together with its open source effort, right, in parallel and working closely with. And that would not have been possible. If it was a closed source,
Matt Coles:Well, uh, we would not have been transparent. We would not have known. Microsoft, again, go back to that example. They have a, they have a whole security apparatus around closed source components.
Izar Tarandach:they do. And I am by no means saying that Microsoft is not doing enough or everybody has their problems and all that good stuff, but things in all best families. But, you know, I I, I, I still think that some processes in, in, in some places are lacking vis-a-vis the same processes in, in more public places. I think that what, how, what's the same, sun is the best, uh, cleaning agent. So, when things are exposed, you actually see everything for what it is and all the ugliness and all the beauty. So,
Chris Romeo:that's,
Matt Coles:Yeah, I think the biggest
Izar Tarandach:the number of bugs Yeah. No, no, go ahead.
Matt Coles:I was just gonna say, I think that it touches upon something I mentioned, you know, at the very beginning, right around when you use open source components, when you use any component, you inherit what comes with it. And the problem, the problem with it moving the needle or not moving the needle forward is there's a There's this notion that by selecting open source, I'm not going to inherit any problems, so the head in the sand problem, right? I'm not throwing this back at developers, because developers aren't necessarily in the best position to be able to know what they're getting, although Ideally, they do. Engineering 101 should be validate the components before you start to integrate them, right? This whole build versus buy decision, acquisition, and integration should follow some process that helps with making informed risk decisions. It's, it just starts with one, but now as you start to include dozens of components, hundreds of components potentially, and the tools that you use build, bring in other components, and those bring in other components, you get these transitive dependencies, the amount of complexity goes up, and the fact that there are, there's so much code that other people wrote that you can use, applications are tending to get more complex. And so it's sort of like, uh, there was an old episode of, of, uh, two and a half men. If you, if you, uh, if anybody used to watch that show back in the, back in the day, and one of the episodes that we're talking about, uh, um, it was, it was about financial, financial issues where they basically took a cup. And, and, and it was like, it was a cup of water, you know, and if you poke a hole in it, you know, the water comes out, and you pour water in, it will fill up, and it will sort of be equilibrium, and whatnot. But if you, if you don't, and you poke a whole bunch of holes in it, right, it's gonna drain out completely, and if you try to put stuff in the top, then, then it will just And you end up in the bottom and you won't have anything left to drink. Well, imagine that kind of analogy when it comes to complexity and issues of software, and you, you keep on adding components because you get You know, I want this piece, and I want this piece, and I want this piece, and I want this piece, and now you're, you're, the magnitude of the security problem increases exponentially on top of it. And so while you can have eyes on it, sorry, and I, my apologies for the, for the dissertation here.
Izar Tarandach:No, no, just
Matt Coles:This is supposed to be interactive, you know, the, the, the.
Izar Tarandach:Listening is interacting.
Matt Coles:The, the notion, the notion that, you know, While you can have eyes on the, on the thing, while you can have eyes on the code, if you're only inheriting, if you're inheriting it, and you get all the things come with it, but you're only using a portion of it, and then you add other things on top of that, and you continually add things on top of that, you suddenly lose sight, and now it becomes an iceberg.
Chris Romeo:mm hmm.
Matt Coles:Where you have the tip of the iceberg and everything below it,
Chris Romeo:Because of the depth of how many, how many pieces are there. So I want to, I want to challenge something that you said pretty early in that, in that explanation. And that is, I don't think people do build versus buy anymore. I don't think that's the modern
Izar Tarandach:Oh, no. No, no. Nobody.
Chris Romeo:It's more of like, is there, the question is, is there a component? That I can import that will provide the functionality that I need. I don't think there's really ever a question about should I build my own version of this component? That's my perception of the
Izar Tarandach:It's, it's I think that it's even, it's even worse. I've seen cases where what you need doesn't exist, so people are ready to move the design towards something that already exists, just so that they don't have to build that whole thing from scratch. So, close enough is good enough. But now I want to pull a Chris. I want to put a thought experiment on the table. as experienced security people. What would it look like if security people would look at open source as a hive of scum and villainy? How would that translate? Because we already agreed that we don't. would it look if it did? What would be the argument here?
Matt Coles:I have a feeling, are we talking about like pirates of the Caribbean? We're talking about Tortuga or
Izar Tarandach:is the picture in my mind. Yes, I will not deny that. In my mind I'm talking like a pirate, har har me mateys, for like half an hour.
Matt Coles:Pillage and burning, and all the, all that.
Izar Tarandach:Less of that, more of the Roman dancing.
Chris Romeo:I mean, I guess it would be, I guess it would be demonizing developers, right? Saying like, open source, but I'm just, I'm on, I'm in your thought experiment here.
Izar Tarandach:no, but think from a security point of view. Why? How would we do that?
Chris Romeo:how would we do it? I
Matt Coles:Wait. How? How or why?
Izar Tarandach:no, what would it look like? Okay, so ChatGPT, you are now a security expert that considers open source to be a Hive of Scum and Villainy. Describe to me what's in your mind.
Matt Coles:oh, oh, oh, yeah, so this is a, this is a whole lot easier discussion, let's assume for a moment that, that developers, developers of open source software are, are corrupt, that they don't consider security at all, and they intend to deceive. Here's my code, take it.
Izar Tarandach:But if that was the model, if that, that was the model, how long would something like that actually exist and expand? I mean, we are talking Oh, now I get it. I think that they may have been talking about the, you know, the, the bit in the podcast, in the podcast where you guys were discussing that you couldn't trust package managers. Could that be it?
Matt Coles:Are we talking about dependency injection now?
Izar Tarandach:I think that in a way that's where the things
Chris Romeo:okay, so,
Izar Tarandach:see a picture here.
Chris Romeo:okay, well,
Matt Coles:Please, please, please enlighten us because, uh, I'm lost.
Izar Tarandach:Well, Johnny Depp is in it. Okay. There's a bit of parrots all around.
Matt Coles:And maybe some Keith Richards too? Are
Izar Tarandach:Oh. Now
Matt Coles:you kidding me?
Chris Romeo:You're mute, you're muted.
Matt Coles:Izar, we can't hear you.
Chris Romeo:Can't hear you.
Matt Coles:Nothing.
Chris Romeo:Well, you'll have to wait till next week's episode to hear Izar's explanation for this entire
Matt Coles:Yeah, he was just about to explain it and he went
Chris Romeo:That's right, dun dun duuuun, cliffhanger. That's how we roll here.
Matt Coles:Reboot. Try to reboot. Kick it.
Izar Tarandach:What, what, why, why is
Matt Coles:There you are.
Izar Tarandach:Why is Cliff and why is he hanging?
Matt Coles:There you are. You're back.
Izar Tarandach:so yeah, so where did you guys lose me?
Matt Coles:Uh, right as you were about to explain everything
Chris Romeo:were about to explain this momentous
Matt Coles:You said, you, we said
Chris Romeo:out the whole thing.
Matt Coles:yeah, Johnny Depp is in it. Johnny Depp is in it. And then you said no to Keith Richards and then you went, you went silent.
Izar Tarandach:So Keith Richards is listening to us and probably sabotaged my, my setup here, but I remember they had the number 42 in it somewhere, but no, what I was thinking was, okay, so in, in the, the podcast in question here, I think that Chris and his guest, I'm sorry, I forget the name. I think that there was, there was some, uh, uh, thingy about, uh, Is it still recording? Because it tells me that it uploaded. Anyway, so um, they were talking about how you couldn't trust package managers, right? And then Matt threw in dependency injection. And I started thinking that, you know what, perhaps that's what triggered the uh, security people saying that developers are bad because Clearly, who would do something like this, right? But then Matt mentioned that if that was the case, then, uh, No, no, no, no, in your, like, in the thought experiment, you said that a bad developer could create a malicious package, and that's what triggered the whole thing for me. So my question when you guys couldn't hear me was, okay, let's say that that would happen. For how long would that package be out there without somebody figuring it out and killing or removing or whatever? So, it's not like that would expand to the whole community of open source. So, while yes, I
Matt Coles:collusion. It'd be massive collusion. And we know, we know that packages, malicious packages stay up for, you know, uh, on PyPy, for instance, they stay up for 30 days, you know, just, I, I don't, I'm pulling that number out of the air, just a few, few pack, you know, few discussions, uh, you know, news articles, they don't get discovered immediately and then they stay up for some period of time.
Izar Tarandach:So, for the whole Hive of Villainy thing to exist, there should be some cabal that controls open source and makes sure that everything that's bad is happening and nobody knows about it.
Matt Coles:That's right.
Chris Romeo:Like an Illuminati for the open source.
Izar Tarandach:Being there, being of
Matt Coles:GitHub, the dark GitHub.
Izar Tarandach:Right? A"GitHub-minati." Not to use something closer to me here. But been there, done that, and no, it's not how things work. So, yeah, don't. No, how?
Chris Romeo:And this is, um, here's, let me, let me throw another kind of idea at you guys and get your take on this. So I think one of the challenges that we have in addressing the software supply chain is we tend to lump every package on earth together into this problem. And I was doing a little bit of research yesterday for, for something, an article that I wrote in a reasonable AppSec, the newsletter, and I found that there's 1. 3 million packages in NPM. The node package manager. How many of those packages actually matter? It can't be 1. 3 million. Like, so part of our challenge here is we're addressing every piece of open source software in the same way on earth. And so what, one of the things I started in my own little thought experiment of how would I solve the software supply chain if I had all the power in the world? Why not have the package managers have some criteria? Or have a, a package manager that only serves up things that are, meet a certain criteria. But
Izar Tarandach:because dependencies.
Chris Romeo:trust me, yeah, I guess dependencies do start to break that down. But, and that, so that, that brings the question then, would it require, and I'm, this is, I'm throwing this to you guys. Would it require the way open source is built to rely, would we have to change the philosophy of open source to be less dependent on dependencies? And more focused, or is that, is that ship already sailed?
Izar Tarandach:It's recursion, right? You can't write something that things will be highly dependent off. And say You shouldn't be dependent of everything, or you should give such importance to the things that you depend on that the whole inheritance problem that Matt alludes to would go away. So, I don't know, I'm just spitting it out here. I think that, you know, if somebody wakes up in the morning and says, I'm going to write a package that does ABC and I'm going to make it available to the whole world, If we just start lumping process on top of it, that person will have less of an incentive to wake up in the morning and go write back a JVC. And we are going to end up losing.
Matt Coles:yeah, I, you know, I, I think, first off, I think we're conflating term the, where you misuse, not misusing, double, double using inheritance. I was talking about inheritance, meaning you own it, like you, you, it now becomes part of you into your scope. You're pulling it in, so it's now in your scope, as opposed to inheritance, like, like a, a hierarchy, um, which is where transitive dependencies come in, right?
Izar Tarandach:I know, but one implies the other.
Matt Coles:uh, no, because I'm using the word differently. Uh, in two different ways, right? So I'm using inheritance to mean it becomes within, within your scope versus one relies on the other, right? So when I,
Izar Tarandach:your scope, it's because you rely on it.
Chris Romeo:It's more of a responsibility
Matt Coles:yeah, respond,
Chris Romeo:Matt's describing, he's basically saying that if I take a package and include it in my application, I am accepting responsibility for the security of that package that I brought. And I'll give you an example of one of the, one of the brilliant people at Cisco years and years ago, um, when open source was first becoming a thing. Um, the saying that they, that the tagline is that they. distributed around and the whole company got behind is, um, it may not be your software, but it is your problem.
Matt Coles:Yeah. Yep. So,
Chris Romeo:that was to make that argument for people to say, if you're going to include a package, don't, you can't, no customer is ever going to listen to you say, well, that vulnerability, that was in the component that we use, that's not really us,
Izar Tarandach:go talk to Joe,
Chris Romeo:is. Yeah, this was a long
Matt Coles:you brought it in. Yep.
Chris Romeo:but that was, but that was part of the challenge. I'm going back. I mean, I'm, I'm dating myself here,
Izar Tarandach:Oh, totally agreed,
Chris Romeo:years ago, right? People were saying that. People were saying, well, it's not, the vulnerability is not in what we wrote. It's in the components. So it's the components problem. Just tell the customer that. And everybody was like, we were like, as security teams, like, no, we can't tell customers that it's not our, it's not our product.
Matt Coles:Right. So, so the, so the other part of inheritance that you've talked about, the hierarchy of this component relies on this component to function or, or to do, you know, to do whatever, um, that use of inheritance, I think, you know, that goes back to the dependency and the question that Chris raised. I want to throw out something that I want to mention something that has come and gone. And maybe it may be important for this discussion. Do you remember reputation as a concept? When it comes to open source, there was something that was being pushed a while, I know, I know, a while back, a couple of years ago, certainly, maybe, maybe five years ago, it started where there was a notion of reputation as a, as a property of components, and you had, you had a thing, you had a, it was sort of a collection of um, a correlation of, of, of, uh, attributes around things like, um, how recently was it last updated? Uh, how many stars does a, does the repo have? Um, and has it, does it have any defects that, that cause it to have a negative reputation?
Izar Tarandach:Isn't that the OpenSSF scorecard?
Matt Coles:it might be, is that what that is now? I don't know. It wasn't OpenSSF.
Chris Romeo:it's the same thing. I remember, Matt, what you're talking about. There
Izar Tarandach:how long ago are we talking about?
Matt Coles:I'm thinking, I'm thinking back in like 2014, 2015 timeframe.
Izar Tarandach:the scorecard is pretty new, but the things that you are listing, I think that they are directly there.
Matt Coles:Yeah, I mean, I recall this from way back when there used to be a sort of a it wasn't a system, but it was it was a
Chris Romeo:like an
Matt Coles:was yeah There was some sort of metric that would get generated and you could look it up and I forget there was a website
Chris Romeo:and I
Izar Tarandach:I was never big on reputation.
Chris Romeo:fell apart though, because for the, and the reason OpenSSF went the way they did with the scorecard, like the scorecard doesn't exist for every component, that's how I understand it, it's like the top components because they're like, hey, these are the things that have the most risk because they're used the most across the entire Uh, in, in all the industries that rely upon it versus, so it's, it's, but the reputation, I remember it kind of, it kind of didn't work because it was a lot of work and people just didn't do it and they didn't have any incentive to do it either. There was no, there was no reason why I, why I would do it as an open source
Matt Coles:And it was a it was a it was a trailing indicator because as as the reputation changed the reputation score would change But you would have to It would continually watch its progress and it would trail the actual behavior of the project. It also was really probably open to collusion, right? Because if the only people who had incentive for rating reputation were people who would rate it unnaturally high, then people who consumed it, consumed that reputation score, would then, um, would then get an Unrealistic value and choose a
Chris Romeo:a self metric though. There was no repository of reputation scores that had been independently compiled.
Matt Coles:no, I think that this,
Izar Tarandach:Oh my god,
Matt Coles:there were tools, there was tooling around it. There was tooling around this, like it was, uh, Black, not Black Duck, but one of the other, uh, uh, SCA tools at the time, um, reported reputation scores. Maybe it was from their own repository. I don't know, but, uh, so, um,
Izar Tarandach:you imagine the industry if that had taken off?
Matt Coles:yeah, but can you imagine if, can you imagine that would help, potentially help solve the problem of, uh, avoiding the case of components that are, uh, you know, whatever, like hive of villainy or whatever, you know, you would, you would quit, you would have an ability to have the community crowdsource, which components are better for their purpose. Not just by having eyes on the code, but also from their actual usage.
Izar Tarandach:Look, I don't know why it didn't work, but off the top of my head, I can only imagine the mess it would have been. With people saying, oh, I want to write this thing, and I wrote this thing, and I want to publish it, but I can't get the right reputation, so I don't get visibility. Okay, let's split, let's split everybody. These guys are going to get the reputation, these guys are not, and you publish whatever you want. And you see what I'm going to do?
Matt Coles:Yeah, oh yeah, it's totally open to who's in the circle and who's not, right?
Izar Tarandach:Yeah! Do we need more of that?
Matt Coles:as somebody who wasn't, who, as somebody who didn't have a lot of friends in high school, uh, you know, I know exactly how this
Izar Tarandach:was a square!
Matt Coles:At least you had a square, you had four points to work with.
Izar Tarandach:Well, where's the, where's from, uh, You are so far from the line you can't even see the line. Oh, that's Johnny, no, that's, uh, No, Tribbiani. Joey, yeah.
Matt Coles:Yeah, yeah, I would have been better off living in flat world.
Izar Tarandach:Which I haven't read this year yet. I have to go back there,
Chris Romeo:All right, well, what do we, how do we, how do we conclude this? How do we,
Matt Coles:Uh, myth busted.
Chris Romeo:what's our takeaway? That's
Matt Coles:Myth busted.
Chris Romeo:to end it.
Izar Tarandach:Mateys, there is no scum and villainy happening in here. Oh
Chris Romeo:uh, to wrap up this conversation. I'm sure this isn't the last time we'll discuss the software supply chain on the security table. So it will, the issue will come back up again. Probably within a month or two. So, uh, folks, thanks for listening to this episode. Hope you enjoyed it. Uh, please like, I was going to say like us on Facebook, but we don't have a Facebook presence
Izar Tarandach:my god,
Matt Coles:we do, if we do, the reputation is poor.
Chris Romeo:yeah, we're on, we're on the YouTubes. We're on
Izar Tarandach:or if we do it's not us.
Chris Romeo:It wasn't us. Yeah. We're on, we're on LinkedIn. We're on YouTube. Um, and wherever you find fine podcasts in audio form. Thanks for listening folks.