Summary
Christopher Robinson (aka CRob) is the Director of Security Communications at Intel Product Assurance and Security. He also serves as the Open SSF’s Technical Advisory Committee (TAC) Chair. And soon, CRob will step into another role: co-host of What’s in the SOSS? With 25 years of enterprise-class engineering, architectural, operational and leadership experience, Chris has worked at several Fortune 500 companies with experience in the financial, medical, legal, and manufacturing verticals. He also spent six years helping lead the Red Hat Product Security team as their Program Architect.
Conversation Highlights
- 00:57 – CRob’s day-to-day activities and his affiliation with the OpenSSF
- 03:15 – The insight CRob will bring to the podcast as co-host
- 05:46 – What developers writing “post-bang” code should be considering
- 08:40 – Lessons open source could learn from corporate and vice versa
- 12:17 – CRob explores the evolution of open source
- 14:22 – Crob answers Omkhar’s rapid fire questions
- 15:57 – CRob’s advice to people entering the cybersecurity field
- 18:18 – CRob’s call to action for listeners: give back
Episode Links
Transcript
CRob soundbite: (00:01)
First and foremost, open source is agile. And that’s something that corporations need to understand. And that it moves at a totally different velocity and isn’t necessarily beholden to month-end change freezes or a year-end close when you’re trying to balance the books. So open source is always moving.
Omkhar Arasaratnam (00:19)
Welcome to What’s in the SOSS? I’m your host Omkhar Arasaratnam and the general manager of the Open Source Security Foundation, the OpenSSF. Joining us today is a good friend of mine. He sometimes goes by Christopher Robinson, he sometimes goes by the security Lorax, but most often he goes by CRob. CRob, welcome to the show!
CRob (00:41)
Hey, thanks for having me Omkhar.
Omkhar Arasaratnam (00:43)
It is a pleasure.
CRob (00:46)
The pleasure’s mine, sir.
Omkhar Arasaratnam (00:48)
So, other than being a security Lorax, can you tell us your title and what you do in your day job as well as the work you do with the OpenSSF?
CRob (00:57)
So I like to say that I really don’t do anything is my claim to fame. I just write and I talk on podcasts like this stuff. But my title is I’m the Director of Security Communications for Intel. So I help make the internet a little less sad about vulnerabilities that impact our portfolio, do crisis communications, I work with our PSIRT and whatnot. And then the other half of my time is spent towards upstream community work like our collaboration at the OpenSSF.
Omkhar Arasaratnam (01:28)
For our listeners that may not have attended a TAC meeting, things of that nature, do you want to talk to what your role is as TAC Chair, what the TAC does and how the TAC works in the OpenSSF to help make open source software a little more secure?
CRob (01:45)
Right. So the Technical Advisory Council, or TAC, is a technical body. We are voted on every year, and some of our seats are appointed by the governing board. But the duty of the TAC is to take a look at the technical initiatives of the foundation. So things like software projects or work on specifications and standards or guides. And we help steer that, making sure things are aligning with the strategic direction of the foundation and they all support the general overall kind of ecosystem uplifting of open source security for everybody.
Omkhar Arasaratnam (02:21)
Amazing, and thank you for all the work that you do. So much of the amazing projects that we have under the OpenSSF thrive under the tutelage of the TAC, and thank you for that. Now as the saying goes this ain’t your first rodeo. You’ve been doing security for a while.
CRob (02:40)
Are you saying I’m old?
Omkhar Arasaratnam (02:42)
It was implied. (Laughter) And for our audience, the many years of wisdom and experience that CRob brings to the table is one of the reasons that CRob is our new co-host on What’s in the SOSS? As we all believe, he’s going to bring a lot of that experience to the interviews in speaking with some of our guests. CRob, I’m going to put you on the spot, my friend, some thoughts as the newest minted co-host of What’s in the SOSS? What, what do we have in store?
CRob (03:15)
I’m really excited. I’ve got some, a whole list of folks lined up, so we’re going to talk about things like why are people still installing known vulnerable packages? We’re going to talk about large corporations adopting a lot of the projects of the OpenSSF and kind of understanding how an actual person could do some of that. We’re going to talk about coordinated vulnerability disclosure. We’re going to talk about the Linux distros and how kind of their role in helping support security of the ecosystem. So again, I think we have a lot of amazing content, some amazing people that are contributors to the community that we’re going to talk to.
Omkhar Arasaratnam (03:49)
I’m very excited. I can’t wait to hear all the interviews that you have lined up and, and learn more about how people are adopting the work that we’ve been working so hard on. In your career in which you’ve done many things, you spent a lot of time on what I would call the post-bang side. So vulnerability comes out or an exploit occurs in the field. Can you help orient our audience to some of the work that you’ve done in that arena and some of the unique experiences that you’ve had?
CRob (04:22)
Yeah, absolutely. I’ve spent almost seven years of my career working as part of Red Hat product security where under Mark Cox, I helped run the program with him and then eventually partnered with Vincent Danen, who’s now the current leader there. And so I have a lot of experience on both pre- and post-bang. But for my particular skillset is the post-bang piece, trying to help make sure that when that public disclosure goes out, and the world is aware of something going on, trying to make sure that they have adequate information and access to the fixes so that they can treat the problem that’s being disclosed.
And it’s important that it’s sometimes overlooked as when the responders or developers are in the heat of the moment trying to fix the problem. They’re not thinking about the downstream consequences or what happens when this thing goes public. You don’t want to be on the front page of The Register or The New York Times. So it’s trying to think about things like that and making sure that people can defend themselves.
Omkhar Arasaratnam (05:22)
You have a very particular set of skills, Mr. CRob. What should our developers be thinking of as they’re writing code to make the role of that person that has to deal with the after the fact, the post-bang, a little bit easier? What can they be doing in development so that it’s a little less, the incident is a little less exciting?
CRob (05:46)
I have a couple pieces of advice. First and foremost, all projects should talk about — whether it’s a single maintainer or a team — you need to sit down and think about how, when you get a vulnerability report, how you’re going to handle that and ultimately how you’re going to disclose it. And in the industry, we call that a vulnerability disclosure program or a security policy. So it’s important to have that. And that helps set expectations both for when the finder comes to you — they’re making a demand of something getting fixed. It also helps your downstream understand exactly what you’re gonna do. Are you going to fix something? How quickly are you gonna fix something? So having that documentation upfront and that agreement helps set the expectation so that when things go public, ideally it goes smoothly for your downstream.
And next, you need to understand kind of what your project depends on. Very few projects are self-contained and they only have code and only use code written within that project, you have dependencies, you have libraries and other components that you’re calling out to. So understanding what you depend on helps you react when one of those components has a vulnerability. And then that’ll ideally help avoid your downstream asking, are you affected? Are you affected? So understanding your dependencies, consider writing an SBOM for your team’s use, your project’s use, but also consider sharing that for your downstreams, because that’s valuable information to them to understand and helps with their vulnerability remediation.
Next up, I would say that find a big brother or a big sister in the community. There’s a lot, open source has been around for three decades now that since Linus released the kernel, find someone that you look up to, that you respect and ask them advice. Line up people that when you’re in the middle of a crisis, people you can talk to that might have more security expertise than you so that you can ask questions and help get help if you need it. But having that community, big brother, big sister is invaluable to give you that advice and guidance and suggestions on how you might be able to do something.
And then finally, I would encourage all developers to embrace the mentality of Kaizen, that continuous improvement. So what you do today isn’t necessarily going to make you successful tomorrow. So think about it with every release, with every vulnerability that you fix, think about how you can adjust your practices or tweak your tools so that maybe you can avoid that situation going forward.
Omkhar Arasaratnam (08:08)
That’s some great advice and certainly speaks from those — how many decades of wisdom was it that we were up to — so, sorry, I’ve said too much. With your experience, I’m wondering between the time that you’ve spent on open source and in corporate, what lessons can be learned from either side? Like what should corporate security be thinking of that open source does incredibly well? And what does open source need to think about that maybe corporate security has been doing a little bit better of a job?
CRob (08:40)
That’s a really interesting question. I think, and I can address both points of that. First off, for those of you that aren’t aware, at its core, open source software is about sharing. It’s about openness and transparency and meritocracy, where the best ideas win. So, first and foremost, open source is agile. And that’s something that corporations need to understand, that it moves at a totally different velocity and isn’t necessarily beholden to month-end change freezes or year-end close when you’re trying to balance the books. So open source is always moving. So just being aware of that and that agility not only is in the process, it’s also in their thinking where they are able to ingest new diverse ideas, different perspectives.
And that’s something that corporations potentially can learn from kind of seeing this attitude and embracing the fact that, you know, somebody, a grizzled veteran of a quarter century in development and security might not have all the answers. And somebody, a new junior person might have just as valid an insight into the problem as everybody else. Next up, where developers are incredibly creative people, but kind of like me, they tend to be a little lazy. So wherever possible, they love automation. And that helps them become more efficient, helps them be that creative source of inspiration and ideas. So open source is all about automating. And that’s something I would really recommend.
Back when I was in several corporations I was at, we always looked for opportunities to automate a process. And whether this is part of your CI/CD pipeline, part of your deploying servers or configuring Kubernetes clusters, whatever. If there’s like, a repetitive low-value task, make a robot do it for you, write automation to make that go away. And then again, just thinking about open source very much kind of avoids that monoculture and they avoid monolithic thinking. So again, you’re going to have really great diversity of thought and diversity of background. And I would again, encourage corporations to embrace that.
Now flipping this on its head, corporations are generally, hopefully, good at making money and good at directing resources and managing time and priorities. So that’s where open source kind of falls down a little bit. We’re not quite as organized and disciplined as we could be. And where I would, the very first and foremost thing, and you’ll see this, it varies widely by project and community, but documentation and process are key because it not only helps you draw in new members if they can understand the kind of what your processes are and how they can interact with it.
But it also helps your downstream understand what you’re doing, how you’re doing it and having procedures like tabletop exercises where we went through this effort and the vulnerability disclosures working group at the foundation. We’ve been partnering to help create these resources so that an upstream project can understand the value of doing a tabletop exercise or going through a threat modeling exercise to understand how their software can be broken.
So these processes, the discipline and rigor — not that I’m saying you would totally want to be inflexible — but open source definitely can adopt some of these things to help improve the quality of life of the maintainers and the downstream.
Omkhar Arasaratnam (11:52)
Make the incidents boring.
CRob (11:54)
Right, exactly. It should be just a non-event. It’s just another patch.
Omkhar Arasaratnam (11:58)
That’s definitely some interesting lessons that can be learned from either side. Now, in your experience in using open source, I’m sure over the years you’ve seen it evolve. How have you seen it from your earliest days engaged with open source to where we are now? Have you seen that evolution?
CRob (12:17)
So when I started off, I ran a corporate engineering and operations team and we were responsible for first web security of a large financial institution. And then I moved over to the distributed side, the distributed server side, where I ran the Unix Linux team. So back then, when I first got into this space, the idea of large companies using open source was generally almost exclusively a cost play where we had feature parity, you know, that the Unix and Linux were generally the same. And it was pure cost savings where you could deploy a server for one quarter the cost of a traditional Unix device.
And, you know, there wasn’t a lot of innovation, but getting those ideas from Linux and open source into these large financial institutions helped them understand and be able to harness some of the innovation and velocity that happens upstream. That’s where you started to gradually over the last decade or so, I’ve seen companies go from, we’re just trying to save a couple bucks to, hey, there’s some amazing innovations here. I want to integrate these features into my own development practices or my own portfolio so that I can be that, you know, take advantage of some of these cutting edge things.
And that’s like how things like Kubernetes and containers all came about because that was a way of trying to help improve operational efficiency. So now again, it’s kind of transitioned to where we are now where people are participating upstream and helping set some of that innovation being very engaged upstream to help steer things to have good outcomes downstream. It’s a nice evolution and open source software development. It used to be we were all kind of a Waterfall waterfall style of development model or it was very slow and regimented.
And now we’ve changed to agile methodologies and that’s the de facto way how software is developed today.
Omkhar Arasaratnam (14:14)
It’s certainly amazing to see how adoption has changed over the years, and I can’t wait to see what’s coming next.
CRob (14:21)
Yeah, me too.
Omkhar Arasaratnam (14:22)
So now, CRob is when we transition to rapid fire. So here’s how rapid fire works. Can I ask you a few questions?
CRob (14:30)
You may.
Omkhar Arasaratnam (14:31)
And in asking those questions, I’ll provide a set of pre-scripted answers or the right answer may be, no, Omkhar, you got that wrong. Here’s what I think. Are you ready to go?
CRob (14:43)
I am, sir.
Omkhar Arasaratnam (14:44)
Alright, first one. Spicy or mild food?
CRob (14:48)
Spicy, no other answer is valid.
Omkhar Arasaratnam (14:50)
Totally agree. Spicy or nothing. And I recall from a few meals that we’ve shared and a few drinks that we’ve shared, you know how to hold your spice, man. You do all right. All right, this next one’s a bit trickier. Favorite text editor: Vim, VS Code, or Emacs?
CRob (15:08)
VI, colon q, baby!
Omkhar Arasaratnam (15:15)
There you go! Exclamation mark. Quit without saving. Now the last one is incredibly controversial. Tabs or spaces?
CRob (15:21)
(Exasperated sigh) I like tabs, but I understand that spaces have their place and are useful. So again, I’m not a purist. I would lean towards tabs, but you’ll see some occasional spaces.
Omkhar Arasaratnam (15:33)
That’s an incredibly diplomatic answer.
CRob (15:36)
I do my best.
Omkhar Arasaratnam (15:38)
In wrapping things up, CRob, what advice would you have for somebody entering our field today? Be they somebody graduating from college versus maybe somebody who’s made a career change and decided for whatever reason to get in a cyber. I mean, that’s, I don’t know why they’d make that decision, but what advice would you give somebody entering our field?
CRob (15:57)
I have so much advice. It’s hard to choose just one, but I will say this. In my experiences in the last (intentional murmur) century of doing cybersecurity and software development–
Omkhar Arasaratnam (16:08)
What was that, three centuries?
CRob (16:10)
Pretty close. I think that there are so many interesting things going on, so many different and unique aspects of the trade. And I would, it’s very easy to get overwhelmed. It’s like you’re a kid in the candy shop and you want a little of everything. And then when you do that, you get sick and you vomit.
So my advice for new folks is find things that you’re interested in, that you’re passionate about, that excite you, and go find people that have that similar interest. You’ll do better work when it’s focused on things that spark joy for you. And then secondly, once you find your people, so to speak, you find your community, whatever the type of specific nuance you’re interested in, whether it’s GRC or application security or risk management, talk to people.
Find someone that is a mentor or a role model. Reach out to them and engage with them. It’s been my experience that people within both open source and cybersecurity, they like to talk and they like to talk about themselves and share their experiences. And it might be intimidating. You might think of someone as an air quotes rock star that they’re superhuman, but they’re not. They’re just people just like you. And they like to share their experiences.
And I have personally benefited from having a long trail of mentors in this space where people have been incredibly generous with their time and helped teach me concepts that I was unfamiliar with, or I was able to, you know, in reverse, I helped mentor a lot of people as well. I also work with an organization called ISC2, and I’m a certified cybersecurity person. And part of our code of ethics, part of the idea behind those certifications is improving the trade. So, my contribution to that is helping groom the next generation of folks.
So, I feel obliged to do this and many people in my space do. So again, find people that you look up to, talk to them, have them share their experiences and you’ll learn more over coffee or an adult beverage than you ever will from a book or classroom.
Omkhar Arasaratnam (18:08)
Some sage wisdom and for what it’s worth, CRob, I consider you to be one of our rock stars.
CRob (18:13)
Aww, thank you.
Omkhar Arasaratnam (18:14)
Last question. What’s your call to action for our listeners?
CRob (18:18)
I talk a lot at cybersecurity conferences and every time it’s generally about open source security and every presentation I have a similar slide where I say, chances are very good, 90 to 98% that you’re using open source software. Why aren’t you contributing back? And contribution isn’t necessarily development or money.
But show up to those communities, give those communities feedback, help them out with some docs, take some notes in a meeting, just participate in the conversation. Be that sounding board as a developer’s testing out new features. If you have the skill set and you are a development person, contribute some patches, fix some bugs, look at their backlog.
And that is a huge help to a project. Somebody comes in and either provides them feedback or helps them work on their backlog. And that’s the best way that you get a lot of value from this free software. It’s just simple, easy ways to get back.
Omkhar Arasaratnam (19:18)
Patches are welcome.
CRob (19:19)
Patches are always welcome.
Omkhar Arasaratnam (19:21)
CRob, thank you for joining us today on What’s in the SOSS? It’s my pleasure that you’re going to be joining us as co-host. So I’m really looking forward to hearing your episodes as well. And yeah, thanks for all the support and all that you do for the community.
CRob (19:34)
Very welcome. I’m looking forward to it. Thank you.
Announcer (19:37)
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?