great webinar and show to go through today but first as always I love to see where everyone is tuning in from so let us know in the chat whereabouts uh your listening and watching from um I'll start I'm tuning in today from Paris in France um it's not it's not where I live but it is where I um our offices are that I'm here and fairize whereabouts are you tuning in from today uh I'm coming from San Francisco California San Francisco all right we've got Toronto Nigeria Arvin San Diego India I always love to see uh the reach that we can get Ukraine welcome Czech Republic Czech is uh one of my favorite countries I love uh I was at a conference in Prague this year it's my first time there Nepal Serbia Portugal I was in Porto last week at Porto hard Tech conference um very very cool place it's very wet laughed last week but uh super super cool place UK lots of different countries well um I love to see where that is it also takes up a bit of time whilst we're waiting for everyone to join but uh great to see so many different places here South Korea we're still going so a little bit of uh of a run through of what we're going to go through today so intros which is currently what we're what we're doing then we're going to talk about a little bit you have to suffer through me talking for about 10 minutes um where I'm just going to discuss what are Supply chains um if there is in fact a supply chain what it looks like and then we're going to talk I'm going to talk very quickly about some of the anatomy of a supply chain attack what a supply chain attack looks like in practice once it's been done then I'm going to hand it over to Ferris who's going to run through a presentation about the challenges of Open Source and supply chain security so this is something that really affects all areas of software development today which we'll elaborate on I'm sure we're going to do a little bit of a lightning demo of socket security which is a fairly new tool to the ecosystem so I'm excited about that and then of course we're going to go through a q a so if you're in crowdcast we're also streaming to some other places but the main platform is in crowdcast and if you're in crowdcast to the right hand side of your screen you'll see some options one of those options is to ask a question so uh feel free to ask questions at any time during the presentation we're going to get to them at the end but you can also upvote and um upvote and download and comment on other people's questions so that we get kind of the the ones that people want to hear we make sure that we get to them so feel free to do that and at any point feel free to communicate in the chat we always love participation so that's the general flow of what we're going through today so without further Ado I'm just going to get started I'm going to go straight into it so is there really a supply chain and what does that actually look like so supply chain we're kind of familiar in if we're talking about typical manufacturing right you had your raw components and materials you have your assembly lines you have your kind of testing lines and then obviously packaging and shipping and we get the end product you can imagine that going through the car manufacturing all those things cap happening there's lots of moving components obviously it's more complicated than this in reality but everyone can typically understand this software is actually no different especially in the modern era that we're facing today so we have our Frameworks and our packages and our open source kind of uh open source libraries that we're using combined with our own source code which comes under that first component but then we have our source Control Management our Ides then we have continuous integration and testing the CI cd part department of it which it goes through and then we have really our finished products our software artifacts things like our Docker images our packaged software so it kind of follows a similar are if you want to think about it a similar Avenue that uh you know the traditional supply chain of a traditional kind of physical products follow as well but it's very nice to think about it in a linear process that we have this nice kind of process that we flow through but it's not actually the case the software supply chain in reality gets quite complicated that's because we can have software dependencies that are also dependent on other dependencies we can have dual dependencies where components are dependent on each other we can have lots of different packages and everything can be can have dependencies and areas within it so the software supply chain whilst you can think about it in a linear line is actually not it can extrapolate and be quite complicated so we definitely experience this why is this why does this matter because it's complex it means that we're actually vulnerable to a supply chain attack at multiple different stages of the process it's not just our end artifacts and applications that are vulnerable it can we can be vulnerable to areas in our testing processes we can be vulnerable to areas and vulnerabilities in our in our control and our source code and even right back down to the Frameworks that we're using so the software supply chain can be a really complex topic and one that's not really easy and we've seen a huge shift our attack is really targeting this so when you attack a component of the software supply chain it can affect hundreds thousands millions sometimes billions of different applications components we saw this with log4j coming in we had this huge impact because so many different things uh were really dependent on it and this has really changed economics of how hackers operate we all like to think of a hacker as a you know someone in the basement with a hoodie on type computers into a line the reality is that hacking organizations operate a much much more like a traditional business than you would expect and we've changed and supply chain attacks have changed the economics that they follow the economics if you want to to to to to go there and so we've seen a huge uptick in this right because it's the most profitable thing you can Target huge areas you can Target uh companies that may be really secure in their forward-facing components but are vulnerable to some of their dependencies so we've really kind of seen a huge increase and we've seen this in the news so we have to be aware of this we have to take action against it so I just want to talk very quickly through one software supply chain uh we're going to run through the kind of anatomy of this of exactly what happened so that you guys can all kind of be familiar with what actually happened the software supply chain that I want to talk about is code cop so what is code COV code COV is a testing tool it sits in your CI CD environment it's code coverage it basically test how much of your application is being tested so we want to make sure all of our application is tested code COV gives us some figures of how much of our application is actually being tested but last year early last year there was a massive supply chain that affected huge amounts of codecov's customers because they were breached so what actually happened so in codecov's finished product the artifact their Docker image there was a plain text credential this credential essentially gave read write access to attackers to modify a component in codecov's the way that the code cost image is put together it was a bash uploader script the attackers were able to inject a malicious line of code which basically turned code Cove malicious itself what did that mean well codecov had 20 000 customers at the time of the bridge every single time one of those customers used codecov in their testing environment the malicious version took all the environment variables took the secrets that were being run in the environment to test the application so it could have been database access strings it could have been API keys but importantly it also would have been things like access to your internal git repositories so what actually happened was the attacker got access codes got GitHub tokens or other version control system tokens to access to private Source control of multiple different companies maximum would be at 20 000 but quite a lot and they were focused on the larger customers hashicorp twilio monday.com a lot of big names were affected from this bridge so we can see here how end product that had a vulnerability was exploited by an attacker that update really went into the supply chain and now everyone dependent on that component has now vulnerable and now they've had malicious intrusions into their internal infrastructure because of that so none of the companies that were actually ultimately breached now the victims did anything wrong but because they had a component that was turned malicious um they were they were impacted by this this is why it's so important to really secure our supply chain because it's an area that we have limited control over we have control over what we put into our supply chain but even if you extrapolate that to dependencies of dependencies we have limited we have limited ability to to maintain that so we can do everything correctly and still be vulnerable that's why it's so important that we understand our supply chain and that we do everything to protect it so in this case uh those hard-coded credentials inside the docker image there's also hard-color credentials inside the the victims repositories so keep Guardian in case you're not familiar with us we provide tools to help prevent that the GG Shield is the tool uh is our open source tool for developers so if you're not using that go check it out it's the repositories on GitHub you can put it into your CLI and prevent yourself from committing secrets But ultimately the supply chain can be attacked in lots of different areas right we've been through one which is going through that testing stage but this one here is from salsa which I believe is a Google initiative this this image here and it's kind of showing a lot of the areas of where the software supply chain can be attacked from so this this diagrams depicting our software supply chain and kind of all the areas that we can really uh that intrusions can inject themselves so namely there's our build Integrity to ensure that the software is built from the correct sources dependencies and it hasn't been modified that one's really important is our source integrity and then really importantly these are dependencies and that's what Ferris is going to talk about now is that dependencies component of our software supply chain so with that I'm going to stop sharing my screen that was just a very quick introduction to kind of get everyone up to speed and I would like to invite Ferris to share his screen now and run us through the presentation the main event what you are all here for all right thanks for that awesome intro and with all that context I think people will be uh really uh ready to go for uh my talk so uh can everyone see the screen we can now you're all you're up and you're up and going all right that's awesome cool yeah so thanks thanks Mackenzie for all that uh awesome context on supply chain attacks so um everyone I hope you're excited for uh for our talk here and I'm gonna do an awesome demo as well of uh socket and how it works at the end uh but but yeah let's let's get started so um so just a little bit on my background so you know most of this talk comes from my experience as an open source maintainer writing some of the most popular open source libraries uh and uh being on the board of the node.js foundation I really got a chance to witness firsthand the massive increase in the way that open source is used within organizations as well as the increase in supply chain attacks um so uh now I'm I'm focused full-time on this problem scaling open source security for many many organizations through uh socket which is a product that defends applications from software supply chain attacks specifically around dependencies so um so this talk is is uh is really about the Lessons Learned being at the Forefront uh of uh the rise of supply chain attacks uh like I said I've been working on open source full time since 2014 so I really saw this uh this this firsthand um so before we start uh what is this software supply chain attack so McKenzie already went over this a bit um the kind of official definition is like when a cyber threat actor infiltrates uh vendors Network and then uses malicious code to compromise software before the vendor sends it to their customers that's kind of like the official or the sort of formal definition but what does it really mean uh for us as as JavaScript developers or or as as developers in general for JavaScript what this really means is an attacker somehow got their malicious code into your node modules folder and that ended up getting used in your application so somehow this dependency got compromised uh and and now you're you're you've installed malicious code into node modules uh and so um with that in mind let's let's now kind of talk a little bit about you know why are so many supply chain attacks happening now um what what has changed about the world uh to you know cause this uh this this increase in attacks I think it really comes down to three main reasons uh the first the first reason here is that there's been a massive increase in just the number of third-party dependencies that we're using in our applications this is because the way that we write software has changed uh we're using a lot of cloud services we're using no code tools we're using apis we're using a ton of Open Source packages no one really writes software from scratch anymore you know no one is sitting here you know writing a you know opening up a blank file and and building an entire application everyone today builds software on the backs of other you know companies and tools and apis and open source packages um one example of this is if you just look at large organizations you know they use over 177 uh SAS applications um just as kind of one one indicator of the the dependence that we have on others but if you go to the to the to the um you know developer context and you look at an average application you'll find that about 90 of the lines of code in an application actually come from open source dependencies so you know most of the code that's actually running in an app isn't written by by you by the developer it's written by you know by these dependencies um and so you know gone are the days of people copying code Snippets from stack Overflow and Reinventing everything by writing it in-house um really developers are using dependencies very liberally because open source is is just so so useful I mean it lets us build powerful applications in days or in weeks instead of in months or in years so we can really go fast by building on all this awesome software that's out there so let's look at one example of an application like this so uh probably a lot of us have heard of Discord uh Discord is an awesome chat application it's built on a massive amount of Open Source if you take a look at the uh the dependencies that are used inside Discord you'll see that it's using almost 20 000 npm packages and if you look at the commits in those you'll find it's actually been written by almost 400 000 different contributors from 200 countries so this is like you know this is an amazing number of packages an amazing number of people um working together on this and so in some ways it's obviously very incredible that open source lets us do this but on the other hand you know if any one of these contributors uh you know it goes goes Rogue or decides to be you know evil and put malware into into their code contributions then you know this application and many many others that depend on it on this open source will be affected so um and so this is kind of just an example of the the way that we write apps today really is it's just we're using a lot of Open Source um one other stat here that kind of helps driving Point home is the average npm package today has 79 third-party uh dependencies uh and so when you install one package you're actually installing 79 other third-party packages and depending on 39 other maintainers so um so this is this is just like the way that the software seems to be written today and so this is just introduce introduces new risks uh and then I like to show this visualization so this is a visualization made by the socket team uh this is um the webpack package so webpack is a very popular front-end tool for bundling your JavaScript dependencies uh and preparing the JS to be used by your users and what you're seeing here is the visualization of all of the files and dependencies that make up webpack so every gray box is a package is it open source package and then every purple box is a file within a package so let me restart this right here and you can see um you can see from the beginning so what you're seeing here this is webpack big gray box you open it up inside you have other packages and you have other files inside and we're going to keep peeling back the layers one layer at a time and you keep seeing every time we peel back a layer you get more packages you get more files um and and and you can just get a sense of the complexity here uh the number of different dependencies that are used just just for this one dependency webpack so the other reason why we're seeing more supply chain attacks is that uh change happens a lot faster than it used to so we've gone from a world of releasing software once every year to sometimes hundreds of times per day in a lot of companies so in this world security the security team can't really be a gatekeeper anymore because every time you push to Matt to main or Master you may be running a deploy and and deploying that straight into production and so it's not really possible for the security team to kind of enforce rules uh anymore and uh in today's culture of fast development a developer might update a dependency uh and deploy it to production you know in a couple days or maybe even hours after that dependency was originally published and this is partly due to uh folks are doing a better job staying up to date uh to avoid vulnerabilities a lot of people are using tools like dependabot to keep their dependencies up to date as you can see in this screenshot here um and so as people are starting to take vulnerabilities more seriously uh they've actually weirdly made themselves um more vulnerable to supply chain attacks because uh you know take this this picture here for example this this PR right uh it says it's updating Express rate limit uh from version 5.3.0 to 5.5.0 now I look at this and I say oh you know a new version that sounds like it's good right it's going to fix some bugs maybe it's going to make things faster maybe it's going to make things more secure uh I don't really get much of an indication in this in this pull request about whether this is safe or not and you can see this was sent this PR was sent a couple days ago so this package is pretty new there probably hasn't been a chance for very many people to review it and so I don't know if this is safe it probably is but it might not be right and this is this is one other reason and you know that we're having so many more of these supply chain taxes because there's so many dependencies and we're doing all this work to keep them up to date we're updating a lot of versions and every time we do that we're bringing in new third-party code into our apps every every single one of these updates is new third-party code and we're today we're really not reviewing that code or if we don't really have a process for really understanding if that code is safe so this brings up a question you know how quickly should you update your dependencies um you could you know you know a lot of for the you know if I could say about 10 years ago uh a lot of the teams were on the on the slow side here they would really rarely update their dependencies and obviously we've learned the problem with this is it exposes you to known vulnerabilities uh and uh and so a lot a lot of teams have actually done a pretty good job in the last 10 years of Shifting over to this fast side here where they're actually updating their dependencies pretty quickly but as I just mentioned this comes with its own downside which is that you're exposed to supply chain attacks because you're now pulling in code uh very quickly and the quicker that you update your dependencies the fewer eyeballs that have actually had a chance to look at that code and uh you you know not that many people are really looking at at uh you know at these at some of these dependencies so this is really a challenge for for a lot of teams here is how quickly should you update and really I don't I'm sorry but I don't have really a good answer here um uh other than you know socket can actually help with uh with helping you update fast and and to to uh to give you some feedback on whether dependencies are safe as I'll demo at the end um and then finally the third reason is that the cost of attack has actually become so low that you're basically going to be attacked um it you know it used to be that uh only you know big name companies were worried about being targets but today just by virtue of using open source you will be attacked give you an example so earlier this year uh there was this tool called Amazon cdk or Cloud development kit and they were um they were this is what users saw when they went to go run the Amazon cdk on their terminal uh they printed out it printed out gibberish messages and included the text liberty liberty liberty as you can see uh followed by all these all these these weird uh non-ascii characters and an infinite Loop which caused the program to hang and so I'm not an expert in product or marketing but this really isn't a good experience and most companies don't want to deliver this type of an experience to their users so what really happened here let's talk about what happened here um basically um a few months earlier the maintainer of a package called colors JS which is one of the dependencies that Amazon used had warned on Twitter he would no longer be supporting big corporations with his free work and then he actually decided to sabotage the package so uh when he sabotaged this package he put you know this this the code that you saw to print out all this extra stuff in the terminal and um and uh added these infinite loops and in doing so he actually affected many many packages actually 2.5 million um or sorry the package had 2.5 million weekly downloads and he actually affected about 30 000 apps that we know of that are public on GitHub not to mention Untold numbers of private repos as well so this is the kind of impact that one person one one dependency going rogue can have on the ecosystem because of because of the way that we write software today and we're so dependent on everything on each other uh and then you know it's not just intentional sabotage there's also packages that sometimes get taken over uh by by somebody else by an attacker so I'll give you another example here um last October um on this Russian hacking Forum there was a post that appeared uh here you can see on the screen um this post was about hackers selling the password to an npm account that controlled an open source package with over 7 million weekly downloads and they were offering this uh account for uh sale for twenty thousand dollars and two weeks after uh this message appeared the package was actually compromised and three malicious versions were published and um the attacker added malware that would execute immediately whenever anyone installed one of these compromised versions so I'll just give you a quick preview you know quick peek into kind of what the malware did here um I'm not going to get too too much into it but just to give you a taste of like what does the malware actually look like when you're when when an npm package is compromised so let me draw your attention to the the uh this is the package Json file and I'm going to highlight the pre-install script so the pre-install script runs automatically anytime this package is installed and so the attacker added this line so that their malware would run immediately when anybody installed UA parser.js and this is actually a very common technique a 2022 paper found almost 94 of malicious packages used at least one install script and so this is just kind of the main way that attackers like to deploy their malware to his install Scripts so let's actually take a look at the at the script of the attacker ran so you can understand a little bit more about what what do one of these attacks look like so you'll see here the first um the first line uh first couple lines are getting the user's country using a web service and it's grepping for um four country codes Russia Ukraine Belarus and Kazakhstan and if the user comes from any of these four countries then the malware will actually stop running and it won't it won't proceed any further so the user will be safe and so probably what this means is um that the attacker comes from one of these countries because usually they don't want to antagonize their local law enforcement and so this probably it's probably the the it's we can probably assume that the uh the attacker comes from one of these places or at least operates in a group that uh that operates in these countries so let's say now that you're unlucky you you live in a different country so the malware is going to con this is going to continue running so the next thing that it does is it checks to see if the uh if there's a process called JS extension that's running and uh this is just the name of the malware so if the mount is already running then it will it will quit um otherwise it's going to actually try to infect you now so it downloads the it downloads a file from this amazingly suspicious looking IP address uh it makes the file executable and then it runs it and so this is actually going to run the malware and you can see here it's it's a it's actually a Monero Miner which is a cryptocurrency so it's going to be abusing your system resources to mine cryptocurrency for the attacker uh and then I'll show you the windows version really quickly it's very similar but I'll just highlight one difference so Windows users had a little bit of a different uh attack so uh it also downloaded this extra dll file and then it registered this dll file down here and that extra step on Windows led to um stealing passwords from 100 different programs on the and also the windows uh credential manager um so uh this was really nasty for Windows users they actually lost um you know a lot of uh potentially other accounts that they use on their machine so you know we've seen headlines about these types of attacks uh whenever you see these this is basically what's happening is the package is taken over uh the person who takes it over adds malware into the package and then they they use that to attack the users so packages get hijacked for a lot of different reasons maintainers could use weak passwords they might give access to the to the wrong person they could themselves become malicious uh they could be protesting something you get malware on their laptop so there's a lot of reasons this could happen so we've gone over uh kind of two um what are called ttps so tactics techniques and procedures and I want to just mention a couple more that you might see in malware um so uh the next one is typo squatting this is one of the most common techniques so um let's go over how it works so there's a package called HTTP errors here and it's very popular has 52 million weekly downloads it's awesome software very useful but say you're going to install it and you're starting to type this into your terminal npm install but you make a typo and you accidentally install TTP error so this package is not okay to use this package is very bad uh it's it's malware it's awful right you do not want this one on your computer and and it's so it's it's so easy to make a typo when you're when you're running npm salt and the consequences can be very very dire so what I'm going to show you now is using uh socket uh the tool that we're building uh at the company I work at um I'm going to show you what you can learn about the the incorrect package here the type of package to say you were to look it up on our website let me just draw your attention to uh this line here you can see online um 112 that this package is actually including the child process uh a module and then it's using that to run a shell command and so we call that out here right in the file you know where you can see it um and so if you actually zoom in there you can see this is actually the command that's going to run it's a very sketchy command you do not want to run this on your computer um it's it's uh basically downloading some code from a bitly URL and then executing it so this you know this is a quite a big difference for just a few characters mistake um and then finally I'll mention uh one final technique which is called dependency confusion so this one can happen when a company is publishing npn packages to their own internal npm registry and then they use a name that hasn't been taken yet on the public npm registry and then later an attacker can come along and uh register that that name on the public registry and put malware in it and then many internal tools will get confused and use the public version of the package instead of the internal one so um we found a few examples of these on npm you can see a lot of them come from they appear to conflict with a very popular organizations that you might have heard of like Yahoo and so on and so forth here so there's a lot of these these uh these packages that um are designed to to to confuse internal tools um and then if you open up one of the if you open up some of these packages the kind of code you'll find inside it looks like this and it's very heavily obfuscated it's hard to know what it's doing but it's it's definitely not something that you want to run on your computer so this is just a sampling I just wanted to give you all a taste of some of these attacks what do they look like how do they work so now you have an idea um and I just want to emphasize this is just the tip of the iceberg at socket we were monitoring security incidents in open source packages and we saw around 400 supply chain attacks in open source packages in just the last 30 days so there's a lot of these happening if you're curious you can actually go to the URL on the screen uh on the footer there and you can take a look at some of the other attacks that we've uh we've seen and see what socket would have detected in them um if you had had socket installed so now let's talk about how you can protect your app because I want to leave you with something you can actually do so it's not hopeless there's actually something you can do here and this will give you a sense of what are some of the leading companies doing also that are that are protecting themselves um so the way the way it works today when a developer adds a new dependency this is what they and their teammates see there's really no feedback in this GitHub diff view about what risks this change introduces uh the developer or the code reviewer looking at this would have to painstakingly review every line of code of this package as well as the the every line of code of its dependencies um so when when somebody sends in a PR and it looks like this almost no team is actually reviewing this dependency right I mean when's the last time you got a PR from a teammate looked like this and then you went and actually did research on the package right most of us don't actually dig into these dependencies and the GitHub interface doesn't really give us much of a uh that doesn't give us enough information about this this dependency that would give us the context we need to really decide if it's safe or not um so um so like that that raises the question really how closely should we be really evaluating our dependencies so how closely should you audit your dependencies and um you know a lot of teams today are pretty much doing no audit uh they just allow developers to add any dependency that they want and that's the sort of Norm today and you know this is this is in some ways it's good because it's fast it doesn't it doesn't slow developers down but the downside is it makes you vulnerable to supply chain attacks because you're basically pulling in you're letting developers pull in third-party code that may have not you know that has never been vetted by anybody potentially right it's it could be it could it could be anything in there um now if you um you know if you you know you could imagine okay let's let's review every dependency let's go more much more over to the full audit side how does that work so this is something that really only the very biggest companies do companies like Google um and they'll do this because it's it's really the safest way it's the gold standard way to make sure that you're not going to be hit with supply chain attack uh it's it's it so it is very safe but it's very slow because you have to review every line of code of every dependency it's a lot of work uh almost no no one except these really really big companies can afford to do this so you know I think some of you might be thinking well hey what if I use a vulnerability scanner you know what if I use it use a some kind of a cve scanner and I just fix the the dependencies that are um you know I use that to tell me if if my dependencies are vulnerable or not the thing is that malware is very different than a supply chain attack so or sorry vulnerable vulnerable code is very different than than code that has malware in it so supply chain attacks or malware can take weeks or months to be discovered and in today's culture of fast development a malicious dependency might be merged into master and then running in production in days or even hours and this isn't really enough time for a cve or a known vulnerability to be created and to make its way into the tools that a lot of teams use so uh this 2020 paper found that on average a malicious package is available for 209 days before it's publicly reported and so during that 209 days there's no cve published and so developers really have no feedback that they're potentially installing a compromised tendency and uh this is another paper from 2021 uh that found similar results including that 20 of malware persist in package managers for over 400 Days and have more than a thousand downloads so really just to drive the point home here um vulnerabilities and supply chain attacks are very very different they need different solutions so vulnerabilities are accidentally introduced by maintainers by the good guys and have they have varying levels of risk sometimes it's okay to uh to put a known vulnerability into production if it's low impact or you know that it's not possible for an attacker to actually exploit it a lot of teams already have many known vulnerabilities in production and they're working on on mitigating those over time um and there's often time there because they may not be discovered or exploited before you update to a new version so you usually have some time to to address them uh now now supply chain attacks or malware on the other hand is very different malware is intentionally introduced into a package by an attacker and almost never the maintainer and it will always end badly if you shift malware to production you don't really have a few days or weeks to mitigate the issue you really have to catch it before you install it on your laptop or on a production server so um you know using a vulnerability scanner to try to detect and block supply chain tax is like looking for your keys under the street light because that's where the light is and that's not where you actually left left your keys so I think the security industry is a bit obsessed with scanning for known vulnerabilities um but it's really an approach that's too reactive to stop supply chain attack what you really want to be doing is working toward a position where you're much more proactively aware of what your dependencies are doing so um basically let's talk about how to do that so it's socket we're focused on open source security so you know these are some examples that I'm going to give you here but the principle really applies to all forms of application security so um what we really want to do is provide visibility and feedback loops to developers so we want to give the developers information about what their dependencies are doing and we want to make it easy for them to fix any risks that are present in the packages in a quick way and see the results of that so what do I mean by that so today when the developer is picking a dependency they often check for a few things to make sure that the dependency is going to get the job done so the first thing is they'll say hey does this dependency even do what I want does it does it get the job done right then they'll say you know does it have an open source license uh does it have good docs doesn't have a lot of downloads and GitHub stars does it have any recent commits just have tests and so you can look through and say okay this package generally feels like it's going to help me solve my problem and then you might install it so this is pretty normal a lot of a lot of us do this this process today the problem is that this is kind of missing the real you know this is missing the security question you know what is it how do you know if this dependency is safe so ideally you if you were a security-minded developer you'd be checking for more things than just that you'd be checking for things like is this package going to run a shell script when I install it is does this package have native code which makes it very hard to audit because there's an executable file in there and you can't read the source code for it does the package talk to the network if so which domains does it read environment variables which ones does it contain obfuscated code does it collect Telemetry does it phone home and you know if you could answer these questions you have a much better sense for is this package safe to install or is it going to introduce risks into our into our code base but right now this is really hard to find out these things these things here require a lot of research and a lot of work to uh to investigate as I mentioned the status quo is that developers really have to work very hard to find out this information this is a file dip you can see where you can you know it doesn't tell you anything that tells the developer very little about this dependency so how can we get to a position where developers have much more proactive information so if you were to look this package up on socket uh you would find that we um we show you this amazing package page you can search for any npm package on socket and we'll give you information about uh this the safety of of it you can see the scores we have at the top uh we go into supply chain security Quality Maintenance vulnerabilities and license and then we also call out any uh risks as big Banners at the top of the page so as you can see here the Event Source polyfill package that I've been using in the in all these examples actually has a protest where uh attack in it so what what's what it's doing uh and this is crazy to me that this is actually on npm still but this package if you install it in your app and uh and you you uh you know uh include it in your uh front-end JavaScript it will actually redirect your visitors to a uh another URL uh if they if their language is set to uh certain languages so what this means is actually hijacking some of your traffic uh to uh send to the to the to the URL of the attackers choosing and this is this is just sitting on npm today and so you have to basically know this and obviously a lot of us um aren't using tools like socket so we don't know that this might be in our apps today um so um how do you actually proactively protect yourself against this because you know you might not remember to check socket for every time you install a package and so to do that we have a really nice GitHub app so if you install the GitHub app then anytime uh developer is sending in a pull request uh to change code socket will come in and leave this comment which contains information about the risks in this package and you can see here we say you know we include an explanation explaining exactly what this will do so this empowers teams it gives developers visibility and it lets them know hey this package is you know it's it's it contains risks that you should know about uh and especially if a dependency has changed in its Behavior recently so for many years it behaved one way and then suddenly it's now behaving a different way that's a really really strong signal that hey maybe we should take a closer look here um so this should be communicated to the developer before they update to this bad version the key idea here is that the leading organizations the leading teams they want to shift security from being something like a gatekeeper to being something that enables teams to be secure by default so that's the goal here is the goal is to enable teams to be self-sufficient and Empower developers to be part of the solution uh so using CI is a great way to do this because you can you can communicate it to devs in response to their pull requests you can detect risky behaviors dangerous API usage all this kind of stuff and you can put that information into the pr so the developer can see it and can act on it um so this is you know this is another example of socket doing that this is a package that is a typo squat so the developer actually installed the wrong package here and you can see socket comes in and says hey um you know you might have installed the wrong package here are you sure you really wanted to install uh bowserify instead of browser file which are a very very different packages so uh really you know this concept of adding a speed bump double checking with the developer that they intended to do this is really really great idea uh and if you do this right you can really increase velocity and Empower developers um so if you do that we can really live in this new world where we have a lot of um a lot of third-party code a lot of apis all these all these dependencies but we can do it safely and so security and security teams and developers can be on the same side because both teams really want to ship secure quality software and we can do this together so with that I will jump into a quick demo of socket and you can get a sense for um uh um uh can everyone see me by the way uh still I hope so um yeah we can also see you I'm just hitting your screen whilst you're getting it setting up so yeah okay but yeah just a quick reminder some uh housekeeping there's lots of questions coming in that's great participation in uh in questions and chat is rewarded in the form of Amazon gift cards so we have two to give away today um so I gotta say yeah there's a couple of a couple of winners here team Netherlands Robin is in the lead if you want to knock Robin off the perch then make sure you participate uh they're going on there and uh for someone you're really just oh you've done it perfect we're ready to go cool cool all right yeah so so here's a uh here's an example of uh of using socket to to learn some interesting things about a package so let me just let me just start off on our home page here and I'll give you a demo of this so uh say that I'm an angular developer and I'm looking for a calendar package so I'd search angular calendar I want to I want to include a calendar widget in my in my page so if I search on socket the first thing you'll notice is you get these nice handy scores over here and you get um really helpful search results and if I click on the package you'll you'll notice that you get um issues you know risks that are highlighted right here uh for you as a developer and uh if I click on the issues tab you can even get like a full list of different risks that are present in this package and I want to highlight one particular interesting risk here which is uh Telemetry so this package actually contains tracking code that will track the behavior of your users as they browse your website or or or um you know that kind of thing and it's it's um it's not documented really in the package so this is something that socket can highlight for you um another example I'll show you is uh this is a package that um uh has already been removed from npm so this one is malware but just to give you a sense of kind of like what what socket would have detected if you had attempted to install this um you can see here uh we detect the install scripts we detect that there's a cve we detect suspicious strings we detect network access so before you install this package you can actually see all these risks that are present and if you're curious you can even click and see a little bit more about what exactly would happen here so you can see this is going to run a pre-install script it's going to run this file here node index.js and you can click in and see exactly what would happen so if I actually go to that here index.js take a look at what this package would have done to your computer if you had installed it it would um collect a bunch of tracking data about your machine including your package Json file your host name your username your DNS servers stuff like that and then it sends it off to this URL right here um which is you know owned by the attacker so not not something that you want to run on your computer so that's that's a that's another example there and then finally I'll just show you okay so you know we've seen what socket can find in packages but how do you actually make this useful in your app so if you go to the socket website you can click install GitHub app and uh select your repositories that you want to protect and within you know two clicks you can actually protect your whole um team in your whole organization from these types of attacks so if you do that then what will happen is whenever a developer into the pr let me show you what this PR looks like here so you can see here we're adding angular calendar that package from before and uh you know it looks fine I don't see anything suspicious here I mean github's not showing me anything but if I go into the conversation view you'll see that socket has um come in and if this page can load very refreshing okay so yeah if you come back to the main page here you'll see that socket has left a comment with a list of risks that are present in the package including install scripts and Telemetry with information about how to disable it if you'd like to so all the information is provided right here for the developer so they can take action so that's my demo um if you want to give stock it a try again go to socket.dev and you can click install GitHub app here and you can try installing it in your organization it's free um so go ahead and give it give it a shot and um and now we can do questions so yeah McKenzie do you want to you want to pick out any that seem good to you or do you want me to just uh be the ones that look good um yeah let's let's tackle them so there's quite a lot um which is which is great so we can I mean we can stop um they all look they all look pretty relevant um so I mean let's let's just go through let's just go through them one by one for the moment while we got while we got time so the first one's from Robin so when a platform like code covers breached uh how would you as a customer remedy that how would you fix consequences so this one this one was actually kind of uh earlier on US during my part so I'll take take this one quickly but um so when it comes to a breach like code curve I mean if we take this specific example they're all different but what what was happening with codecov is the attacker was trying to get into private GitHub git repositories why because there's lots of secrets in there so they were basically trying to move into that was their specific Target now it may have been they were trying to get VPN access it may have been that we're trying to gain data and they could have been access to databases there could have been lots of different reasons and it comes down to good development practices so don't have secrets in your repositories that wouldn't have stopped them from getting into your repositories would it would have stopped them from moving forward right so generally they needed additional vulnerabilities to exploit in this case don't use production credentials in your test environments right because then we're limiting our scope so it comes down to good practices can you stop it no you can't I mean you were always going to use dependencies we're going to use third-party tools um I'm not an advocate against that but we just have to have the posture of uh of being able to deal with a breach and that is the last question that I will answer because um and I'll leave it over to Fair us now but the next question we have here is how does socket keep up with the rapidly growing number of Open Source libraries across JavaScript Ruby Java Python and other words how long between new open source component being published and socket doing an evaluation of the components that one's from Brian Wallace thank you Brian for asking that question that is too difficult for me I'm leaving it over to you yeah great question yeah so obviously there's a ton of Open Source packages out there uh npm by itself has two million packages uh and if you look at the number of versions of of the packages published it's almost 10 million so uh there's a lot of code out there a lot of different packages to evaluate so socket what we do is we watch for new packages being published and we evaluate them in real time so uh whenever a new version comes out we immediately analyze it and look for risks and that's so that we can help detect malware and get it taken down from npm immediately so we can report it to them and they'll remove it and usually they're pretty good about removing stuff within a couple of days um and and in the meantime we'll actually put the the package that's malware into our own database and will protect people who've installed the socket GitHub app for installing that package so um that's the way we do it now for um you know so in terms of the time there it's like pretty fast so usually we get notified within a couple seconds that a new package is published then we start the analysis and uh when the analysis finishes after you know a minute or two then we have the answer if that package is safe or not so um so that's the way we do it um and uh yeah so it's it's it's a lot of work it's a lot of computation but um it's worth doing to protect people so that's that's what we do that's that's really quite impressive because I mean at Gagarin we scan all GitHub commits and basically at soccer you guys are protecting another area you're scanning all the npn packages um so yeah that is a huge that is a huge job I will not understand that so but thank you I'm sure the community the community appreciates it all right let's go on to the next question here uh okay from Robin is there a way to force maintainers to be secure this is an interesting one yeah I mean so there's some of this happening already I mean npm has actually recently announced that all maintainers of popular packages must use two-factor authentication to protect their accounts there's certain things that you can do that we can do as a community to improve the security of all packages such as enforcing two-factor authentication um but I think you know in terms of yeah at the end of the day you know what we're doing here is kind of crazy right we're trying to download code written by somebody we don't know and we're trying to run it on our computer and so like you know that should scare you that that I mean that that that idea right is is just inherently kind of it's just there's gonna be risks associated with that right no matter what we what we try to do so what we can do is you know we can scan the code before we use it with something like socket we can um you know we can we can create security standards for how the maintainers treat their own passwords and their accounts but really at the end of the day you know you have to you have to really either look at the code yourself or analyze it to understand Its Behavior in order to know if it's safe because you know you can write anything in a program that's just kind of a fundamental thing about about uh you know uh about programs it's just how it is so I think there's you know there's there's things we can do around standards and encouraging good behavior I think maintainers can look at their scores on socket but really um but there's there's there is some limits to what we can actually do here all right so you mentioned standards in there so almost perfect I don't know if you were looking at that but magically the next question if other standards guiding uh development of dependencies do do they exist where are they where can we find them yeah that's a great question so there's some stuff being put out by um openssf which is this awesome organization that uh is about securing open source for everybody so if you look up openssf best practices they have some guides for making dependencies secure there's also a guide that is being written right now for the node.js project which is covering kind of um main things that you can do to make your dependencies more secure um but there's there's some stuff out there yeah and and you can also check uh socket blog we have some information there as well on on kind of best practices okay next one is from me but you answered this one uh doing in there which was talking about like what are the indicators that we looked for and I think this is a really big distinction well for me it was about like where socket differentiates from some of the others is that you're actually analyzing the packages to provide additional context and provide additional questions that you can answer we're making an all-important decision to to should I install it you're not waiting for someone to find a vulnerability and report it you're actually looking for them that's really cool I just thought I'd meet that uh it's okay is it free forever or are you going to charge I think a lot of people we're gonna keep it keep it free forever for open source repositories and then for private repositories um it's probably going to be paid later um so we're we're still figuring out pricing it's an early uh an early product early company but if you're using it uh today um I would expect most of the functionality to be the same uh going forward if you're using it in a giant Enterprise then yes you know you should expect to pay for it um now this question here is interesting because you described some of this you actually checked the packages on npm itself but in your development workflow um how can you how can you Leverage socket to kind of preempt you or prevent you from doing something something I think that's kind of like what the gist of this question is is yeah how do you prevent them from from doing that or in an automated way yeah it's a great question so we're actually working on a socket CLI which is uh going to be released probably in the next week so I would say check out our blog uh stay tuned um there's going to be a CLI tool that you can use to check the safety of a package before you run yarn at or npm install so you'll be able to basically uh you know you won't need to remember to go to the website to check this out you'll be able to actually catch it before you run the install command and compromise your own machine that's that's the right place to check for it and so that's what the CLI is going to let you do and uh just to follow up on that how do we how do we keep in touch with your progress because I'm sure a lot of people here I mean at the moment you're providing huge help for the community how do we how can we keep up with uh your progress do you have a mailing list or something because that's something that I personally would be really interested in knowing is when that CLL tool and your other projects perhaps more Frameworks become available yeah yeah that's a great question Mackenzie so there's two main ways the first is if you go to socket.dev and you scroll down to the footer we have a box you can subscribe to our newsletter and put your email in there and we'll send about one email a month most to just keep you up to date with how socket is improving what new features we have that kind of thing and the other thing you can do is uh follow us on on Twitter um we're at socket security so if you do at socket security then you can keep up with us there as well okay so look we only have uh very few moments to go we've got lots of unanswered questions here but um we'll do I'll do one more just because uh I saw this one and it refers to geek Guardians products so I'll excited when I saw it is there things that can check Secrets inside packages before it get repository yes uh kid Guardian can do that we can monitor your repository as a whole or we have a CLI tool where you can actually check for Secrets at a pre-hook a commit pre-commit hook something to prevent them from going into your Repository so um I'll send that your additional questions through and um and hopefully we can answer them offline but we do have to um we we do have to wind up as we're coming to the to the end so I'll first just announce the winners of the gift card I saw something in the chat how does it work basically if you participate in the chat in the polls we didn't have any today but in future and by asking questions basically if you uh if you participate then you can win um then you can win some prizes so we have two Amazon gift cards to give away so the first one I can't ignore my boy Robin uh who's asked a lot of questions and participated lots of congratulations Robin uh you will win a gift card here and I'm just trying to see who else um they were uh Brian Wallace Brian Wallace as well congratulations I will email you both um uh after this and with additional information about how you can claim that so congratulations guys don't why would we do this every month if you didn't win a gift card uh this month you can win one again next month um here so follow our crowdcast account and keep an eye on git Guardian in our socials for the next webinars but uh first I want to thank you so much for coming here it's not often that a CEO really makes the time to talk to the community and what you're doing at soccer is really Community Driven so we appreciate you for trying to keep us safe it's not an easy task that you've decided to embark on uh but one we are very thankful that for doing so thank you so much for being here it's it was it was really a pleasure to listen to you and to have you answer our questions yeah thanks Mackenzie this is really awesome and awesome questions from the community so thanks everybody all right so that concludes it thank you all for being here and I'll see you guys all next time