In this episode, host Paul Roberts chats with Naveen Srinivasan, an OpenSSF Scorecard Maintainer, about his talk at this year’s RSA Conference on how to better trust open source software. In their conversation, Naveen explains how the OpenSSF Scorecard tool can help developers understand the security posture of open source dependencies.

EPISODE TRANSCRIPT

WHAT PUSHED YOU TO BECOME A MAINTAINER OF THE OPENSSF SCORECARD TOOL? 

NAVEEN SRINIVASAN:
Absolutely. I want to dig back a little bit about the history behind this. Specifically I just don't, I have a fundamental feeling wherein I specifically don't trust stuff. Trust is a problem for me. I usually don't do brew installs on my Mac.

I usually run a Linux box separately. My Mac is just a dumb machine, which runs that. So I saw a blog post from Kim, who's the Chainguard founder, in late 2019, if I'm not wrong. This was during my, almost my winter break. I saw a blog post about how On by Proxy, didn't have this automated way of figuring out the dependency because they just didn't trust their dependency and they wanted an automated way to trust that.

I saw this blog post on Medium from On by Proxy. I'm like, perfect. This is my solution. I was working for a large financial giant back then and we had the same problem. I said, I'm gonna go look at this project, which is Scorecard. And I did my, and during my winter break I said, I'll do my first PR.

And the contributors and the maintenance were amazing. They merged my PR and my winter break I didn't have anything else to do. I kept contributing, contributing. And Jan, first week, Dan Lorenc the CEO of Chainguard he was the, he were the initial contributor. He sent out a message saying, Hey, do you wanna be a maintainer?

And I down, I went the rabbit hole. That's how it started.

CAN YOU EXPLAIN WHAT SECURITY SCORECARD IS?

Absolutely. Security Scorecard gives you a score for any of your open source projects, looks at the best practices and gives score of how they are, how it is, how the particular project is doing. It does about 18 different checks and gives a scoring for all 18 different checks.

So essentially anybody can understand how good the project is, how much they can trust. And all of this is done automatically. There's no human beings involved in doing this. So essentially that's the reason why it scales pretty well. It is free software. It's a hundred percent free.

There's nothing paid for this. There is a GitHub action. There's a client, there's an API. There are multiple things that anybody can utilize to do this.

YOU PRESENTED A TALK AT THIS YEAR’S RSA CONFERENCE WITH GOOGLE’S BRIAN RUSSELL CALLED “HOW DO YOU TRUST OPEN SOURCE SOFTWARE?” TELL US MORE ABOUT IT. 

Absolutely. Brian is product manager from Google, specifically focused on open source software, especially in supply chain security. So Brian and I have been doing this, or have been collaborating and trying to do what's right thing for the Scorecard specifically. Then we decided we are gonna go spread this news across to different industry partners, different people, because people are unaware of that.

So we have been doing this for I think five, six months trying to go to large conferences to talk about this specifically. So essentially the whole idea behind this talk is, how can any individual, any organization build the how you trust to depend on an open source project instead of going blindsided.

It's almost like having your parameter on your cart to say, what speed am I going on? That's a way this will essentially give you some kind of score, which essentially gives you how do you trust something. That's what we are specifically talking about. The GitHub action, the API, all the things with respect to that and teaching people what is software supply chain posture, why software supply chain is critical from that angle to how they can utilize Scorecard and also talk about what is OpenSSF.

We made sure that somebody who, they have just five seconds or 30 seconds, they can get something out of this talk to five minutes, 15 minutes, one plus days.

So essentially we have different things that somebody can walk away with because it's like anything else in life. You initially want to try something than you want to spend more time. And so that's our goal behind the start.

HOW DOES SECURITY SCORECARD FIT INTO THE EXISTING ECOSYSTEM OF TRADITIONAL APP SEC AND SDLC TECHNOLOGIES?

Absolutely. So it is complimentary. It doesn't replace any of those tabs. So essentially, right now, if, given an example, if within an organization, if someone else is building a library, you understand who is that person building a library, what SDLC policies that they're following? What is the provenance of that?

So you. You have trust on this other team who's building the software. But the modern software, as per Linux Foundation, both 70 to 85% of software is using open source. How do you have that trust? How do you build the trust? So wouldn't it be nice to know? The same things that you can do with your sister organization who was trying to build that similar library.

So that's where Scorecard comes in. Scorecard is essentially only complimenting with other tools, but giving you that answer as to how do I trust something? What are the provenance? Giving an example, being the, do these projects have code review? Code review is one of the checks with Scorecard.

So we give scoring from zero to 10, 10 being the best, zero being the least. It always essentially gives an organization points to look at as to, is this critical for me? If it's critical for me, how is this project doing? It's giving insights into what the projects are all about.

TALK A BIT MORE ABOUT WHAT FALLS UNDER THE DANGEROUS WORKFLOW UMBRELLA, AND WHAT SHOULD DEVELOPMENT TEAMS BE DOING TO PAY ATTENTION TO THIS?

So the dangerous workflow, I would compare that to almost like SQL injection. So if you don't take care of a SQL injection, somebody's likely to inject SQL in, could drop your table, could delete records. That is what the dangerous workflow I could compare with. So there's a classic example wherein we can take the workflow that is not secure.

Somebody can commit code in into your pository if you don't, if you don't secure your workflow, because you would've never assumed that would've been possible, and that's what can happen, and you would never be able to figure out that it went into that. That's one of the classic ways of somebody injecting code in.

By just opening just by just not even, you don't even have to merge that PR. Even opening that PR we, if the workflow isn't being set it can commit code into your repository, which is not your intention at all. And this is where if you have proper branch protection. And if you follow the best practice of GitHub action specifically on the dangerous workflow, you avoid this in defense in depth.

So essentially, if something goes wrong, if somebody, if there's another zero date, but your branch protection which should take care of that. And that's the idea behind having those things called out.

FOR DEVELOPMENT TEAMS, WHAT SHOULD THEIR POSITION BE WHEN IT COMES TO USING OPEN SOURCE DEPENDENCIES THAT MAY OR MAY NOT BE MAINTAINED?

I understand specifically on that there could be, they could be using libraries which don't need any updates at all. It could be extremely, teeny tiny library, that does not require any update at all. But what's our Scorecard is trying to do? Scorecard is trying to make it generic.

So essentially we are trying to run this across millions of repositories. So talking with respect to if you trust something and if you know those things don't require any change, the ignition can ignore that check for that repository. But generally if things aren't, it's just like any other yard, if you don't, if you don't take out weeds, if you don't cut your grasses, guess what?

There's gonna be pests coming at home. So that's the same perspective.

HOW BIG OF A PROBLEM ARE SOFTWARE VULNERABILITIES IN COMPARISON TO OTHER SOFTWARE SUPPLY CHAIN RISKS?

Every organization is looking at vulnerabilities. I'm not saying that's been a focus for a long time. It's not something that has been new. But obviously with the open source software, lot more vulnerabilities are being identified and being patched, and that becomes a job for itself for somebody to do that. But,

I'm gonna give an example of Stuxnet being an example. Stuxnet was a classic software supply chain issue where in government, we don't want to name who it was. We didn't want the Iranian government to build nuclear weapons and it was a classic supply chain attack wherein they were able to inject it and because the Iranian government had defense in depth, they secured everything physical, they didn't have anything else.

Nobody could go into that. But with software supply chain attack, we were able to bring down the nuclear buildup in Iran. That's being the example because introducing vulnerability in that is extremely hard. But if they were able to introduce the vulnerability by software supply chain. So essentially that could bring down a nuclear program when some can bring down a nuclear program.

Think about every other organization has to what they have to think about. So essentially, this is not a problem. I'm not here to say that vulnerability is not an issue, but I'm saying also think about it's not the peripherals, it's across the supply chain. That's where the problem is going into.

WHAT’S IN STORE FOR THE FUTURE OF SECURITY SCORECARD?

So up until now we are focusing on GitHub. Now we are also, with the community support, we are focusing on GitLab also, we are trying to move into GitLab. We are trying to say, how can we as OpenSSF Scorecard, go ahead and help, not just GitHub being the primary focus.

We also looking at how we can help GitLab. Another one feature where I'm gonna shout up for myself is we are trying to build up a GitHub action, which specifically gives you a score. Every time you bring a new dependency, it automatically gives you a score as a comment. So essentially it gives you, we are trying to move to the far left.

Essentially, if somebody's bringing a new dependency in or upgrading a dependency, we want to get you a score. So essentially gives you that insight immediately. Coming back to organizations can utilize this using just the API Scorecard provides and should be able to use this. But Scorecard's team is trying to build a GitHub action to specifically solve this.

So these are the kind of things that we are working on to essentially help the problem shift to the far left. The sooner we help people cast these problems, the better decision that they can work on. Another final thing that I also want to talk about is the, Scorecard stream is also trying to build a policy engine.

So essentially cause it's perspective problems or perspectives. So every organization can have different perspective. Scorecard does not want to be in the business of giving perspective. We rather let the teams make that perspective, but we just want to give the data, raw data and let the teams make those perspectives with policy engine to make those decisions.

And that's what we are also trying to work on to do that for the community.

WHAT ADVICE DO YOU HAVE FOR INFOSEC PROFESSIONALS OUT THERE WHO ARE LOOKING TO BROADEN THEIR SPHERE OF REFERENCE AND BRING IN OUTSIDE KNOWLEDGE?

I fundamentally believe books are opportunities to speak with these phenomenally achieved leaders and that's the only way I get to have their time to go get to speak to them. So that's why I fundamentally believe that. And I also, I'm a big fan of Charlie Munger. Charlie Munger's, Fundamental Philosophies figure out all your knowledge only being, using, being rational is the critical point for him.

He said his grandfather taught him specifically being rational. And I learned about Charlie Munger late in my life. Not that I learned it very early and, so that's why I'm trying to be rational. I'm not there. I'm trying to be like anything else in life is trying to be rational.

I realize using books is the only way to be, to have perspective from different individuals because I realize all of us have very strongly opinionated on certain things, which we don't want somebody else coming and telling us. This is not right. But when we read books we are able to understand that.

At least I'm able to, and I specifically I like to buy physical books rather than Kindle books because I get to see them. It's based on my mood, what book I wanna read, and I keep reading different things based on that.

I'm a big believer in mental models, so I like to take shortcuts in my life. And I realize creating mental models have been extremely helpful looking at everything. For example, being using first principles to fundamentally analyze any of the problems had specifically helped me take that knowledge, apply that, do software, and trying to see, is this the first principle?

I read this book many times Of Mental Models by Shane Parrish on Farm Street. There's three books of that, which is really great. And I'm also reading I read many books simultaneously. I get bored, I keep flipping many books.

I'm reading a book called Creators by Adam Grant. Adam Grant is a professor in Wharton, and I recently happened to discover him. And the real funny thing is I just finished halfway out the book and I said, no, I need to re-read it again. I'm starting over to, because I realized I haven't grasped it and I read, I'm rereading it.

Those are a few things I would recommend somebody to start looking at it. But coming back to this one final thing is reading should be enjoyable. So if you don't like reading those subjects, go pick any book that you'll love to read. The reading should not be a chore. It can be fiction, it can be comic.

So reading should be an enjoyable. So take your time, read what you love because you will eventually love to read.