Supply Chain Security With Jonathan Meadows

“Jonathan Meadows: But over the last sort of four or five years, people are starting to coalesce around particular technologies and approaches. And this is only ramping up with the formation of VRSF, and from some of those working groups. So, I think I'm optimistic about the future, in that we're actually getting together to actually try and build out these capabilities. And really just go back to that. I think that's the only way forward. Making sure that we work together as an industry. This isn't someone goes off and implements something. This is absolutely we need to be working in the open, making sure that we work together to fix this problem.”

[INTRODUCTION]

[00:00:39] ANNOUNCER: Hi. You’re listening to The Secure Developer. It’s part of the DevSecCon community, a platform for developers, operators and security people to share their views and practices on DevSecOps, dev and sec collaboration, cloud security and more. Check out devseccon.com to join the community and find other great resources.

This podcast is sponsored by Snyk. Snyk's developer security platform helps developers build secure applications without slowing down, fixing vulnerabilities in code, open source containers, and infrastructure as code. To learn more visit snyk.io/tsd.

On today's episode, Guy Podjarny, founder of Snyk, talks with Jonathan Meadows, head of cloud cybersecurity engineering at Citibank. Jonathan has an extensive software engineering experience in the financial services industry, coupled with an in-depth knowledge of cybersecurity. He is a keen advocate for DevSecOps culture with a heavy use of threat modeling, co-defined security controls, and automated security testing. He also started the CNCF Financial Services User Group, and ran the recent Kubernetes threat model project. We hope you enjoy their conversation. And don't forget to leave us a review on iTunes, if you enjoyed today's episode.

[INTERVIEW]

[00:02:06] Guy Podjarny: Hello, everyone. Welcome back to The Secure Developer. Today we're going to talk about DevSecOps at scale, in part talking about supply chain security and some big needs that we have in the ecosystem, and what can we do about them. And also, just about operating DevSecOps at scale within a massive organization, in this case, Citigroup. So, to talk about all of those we have with us, John Meadows, who heads up cloud security engineering and application security at Citigroup. John, thanks for coming on to the show.

[00:02:34] Jonathan Meadows: Thanks for having me, Guy.

[00:02:36] Guy Podjarny: So, John, before we dig in all these massive topics in front of us, tell us a little bit about what you do, and maybe just a bit of your journey through where you are today?

[00:02:44] Jonathan Meadows: Sure, absolutely. So, I'm the head of cloud security engineering at Citigroup, and also head of application security. From past lives, I've been a developer for many years, working through trading systems, working at multiple different financial institutions, building out code around trading systems, and also a lot of work around securing those. And then more recently got into the cloud, about five or six years ago, building out those cloud security architectures, ensuring that we have a solid capability of deploying cloud native applications in a secure manner.

Also, four or five years ago, started to look at supply chain, and looking at how we can secure the supply chain for closed and open source software. So, a lot of scope there. But it's really, really an interesting journey going from development through to the security side of things into the cloud and into supply chain. So, fun area to be in.

[00:03:39] Guy Podjarny: Indeed, and not an easily solved one at it. Before you've been at Citi, you've been at a couple of other big financial institutions as well, right?

[00:03:48] Jonathan Meadows: That's right, right back from Lehman Brothers, back in the day, was there for an awful long time. And then into Nomura, and two or three years at Nomura, and then into JP Morgan, for a good decade before coming across to Citigroup two years ago.

[00:04:03] Guy Podjarny: Yeah, cool. So, you definitely have a broad lens of how software is consumed and secured, sometimes not, in these different organizations.

[00:04:11] Jonathan Meadows: That's right.

[00:04:13] Guy Podjarny: So, with that, John, there's a lot we can talk about. But probably a good topic to start from is supply chain security. You've been digging into this space for a while, maybe we start off with a bit of a definition. What does it mean to you supply chain security?

[00:04:26] Jonathan Meadows: This scope is huge when you look at supply chain security, right? And it's really the way that you ingest, build, ingest, and deploy software as an entity. And really, your supply chain really does come or start right down at the initial dependency level, all of your dependencies for the application through all of the components that you bring into an enterprise, whether that's within routers, or databases, or the applications that you then build. And then you need to continue that journey all the way through to how you distribute that software to your clients.

And it's a true chain, so that multiple different enterprises within that chain, need to look at that supply chain and you need to be aware of what that looks like as well, from effectively who's building the chipsets in your servers, through to who’s putting the firmware onto them. Applications on top of those, through to which you can see that as an enterprise and then delivering an application to your customer.

So, it's a really broad problem that obviously multiple different industries also tackle. And the difficulty with a supply chain and supply chain security is it really is as secure as the weakest link. So, you really do need to get a good grip on where you're getting your software ingredients from, as you're looking at that problem. Now, it's a wide area that people have been looking at for many years now for some great work coming from NYU, and Justin Cappos, are some of the work they did around the Tuff protocol, signing software artifacts, and then Justin Cappos, implementing functionality like in Toto, that's in the open source arena.

And really, teams are now building upon that to secure their supply chain, as they focus on maturing that capability. So yeah, that's what it really means to me. But it's just such a huge area to get involved in. It's one of those problems that isn't solved and I think it's going to take the industry to work together to actually come up with a joint solution.

[00:06:23] Guy Podjarny: Yeah, fully agree to that, sort of the end to end element of it is probably the biggest challenge here getting everybody to align on anything is pretty hard. And this is one that's security, which is tougher. How do you delineate the company lens, sort of the actions a company should do from the industry? Maybe we kind of take those two lenses a bit starting from whichever, and sort of say, “How should one think about their role in this mix?”

[00:06:53] Jonathan Meadows: Yeah, I think that's an interesting topic, right? Because the reality is, we're part of the software industry, and all of the different enterprises are part of solving that problem. So, you can't really just solve it as an individual enterprise. You need to be working with the industry in the open source community to come up with a joint solution. And that's why I've been very sort of active in the open source community working with different teams to come up with solutions and figure out how we can address supply chain security. I think that's the way forward. Because at the end of the day, it's really the dependencies that are going to make the difference and making it more secure for everyone. And you need to contribute back to the industry to help this problem get solved, right?

So, at Citigroup, we're part of the CNCF, the Cloud Native Computing Foundation, we're part of the Open Source Security Foundation, and we do contribute back heavily to open source and working with these different groups. I think that really is the way that we need to solve this problem and do it openly. Because at the end of the day, you can put as much security at that perimeter when you're looking to the supply chain. But as I said earlier, it's weak as the weakest link in that chain. We need to work together to make sure that we can help secure open source software and vendors and dependencies. So, that's why we need to get out there and assist.

I think when people start to look in that lens, and perhaps start to look at threat modeling their supply chain, that's where sort of light bulbs will start to go off. And you'll realize, “Hang on, it's not something that we can just tackle by securing our build, we need to really go and look at the multiple areas around securing that supply chain.” And you can sort of split it out where, you know, on the on the left side, you have secure development, then you start to look at secure ingestion of that software. There's a major body of work there.

Then you look at secure build, and then on to runtime and deployment. But if you start to split it out there and you look at the threat model, you'll start to see where perhaps, as an enterprise, you'd want to start to focus and realize that actually to cure or to address some of those issues, you really do need to work at the industry level, to provide guidance and also help remediate some of those issues with open source software and capabilities.

[00:09:14] Guy Podjarny: Yeah. So, let's talk maybe about some of these open source activities and some of the ones that you find most interesting or most compelling for people to first be aware of and then maybe subsequently participate or consume.

[00:09:27] Jonathan Meadows: Yeah, absolutely. So, I encourage people to look at the good work coming out of both the Cloud Native Computing Foundation and OSSF. We've been working with the Cloud Native Computing Foundation’s supply chain working group. I stood that up as part of the security SIG sometime last year. And as part of that, we've actually published a Best Practice Guide to Supply Chain Security. There's a great group of experts within the CNCF got together and published that document and really shows people how to really look at it from an enterprise or an end to end perspective to secure that supply chain.

So, it's a great starting document. I recommend people start to look at it. There’s additional work that's going on within that supply chain working group, looking at putting together a draft architecture, of how to put together a secure software factory, also how to look at that supply chain again in that sort of end to end view. So, that's definitely an area I'd recommend people lean in and collaborate, take a look at the materials there, but also come and join us in that group. It's an open forum, as with all these forums, and it'd be great to see people participating in there.

And also, in the the OSSF, some great –

[00:10:39] Guy Podjarny: Before we can have veer on to the openness, you say draft architecture, draft architecture for companies to embrace themselves? Or is it architecture for the ecosystem?

[00:10:48] Jonathan Meadows: It's a reference architecture just for the Secure Software Factory part of it. And what I mean by that is the ability to build software in a secure manner. So, setting up ephemeral secure pipeline that would allow us to understand what you've actually built, and provide, effectively, attestations at the end of that factory, that it not only gives you the output, the secured product, but also metadata to show you how that product was built. So, it definitely came from that source code, for example. And it definitely went through the different components within a secure pipeline.

That's effectively an architecture for that part of the component. But also, within that initial document that we put together as a group, we were really looking at it holistically, truly end to end, from ingesting the source code and suggestions around how you'd even secure your source code repositories and scanning the open source software before you put into that software pipeline. So, that actual architecture is only a component of that whole. But it's a decent start. And again, it's a reference architecture, just something that people can throw stones out and take a look at, build upon or or reimplement, and it gives you some idea of where to go.

[00:12:01] Guy Podjarny: Got it, yeah. Okay, that's it sounds very useful. And in general, it sounds like and we can maybe go back and take that apart in a sec, but there's the element of building something secure in the first place, there's the element of tracking it across the pipeline to know what you're consuming at any given time. And then there's the element of assessing what is trustworthy, right? And what isn't probably the hairiest problem of them all.

[00:12:24] Jonathan Meadows: That's right. And when you do that threat model, and you look at that, sort of end to end, your end to end software supply chain pipeline, you realize that actually, a huge focus needs to be brought upon your ingestion and what you're bringing in, and the security and provenance of that functionality in the code, right? And that's where there's been some great work around SBOM from Dr. Alan Friedman, NTIA and SISA. Trying to get people together to look at providing an SBOM, a software bill of materials. What that is, is basically a list of ingredients for what software is in the software that you're consuming, whether that's closed source, or an open source piece of software, that will at least tell you what's coming in. But then you can also extend that and look at, “Well, that gives me the constituents of the software it's coming in. But what about the security of perhaps the vendor or the open source product itself, or project itself?”

So, digging into this a little bit, if you're looking at just that open source ingestion piece, you're looking at the content, but also start to look at that project. And that's where you could perhaps start to look at the open source security foundation scorecard, where they've put together a list of metrics around the security of the open source project itself. And you start to reason about the security of that project, as well as the components that it makes up. That's definitely an area that we’re starting to pull out as part of that working group

[00:13:51] Guy Podjarny: So, those were some good, I guess, existing work and upcoming work from the CNCF supply chain security group, which we'll put the link to in the show notes. And on the OSSF, I'm also on the OSSF board with you. So, we're seeing there, but which projects are you find most compelling when it comes to supply chain security in the OSSF?

[00:14:11] Jonathan Meadows: This is a great thing that I like about the OSSF, it’s even wider. If you look at the supply chain ecosystem, there's multiple different projects here that are looking at each individual stage. You've got the integrity working group, where effectively we're looking at how to look at the provenance of those materials, but also starting to extend sort of further left and looking at securing critical open source software. This is one of the areas that I really do believe in looking at working with the the open source industry and projects to help people secure their software either by putting together security audits or providing resources, and in some situations finance to help secure the software at source.

It's really interesting looking at the OSSF and how it's expanded that actually if you can look at it in a certain lens, that actually the majority of working groups within the OSSF, we’re in some way connected to that supply chain. So, it's pretty exciting group and space, heavily interested and involved in that one.

[00:15:12] Guy Podjarny: And pretty much the sort of the whole flow over there. So, let's try to sort of paint a bit of a picture and try to give listeners a bit of guidance on what they can do in different areas. So, tell me if I have this correctly. When you talk about supply chain, there's the notion like for my company lens, there's notion of, what is it that you're consuming? The trustworthiness piece. There's the notion of, how do you know what you think you're getting is actually what you're getting? So yes, you trust this open source project, but is this thing that you downloaded, actually correct? That it's that sort of been untampered, not tampered with as it went through your pipeline as you consumed it. And then there's just the ongoing tracking of what do you have and where is it at? So, you can deal with it once a problem has been formed. Is that the right way to – I guess there's the last one, which you mentioned, which is the actual upstream and how do we get together to find the biggest suppliers and help secure them? Which is its own topic. Am I missing? Does that capture it correctly?

[00:16:16] Jonathan Meadows: That’s absolutely spot on. I think one area that you need to add there right up front is the secure development of your software. So, it really depends on where you sit within this ecosystem. Again, back to that threat model of these the different areas, perhaps as an enterprise you need to look at, but you may be close to the front of that ecosystem, you may be writing firmware on a chip, or you may be towards the end closer to the customer. And the reality is the majority, the software you're using is actually being consumed, then you're implementing it. That sort of gives you a bit more of a lens of prioritization of where you'd need to focus perhaps more on.

But at some point, you still have to have a secure development, and that's really ensuring that you have a good understanding of how you're developing your own source code, leveraging those open source components, ensuring that you've got a good handle on your source code, security, access control and such. And then that then merges with those dependencies that you've added in there. So, I see it very much as a secure developer, or secure the development environment, then the security of the software you ingest, both closed and open. And then as you say, into the build, and then deployment downstream.

[00:17:30] Guy Podjarny: Do you find it helpful to include the notion of secure development as part of the supply chain aspects to create a holistic? Or versus maybe the counter argument would be that you rather separate them so that they're a bit more contained, sometimes boiling the ocean? Do find that the two are just too intertwined to decouple and you have to think about them as one?

[00:17:53] Jonathan Meadows: They are intertwined, but you can look at them in slightly separate entities, because I think that the focus areas are very different as you look at those different dependencies. You're sitting there from a development perspective, working on your code, within your IDs on a particular system, desktop, or whatever you need to ensure that the security of that as an entity is sound. And then you look at how you're ingesting the software. Because your desktop could be compromised, your ID could be compromised. And there are details of these exploits being effective. And that's in addition to looking at those softwares that you ingest.

There’s some really good data out there from actually in the CNCF security SIG, where they list the supply chain exploits, and gives you an idea of where they are within the supply chain. There are also other areas. I think there's a couple of different repositories of exploit that you can take a look at to just inform your supply chain threat model and get an understanding of where some of those exploits sit. You will see that there are some on the secure development side as well as ingestion.

[00:18:57] Guy Podjarny: Yeah, we've kind of laid out those threats, imagine you're talking to someone building a security program, they're sold. They believed this risk, they agreed that they need to invest in it. Walk us through a little bit of like, what would you advise, some of the key actions may be, in these different steps?

[00:19:16] Jonathan Meadows: I think as people look at maturing the supply chain program, you want to start with understanding, where are you ingesting that software from? And again, that's back to vendor software, as well as open source software. Get an understanding of where that's coming from, who it's coming from, and are you pulling off the internet? Are you taking it from a point that you trust, developing signatures and such? How are you ingesting it into your company or your group? And then look at the inventory, do you have a solid inventory of where your software is, and an understanding of when it was updated and get an appropriate level of metadata?

And then you can start to build up that picture around the hygiene of the software that you ingest. Have you ingested software and haven't touched it in like five years, or have you been getting it from a point that you truly trust and haven't really looked at it at that point? That starts to sort of build up your picture of where you're getting that software from and what you actually have. And then you can start to put controls around ensuring that you're validating the software that you ingest, are you ensuring that you have an SBOM from a particular supplier or open source software, or at least you’re checking that you have particular vulnerabilities, and you won't let it through. That's where you start to get into a bit more mature mindset around how you're ingesting that software.

And again, it kind of depends where you are in this supply chain. If you're right at the front, and you're building tools for other people to digest, you probably focus more on the build. But more of the enterprise is probably closer to the other end serving customers, but building software. So, probably more of a weight on the ingestion area, than ensuring that you have the inventory and real validity on the software that you're ingesting. And then start to look at the secure building of that software to ensure that if there's compromise within your group, that you're able to understand the provenance of the software you ingest, and also the security of those components that you've actually built it upon. Then you're starting to move into that sort of next level of maturity, when you have a real understanding of where your software is coming from, real understanding of your inventory, real understanding of how secure you're building it, and you're starting to step up a couple of levels in terms of maturity.

The reality here, though, is that there's a lot of good work in another project called SLSA, which is under the OSSF, kind of steps up to the levels of maturity around supply chain, and I'd recommend people start taking a look at that.

[00:21:49] Guy Podjarny: Just to say, we call it Salsa, but it’s SLSA for those trying to google salsa and getting to something totally different.

[00:21:56] Jonathan Meadows: Indeed, indeed. But that's a great body of work that we're excited and contributing to. And it really shows people how to step up the multiple different levels of thinking through their supply chain. But I think to me, we're still working on that and there's more work to come there as we look at how we can validate that ingestion of software into your supply chain program.

[00:22:19] Guy Podjarny: So, I think this is a great model. And I really like SLSA as well in the work that it’s done there. So, you go through from how you're consuming it to what you're consuming, or what your inventory is to the judgment, a little bit of it, of saying you know how good or bad or issue it is. You go off to the controls you put in place and your build process, and then into sort of securing what you're actually creating yourself on top of that, and tracking towards deployed. So, you have that flow. When you think about it, none of these are easy, these are all pretty hard, how important do you think is kind of accepting that it's going to be flawed or sort of investing in like fast response, right?

If you think about the last little while, we've had two cases, one Log4j that required a quick upgrade, which there's a lot of like a constant stream of mini Log4j type, Log4Shell type issues that happen all the time, but it's one. The other, we had the maintainer of colors, JS and a few others, Faker, basically introduced a problem for a variety of reasons, and maybe triggering a need to roll back as far as consumers were concerned. Is this just the reality that we need to accept that this will happen? Or do you think if we got it right, then we move that into sort of a remote possibility?

[00:23:37] Jonathan Meadows: I think it's a great question. I think it's a question I've been talking to some of my colleagues at the OSSF around. I think it's the same issue as many other things in cybersecurity, right? There's no 100% point. There are metrics, I think we need to bring into play here that will allow us to get an understanding of how you're doing from a supply chain perspective, also how you can react to the resiliency of cybersecurity in general, as well as the cybersecurity capabilities of your supply chain.

So, we need to start thinking about what metrics are going to provide us that understanding about supply chain resilience. And there's been some good work out there with DORA looking at just from a DevOps perspective, how do you measure the the capabilities that you have there? And one of them really focuses on how quickly can you fix an issue? And I think those are the sort of metrics we need to start thinking about, irrespective of how secure we think we are ultimately, given the number of links in that supply chain, we may have to upgrade quickly.

So, what is the metric that shows you how quickly you can update your software? And really, that's when that you start to have that closer lens on to get a better understanding of how quickly you can remediate those issues or mitigate these issues. I think the Log4j issue was obviously a major issue for the industry and kind of that wake-up call that’s got everyone looking at their inventories and hygiene, and how quickly they can respond. And that's perhaps the metric we need to start looking at, is that in addition to hardening our supply chains, and building out all these capabilities, and really working together as an industry, because it's not something that one person is going to be able to solve, or one group is going to be able to solve. But then at the same time, looking at individually, what are the metrics that are going to give us an understanding how quickly we can react if there is that issue. I think that's the metric I might suggest people start to look at, and we get better at understanding.

[00:25:31] Guy Podjarny: Yeah, for sure. Maybe zooming out a little bit, from these practicalities, when you think about this problem in a bit more abstract, maybe trying like a glass half full, glass half empty type perspective here. If you think about the doomsday scenarios, you're pessimistic, you think about this problem, what do you think is the worst thing that can happen here? What's a negative forecast? And then we'll kind of switch to the positive, what’s the optimistic lens?

[00:25:58] Jonathan Meadows: What’s negative potential forecast? I mean, I think this is a significant issue. I'm sort of downplaying it from an Englishman's perspective, right? It is a significant issue that we need to be concerned about and aware of at an industry level. I think multiple different players are involved in making sure that we can address these issues. I think it really has got to the level now when we do need to come together as a wider group to start focusing on this. Because we must have a better understanding of our supply chain to ensure that we don't leave that door open.

I think we can all think about doomsday scenarios and such. But I feel much more positive that now we're starting to get more focus as an industry in this particular area. This isn't a new issue. It's been there for decades. But over the last sort of four or five years, people are starting to coalesce around particular technologies and approaches, and this is only ramping up with the formation of VRSF. And from some of those working groups. So, I think I'm optimistic about the future in that we're actually getting together to actually try and build out these capabilities. And really just go back to that, I think that's the only way forward, making sure that we work together as an industry. This isn't someone goes off and implement something. This is absolutely we need to be working in the open, making sure that we work together to fix this problem.

[00:27:20] Guy Podjarny: Yeah. I'm fully aligned and I know, just sort of sharing a bit of my perspective is my fear is that we revert to too many people thinking that they can control it by consuming less. And that's just you'll be secure all the way to bankruptcy. I mean, there's no, we need to take advantage, to leverage the work that each other is doing. We build on these supply chains, that allows us to create amazing things. The solution of, “Let's restrain and only allow our developers to use these seven sorts of highly curated, highly vetted, open source components,” is not a practical one. So, just need to make sure that our solutions that we put in place are ones that don't assume an excessive amount of constraint.

[00:28:05] Jonathan Meadows: I completely agree. I completely agree with that. That's why we're taking the opposite view and trying to be as open as we can, working with open source teams and external parties just to work together on this issue. This isn't something you can just hide away from or decide to stop using open source software. It's very much, we need to work together to come up with a joint solution.

[00:28:26] Guy Podjarny: So, I think supply chain is a pretty massive topic, and it's one that is that is hard a little bit to wrap your head around, and we've already kind of outlined a few specific guidelines of how we work together. Maybe switching gears to talk about a couple of other topics, more into these domains that are in our control, which is building secure software of our own. In a past conversation, in a panel you and I were both on, you mentioned this notion of security libraries that caught my attention. Do you mind sort of explaining a little bit about what that means?

[00:29:02] Jonathan Meadows: Sure, I mean, it was really around like the the levels of maturity of DevSecOps and how I've seen different companies and industries move through that. And it really started from looking at some of the – just initially start to at least scan and get an understanding of where vulnerabilities may be. But then quickly shift left, as it were, just as we're all looking at the DevSecOps programs. But then you get to a point where, in order to make it more scalable and secure, we look at, or I've seen multiple people looking at, providing secure libraries where you can create access to certain security functions via a series of libraries and only implement it once. Make sure that you threat model the ability to provide that capability. Make sure that you harden that component, whether it's secure logging, whether it's cryptography, whether it's secrets management, and ensure that you provide a hardened component that’s easy for developers to use.

It really takes the difficulty out of securing that part of the product from the security, but from the application developer. We're not implementing it multiple times as a security library, that's something then leverage. Because you've threat modeling and hardened it, you have a much better understanding of how that library is going to perform, and you can manage it sort of centrally. But part of that is also to provide those capabilities to the software developer as easily as possible.

So, whilst it could be a library, that's kind of the least common denominator in many ways. People start to look at, how can we provide that secure functionality in the platforms that we host the applications on? Whether that's securing the cloud platform and providing those security capabilities to any application that's deployed onto them. Or in the container orchestration layer or in a service mesh. I think teams are looking at how can we provide those security capabilities as low down in that stack as we possibly can, so that it's inherited by subsequent stacks and it removes the need for developers to start to think about that and implement it? It just kind of removes entire classes of vulnerability or security requirements by doing so. And really, I see people moving into that area, it just makes it much more scalable and easy for people to really deliver their software and focus on what application developers want to do, which is the business side of their software, rather than the security elements of it.

[00:31:28] Guy Podjarny: Yeah, I really like the idea of these security libraries. And the notion of doing it under that mantle of simplification, as you mentioned right now and making it easier if you're sort of thinking concretely. Give us something just to turn this into maybe a more practical solution for someone to invest in. What's an example or two of libraries that you might create?

[00:31:50] Jonathan Meadows: Well, some of them already exist, or some of them have been implemented directly within the languages. React, for example, is a great story of some of the security capabilities there. But similar security libraries, such as secure logging, or such as secrets management, right? Having a capability, where it's just an easy API, that you can log securely, or have the ability then for security teams to perhaps inject additional functionality in there over the course of time that would allow it to sanitize particularly log messages, for example, or provide additional diagnostics from a security perspective directly into the application. I think there's a lot to be said for that security, the logging libraries, and that was before some of the recent issues.

[00:32:35] Guy Podjarny: It’s somewhat ironic. I fully agree, though. It's still correct around logging, which is Log4j mix adds a certain flavor of irony to it.

[00:32:44] Jonathan Meadows: Yeah, it does, isn’t it? I know we had that conversation before the Log4j issue, but I do think it's still an area for investigation.

[00:32:54] Guy Podjarny: So, of the libraries, we're talking about simplification, and maybe connecting it a little bit with this notion of the supply chain. When you think about security libraries, which I guess they are themselves dependencies, but you think about the broader concept of simplifications, what do you think are the key areas to make easy for developers in the context of the supply chain security problem?

[00:33:18] Jonathan Meadows: I think a lot of it goes back to the ingestion, and ensuring that we take care of a lot of that before. I mean, again, I guess I'm looking at from an enterprise perspective, but take care of that before we actually provide those materials to the developer, and give them much more of an insight into the dependencies that the team is actually using, and the security of those dependencies. And ensuring that we can also highlight this as the most up to date and secured one, which obviously is quite easy these days.

But give them that insight and level of security before they actually ingest that software, and that could be everything from obviously scanning it before you provide it to the developer, but also looking at providing some of the operational metrics so they can see the metadata on the libraries and dependencies they're using, give them that data. So, they can see that perhaps the open source library hasn't been updated in two years, or there hasn't been a CVE registered against it in two years, or it’s only been updated and maintained by one developer, and perhaps there's a risk score that highlights, “You should be thinking about this, maybe this isn't the dependency you want to use,” or it's a different one, or recommend a different one. Go the extra mile and recommend a different library around that. Now, whether you can take that one step further and get a team to sort of an operation, open source program office to look at that before you give it to the developer or just give that information directly to the developer. Those are sort of some of the areas, I think, that would be worth investigating.

[00:34:49] Guy Podjarny: Yeah, absolutely. And I think the visibility is, you know, I love that perspective. And fundamentally, if it's easy enough, and you're sufficiently well-informed, people make the right decisions. So, we're kind of getting them to that. I guess, that's the compliment to that ease is data and made accessible to the right spot.

[00:35:07] Jonathan Meadows: Absolutely.

[00:35:09] Guy Podjarny: So, we talked about some of the building of your own security software and around the supply chain security. Earlier, you mentioned also the importance of us rallying and going off and going back to the roots, what I've been calling, what I refer to as some of the key suppliers and helping them secure them. How do you see that scaling in the industry in terms of enterprises supporting these organizations? Today, we have a, shall we call it sub-optimal dynamic between the consumers of open source and the businesses that consume them. What would you like to see? Maybe that's the optimist again, but what do you think we should strive at?

[00:35:49] Jonathan Meadows: Yeah, I think this is an area where, again, people need to contribute back to the open source community. We are in the open source community. It's not like people are outside it. I think enterprises and teams need to be aware of the fact that we're actually in the open source community and part of it and contribute appropriately, whether that's within time and contributions back to the open source software, or working with organizations like the CNCF and the OSSF to work on projects to come up with better ideas around supply chain or other areas.

Additionally, financial commitments as well, look at contributing back to help people secure their software, or build that software and appropriately pay to provide that capability. That's something that I think needs to come to the fore a little bit more. I know that the OSSF is looking at trying to do an amount in that area, and I think that's where it's probably going to be heading.

[00:36:41] Guy Podjarny: Yeah, fully agree. The OSSF is probably for context for those who don't know, has been recently reestablished or revived under the Linux Foundation and has a lot more backing and firepower around it at the moment to do it. So, if you were aware of the Open Source Security Foundation from a couple of years ago, it's a bit of a new and definitely improved in terms of scale and scope of operation. So, it's worth checking back out.

So, John, thanks for all this, all the insights. Probably, supply chain security is a topic for many, many, many of conversations to do it. I think this is probably like a lot of material already for people to digest in one episode. Before I let you go, I'd love to ask you, my newish question for the year that I like to ask anyone, and maybe I'll caveat to say, except supply chain security, given the sort of the amount of conversation, if you had an unlimited amount of resources and money at your disposal, and you could take on a problem in your world, instead of DevSec, open source SEC or other world, what problem would that be? And maybe what would your approach be?

[00:37:49] Jonathan Meadows: It's difficult, and I'm going to cheat a little bit, because I guess it would be in that focus area, to an extent. I think it would be really adding more money or looking at how we can appropriately apply that money to the open source software ecosystem. In terms of paying for people's time appropriately, paying to secure software appropriately, and effectively giving that back to ensure that effectively the infrastructure that we're defending upon we appropriately fund and we can build out. I think there are areas of that that are already at play, or starting out in the OSSF, for example, but it would be extending that. That would be my view. At the end of the day, we're all dependent upon open source software. And it would really be ensuring that we work to assist that ecosystem, ensure that we can take it to the next couple of levels in terms of capability and security.

[00:38:40] Guy Podjarny: Yeah, absolutely. I think it's definitely one that both requires the funding and the ingenuity and the payback is pretty massive. So, well said. John, thanks for coming on to the show and sharing all these perspectives and insights and all these specific tips on how to tackle this problem.

[00:38:58] Jonathan Meadows: No worries. Thanks for having me, Guy. And yeah, I definitely recommend people join in and take a look at the Open Source Security Foundation and Cloud Native Computing Foundation working groups and come and join us solve these problems. It's the only way we're going to make traction is working together on it. Look forward to seeing you all in those group meetings.

[00:39:18] Guy Podjarny: Yeah, super well said. And thanks, everybody for listening in and I hope you join us for the next one. Thank you.

[END OF INTERVIEW]

[00:39:28] ANNOUNCER: Thanks for listening to The Secure Developer. That's all we have time for today. To find additional episodes and full transcriptions, visit thesecuredeveloper.com. If you'd like to be a guest on the show, or get involved in the community, find us on Twitter at @DevSecCon. Don't forget to leave us a review on iTunes if you enjoyed today's episode.

Bye for now.