Open Source Puppies and Beer

Chris, Izar, and Matt address the complexities of open-source component usage, vulnerability patches, civic responsibility, and licensing issues in this Security Table roundtable. Sparked by a LinkedIn post from Bob Lord, Senior Technical Advisor at CISA, they discuss whether software companies have a civic duty to distribute fixes for vulnerabilities they discover in open-source components. They also examine if there is a need to threat model every third-party component and consider the implications of certain licenses for security patches. This is a discussion that needs to be had by anyone using open-source components in their code. Listen in and engage as we learn and think through this important issue together!

Links:

Bob Lord’s post about Open Source Responsibility:
https://www.linkedin.com/posts/lordbob_just-a-quick-thought-on-open-source-if-you-activity-7146137722095558657-z_RI

FOLLOW OUR SOCIAL MEDIA:

➜Twitter: @SecTablePodcast
➜LinkedIn: The Security Table Podcast
➜YouTube: The Security Table YouTube Channel

Thanks for Listening!

Transcript

Izar Tarandach 0:10

I can give you opera. I

Chris Romeo 0:12

is something that's required on the security table. What a way to start an episode! Welcome folks to the security table for our first episode of 2024. My name is Chris Romeo, joined as always by Izar Tarandach and Matt Coles. Um, I need to think of better nicknames for you guys, but it was a holiday season and You have one. Izar is your, that's not really a nickname though, that's kind of a, an actual name. Um, but I do have to think up some, I'll, I'll work on that with ChatGPT, uh, before the next episode. Uh, what we want to dive into is a LinkedIn post. So Bob Lord is a guy who works at CISA, his title is Senior Technical Advisor, and he wrote this interesting note about a week ago from when we were recording this, so right before the first of the year, right before New Year's, and here's what it says. I'll just read it to you verbatim to set you guys up here so you can then be prepared to react to it. And so here's what Bob writes, and I quote, Just a quick thought on open source. If you are a software company and you use open source components, you own the QA, quality assurance, and security ramifications for using that component. You didn't write it, but you still own the customer security outcomes. If you find a vulnerability and create a fix, it is your civic responsibility to ensure all users of that open source library enjoy the added security. Civic responsibility. That sounds big. That sounds big. All right, Matt, what I see you kind of, you're pondering, I can see some pondering in your eyes here. What's your, I mean, what's your first reaction to this, to this statement?

Matt Coles 1:54

Um, so there's a bit to unpack here. Let's, let's, let's take each part. I mean, Bob is asking for, Bob is suggesting, uh, I think more than just that last line. The last line is the important part, but the, but there's more to it. Right? Um, so if you use a, if you use an open source component, you own the QA, the quality assurance and security ramifications of using that component. That is true, right? If you build software and you use code, whether you're writing that code or you're inheriting that code. The collection of all that code and the thing that it creates is that company's responsibility. That makes, that makes sense, right? Um, if you find a vulnerability, I guess, and create a fix for it, the question is here, there's a part of when you create a vulnerability, oh, sorry, when you find a vulnerability, should you report it upstream? And we can talk about, about that reporting upstream into open source projects. Uh, but should you report it or should you try to fix it? And I think what Bob, and then the key part that Bob is calling out here is if you're using an open source component and you fix it for yourself, should you distribute it to the community? Should you push it back upstream so that all users of that component, uh, should, should be able to take use, make use of the fix that you created. that you're now going to be benefiting from as a software vendor. And this gets into enough

Chris Romeo 3:28

Bob calls that a civic responsibility.

Matt Coles 3:30

Civic Responsibility, yeah. So this becomes a question I think from a, at least from a, I think in corporate worlds, it becomes an IP creation slash sharing question, right? So there's some legal implications potentially. There's certainly more things. Whether it's a civic responsibility or not, I guess this goes down to, again, responsible disclosure practices and, and Um, and what the nature of open source components is, who's responsible for making fixes, uh, and distributing those fixes to users?

Chris Romeo 4:02

So Izar, I want to get your take first and then I want to back us up into that first, I want to dive deeper into the first section, um, the QA and security ramifications, but I want to get your initial take on this first.

Izar Tarandach 4:17

I wish I had a pope hat to wear here because it's so easy to pontificate, right? But, uh, first of all, a shout out to CISA, you said? He works at Bob Lord. And, uh, hey, I love your guys work. And we even wrote letters to you guys. But, uh, great job there, great

Matt Coles 4:35

No, no, not hate, not hate mail.

Izar Tarandach 4:37

no, no, definitely not. All constructive. But, uh, yeah. So, I would say that there's no way not to agree with the first part, that we're going to go back, which is the one where if you use it, then, hey, you own the QAN security. I don't think that's a given. But the second part, it goes away from the technical, it goes away from the, uh, even from the, what was it? The civic responsibility. That just screams The ethics of it, right? And the IP generation, of course, brings, as the comments did, brings us straight back to, hey, what license are you operating under? But, to me, the main point here is, the moment you put civic responsibility in there, the first question in this context that comes up to me is, You and what army? So,

Matt Coles 5:36

Who's you in this case? Who's you in your, in your

Izar Tarandach 5:39

person who's telling me that I have a civic responsibility. So, yeah, I fixed it. Why do you think that there's a civic contract here that means that I have to go and offer the fix to other people? Especially if you take into consideration the costs involved in terms of, uh, forward looking, and as an open source maintainer, I think that Matt is also going to agree with me, sometimes you get some really, really good Patches. Sometimes you get some patches that, uh, are less good, right?

Chris Romeo 6:14

You just have to say thank you. Thank you for, thank you for this input and then you like delete.

Izar Tarandach 6:20

indeed, and I could go on for hours on that. Frankly, my experience has been mostly positive by a huge march. I learn from every patch that PyTM gets. But, um, my point is that, uh, Okay, so you fixed it. So now you exercise your civic responsibility and you push that up. What do you do tomorrow when another user comes and says that your patch borked his edge case? You stop what you're doing now and you fix your patch? Because now you also own that patch.

Chris Romeo 6:55

Yeah, it's like a commitment, right? It's a commitment forward. It's more than a patch.

Izar Tarandach 7:01

There was a, there was a, uh, a comment here by,

Matt Coles 7:08

Well, so while you're looking up that, that

Izar Tarandach 7:09

by Michael Scovetta, sorry, Michael

Matt Coles 7:11

go ahead,

Izar Tarandach 7:11

Scovetta saying open source software provides tremendous value, but it's only free as in free puppies.

Chris Romeo 7:17

Yeah.

Izar Tarandach 7:18

So we left free beer now,

Chris Romeo 7:21

yeah, it's Wait, I thought it was the other thing. I thought it was It's, yeah, it's free as in puppies, not free as in beer. Yeah,

Izar Tarandach 7:29

No, free as in beer, not free as in speech.

Matt Coles 7:30

right, free, free, free from, free from cost versus free from, from, uh, responsibility.

Izar Tarandach 7:38

Yeah, but the free puppies here,

Chris Romeo 7:40

Yeah, hidden cost. Which is like the puppy, right?

Izar Tarandach 7:43

and this thing got me viscerally, because first, I love puppies, who doesn't? And if you don't, I don't love you. But, uh, but frankly, I mean, it's a puppy, you brought it in, you're taking care of it. And it's going to be with you, I hope, for a long, long, long time. It's going to give you joy, but you have to feed it and clean it and clean after it and take care of it, right? So that, to me, in some cases, may easily trump the civic responsibility,

Chris Romeo 8:13

Yeah, I

Izar Tarandach 8:14

which is a strong argument.

Chris Romeo 8:15

I want to come back to that. Let's, I want to unpack the first section of this because I know you guys are both like, yeah, yeah, yeah, this is good. This is fine. I don't know that this is as clean as we're making it sound like. And so,

Matt Coles 8:28

We will deal that.

Chris Romeo 8:29

We're company, I love that, what are you guys, the puppy patrol here? You're like, I made a noise, like I whistled. All right, so if you're a software company and use open source components, you own the QA and security ramifications for using that component. You own the QA, the quality assurance. So, In reality, that statement sounds like something that should be easy to agree with. But when we think about the reality of how people use open source, you own the QA. So that means I gotta write unit tests? gotta do regression testing?

Matt Coles 9:02

I would, I would be, I would be careful not putting reading too much into that. You own, you own the, you own the usage, you, you own the usage, right? It is up to you as the, as the software integrator. In this case, you're integrating code, right? Integrating somebody else's code.

Chris Romeo 9:18

Okay.

Matt Coles 9:19

You are, I mean, you should have a development life cycle that includes QA for the thing that you're building and any components that you include. should be covered, like, code coverage, right? Should, should include the code paths that, that come in from that open source component. In that respect, there's nothing, there's no differentiation, I guess. It's, it's part of the whole system, you test the whole system, and if there are side effects that come out of that, um, you're, you're, you should hopefully be in a position of discovering that. You shouldn't, if you embed a web server, you know, Tomcat or something like that, or Apache, and, and it has extra features that you keep enabled in your product. That's on you as the software vendor, right? You should, you should close those off...

Chris Romeo 10:11

I own, so wait, I own the vulnerabilities that exist in that software,

Izar Tarandach 10:14

No, wait, wait, wait, wait. We're talking QA now.

Chris Romeo 10:16

No, no, no, I'm trying to, I'm trying to walk you into a path. I'm, I'm, I'm leading you down a path that I'm going to, I'm going

Izar Tarandach 10:21

Look, it's simpler than that

Chris Romeo 10:22

to flip the table at the end. But.

Izar Tarandach 10:23

It's simpler than that, okay? When you're bringing in something that's open source, basically you are bringing in a promise. I promise you that this thing that somebody wrote, sorry, they promise you that that thing that they wrote does A, B, C, D, and E. It's your responsibility to make sure, by using QA, that it does what you need, no more, no less. And that includes the security clause. It's your responsibility to make sure that you're not bringing risk by incorporating that component.

Matt Coles 10:53

inherit, you inherit what comes along with the component And by, and by the way, the promise, this is where licensing, I think, actually is critically important. If you pull a component and it has the MIT license or the two clause or three clause BSD license, you know, where it's basically use it as is. And you're free, you know, you're free to use it as, as it comes, and there's no warranty implied. That promise is, as a, as a component developer, we believe it works. But it's on you to figure it out, does it work for you? As opposed to another license that may say, we get, we, we validate, we warranty its, its function, or fit for purpose, or whatever you, your language you want to use, that, you know, if it's a problem, come back to us and we'll fix it for you. That's a different promise. In

Izar Tarandach 11:37

sorry, Matt nails it when he says that. When you inherit the thing, people forget that inheritances have taxes on them too.

Chris Romeo 11:46

Hmm.

Izar Tarandach 11:47

So you're

Matt Coles 11:47

states.

Izar Tarandach 11:48

yeah, you're not only bringing that thing and running around free and carefree saying, Hey, I just found the, the, the, the component that does everything that I wanted. No, you have that tax you have to take to pay care. To what Matt is saying, you have to pay care to downstream. What does that do you have to pay to, to pay attention to How long is the thing going to be around? Right? So there's a tax to be paid when you

Chris Romeo 12:11

let me, let me ask another. Revealing question. So it'll be a leading question too. Cause watch the first one, this will be the lead and then we'll come back around. So do you use, does either of you use open source components in anything that you do?

Izar Tarandach 12:27

In the last five minutes,

Matt Coles 12:30

Yeah, I use open source applications or components, yes.

Chris Romeo 12:33

In things that you've built, in things that you've built the last month, do you use open source components?

Izar Tarandach 12:38

constantly.

Matt Coles 12:39

Yes.

Chris Romeo 12:39

Okay. So do you have, have you created threat models for each of those components?

Izar Tarandach 12:43

In my mind. Yeah. My mind is a very threat model place.

Chris Romeo 12:48

But that would be, so that would be the security, that would be security ramifications for using that component would technically be, so we should technically have a threat model for every third party component

Matt Coles 12:58

whoa!

Chris Romeo 12:59

Inside. of

Izar Tarandach 12:59

No, no, no, no, no.

Matt Coles 13:00

Timeout, timeout.

Chris Romeo 13:03

Security ramifications for using that component! I'm reading it off the page!

Izar Tarandach 13:07

No, no!

Matt Coles 13:09

That's not. So we, so as a person who uses a third party component, an open source, let's open source, right? Or generically any third party, anything that comes from a third party, whether it's a desktop application or a software library or fragments of code. You certainly should be threat modeling it for your usage. That does not mean you're threat modeling its entirety. Right? And it doesn't necessarily mean it's a formal threat model. So for instance, if I use, um, let's say I use an open source password manager. know it has certain security properties and I'm going to put that into my personal threat model. Now I don't have that written down anywhere, but I have an understanding of how that impacts me. What its security posture is and how it impacts me. Similar process may happen for, for a, for a software application, but I'm not writing commercial software applications. If I was a commercial developer, or if I was doing this for PyTM, for instance, for as an open, as another open source tool that was, that was inheriting open source components, then it should go into the, it should be factored into the threat model for PyTM or for the commercial application. So,

Chris Romeo 14:24

let's do a little thought experiment. Go ahead, go ahead, make your point

Izar Tarandach 14:27

No, no, no, You you, you go No, no, you go.

Chris Romeo 14:29

So the, the, the way he wrote this, if you're a software company, so let's just pretend we're not threat modeling superstars, right? Cause we have, we kind of have an unfair advantage cause we've studied this thing. You guys have written the book that what I think of is currently the book on the topic, right? So software developers are not in, like a software developer at a software company does not have the superpower of threat modeling. Maybe they do, but they don't have the knowledge and experience that

Izar Tarandach 14:55

We want them to

Chris Romeo 14:56

We want them to have, yes. But, so, I guess, does, how does that change the conversation, though, about how they use a component and consider the security ramifications of that component?

Izar Tarandach 15:09

That's a wonderful question, a wonderful thought experiment. And I'm happy that I shut up and let you introduce it before, because now I can go exactly to where I was going before. Let's imagine the, the, let's respond to your experiment with the, the quintessential open source component that everybody uses, crypto. Aside, if you are doing your own crypto, you shouldn't, unless you are a cryptographer. So, a developer looks at the crypto component that they decided to use, okay? Their threat model assumes from the beginning that whatever algorithm is in there, the implementation is good. Implementation is well done. He doesn't have, and I wouldn't have, the, the mathematical acumen to look into the code and decide from that, that this is a sound implementation of a crypto algorithm or not. But in their threat model, they are going to say, okay, what happens with the keys? Where do I store them? What's the size of the key? What's this? What's the cipher? What's the mode of the cipher? And so on and so forth. But then comes the one question. that every developer should be able to put in their minds, even if they don't know all this stuff, what happens if that black box that I am unable to understand and to measure and check the goodness of it, what happens if that black box is broken? So they should be able to design their systems. With what even has a formal name, Crypto Agility, where you should be able to just snap it out, put another one in, and get exactly the same things and move on.

Chris Romeo 16:59

We're talking about trust. You're talking about,

Izar Tarandach 17:01

Not, not,

Chris Romeo 17:02

an element of trust that the developer has for a crypto library that, because they don't have the ability to test it themselves and analyze it, which I don't either, I couldn't analyze a crypto

Izar Tarandach 17:12

library. Not, not quite, not quite. I'm thinking in terms of, what if you had a car, you have absolutely no mechanical ability whatsoever, and one bright day you're driving, and you start hearing clunk, clunk, clunk, clunk, clunk, clunk, clunk, clunk, you don't know what it is. You drive into a mechanic, they open the thing, take out the engine, put another engine, and you happily go on your way. Might not be the cheapest solution, but it is the one that's going to solve whatever that clunk, clunk, clunk, clunk, clunk was, and not going to give you problems down the road. So the open source responsibility of developer here is to assume that things could go south and be ready to snap the thing out and put something else in.

Chris Romeo 17:58

But there's a trust, there's a trust element to this, in

Izar Tarandach 18:01

But that trust is assumed, because nobody is, the licenses, the licenses and the authors, they're not promising you, trust me, they're promising you, hey, I think that for the things that I tested, for the itch that I decided to scratch, this piece of code solves it. But that's it.

Matt Coles 18:21

By the way, it's in the, it's in the bringing that component in that, that those assumptions, we talk about this all the time about threat modeling is you make certain assumptions. Hopefully you write them down. Hopefully you validate them and hopefully you're prepared if they become invalidated. But you make certain assumptions based on the nature of the component, right? If the component comes from somebody in a questionable location, you know, a single developer, okay, if you, if you try to use a crypto algorithm that's implemented by a single developer in a, uh, in a questionable country, perhaps, or uh, or who ha, who, you know, there, there may be some other, other, uh, issues there. You may make certain assumptions about the fitness of those algorithms and have mitigations in place or have at least considerations in place for what to do about if something, if things go south. Right? So there's a, there's a risk, presumably, there's a risk discussion that should happen. There's assumptions that are decided during the threat modeling exercise if you're doing threat modeling, or they're implied. I bought the, I got this component. I'm gonna use it. I hope nothing bad happens. I'm making a lot of implied assumptions there, right?

Izar Tarandach 19:33

Now, on the side of those assumptions and on the side of trust, since we already went that way, uh, there is the, I think it's the OSF scorecards project that does try to give a measure of, uh, uh, perhaps trust is the wrong idea, the wrong word, but

Chris Romeo 19:51

more assurance. It's not trust, it's assurance. Because they're

Izar Tarandach 19:54

Right, but I think that the same way that severity got changed for risk, I think that in this specific case, assurance becomes trust.

Matt Coles 20:06

Assurance enables trust, right?

Izar Tarandach 20:09

Yes. Yes. That's what I

Chris Romeo 20:11

I grew up learning about assurance in the late nineties and looking at evaluating products using government standards and stuff. So for me, assurance is evidence and proof that allows me to get a more warm and fuzzy that security and privacy have been handled correctly. It's not fail. It's not foolproof. It's,

Matt Coles 20:30

it's not foolproof, assurance drives and enables trust, and the more assurance you have, the better trust you can have,

Izar Tarandach 20:38

Yeah. Yeah. Yeah.

Chris Romeo 20:39

Better you can sleep at night with the fact that you're saying, yeah, I trust this thing. Why do you trust it? Well, because I've seen their threat model. I've seen their SDL that they apply to it. I've seen their test cases, and I think they're doing everything they possibly could do. Okay, now that's assurance, and that breeds trust, and then I can now say, okay, they're doing everything they can to make this component at the highest quality and the most secure and considering privacy as possible.

Matt Coles 21:08

Izar, you have a smile on your face. What's your

Izar Tarandach 21:10

No, I'm thinking, I'm thinking here to myself. We, we, we are treating trust as a transitive value when we don't really have a trusted route of trust. I mean, for example, the scorecard, we are just trusting the OSF and what they decided to measure in the scorecard,

Matt Coles 21:39

It's turtles all the way down if you go there, Izar.

Izar Tarandach 21:41

it is, it is, but I'm looking for the biggest, I'm looking for the biggest turtle, the one on top of the elephants.

Matt Coles 21:47

I guess, so what you're bringing up is actually an interesting point, and we're straying off topic here from Bob's original blurb, but I think it's an important topic that you're bringing up. How do you trust, how do you gain trust from assurance if the process of assurance is not trustworthy?

Izar Tarandach 22:07

So let me bring Bob into the conversation. How do you have that trust knowing that just anybody can submit a security patch? And, and, and I say security patch, differing from a patch, because that security patch probably has a bigger risk associated with it than any other patch. Because it's treating something that is a security condition, a security check, security case.

Matt Coles 22:38

So I If

Chris Romeo 22:38

you're going to go there though, just real quick, you, you have to separate the open source universe into projects that Matt created on this weekend and uploaded to some source repository somewhere and people are downloading versus open SSL. None of the three of us could get a security patch through OpenSSL's process at this point. Because we're not trusted members of the team, we're not,

Izar Tarandach 23:03

oh,

Matt Coles 23:04

oh, no, no, no, no, no, no, no, we need to, that's a Important area, but I think, I think we're on the, we're working up the wrong tree there, right? We We should not, we do not have the ability to direct commit to mainline on OpenSSL, 100%. But we could probably get a patch into OpenSSL. We could either do it by tricking a maintainer. Or having a good patch that maintainer reviews because they have a reputable process for reviewing commits, right? Or patches, right? And so, yeah, go ahead Izar. I was going to say, so there's a precondition here. Somebody finds a vulnerability, and for the moment let's assume it's a legitimate vulnerability, finds a vulnerability and decides to create a fix. Versus finds a vulnerability and reports it. and waits for a fix to get created. So first off, somebody finds a vulnerability and reports it, or decides to try and fix it themselves and then push the patch upstream. Right? And now it comes down to the project, um, to how their, what their practices are for, how those patches make it to their mainline, to make it to commits to out to the, to their release, uh, through the release train. You know, if you look at OpenSL, you look at FreeBSD, uh, I'll, I'll highlight because they have really good documentation on their website. Um, they have dedicated maintainers who have been validated and vetted. They have and they have tooling and, and, and a system and a pipeline in place that has all the right checks and balances and, you know, automated QA runs and, and regression testing and the whole works. And that establishes trust.'cause you have assurance in the process that allows you to establish trust that what patch gets pushed

Chris Romeo 24:47

not at the front door,

Matt Coles 24:49

throughout the, throughout the pipeline, throughout the

Chris Romeo 24:51

where you're trying to get your, your PR, you're submitting your PR as a, as a, let's call it a nothing burger in

Matt Coles 24:58

Yeah, as an untrusted, as an untrusted individual, but somebody's going to go review

Chris Romeo 25:02

But they, but my point is in a project like Open SSL as as, which has been funded now, I mean, I remember the days when there was two guys that worked on open SSL in their free time and everybody built their products on top of it. So

Izar Tarandach 25:14

So that means that at some point OpenSSL was a weekend project.

Chris Romeo 25:19

It is, but now it's, but now it's become, it's got investment, it's got full-time employees. My whole point

Izar Tarandach 25:25

because it was foundational.

Chris Romeo 25:27

Yes. And, but my whole point here is Matt, if you try to submit a PR to fix a vulnerability. They're going to scrutinize the crap out of it because you

Matt Coles 25:34

And they should.

Chris Romeo 25:35

haven't, but you're, you're not a known quantity. My point is that you will, I don't think you can get a, I don't think you can sneak a, a PR past them easily.

Matt Coles 25:47

Good.

Izar Tarandach 25:48

so here's the thing. Why? Because, as Matt said, they have these huge, tested, well known, respected operators exactly for that threat model, exactly for what if somebody tries to sneak a patch in here. And that's what makes it different from PyTM that's developed on the weekends. That's the only thing that makes it different, by the way. But, uh, the, the, the point here is that If we are honest about it, the processes in place to put in a patch, especially a security patch in OpenSSL, FreeBSD, Linux, things that we work with every day and that are foundational, right? They are much, much better than many companies I have seen. In a company you could get that patch in, and many times I have seen places that don't have that in their internal trust model. They could end up with, like, code that, who wrote? I don't know who wrote it, it just showed up one day, right? But as you said, on OpenSSL, that would be much harder. But then comes the question, and here we have to go to the source of all wisdom, which is XKCD, and remember that the drawing that it had of like the blocks, and right here at the end, somebody in Nebraska tirelessly working on that little model that everybody relies on, right?

Chris Romeo 27:14

Yep.

Izar Tarandach 27:16

So let's go back to Bob, the civic responsibility. Where does that civic responsibility emanate from? Does it

Chris Romeo 27:23

is, what is civic responsibility? Cause like when I think of that, I remember the only time I've ever heard it is two times in my life, civic, my civic responsibility was to vote and it was to sign up for the, what do they call the draft here in the US?

Izar Tarandach 27:37

The reserve service,

Chris Romeo 27:39

selective service, which I don't even know if they do that anymore. I'm, I'm so old.

Matt Coles 27:42

I that, I think that they do.

Chris Romeo 27:43

That, those are the

Matt Coles 27:44

we're old enough, we don't,

Izar Tarandach 27:45

until 55, but you see, you touch exactly in the two points that basically define civic responsibility, right? You are participating in the social contract that makes this community that you live in a community. So you are committed to participating in how it is, uh, how it is led. and how it defends itself. Without those two things, you probably don't have a community, you have something approaching an anarchy or something like that.

Chris Romeo 28:11

Mm hmm.

Izar Tarandach 28:12

So the civic responsibility of somebody participating in, if we translate that to the somebody participating in the open source ecosystem. Let's forget for a second about the voting, because I suppose that you could say that by bringing in a component, it's a form of voting. You are saying I'm participating in this thing that's called OpenSSL.

Chris Romeo 28:37

Mm hmm.

Izar Tarandach 28:40

But then comes the second part, the helping defending it. By adding a security patch into something that you decided to adopt for use, not for development, for use, do you have a social responsibility to defend everybody else that made the same decision?

Matt Coles 28:59

So can, can I answer that with a question?

Izar Tarandach 29:02

Please do.

Matt Coles 29:04

Um, and I, I, I'd like, I'd like to look at examples sometimes as, as models for answering other people's questions, because sometimes it's good to make those correlations. So let me ask you. You, you started, you, you were saying, should you, if you make a patch. for a vulnerability should you distribute it back to the community. Make a lot, help the community defend against the thing that you found and fixed. And I would ask, just bring that up just a little bit. Which side do you, which side do you fall on when it comes to, do you find a vulnerability? Do you sit on it as a zero day or do you report it to report it responsibly upstream? So ignore whether moment you're going to fix it because you may not have the technical capability to fix it.

Chris Romeo 29:51

I guess

Matt Coles 29:52

But should you report it?

Chris Romeo 29:53

I was assuming we were talking on the side of good in

Matt Coles 29:58

I would hope so.

Izar Tarandach 29:59

Okay, so let's keep on the side of good. Bug bounty. You just found a problem on a third party component as a participant in a bug bounty of a product. it's not a bug bounty of that component.

Chris Romeo 30:09

You're getting paid, like you can, you, you're gonna get you're gonna get re you're gonna register the vulnerability before, and then maybe you have, you should go make a fix after it or whatever. But

Izar Tarandach 30:17

but now if they have the civic responsibility of pushing a patch for that, you just killed the N other bug bounties that you could run to and get paid for the same vulnerability.

Chris Romeo 30:25

yeah, I mean, that's a whole other We, we can have a whole episode on bug

Izar Tarandach 30:30

so no, but no, no, no, no, no, no, no, it's the same question, because think, because think, if those guys have a responsibility to patch and solve and distribute, then you, by pointing out the thing that gives you, that gets you money is basically killing the golden goose. So you have to, you have to report to everybody at the same time. And now you have a race to the top to who creates a patch and gets it in. So now you are DOSing the open source component because they are going to get 20, 30, 100 patches

Chris Romeo 31:03

if, hold on, hold on. I want, I want to take what you just said, and I want to, I want to throw a curve ball here. What if people had bug bounties for open source fixes? Not for breaking, but for building. What if you had a world where you could go and you could get paid$2,500 to fix a critical vulnerability in OpenSSL? And you were somehow vetted, like the bug bounty platforms have that vetting where you can say, I want only people that are kind of vetted and real people and we know they're not criminals or whatever that are involved. Like, why don't we

Izar Tarandach 31:35

Isn't there something like that? Aren't there some projects that do get funding to, for other people to patch them?

Matt Coles 31:43

Yeah, there used to be. I don't know if they still exist, but I

Izar Tarandach 31:45

I don't know.

Matt Coles 31:46

one or two. I remember a few years ago.

Izar Tarandach 31:50

I would love to see it, as Chris seems to be implying, at a grander scale. Somebody with the resources to help those developers absorb those patches, and test them, and do all the good stuff that OpenSSL does. As an infrastructure, I would love to see that.

Chris Romeo 32:08

mean, this is back to the breaker versus builder challenge that I've been yelling at about for years and years now. Like, our focus as an industry is all on breaking stuff, and Bug Bounty just proliferates that. It's about how do I break it? Now imagine if you had to submit a vulnerability and a fix as part of the bug bounty. So you can't just break it, you actually have to fix it as well, so that the company could

Izar Tarandach 32:33

Oh,

Chris Romeo 32:33

then and apply that, right? Like, at from an open source component, but,

Matt Coles 32:36

Yeah. I mean, that's, that, that's a, that, I think that would be an insurmountable challenge for a lot of people, but it, you know, it may improve the quality of findings, right? Um, because you'd have to really understand the code or really understand the architecture to be able to support something like that. But I think that could get pretty, you know, pretty challenging. Is it sufficient to drop a threat model? Like, here's how I'd fit, or here's a new design. Here's how I would fix it from a design standpoint if it's a design flaw, versus actually writing code and putting a PR in place, right? So there's probably some challenges there, but I want to call out one thing really important. Sorry Izar, I know you have

Izar Tarandach 33:09

No, no, no, no, go for it.

Matt Coles 33:10

uh, but what Bob is then also calling out as civic responsibility is You make it for, you make it for altruism, is it altruism the word I want to use? It's where you, it's where you, you contribute back to the community at large, because it's the right thing to do, not because you get something from it. You get

Izar Tarandach 33:33

And you just got a puppy.

Matt Coles 33:34

well you get benefit from it, but you

Izar Tarandach 33:35

No, you got a puppy. You just got a puppy.

Chris Romeo 33:38

Well, you get the benefit because you made the fix. Like, you're improving your own security because you use the component,

Matt Coles 33:45

But you're, but you're also distributing it to others, so, but without expecting anything in return from them. I

Chris Romeo 33:51

We can't go any further until we address the licensing issue, right? Because

Izar Tarandach 33:54

No, no, wait, wait, wait, wait, wait, before we go further than that

Chris Romeo 33:57

they can't do this.

Izar Tarandach 33:59

before we go further than that, the, the builder versus breaker, two things. First, do you really think that we have that amount of people who are both able to find and fix stuff? And second, can we have a whole episode on that, please?

Chris Romeo 34:13

Yeah. Let's do, I, I, yeah, I don't need, I'm going to, I'm going to save an answer to that into a future episode, because I think that's, that's somewhere we can dive

Izar Tarandach 34:21

Okay. License.

Chris Romeo 34:22

got to deal with licenses here because one of the challenges here, this all sounds great. If you create a vulnerability and create a fix, it is your civic responsibility to ensure all users of that open source library enjoy the added security. But what about the license? And Matt, you've already touched on some of the license challenges that exist here. There are licenses that don't even allow me to Like, aren't there licenses that open up Pandora's box if I do submit a security patch? Aren't I then I don't know. I mean, it seems like, it seems like there's a licensing challenge here where some licenses are just not going to be friendly for my company to be able to make a, fix a security issue. Okay. That

Matt Coles 35:04

is a really important statement. There are some licenses that if you make a, if you make a fix, if you make a change, you need to distribute it back upstream, right? GPL, I think is the big one here, right? If, if you make a fix, you have to distribute the fix. You have to distribute the code change. Right? By the license. If you, if you're under BSD and you make a code change, I don't care, right? BSD doesn't care. Or, or, uh, MIT license doesn't, I think, doesn't care, right? That, that, that you make a code change. Use it as is and free to modify in any way, shape, or form. Uh, so, there are some licenses that require you to push upstream, and there are some that require, that, that don't care if you push upstream. And then there's some that, and then there's some that are, uh, I, it's copy left and there's some other license types, I think, in there. I'm not, not an expert in licenses and stuff, but, you know, we should find a lawyer who is, um, that, uh, that is, um, you know, that, that actually exposes more of your IP than just the change that you make. And that's, yeah.

Chris Romeo 36:10

the one I was concerned about was the, the exposure. Izar, go.

Izar Tarandach 36:15

Two things. Well, I'm very two today. Push up stream or make it available. That's one.

Matt Coles 36:23

Fair enough. Yes. Yeah. Yep.

Izar Tarandach 36:24

and second, because those are different.

Matt Coles 36:27

They are different, yeah, sorry, I used the wrong, wrong term there. What,

Izar Tarandach 36:34

are you guys seeing this? Look at this! Ha ha ha ha! I just went like this with my finger, what, what, what the

Chris Romeo 36:43

using a Mac? It's a Mac feature. It's a Mac feature. I'll tell you how to turn it off later after we finish.

Izar Tarandach 36:48

I HATE MACS!

Chris Romeo 36:49

I love it. There's,

Izar Tarandach 36:54

I went like this with my finger.

Chris Romeo 36:55

there's various, there's various things with the, with the, one of the new releases of MacOS where you, gestures get translated into

Izar Tarandach 37:03

I'll give it a gesture soon.

Chris Romeo 37:06

Let the record show that Izar is now doing a gesture that is not resulting in any type of, uh, balloons flying around

Izar Tarandach 37:14

Balloons, yeah. Anything coming out of this? Anything? Anything? No? Okay.

Chris Romeo 37:20

feel

Matt Coles 37:20

Do, Do,

Chris Romeo 37:21

yeah, I feel like you had a point

Matt Coles 37:22

and see.

Chris Romeo 37:22

that. There was a point there somewhere. You said two things. First one was the, the upstream versus

Matt Coles 37:30

versus

Izar Tarandach 37:31

make it available.

Matt Coles 37:32

right?

Chris Romeo 37:33

what was the second one?

Izar Tarandach 37:35

I forget. I got ballooned out of it.

Chris Romeo 37:40

Uh, that's all right.

Izar Tarandach 37:41

This is ridiculous.

Chris Romeo 37:43

all right. We'll, uh, it'll, it'll come back to you. Once we start talking about something else. So, but I think, I think it sounds like we're all agreeing though. The licenses. Could be a challenge,

Matt Coles 37:53

Could

Chris Romeo 37:54

for, with this

Izar Tarandach 37:54

No, no, no, no, Now I remember, now I remember. The IP thing. Yeah, yeah, the IP. If you are putting IP into patches that you would send upstream or make available, something is very wrong.

Matt Coles 38:08

sorry. Your, when you create, when you create a patch, that is your IP, that is IP, that, that is intellectual property. You have, you have taken your brainpower and written it into code.

Izar Tarandach 38:17

Yes, because it's a line that one of your developers wrote. But is it IP?

Matt Coles 38:24

it trade? as IP? is it trade secret versus not? Yeah,

Izar Tarandach 38:30

matters? Yeah, right?

Chris Romeo 38:31

So there's secret versus not, but there's also valuable versus not.

Izar Tarandach 38:35

yes, things that matter and

Chris Romeo 38:37

IP.

Izar Tarandach 38:38

what I'm saying is, anything that you would write into a patch that you send upstream, by its own nature, should be something that you could print out and put it on an outdoor in the middle of the street,

Chris Romeo 38:52

I guess, is it a competitive advantage to have a patch to a vulnerability that you create yourself?

Matt Coles 38:56

I would

Izar Tarandach 38:57

only if you're in the business of exploiting other people.

Chris Romeo 38:59

Which, almost said

Matt Coles 39:01

Well, or if you want a pro or if you product, want a product at work, let's say for a moment that that pa, that that patch is to close a hole that causes a permanent denial of service and your product will work and everyone else's won't. Right? I mean, that's a competitive advantage,

Chris Romeo 39:15

Which would not comply with Bob's statement here, though. Like, you would not be being a good member of the community

Izar Tarandach 39:24

are not exercising your civic responsibility.

Matt Coles 39:27

right?

Chris Romeo 39:27

Yeah, I mean, I don't know. I think that's a good place to leave this one for today. I think, uh, I think, well, I want to, I want to reiterate something Izar said at the beginning. Um, we love CISA. We love what they're doing. So this is not a, we're not, we're not attacking this statement. We're just trying to unpack it and understand it and, and think about it and, and ultimately help more people to, to, to hear what Bob put into this post, because we thought it was really powerful statements. And, um, we thought there was a lot to unpack there. As you saw, it took us 40 minutes to unpack it. So, um, once again, thanks Bob for putting that statement out there. Thanks for all the things you're doing at CISA. We're, we're definitely big fans of secure by design, secure by default, and all the work that's going on there. So, uh, thanks folks for tuning into another episode of the security table and stay tuned for whatever the heck we decide to talk about next. Ha ha ha

Izar Tarandach 40:19

for Izar and more Mac wonderment.

Chris Romeo 40:23

ha!