Determining Who Bears the Burden of Ensuring NPM Module Security

Key Takeaways

[Music] we'd like to thank godaddy our sponsor for our podcast from no Jas interactive in Austin Texas you may know godaddy as a hosting company but they also have a deep involvement in the know Jas ecosystem you can learn more at godaddy.com that's geo da e dy com godaddy.com hey it's Alex Williams of the new staff here for Jay tube nodejs interactive in Austin Texas and today we're going to be talking a lot about security and I'm here with two people were actually you know participating in the conference guy Bjarni and girly emma is that it yeah looks for it and got you just spoke and perhaps you can tell us a little bit which is fast and you're speaking later on today on a security matter so you were snick and maybe you can also just a little bit about what's nick is and just helped us so much would be discussed it out pertains to like the end user out there high level our mission is to help you use open source and stay secure and there's some today there are some fundamental challenges around owning open-source security especially when you not talk about you're not talking about the big projects you know the sort of angular project that's backed by Google or react by Facebook but rather the you know 300,000 packages in NPM that are oftentimes built by 12 individuals just sort of know in the internet on their spare time so big hairy question around how who should be responsible for securing those components you know they have security knowledge secure detention and then also the consumption of these packages is it's quite complex and indirect so when there is a vulnerability in one of these packages that was already found and that was already fixed we see that it takes a very long time for people to to just find out about it and then pull in those fixes and secure their application that uses the packages so what do we do it's nick is we give you tools that integrate into your development flow to help you find vulnerable and p.m. packages and ruby in as well with more language that's coming and then fix those as easily as possible there's literally like a single button click fix for that sort of figures out the right patches and upgrades you need to do to fix the problem and then do that continuously as well as getting alerted to new vulnerability so you can respond to them fast so this is what we do this is kind of a lot of what we work in the note space and we're also part of the Ojays foundation kind of helping boost security there and what uh what my talk was about which kind of relates to this is first kind of raising awareness that specifically so making people aware of the fact that they should know whether they're using vulnerable NPM packages what do you think for that or or anything the tool of choice and then second these packages actually serve as a really good example of real-world vulnerable these when you talk about security education you know nothing is more impactful than seeing a live exploit a vulnerability and when you take packages like Mongoose and and Mark like very popular packages well scrutinized and you can see that they have a vulnerability first of all ego goes away like people sort of accept this El Camino if these big packages have Horner ability then it's okay that i have-- it and second it's it's useful to learn from you know what was the mistake that they've made understand its implications because you can actually show kind of a live hack on it and then try to avoid making the same mistakes in your own code so this talk was you know I picked we have a sample vulnerable application and we basically picked a show to exploit on a bunch of them you know kind of raising uh raising awareness both to the specific vulnerabilities and also to the secure code practicing you can derive and so you're talking tomorrow we're talking today I mean right and tell us a little bit about rising stack and in and what you're gonna be discussing yeah so um rising stack started as I'm not Jess development and consulting company and in the past year we have been building a tool called place or which helps developers to debug and monitor node.js applications as well as my services so that's our main focus and as we are having a lot of sensitive information from our users securities from the part of most priorities um and this is why I picked the topic which is surviving web security and today are really more about advanced topics and obscurity so it's not gonna be like cross-site scripting attacks but actually I will talk about attack Therese how you can use them to fight potential attack vectors in your applications and through attack trees I'm going to show readers attacks I'm going to show timing attacks and how the human factor comes into the picture when we are talking about security the human factor may be that we can talk about that a little bit because you know the people who are building these applications ah you know many of them are you know there's kind of the wide spectrum of people there's beginners there's you know there's experts out there but everybody makes mistakes right you know and and you know so what is you know what is your point of view on that what's the approach that you are the G that you are both advocating that that end-users think about no because there because people are going to be making mistakes and like the module ecosystem is so gigantic and there's so much actually that you need to be thinking about you know aware of you know how does that you know how do people you know what do you what is your what is you like recommendation yeah i think when we are talking about human factor it's a lot broader than actually just coding modules so actually hourly recent study shows that ninety-five percent for a security incidents in full of some kind of human error or whether it's be coding something was simply forgotten so it's not just good but actually how you operate your system so it comes into the picture as well but it comes to security issues in modules then i think one of the biggest thing that we can do is education so for example what guy spoke about it is like showing real life problems how you can fix them so basically you won't do that problem again you won't do that mistake again yeah i think i think alongside convolve these that are good practices as a whole I think for open-source security specifically there is a little bit of a responsibility question so I think I alluded to that before we need to get better as a community in drawing the line around what is the responsibility of the open-source author the open source package author versus the responsibility of the open-source consumer because today what happens is the open-source consumers think of this as off-the-shelf software and they expect the same level of like entitlements and warranties that they get from from from vendors that they pay the open-source authors you know they're doing this on their spare time you know they're doing them for good will they get some value out of it but they definitely are not you know you're not entitled to anything from from these people that are sort of giving you value from fruit for free so I think we need to better sort of delineate the two as far as as kind of my recommendation to the two entities I think as an author I think you should do your best to care like you know the kind of the first thing is you know care about security think about it try to to write secure code and the second thing I would advise is to declare so naturally as you're right code you should you make security trade-offs you decide whether or not to run a security test you decide to communicate in HTTP versus https that information is hidden in your head and in your code if you can declare that add a security md file to your repo just sort of inform people about that it'll make it that much easier for the consumers to to be kind of informed on the consumer side I think what you need to do is just take responsibility and and understand that you are getting this value for free but it is on you to a large extent to to understand if there are security flaws if there are security mistakes and not just sort of shared responsibility for it build that into your own processes so when you think about these different issues and then you think about the overall you know module ecosystem out there and and how vast it is right what is it that you think needs to be done almost at the abstraction level you know to help kind of you know make these kind of larger principles that you're talking about for both the author the end-user more realistic right because it means you can there can be a lot of you know community advocacy around these topics but community advocacy can only go so far yeah I think so no starting from what you cannot do is you cannot expect developers to become security experts you know that's just infeasible it's hard enough to be a developer these days right in terms of evolving the avalanche of information you need to absorb and you can't really expect them to build security expertise overnight but i think the the solution lies on one hand with tools so you need sort of tooling providers be it github or be it tools like like sneaking trays or other tools to make it easy security has to be sufficiently easy for you to do it today security is just too hard and then as a community I don't really have like a solution about how we do it but what would be amazing is if we can figure out a way to incentivize secure code today if you have an open source package and you spend a lot of time to make it secure you really don't get any credit for it there's no there's no way for you to get some you know security plus 1 right some kudos for it you just you know spend time that did not translate into function so as a community I think it would be amazing if you know through github through others through just sort of celebrating people to do it right we find a way to just acknowledge and incentivize the people that do it well yeah I totally agree and also if I'm right and p.m. for example working on a batch system so module can be marked if they don't have any known security issues which could be a great indicator even for from the consumer side that okay it's something that was verified I can use it probably probably it's not have it doesn't have any issues and we see that we see people adding like the snick badge says vulnerability 0 it serves two purposes you know one is it declares that this component has cared about this issue and has looked and saw that it's not using vulnerable dependencies and two is it tells you that you should care you know when you're looking at that repo and raises awareness so tell us a little bit about the tool ecosystem out there you know kind of in the context of security how is it different now compared to like a year ago what and what and what what effect is that having I think that or what does announced yesterday was a really great use that the most security project just move to the foundation so basically security is now part of the foundation and I think it has a really great story that it becomes one of the topmost priorities of the foundation as well so all vendors like sneak the not security platform trace can simply contribute to these security findings to make it a really community effort to secure the knot ecosystem and I think that's great I think you know first of all it's awesome to see the node.js foundation declaring and I think they did the same note summit and earlier this year to talk about security as a top 3 item you know that's not obvious it's not a given and it's great that that attention happens that that at conferences like this there are multiple security talks you know I do a lot of conference talks and you know it's really not a given that in a developer conference you'll have it so first awareness i think has grown dramatically over the course of the last year in terms of the tooling ecosystem I think there are more vendors in here you know I'm a believer I think building a business around open source is a really tricky thing and when done well I think it contributes to both you know promising business and and sort of a thriving community so I think we're basically in that exploration phase right now there are tools like NPM for instance that's not security oriented but it is a commercial entity within the open source node space and there's always some complexities around how NPM and the node.js foundation interact and the note the node.js foundation kind of tracking formable packages is a good example of this the vulnerable packages are in NPM they're not in node so on one hand it's great that the foundation does it on the other hand again there's just like some some unclear ownership comes back to kind of this like ownership and delineation but but again i don't i don't think anybody can anticipate the perfect answer right now but what I feel is there's a lot of evolution in the tooling space right now you know snake i think is a component of it we see sort of the node.js foundation working on a lot of security in the node space tools like trace and note source have integrated with us for instance to sort of build tracking and identifying vulnerable packages on running servers and we have a bunch of those so i think a lot of it is around building awareness subsequently tools and a run bringing that tooling back into your existing workflow i think one of the that's maybe another evolution that happened this year is that instead of expecting you to learn and embrace and independently use an entirely new tool these tools you know like sneak coming to github or trace doing a variety of monitoring and bringing the security assessment into it or a note source when you're monitoring kind of your runtime platform all of these tools come to your existing practices and make security a built-in component so it's that workflow then yeah that you need really yeah and those so that it's really so make it accessible so basically I it shouldn't be a hassle but yeah as guy described as well for example we trace our users don't really have to do anything so they just updated our trace collector version and they got the security feature so that's a really convenient way to have some kind of security in place with basically zero effort there's a like fundamentally everybody wants to be secure but there's how much they want and then there's how much effort it is RAM and they need to want it more than it is effort so the two ways to make security happen is to increase how much people care which is a long process that needs to happen and you know we get the the help of news and headlines that sort of raise awareness to it and we get the help of talks like this and then there's the the path of just making using it easier and I think that's where a lot of the tooling opportunity kicks in is just make it simple make it accessible you know allow you to continue to move at your existing pace but build secure process secure software in the process so what would this security group do to help do you know to help you as tool makers contribute more you know to you know the the overall kind that workflow experience we're talking about what is it what is that we know what is the role that secured to user group could have really going to be for you know for you as toolmakers probably I think the first thing we should clear is how security disclosures work because it's something that haven't been really clear as I see so if there are some known issues how should it be disclosed the when should it be disclosed if it's either fixed or not so I think that's one thing that this group have to define first and I think I would kind of point 23 i thinkI items you know one is is keeping a node.js run time itself secure and I think they're doing an excellent job at it i think that is dramatically improved since the foundation has been created and I know I'm kind of you know a little bit of a broken record here but I think that comes back a little bit to ownership which is it's very clear who needs to own that and take care of it and they're doing a great job at it the second is is awareness because i think the node.js foundation people look to it to understand what is the best practice and what you should do and and again i think coming to events like this is not a component i think the security user group is the one that sort of sets the the tone around what should be emphasized and what shouldn't be so those conversations are happening that's great and then lastly on the technical level I think it's about support for the different tools so sometimes you need you know hooks in the runtime to be able to you know perform some instrumentation or get some visibility or be able to you know run something post-installation so you can modify a vulnerability or so I think just being responsive and aware and collaborative with the the vendors is useful there's a little bit it's very easy to take security tools as finger pointers it's very easy to say hey you know it node you want to say note is secure and when or like a 10pm for instance right npm as an entity is very secure but they have a lot of these packages in this package of sometimes insecure and it's easy to interpret somebody highlighting vulnerable NPM packages as pointing a finger at NPM and saying you shouldn't be doing this because it's insecure and it's not at all the message and in the world of security as a whole and in the world of node and NPM specifically I think it's critical that the the anchor tenants the 9pm a node look at the security tooling at the security research that happens and collaborate with with those tools as opposed to trying to pretend that the problems don't exist and you know I think I think there's a little bit of improvement to be had there in the current space improvement well I guess I feel like this is going very very well on the node front over the last year but sometimes in the in the NPM space be at the NPM package owners or sometimes the NPM kind of platform you do see some more pushback around you know preferring preferring to not have the conversation on some of the issues versus versus a sort of accepting you know almost thankfully right the fact that there are there a problem so it's just like it's been a little bit more inconsistent in the sort of the NPM package space and then p.m. space in the notes base i think right now there's a lot of arms wide open to researchers and security tools that kind of come and help eventually secure the platform i guess that speaks the the both the working together and then some of the inherent conflicts that come with you know node an NPM yeah yeah its finger pointing a little bit right now you're pointing out the floor nobody likes yeah you know when you call their baby ugly so it's a it's it's not a simple thing right it's a whole topic in itself so so what's your view on that I mean in terms of like you know the thought about that conflict in the kind of inherent call you we're seeing this a lot kind of not just an p.m. to but like in like you know a module management overall if you know there's a lot of different kind of groups out there that are that they may have like VIN VIN need to work together better like is it tc39 is that what it is or and you know in the note J ask unity right like and like thinking about you know actually you know what what do you actually people use and what would be like the common kind of ability for you to be able to make them be able to work you know these different modules be able to work together right and you know and so this seems to be kind of like one of those like just very long term kind of problems that we see in the in the in the ecosystem where we're all yeah i think when i first met its cute it was like five years ago yeah actually does adams talk in lisbon so I think it should air that was the time that the security project was announced so since then a lot of things improved there but yeah it's a long process yeah yeah i think it's a it's also not a process just the clever we're here talking about no than nvm this problem exists throughout the sort of the sphere of open source to source packages and I think NPM is ahead in terms of adoption and distribution and no just just the sheer growth of it make it a little bit of a flag bearer for ya the volume are before the problem right it's an extreme manifestation of a problem that actually exists in various environments like we support Ruby as well and there are different practices there with gems being global and with you know the log file encouraging you know less updated deliverables and so like each echo system has its own variant of the problems but it's important to also understand that it's not that unique I think what the node.js foundation really helps us is the fact that there is sort of this clear entity that we work with with regarding to too many of these conversations if you look at Ruby you know it leadership is not quite as clear right if you look at Java it's like more fragmented so I think I think note is is an opportunity for us to sort of get many of these things right like for me it's nique we started with node because we believe that note is kind of the opportunity to set a model to how sort of truly tackle securing the the sort of open source package ecosystems and now that we sort of feel like this is in a good state and it's a ton of work still we're sort of expanding to other spaces and they'd you know I still believe that path well great well thank you guys both for taking some time to talk with us today I appreciate it and having to have a good time with the show and you know and and we'll talk again soon Thank you Thank from thanks [Music] we'd like to thank godaddy our sponsor for our podcasts from no Jas interactive in Austin Texas you may know godaddy as a hosting company but they also have a deep involvement in the know Jas ecosystem you can learn more at godaddy.com sgod a TDY calm godaddy.com [Music] two