CRob (00:25.07)
Welcome, welcome, welcome to What’s in the SOSS. The OpenSSF podcast where we talk to the amazing people that help make this open source ecosystem for the benefit of everybody. Today we have a real treat: friend of the show Tracy Ragan is here to talk with us about several topics near and dear to her heart. But Tracy before we dive into the exciting technology, can you maybe give us a little bit of information about your open source origin story?
Tracy Ragan
man, which one? When I first started getting involved in open source was the Eclipse Foundation. The Eclipse Foundation was my first foundation in open source and was really the beginning of me understanding what open source was and why it’s important. This was during my Open Mac software days and I think IBM was looking for a woman to be in the room.
To be honest. one of them reached out to me and said, hey, we need somebody technical to add to this board. Would you be interested? And I said, sure. So I went on an honesty of, I always think I was number five or six on the original Eclipse board. I actually even did the help doing the interview and chose Mike as our fearless leader. So I’ve been doing open source for some time, really, and been on these boards for a good part of my career.
CRob
That’s awesome. And it’s like super helpful being able to steer a significant part of the ecosystem through that board membership.
Tracy Ragan (02:07.234)
Yeah, and open source boards are a beast of their own to be quiet on. Because they get so big, and that’s good, but sometimes it can be bad and it can be hard to navigate, but it seems to always work out.
Right.
CRob (02:21.038)
That’s great. So you’ve been doing open source for quite some time and what types of projects are you engaged with more frequently this time right now?
Tracy Ragan
So, you know, I keep my foot in two realms. One foot is in the open source security foundation and the other is in the continuous delivery foundation. I’m a DevOps person. That’s who I am. I have been doing configuration management and whatever you want to call it over the years has gone through so many ridiculous acronyms. But when we really boil it down, it’s still configuration management and getting code from Code to Cloud, let’s just call it that. So I lead an open source project at the Continuous Delivery Foundation called Ortelius, and we’re going to talk a little bit about that. But I also try to keep involved in the open source of the OpenSSF as much as I can. And of course, I get involved in things like the Security Tooling Working Group.
I’m working with Ryan Ware over there too, because that really falls into my area of expertise, right? If it has the word tooling, I’m interested. Because I’m a DevOps person, you know? Is there something I should be adding to my DevOps practice? And then I’ve been involved in DevRel and I’m on the marketing committee and I help lead some of the initiatives at the OpenSSF is working on. But really where my heart is is in between, it sits in between DevOps and open source security. And we can call that DevSecOps if you want, we could all call it DevOSSOps. So that’s what I’ve been working on for the last four years.
CRob (04:21.805)
To go a little bit off script since you opened the door for our audience. Could you maybe explain a little bit more about DevOps and kind of why it’s important for open source communities to have this capability?
Tracy Ragan
So we all have a factory floor that we run. moving code from, if we talk about the software supply chain, let’s just talk about it from that perspective. We are pulling in packages, whether it be an enterprise piece of enterprise code or open source code or something the government’s writing, we pull in these packages, these transitive dependencies that we don’t necessarily understand. We just know we have to have them.
And that’s the way life is. We’ve built this ginormous, I like to call it a Death Star of open source packages and dependencies that we use. We’ve done that over the course of the last 15 years, and we’re not going back. So DevOps, the idea of continuously integrating and continuously deploying code out to end user consumers. We won’t identify what that consumer is. It could be a developer consuming your code, or you could be delivering software to an end user that’s running a mortgage application. When we do that, we have traditionally focused on just being able to execute build and deploy scripts, which is really important.
Gathering the information from the build and deploy scripts is really critical right now in where we are right now in tracking vulnerabilities. Because it shows two things. The build scripts, if we’re doing an SBOM, and please do, shows us the packages we’re consuming. And the deploy script shows where we’re deploying them. So the DevOps, you know, the DevOps pipeline is important, but the data that it generates is critical right now, absolutely critical. So we should all be doing some level of DevOps, but in my mind, we should all be gathering the DevOps information and making it actionable. So we have a lot to do in terms of evolving where we are in the CI, CD world and the continuous delivery foundation and where we believe this kind of technology, how it should evolve.
In my mind right now, we have so many things that we’re working on. AI is chasing us. We have vulnerabilities we’re worrying about. And right now, we haven’t done a whole lot to evolve the DevOps pipeline. So that’s why I talk about it as much as I can. Because that’s where we’re going to find vulnerabilities and fix them. Otherwise, we’re not going to do that.
CRob
Absolutely. And to bridge these two worlds, you recently helped write a blog about our OpenSSF Scorecard, which is a tool that consumers can use to kind of understand the security qualities of software. Could you maybe talk a little bit about your blog and what you were trying to educate folks about?
Tracy Ragan
So we have several really awesome tools at the OpenSSF, one of which is one of the first ones that we came out with. Jamie Thomas kind of spearheaded this called the OpenSSF Scorecard. And what it does is it goes through and it evaluates your repo on certain characteristics.
if I can think about them, dependency management, security configuration, your quality of your code, access control, documentation, if you’re using a CI-CD tool, if you have actions, security practices. And it gives a score for each of those areas to try to define what the… This is the closest we’ll have to compliance in the open source community. Compliance is critical.
Tracy Ragan (08:26.754)
but how do you enforce compliance? But one way is we can evaluate it. So OpenSS Scorecard, I have found to be a very interesting project and as I have pointed out, one of the first of the OpenSSF, which doesn’t mean it was new and it needed extra work. It is about as complete as you can get for doing compliance around open source repos. So…
We at Ortelius, so Ortelius is an open source project incubating at the Continuous Delivery Foundation. We started incubating there before the OpenSSF was formed. And what we do is we gather all that critical DevOps data from the pipeline. Okay, so we like to call us an evidence store. And part of what we gather is the OpenSSF Scorecard.
So if you’re a consumer and you want to know the score of the packages that your application is consuming, Ortelius can provide that information to you. And not only that, what it does is it aggregates. So if you’re working in a decoupled architecture, you’ve got 100 containers that you’re building, and each one of those containers has code, and each one of those containers have an OpenSSF Scorecard, and the packages within them have a scorecard.
We’re aggregating that data up to the logical application level so that you begin seeing what you’re consuming at the time that you consume it. Now there are a lot of tools out there that help manage open source packages. The secure software development framework tells us we should have a repo of the packages that we want to make sure that people are not using and people are the ones that we are approved to be using, but they still need their scorecard. We still need to understand that. And to be quite honest, not every organization out there is using a repo that tracks your open source that you’re using. What can we, you know, the way we looked at the problem was what can we do to, you know, most DevOps engineers don’t have budget.
They have no budget authority. In fact, I’ve seen a t-shirt that says that, no budget authority, right? So what can we do to make open source more secure through open source? Well, OpenSSF scorecard is one of those ways. And one way to see it, because it’s hard to aggregate this information unless you try to dig down to every package and look at their scorecard, is to expose it.
And by exposing it, we are showing people that the packages that they’re consuming, are they trying to be compliant or not? And unfortunately, CRob, most of them are not trying to be compliant yet. And I don’t want to be like, you know, I go to hockey a lot. And one of the things you do at hockey, if you get a penalty, you do shame, shame, shame. But in a way, you know, if you’re looking at Ortelius and you’re seeing all these packages with a zero scorecard value,
We’re kind of exposing it. And I would like to be able to, you know, we could evolve a scorecard to say, you know, let’s highlight the packages that have a seven or a six and above. Because to be quite honest, it’s a test to be able to achieve it. But every single one of those in that test, except for maybe, I think fuzzing can be really, really hard, is totally doable.
And I would encourage any open source community or if you have a package that you’re managing, know, give it a scorecard, go through it. It’s not hard to install. It’s going to start tracking things. But then when you go to have to do all the things that it’s tracking, it’s much more difficult to comply. But we need you to do that at this point in time.
CRob (12:27.64)
So you touched a little bit about your involvement with our DevRel community and it kind of touches into DevOps. Why is DevRel important and how does it help us encourage things like scorecard use?
Well, to be quite honest, I think the person who’s doing the best DevRel right now is Mr. Wheeler with all of his education, right? Education is what we need to do right now. David has done an amazing job of getting his education out on cybersecurity. DevRel has been in OpenSSF for me. It’s been really hard. And one of the reasons is because the tools, this is where I see the disconnect.
The tools that the OpenSSF is creating, and we have created a bunch. There’s SBOM tools. There’s a ton of new open source projects. They need to be consumed by the DevOps professional, because many of them are command line driven. They have to be executed for every workflow, like an SBOM, for example.
But on the flip side, to be quite honest, I talk to DevOps engineers all the time and they haven’t even thought about what it would look like to add a SBOM to the pipeline. We don’t have that big of an adoption of many of the security tools that’s coming out of the OpenSSF and it’s hard to keep track. It’s hard to know what they do. And it’s hard to update DevOps. Jenkins workflows or a CircleCI workflow, whatever tool you’re using, it’s hard to update those workflow files.
Tracy Ragan (14:11.884)
And there’s a lot of them. There’s thousands of them.
So if you’re in a monolithic environment and you want to add an S-bomb to your workflow, that’s fairly easy. But if you’re in a decoupled Kubernetes microservice container environment, you’ve got a lot of work to do to do some simple things like an S-bomb, much less scorecard. So these conversations are really important to the DevOps. We need to educate the DevOps engineer. It’s not necessarily just educating the developer.
We push so much stuff on the developers lap, even though the education that’s coming out of OpenSSF is great. However, we’ve got to do the same thing now for DevOps engineers.
CRob
Absolutely. initiatives like DevRel can help provide that education and give a forum where folks can talk through some of these issues, correct?
Tracy Ragan
Yes, but oftentimes what I have found that in our, in security dev rel, we’re almost, we’re in an echo chamber. So when we talk about security, we get people who are interested in security and they like to talk about SBOMs. It’s probably our favorite thing to do. But the one thing that we’re not doing is getting DevOps engineers to talk about SBOMs and why they’re important.
Tracy Ragan (15:40.524)
So somehow we have to cross the divide and we have to get a handshake between these two organizations. And you know what? It’s not just within the Linux Foundation with the CDF and the OpenSSF. It’s in every single company I have ever spoken to, there is a divide between these two teams.
Tracy Ragan
Well, I look forward to collaborating with you to try to see how we can help adjust that. Let’s move on to the rapid fire part of our interview. Are you ready for rapid rapid fire? Got a couple of wacky questions for you. First off, very contentious. Vi or Emacs.
Yes.
Tracy Ragan (16:12.642)
WRAP
Tracy Ragan (16:24.94)
V.I.
CRob
Excellent. And to be clear, there are no wrong answers. Just some answers are better than others. Like VI.
Tracy Ragan
Yeah, I mean, I wouldn’t even know what to do with anything else except for brief. Remember brief? I used to love brief. wow. Yes.
CRob
Yeah, that’s a blast from the past. Tabs or spaces?
Tracy Ragan
spaces.
CRob (16:51.022)
Very popular answer. What’s your favorite open source mascot?
Tracy Ragan
Well, you know, how could you not love the goose?
CRob
Excellent, and our last question, mild or spicy food?
Tracy Ragan (17:11.937)
You know, when I first moved to New Mexico, I only ate mild food. And now I love spicy. It took me 20 years, but I finally started eating spicy food. So spicy now. That red chili taught me better.
CRob (17:31.49)
Nice. I love green chili. Thank you. And as we wind up for the interview here, do you have a call to action to our audience where they might be able to pick up some of these ideas or participate and collaborate to help move these wonderful projects forward?
Tracy Ragan
You know, I would say if you’re a security professional, to go sit down and talk to a DevOps engineer and really understand how they see the world. And take the time to say, could you show me what it would take to add an SBOM to a single pipeline? And if you’re a DevOps engineer, start taking a look at some of the tooling that’s coming out of the OpenSSF.
The Continuous Delivery Foundation did start a SIG recently called the CI/CD Cybersecurity. And what we’re doing is we’re going through every single, we’re starting with a secure software development framework and we’re going through all the tasks and we’re identifying the task by number that needs to be added to the DevOps workflow. And we’re adding open source tools that you can use to achieve that task. So.
If you’d like to get involved in that as a DevOps engineer and learn more about these things, look up the CD Foundation’s CI/CD Cybersecurity SIG, because it’s becoming an education for all of us to go through that process.
CRob
That sounds amazing. I look forward to checking that out. Tracy, thank you for your time today and thank you for everything you do for developers and DevOps folks and cyber people. We really appreciate all of your contributions to open source and thank you for joining us today.
Tracy Ragan (19:17.08)
Thank you, it’s my pleasure.
CRob
Well, happy open sourcing everybody. That’s a wrap.
Like what you’re hearing? Be sure to subscribe to What’s in the SOSS on Spotify, Apple Podcasts, AntennaPod, Pocket Cast, or wherever you get your podcasts. There’s a lot going on with the OpenSSF and many ways to stay on top of it. Check out the newsletter for open source news, upcoming events, and other happenings. Go to openssf.org/newsletter to subscribe. Connect with us on LinkedIn for the most up-to-date OpenSSF news and insight, and be a part of the OpenSSF community at openssf.org/getinvolved. Thanks for listening, and we’ll talk to you next time on What’s in the SOSS.
The recent Tech Talk, “
Mihai Maruseac is a member of the Google Open Source Security Team (GOSST), working on Supply Chain Security for ML. He is a co-lead on a Secure AI Framework (SAIF) workstream from Google. Under OpenSSF, Mihai chairs the AI/ML working group and the model signing project. Mihai is also a GUAC maintainer. Before joining GOSST, Mihai created the TensorFlow Security team and prior to Google, he worked on adding Differential Privacy to Machine Learning algorithms. Mihai has a PhD in Differential Privacy from UMass Boston.
Daniel Major is a Distinguished Security Architect at NVIDIA, where he provides security leadership in areas such as code signing, device PKI, ML deployments and mobile operating systems. Previously, as Principal Security Architect at BlackBerry, he played a key role in leading the mobile phone division’s transition from BlackBerry 10 OS to Android. When not working, Daniel can be found planning his next travel adventure.
