OpenSSF

• 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?

In this episode, CRob discusses the finer points of developer relations (DevRel) with Katherine Druckman, Open Source Evangelist at Intel and co-chair of the OpenSSF Marketing Advisory Council and DevRel Community. Katherine enjoys sharing her passion for a variety of open source topics and is a long-time open source advocate, developer and podcaster. She’s currently the host of Open at Intel and co-host of the FLOSS Weekly and Reality 2.0 podcasts. She spent over a decade at Linux Journal. A passionate Drupalist since she first downloaded a tarball in 2005, she has also been a Drupal contributor and engineer.

Additionally, Katherine will be a featured speaker at SOSS Fusion/24 in Atlanta on Oct. 22-23. SOSS Fusion/24 is a collaborative and forward-thinking initiative dedicated to securing open source software. This event will bring together a diverse community of professionals from the public sector, software developers, security engineers to cybersecurity experts, CISOs, CIOs, Founders and tech pioneers.

Katherine will be an active participant at SOSS Fusion/24 and will share her insight at the following presentations:

• Roundtable: Building Developer Confidence in Software Security with the DevRel Community, with Lori Lorusso, Percona; Tabatha DiDomenico, G-Research. Oct 22, 11:30 a.m.
• Keynote: Fireside Chat with Window Snyder, Founder & CEO, Thistle Technologies, Oct. 23, 9:30 a.m.
• Keynote: Back to Security Basics: Evaluating, Consuming, and Contributing Open Source Software, Oct. 23, 9:55 a.m.

Check out the full schedule for SOSS Fusion/24.

• 01:42 Katherine shares her non-traditional journey into open source
• 03:30 DevRel’s definition varies, depending on the organization
• 06:11 Tips for making connections with developers
• 08:23 How DevRel professionals can help integrate security practices and tooling into everyday maintainer activities
• 09:38 Katherine answers CRob’s rapid-fire questions
• 11:05 Katherine’s belief that all knowledge can be relevant — even if it’s outside of your field
• 12:23 Developers and security folks should be working together

• Katherine Druckman on LinkedIn
• OpenSSF DevRel Community
• Open at Intel podcast
• SOSS Fusion/24
• Get involved with the OpenSSF community

Announcer (00:01)
Today’s guest on What’s in the SOOS? is Katherine Druckman, Open Source Evangelist at Intel. Katherine will be a featured speaker at SOSS Fusion/24 in Atlanta, October 22nd and 23rd. SOSS Fusion is a collaborative and forward-thinking initiative dedicated to securing open source software. The event will bring together a diverse community of professionals from the public sector, software developers, security engineers to cybersecurity experts, CISOs, CIOs, founders and tech pioneers. To learn more, to register and to see the full schedule visit openssf.org.

Katherin Druckman soundbite (00:36)
We solve technical problems with technical solutions, but there are also so many human problems with so many human solutions. And I think step one to effective engagement with open source maintainers is taking notes, find out what they really, really need and then try to connect the dots.

CRob (00:54)
Hello, everybody. Welcome to What’s in the SOSS? I’m CRob. I do security stuff on the internet and I do a lot of work with the Open Source Security Foundation. I work on the Technical Advisory Committee, the governing board and a bunch of the technical groups. And one of the great things I get to do is co-host What’s in the SOSS? — our podcast about learning more about interesting topics and people within the open source ecosystem. And today we have a real treat. We have my friend from work, real work, not fun upstream work Katherine Druckman from Intel. How are you doing today, Katherine?

Katherine Druckman (01:29)
I am doing well, thank you. I appreciate you having me. This is gonna be fun.

CRob (01:34)
It’s gonna be great. So for our listeners who may not get the opportunity to work with you all the time, could you maybe give us your open source origin story?

Katherine Druckman (01:42)
Oh yeah, sure. Wow, that’s a long time ago. (Laughter) Yeah, so this is funny. I like to talk about that I have a non-traditional background. Actually, I went to my, I have an art degree and then my graduate studies were in decorative arts history. It makes total sense why I would end up here, right? So at some point in there, I was doing some — let’s call them art things and art and antiques and decorative things — and I decided I needed a website for these things.

And I had a lot of nerd friends who were very involved in some tech startup at the time. And this was in, gosh, I don’t know, around 2002 to 2004 maybe. And I was always kind of a nerd, to be honest. Like I had dabbled in a little Linux before that. So I asked one of my nerd friends and I said, hey I heard there’s such a thing as an open source content management system. What’s that and can you recommend one? (Laughter) And he said, oh, here’s a few. I tried a few. I settled on Drupal to build a website. And then I started building other websites and then I started learning more and more. And anyway, long story short, I ended up at Linux Journal because I learned the Drupal. So that’s the short-ish version of my origin story. And then I had a lot of adventures along the way and somehow all of them led me here.

CRob (03:03)
I’m going to have to do a session sometime because there are a lot of us that come from non-traditional backgrounds that work and live in here in high tech. So that’s interesting to hear. So let’s talk about kind of what you do with the Open Source Security Foundation. And this is really introduced me to a very interesting concept. So for our audience, could you maybe explain what DevRel is and why it’s important?

Katherine Druckman (03:30)
Sure, yeah, yeah, yeah. So I co-chair the Marketing Advisory Council, is I believe what we’re calling it today. Apologies if I got that wrong. And as part of that, we created an initiative and created a DevRel community to do developer relations on behalf of the OpenSSF. And what that means, developer relations type work has a lot of names, right? Some people call it developer advocacy, evangelism and it really kind of depends on the organization where you’re doing it.

For the OpenSSF specifically, really we’re there to raise awareness where hopefully the mission is to connect developers and users and consumers of open source software and then in particular maintainers of open source software to all of the wonderful tools that brilliant people like you and all of our buddies are working on at the OpenSSF. So I got involved because, frankly, I was really into the mission of the OpenSSF even before I was at Intel.

When I heard about the formation of the OpenSSF, I was kind of following it because one of the things I do in my small amounts of free time is I occasionally co-host, and at the time I was co-hosting Floss Weekly, another podcast. And when we’re looking for news stories in the open source space, I came up with, oh look at this! There’s this new foundation. They’re doing work. It was always a source of insecurity slash curiosity for me. I never felt, when I was a software engineer, like I was fully prepared from a security perspective. So it was something that I pursued. So that’s where I jumped in.

But going back to the original question, which is, what is DevRel? The funny thing is if you asked 20 different DevRel-type people, they would probably all give you a slightly different answer. Because at the end of the day, you really kind of need to connect the goals with the specific organization with the work that you do. Because it can vary. Generally speaking, it’s whatever serves the needs of your organization. And it can be education. It can be being a catalyst between end users and a product. You might work with product teams, but you might be more educational and community focused like I am. The meaning varies depending on the organization. Yeah, and it’s just, it’s not an obvious answer, I don’t think.

CRob (05:49)
That makes sense. As you know, it’s very hard to quantify what the open source is. There’s so many different permutations, so I get that. Thinking about the role of DevRel and maybe in particular with the OpenSSF, from your perspective, what have you seen that works with trying to help get engaged with maintainers and then keeping them engaged?

Katherine Druckman (06:11)
I guess I’ve seen a lot (Laughter). So back to the thing about, you know, it varies, right? I think ultimately, developer advocates and developer relations people are there to identify with and advocate for the needs of developers, because we are them. Most people that are in the DevRel space were developers, were software engineers. And we’re kind of, we’re drawing on that on our personal experiences. And I think what works, if you want to engage, especially with open source maintainers, developers and maintainers just want to get things done. We’re ultimately, we’re makers, right? We’re makers and we’re creators. And I think we all crave resources to help with that.

Sometimes it’s education, sometimes it’s tools. Sometimes it’s just, being heard, I think. So something that’s resonated for me: I’ve started having some conversations recently about maintainer burnout that have gone unexpectedly well. And I did this, I think, for a lot of reasons, right? I like to talk to smart people about anything and everything. So any excuse to talk to a lot of really interesting open source maintainers, I’m all over. But this was a topic, I think, on my mind and on the minds of a lot of people on my team.

So I started talking to more and more people. And I think these conversations have resonated even more than I expected. And I, my suspicion is just because people feel heard and understood and listened to. And it’s, so, you know, I think if, if you want to engage with software maintainers, step one is listening to them. You know, forming those human connections, you know, I think, you know, we get bogged down in the world of software and it’s a very, we, we solve technical problems with technical solutions, but there are also so many human problems with very human solutions. And I think step one to effective engagement with open source maintainers is listening. Listening, taking notes, find out what they really, really need, and then try to connect the dots.

CRob (08:12)
Well, I’m going to put my listening ears on right now. From your perspective, how do you think DevRel can help get security practices and tooling better integrated into maintainer daily workflows?

Katherine Druckman (08:23)
Yeah, that’s such a good question and a complicated one to answer, but I’m going to give it a shot. I think it goes back to listening, right? I keep saying that, but I think with things like connecting tooling, it’s figuring out all the spots along the development lifecycle where maintainers and developers are stuck, right? Where in the process are things most difficult and where do they need the tools to unblock them along the process? I think so that’s part of it. Connecting people to the things that really, really help.

Tools that smooth processes and resources really of any kind, frankly that let them kind of unplug and sleep well at night, you know (Laughter). I also feel like I would caution people to not try and focus too much on ticking boxes that don’t necessarily help the developers and maintainers. I think when you’re on one side or other of a conversation, sometimes if you’re, let’s say, a tool creator, you kind of get in the mindset of ticking the boxes that you think that people need to solve. But it’s really important to make sure that you’re pursuing the right things that really do have a direct impact on just making developers and maintainers’ lives easier.

CRob (09:38)
Let’s move on to our rapid-fire section of the interview. (Sound effect “Rapid fire!”). I’ve got a couple questions for you. Are you ready?

Katherine Druckman (09:46)
Oh, I, sure.

CRob (09:48)
Do you like spicy or mild food?

Katherine Druckman (09:51)
Oh, I like spicy, but my stomach prefers mild.

CRob (09:54)
(Laughter) Fair. What’s your favorite cocktail?

Katherine Druckman (0958)
Oh, gosh, lately a Paloma.

CRob (10:01)
Vi or Emacs?

Katherine Druckman (10:02)
Vi.

CRob (10:04)
Oh, thank you. Yay. There are no wrong answers, but Vi is always right. Being that you’re a fellow podcaster, what’s your favorite type of microphone?

Katherine Druckman (10:14)
Ahhh, ohhh. That’s a…I like Shure. I have a couple really good Shure mics.

CRob (10:19)
I love it too. So last question, rapid-fire, tabs or spaces?

Katherine Druckman (10:24)
Oh, God. Spaces. But I’m probably gonna get…

CRob (10:28)
(Laughter) This is very controversial.

Katherine Druckman (10:29)
I know. I’m probably gonna get yelled at for that, but I know I’m supposed to…I feel like I’m supposed to say tabs, but if I’m being honest, I’m probably gonna say spaces.

CRob (10:39)
That’s fair. Again there are no wrong answers. It all goes up to personal style and especially working with developers. No two developers do their work the exact same way.

Katherine Druckman (10:48)
Fair.

CRob (10:49)
Thank you for those amazing insights. So as we wind down here and close out, what advice do you have for somebody that’s interested in starting a career, whether it’s as an open source developer or getting into like cybersecurity or anything? What advice do you have to the new next generation?

Katherine Druckman (11:05)
Sure, yeah. Well, as I mentioned when we first started, I have a very non-traditional path, right? And I would say don’t be afraid of that. Learn all the things because you would be surprised at what sort of obscure piece of knowledge you might dig up from all of your experiences that might help you. Something from another field. I really like kind of interdisciplinary thinking. The example I use a lot, probably too much, is ergonomics and design, German kitchens of the 1930s. Yeah, it’s a whole thing. That’s what happens when you go to grad school for design history. But it’s a thing.

And every now and then, I think back to it. And I think about just the effectiveness and the simplicity and the amount of attention to detail that people put into the evolution of the modern kitchen. And it comes out in unexpected ways. And that’s, you know, it’s kind of a random and possibly silly example, we are a whole people and we draw from our, from all of our experiences. So I would just recommend learn all the things. Nothing is, nothing is not relevant.

CRob (12:11)
Awesome advice and I really like the idea of kind of connecting your background to your passions. As our final question, what call to action do you have for our listeners? Is there anything you want to inspire them to go do?

Katherine Druckman (12:23)
Yeah, come join our OpenSSF DevRel community. That’s the biggest one. Yeah, we have office hours, we have meetings, this is open to anyone. We would love to see more developers and maintainers help get this thing off the ground. Have a really effective meeting of the security folks and the developers because I feel like sometimes we’re seen as almost like opposite sides, which doesn’t make sense to me because to me, I don’t think of it that way. I never have.

I’ve always been a developer who wanted to do the right thing from a security perspective. So I feel like we should all just be like me. (Laughter) But seriously, come to our meetings, come join us. You might have some fun. We’re solving important problems. And yeah, I look forward to seeing everyone. The other last piece of advice I would have is I just got a refrigerator that has a freezer that makes craft ice and it makes these balls, because we’re talking about cocktails, it makes spherical ice. So yeah, that’s my other piece of advice. Get your hands on one of those because it’s really cool. The cocktail question reminded me and I feel like I needed to mention that.

CRob (13:29)
(Sound effect: “That’s saucy!”) That’s awesome. Thank you so much, Katherine. I really appreciate our conversation and everything you do to help get developers engaged and help get them empowered to continue the amazing work they do. So thanks for joining us on What’s in the SOSS? And we look forward to seeing you next time. Thank you.

Announcer (13:48)
Thank you for listening to this episode of What’s In the SOSS? an OpenSSF Podcast. As a reminder, Katherine Druckman will be a featured speaker at SOSS Fusion/24 in Atlanta, October 22nd and 23rd. To learn more, to register and to see the full schedule, visit open ssf dot org. And to subscribe to our series of conversations on Spotify, Apple Podcasts, Overcast, Pocketcasts or wherever you get your podcasts. We’ll talk to you next time on What’s in the SOSS?