Open Source Security: A Deep Dive

Matt Chiodi (00:14):

Software supply chain security, when you hear that term, what comes to mind? I know for me, the first thing that I think about is what happened with the SolarWinds attack a few years ago. And so in this episode, what I wanted to do was bring on an expert, someone who is actually very much involved; has firsthand experience with software supply chain security issues. And I could think of no one better than Varun Badhwar. Now, Varun is a good friend. I worked for him for a couple years back at Red Lock, also at Palo Alto Networks, but the thing that I think is unique about Varun, and he'll talk about this during the interview, is that when he was at Palo Alto Networks, he managed a team of over 400 software engineers. Therefore the whole concept of software supply chain security is something that Varun knows really well. I think you're really going to enjoy this episode. It's actually one of the shorter ones, but as usual, Varun is succinct on point and really doesn't waste time answering questions with a lot of flowery words. Get your pens ready, take some notes, and enjoy today's episode.

Matt Chiodi (01:27):

Varun, thanks for coming on the show.

Varun Badhwar (01:28):

Thanks for having me here, I'm excited to chat about all the great things we have lined up.

Matt Chiodi (01:33):

Awesome, let's just start off with just a quick background and specifically we're going to be talking about software supply chain security. Tell me a little bit about your background and what's your specific experience with the software supply chain.

Varun Badhwar (01:48):

I've been building companies for the past 13 years in cybersecurity. Prior to that, I was a practitioner myself at salesforce.com. I was fortunate enough to be in the cloud security space as a practitioner before most people could spell cloud security. I'm talking back to 2007 or 2008, and I've been privileged and lucky to be ahead of the curve in a number of areas. Cloud happened to be one of those, most notably prior to starting indoor labs, I was the founder and CEO of Red Lock, which is the leader in cloud security posture management. It then got acquired by Palo Alto Networks in 2018, where I then went on to create Prisma Cloud for Palo Alto Networks. You were there with me side by side as we did this, so it's an amazing journey. However, speaking of how I got into software supply chain security; I am by no means a PhD in this space.

Varun Badhwar (02:40):

I'm just a person who was on the receiving end of this problem. Back at Palo Alto Networks, when solar winds happened, obviously the board and every company management team was pretty spooked and wanted to make sure that we had better handle governance over our own supply chains. And I think reality, Matt, was you come to realize that as an industry, we have never really foreseen the threat the way it affected all of us. And what I mean by that is, if you talk to most CISOs, they would talk about the big IP risk of being a contractor leading the building with a USB drive with the source code. However, we never thought about our source codes being weaponized against our users; our customers. Therefore as you start thinking about that problem, you start looking into your software development practices. And the biggest recognition was that over 80% of code was not code my developers were writing, but were borrowing from complete strangers on the internet. These are strangers, but we can't even really call them suppliers, right? I mean, these are strangers, they owe us nothing, and we have no contractual obligations with them. We don't know where they live, and we don't know their motivations. The first thing we all think about is, well let's get software composition analysis tools working, and I know we're going to talk about this in more detail. However, for me, firsthand when I ran these types of tools for my product area with 400 engineers on my team it was reporting ten thousands of vulnerabilities, which as we were trying to go investigate, it would turn out 7 to 8 out of 10 were false or were just not applicable to the way we were using that open source software. At that point, I looked at my peers in the industry and I said, are we crazy or is everybody facing similar challenges? And everybody was. And I think that was where I said, okay, it's my calling to go solve this problem in a much more comprehensive, efficient way than the way the industry has been so far.

Matt Chiodi (04:46):

If I'm a listener and my company, and I think all companies at this point are software companies, it doesn't matter what you're doing. You're creating software or you've outsourced it to somebody to create for you; how do organizations go about identifying and mitigating this risk. And I ask this because depending upon the size of the company and what they do, this is really complicated and complex. Therefore, how do you start that process of identifying and mitigating these risks?

Varun Badhwar (05:15):

Great question, but before we get that, I find that not everybody has the same level of understanding of how open source works. Therefore let me maybe just give a one-on-one preamble on this. How does all of this come together in your environment? First and foremost, there's 47 million packages and versions out there in the open source ecosystem. There's over 3 trillion annual downloads being performed by your developers in your company. Therefore the magnitude and the scale of this problem is massive. Now, the second piece is, there are three layers here in an application, there is your code. Think of this as the assembly line in your manufacturing facility. Within this assembly line, your developers are bringing in dependencies or open source packages directly. What direct dependencies are, they are things you have intentionally chosen to select and bring into your environment? Then there's a bigger problem because for each one of those things that your developer wants to bring in, on average, it comes with 77. And it's called transitive dependencies. Therefore just think for a moment here, you thought you were bringing an x, the x brings in 77 friends to your party uninvited, but they're there at your house. And if you're worried about COVID spreading, guess what? They could spread COVID as much as your first friend can. And so from an inventorying perspective it solved, like to your question, I think the biggest problem has been, we haven't even recognized the magnitude to this problem and just how this sprawl happens. I think once you start getting an appreciation of that, then obviously the second question comes up, how do I do this in a manner that is efficient and effective?

Varun Badhwar (06:54):

Let's be honest, developers are winning the battle of innovation in time to market. If you put blockers, they will win. And what is the evidence behind that? Well, five years ago, large enterprises were blocking access to GitHub. Your developers couldn't even go out and get code. However, today we have pivoted to the other extreme, which is you can download anything off the internet, and there are paper-based governance rules that say you should do X or you should do Y. There are still a handful of companies that require engineers to log tickets and wait for weeks to get approval, but those programs don't work. Now, let's also draw a parallel here, Matt, to third party risks. What do we do in a commercial vendor selling software? Our procurement team will not let a vendor get through until we understand their SOC two, their pen test reports, and their questionnaires.

Varun Badhwar (07:44):

We're basically evaluating security and operational risk, however in open source we're doing nothing. And this is even though we have zero contractual obligations. Therefore where I think we as an industry need to evolve is having certain guard rails; training wheels. Which basically is, we can't block GitHub access, but we also can't have ticketing based approval mechanisms for developers to wait for things to come in. You need automation. Somebody put this in while I was speaking to yesterday, you need a Carfax Province source software. You need a mechanism in which you can evaluate who are the people behind the project. How good is our code quality? Can I trust that they'll maintain it? Is it secure? We just need a whole mechanism around that that works at scale, not requiring the army of developers that the 1% of companies like Google and Microsoft have to build all of that infrastructure themselves.

Matt Chiodi (08:35):

I appreciate that background, and I know that the approach for some companies I have been at in the past, there were some individuals in the organization that just say, well, we're not going to use open source. Which I think is a losing proposition, but is that even possible? Is it even possible to build a commercial tool of any type without using open source?

Varun Badhwar (08:56):

It is not, you will not be viable, and you’ll not be in business. If your competitors are shipping something in three months and you're taking three years to ship it because you want to build everything yourself, it's not happening. Your product is dead on arrival. And the other piece is that people think it must be the software vendors and the SaaS companies using a lot of open source. That's actually factually incorrect, every company is a development company. If you're a retailer, you're building mobile apps, you're building your own self-checkout applications and other things, and if you're a bank, you're building applications. We are finding everybody from automotive to manufacturing, and all across verticals have this problem. In fact, believe it or not, most people are surprised, but one of the most forward leading organizations in starting to enforce a lot of this US government regulation and software bill of materials and more visibility and transparency is the FDA. The FDA is now mandating any MedTech company who are shipping devices or software to start submitting those S bombs. Therefore the writing on the wall affects every business, it affects every industry, and you just can't live without it. Now the question is, do you want to have a home without surveillance cameras, alarms, monitors and guard dogs, or do you want to do something about it? Because guess what, the bad actors have figured out that this is a weak spot. And every single month we find thousands and thousands of malicious open source packages being deployed into these ecosystems to try to get your well-intentioned developers who are trying to move fast to basically be compromised.

Matt Chiodi (10:32):

Eliminating open source isn't going to work because it's a part of how software is developed. How do organizations go about identifying and starting to mitigate this risk? If I'm an organization, and maybe I've made investments in some tools in the past, but I really don't have a strategy, where should they start?

Varun Badhwar (10:56):

That's a great question, the most common alternate people have used so far to try to solve this problem is software composition analysis or SCA tools. It's important to understand where these tools started out their journey from, they all started about a decade ago with license compliance. Legal teams wanted to understand exposure to legal risk based on the components you were using. The mechanism to scan and the technology behind it was pretty dated, and eventually we said, okay, we need to do vulnerability compliance and organize data. Therefore, the same technology was used to then start doing vulnerability scanning. And that has led to tremendous wastage of engineering cycles because what you'll find these tools end up doing is causing a lot more noise than there's value. Therefore how do you solve all of this? Let's get through the principles first one, this has to be integrated into the developer work, asking developers to go outside of their workflow to go find things and understand if they can use it, doesn't work.

Varun Badhwar (11:55):

Therefore step one in the IDE, that's where your developers are bringing in open source software. They're going in and doing a command like NPM install, react. You need to be in that workflow to A, recognize what somebody's bringing in, B, do that assessment that Carfax scans for them and say, wait a minute, you're trying to bring in this piece of software. Here's everything we understand about its security and operational risk; the human risk, the code quality risk. Provide those metrics to your developer because I promised you, if the developer understood that information, they would likely make better choices themselves. Today, not having that information means they're trying to do their own research, and they're looking at things like GitHub stars for open source projects. I could buy a thousand GitHub stars for $64 today on the internet, so those aren't real metrics. What you're truly trying to do is identify in the developer workflow the potential problems, and give them that feedback. Now, let's say at that point they choose to ignore you. Well, guess what? They've got to push that code into a source control system; the GitHub or GitLab. Well, if you're integrated into the whole pipeline as they're trying to check in this imported package from the open source ecosystem into your code repository, this is where you can actually enforce policy. An example of a policy is, you can say I will not let you bring in unmaintained open source software into my enterprise, or I will not let you bring in something that has a known vulnerability that I've been open for over six months and not been fixed in a particular package. Or I will not let you bring in something that doesn't even have a CI pipeline through which they ship updates, because for me, getting providence and understanding of risk will be difficult. Therefore those policies can then be enforced in the CI/CD pipeline. You can break bills, warn developers, and report it to the security teams. The whole idea is to be automation first, and then if you need to triage for further investigation, you can. And ultimately, all of this data surfaces in a centralized inventory, which now across a clip, a typical enterprise that has thousands of code repositories can tell you at an aggregated view across all of the different open source components you're being used. Not just the direct ones all the way down to the transitive ones, but Matt, more importantly, not just telling you what has been imported, but specifically down to the line of code of how it's being consumed by your developers. And this is because that is the single biggest way you can get to prioritization and elimination of a lot of vulnerability noise and general feedback that slows developers down.

Matt Chiodi (14:41):

Obviously, when you're talking about software development, there's multiple different tools and teams that are involved. Let's talk a little bit about this from a strategy level. Let's talk about collaboration between different stakeholders and by stakeholders, it could be those that are both inside the organization as well as those on the outside. For example, the software vendors themselves, government agencies, and I know you mentioned SBOM so maybe let's talk about that a little bit right there. However, what's happening at the government level, because they've been talking about the software bill of materials for a while. And so actually let's go down the rabbit hole on that a little bit. Where does the SBOM come in with software supply chain security? Is it a panacea? Is it the silver bullet? Help me understand that.

Varun Badhwar (15:26):

It's the start of a conversation and what I often call an SBOM is a means to an end. Ultimately, we're all hoping and praying that software builds and materials will help us to secure our open source usage around that. However, let's be real, it's an artifact. Producing an artifact doesn't solve a problem. Therefore, to me, if you want to build this left to right picture in your mind, the left hand side is when a developer introduced some new open source code. Somewhere in the middle, they developed it, customized it, tested it, integrated it, put it in a container, and they shipped it. On that far right end side, when you're shipping it, somebody produces an SBOM. Guess what you can do at that point? Nothing. You can produce an artifact, but you can't change the outcome. The outcome is if something bad went in on the left hand side, it's showing up on your SBOM. The other piece I kind of commonly touch upon here is, everybody loves to talk about the food label analogy, so let's touch on that. When the FDA said we're going to put food labels on, what did all the manufacturers do? They slapped on the labels, but guess what, if the ingredients going into your product now were not good, you were embarrassed and you were self-aware that you need to go fix it. And you need to replace it with healthier, more nutritious ingredients; you don't want 10 grams of Tran’s fat, for example so figure out a way to kind of reduce that. Therefore I think this is why SBOMs are a means to an end, because once you start having a conversation to air your dirty laundry, expose your lack of maturity and governance of processes for how your organization uses open source software, and your customer sees that artifact, it's going to force you to have that lifecycle approach for managing open source software, so that's one. The second question you asked is, who are the stakeholders internally? Well, there are two main organizations, there's a security team that's obviously driving policy driving requirements, and then there's the engineering organization that ultimately has to change behaviors and commonly you find a lot of tension between these two organizations. I wrote about some LinkedIn a couple days ago on Valentine's Day regarding sharing the love between engineers and security professionals. Remember, engineering KPIs are on speed, time to market for produced delivering features. Security is risk management; these are orthogonal. Therefore how do you bring these together? Well, let's find the common ground. The common ground is open source software, if not managed correctly, can add a lot of headache for our engineering teams as well. The maintenance of it, the upkeep of it, it's not automated. There's no customer success team with open source software telling you how and when to update it. Therefore you as an engineering organization that's consuming it now has to manage and maintain it. So there's certain common ground there where you want to nurture all of this.

Varun Badhwar (18:19):

Security wants to make sure you're on the right version, you're using the right level of software compatibility and all. So we're looking at those overlapping spaces, and what we're finding in most of our customer engagement is stakeholders of both. There's somebody from the engineering platform teams or more the snazzier name for this is engineering productivity teams in your organizations. Those teams working closely with the application and product security teams to say, how do we solve this end-to-end problem? Because okay, somebody needs an SBOM on the product team side. This all needs to manage work; Engineers need to bring in more open source software and be more effective finding the common ground. And let's find a centralized mechanism to solve dependency management end to end.

Matt Chiodi (19:02):

Prisma Cloud secures infrastructure, applications, data and entitlements across the world's largest clouds, all from a single unified solution. With a combination of cloud service provider APIs in a unified agent framework, users gain unmatched visibility and protection. Prisma Cloud also integrates with any continuous integration and continuous delivery workflow to secure cloud infrastructure and applications early in development. You can scan infrastructure as code templates, container images, server less functions and more while gaining powerful full stack runtime protection. This is unified security for DevOps and security teams. To find out more, go to Prismacloud.io.

Matt Chiodi (19:49):

We talked a little bit about this, but are there any best practices or industry standards that organizations should follow to improve the quality of their software supply chain?

Varun Badhwar (20:01):

It's all emerging, there's a lot happening every single week. Google has a standard called SLSA, you've got NIS that has a framework around this, and also OSP that has a framework around it. Frameworks are a dime a dozen, now I think the question will be, it remains to be seen how these will be adopted. CIS now has its own frameworks and checks, unfortunately though, as we have seen in the past life, the first thing that drives a lot of security shifts is compliance. And I think for organizations that are selling to anybody in the government trying to compare themselves for the SBOM movement is probably where we're seeing the most activity and action. We will be launching in a couple weeks’ time, some very interesting research on this topic. I won't share much more than say, look out on March 1st for an announcement on the Endor Labs side on how you can actually think about these risks and prioritize these risks. It's peer reviewed by dozens of CISOs, so it's coming shortly... There are certain things that are fundamental Matt; you don't need a standard to align with them, for example, visibility, and inventory of your software components. These are foundational controls. Get those things in order, get your vulnerability management program to be more efficient because right now you're piling up more vulnerabilities than you can fix. Get your basics together and then you'll be in a much better shape to manage and maneuver through a lot of the emerging challenges. I think where organizations are is there's a bit of inertia; you can't get out of your own way with the way you're using existing tools and doing vulnerability management. I think we just need to get past that, but to net it out, there are a lot of standards. Pick a favorite one, but at the end of the day, it's not rocket science, its visibility, it's guardrails to prevent bad things from coming in. It's detection and response measures for the next log4j incident. It provides better preparedness, so that you can find these things, resolve them faster, and the fourth piece is really around compliance. Therefore to sum it all up, it's select, secure, maintain, and comply; that's all you're going to focus on.

Matt Chiodi (22:21):

You touched on this a little bit earlier; a good bit of software development is now being done natively in the cloud. Therefore, that's all the big ones that we all know about. Is there a gap in the security tools and services that's being offered by the cloud providers when it comes to the software supply chain?

Varun Badhwar (22:42):

This is an interesting question because I think cloud platform providers see things when you're ready to deploy them. If you think about a lot of it, the cycle starts with a developer pulling down code locally on their laptop as they're investigating things. They write some of that software, then probably the next checkpoint is the GitHub GitLab platforms of the world. And then ultimately it's the cloud platform providers. So I think unlike the cloud security, posture management market and cloud workload protection, where you can say, well, how much are cloud providers going to do? I think really the question here is what is GitHub and GitLab as to where the majority of source code lives doing about this problem? And we've found a couple of areas where they've really made good investments honestly speaking, and the first one is first party code.

Varun Badhwar (23:29):

For that 20% of your code that you are writing; your developers are writing, the legacy way to do scanning against that was SaaS products like Veracode and fortify and check marks, but they were extremely noisy. They weren't integrating into the development process, and so a lot of those use cases are now best handled by GitHub through advanced security and GitLab through their premium offerings. Like everything else, this is a shared responsibility even with open source code. The other piece I would caution the listeners on, and this is a policy that we all fall under the trap, is the maintainers of this open source project are volunteers. Please remember that they owe you nothing. During Log4j there were so many companies sending the maintainers of log4j's spreadsheets and asking them to complete it. Why? They don't owe you anything, you don't pay them a dollar. Yesterday I published about a maintainer who runs a particular JavaScript project with 250 million downloads a month. He can barely pay his bills, he's a single maintainer that lives out of Russia. The entire internet infrastructure from Netflix to Amazon depends on him. And people aren't willing to pay him, the guy can barely make $3,000 a month through donations and he's trying to feed his family and kids. Therefore, take on the responsibility, it is yours as a consumer of software, and set aside budgets for open source programs. We are starting to see more progress being made with GitHub, GitLab and the others. However, I think by the time it gets to your front deployments in the cloud, it's too late.

Matt Chiodi (25:06):

That gentleman that you're talking about that's making $3,000 a month sounds like a perfect target for some type of espionage. We'll leave it at that, but when someone's that influential, and there's a potential economic motivation it sounds like the perfect pathway for some type of espionage.

Varun Badhwar (25:26):

I'm saying this not to freak out your audience but there are two more pieces of information there. He lives in Russia and has been in jail for 10 months in the last three years. However, your team still uses that open source, did you know that? You had no way to evaluate it, therefore we need to get better at that.

Matt Chiodi (25:43):

You just made a bunch of security people have to do a lot of work after they hear this. Tell us a little bit about indoor labs. How are you approaching this? What makes your approach unique compared to some of the others in the market?

Varun Badhwar (25:59):

Like I've said, this is a pain that I felt firsthand, so we took a very user-centric approach to say what are the problems the engineering teams are facing? What are the problems the security teams are facing? And we've bottomed out on three things that needed to be solved, one is the alert noise problem. The SCA tools generate far too many alerts and the reason they do that is they're very core screened in their analysis. To just be a little bit more technical for a minute, the way all of the SCA market works is they scan your manifest file. The manifest file may be a palm XML file, or the package JSON file. These files are basically directory listings of anything being imported. Therefore I know you may be importing it into your source code, but I have no idea how you use it. So let's say you imported the AWS SDK, it's a great open source; everybody needs it for cloud applications. Now that SDK comprises code for hundreds of different services of AWS. For my application, I'm probably using two services, so guess what? The only thing that I care about is tracking what parts of the AWS SDK library my developer is using and off those two parts, what other dependencies transit did they get called. And by having that knowledge of that dependency graph to that level of fidelity, now I will only bother you when there's vulnerability hearing machines related to the pieces of code you actually use. Not yelp by association, so that's one.

Varun Badhwar (27:37):

And by the way, that is almost rocket science. We have seven PhDs and other smart engineers really working on this problem of building these call graphs at scale to understand there; so that's one. The second is the Carfax problem, there's 47 million packages and your developer may want to use anything tomorrow morning. How do I get the analytics and metrics of the different things related to humans, the code, security to quality and present them scalable. And so there's a pretty sophisticated infrastructure that does that at scale and provides those findings to you. Most of the existing tooling focuses on just two things and they are both late indicators, license risk and vulnerability risk. And they miss everything else that would be an early signal, like the signals I just told you about.

Varun Badhwar (28:27):

Like this package with 250 million downloads in somebody whose star is probably something you should be aware of as a potential risk if it's running your critical application. And the last piece is you, what are CE's? What are vulnerabilities? Vulnerabilities are typically well-intentioned developers that made coding mistakes that are now surfaced publicly and now you track them in their national vulnerability database; that's what USCA tools do. There are now thousands and thousands of malicious intentions people putting malicious packages. These are not accidental coding errors. They are knowingly malicious packages available in the ecosystem for your developers to download. They don't show up in the CV database, how do you need tech walls? How do you prevent those from coming into your environment? Those are probably the three main areas that we focus on. And as I told you, we had to find the commonality between engineering and security. And one of the big problems was it's great for security tools to tell you have a problem, but engineers find it very difficult to update open source software. And so the fourth competitive advantage we have is we actually help engineering teams with improving their application resiliency by actually looking at aiding and further optimizing all this open source code, maintain it, update it, and remove it when necessary to keep their applications running.

Matt Chiodi (29:51):

What have you found to be the best way to incentivize engineering teams to actually use user security, whether it's end or, or for that matter, any type of software tool. And like you said, if you try to force somebody outside of their normal process, that's going to be usually something they push back on. And like you said, there's this whole understanding that hey, these security tools are going to be super noisy, and they're going to create a lot of work for me. What have you found to be the best way to incentivize these teams? I know its classic insecurity that developers are always the problem, but what have you seen is the right way to actually make it? If someone makes an investment in a tool, for example, Endor, how do they make it so it's actually used and not resisted?

Varun Badhwar (30:35):

Well, I think we're seeing a couple of paradigms shipped. One, I think it's very rare to see a security team exclusively evaluate and purchase a security product today where they don't have the engineering team involved in the decision making process and in the evaluation process. And so, how do you delight not just the security people who are paying the bill, but how do you delight the users? Nobody wants more software security products. The second piece is can you build a security product that not only doesn't suck? There are three generations of security tools, there's been a good old meaty security tool that absolutely sucks. Then there's been the next generation where they said, okay, let's build security tools that don't suck, and I would give Sneak as an example of a product that for the last five years have had that perception of look, it's a security tool; it doesn't suck. It's probably the least sucky security tool out there. And then there's the third vector where I think a lot of companies now need to be, which is how am I not just a security tool that doesn't suck, but how do I actually enable developers in their own workflow? Meaning it's not just about security, but it's about productivity enhancement beyond security. And I think where Endor has been really focused on our teams and our product and engineering teams have really done a good job is thinking about that life cycle. Don't just find me security problems, find me potential operational problems in my code. How are you going to make sure that I don't get a page at three in the morning one of these days, because my application went down due to an incompatibility of some open source software? That could be a bug unrelated to security, but it did bring it out of my application. Therefore, I think for us it's really pushing the baton on that piece. Go beyond security, how do you actually enable developers to not not just use it to get pretty cleans off their back, but they're using it because they are getting super charged in doing their day-to-day jobs.

Matt Chiodi (32:27):

This has been a fascinating conversation. Is there anything that I maybe should have asked you that you wanted to comment on?

Varun Badhwar (32:34):

No, I think we've covered a lot, Matt. A couple of things that thematically we've touched on is, I think a lot of the industry is still trying to understand and quantify what are these next gen supply chain attack vectors; what is important? We have produced some pretty good research on this space. It's not sales Z content, but if people want to go to Endorlabs.com and then click on risk explorer. It's a very interactive way to understand these emerging risks that we talked about that go beyond vulnerabilities, and so I would point your audience to that. And I think if there's one thing we all as an industry need to step up on is maybe attackers have figured out our weaknesses on the supply chain. And I think we are taking far too long as an industry to turn our ship towards the direction we need to go. And like it or not, this is one of those rare times where the US government is regulating ahead of the industry, being ready for it. Normally regulation follows big paradigm shifts and the industry option, however, this is the opposite case. I think we all need to wake up, get to work and start understanding how we can better secure our supply chains. However, other than that, it was great to be here and chat with you again about that.

Matt Chiodi (33:47):

Awesome! Well, what's the best way for our listeners to connect with you? Maybe they've got questions, or maybe you've scared them with the story of the $3,000 a month Russian who's touching 250 million downloads per month. What's the best way for listeners to get in contact with you?

Varun Badhwar (34:04):

Look, if you want to learn more about the space, check Endorlabs.com. Personally, I'd love to engage with the community, hit me up on LinkedIn, follow me at Varun Badhwar, and I’m happy to chat more and brainstorm on ways to make our supply chains more secure.

Matt Chiodi (34:20):

I love it! Varun, thanks for coming on the show, it's been great.

Varun Badhwar (34:23):

Thank you.

Narrator (34:25):

Thank you for joining us for today's episode. To find out more, please visit us at Cloudsecuritytoday.com.