Nice to meet you, everyone. I'm Alexandra. I'm a solution engineer here at Snyk. And today's presentation and workshop would be around open source
security and finding, fixing and hacking an OGS application of vulnerability
security. So if you want to, you can share your camera. I'm Matt. I'm a solutions engineer in Snyk. Yeah, I'd be here just to kind of linger in the background and answer any questions you guys have in the chat and to curate it so that Alex has a little bit of leeway on that side. Yeah, nice to meet you all. Yeah, I think the main thing we want to get out today is kind of understand what it is that you want out of today's session. So if anyone is feeling brave to come off mute and introduce themselves and tell us a little bit about you, what you were hoping to get out of the session, so it'd help us to kind of improve as we go and also make sure that the sessions are relevant for you guys or girls. Ilian, any intro? No, no intro for me. Just to see if it goes well, I would say, please use your camera. Let us know what you want to get out of the session. Make it interactive. I think also fun for you to engage with us. And hopefully we will get to see you at the actual event days, either on a Thursday or Friday in Amsterdam. And be sure to pass by our booth because we have something ready for you, since you joined this workshop. So if you're there in Amsterdam as well, please join us during the days and come by for chat. Yeah, please come say hi. I will be there in person. So it would be nice to actually interact in person. Okay. Awesome. Then if everyone is ready, I can start the presentation. Okay. Let's see. Okay. It works. Everyone can see my screen? Yeah. Awesome. Okay. Great. Well, I guess we can all agree about the unicorn in the room that open source is indeed awesome. And as a software has become widely used over the past years due to his nature, his collaborative and public nature, and simultaneously making it really convenient for us as developer, but also for bad actors to use. And cases like Lope4j, it's shown that open source
security, it is a real and a serious risk to organizations. So I think nobody can actually argue the fact that open source software has made an incredibly huge impact on modern software development, and it continues to expand over here. As you can see on the graph, it's a real testament of how awesome open source it has been and how much growth it has in some of the largest open source package registries that are in the market. In fact,
npm is the leader. I think every year
npm comes as a leader and it has a 33% year on year growth. And earlier this year, 2022 in March, they've passed 1.8 million packages in the registry, which is incredible. But again, considering the fast growth and how many open source packages are in the market, we are also seeing continuously growth and vulnerabilities within open source. And these vulnerabilities need to be mitigated by anyone who owns or maintains or even use open source software, right? So it's quite hard to imagine creating an application aside whatever software to write something without using open source dependencies. Every website that you enter has functionality based on libraries that are written by someone else, right? And we all use them. After all, of course, the applications that we deploy don't contain only our source code, the code that we are writing, but also dependencies that rely on that application. Unfortunately, the majority of open source vulnerabilities that we have discovered in
npm are 86% of them. They're actually indirect dependencies. And those indirect dependencies are the ones that are actually really hard to see and we have less control of. So when it comes to open source and the importance of open source is really a key to talk about open source
security, right? Open source
security takes into consideration the risk and the vulnerability that you brought into the outside world, your third party software components that you bring into your code application. And of course, it addresses the tools and the processes that you need to take ownership over in order to secure those open source components. Using open source, unfortunately, means that we as developers rely on other strangers, maintainers, to actually maintain the code of that application and maintain the code that the application, our application relies on. So it's quite essential to manage open source components and dependencies to mitigate that risk. Also, we know and we understand the pain of and how difficult it is to have visibility and to maintain visibility across all open source components used within your application. And it's quite a tedious task to maintain and to look to every open source component that you have and compare that to a known
database of vulnerabilities. What I want to do now is have a bit of a mental exercise. So imagine that this big orange blob, this orange blob is your application. The application that you've written for a year, I don't know, six months that you've put your soul into it. Now it's working. It's perfectly live and in production. Every function works just fine, right? Unfortunately, the reality is that this big blob, the application, the code that we are actually writing, it's really like significant, really small, a significant part of that whole blob that we have imagined. And all of us actually rely on
community powered base code. And we're leveraging that code, that beautiful open source world for us, you know, to increase our
productivity instead of writing functions that are already in the market, we are focusing on improving and innovating tasks that we've never had this time before. The whole idea, the exercise, maybe to put a question is how much do you really know about your dependency, right? How much do you really know about what you have brought in your application code to your libraries? Application as today actually consumes lots of packages, lots of
npm packages, often hundreds and thousands of them. And we often overlook that with those packages and their great functionality. Also, we have pulled in some
node.js security risk, right? And many packages open new ports, thus increasing the attack surface that we might have. And roughly, we have found that 76% of
node.js shops use vulnerable packages and some of which are extremely severe. Unfortunately, with the nature of open source, projects and packages sometimes tend to go stale and maintainers don't have the time to fix the
security flaws. So, I wanted to use your expertise for a bit of a question and answers, if you want to. So, we have a
security report. I think it was in 2019 and 2020 that covers many registries across the system, across the
ecosystem. And we found that there are actually really a lot of misconceptions about packages and especially about
npm registries. So, I wanted to use your expertise in this case and maybe answer three top misconceptions that we have found within that report. And you can leave it in the chat, the responses. I'm quite curious to see what you think. And the first question would be what is the percentage of packages on
npm that have no dependencies whatsoever? And you have the possibilities, the four possibilities put there in the slides. So, what do you actually think of? The rough percentage. Okay. 12, 6. 6? Okay. A lot of people say 6. Okay. Good. The correct answer, though, is actually 28. So, 28% of packages on
npm have no dependencies whatsoever. So, that is quite a large number of packages if you think about that now in the
npm registry, there are 1.8 million of packages, right? The next question would be what is the average depth of a package dependency chain, right? On
npm. So, think about a dependency tree and the length of that dependency chain. What do you guys think? You're actually really close. Yeah. Okay. I see a good answer. I've seen a 4. So, the correct answer is that the average of depth of packages dependency chain in
npm registries are actually 4.4. So, it's quite a bit higher than 4. But making an assumption that
javascript developers favor actually creating smaller chunks of code and using those chunks of code, use them actually across their projects, right? And the last question, and I will leave you with a question. No more questions from my side. Is how many packages on
npm could be considered to be abandoned? Abandoned in the sense that they had no release in the last 12 months. You're really kind. Yeah. I see 61. So, the correct answer is actually 61. So, 61% of the packages on
npm did not publish a release in the last 12 months. So, that is quite a bit of a number, right? And you might say, yeah, but it's not a big deal because we know that there are packages with a huge history with no vulnerabilities. Unfortunately, we have found that
security vulnerabilities appear in time. And it takes a lot of time even for maintainers to notice that there's a
security issue within those packages. Based on that report that I just mentioned, what they consider to be a good point is that based on the research, all of these ecosystems that they have targeted, they are good right for exploitation and the number of incidents they say that will only increase in the future. So, unfortunately, that is the reality of open source. And even though that it's the best thing that happened in the software modern development industry, it also comes with a great risk. A great
security risk. So, I wanted to touch base on how those packages could get infected. There are many ways. There are many types of attacks, many methods. And one might be to, I don't know, to infect an existing package by injecting malicious code into the sources during the build or into the package registry. And basically, we will take an innocent pull request that would contain a malicious code and for that project or that project maintainer to, you know, actually merge it. Another method would be uploading malicious packages to a repository or to a repository mirror. But the most common use, the most let's say vicious one is type of squatting attack. And what that does, it's a bad actor that is pushing a malicious package to a registry with the hope of triggering or tweaking developers into actually installing them. And we've seen these types of attacks across Python and
node.js registry and with the most, let's say, not worthy is cross environment package. What that attacker did, it took the similar name of the popular package and it had the same functionality within it, but also it captured environment variables and sent them to an attacker controller remote server. Sorry, my cat is trying to do stuff and I'm still petting it. But this is some ways that your packages and your libraries can get malicious code into them. And for sure we've seen that a lot of bad actors actually exploit those vulnerabilities. So if everyone is okay and we don't have questions so far, I will actually go into the hacking or trying to explain a bit of what we're going to do and go to the actual workshop. So as you already know, attackers do prefer to target open source. And they know that by targeting one vulnerability, they will have many victims and many organizations to target. Right? So what I wanted to discuss and the package that I wanted to discuss on
npm is marked. So marked is a highly used package. It has nearly 5.5 weekly downloads. And if I will go to sneak vulnerability and if I already searched it, but this is the package. And as we can see, even though that it's highly usable, it has all sorts of vulnerabilities within this package. And the latest one, the latest disclosed one is in 2022. So this year. And what we are going to inspect and try to exploit is a cross-site scripting vulnerability. This specific vulnerability was fixed in 2016, but it has a good open source story and why is
security so important when it comes to open source? So as I said, we are going to target a cross-site scripting vulnerability. So if you don't know, a cross-site scripting attack will occur. A cross-site scripting attack will occur when the actual attacker tricks a legitimate web-based application or a site to accept a request originated as a trusted source. Right? So this is done by escaping the context of the web application. And then the web application itself will deliver that
data to a user alongside with other trusted dynamic contact without actually validating the request. So the browser unknowingly will execute that malicious script. In our case, it's going to be a
javascript. And in order to perform those actions that are otherwise blocked by the browser's same origin policy. The whole idea when it comes to cross-site scripting and what it does, it actually breaks the browser's same origin policy. And that is exactly what we are trying to do. So you are well aware that each time you visit a website, your browser will download
html, SSS, and
javascript from the server that hosts that website. Right? And then the browser by itself will interpret it and display the
html and SSS and also will execute the
javascript. And what we are trying to do is basically commit a malicious
javascript code within our application and see what it does. Knowing that through the cross-site scripting vulnerability, users can actually have sensitive information in their hands. They can steal secrets, user credentials. They can inject all kinds of different malware into your application. And they can even change the appearance of the certain website to treat the users of doing action that they will normally do within that website. So giving a bit of context about Markd itself and the package, I don't know if you know, but Markd is like a low compiler for Markdown. It actually parses Markdown and converts it into
html. And Markdown is something that is really highly used in the world that we actually live in. A lot of blogs, a lot of sites like Reddit or even GitHub. So the readme in GitHub actually supports Markdown. So you are at the end of the day will come across Markdown even if you like it or not. What we know and what they say is that Markdown actually doesn't support
javascript. Right? And therefore, they are saying that they are immune to cross-site scripting. But that is not necessarily the truth. Because they are still using Markd. So in Markd, we can have access to links. Right? Inline
html. So within inline
html, we can include script, tags,
javascript links that can be used by a hacker, in this case us, to inject malicious scripts into an application. And what that attacker will do is basically bypass the output sanitization within Markd that it's currently set as. So if I will look into my code, this one, I will know that this output sanitization, this is currently set as true. So it's okay with everyone. I can give you guys one minute if you want to do this along with me. And if you want to download the GitHub repo and do it locally. If not, I can start. So just let me know if you want to do it in the same time. Do you have the information? Okay. Following the presentation. Okay. Great. So what we have here, you can see my screen, right? I'm not showing something that okay. What we have here is a goof to do application. It's a simple, basic to do application that uses Markd as a library. And we already know that it's vulnerable for cross site scripting vulnerability. So what I'm going to do here is just say hello, everybody. And it works. It works fine. Nothing wrong here. But what if I want to do I don't know. I want to actually buy something, quite important item after pandemic. And we know that this Markd did the Markd down. It did exactly what it intended to do. It basically bought the beer item and it worked just fine. But what if I add an URL as a hyperlink, right? So if I would use link. And use link. What do we do now? I think that it's correct. We're not forgetting something. But as we can see, it worked just fine. It created the link. I can click it and it will direct me to the Snyk website. All good. Nothing wrong here, right? So again, what we know is that Markd down doesn't support script. But what it does, it supports links that can access the potential of
javascript links and that can cause by themselves a lot of damage, right? So let's see if I can try and put a
javascript. Okay. Let's see what happens. Okay. So something has happened. Something is not quite right. And if we go to inspect this, we will see that this, what we tried, the
javascript, actually didn't work, right? And it didn't work because inside the Markd source code, right? Most likely there are different types of regex and some of them include
javascript.
javascript.column. Remember, we said the sanitization protection output is set as true. So what that does, it actually looks at all the different things that we are trying to input, like
javascript, column, whatever function that we want to have, and it's actually sanitizing them away, right? But what I can do next and what I can try is to use the
html encoded character. So if the sanitization is only looking for the
javascript column function, maybe I can actually surpass that and maybe I can represent that column in a different way as an
html entity and I will basically break the sanitization. So if I put, hopefully I will. I don't know.
javascript. So as I said, instead of using the column, I will use the
html entity to represent the column, right? So it would be 58, right? Alert. And also representing the parentheses here. So let's see. Hopefully I write this correctly. I did. But unfortunately, or thank God, the sanitization worked again. So in this case, again, there is a regex that is actually looking for what I have put in here. So it's also looking for
html entities. That means that the maintainer of Mark actually had a good
security mindset thinking about different ways that the application can be, you know, corrupted and can be vulnerable. But unfortunately, even with that in mind, it's not enough. So we know about
html and we know that it has a very loose format and also that the browser itself is very tolerant on how they can process information, right? So if I will make a slight change here in the
html ID. So instead of using
javascript and add this, like a valid
javascript keyword to the
html entity and say alert and hopefully this time I can say that Mark was exploited. Okay. And also add the parentheses at the end. Okay. Hopefully, fingers crossed it actually worked. And it did. Because in this case, as we know, what they are looking for are
html entities. And what I did now is by adding this, which is a valid keyword in Java, I actually made this
html entity unusable. And that is exactly where the flaw is in their code. Not considering that this might actually be a vulnerable inclusion. As you already know, this worked. That also meant that the browser itself, it allowed the
javascript to be executed. And if I click as a user and my break and of course this particular script is not a highly usable one. Of course an attacker will potentially inject a really high malicious and sophisticated payload to trigger that break into a cross-site scripting vulnerability. But the idea is that it is possible. And this can be used to and it was used to break the browser same origin policy. So, that was the hack by itself. What I wanted to showcase, it's also the story behind Mark and the package. Because the idea is that this vulnerability that we just exploited successfully, as I said, it was fixed in 2016. Right? So, if I go to the
database, I do have it provides me an overview. It provides me with the details of cross-site scripting. The ones I have explained. But also, it shows me who actually disclosed this vulnerability. So, Matt. Not our Matt. But another Matt. Actually create a pull request to if it would work. It created this pull request, right? Saying that this is a cross-site scripting vulnerability with
html entities to the marked registry. But unfortunately, even though they provide a great report showcasing, right? What this does, people were actually communicating saying, hey, this is something that is quite vulnerable. It also provided all the tests necessary. Right? And also, it provided the fix for tests for the
security vulnerability to just, you know, be merged for this pull request to be merged by the maintainer and be fixed. Unfortunately, with the open source
security story, as I said, maintainers do have their own life. And sometimes a pull request like this, a one that would be actually really useful and will fix the
security bug, it actually took a year. From Matt being the person that says, hey, this is vulnerable. This is what you can do to fix it for the actual project maintainer to actually merge this pull request. It took them a year. So, a year of knowing that this is out there in the internet that can be used and exploited. Then what I want to do is to actually showcase how you can fix and how you can understand what you bring into your code. So, that would be most likely a tool or a process that you would use when you're writing the code, when you're writing the code that, you know, you would use in the application, but also importing the libraries within your application. You will need a tool, most likely that it's really easy, developer friendly, a tool that would make your, let's say, findings actionable. Something that you can use on a daily basis to actually, you know, have a
security output on your vulnerabilities. And that comes the story with Snyk. What we do and what we have is and the first interaction as a developer that you would have with Snyk would be through the ID. We do have a full platform that has various integrations and it integrates across the software development lifecycle. But the first thing, the first interaction that you would have as a developer would be right in the ID. So, I have opened the Node project, the Guf2do application that you've seen vulnerable. And what I want to do is just trigger a test with Snyk. And what it does, it worked really fast. And what does open source, Snyk open source behind what this ID actually looks at the dependencies, the open source dependencies that you've brought within your code. It creates a full dependency tree. And it looks not only at the parent, the first library, it looks into the transitive dependencies that I have talked about. The ones that are really hard to actually see as a developer that you have introduced within your code. So, if we're searching for marked, which is here, as a vulnerability, what you can see in the ID is how this vulnerability was introduced to, to which package, how you can fix it. The overview, again, about what marked is, some details about cross-site scripting, the types of attacks that you can expect, I guess, and ways that you can also prevent it. Right? So, what I can do as a developer, I can basically go to the package JSON, look at, okay, how I can fix this. If I can change and I upgrade the marked version to a newer one, if I search for marked, okay, JSON, and I change it to 6. This is the only one. And hopefully that's been everywhere. And if I just save it, right, file, just make sure I saved it. And run the scan again. Hopefully I've seen that the start I had 96 vulnerabilities and now it will appear 96 again because probably I didn't save it right. I don't know why. And what I can see now that it's actually the vulnerability that I just fixed by upgrading to a newer version of that library. It's not here anymore. So, that is how I can have the
security output and the responsibility of
security into my hands when I'm actually writing the code. I do have a good visibility of an understanding of what do I have in my application and code and my dependencies that I brought in from the open source world. Do you have any questions? Nope? Okay. Good. Then what I wanted to also present is besides the open source that we have discussed, Snyk also offers a platform. So, Snyk is a developer first platform. It actually takes and makes
security easy for developers to use and integrate across their current workflows without blocking them. What you have seen, it's a fix to the open source tool that we have. But we also have a SaaS
tooling, which is Snyk code. We are also looking at vulnerabilities within
containers. So, the similar to the open source, but we are looking at the packages, Linux packages that you have in your container images. And also, we are looking at deployment configuration files, misconfigurations that you have within your infrastructure as code. I don't know if you have seen the Snyk platform so far. But if not, I want to showcase a bit what we already seen, but through the actual platform. So, again, Snyk has various integrations. It does support various SEMs, GitHub, GitLab, Bitbucket, container registries, continuous integration. So, you can integrate within your pipelines using Jenkins, Bitbucket pipelines, DIDs that you have already seen. Of course, we have also notifications integrated. So, if you use Jira, you will also have access to that. What Snyk does, it's really easy to import any project. So, if you have GitHub, GitLab, you can easily go into the integration, choose whatever project you want to import. And once that is imported to the application, you will have the reports based that I will showcase here. So, what we have seen within hello, again. I thought that I got rid of you, but hello again. What we have seen in DID is the package JSON, the open source tool. Can you please? Thank you. Okay. So, that is how it looks within the platform. As I said, what Snyk open source does, it creates a full dependency tree based on your manifest file package log JSONs. We're looking not only at the parent image, but we're looking at the transitive dependencies and help you understand the risk of those dependencies if they are vulnerable. Right? In this case, this is exactly what I said. Transitive dependencies that has a lot of vulnerabilities within those depth chains. And what we can do with Snyk, we do have the Snyk vulnerability
database that looks at various
data vulnerabilities sources. So, CVSs, CVEs, but also, again, we have our own. So, I don't I think I've seen a question. Does Snyk do a cognitive load check? Yeah. Not entirely sure what that means. Can you maybe rephrase? And we'll take the question after. Okay. Good. So, what we do, we also offer the Snyk vulnerability
database. That is actually enriched by our research team that does a lot of research that looks at various different types of resources across the market. And we do pump the
security prioritization score. So, as you can see, for this vulnerability, we have a CVSS of 7.1. But in what we say, it's a prioritization score at 741 because we did find and exploit maturity, which is mature. And it also has a fix available. And what we do based on this, we create you the help that you would need to actually understand what is prioritization and how you can prioritize all of these issues. In this case, I found 48 issues. But what this does, it helps me understand that this is highly important. This has a fix available. This has an exploit maturity. Therefore, I should prioritize this. And also, you can do the same with filters within the application. And out of 48, because I said fixable and mature, but also let's put a proof of concept, out of 48, I will have 15 issues that are highly important. And that would be the ones to tackle first. As I said, we do also offer the Jira integration. So, if this is an issue that it's highly important, you can use the integration, assign me a reporter, and of course assign me and have it put it in the sprint backlog and use it in the next sprint. So, on my end, that is it. I hope that this presentation made clear the importance of open source and open source vulnerabilities and how important it is to keep track of your dependencies and what your third party code you bring into your application. If you have any open questions, we are here to answer. So, please share them. I think there was another question on whether Snyk was free for big teams. Big teams like... Well, I think Dennis, if you want to come off mute and ask again what that question was so we can answer it. I think that was meant to be Snyk and not sync, but maybe that was a autocorrect thing going on there. But for context on pricing, yeah, as Alexandra is showing there, we have free, but that is limited to the amount of tests that are scanned per month. So, obviously, we can have proper commercial discussions with you guys and kind of match up what the different pricing tiers look like and what they can offer based upon feature sets and also advise you on the best ways in which you can consume it in your teams and scale it across your businesses. So, I think rather than looking directly on the site and getting information from that, then please feel free to set up a meeting with us. If you hover over this section, Alex, just here. Are you showcasing me something? Yeah, over here. The feature? You should see it growing on your screen. Yes. Then if anybody is interested, if you go to the Snyk website, after this loads in, you should be able to just go in and request a meeting like that and effectively book a demo up there as well. We can go through in more details kind of like what Snyk can look like in your business and inside of your workgroups. And also keep in mind that we are going to be there in Amsterdam for the conference. So if you would want to discuss more at the boot, feel free to join and we can have an in-depth conversation and maybe I can showcase even more features and things that Snyk can do. So feel free to stop by the boot and say hello. Are you guys actually going to join the actual event? So are you going to be there in person? Yes, no. I will. I know that you will not. Unfortunately. Okay, I see a lot of nos. That's okay. We'll attend. Awesome. If we have the time now, maybe it might be worth highlighting the Snyk Advisor and potentially Snyk Learn as well, just because they're also cool tools and they're also completely free as well. And they can help you with actually navigating kind of what open source libraries you could be using as alternatives. And also like some of the highlights that we've gone through in terms of like different kinds of vulnerabilities, you can get information on them. So what Matt just mentioned, Snyk Advisor would actually be the tool that you would want to use before even importing a library within your application. If you want to check the
security and the dependency health of that library, you can do that. Again, it's free. You can use Snyk Advisor and you can check the package health score. If it's
security, the popularity, maintenance, if it's
community active. Also, we do provide different ways that you can change, different solutions that you can change the libraries that you want to import with a good one, not a good secure one. Also, the number of downloads. Oh, yes, I searched for Express. So we've seen that this is highly downloaded. Another tool that you can use is Snyk Learn. So if you want to learn more about vulnerabilities, like the ones that I have presented, again, free to use, you can actually go to we have the various ecosystems. But for
javascript, exactly, you can go to cross-site scripting and try it for yourself. Learn what cross-site scripting is and have it have an actual example and try to hack along with the team. And it provides good information. Really nice to actually learn and do things by yourself and understanding how cross-site vulnerability works, but also many more. Content injections for Python, Spring for shell, for Java, SQL injection for Python and so on. Free to use, really nice to get more into
security and have a good learning experience. Anything to add, Matt, if you want to? I don't think I covered. I don't think so in terms of like, obviously, what you showed us there. There was a question coming in from Edmundo around the differences between something like Snyk and Dependabot. It might be worth showing off kind of the functionality that we can do with regards to actually automated fixed pull requests. Because that's something that's specifically different between us and Dependabot. So if you were to go into and open up your package.json here and find a transitive dependency. So this is a, I think this is a direct one. Maybe this one. So that's an example of one. Yeah. And there's no remediation for that one. Well, it's partially fixable. Let's see. I know an example one is a negotiator. Type that in. Okay. Oh, is the new shop project. So I don't know. Okay. If you go to your dependencies over here, and then run over to the dependency tree. So this is a really cool feature with Snyk is being able to graphically see kind of how transitives are making its way into your application. And if you just open up a few of the, yeah, a few of the vulnerabilities here. So you can see that you've got all of these kinds of vulnerabilities that are coming in via transitive dependencies. So Snyk will show you these in a graphical way. And then what we'll do is we'll also show you how you can fix things well inside of this. And what we would do is open up a fixed PR. So is this one that's fixable? It looks like that. Yeah. So what we do and what is a standard feature in these tools and what's available inside of the
database is because we have a vulnerability inside of the transitive dependency like moment here. What we'd end up doing is basically showing you the version of moment you can go to in order to remediate vulnerability. But the difficulty in that is knowing, okay, we know that moment can be fixed using this vulnerability using this version, but how do we actually call that in? Because we aren't actually referencing that ourselves as being pulled in, not necessarily with our own permission. It's kind of coming along for the ride with the package you actually want to use. And what we do is we tell you the version of the parent package you can call in, which actually has the fixed version of the transitive dependency in its dependencies itself. And that actually becomes very useful and it becomes like very laborious to keep and maintain that
database. So that's some of the work which Snyk is putting in on its end. And as Alexandra was showing, when we go through and click those buttons and basically open a pull request, we can actually change that for you. If you have a look at dependable as well, unfortunately they wouldn't be able to provide this information for you. It would kind of spin for a while, then come back and say we can't make that change because it's a required dependency, but they won't actually be able to tell you like change your parent version or the thing which it's dependent upon in order to fix this vulnerability. Does that make sense? Yeah, that's cool. Very nice. Because with dependable, it's always a pain having to look at all the dependency tree. So that's very easy. Cool. Thank you. Yeah, it makes sense. I mean, that's just like an example of like one of the ways in which we're different. But obviously, we can go into more detail about the different ways we can integrate all that kind of stuff. But that's more of a, you know, like quality, I guess more of a nice to have features. This is like, I'd say a very big difference between using
npm as like your core technology, if you're already using GitHub as well. Then obviously, you might use dependable anyway. So effectively, the main difference between us and them would be activating it inside of like your CLI as well. So you can scan things locally, scan things in like an ID. And then also when you do scan things like why GitHub here, you can actually automatically fix things and it can tell you how you fix these. I think another cool thing to mention is, of course, every time that you raise a pull request, that pull request would be also scanned. So we are looking for licenses issues for
security issues with open source, and for sassed. So within the pull request, you will know if you know, if you have changed something in your code, and you want to be merged, you will have this showcase, if this if this vulnerability or not within that change that you want to make. Would you have a situation with GitLab? Yes, we do. Let me just showcase and again, the sneak and showcase all the integrations. But yes, we also do support GitHub. It's over the workshop and the presentation. So I like to thank everyone for joining in and taking the time to listen to us and have more in depth details on
security and open source and cross site scripting. And I do hope that we will meet in person at the boot and we can discuss further more about sneak and open source
security. So thank you, everyone. And I hope you have a great evening.
