OpenSSF

• 01:08 – Rodrigo shares his entry into open source
• 02:42 – Diving into the specifics of a high-profile incident
• 06:22 – How security researchers coordinate a response to a high-profile incident
• 10:33 – The benefits of a vulnerability disclosure program
• 11:57 – Rodgiro answers CRob’s rapid-fire questions
• 13:43 – Advice for anyone getting into the industry
• 14:26 – Rodrigo’s call to action for listeners
• 15:53 – The importance of the security community working together

• Rodrigo Freire on LinkedIn
• Rodrigo’s blog on Red Hat’s response to the XZ incident discovery
• Get involved with the OpenSSF community

Rodgrigo Freire soundbite (00:01)
Who do I ask and to grab by the arm? Man, I need you to, right now, please assess this vulnerability! It’s very important asset to have that Rolodex of contacts and to know the ones to ask for help. You don’t have to the information — have to know who knows.

CRob (00:18)
Hello everybody. Welcome to What’s in the SOSS? The OpenSSF’s podcast where I and Omkhar get to talk to some amazing people in the open source community. Today, I’ve got a really amazing treat for you. Very special guest. My friend Rodrigo from Red Hat. I’ve known Rodrigo for awhile, and we’re here to talk to about a really important topic, kind of, both of us have worked a lot with.

Rodrigo Freire (00:44)
Thanks Chris. Hello. Yes, I had the pleasure to work with CRob for a good number of years and I was in charge of the vulnerability management team at Red Hat. Yes, it was five definitely fun and character-molding years.

CRob (01:01)
So maybe you could share with our audience a little bit about your open source origin story. How did you get into this amazing space?

Rodrigo Freire (01:08)
It’s funny. When you say that I worked with a Linux version 1 dot something, well that pretty much disclosed the age, right? It was back in the 90s. I was working on an internet service provider and there was that multi-port serial adapters for moldings, and that was pretty much the backbone of the ISP. And then sendmail, ISC buying DNS server. And back in the day there was not radios for authentication — it was Cisco stack hacks, so yeah. (Laughter)

I started on the classic ISP admin back in the 90s. That’s when I got involved and then worked in the Brazilian government promoting the open source, and it was interesting time. When the government was shifting from mainframes and going to the to the low platform. And then the Linux as a security thing, and then the Linux was more focused on performance and the security. So this is where I started to wetting my toes in open source software.

CRob (02:22)
So let’s dive into the meat of our conversation today, my friend. We’ve all seen them, and maybe you could share with the audience from your perspective — what is a high profile incident? You know, sometimes it’s called celebrity vulnerability or a branded flaw. Could you maybe share like what is that?

Rodrigo Freire (10:33)
Yeah, definitely. I don’t know how does that translate to English actually. So I live all the way down here in Brazil, but I like to perceive them as like creating commotion. So that’s going to attract media audience and Twitter clicks and engagement and, h my God, look what I found! And in the end, that might be somewhat another Brazilian saying for you guys: trimming the pig.
A lot of cries for very few actual hair.

So you create all that commotion, all that need and so that comes escalating from CEOs, whatsoever, security teams for something that in the end might be some moderate impact or sometimes even something that does not affect some customer systems. So it’s a lot of brouhaha, I would say. However, on the other hand, there are some security events that are definitely something that you should pay close attention to.

So for example, we had the Heartbleed and then there was Shellshock and ghosts. I’ve been over the course of the years, a number of GLIBC vulnerabilities that can elevate you to root, even to the extent that it was even used as a tool to get a root on the system that someone forgot the password. Yes, that happened once, to a customer that shall be renamed unnamed.

And then finally, I think the mother of all incidents that I worked with, it would be the XZ security incident that happened a couple of months ago. More often than not this is something that just created distress with the security people with the good people managing the data center without something that’s really putting the customer at risk. However, on the other hand sometimes, some less often there, will be definitely something that’s really of concern and because the customer should pay close attention for that.

CRob (04:52)
So what do you think the motivation is that last year there were like 25,000 vulnerabilities? What’s your perception of why some of these get a celebrity treatment and others don’t that may be more severe?

Rodrigo Freire (05:08)
I have read somewhere on the internet, over the internet, something more like in the lines that over promoting something for personal gain. That resonated very well with me. On the community industry, there’s a lot of effort that’s put for you to render your portfolio, your reputation across the industry. And so, someone shows on the resume, hey, I was a guy who found the Heartbleed or the Ghost vulnerability.

A lot of people are going to recognize you, oh my God, you found that vulnerability, So yeah, it might be something like that. Sometimes it might not be that intent, but in the end, Chris, I really don’t think that’s not something that’s changed the tide on the security landscape for a good impact, I would say.

CRob (06:00)
Yeah, I would agree. Thinking about you managing some of these high-profile incidents, for our audience, maybe you could shed some light on what goes on behind the scenes when a security researcher comes to an open source project or a vendor like Red Hat. How do you get all the stakeholders together? How do you run these types of things? How do you keep the team focused?

Rodrigo Freire (06:22)
Internally at Red Hat we have some internal prioritization of the CV based on the scale. We use a four point scale. We are not attached to the CVSS score or the ranking. We focus on the product rank for the security issue. Say for example, I use HTTP server, for example, Apache HTTP my system. Alright, so there’s a vulnerability affecting CVSS score in 10, a perfect 10 on CVSS for that.

However, this functionality it’s not exposed on my system or is not use it is not enabled is not supported. Why would I score that as a 10 since it’s not a valid usage on my product? So yes, I would just lump something as not a factor or even a factor, but the impact is low. Putting the customers at a heightened risk, we take that, so this is a Red Hat score as a product. I strongly believe that the the way we rank these vulnerabilities on our product is how the customers should actually be paying attention instead of taking the worst -case scenario in whatever possible use of the component.

I’m not saying that this is not important. It is, it is key. However, we do have people, we have a human operator that’s taking into account how that vulnerability is actually exposed on the product. So I think that’s something very important for the vendors to do. So they take a general vulnerability and then you issue a score for your product. How is that actually exposed on our product? So that said, this is how we select how and went to fix something.

And then, let’s say for example, in the case of a high-profile event, oh man, there was a very ugly vulnerability that showed at the eve of 2022 to 2023. It was December the 21, something like that. It was on the 20s. So we had the company at a freeze and I was working. So the…sorry, this still has to be taken, right? And then there was a KSMDB, it was a kernel SMB server vulnerability. Actually, it was a stream of them that was disclosed by Zero Day Initiative.

That was an uphill battle because in the end it was not affecting RAN because we don’t enable KSMDB on our kernels. So it was not affecting us. However, I needed to get all the techies, all the specialists to assure and ensure because customers questions were starting to pile up. It’s not only RAN had that runs 24-7, our customers as well were surprised. So we have to provide the answers. And then finding the right resources. This is one of the key abilities for everyone managing any security program. So it’s this vast network of contacts and who to ask and who to grab by the arms. Man, I need you to right now to please assess this vulnerability.

It’s a very important asset to have that disclosing the age again that Rolodex of context and to know the ones who ask for help to get information. You don’t have to know the information, you have to know who knows.

CRob (09:55)
Right, and I think it’s really important that some people in the supply chain, like a commercial Linux vendor, are able to contextualize that. Vulnerability may be abstract or not applicable, and I love that, that a lot of folks do that within the supply chain. Thinking about a vulnerability disclosure program, what we colloquially refer to as VDP, it’s important for large projects, and it’s required for a large commercial enterprise.

Could you maybe talk to some of our listeners about what the benefits to their downstreams would be to put the pieces in place to get some type of vulnerability disclosure program together?

Rodrigo Freire (10:33)
So Red Hat has a VDP in progress, so we credit for every finder that comes to us disclosing a vulnerability, we’re going to acknowledge, we’re going to point towards the person who finds this CVE. This is an integral part of our workflow for giving credit to the finder. Of course, we ask the finder, would you like to be credited? How would you like to see that credit get credited?

And also, that’s not only for the CVEs, however, for findings on our infrastructures as well. So for example, on the customer portal or on some catalog or webpage or whatever else they find something at Red Hat, we give credit to every finder. We don’t do bug bounties. However, we have this VDP, so someone is working their way to have a portfolio as a finder, as a pen tester, as a CVE finder. That’s 100% fine. We will give credit.

And then, this is getting adjusted, we will negotiate with the finder how much of time would you want to have that under embargo? So we have all this negotiation with the finder to make something that can accommodate everyone’s need.

CRob (11:48)
So it’s some good points. Well, let’s move on to the rapid-fire part of the interview. (Sound effect: Rapid fire!) Yeah!

Rodrigo Freire (11:56)
Here we go!

CRob (11:57)
First question. Here we go! Are you ready? Spicy or mild food?

Rodrigo Freire (12:03)
Definitely spicy, man. I’ve been to India in November on the end of last year, man. It was the time of my life eating any spicy food to the point of sweating in my head, man! That was a trip!

CRob (12:20)
Nice! (Sound effect: Oh, that’s spicy!) What’s your favorite whiskey?

Rodrigo Freire (12:26)
It’s Talisker. And I tell you what, if you’re having a Talisker and then you drink Blue Label, I’m sorry, Blue Label, that’s going to fade. Blue Label is just going to fade away. Talisker for the win.

CRob (12:42)
Very nice. Next question, Vi or Emacs?

Rodrigo Freire (12:46)
Vi, come on man!

CRob (12:48)
(Laughter) Nice! Rodrigo, what’s your favorite type of hat?

Rodrigo Freire (12:55)
Type of hat? Man, I actually found that, well, my favorite one is actually a Red Hat, right? But after I got a decision to become a bald person, I actually liked being bald and I seldom use any kind of hat, right? So I’m a proud bald, I’d say. On the other hand, it would be just a baseball cap.

CRob (13:17)
OK, fair enough. And last question, tabs or spaces?

Rodrigo Freire (13:22)
Tabs! Show some finesse!

CRob (13:26)
Nice, excellent, excellent. Well, now. (Sound effect: That’s saucy!) As we wind up, do you have any advice for someone that’s looking to get into the field, whether it’s cybersecurity incident response or open source development? What advice do you have for these newcomers?

Rodrigo Freire (13:43)
First of all, play nice. Show respect and make your due diligence. I think everyone is going to embrace you wholeheartedly because no one likes vulnerability. So if you’re going to find new stuff or even help to fix this stuff, show the attitude. So be positive, make your relationship network. That’s important because without it you’re not going to succeed or you’re going to earn some bad reputation as well. Everyone’s already fighting a hard battle, so play nice.

CRob (14:15)
Nice. That’s excellent, fantastic advice. And our last question, do you have a call to action that you want to inspire our listeners to go do as soon as they listen to this?

Rodrigo Freire (14:26)
Yeah, definitely. So, take into account your environment. So, no one likes emergencies. Emergencies are expensive. No one likes emergency maintenance windows. So, get to understand your environment. So, is this CVE, is this vulnerability really affecting? So, can you be that trusted advisor on your organization so you actually can be the person who sets the expectation, the needs of the company?

There’s some pressure from these high profile events from the upper floor asking hard questions. So get to understand your real need so you can actually schedule something that will not hurt your team or your availability or even the stability of your environment. And finally, I would say ask questions. So ask your vendor or your account reps or your consultants. So yeah, if you’re in doubt, go ask your questions. And I think I am positive that they are going to ensure you that you have a secure and stable environment.

CRob (15:38)
Excellent. That’s, I think, some great advice from someone that’s been there on the front lines helping fight the good fight for downstream and representing its customers. Rodrigo, thank you for joining us today on What’s in the SOSS? Really appreciate you coming and talking to us.

Rodrigo Freire (15:53)
Thank you, Chris. And one last word I would like to stress here. So on the security discussion, there’s no Red Hat. There’s no Canonical. There’s not Oracle. No. We all collaborate very closely when it gives regard to security issues. We are in close touch to everyone. Everyone knows each other. So there’s no, Red Hat’s only playing ball alone. No such a thing. I got to tell you guys, the XZ security incident was first disclosed to Debian and then Debian got in touch with us and then we started the coordination. So, yeah.

CRob (16:32)
I love that about our community, the fact that we all come together and able to put our colored hats to the side and come together and collaborate.

Rodrigo Freire (16:37)
Exactly, mister!

CRob (16:39)
Excellent. Well, thank you, Rodrigo. Have a great day.

Rodrigo Freire (16:42)
Thanks, Chris.

Announcer (16:43)
Thank you for listening to What’s in the SOSS? An OpenSSF podcast. Be sure to subscribe to our series of conversations on Spotify, Apple, Amazon or wherever you get your podcasts. And to keep up to date on the Open Source Security Foundation community, join us online at openssf.org/getinvolved. We’ll talk to you next time on What’s in the SOSS?

In this episode, CRob talks to Stephanie Domas, CISO at Canonical, the creators of the popular operating system Ubuntu. Having started her career with over 10 years of ethical hacking, reverse engineering and advanced vulnerability analysis, Stephanie has a deep knowledge and passion for the hacker mindset.

• 01:14: Stephanie shares how she got her start in security
• 05:41 Interesting things Stephanie has discovered since becoming more directly involved with open source
• 08:20 The challenge of instilling trust into those who consume open source
• 12:42 Stephanie answers CRob’s rapid-fire questions
• 14:07 Stephanie’s advice to those getting into cybersecurity
• 15:43 Stephanie’s call to action for listeners

• Stephanie Domas on LinkedIn
• Canonical homepage
• White House’s M-22-18 memorandum
• CISA RSAA
• Secure Software Development Attestation Form
• NIST Secure Software Development Framework (SSDF) SP 800-218
• Get involved with the OpenSSF community

Stephanie Domas soundbite (00:01)
For those who aren’t in security community yet, if you have that protector personality and you like to help and you like to make sure things are great when people use them, security may be for you, right? Those tinkerers and those protectors make such phenomenal security people. If those are you, we need you in security.

CRob (00:18)
Hello everybody, I’m CRob. I do security stuff on the internet. I’m also a community leader within the OpenSSF. And we have this nice little podcast you’re listening to called What’s in the SOSS? Where I get to talk to the most amazing people that work within and around open source software. And today we have a special treat. We have Stephanie Domas. She’s the CISO of Canonical. And she’s also a former teammate of mine and a fellow Ohioan. Stephanie, welcome to the show.

Stephanie Domas (00:52)
Thank you, CRob, it’s nice to see you again and thanks for inviting me.

CRob (00:55)
You’re very welcome. It’s nice to be seen. Gotta couple questions here. We’re going to have some fun questions later on, but let’s start off. Why don’t you describe to vthe audience kind of who you are? What’s your origin story and kind of what led you to this point where you’re working with one of the major commercial open source distributions today?

Stephanie Domas (01:14)
Yeah, absolutely. So the story of Stephanie and so it all starts back in middle school. And I won’t go, I won’t make this a huge long story, but I do think it’s, it’s, I don’t know, it’s colorful background, right? So back in middle school, right? I started to get into PC gaming, like all good nerds were at that time. And I, you know, hypothetically started to get very interested in how the cracked versions of things that I was hypothetically downloading worked.

And so while I was a consumer of these things, I really wanted to understand, you know, how were people figuring out where to patch? How were people figuring out how to change these games so I had more money or I had new powers. And so this led me on this spiral of just really wanting to understand how computers worked, right? So it all started with just how, how was this even happening? And so I kept digging deeper and deeper. And before, you know, I was in university studying electrical and computer engineering, and I was focused on processors.

And so I was very interested in essentially this, the brain of the computer, right? How is it doing it? Because at the end of the day, when I started to peel back the layers of cracks and the key gens, it all came back to trying to manipulate how the computer worked. And so I found this super interesting. And so, you know, I went to college, I started to get really interested in the cyber side of things, right? So when my university didn’t have a cyber program, I was still very interested in trying to peel back that onion.

And so I started, I joined an ethical hacking team. I participated in Capture the Flags or CTS and I was very fortunate that that first role I landed outside of college was on a security research team. And so I got to spend seven years just doing really fascinating security research. And given my focus was processors, as you can guess, my focus was on x86. So I did a tremendous amount of x86 security research for a number of years. And while that was immensely fun, at a certain point, I felt like I wanted to have a bigger impact on the world. And while my research was like interesting, right? I didn’t feel like I was having that big impact. And so I kind of did two things, right? I one decided to go do a startup and not just a startup, but I wanted to do it in an industry where I felt like cybersecurity was really, really weak. Right. And so I went and did a medical device cybersecurity startup. I felt like that, that industry, because of the impact for patient harm had this really high need for security and yet not a lot of security people were focused in the area.

And so I did a startup that, to this day is still having, I think, a profound impact on that community. And then I also started teaching because I wanted to give back, have a bigger impact. And so I started to adjunct at my alma mater, which is the Ohio State University, teaching a bunch of software and security courses and assembly. And, you know, I eventually started transitioning. I also started teaching at your traditional security conferences like Black Hat and DEF CON and DerbyCon. And then given my background in processors, I obviously ended up at Intel, which is where we had the privilege of meeting.

And so I got to be there for three years as the chief security technology strategist. And that was a ton of fun, right? Given Intel’s large impact across the world’s compute, right? I got to sort of fulfill my desire of driving impact across the world’s compute. And then last September, I had the honor of joining Canonical as their first CISO. And that’s really exciting for me because as you know, we all know listening to this, right? That just open source is such this beautiful thing where we’re capturing the world’s creativity as code. And while Canonical is the maintainer of dozens of open source projects, we are obviously most commonly known for Ubuntu.

And I’m also this fundamental believer that while a lot of people think of security as sort of guarding gates or building fences, it is all of that. But I actually believe it’s so much more that that security is also about building bridges and enabling compute that couldn’t have happened otherwise without security. And so I’m still on that mission to improve the world’s compute by doing amazing things in security. And so I’m so excited to be at Canonical to be a part of bringing that sort of how can security be an enabler to the world’s compute through open source.

CRob (05:14)
Nice. Well, you said something interesting that I want to circle back to in a future episode. I want to talk about DerbyCon, which was one of my favorite conferences ever.

Stephanie Domas (05:23)
I was so sad when they closed down.

CRob (05:25)
I know! #TrevorForget! But you know it being new to open source. What’s one of the most interesting differences that you’ve encountered kind of in your journey here and as you’ve gotten to know the culture around Canonical and the broader upstream open source?

Stephanie Domas (05:41)
Yeah, so this is a super fascinating thing for me because before joining Canonical, while I had been a consumer of open source and Ubuntu had been one of my daily drivers for, I don’t know, 15 years, basically, since they started doing security research, I wasn’t actually that familiar with or hadn’t really dug into the unique nuances of how you actually drive security into open source. And so that was obviously one of the first things that needed to happen in a transition here.

And so one of the really fascinating things to me was there are so many common practices in how you drive security into software, right? Commonly captured as things like your SDLC and SDLC best practices. And a lot of that is just, I don’t know, it’s relatively mature, right? Here’s all the things you need to do. And so one of the things that was super fascinating to me and is still just like a constant source of interest for me is how you translate all of those SDLC practices into open source. There’s so many nuances associated with one, it being open source, right? The fact that there are so many contributors and community members, but also one of the things that has been really eye-opening to me in the open source space is because it’s open source, you have so much more, you have much more complex dependency systems in the software, right?

Because it’s open source and because there’s a sense of community and because everyone sort of develops a library that does something and then everyone else consumes it, right? You get much more of these really complex interdependencies and upstreams and downstreams that just simply don’t exist in proprietary software. And so when you start trying to apply your traditional SDLC practices to this, a lot of it doesn’t fit. And so it’s an interesting paradigm of there are known good things to do and they don’t quite translate into open source. Some of them do, but a lot of them don’t. And so that’s been a really interesting journey for me to try and figure out what can we take, what doesn’t fit, how could we make it fit, how can we still achieve some of the same outcomes in this open source and really immensely complex dependency trees.

CRob (07:40)
It’s a great challenge that I’m glad that we have folks such as yourself helping try to drive this. And that kind of touches onto our next question. You’ve spent time within traditional large enterprises and generally with those types of companies, you’ve got well-defined boundaries and regulations and policies and whatnot. And part of Canonical’s job is making open source consumable for those types of customers. Talk a little bit about some of the processes that might work in an enterprise that can help instill trust into folks’ open source software consumption.

Stephanie Domas (08:20)
Yeah, so this one’s super fascinating as well because there’s open source and then there’s open source that is enterprise-ready. And while sometimes that means at the high level, right, it’s things like, it’s resilient, it’s been tested, maybe it’s supported. But I would say that’s actually kind of just cracking the surface of this, right? At the end of the day, you know, Canonical sits at this sort of in-between enterprise and open source. And some of the really interesting things, especially you see in the security space, is this desire for these companies to translate what they know as secure practices into the open source space.

And so I also mentioned in the last question, right, the SDLC, right? The number of questionnaires we get from customers that say, do you have an SDLC? Does it meet all these requirements? And it’s their standard questionnaire, right? It’s all those standard best practices I just talked about. And it’s really, really hard to say yes to those and feel like you can write like a real solid checkbox in that line. And so just giving like a super nerdy example is something that’s just been on my mind recently. So I’m going to throw out some nerd numbers here. So the OMB memorandum, M-22-18, right? I see you shaking your head and I know people can’t see this.

CRob (09:33)
Oh, I’m familiar with it.

Stephanie Domas (09:35)
The thing is just, this is, this is a real big thing right now and it is requiring software manufacturers to fill out a repository for software attestation art, sorry a secure software development attestation form to then file in the repository for software access stations and artifacts. This form is derived from the NIST SSDF, which is the NIST secure software development framework, SP 218. I’m throwing so many numbers at us right now, but the whole point is, right, this is an example of sort of what I talked about in the last question where enterprises have these known ways of doing things and then this SSDF is a common accepted way of doing secure development lifecycle, but a lot of it, well, not all of it translates cleanly to open source.

And so now you have these memorandums coming out asking software developers to fill out this form. And some of the questions in there, I would say at least half of the questions inside of it are around the development machines, right? Was the development done on a machine that is isolated? Was the development done on a machine that follows security best practices? Well, how on earth am I supposed to answer that question for open source? Do I answer with the mindset of just Canonical developers, in which case I can give a straight answer? Do I answer with the community members? And the form that they’ve developed has no area for you to explain nuance. You’re either in alignment with the form or you answer no and they consider you sort of out of alignment and you are considered to need to put together a plan for how you get in alignment.

And so things like this are really interesting in sitting in that intersection between enterprises and open source because a lot of these sort of regulations and efforts of what these enterprises are looking for, right? The checkboxes they need to get in order to be able to them satisfy their customers don’t translate. And so we sit at that intersection of trying to, you know, one, make it your traditional enterprise ready with resilience and testing and code coverage and all of those great things.

But also the really interesting part of the really complex part that I think a lot of the community members maybe don’t appreciate how chaotic it is, is how you translate all of these regulations and these internal NIST frameworks that all the customers want checkboxes for into how you meet those in an open source space in a way that you can say with confidence, right, we want to have confidence when we say, yes, we meet this is really, really difficult to do. And yeah, so that memorandum is on my mind a lot right now because we’re attempting to go through that process right now. And again, it’s like, how do I answer this question when I don’t control community members’ laptops, right?

CRob (12:11)
Yeah, it’s a lot of really interesting challenges. I could spend hours talking about SDLC too. I’m really excited again that we have folks that are bringing, kind of live in both worlds. You’re bridging the gap between enterprise and community and trying to help make a successful translation. I really appreciate that. And I also appreciate we’re at the time of the show where we’re going to do the rapid fire round!

Stephanie Domas (12:35)
Woo!

CRob (12:36)
All right, I got a series of fun questions and let’s see how you do. There are no wrong answers. First question, spicy or mild food?

Stephanie Domas (12:46)
My gosh, so mild. I am absolutely a wimp with spices.

CRob (12:49)
(Laughs) Alright, fair enough. Next question. What’s your favorite flavor of ice cream?

Stephanie Domas (12:55)
Vanilla.

CRob (12:56)
Vanilla? Alright. French vanilla? Vanilla bean?

Stephanie Domas (13:00)
(Laughs) I am not fancy enough for that one. My palate is not refined enough to know the difference.

CRob (13:06)
(Laugs) Very nice. All right. Vi or Emacs?

Stephanie Domas (13:12)
Vi, definitely.

CRob (13:14)
Yes, hooray! There are no wrong answers except if you pick Emacs.

Stephanie Domas (13:18)
Yes, my Vimrc file is complicated and every time I move computers and I haven’t moved it, it’s very painful. So it’s got a lot of customization, I won’t lie.

CRob (13:31)
Excellent. And last question from rapid-fire: tabs or spaces?

Stephanie Domas (13:36)
My gosh, I’m gonna get some enemies here. I’m a tabs person.

CRob (13:39)
Yeah? very nice. Again, there are no wrong answers. Everyone has their own way of working. That’s great. Thank you for sharing our little fun segment. And as we wind down, what advice do you have? You mentioned that you’ve been a teacher and you’ve given a lot of your time to try to help bring up the next generation of folks. Well, what advice do you have for people that are getting into either open source development or cybersecurity?

Stephanie Domas (14:07)
Yeah, I guess so. I’ll focus on the cybersecurity one and I’m going to get a bit of like social emotional on us here instead of technical. But my advice, my high level advice is just assume the best in your community team members until you are given a reason to otherwise. I see so many times some new vulnerability comes out or some new incident or a breach happens and I see people in the community kind of they jump to assuming negligence or assuming that people are dumb and you see statements like how could they not have done X, like that’s so obvious and it makes me really sad because I feel like most people in the community actually are really trying to do the right thing.

They are on limited resources. They have to make tough decisions and sometimes literally things just fall through the cracks and so I see people get burnout because, not because they’re not trying to do the right things because they’re trying to do the right thing, and people don’t aren’t appreciating that they’re trying to do the right thing right so we’re going to. It’s going to be a high-level one of be good to your fellow security members. And if you’re in a position to offer help to them, somebody who happens to be in the spotlight, is firefighting, is involved somehow in a breach or an incident. Instead of sitting there and trying to judge them offer to help them, even if it’s just to offer a shoulder for them to have somebody to not yell at them for a moment, send them a digital coffee, something. So assume the best in your security team members until they give you a reason to not.

CRob (15:31)
I love it. More empathy for everybody, I think, will make the world a much happier place. And finally, do you have a call to action for our listeners? Something you want to inspire them to do next?

Stephanie Domas (15:43)
Just, I know this is one, it’s also kind of cheesy. It’s just, I don’t know, just always be curious in how stuff works, right? I think there’s so many different reasons why people get into security. I got into it because I was a tinkerer and because I’m curious. If that’s your passion, right, follow that. I would also say the other really big one I see is people who have this protector personality. So if you feel like, for those who aren’t in the security community yet, right, if you ever, if you feel that protector personality and you like to help and you like to make sure things are great when people use them, right? Like security may be for you, right? Those tinkers and those protectors make such phenomenal security people. If those are you, right? We need you in security.

CRob (16:24)
That’s awesome. Such wise words. Thank you, Stephanie. I really appreciate your time. O-H…

Stephanie Domas (16:30)
I-O!

CRob (16:31)
Yes!

Announcer (16:32)
Thank you for listening to What’s in the SOSS? An OpenSSF podcast. Be sure to subscribe to our series of conversations on Spotify, Apple, Amazon or wherever you get your podcasts. And to keep up to date on the Open Source Security Foundation community, join us online at openssf.org/getinvolved. We’ll talk to you next time on What’s in the SOSS?