CRob 0:22
Welcome, welcome. Welcome to What’s in the SOSS, the OpenSSF podcast, where I get to talk to some of those amazing people on the planet that are helping secure the open source software we all know we all use every day and that we love today, I have some very special friends with us that are doing the yeoman’s work trying to help work with projects to help improve their security posture. I have Amir and Derek from OSTIF. Can I give you guys just a brief moment to introduce yourselves?
Derek Zimmer: 0:54
Sure, I’m Derek Zimmer, founder of OSTIF. We’ve been doing this for 10 years now and take it away. Amir.
Amir Montezary: 1:04
Thank you. Amir Montezary, Managing Director of OSTIF, open source technology improvement fund, yeah, absolutely thrilled to be here on the podcast and to be talking with you, CRob, and to be talking about the work that we do. As Derek mentioned, this is our 10 year anniversary. So coming up on 10 years of really developing this organization, the processes and really fine tuning to a degree what we do and the value that we provide to the open source ecosystem. So absolutely thrilled to be here and to talk about it.
CRob 1:40
That’s amazing. So happy birthday OSTIF, for our audience that might not be familiar directly with your work. Could you maybe tell it? Tell us what OSTIF is, and what do you all do?
Derek 1:53
Sure. So we founded the organization 10 years ago on the idea that we needed a maintainer centric organization that could bring security resources to projects. There were some efforts in the past to do something similar to what we do, but most of the time, those were very corporate centric. So the ideas that circulated around them were very were dictating what open source should be doing and not we’re here to help. And here’s some resources so that that different perspective was the the kickoff for why we wanted to create something different.
Amir 2:36
Yeah, absolutely. And and still today we see that open source projects, because of their very nature, you know, they need a very strong, independent body to to help them. We provide that platform, being a nonprofit organization, being vendor neutral, being neutral in all senses of the word, and just solely focused on, as Derek mentioned, helping projects, getting them the security resources that they need, and in a way, most importantly, being able to provide those resources in a way that directly impacts the project and its security posture was really what drove us to start this organization. You know, typically, open source developers, maintainers, are not security experts, and that’s okay. Security is a very difficult topic, and like, like a lot of other things, it’s best to be left to the experts. So while, of course, there are things individual developers and maintainers can do to, you know, improve their their hygiene, so to speak, and improve the security posture of their projects, we found that getting independent third party expert audit review in a way that is again meant to be collaborative, as in, these auditors work with the maintainers, as opposed to kind of dictating to maintainers or telling them, you know, things to do, work with them on improving, kind of the holistic security posture of their project, and we found that to be really successful. A lot of research suggests that this is a very good practice to do. I come from a background in it, auditing, reviewing critical payment systems in the United States. That is a great field, and that we saw that that level of independent review, or third party review, that kind of due diligence, really helps improve the the state or posture of a software project. So so it was really. Founded on the need for it to exist. We saw there was a big need for this, that a mechanism to get security help, to open source projects, working directly with maintainers, and doing it in a way that is inclusive and impactful and most importantly, efficient, is kind of what drove us to do what we do, and so in terms of kind of how we do that, it’s largely a lot of just relationship management. So we’ve in the last 10 years, built a really vast network of security experts, researchers, a lot of which are solely focused in the open source security space, so they kind of understand some of the idiosyncrasies involved in open source software, and can, again, can actually provide meaningful review work and collaboration and essentially handle that whole process, because there are quite a lot of moving parts between. You know, typically you have a separate body funding the work, you have the maintainers or contributor base that could be very much distributed around the world. You don’t always have, I guess, established kind of decision making structures, as you might see in a corporate setting or in a more commercial environment. So we kind of handle all of that, all of that goodwill building, relationship building, project management, contract management, basically all of the pieces so that all that, all that’s needed for a funder, for example, someone who wants to fund security outcomes, or the project you know that would like to improve their security posture, they can just focus on that, and we, as an organization, as an independent body, essentially handle all of the all of the minutia and the administrivia and the facilitation and management to make it, to make it a very streamlined and efficient process. So that’s kind of high level overview.
CRob 7:23
As you both are aware, you have been long time participants and partners with our foundation and also our friends over at Alpha-Omega. From your perspective, kind of with your 10 years of working in this particular space. What do you all see as the main value that projects get out of these types of engagements?
Derek 7:47
So actually, this has changed over time, because we started out experimentally trying things just to see what works and what doesn’t. Initially, we started out as a bug bounty organization. So our concept was that companies would donate money to us, we’d establish bug bounties for projects, and then those projects would get the security benefits. What we quickly found out was this does not work well for projects that don’t have a lot of security resources, because they get buried in bunk reports things that are not actually problems. And then there’s also the bag bounties, where some dependency has a vulnerability, and then someone will go shop around to every project that depends on that dependency and try to get a bug bounty out of it and and so on and so forth. And then, increasingly, AI is also becoming a problem because it is doing automated reports to maintainers which are not accurate and then have to be thrown away, and they can be done at a much greater pace than an individual could just a few years ago. So essentially, we, we abandoned that entire thing and went to the idea of having professionals come in, give all of the support that they can give to the project, and kind of meet them where they are, and then extend their their testing so that they get long term benefit from the review as well. So So it started out with skin in our knees and finding stuff that didn’t really work, and then progressed over time, after a lot of feedback to where we are now, which seems to be extremely helpful.
Amir 09:34
So yeah, and to echo that, I would say, I would say the main value of our engagements is that direct impact. You know, we go directly to the project, to the main work with the maintainers or contributors of a project, actually going to the source. You know, the source as in reviewing and improving the code of a project. Project its design, and as Derek mentioned, one way we’ve added even more value as part of our engagements over time is creating or augmenting tooling for projects as well, so that they can continue to have security scrutiny and tools that can help them in their development cycles and to help projects mature. So I would say that that direct focus on the projects, on their code base and on the on the tried and true practice of a expert third party review is how we’re really delivering a lot of value. I would say through our engagements, we’re coming up, as I mentioned on our on our 10 year anniversary next month, and I think we have found well over 100 high or critical vulnerabilities and these projects as parts of our as part of our audits. Thank you. Thank you. We’re really we’re really proud of what we’ve been able to do and the positive impact we’ve been able to make. And yeah, and I think that really comes from sticking to our mission and to our commitment to this best practice of, you know, expert third party review, but doing it in a way that is collaborative and impactful. So so we didn’t just find all of those, those vulnerabilities, those have all been fixed and remediated, and a lot of those, at least a good portion of them were kind of design bugs or or classes of bugs that very well, you know, could eliminate future problems very effectively, not in a, unfortunately, not in a very Easily, easy to measure way, but, but the feedback suggests that the projects are, in fact, much in a much better state after our engagements. So we’re really happy to be able to do that.
CRob 12:15
That’s phenomenal. I love the fact that you all started off in one direction, and then you learned a little bit, and you’ve pivoted so you’ve evolved yourselves. Thinking about your engagements over the last almost decade, is there one thing you wish a project or a developer knew or did prior to coming into one of these engagements that would make the whole enterprise be more successful or go more smoothly. What was one thing you wish people did or knew?
Derek 12:46
So the big takeaway is that if you do a security engagement with us, it’s not scary, because we are here to help. We will offer you any support and resources that we have. You know we’re not going to find a big pile of bugs that you don’t understand, dump a document on you and walk away. The whole point of this is to help projects improve by giving them everything that they need and meeting them where they are. So the FAQ we usually get from maintainers is, you know, how long is this going to take? How much time do I have to invest into this? And then always the questions about, are you going to drop zero days on me at the end of this engagement? And of course, we follow disclosure policies that everybody agrees on and also we are very flexible. So if there’s a design level problem that requires a big rewrite, we’re not going to just drop it on the internet in 90 days. We’re going to be forgiving. So the pressure from us is very low, and I think that that’s one thing that maintainers would really like to hear from, you know, working with us.
Amir 14:07
yeah, plus one to that, Derek, I would say it’s very not meant to be a collaboration. It’s meant to be a engagement that is collaborative in nature. And I, I do wish more developers knew that it wasn’t as again, to echo you Derek, it’s not, it’s not a scary thing. It’s not you’re like, you’re going to be going in front of a tribunal, and you know, it’s very much, let’s work together to make this project better. And I’ve, I’ve I’ve observed personally that it’s one of those types of things where the more you put in, so the more that developers, maintainers, contributors, the more that they’re able to put into the engagement, in terms of providing audit teams with in. Site or with feedback or context, because I think that’s the piece that really is missing significantly with a lot of the, as Derek mentioned, kind of the tooling and some of the other kind of at scale things that at scale solutions, they really lack that context that is really important, especially in terms of security, when it comes to security in a code base, so it definitely has a multiplier effect. You know, the more we’ve seen projects being engaged in the audit, typically, we found much better results. And I can even give a direct case study example, where one an engagement that we were involved in. The audit team and the developer team happened to be our train ride apart, so they were able to arrange, essentially, an in person kind of orientation, kind of to really just discuss and get to know each other and gets in, you know, it was a really cool thing, and we learned that that led to a much better understanding of the code base as the team was auditing it, and that allowed them to find more significant findings, because, again, they had that greater understanding as a result of the context provided By the by the team and and, and actually that that same team that we worked with on this direct engagement yesterday at one of our virtual meetups, we learned that they did something similar. So their client wasn’t as was a quick it was a flight. But flights in Europe are shorter just and they were able to get together with the with the main maintainers of the project, and do, again, a very similar thing, where they were able to get together discuss, and that led to a much better understanding of the project, and allowed the auditors to add that much more value as part of the audit. So I to sum it up, I would say, as I said, add value. That’s I would that’s how I would sum it up. Is that I wish more developers knew that this is about adding value. It’s about collaborating. It’s not about, you know, making you feel bad about making mistakes or anything like that. You know, human beings will always, will always, you know, will always have that, that, you know, human error, and it’s totally normal and fine. And that’s why this as a practice is so important, because, you know, it’s such a common practice in software and really in the in the greater kind of landscape, you know, independent review. And so, yeah, I would say, you know, it’s meant to be collaborative. It’s not the scary thing. It’s really more about, as Derek said, helping and giving you resources to make your project better than anything else.
CRob 17:53
That’s amazing, and I really appreciate just kind of the innovative ideas and the coming to where the project is mentality and really you guys are making sure that security audits aren’t scary at all. But let’s move on to the rapid fire part of the interview. Are you ready for rapid rapid rapid fire? Got a couple wacky questions. Just give me the first thoughts to come out of your mouths, vi or Emacs?
Derek 18:22
oh, VI
Amir 18:25
yeah. Second that excellent.
CRob 18:26
There are no wrong answers, but there are better answers than others, right? What’s your favorite open source mascot?
Derek 18:36
Oh, I’d have to say the VLC cone. Nice, just because it’s nonsense, and they admit that it’s nonsense, and they constantly get asked about it and give nonsense answers. So it’s fantastic.
Amir 18:51
That’s a good point. And you can always tell who the VLC people are at, like FOSDEM, for example, because they have the big, the big cone on the head. And that’s a really good question. There’s a lot of really good ones out there. I’ve honestly found that the this the simpler ones mascots are, I tend to remember them more, but there’s, I’d say, for me, there’s too many good ones to pick so…
CRob 19:16
That’s a very diplomatic answer. I appreciate that. Spicy or mild food?
Derek 19:22
spicy all the way
CRob 19:28
nice, that is always the right answer.
Amir 19:30
Some of our greatest ideas came over spicy food. So…
CRob 19:35
And finally, and most importantly, Star Trek, or Star Wars.
Derek 19:40
So I’d say I’m Star Trek. I I like the idea of everybody working together toward, you know, a peaceful, wide, reaching society,
CRob 19:52
Open source of you. That’s awesome.
Amir 19:54
I would also say Star Trek. I missed the Star Wars kind of lore growing up, yeah, my experience with Star Wars, I had a high school teacher who, anytime he would not be able to make class, instead of a substitute teacher, he would just play the beginning of the first Star Wars movie. I think it was episode four, so I’ve seen the first 30 minutes plenty of times. So maybe that left a bad taste in my mouth with Star Wars.
CRob 20:27
I see we’ve had very different life experiences. That’s great. Well, thank you, gentlemen. I really appreciate you putting up with the nonsense. And then finally, as we wrap up, do you have a call to action for the community or developers, as we kind of close out
Derek 20:45
Sure, I would say we really operate on the principles of Spoon Theory. Have you ever heard of that? It’s from psychology. And the principle is that you have so many spoons of energy that you can devote to various things, and the way that we apply this to open source is thinking about the security knowledge and the just general energy available among open source communities. Some of them are very well supported. They have dedicated staff that are paid, and it’s their job to be there and be available. And then you have the complete opposite end of the spectrum, which is a solar solo maintainer invented a thing. That thing somehow became a really important piece of infrastructure. They don’t have any security knowledge, so they do what they can, you know, reading documents and and whatever, but they don’t have the available energy to invest in security so that that’s where I’m coming from. When I say, meet projects, where they are, and the call to action would be, if you are a security researcher and you’re interacting with open source, this is what you need to consider is their position on that spectrum of knowledge and available energy. So…
CRob 22:09
Amir?
Amir 22:10
Yeah, plus one to that, and to add, I would just say that if there’s one thing I’ve learned, you know, from doing this for 10 years, it’s that. It’s it’s important work, and it needs there. There’s almost an unlimited demand for it. You know, I was really shocked when I saw how some of the you know, projects, biggest names and open source projects, household names that we hear every day, really needed almost the same, if not more, security help than maybe the smaller projects, because, for example, some of the really big projects, because they have so much more scrutiny, they have a lot more noise to go through, for example, or they have, they could potentially have huge backlogs of bugs that they just haven’t gotten the time or resources to go through. And so I think my call to action would be, you know, we are one of the one tool in the in the toolkit, but I do think what we do really does help open source projects and we can do more with more. So we always are typically trying to do the most we can with what we have and which we always do, of course, but I think we really could do more with more so we can add more more help for projects, more diligence for projects, more ongoing support for projects. The work that we’ve been doing, doing tooling, augmentations, for example, has been really successful. And, you know, we, and we as a small organization, we are always happy and willing to take on more work. So we’re always open to new collaborations, new collaborate tours and helping how we can to fulfill our mission, which has been to help open source projects improve their security. So yeah, come talk to us. We’re involved in a lot of the open source security foundation working groups and events. As you mentioned, we’ve been strategic partner for Linux Foundation and OpenSSF for some time now. So yeah, we are always happy to collaborate and help how we can in the nature of open source. And so I’d say that’s that’s all I have. All right,
CRob 24:38
Derek and Amir from OSTIF, thank you all for your amazing work and helping collaborate with our developer community, and that’s going to be a wrap. Happy open sourcing, everybody. We’ll talk to you all soon. Goodbye.
Amir
Cheers, everyone. Thanks.
Outro
Like what you’re hearing. Be sure to subscribe to What’s in the SOSS on Spotify, Apple podcasts and Antenna, 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 all. 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.
For nearly 20 years, Daniel has worked as a software engineer in the Defense and Aerospace industry. His experience ranges from embedded device drivers to large logistics and information systems. In recent years, he has focused on helping legacy programs adopt modern DevOps practices. Daniel works with the open source community as part of Lockheed Martin’s Open Source Program Office.