Skip to main content
Monthly Archives

August 2024

What’s in the SOSS? Podcast #12 – CISA’s Aeva Black and the Public Sector View of Open Source Security

By Podcast

Summary

In this episode, Omkhar Arasaratnam visits with Aeva Black, who currently serves as the Section Chief for Open Source Security at CISA, and is an open source hacker and international public speaker with 25 years of experience building open source software projects at large technology companies.

She previously led open source security strategy within the Microsoft Azure Office of the CTO, and served on the OpenSSF Technical Advisory Committee, the OpenStack Technical Committee, and the Kubernetes Code of Conduct Committee. In her spare time, Aeva enjoys riding motorcycles up and down the west coast.

Conversation Highlights

  • 01:37- Aeva describes a day in the life at CISA
  • 02:38 – Details on the use of open source in the public sector
  • 04:27 – Why open source needs corporate investment to maintain security
  • 06:20 – Aeva shares what their second year at CISA looks like
  • 07:58 – Aeva answers Omkhar’s rapid-fire questions
  • 09:28 – Advice for people entering the world of security
  • 10:16 – Certs are nice to have, but they aren’t everything
  • 10:42 – Aeva’s call to action for listeners

Transcript

Aeva Black soundbite (00:01)
The burden of securing open source — its ongoing maintenance, its testing, quality assurance, getting signing —  to make open source continue to be deserving of the trust we’ve all placed in it that can’t rest solely on unfunded volunteers. Companies have to participate, shoulder up and help.

Omkhar Arasaratnam (00:19)
Welcome to What’s in the SOSS? I’m your host Omkhar Arasaratnam. I am the general manager of the OpenSSF. And today we have my good friend Aeva Black joining us. Hi Aeva!

Aeva Black (00:32)
Hi, Omkhar, thanks so much for having me on today.

Omkhar Arasaratnam (00:34)
It’s a pleasure. Now, to start things off, why don’t you tell our listeners a little bit about your title and what you do?

Aeva Black (00:43)
Sure. So my official title is Section Chief for Open Source Security. Sounds kind of anime. I like it. I’m also a technical advisor here at CISA, the US Cybersecurity and Infrastructure Security Agency. We’re so enthusiastic about security, put it in our name twice. What I do day to day is just kind of work on solving open source security problems that I have been working on before, but now on this end of the fence.

Omkhar Arasaratnam (01:10)
Well, as I think I’ve told you in the past, my son is a huge anime fan. I literally had to bring a check bag back with me from Tokyo with all the various paraphernalia. But aside from indulging in my excitement about hearing CISA titles associated with anime, can you tell us a little bit more about the day-to-day? I mean, Section Chief sounds like a pretty cool role and you have been involved in the community for a while. What’s your day to day look like Aeva?

Aeva Black (01:37)
Honestly, you know, my previous careers, I often wrote code these days. Day-to-day looks more like answering emails, hopping on meetings, whether they’re internal meetings or interagency meetings, meetings with the open source communityies, but it’s a lot of talking and writing and speaking in public.

Omkhar Arasaratnam
When you announced new role at CISA and that you’d be joining CISA —  I think it was late last summer, I think about August, if memory serves — I was incredibly excited because I’ve seen CISA over the years take a stronger, better, more supportive approach when it comes to open source software. And I was really excited to see somebody like you that has had such a long history of open source support and advocacy join CISA. Can you talk to me about what it looks like on the inside, as everybody’s sitting back with their developer keyboard, clickety clacking, doing git commits all day? Has, has the government evolved into pure open source? How’s that going?

Aeva Black (02:38)
You and our listeners might be surprised to realize just how much both federal and state governments have always used open source. Our, our friend Deb Bryant — she’s been around, used to be at Red Hat, helped out in the open source initiative — used to actually run the open source programs office for the state of Oregon more than 10 years ago. So I think what it looks like today in CISA is pretty much what it has looked like. There’s more clearance, there’s more coverage, should we say, for folks who want to contribute to open source as part of their day job.

We’ve seen that get written down in sort of a guidance way, both in the DoD CIO’s memo a couple years ago, the DHS CIO memo for all DHS agencies includes groups like Coast Guard to use more open source, to contribute to open source, to be good participants in the community. So we’re seeing certainly more support for that. But again, folks across government have always used open sourcing. My first moment of realizing that, probably 2008, I saw some folks from the US Navy give a talk on using MySQL in a cluster running in their ships for battlefield awareness. It was the best database they could find at the time for what they needed. So it’s really nothing new.

Omkhar Arasaratnam (04:00)
Thanks for letting us know. I hadn’t realized that. And it’s very encouraging to hear that not only are we seeing broad adoption of open source within private sector, but also within the public sector. Now, security is a really important mission with a near infinite problem space, especially when it comes to open source security. You’ve been doing this for a while, where should we start? Because it seems like we could start just about anywhere and still have a life’s work ahead of us.

Aeva Black (04:27)
Yeah. Like you said, I’ve been doing this a while since the late 90s, and really as part of my job since the early 2000s. What hasn’t changed: the breadth and the diversity of open source communities is our strength, it is global participation in these communities. And so for today, in light of some of the recent threats against open source, and the pretty big compromises or vulnerabilities in open source that have affected products, we still need to recognize that open source is maintained mostly by volunteers in a participatory community-driven approach.

And yes, of course, companies have a big role to play too. But money isn’t always the solution, but research and common sense have shown that it usually is part of the solution. The burden of securing open source, its ongoing maintenance, its testing, quality assurance, getting signing all of those sorts of activities to make open source continue to be deserving of the trust we’ve all placed in it, that can’t rest solely on unfunded volunteers. Companies have to participate, shoulder up and help. that the transparency in open source, the promise that anyone can modify and study the source code, that transparency has to also be sort of dialed up for the amount of code that’s out there today. There’s so much more code than there used to be in open source, and the ratio of number of humans reviewing code to amount of code published has changed. That increases the risk a bit.

Omkhar Arasaratnam (05:57)
That’s some great advice as to where to start. Now we can slowly see over the horizon, the holiday season fast approaching. I know I’m, you’ve certainly had some great accomplishments. We’ve had some great shared work that we’ve done together. As you look to your second year in your role, what are your priorities? What’s in front of you and what would you like us to focus on?

Aeva Black (06:20)
Yeah, for myself and my team here at CISA, I’ll share that I knew things would be different in the public sector. It’s my first time in a public sector role. Hiring in any role is never as fast as we want it to be. We find a great candidate and the machinery of the organization, private sector or public sector, it’s always slower than we wish. So one of my priorities is continuing to grow my team and to bring more knowledge about open source and from the open source community into roles in the public sector, not just in my team, right, but across the agency and supporting other teams that don’t yet have as much knowledge about open source. Right? So a lot of internal awareness and training in terms of outward work. There’s been a lot that I find really encouraging with groups like FreeBSD’s attestation to the NIST secure software development framework.

A year ago, I had thought that there was no way to make the SSDF work for open source. And I was proven wrong and I’m delighted by that. And now I’m seeing a number of additional foundations and projects working towards a similar goal with their community and their funders working together to raise the bar on how and what secure assurances can be made about the process by which community-stewarded open source is developed. It’s not interesting who’s writing it, but how is it written? How is it tested? How is it assured? I’m really encouraged to see more of that and look forward to partnering with folks, including the OpenSSF towards more of that.

Omkhar Arasaratnam (07:58)
And we look forward to working with you, Aeva. So now is the time in the podcast in which we move to the rapid-fire section. I’m going to prompt you with a couple of different answers. There’s always a possibility that I’ve missed something, and you give me what you’d prefer your answer to be. Now I feel like I have some insight to the first question because we’ve eaten together several times,

Aeva Black (08:23)
That we have!

Omkhar Arasaratnam (8:24)
But spicy versus mild food, Aeva?

Aeva Black (08:27)
It depends if it’s Indian food, spicy, if it’s Mexican medium to mild.

Omkhar Arasaratnam (08:32)
And if it’s sushi, mild.

Aeva Black (08:34)
I mean, jalapenos on sushi can be really good.

Omkhar Arasaratnam (08:37)
Hmm. Yes. Yes, I agree. I take that back. Fair enough. Or a nice spicy salmon roll, perhaps.

Aeva Black (08:45)
True. Yeah.

Omkhar Arasaratnam (08:47)
Alright. Text editor of choice: Vi,  VS code, Emacs?

Aeva Black (08:52)
Easy, easy. Vim. I’ve always used Vim. I have my system set up, put me in Emacs, I usually have to shell, like use a different shell to kill it because I get stuck.

Omkhar Arasaratnam (09:00)
(Laughter) Well, I mean, Emacs is an operating system on its own, to be fair. (Laughter)

Aeva Black (09:04)
Yeah, just not one that I’m comfortable in.

Omkhar Arasaratnam (09:06)
I am also a Vim person, so shared, shared joy there. Tabs are spaces?

Aeva Black (09:13)
Spaces.

Omkhar Arasaratnam (09:14)
I knew it. Awesome. All right, Aeva, we’re wrapping up now. So in closing out, I have two final questions. The first one, what advice do you have for somebody entering our field today?

Aeva Black (09:28)
I wish I had an entire podcast on just this one, but really find your hyper-focus. For a lot of us, we can get stuck on things. Figuring out how to get stuck on the things that were good for my career helped me out early on. And building a T-shaped set of knowledge, so go deep first. Once you’ve gone as far as you want to go, then do it again on a different topic, and that builds breadth over time. Certs are nice to have to get past resume filters, but your network is everything. Maintain relationships across jobs. That’s the second big piece of advice I’d give.

Omkhar Arasaratnam (10:05)
I’ll let you in on a secret. I think the last cert that I got was as a Red Hat certified engineer in 2002. Do you want to share with the audience what last cert you got, if any?

Aeva Black (10:16)
It’s the if any part. Yeah. (Laughter) I considered a couple of certs back in the old MySQL days, early career. I never bothered with the Linux certs or the networking certs because I’ve just logged into a system and show that I knew my stuff.

Omkhar Arasaratnam (10:35)
Absolutely agree. Last question, Aeva. What’s your call to action for our listeners?

Aeva Black (10:42)
Well, for the listeners that are or work at a company, be a responsible consumer of open source. And that means participating in the project so you have insight. It means vetting the code and staging it appropriately locally. If you’re not a large corporation, but a member of a community, then my advice is make sure you’re building your community with stable governance and documented norms so that companies can understand how to work with you and that you behave as a group of a community in a predictable way. Predictable release cycles, predictable vulnerability management, all of those sorts of activities as an open source developer help to grow the project. And leave breadcrumbs, leave gaps for new contributors to fill and make sure you’re passing down the ladder to the next generation of contributors.

Omkhar Arasaratnam (11:38)
Excellent advice as always. Aeva Black, thank you so much for joining us on What’s in the SOSS?

Aeva Black (11:43)
Thanks so much for having me, Omkhar. See you around.

Announcer (11:46)
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 slash get involved. We’ll talk to you next time on What’s in the SOSS?

What’s in the SOSS? Podcast #11 – Google’s Andrew Pollock and Addressing Open Source Vulnerabilities

By Podcast

Summary

Andrew Pollock is a Senior Software Engineer at Google, currently working on https://osv.dev. With a background as an Enterprise Security Engineer, he has extensive experience in large-scale Linux Systems Administration and GCP Security. Andrew is passionate about the human factors in security, focusing on scalable solutions, great user experiences and self-service opportunities. He has primarily worked in Linux/Unix environments as a Site Reliability Engineer or Security Engineer, with a strong interest in process improvement and automation.

Conversation Highlights

  • 00:52 – Andrew shares his background as a “mid-90s data nerd”
  • 02:31 – Managing vulnerabilities in the open source ecosystem
  • 03:57 – How to navigate inconsistent metadata
  • 06:26 – The challenge of source attribution
  • 07:54 – The rapid-fire round
  • 09:15 – Andrew’s advice to open source developers
  • 10:22 – Andrew’s call to action to developers

Transcript

Andrew Pollock soundbite (00:01)
The beautiful thing about open source is it’s open to all, it’s accessible. You can play around with things, you can break it, you can fix it. It’s fairly approachable. Most of the larger projects have vibrant communities around them that are fairly welcoming and inclusive. 

CRob (00:18)
Hello everybody, I’m CRob. I do security stuff on the internet and I also am a community leader within the OpenSSF, the Open Source Security Foundation. One of the really cool things I get to do as part of the OpenSSF is to host What’s in the SOSS?  where I talk to amazing people from across the open source ecosystem. And today I have my friend Andrew Pollack from Google. G’day, sir.

Andrew Pollock (00:41)
G’day, CRob, how you doing?

CRob (00:43)
I’m doing wonderful. Thank you for asking. Andrew, could you maybe give the audience a little bit of your backstory, your origin? How did you get into open source and what are you doing today?

Andrew Pollock (00:52)
Yeah, so I’m a computer nerd of the mid-90s. I grew up in the MS-DOS era and out of high school, I started studying an information technology degree at uni and I was also working as a mainframe operator at the Brisbane City Council where I also encountered Unix and found Linux in its early existence to be just way cooler than DOS. My Linux distro of choice was Debian and I quite enjoyed using Debian and aspired to become part of that project, and so I joined Debian in the early noughties. I became a Debian developer and started participating in the Debian project proper. And that was sort of my ground level sort of involvement with open source. And I’m still a Debian project member today, but nowhere near as active as I would like to be.

CRob (01:47)
And what are you doing today within the open source ecosystem?

Andrew Pollock (01:50)
Today I work on OSV, which is a couple of different things, right? So the part that intersects with the OpenSSF is the OSV schema. And the part that I more actively work on is osv.dev, which is an open source implementation of a database using the OSV schema to aggregate and enrich those records.

CRob (02:16)
Very nice. Well, I know amongst other things, you’re a big data guy. So let’s talk about vulnerability data and why it’s important. Could you maybe explain some of the key kind of data points that we need to effectively manage vulnerabilities in this wacky ecosystem?

Andrew Pollock (02:31)
Yeah, you know, this is all about the data. So I really enjoy looking at the data in aggregate form and zooming out and looking at challenges with using that in bulk. So OSV provides vulnerability information about software packages at the source code level predominantly and it also provides Linux package of vulnerability information as well. 

And the thing that we need to be able to convey that information accurately is a good package name and good version information because we want to address the use case of vulnerability scanning, first and foremost, and then vulnerability remediation for things that are detected. So step one, to be able to identify what’s vulnerable, you need to know, you need to have a package name that’s meaningful within the ecosystem that you’re sort of wanting to operate on. And then you need to, at a minimum, know what version you need to be beyond to not be impacted by the vulnerability.

CRob (03:43)
I bet you see, let’s call it mildly, some inconsistencies across our amazing ecosystem. Could you maybe speak to some of the challenges that you see within vulnerability metadata today?

Andrew Pollock (03:57)
OSVs got multiple different data sources today, and a lot of them come from language ecosystems, which have some sort of curation within themselves so they’re fairly internally consistent with their packages because they know their own sort of backyard. Where I started looking more broadly was the problem space of C and C++ software, which doesn’t sort of have a centralized repository of vulnerability information. So we had to look at the CVE space for that, and we started pulling CVEs from the NVD to try and figure out which ones of them related to software that was not being covered by OSV-native vulnerability information.

And that’s where — me as a data nerd — just lost my mind because things were very, very inconsistent. So the challenges in that space are around naming. As I said, knowing what the package is to be able to identify it and, to a lesser degree, versioning as well because there’s no consistent versioning scheme when you go from one random open source project to another. And not all open source projects even follow any particular release practice or versioning scheme. So you don’t know anything about a string that is being called a version.

CRob (05:31)
Can you maybe just give us some insight to how you might try to handle some of those problems?

Andrew Pollock (05:35)
I would obviously advocate for projects as part of their maturation process to adopt release management practices that would include things like a formal versioning scheme. SemVer is the one that immediately springs to mind. It’s a standardized format. You can make some pretty clear assumptions about how that one walks and talks. Calva is another one that I know of. So that’s really, really helpful for reasoning about a project.

CRob (06:08)
So can you maybe talk to — you and the others in the OSP project — what you’re attempting to solve within the open source ecosystem? You know, how do you find these authoritative sources? Like how do you know what the right source is to try to make some of these attributions?

Andrew Pollock (06:26)
For the more formalized languages, we don’t have to find the source. The source sort of defines itself, right? So for your Pythons and your Gos and your Rusts and those sorts of things, they have a curated data source and they’ve chosen to supply that data natively in the OSD format and that’s great, right? So where we’re having to do that synthesis ourselves is where things get trickier. And so the challenge that we have is firstly determining what is the authoritative source for a particular piece of software. So that’s sort of 90% of the time that’s attributing it back to a GitHub repo. And then figuring out what the versions are in that repo. 

So we’ve got a real mix where there’s somebody in the business of providing accurate authoritative data, and then one where we’re having to do some inferences about it ourselves. And for the ones where we’re doing the inferences ourselves, we just have to look at the existing vulnerability data that’s available to us, so the CPE records and other data sources like the NVD CPE dictionary and look for hints as to what the what the repository might be. And that’s either metadata in the CPE dictionary or metadata on the CPE itself. So reference URLs typically.

CRob (07:54)
Well, I think it’s amazing work that you all are doing for the community. I think it’s very helpful for researchers and downstream and also community members. So I really appreciate it. Let’s move on to the rapid-fire part of our talk today. First off, spicy or  mild food.

Andrew Pollock (08:12)
I’m on the milder end of things. I value my taste buds and my sense of taste, so I don’t like to destroy them by too spicy stuff.

CRob (08:20)
Very nice. What’s your favorite whiskey?

Andrew Pollock (08:23)
Ooh, well funnily enough I just talked about taste bud destruction, but Laphroaig.

CRob (08:29)
Laphroaig. Very nice. Yummy. So being a developer from your background. Vi or Emacs?

Andrew Pollock (08:37)
Oh, Vi all the way.

CRob (08:39)
Yes! Another fan. And finally, tabs or spaces, sir?

Andrew Pollock (08:44)
Uhh, spaces.

CRob (08:46)
Spaces. All right. Any any rationale why?

Andrew Pollock (08:49)
I think I like my consistency, right? And so if you have tabs, you’re at the whims of what the editor’s tab spacing is, whereas if they’re spaces, they’re spaces. It’s unequivocal.

CRob (09:02)
Very nice. Well, and as we wrap up, what advice would you give somebody that’s kind of coming into this space? They want to become a new open source developer or contribute to a project, or they even want to get into cybersecurity. What advice do you have for those folks?

Andrew Pollock (09:15)
Well, my career background is I’m very self-taught, and I’d like to think that that’s still a feasible career path for people today. And the beautiful thing about open source is it’s open to all, it’s accessible. You can tinker with things as a hobbyist, you can tinker with things in your own time, you can play around with things, you can break it, you can fix it. It’s fairly approachable in a sort of incremental way. And most of the larger projects have vibrant communities around them that are fairly welcoming and inclusive. 

And so stay curious, experiment, learn by breaking things and putting them back together, I think that’s a great way of learning. I’m an experiential learner myself, so I think that’s a great way to learn. I think open source is a fabulous sort of ground level way to get involved.

CRob (10:08)
That’s awesome. I think that’s excellent advice for somebody looking to get into this crazy space we all live in. Closing out, do you have any call to action anything you want to try to inspire our listeners to get into or help out with?

Andrew Pollock (10:22)
Yeah, given that I’m spending a lot of time looking at vulnerabilities in the aggregate, my sort of call to action to developers is to think about the bigger picture when you take a dependency in code that you’re writing because that’s normally how known vulnerabilities come into your code that you’re working on. So the OpenSSF has some really awesome best practices guides around evaluating a dependency or a project before you might want to take it on as a dependency. 

And we’ve got some other teams in the Google open source security team that they’re doing a lot of dependency analysis type insights. So it’s very easy to just take a dependency on board to solve a problem. But if you don’t sort of look at the entire graph of dependencies that are behind that sometimes you’re actually sort of taking on quite a liability. So that would be my sort of piece of advice to sort of developing in the open source space is sometimes it might be better off just re implementing some functionality yourself rather than grabbing something that solves the need.

CRob (11:32)
Yeah, that’s unknown that you don’t know who how made it and what’s inside it.

Andrew Pollock (11:37)
Could be an iceberg.

CRob (11:39)
Exactly. Well, Andrew, I really thank you for your time, everything you do for the community, your time today. Thank you all and have a great day.

Announcer (11:47)
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?