 Thank you so much. I'm so glad to be. Hi everyone, thank you so much for joining me today and a huge shout out to Linux Foundation. I'm glad to be speaking at the event. Today, the topic is live hacking session because we're going to be doing some live hacking. And we're going to be talking about weakest line of code as well. So that's what the talk is all about. I'm a bit about myself. Okay, here we go. A bit about myself. I'm a security relations leader at sneak. I'm also one of the global board of directors at a wasp. I'm also on the review board of blackhead Asia grace opera India and some of the conferences in I'm the bad but besides telly. I'm also involved in some of the diversity initiatives like in for say girls and for say kids who sec to name some of them. Now, if I go ahead and look at the screen. Let's take a moment to reflect on this picture. When you look at this photograph. What comes to your mind. What is the futuristic outlook of the world, or perhaps the uprising of our robots overload that happens right for me I asked myself, what are we doing. And then, how much of the day, how much does the robot learn from about a child, or where the information is getting stored. It is stored safely, or if it is stored safely. Where does the robot get its software updates from, and can this upstream source be compromised. What can happen when it gets compromised. Maybe there is a probability that someone hacks in and can watch the video feed and talk to the child and see what what's happening around in the house. There are things that keep me up at night. So from this talk, that means you care about software, you care about software security. Most of all, you're curious like I am, how does open so security or software supply chain impact all of us. If I talk about the piece of code that we use in our own applications. How much of a code. Are we using as a homegrown code or written in house. Very less. And then rest of the code is libraries used in our code. We are using containerized applications we're using serverless functions we're using bare bone easy to installs. If they bundle up open source dependencies, then the risk is there. Yes, the open source is accelerating, however, with a great adoption comes great responsibility and risk at the same time. Free and open source is going to stay forever with us. Now when that's going to stay, we have some due diligence to pay for. So sneak advisor is something which is helping open source code and recognizing if there are any vulnerabilities and that's totally free to use that's why I'm mentioning here. Now, let me tell you about the NodeJS ecosystem, and we all work towards responsible disclosure or finding some bugs or reporting some bugs. So, Sydney also takes responsibility in reporting NodeJS ecosystem vulnerability vulnerabilities. So if you find a bug in NodeJS platform, you can report it and we are managing the disclosure program. So we have some due diligence that we're trying to do for the community. Now we've talked enough about open source, but does that the only thing that we need to care about. How about containers. The problem is using safe images is not very intuitive consistently year after year. We have not docker images on docker hub carrying security vulnerabilities and then by default. Now the result is docker images almost always bring down vulnerabilities along the great value that they have. And when we talk about great power, again, great with great power come great responsibility. And that's where we need to be very sure that we are we have the right images we have the proper images that we're using and not the vulnerable images. On top of it, we've started using infrastructure as a code. When we say infrastructure as a goal. That's why we need developer first security, we need platforms that point out the issues in the form that the developers can understand earlier what developers were doing, they were just coding the application and shipping it. And trust me, we have done it like I used to be a developer at one point, and then I moved to security. Now, being on this side I understand what are the challenges that are there on the developer side. One important aspect if I highlight now the, the era has changed there are technologies that have changed. So think about earlier they were only coding the code, like they were just writing the code. They're taking care of containers they're getting taking care of cloud and whatnot the whole environment they need to take care of. So it comes with a lot of responsibilities and then you're trying to force upon security on them. But why are we trying to do when we say the code that makes up an application has changed the in order to maintain the pace, which is required to compete in this whole transforming world when we say, there's so many things that are coming with a lightning speed. So application development is also transformed from developers coding functionality to assembling applications via a combination of proprietary tree and open source code, and even keeping containers and infrastructure as a code in them. So this increases speed, but also risk at the same time. There are vast majority of risk that comes into our overall code base, which is often open source code. Now, which creates a new open new ownership and security responsibility for the company and leveraging the software supply chain to stay competitive in the context of this whole digital transformation, often application security teams focused first on the open source code or custom code, like the tools like sast and dashed. That's all good sast and dash we've been following for a very long time, but as this is the code that their development teams are writing, but maybe the primary responsibilities to take care of that. What happens to the open source code, which quickly becomes the majority of the code like when I say 80 to 90% of the code is open source. How are we going to handle these open source code? How are we going to handle it? And especially the vulnerabilities present in the open source codes are known to attackers because it's all out there in the wild. And think about those bots, which are constantly probing to find those opportunity to take advantage of these vulnerabilities. These vulnerabilities are more likely to be found and exploited than just single hacker probing these vulnerabilities and uniquely finding them. And on top of it containers, there are hundreds of packages on the internet, which are vulnerable and we're still using it. Talk about infrastructure as a code. If I talk about a WASP itself, WASP top 10 draft version has just got released. And in that security misconfiguration is around the top. Now, when it's around the top, that means it is of some importance. There's a lot of people who have put in the efforts. There are a lot of organizations who send the data. And similarly, not just a WASP, I take the Ponymon Institute research report that also talks about the same. We need to concentrate on the misconfigurations. It's a one high priority. Now, when we are talking about that, let's rewind back in time to get an early glimpse of how one developer perceived the risk of open source software. In 1984, the Turing Award winner Ken Thompson, he wrote an essay titled Reflections on Trusting Trust, in which he describes how he added a backdoor to the login program and then he continued and added a backdoor to the C compiler and then he further continued to change the attack by backdooring the compiler that compiles the compiler. Now, in his revelation of how software can be taught to learn specific crates and then pass them on to their spawns, he explains how software can remain without a trace of a Trojan horse. Now, when we are talking about that, how about developers as a malware distribution system or vehicle as we are learned by Thompson's Trojan horse story, dated back in 1984, where that goes back long back where developers targeted as a vehicle to distribute malwares. Do we still see all of these things? Absolutely. Now, these things are more increased. Think about sourceman's SDK. Think about event stream followed by electron native notified. And in 2018, the JavaScript ecosystem witnessed its first high impact spearheaded surgical attack targeting maintainers and developers working in open source and themselves being used as an attack vehicle to distribute malicious JavaScript code design to decrypt itself. And on top of it, running a specific environment targeting developers off a Bitcoin wallet application. That's on that's again even more interesting. So this was very well known even stream incident. Now, if I tell you about the history, even stream existed on the NPMJS registry since 2011. Practically did not receive any release in the last two years, but gained millions of downloads per week out of the bloke a person comes in and on the GitHub repositories opening an issue and wanting to help as it's a custom marine open source ecosystem. They want to help the open source ecosystem, then further contribute code with several pull request, and then they create pull request that act as a dependency into the even stream on package dependency tree, which supposedly intent to improve the code base of the ecosystem. A few days later, or weeks later, what he did, he added a code payload inside the dependencies, which they added, which injects a malware into the specific Bitcoin wallet called Kobe. Because the Kobe wallet applications use even stream as part of a build process, this has gone unnoticed for almost three months, resulting in two versions released for the Kobe Bitcoin app. That's huge. And there's an academic research paper published in 2019, which investigated that properties of a language based software ecosystem and found that 61% of the open source packages on NPM could be considered as abandoned or not in use or maybe not being updated because they did not receive any release in the prior 12 months. And there are people who keep showering their back things on these things, but it is, is it right. Now, when I say it is not right, because what I feel that everyone is trying to contribute to open source in some way or the other, if a project is abandoned what we can do is we can pick up and help if we feel that yes it is relevant for the ecosystem. And if we can't do that, I'm sure we need to educate people to, to not use it but not bad mouth, any of these projects. Now, when all of that is right, how much is thought, are we giving to the security of our own development infrastructure resources like the cloud infrastructure, the staging environments and the bill and continuous integration tooling. How much are we concentrating on that. And then how much do we know about the current state of open source security and what it entails for us. If I talk about this classic case of marked cross excerpting or marked like marked in my town. So, this case study actually goes several years back marked as a markdown parser for the web downloaded millions of times a week. One of the most popular libraries for this purpose is the JavaScript and NodeJS ecosystem. But one day, a security researcher opened a code pull request which reports and fixes and access is vulnerability. That's a really good thing, which including tests for future code regressions to the proof of concepts examples. Now on the screen you would be able to see that yes, this is the time when the pull request was made. Now when the pull request was made. Interestingly, when the fix was done. So as is with the open source software. The interesting case is that maintainers are really just trying to do their best. But they can't be there all the time. It does not possible. And then there are no legal obligations or contracting obligations for them to support you. So this vulnerabilities vulnerability was left out in the open with no fix for a year. That's a long time very very long time. This security issue was proposed code fix was open in 2015, but the only merge was done in 2016. Now cherry on top of a cake, when we are all so much independent or so much dependent on open source software. So the question of where do we put our trust and what are our mitigation strategies and security controls to cope up with the risks involved. In 2017, a security researcher with the NodeJS Foundation conducted a research in which he wanted to assess the state of weak NPM credentials used by the maintainers. His work revealed the devastating truth of developers lack of security hygiene. The security researcher was able to gain and publish access to 14% of NPMJS ecosystem modules. That's a huge one. Now some of these modules are downloaded tens of millions of times a week and are essential and keep part of the thriving JavaScript ecosystem. The problem was rooted within secure passwords chosen by chosen by the well known maintainer accounts, such as literally the word password. Who does that now. Now let me put it across to you in a way where and I'm sure all of you would be using toothbrushes. And I also I'm also positive that you would not be sharing your toothbrush with anyone, like I don't share my toothbrush with anyone. So passwords are like toothbrushes. When you don't share your toothbrush, and it is unique to you. Why can't we keep our password unique and a big one which people can't remember or use a passphrase, right. So what could have happened if a malicious person would have got access to it. So many things that could have happened, right. If a malicious person would have done it. If our code packages can reach thousands of millions of developers, shouldn't we have more protection in place. And as people around software security or open source security, can we do better for our own account security hygiene. Maybe yes. So now when NPM, the largest registry of open source software packages spanning like 1.5 million packages today has supported two factor authentication says the end of 2017. Despite all the security incidents and compromised accounts happening throughout recent years in 2019 only 7.1% of NPM packages maintainers have enabled multi factor authentication. Unfortunately, this is a case with almost every ecosystem that we see. And the software supply chain security story isn't resonating enough with the developers. We still see that there are only few that there's a bit of percentage that has increased in the multi factor authentication. Now, as part of the security ecosystem, I can say that humans often represent the weakest link in the whole chain. Now when they do that. There was a term which was coined by Linus law back in 1999 by, and by Eric. Now, if I'm not wrong. Now, he said the cathedral and the bizarre, in which he explored the difference between software development, which is executed within the open source movement and that of enterprises and formerly organized companies. Now, he also stated that large number of developers and users, which you suffer, they use it with a flaw. In January 2021, it was discovered that pseudo a common utility, which is installed on many Linux distributions has a security one of a team. Now what is that, which is a heap based buffer or flow in pseudo. Now what that does is, specifically, if any unprivileged user is there, they can get access to the root access, just based on the pseudo configuration or default pseudo configuration. And on top of it, what is it's so haunting about this vulnerability is that it is hiding in the plain site for a decade, like 10 whole years. That's like humongous. And in January 21 2021, a security researcher broke into Microsoft Visual Studio code GitHub repository, essentially providing him with the capabilities of making code modification. It's interesting to know that. Now to the popular and very well loved ID that many developers use, and even I still use it, I'm going to use it today as well as part of the demo. And by using that, there was a command injection flawed that was made possible as a valid attack vector due to the flawed regular expression in that. Simply by opening a new code pull request the researcher was able to execute code that the VS code CI scripts were running without requiring any sort of authentication or authorization checks. This led to remote servers, reverse shells on the CI servers, and from there on the ability to gain push and write access to the repositories source code. That seems so interesting to me. I love doing all of this. And fortunately, the researcher responsibly reported the flaw to Microsoft before advancing like before advanced threat actors could exploit it. Now when I say visuals to your code, they are about 14 million monthly active users, like so much of download. We've reached a point where we take open source for granted open source registries are open in the nature and allow developers to openly push their packages to it. Now, we have some come accustomed, we've become so accustomed to opening an issue in a project open source code repository, and asking for help, asking for a feature asking to get our bug fixed for us. We import open source libraries to our projects. Now, that's what I've seen. I am trying to compile a code. And while compiling, I realized that I am missing out on a library, but I'm going to go to go to the internet and download it. Wow, that's so interesting. And that's when comes a point that if maintainers remove their dependencies from the registries. That is exactly the story of what happened in 2016. A maintainer, which had 10s of his open source packages from note and PMJ is one of them was very pivotal package in the ecosystem and failing to download it. Now resulting in a widespread package of CIs and install processes. And at the very least what we learned from it, the weakness is how business fail to manage these open source software and expose the soft spot. And on top of it, how registries did not foresee this on the problem, or as a problem, and so we're not designed to handle these kind of things. Now, I have so much of a, so many libraries which are there in the ecosystem, and I suddenly pulled my hand off, and things will start to fall apart. And that's going to be very, very tricky. And what kind of malicious soft activities and assets can be tracked back to the open source systems. What's inside these registries, time after time we find more and more malicious packages, hitting the NPM, NPMJS ecosystem. And if you accidentally install one of them, what will happen, you wouldn't even get to know, you wouldn't even be able to find it out. There's something which is happening. And malicious packages aren't just a thing on the JavaScript ecosystem, they're everywhere. And on March 2021, more than 3000 malicious packages were published in the PIPI registry. To further show on how attackers can harness open source to their advantage. Alex Berson published his research in February 2021 about how he exploited design flaws and package managers, registries and human error to infiltrate into corporations such as Apple, Microsoft and many more. Now, when all of this is happening. I would like to leave you with the thoughts or questions to ponder upon. Are we going to have less or more software in the future, or are we going to use less or more open source software. And on top of it, who do we trust, do we trust them, or are we missing out on something. Now, let me give you a brief of what I have talked about developers often think about the security of their app in terms of vulnerabilities that lay into the open source dependencies. Now, your open source dependencies footprint is great start to improve this application security posture, because open source components make up to 90% of the code. But what lies beyond that so much more. So what do we see next. Let's go ahead and have the environment. All right, let me go ahead and show you something interesting. Okay. So, I'm going to be doing a role play here. And that's what I like about. So I'm going to be a developer. I'm going to be an attacker. I try and not use the term hacker because we all are trying to hack our own applications and secure our organization so I'll use the term attacker and avoid using hacker to the most, but I still use sometimes. So as developer, that's the first role that I'm going to be using here, if you can see on my screen. I have visual studio code which I love, which I love totally because I it gives me wings to move around set up my own web application. Now, here, my code is there. And then I use a lot of extensions. So let me go ahead and show you one extension which is called instant instant markdown. I'm sure some of you would be using instant markdown because it's good to use it's good to have. So while I go here. It says instant markdown, the version is 1.4.6 and see the number of downloads. That's huge crazy. And it's asking me to update it to 1.4.7. Interestingly, now I don't want to update right now. I have a lot of work to do. I don't want to close my visual studio code. I'll update it. I'll take time and update it. That's fine. Now, I'll reverse the rule. I become an attacker. Now, while I become an attacker, there is an interesting thing interesting take your what it is is that I am going to be going ahead. Oh, sorry, sorry, sorry. Okay, so I'm going to be going here and hosting a website. Tell me one thing. If I ask you to to go to my website. So let me just do it itself. I have a website called InfoSec Vandana. Now you know me from the session so you might would like to open my website. Maybe, maybe yes, maybe not. But some of you might go through that. I have a beautiful website which is plain simple nothing more. Now, when that's there, I become your friend. Now I'll share a link with you. I'll say I have something very nice on this website. You might go and try. But what it is, I'll show you here. I have a php server running on my local host. I'm using ngrock to make sure that my sub domain goes to the local host and I can host my application. And this is my simple code. So now when I've given you that details. I'll ask you to open that which is InfoSec Vandana.ngrock.io. And open. Now it's a not secure code. I would not open any not secure application ever. It's bad. Now, when I've done it, there's something which is running. It says you've been had. There's nothing more. What were you trying to say? Okay. Now, let me go back and see my code. Is there something which is interesting, which is coming? No, nothing which has come. Let's see. Okay, nothing. Now, here I'm running a plugin, which is called instant markdown plugin. Now, if I use this instant markdown plugin, and then try and load the application. Now, as a attacker, I have this application set up as a developer, you have something running, right? So when I am trying to do that, you have, you've been thinking, okay, there's nothing which is wrong. But think about from perspective wherein you have something in your system which is running an older markdown plugin. Now, you're using that. Is there something that I can get from your system? Maybe, maybe not. So let's see. Okay, I can see something which is happening here. My PHP server is also giving me some inputs. Yeah, so it's the exact time if you see. And now I can see something beautiful here. There's a file which has come, which says, can't touch this password. As an attacker, I got this file. But if I am a developer from where I've got this file, like, I've got this file from a developer's account. Now, again, if I go back to the developer role, interestingly, what I can see. Here, let me go ahead and show Alice. There is a password file. In generally, we keep a lot of keys file here. What it says, can't touch this password. Now I'm an attacker, and I got this file, but I can fetch as much as information I want, which is slang over in the home directory. There's much more, which I can fetch, I can get it from here. So the most important piece is that let's keep our ecosystem up to date. I totally love this Jeff where she keeps trying to do the, to have the environment. Now, now I don't want to talk about my presentation. I want to show you something more. Now while we are talking about it. So let me go ahead, come here to let me see. Now, this is like, I keep trying to do the demos before every session. So for before this, this session also I was trying to do something. And I left it open. Oh, that's what I do. Because a lot of times demo quotes don't shower their blessings on us. So now here, I hope they do. I'm going to go ahead and let's see if it works. Oh, it works. Yeah, let me build the whole scene. I'm a person who likes to make list, like literally 123456, because I tend to forget things. And now we are all virtual. So it's even more wherein I forget things. Okay, now, what exactly do I want here. And interestingly, I want to have this particular website, which helps me with making to do the list. I'm new here. So I'm going to make, I'm going to make a registration here. I'll say one day. Okay, I'll say, no, I don't want to find my address. So you've got access to my address. I'm going to say one day. Okay, that's, that's the wrong name. That's a Linux. That's what ABCD 123 for never use this password. As I said, never, ever use this password. Now why I say that because it's the most insecure password that you can ever use it. And that's why I'm telling you never use insecure passwords. It's bad to use. And that's why I use password manager, which they're going to pop up, which I'm going to say not now because I'm going to use it for demo. I'm going to clean it up. Here comes my to do list. In my to do list, I have homework home, which is like, okay, this one that I have my account which shows my name, email address and few other things. Then this is a beautiful place where I can create my to do list. And I can upload files. I can see my files where once I upload the files, it reaches here. So let's go ahead and create a to do list. So I will say, first list. And I will go ahead and select the date 30th, I'm going to select 30th, and I've created interesting. Now I like to be a hacker. So I'll say one that is a hacker. Okay, great. I love it. My demo is going good. But let's see what else I want you. Now, all of this is good. I'll go to about, I'll see, oh, what it is your in the about I have about homepage, I can see it get a repo, then I can see a license which is there. I can see some frameworks. I believe you wouldn't find any frameworks listed in the website which is not which is like a not so good thing to list, because if I know what version you're using of what thing I will exploit it. That's what I want. You're giving me the information you're giving me the key to your house. And then I can see that there is a version which is the older start version which was vulnerable, and which was involved in a very well known breach. Interesting. Now, as a malicious person, I have some exploits, which I want to use and upload some files. Let's go ahead and choose files. I'm going to go to go. I'm going to go to move. And I'm going to go to exploits. And I'm going to put this exploit. So this is zip slip exploit, which I'm going to upload or think about. Simple uploaded. Do I see anything else. Nothing, as usual, I said nothing, nothing happened. Nothing happened to my exploit which I was running. So I went back to create a to do list. And this time I'll say one that is not a hacker. I'll select a date, which seems not so good but yes, I couldn't upload a zip file. So I'll say, let me create a list. But this time, what do you see? You cannot see the same thing when there's not a hacker. It says, hmm, gotcha. Something has happened. So something happened with my script slide. Let me create a to do list again. One is a hacker. And again, yes. Now I created. If you see, I have this on both the sides. Now why, let me come back to our presentation and show you. So this is what happened with the Equifax breach. Does it matter because known vulnerabilities are where the hackers attack because they can be weaponized exploits and exploits against hundreds of hundreds of or thousands of targets. Now, and the time window sometimes is very short. If you look at what happened with the Apache struts vulnerability, like a couple of years ago, the famous vulnerability which led to Equifax breach. I still remember it because this was one of the biggest breach. And there was only one day between a fix was released and vulnerability was disclosed or the exploit being made available. And then only about two weeks between them, and the time attacks started to pour in into the struts. Now, if you have the ability to quickly find and fix this vulnerability. The issues wouldn't have occurred. But there are times when we cannot just go ahead and say, Oh, this vulnerability I'm just going to go ahead and fix it and we're just going to go ahead and update it. It's not so easy. There is a patching cycle, but it shouldn't be a very, very long cycle. So it's critical that we detect the issues fast. We are sure that we respond to them, and we do it at scale so that we do it over and over again, we do it on all our applications. And because again, again, the majority of our software is open source and will have vulnerabilities we need to keep a track of it. This has happened with me where I was working for one of the companies and they did not have a proper repository of all the application, they were maintaining the enterprise library, but then after it what has happened. And we did it on what are the versions which we're using. And we had sleepless nights managing that, like literally, and on top of it, what happens if we don't manage our developer ecosystem and extensions power the ecosystem for the developers. So any of these are built using the open source vulnerabilities that would just been released. And meaning think about the vulnerable plugins like instant markdown 1.4.6 open and default browser 2.1.3 rainbow for 1.4.0 and many more. Now, this is the vulnerability that I was showcasing you, which is like simplest one. But if you look at this, there is a link that will be shared with you where you can actually reproduce this vulnerability yourself and see how these extensions can be really, really tricky and critical. Now, one thing to remember, be aware of what we install in our dev environment. It's very, very important to have a good documentation. If we don't have a good documentation, it's always going to be a problem for us and always be scanning. Now, what are we going to be scanning source code containers, infrastructure, and so much more. So it's very, very important to maintain. And before I go, we have Linux foundation conferences going on where I'm speaking, and we also have a sneak on coming up next week so you can join us. It's open for everyone to join. And there are so many security sessions there was a cop session around that which is there. Now, the most important of all that I said, we have superpowers of code. So let's go to security and be good to each other. That's very, very important. Thank you so much. I wanted to make it short so we can have we can take up questions in the end. If you have any questions, do feel free to reach me and post it in the Q&A I'll be happy to have a conversation. Okay, so there is a question that I can see in the question, question and answer. Hello, one that I what do you think of products the state of management framework for react, allowing end user to inspect the application data single using the Now, see, I have one thing to remember. It's not about react or it's not about npm. I just explained it the way but the key lies is that we need to use these softwares because these are good to use these are amazing. And the one thing which goes behind with this that we maintain a list of it, we keep a track of it. If there is a new update you patch that comes in, we keep updating it. That's the crux. Please feel free to type any question which is there. I'll be happy to take up any question. Okay folks if anybody has a question you can drop it in the Q&A. I'll give it down here. See, till the time you ask questions, I'm going to be here. Like literally I'm going to be here and keep it open. Or what I can do is I can also post my social media details if you want to connect with me. I'll be happy to have a conversation around anything open source and I'm sure a lot to learn from all of you as well who are joining the session. I'm happy to have a conversation around that. Vandana it does look like another question just came in. Yes. Let me just take a look at it. All righties. Okay, so what are the most common one of these we should be protecting our ISCs from. Now the first thing I would say is that we need to maintain infrastructure as a code for this configuration that's like the huge thing. The ISC comes with its own pros and cons, but the first and the last being the security misconfiguration is very, very important. And what access we are trying to give, because if we don't maintain that, then it's going to be a big, big challenge for all of us. And I have seen wherein the vulnerabilities come in ISC because we are writing this form and we are just missing out on updating the right set of permissions, like it's a huge one. And it's just the beginning. But if we don't have these default configurations, then we can save our environment to a greater extent, like literally to a greater extent. We're understanding what nodes we are spinning, what kind of access we are going to be giving to the node, when are we going to use specific function, what privileges are we going to give. And when we are using these, so ISC what I've seen that it is being used from the predefined templates. Now when it's used from the predefined templates, then that means there are default configurations a lot of time we tend to miss out on them. And another important aspect is when we are defining these templates, let's use the updated version of the software. It's very important. And what else, we can actually monitor it via central system, we can have like a continuous cycle where we keep monitoring all of these things. And sneak has open source components which you like, if you like to leverage, then you can actually go ahead and register yourself at sneak.io. There's an open source component that you can use there are many products, which covers the software code, open source component, and alongside the containers and other things. I hope this answers your question. Okay, so there is. There is a question that says, are there any reliable sources, resources like websites, etc, which list new vulnerabilities in the packages. So for every ecosystem. There are new packages, let's say, for containers, there, there are places where it's listed with the right images for no npm.js ecosystem. Yes, there is a resource where you see new and updated vulnerabilities for Java ecosystem, there is a place where you see it. Even though there are websites like threat post and many other websites which keep publishing all of these. And you can access it. Let me go ahead and share some of these with you so that it can be useful for you and just share the links. So that it'll be helpful for you. And even let me go ahead and share the sneak link where we generally have the sneak disclosure program and sneak vulnerability database, which is like huge one, and there are so many people who actually can get benefited out of it there are there are so many researchers who are working on it, which keeps updating for the new one of these which are coming and which ecosystem go Maven Cocoa boards. And on top of it let me tell you interestingly when we are managing this ecosystem we also have just integrated a new plugin which is around Twitter trending. I loved it because if there is any one ability which is trending on Twitter, you can just go ahead and go to the portal and check out which one is on the top or it comes on the top and tell you that yes this is the one ability which is stopping the charts right now. I hope this answers. If you recommend any vulnerability tools. I'm a huge fan of open source so I can recommend for software composition analysis sneak and was dependency check. So if I have to talk about best which is dynamic application security testing, then, then was zap is one amazing place to to to use. And at the same time burp suite is amazing. Like I use the community version. They are like they have commercial as well and there are many tools in the market. So please feel free to ask your questions. And if there's anything I'll be happy to answer any of those questions. And it looks like another one came into the Q&A. Sure, I'll just check. Okay, so what does detecting vulnerabilities in your system look like what kind of design principles. See, detecting fast and detecting is like you have the tools and technologies, but we need to map it right. If we don't map it right, we would never be able to detect. If we talk about ecosystem where we were using Apache. Now, if I don't know the version. I'll keep looking at it and even I might not even recognize that there is a flaw that has come in. So it's very important to understand all of this that what are the things which are currently in place and how I can leverage it to the best. So let's understand that this is our ecosystem. This is my world and on top of it, let me tell you one very important thing there are a lot of organizations, which have public facing applications public facing service, and a lot of them are not being managed. A lot of code on the code it's like a lot of open source code in the code is not even used. Now why are we doing it, and what kind of design principle, the design principle always follows and depends on the kind of environment we have. If I tell you that this is the kind of principle. No, it's not going to be sufficing because no two organization can have the similar architecture. But yes, it, the, the first step is to get to know our assets, like that's the first thing. If we get to know then we can lay down the procedure this is where we want security this is where how we want our dev secops to be. This is how I want my environment to be. And that's when we would be able to detect if any adversary comes into picture and respond to it, and as well as we'll be able to mitigate that early on. Because if we don't understand our ecosystem we don't have the right tools, or even if we have the right tools but they're not stitched together. Like, there is a solution there's a vulnerability solution they're not even speaking with each other there's no correlation. There's so much going on in the back end. It's going to be a big trouble. So, understanding our own ecosystem can help in designing the right principle. That's what I feel, because every organization has a different architecture. Okay, wonderful. Don't see any more questions in the Q&A for right now so we just want to say thank you so much for Vanda for her time today and thank you to everyone for joining us. As a reminder this recording will be on the Linux Foundation's YouTube page later today so you can view it again or share it with a friend and we hope that you will join us for future webinars. Thank you so much and have a wonderful day.