Henrik Plate -- OWASP Top 10 Open Source Risks

0:00Chris RomeoHenrik Plate is the principal security researcher at Endor Labs. He formerly worked for SAP Security Research, where he led the focus topic open source security starting in 2014. He co-authored academic papers on the topic, presented at academic and industry conferences like RSA, and is the project lead and core developer of Eclipse Steady, an open source solution using program analysis techniques to assess the explainability of vulnerabilities. And he contributes to the Risk Explorer for software supply chains. Henrik joins us to explore the OWASP Top 10 open source risks and how developers and AppSec can put this document into action.

0:39Henrik PlateThe Application Security Podcast is brought to you by Security Journey. Security Journey is an enterprise-class solution with lessons that are built on learning science principles to deliver long-term, measurable results.

0:52Chris RomeoLearn more at securityjourney.com. Hey folks, welcome to another episode of the Application Security Podcast. This is Chris Romeo. I am the CEO of Devichain and also proud co-host of something that's been running for quite 10 years, but we're, we're, we're approaching 10 years. We'll call it that. of, uh, AppSec analysis and the best guests in the business. Joined by my co-host and good friend, Robert, as always. Hey, Robert.

1:31Robert HurlbutHey, Chris. Yeah, Robert Hurlbut. I'm a principal application security architect and threat modeling lead at Acquia. And like I said, yeah, great to be here to talk about AppSec topics.

1:41Chris RomeoSo we're back on the world of OWASP. We've, we've been away from OWASP. for a few episodes, but it's one of those things, you know, it always, it keeps dragging you back in. You know, you try to get away from OWASP, but you just get dragged back into it, but that's good. So we're joined by Henrik Plate today, who is one of the project leads for the OWASP Top 10 for open source software. But Henrik, before we get to anything AppSec related, our listeners are literally on the edge of their car seats. Well, not car seats because they're not toddlers or infants, they're at the edge of their seat in their car wanting to know how you got into application security. So what's your security origin story?

2:25Henrik PlateAll right. So a few sentences about myself and how I ended up with AppSec. So in fact, I do have a developer background. Right when I finished my studies in the late '90s or so, security was not really part of university curricula. So I really went off university developing stuff and I ended up with security more by accident because my development organization was kind of repurposed to become a support organization. And so I started around and I was attracted by an applied research organization, so-called SAP Security Research. So it's part of this big German ERP provider. And so that was, a very nice, let's say, home for almost 15 years where I sat between academia on the one side, you know, reading and publishing scientific papers and between the SAP developments on the other hand side, kind of transferring back and forth either, you know, research trends and research tools to development as well as developer problems to academia for them to solve the problems. That's kind of my, what I, where I ended up in 2007 roundabout. And I did a number of different things around developing secure developer trainings, performing vulnerability assessments for different SAP products and so forth. And I started getting interested in this whole topic of open source security back in 2013. And shortly after was Heartbleed, and that really pushed this whole you know, my activities, my research topics that I started shortly before, and that kept me going until basically now. In 2022, I started working with Endor Labs, which is a US-based startup offering a platform and a solution in this whole open-source security space, let's say. Well, that's a quick wrap-up. of where I come from.

4:27Chris RomeoRobert, you're muted.

4:35Henrik PlateYou're muted.

4:36Chris RomeoSorry.

4:39Robert HurlbutYeah, Henrik, uh, just curious. So, uh, we're talking about the OWASP Top 10 for open source software. What is that? And, um, also curious about, you know, creating another top 10 list.

4:52Henrik PlateI know there are so many top 10 lists out there. Why do we need another one? Maybe we need a top 10 list of top 10 lists. I, so I completely, completely agree to this confusion kind of. So why did we create this thing? Or maybe first of all, let's start and describe in one sentence what it is all about. So what we wanted to do is come up and compile a list of risks, security risks, but also operational risks. that matter for everybody relying on open-source upstream dependencies. So impacting kind of the security posture of their applications, but also, you know, resulting in operational problems. And we felt this is necessary because until then, the open-source risks, at least as part of OWASP, they were all condensed in this one single risk number 9, what, in 2017, I think it was the OWASP Top 10 risk number 9.

5:49Chris RomeoYeah.

5:49Henrik PlateAnd 2021, it became and was promoted to risk number 6, if I'm not mistaken. But the thing is that this risk, this whole, well, let's say the whole problem space of using open source software is so big that we thought we cannot cover this all in one risk, you know, and mingle it one in one, in one thing. And so we, we thought it's better to, to describe this more fine granularly. And, uh, so give people the possibility to devise safeguards and address them, you know, on, on a better granularity, let's say. That's kind of the motivation.

6:26Chris RomeoSo what's the source of this though? Because when I think about like the OWASP Top 10 for web, Andrew and Brian, um, and the rest of the team go out and do a data request, and they collect all this data from different web providers, scanning companies, and they put that data all together, but then they also add a couple of items that are community-driven. So what's your, what's your strategy? Like, how did you come up, how did you decide that these were the 10 things that we really need to care about for open source?

6:59Henrik PlateSo this, I really like the data-driven approach of the kind of original, if you want, OWASP Top 10. But we didn't go that far yet. Maybe this is going to come in the future, but so far we didn't do the same kind of effort. So the way this worked out was we basically, you know, looking, studying academic literature as well as, you know, also inspired by all the kind of vulnerabilities and supply chain attacks going on and, you know, working this whole open source space for very long. Also, I've been a maintainer for a good number of years of an Eclipse-hosted project related to reachability analysis. And so it's both kind of my experience, the experience of my research colleagues that came up with a draft list. And then we started circulating this draft list with more than 20 CISOs and CTOs of different known companies. And, uh, and in several iterations, we basically shaped the, and defined the, those risks and their scopes as, as well as the order. We also dropped a few. Um, yeah.

8:16Chris RomeoSo is the order in this list mean something, or are these all the 10 things like we just need to care about, like Because I've heard Andrew talk about the top 10 for web and by saying, these are 10 things you need to care about. The order doesn't matter. Like we didn't put them in any, like number 1 is not more important than number 10 or number 9 or 8 or whatever. So what's your take on that?

8:40Henrik PlateYeah. So again, it's not data-driven. It's more a subjective feeling on what is, what are the most pressing problems. And that's why, little surprise, this whole problem of known vulnerabilities in open source components. Uh, ranks, uh, at the first, uh, place. Uh, but, but again, it's not data-driven. It's, uh, an order established during the review and compilation process with those 20 and something, 20+ contributors.

9:08Chris RomeoOkay. So I need to care about all 10 of them. I can't just say the top 2 are the ones that I really need to worry about for 2025. I can share, I can wait for 2027 for 3 through 10.

9:21Henrik PlateLet's say, I would say they do have a different level of urgency or severity, and that is also one reason why we, you know, took them out and split up the original top 10 because if you, you of course need to care about known vulnerabilities, right? There is a new published, yet another one. I think in 2025 we have forecasted probably another record year of CVEs being published.

9:48Chris RomeoYeah.

9:48Henrik PlateAnd so this is of course very, very important, more important in my mind than let's say, you know, tracking unmaintained projects, right? So this is an activity that is probably less time critical compared to new advisories, new known vulnerabilities. That's something you have to keep in mind as a, you know, as a best engineering best practice or so, try to, uh, observe the maintenance level or the maintenance status of all your upstream projects. But it's, it's not as, you know, the degree of urgency is definitely different from, you know, vulnerabilities.

10:29Chris RomeoYeah. So if I'm a developer, what, how do I use this, this document? Like, what's the value for me as, as somebody who, let's, let's say they're not an AppSec person, they're just, I mean, you said you came from development as well. So imagine yourself at the start of your career. If you flash forward to that point of your career to today, how could this document be useful to you?

10:54Henrik PlateI think every developer or maybe every development organization should read through those lists and shape their own kind of AppSec program around it in order to make, to have some controls, shape their controls, select controls. to meet all the different or mitigate all the different risks, let's say. So it's not that we have very concrete, easy to apply, actionable advice. That is, some of the problems we talk about are very difficult to tackle. Let's say, I don't know, the problem of over or undersized dependencies, which is, I think, the last one, number 10, right? So to understand how much you use of a given open source dependency is nothing that there, there's no tooling ready, right? So there's, there's still to, to really address many of those risks, there's, these are open research problems. And so that is why it is hard to have very actionable, you know, recommendations. So my takeaway is, my advice would be go through those risks. And try to see whether you can develop best practices and controls in your development processes in order to kind of systematically address this. If that makes sense.

12:15Chris RomeoYeah.

12:20Henrik PlateYeah. And, um, and I think this are, this are, this are also, so one of the future, let's say, additions and works I can imagine would be to really develop some kind of metrics to get a feeling for how for your exposure, how, you know, how relevant is that risk for you? How well did you address it? And those metrics again are not readily available. So there, there's a lot of development still required.

12:46Robert HurlbutSo I wonder if we could start to walk through the list, if we could take, you know, some of these and check them out. So do you mind starting with the first one and talk to us about it?

13:00Henrik PlateYeah, of course. So the first one is the problem of known vulnerabilities in open source upstream components, upstream dependencies. This is something I've mentioned this already in the beginning, right? So this whole topic got a lot of attention, at least starting with Heartbleed, and it's all about you depending on a component that has a vulnerability. And then the question for the developers to answer is to understand and assess whether that vulnerable code in some upstream dependency is really exploitable in the context of your application, which of course is not always the case because you maybe only use a fraction of the code base of that component, or maybe the component not at all, in which case it would be kind of a bloated dependency just hanging around, but you do not actually call into it. So it's all about, you know, learning about new advisories, monitoring the corresponding feeds, and then assessing the relevancy in your application. And then of course remediating this vulnerability, which can be done in various ways, right? The easiest would be to just update to a non-vulnerable version, but then of course that is easier said than done. Because depending on which version you're on, an update may be very difficult up to impossible. And so then you need to think of, you know, maybe developing a control, a countermeasure in your own application, doing something in your infrastructure or environment to prevent exploitation and so forth. So this topic alone is a super complex thing, right?

14:40Chris RomeoWhenever I hear somebody in public, like at a, doing a talk or something, when they're talking about supply chain, And they say, well, you should just update the dependencies. I'm like, you've never developed a modern application in your life. Like, I know that just, you just, that just, the whole talk is like, okay, you don't know what you're talking about if you say that you should just update it because you've never dealt with, sometimes there isn't one. There is no fix for it yet because it's open source and it's, it's volunteers and they don't work nights and weekends. Sometimes they take a break and they don't. Put out a fix when you need it for your production application. So that's—

15:17Henrik PlateOr maybe, and even if you're lucky and there is a fix, there may be some breaking changes. Maybe they changed the API, the method that you use doesn't exist any longer. It has additional parameters. God knows what went on between your version and the fixed version. And describing this, detecting such breaking changes, again, is a research topic. If you follow academia, if you follow the publications on arXiv, there are, there There's a continuous stream of publications around breaking changes, breaking change detection, and change impact analysis. So yeah, I, I completely agree with you here.

15:54Chris RomeoI think AI is gonna solve that all for us, so don't worry about it. It's taken care of.

15:58Henrik PlateYep, yep, yep.

16:00Chris RomeoAI is the answer to everything. I just say that in case Skynet becomes a reality.

16:05Robert HurlbutRight.

16:06Chris RomeoOkay, so I'm looking at OSS Risk 1. You've got, we talked about the description. You've got some examples. You've got actions in here. So monitor applications, containers, and systems for the presence of direct and transitive open source dependencies, and then prioritize the analysis and mitigation of those based on CVSS, EPSS, KEV, and then DAST and SAST tools. So you've got some, you've got some actions that can be taken as a result, I'm guessing, of each of these. So as a developer, I could, or an AppSec person, I could come in here. I can understand what the item is. I can reference some examples, but then you've got some ideas about what I should do, what I could do to mitigate this problem.

16:50Henrik PlateExactly. But of course, all the 3 topics you just, or the 3 things that you read out, it's not something that you can do or that a developer can do easily himself, right? He cannot spend hours on looking up websites. And, you know, performing code reviews and stuff. So it boils down to criteria for tool vendors, right? So you, if you go out and pick your open source or commercial solutions, you gotta, you know, check what are your important requirements and are those met by the different tool vendors?

17:24Chris RomeoYep.

17:26Robert HurlbutAll right.

17:26Chris RomeoSo that takes us to number 2, OSS risk 2, compromise of legitimate packages.

17:33Henrik PlateYeah, well, that's a topic that also got a lot of attention over the course of, let's say, the last 6 years or so. I think it's around 2018, '19 or so when the number of malicious packages being published on PyPI and npm started skyrocketing, right?

17:55Robert HurlbutYeah.

17:55Henrik PlateAnd since, and ever since it It is a hot topic and it's, you know, the number of plenty of exponential curves all around if you look at white papers and so forth. And so this is, this risk is all about basically your open source, the project that is producing your, you know, components has been compromised in some way or the other. For example, the, I don't know, the maintainer of your project used weak passwords, and so the attackers were able to just, you know, go on GitHub and, you know, create a pull request or change code right away in the source code repository of your upstream component.

18:36Chris RomeoYeah.

18:37Henrik PlateOr maybe he was reusing credentials, those were compromised, and again, the attacker could just use the compromised ones to log on either to GitHub or maybe to PyPI or maybe to npm and publish a malicious version of your upstream dependency on those registries. So that is, yeah, happening on a regular basis. So every so often we see that this happens. I think it's got, it got a lot better with some registries, more and more registries imposing 2-factor authentication, like for PyPI. I'm not sure whether you followed this, but in a multi-step process, they were urging first, I think, the very prominent, highly used packages to use package maintainers to enforce and use 2-factor authentication. And they continuously extend the, you know, the list of accounts that require to do this. So that got a lot better. In the beginning, that was a, so this kind of stolen credentials was a very prominent attack vector.

19:42Chris RomeoAnd this, XZ was a more modern example of this, right? Where it was more of a— is that a separate— I'm sorry if I'm jumping ahead. Is that a separate category of human-based attack?

19:54Henrik PlateNo, no, it's the same attack. So what is— because you may be confused by this number 2, which is a compromise of a legitimate package, and number 3, which is these name confusion attacks. They can be both seen as supply chain attacks, but they have one important difference. The number 2 is really there is an existing project with legitimate maintainers, legitimate components, but in one way or the other, the project got compromised.

20:26Chris RomeoYeah.

20:26Henrik PlateAnd there are many different ways for attackers to achieve this goal. We in fact have kind of a, there's a paper which explains or which shows a taxonomy of all the attack vectors at the disposal of attackers, at the disposal of attackers to compromise a package. Now that is 2, and number 3 is different in the sense that attackers can just come up with arbitrary names, typosquatting attacks, publish this, and deploy this in a registry. I find that this is different, or we found that this is different because here it's really easy for the attacker because he does not need to compromise any existing resources. Right? There is no maintainer of such a project. The name is not yet taken. It's just as easy as to, you know, deploy it, push it, and it will find a few victims. So we found this difference worthwhile to be made. That's why we came up with the distinction between 2 and 3. But they both result in the execution of malicious code on developer workstations or at application end users. And XZ, coming back to this, is part of number 2, right? Because there is this legitimate project, and then there was this very sophisticated long-term attack, which I think lasted over a year, where he gained confidence, had maintainer permissions, And then, uh, manipulated test resources in order to eventually plant, uh, the Spectre. So that was a very frightening, uh, instance of this risk number 2.

22:13Chris RomeoYeah. And that's, and that's a common problem in the open source world. I mean, you could also lump together, um, orphan projects in under, under 2. Right? Where somebody works on something for years and years and they're like, I just can't deal with this anymore. Yeah. So they either let it go and nobody's maintaining it, or they quickly hand it off to somebody else that they don't really know and trust because somebody else says, oh, I'll make it work.

22:45Robert HurlbutYeah.

22:45Chris RomeoYeah.

22:46Henrik PlateOf course. And I think, and I, I find this, there's some, you know, kind of intrinsic let's say, challenge for the open source community in this, that, I mean, it is dependent on contributions. And of course, maintainers are open and are willing to, you know, receive contributions, which is kind of playing into the hands of attackers pretending they provide some value in one way or the other, but in fact, under the hood, inject some malicious code here and there. So I, I find this, um, yeah, an interesting conflict, let's say.

23:23Robert HurlbutYeah.

23:25Chris RomeoSo I think we can skip over, we talked about 3 already. I feel like 3 is one of the ones that's most known. A lot of people have written a lot of blog posts about typosquatting and we said, we, I mean, it, it, it started in the world of DNS before we ever got to package software, right? You know, you could go to Google with a, a 1.

23:45Henrik PlateYeah. Yeah. I found this, this whole problem of name confusion attacks is just common, probably to just every kind of application marketplace. Whenever you offer a product with a name, you run into the same problem.

24:02Robert HurlbutMm-hmm.

24:03Henrik PlateAnd well, it could be, it is, it has been very much discussed for, you know, uh, PyPI and npm component registries, but the same worked and works for GitHub repositories, um, Jenkins plugins, and, you know, Visual Studio Code plugins. You just, just name it and you will have the same issue of, of, of name confusion attacks.

24:27Chris RomeoAll right, so what is 4? Unmaintained.

24:35Henrik PlateYeah, here the, the This got some attention, I think just recently with the, some Go components being discontinued, right? So there was a, I think it was the Gorilla Web Toolkit, which was a, which is a very prominent Go package, which where the maintainers decided they cannot keep on with the maintenance and they basically stopped it leaving, you know, leaving the users a little bit in the rain, as we say in German. It's a German expression. I'm not sure this is working in other languages. And so, yeah, that is basically requiring the users, the developers to monitor their dependencies in terms of how active is our projects maintained, you know, are there regular commits? regularly new versions being published, how active is the community and so forth. And then when they detect that, you know, activity levels go down or maybe hopefully as early as possible detect this, think of maybe architectural changes or other ways to work around the discontinuation of such projects. Yeah, that's kind of unmaintained software. It's, it's, it's more, I think it's more, first, it's more an operational problem, right? Because it's not only impacting security, it's also operating, it's affecting, you know, coming with, you know, standard bugs, let's say.

26:11Robert HurlbutMm-hmm.

26:11Henrik PlateUm, but it can of course also become security relevant as soon as there are vulnerabilities detected.

26:17Chris RomeoMm-hmm. So let's jump past 5 and 6 and pick up number 7 here. So 5 was just outdated software. Project uses old outdated versions, though new versions exist. 6 was untracked dependencies aren't picked up by tooling or SBOMs or whatever else. So I feel like those are pretty straightforward. I feel like license is part of open source that most engineering development teams are like, license, that means talk to legal. That's their answer. Like they don't understand really what it is. So let's, let's unpack that one. Like what is license risk?

26:51Henrik PlateWell, let me start with the obligatory, well, I'm not a lawyer, but. Yeah, so here the idea is, it's, I, so the idea is basically that, of course, if you use your open source dependencies, you need to comply with all the, you know, provisions of the licenses coming with the respective component. And it's not only about those licenses that you need to, first of all, you need to discover and track them. And then, but it's not only about licenses, but we wanted to enlarge this a little bit, but also talk about other kind of regulatory requirements. And the one example that comes into my mind is the use of cryptographic technologies. So when, kind of, I was working on this open source project also. I had to, when releasing this as open source, I had to talk to our legal department indeed and had to explain whether we use any cryptographic components, right? And so you basically need to also comply with the crypto export regulations. And so just as another example, going beyond the mere license risks. That, yeah, this, this is, I think, a topic that I don't know if it is covered well or at all by kind of existing tools, open source or commercial. Um, license, yes, but not kind of the, the, the crypto-regulated ones.

28:27Chris RomeoOkay. So Robert, why don't you, uh, pick one between 8, 9, and 10 that we can close on here as far as our final one, and then Certainly folks can go, this, this project is OWASP. It's on the OWASP website. So it's available to go dive into, study closer. Uh, we're just trying to do a broad brush review over the top. So Robert, what do you got between 8, 9, and 10? Which one do you want to unpack?

28:54Robert HurlbutYeah. So 8 is immature software. 9 is unapproved change or mutable. And 10 is under or oversized dependency. I'm going to pick, I'm going to pick 9, unapproved change or mutable. I'm curious about that one. Yeah.

29:12Henrik PlateSo yeah, here the idea is basically to inform developers about the risk coming with the consumption of artifacts that they don't, let's say, they don't have any control over. Whether they change or not. And a typical example is the typical curl bash, right? Curl bashing. You just, you have so many kind of CI/CD scripts and tooling that just, you know, makes a curl request to some shell script of some repository and then execute pipes that shell script into bash to execute it locally. And you have little or no control about Or depending on how you implement it, of course. But the problem is if you do not control whether what you have downloaded stays stable, basically, because you don't, it could be that somebody changed that script and suddenly you execute other stuff in your console. And that is exactly what happened with this CodeCov Bash uploader, right? It was a script related to code coverage. And that was manipulated kind of by an attacker. And so suddenly malicious code was executed. Another example similar to curl bash way of processing input is the GitHub Workflow Actions, right? Which you can also, you can reference an upstream or a GitHub workflow. just by pointing to the main branch of its GitHub repository, and then you will just pull and execute whatever is on that main branch, opposed to pinning a certain version or opposed to even better, a certain commit, or opposed to maybe, you know, checking the digest and verifying the digest of what you downloaded. So that's all about, you know, being able to keep track of changes in your upload dependencies. And so also approving such changes. That's why we ended up with the name unapproved change.

31:27Chris RomeoAll right. Well, thanks for taking us through that kind of overview of these. I know we could dive deeper into them, but I want to encourage our listeners to go look at the project, dive deeper into it, understand it by reading it and interpreting it yourself. And if you got questions, certainly hit up Henrik with those. Uh, but with that, I believe it is time for the famous or infamous, I can never remember, lightning round.

31:57Robert HurlbutAll right, Henrik, we have 3 questions that we typically ask. Uh, so the first one is, uh, what's your most controversial opinion on application security and why do you hold this view? Okay.

32:10Henrik PlateSo one, I'm not sure whether it is very controversial, but after having worked on this whole open source topic for, for several years now, I have the feeling the, what is really broken is how we keep track of vulnerabilities in software components and open source components in particular. So we have a diverse number of databases, you know, keeping track of such information with both public databases, but also private databases. The private databases are not really shared. We can just, you know, get a glimpse of them by using the tooling. But overall, this whole space is very, let's say, inconsistent and transparent, and users have very little means to get to the ground truth. of what is a vulnerable function in some open source component. So I think at the, that is a very fundamental problem I see in this, in this AppSec space, vulnerability space.

33:13Robert HurlbutThank you. Second question is, if you could display a single message on a billboard at the RSA or Black Hat conference, what would it say?

33:27Henrik PlateI would like to, don't reinvent the wheel. Um, and this is, let's say, something that I, that I look, uh, what I learned or what I experienced when looking at the different ecosystems. So there, there, I mean, there are, there are certain, there's the Python ecosystem, the JavaScript ecosystem, R and C and Java, and you, you, you know, you go on, right? And all of those ecosystems come up with their package managers and their registries, and I have the feeling that they are kind of reinventing the wheel and there's too little lessons learned from previous problems. And so maybe this, what we have discussed earlier on, right? So you have a name of a component, it is removed from a registry, and then, you know, the attacker just picks the name. That is something that It's, again, it's common to every registry, but not all. But so let's say it's a risk or a problem that has to be addressed. Some registries do this well since a long time, and then new registries being developed just shortly, they still offer this opportunity. Here in this regard, there is a very nice activity going on as part of the OpenSSF where they provide guidelines on registry developers, and I think they also address this problem. So do not reinvent the wheel when you develop your, you know, package manager and registry. Okay.

35:01Robert HurlbutUh, the 3rd question is, what's your top book recommendation and why do you find it valuable? Uh, some folks have given us, uh, security books or even not a security book, But what's your top book recommendation? Hmm.

35:16Henrik PlateUh, can I pass on one? I don't have any book recommendation ready, I must say. Do we have a, of course, a second question, a third, or another backup question for this?

35:25Chris RomeoWhat's the best movie you saw in the last year?

35:28Henrik PlateThe best movie I saw in the last year?

35:32Chris RomeoNot just 2025, 'cause that's only 13 days old, but In the last 365 days, give you a better little broader spectrum.

35:41Robert HurlbutOkay.

35:44Chris RomeoHmm.

35:46Henrik PlateOh, I think I liked, uh, very much. So what was the title? It was very, um, yeah, it is a kind of, it was a historical movie. Um, it's a series, it's actually a Netflix series. about kind of immigrants from Germany and the beginning of the Second World War. It was very touching to see kind of how, in fact, the US Embassy in Marseille, or at least some parts, some members of the US Embassy in Marseille, southern France, which is where I live, they helped immigrants to kind of flee Uh, the war going on, you know, get the visas to go to the United States and so, and I found this very, very touching and of, and then it had this local, you know, aspect for me because I'm living close, close to Southern France, close to where all this happened. But I don't recall the name.

36:50Chris RomeoUm, uh, yeah. Transatlantic.

36:51Henrik PlateYes. Yeah.

36:52Chris RomeoIs that it? Thanks.

36:53Henrik PlateOkay. Yeah, thanks.

36:54Chris RomeoI, uh, Google to the rescue, so. Cool. So, um, Henrik, and what would be your key takeaway then as we, as we wrap up our interview here? Like, what do you want our listeners to do or call to action or key takeaway for them? What, how do you wanna end the conversation?

37:12Henrik PlateI would like to end the conversation with a, you know, with a call to read through those risks and kind of provide feedback on whether what we came up with those CTOs and CISOs make sense, what, you know, what kind of additional links or toolings for the different languages also matter and which we should link in order to improve the content. I mean, I know from past that maintaining an open source project alive really requires a lot of dedication and time and effort and so maybe Yeah, I, I would love to see this thriving and, um, I would, yeah, I would really ask for your feedback on this.

37:58Chris RomeoSounds good. We'll get folks, get out there and take a look at the OWASP Top 10 for open source software. You'll find it on owasp.org and a link to it in the show notes. Henrik, thanks for sharing your knowledge and expertise on open source with us, and, uh, we hope that a lot of folks will go take a look at this document and dive into it. So have a great rest of your day and thank you very much.

38:22Henrik PlateThank you for giving me the opportunity to talk about it.