JSJ 456: Developer-First Security and Security Tooling For Developers with Liran Tal & Brian Vermeer

Liran Tal and Brian Vermeer from Snyk join the panel to discuss development of secure software in general, and secure JavaScript and web dev in particular. They explain what developer-first security actually means, and the types of security vulnerabilities to watch out for when using modern tools to develop websites and web apps. They also present several Open Source tools that developers can use to improve their code right from within their favorite development environments and IDEs.

Show Notes

Liran Tal and Brian Vermeer from Snyk join the panel to discuss development of secure software in general, and secure JavaScript and web dev in particular. They explain what developer-first security actually means, and the types of security vulnerabilities to watch out for when using modern tools to develop websites and web apps. They also present several Open Source tools that developers can use to improve their code right from within their favorite development environments and IDEs.

Sponsors
Panel
  • AJ ONeal
  • Aimee Knight
  • Dan Shappir
Special Guests
  • Liran Tal
  • Brian Vermeer
Links
Picks
Dan
AJ
Liran Tal
Brian
Follow JavaScript Jabber on Twitter: @JSJabber
Special Guests: Brian Vermeer and Liran Tal.

Transcript


DAN_SHAPPIR: Hello everybody and welcome to another episode of JavaScript Jabber. Today on our panel we have Amy Knight.

AIMEE_KNIGHT: Hey, hey from Nashville. 

DAN_SHAPPIR: AJ O'Neill. 

AJ_O’NEAL: Yo, yo, yo. Coming at you live from Hematoma. 

DAN_SHAPPIR: Myself, Dan Shapir, playing the host. And we've got two guests this time, both of them from the same company, the company I think whose name is Sneak, but we'll learn about that more in a bit. And our guests are Brian Vermeer from the Netherlands and Liran Tal also from Israel. So hi, you guys. 

BRIAN_VERMEER: Hey, Dan. 

DAN_SHAPPIR: We usually like to start podcasts with a quick introduction of our guests. So you choose who goes first, but if you can give us a brief background about yourselves, why we should know about you, what makes you famous in the community, and what's the stuff that you want to talk with us about today? 

LIRAN_TAL: Go for it Brian. 

BRIAN_VERMEER: All right, cool. Oh, okay. I'm the least famous one of us two, probably. So my name is Brian Vermeer. I am based in the Netherlands in a city called Breda, which is close to the Belgian border. What I do, I am a developer advocate and engineer for Sneak. And you pronounced it correctly. I mean, what makes me famous? I don't think I am famous at all, but what we do is we try to get that. Well, we try to talk about security and get security and make security easy for developers. That's, that's the basic goal we want to strive and that's within the JS ecosystem, but it's in many, many different ecosystems that we try to do that. And well, we have our leaders and our people that make a lot of noise about that. And I think that's the point where Eliran comes in because he's very much more of us within here then, and then I probably am. 

LIRAN_TAL: Yeah, no, not famous, but I'm probably mostly known for my role around the Node security working group, Node.js security book I wrote and things around that. So that's like Brian, I'm trying to advocate as much as we can for developers and security around those spaces and Node and JavaScript. And so Brian is completing me in a sense, he's coming from the Java ecosystem. So I think a constant engagement between us is throwing each other back and forth. And that's the fun part of the day-to-day job.

BRIAN_VERMEER: I'm glad he still finds it today. He still thinks it's fun. That's a good thing. So the work relationship is still healthy. That's good to hear. 

 

Leveling up is important. I spend at least an hour every day learning ways I can improve my business or take a break and listen to a good book. If you're looking to level up, I recommend you start out with the 12 week year as a system to plan out where you wanna end up and how to get the results you want. You can get it free by going to audibletrial.com slash code. That's audible trial.com slash code. 

 

DAN_SHAPPIR: Well, when a Java and JavaScript developer can get along, that's definitely a good thing, you know, despite the commonality in the name, there tend to be significant differences in outlook on life and stuff. By the way, Liran talking about Famous, I think that you also made a notable contribution to webpage tests recently. 

LIRAN_TAL: Oh, indeed. Yeah. Thank you for noticing that and mentioning we've actually reached out to Patrick. He's a great guy. And we worked on adding the security part of performance testing, just giving you a whole 360 kind of view when you test websites. So you're now educated about security issues in your websites as much as we can tell about them. 

AIMEE_KNIGHT: We should talk about that. That sounds really interesting. 

LIRAN_TAL: Definitely. Yeah. 

DAN_SHAPPIR: Good thing we have Liran on our bot. So, you know what? Let's talk about that. Why not? Let's start with that even is an excellent online utility that you can just go to that website, webpagetests.org, put in the URL of your webpage, and then it just does a whole bunch of tests on it. Essentially, loads it in a virtual machine somewhere. You can specify where, emulating whatever browser, or actually using whatever browser you prefer, and recording all the activity that takes place. So, it records the network activity it records the CPU activity and so on and so forth, because they actually have access to the virtual machine itself. They have a lot of information about what's going on. And then they present a really detailed view. So for example, in the context of the network, you get an excellent waterfall of all the network requests, when they started, when they finished, so on and so forth. You can also see screenshots, so you can correlate between resource downloads and what a visitor actually sees at any point in time. And then you added stuff to that. So maybe you can tell us in more detail what exactly you added. 

LIRAN_TAL: Yeah, that's, that's a really good description of what web page this is. I guess worth noting it's an open-source project, so you can run it, you know, hosted if you needed to, or just, yeah, trigger the public API and just use that. And indeed it, it kind of focuses it's, you know, for created, you know, by and for the web performance community and has a lot of like top metrics, like first by time, you know, keep alive enabled of those like top level scores. I think it tries to do some accessibility and not tell each like, you know, to which extent, but yeah, what was essentially missing is, you know, giving, giving users who use that as a security score. So whatever we can tell them, I think it's worth noting that, you know, there's no, like, it's not a pen testing tool. There's nothing like too aggressive and obtrusive about it. It's anything that we can figure out about what you're actually using, you know, from externally testing a website. And basically that is we have access to figure out the downright, whatever JavaScript libraries you're actually using. And the other part is we know from the server responses, which HTTP security headers are being returned. So if you're not, if you're having like a content security policy, or you're not having that, we can note those things. So I would say the major success with web page test enabling and having security by default is the fact that we're now having, you know, a ton of more users and developers, you know, using web page test, super aware about their securities the security posture for the website, right? And I think that's like the most important thing. And as they go and explore what kind of score they got, then, you know, what are the, what are the steps needed to fix it and make things a bit, you know, in a, in a safer state, you know, we're giving them tools and actions and how to make that happen. 

DAN_SHAPPIR: So in case people aren't aware of it looks at the top right hand side of the webpage test results screen, you got, you get grades from A to F and they also have color code, so it's easy to tell whether it's good or bad. And I think the first one on the left, the very first score, is actually the new security score that you added. And then if you click it, then you get to that part which actually I think describes why you got the score that you got and what you should focus on improving or fixing or rectifying whatever, correct? 

LIRAN_TAL: Sure, indeed. 

DAN_SHAPPIR: So I think that's very cool and very useful and I think also indicative of the kind of stuff that you're doing and the things that we're going to be talking about today, which is introducing tooling that help developers create more secure software, correct? 

LIRAN_TAL: Yep. It's kind of, kind of the goal, right? Like how do we make security easier? How do we make it part of the workflow rather than something, you know, that's, you know, adding more friction. So we want to lower that down and make it easier for you as a developer to fix whatever security issues are there. And yeah, I think Brian can, can we've done a bunch of things. Super interesting, Brian has been leading some of them. So Brian, do you want to share more about some of the other experiments that we've been doing? 

BRIAN_VERMEER: Yeah, yeah, definitely. I think the key point in this is that as a developer, you have a certain way of working and everybody's way can be different. Either you want something that is included in your IDE or myself, for instance, I'm more of the comma line tools. So instead of forcing you with a certain tool that works in a certain way. We try to integrate our capabilities of scanning, for instance, your dependencies for vulnerabilities. We try to integrate that in many different ways. And one of the things we did recently was we create an extension together with some folks from the community. And that extension is called vault cost. It's for VS code. And what we try to do there is intertwine that knowledge we have about a dependency right into your IDE. So if you for instance, try to import a certain package. You will definitely see it directly inline. If that package you're trying to import that specific version, if it has a vulnerability or not. And by click of a button, if you can fix it up by moving to a newer version or not. And that's, we try to do that in many different ways. Like for instance, when you're actually coding. So you have a JS file open or TypeScript file open but also if you're editing your package.json, for instance. So in many different ways, because we found out that developers just work in, well, they have different ways of working and we want to help them out. Instead of creating new process, like how to do it, we want them to adopt the tooling that fit their process. And I think that is the most important thing if you want to supply tooling for something like security. 

DAN_SHAPPIR: So you said, what was the name of the extension again exactly?

BRIAN_VERMEER: VOLN cost, VOLN as in vulnerability and the cost on how much it costs, how much depth you actually create with that. 

AIMEE_KNIGHT: I'm about to add it right now. 

BRIAN_VERMEER: It is part of the VS Code marketplace and it has a logo with a little little padlock on it with a dollar sign on. If you install it, what it immediately tries to do is it looks at if it's a standalone JavaScript file, it parses out the JavaScript files and looks using an API, it looks if there are known vulnerabilities and it picks the latest one because at that point we know not exactly which one you're using, unless you are using a CDN or so in that kind of fashion. But otherwise, if you're using NPM, for instance, we're usually looking at your whole project and we are looking at which version you actually imported and show you which version it is. And if you connect it to an existing sneak account, which we need for the remediation advice which is actually free by the way, but we need to access that part of the API. We needed to have a token for that. Then you can actually have that advice like, okay, you're using a version 1.2 and you need 1.2.2 for instance, to get it fixed, to get that specific vulnerability fixed that is in there or to lower the amount of vulnerabilities. And to get it as easy out as that, we believe that that will engage developers more to actually fix it. Instead of leaving it first creating the new features and afterwards trying to fix it, which we found out costs a lot of more frustration or may it makes up for a lot more frustration and a lot of rework because it then people found out that that they are using that they need to use a newer version and that actually break the break of our broke API. And then we that's that's the hassle. So if you import it and you see it right away, then you can already figure out, hey, maybe I should use the newer version. 

AIMEE_KNIGHT: Just to give people listening like an idea, cause I literally just installed it. I'm not seeing anything in my files yet, but like looking at your documentation that's pulled up in VS code. So it kind of looks like reminds me of like ESLint where it's just going to like underline where it is. And then like it's, I can see like somebody's importing express or requiring express. And there's, it says there's like six vulnerabilities. 

BRIAN_VERMEER: Exactly. And it shows inline, it shows the number of vulnerabilities and if you can fix it or not.

DAN_SHAPPIR: In terms of the remediation suggestions, it is essentially suggesting just to update to a version that has a fix for that particular issue? 

BRIAN_VERMEER: Yes. What we do is we look at the package and the package can have multiple vulnerabilities. So that means every vulnerability can be fixed in a different version. But then we look, okay, what is the common version in that that fixes all of them? Or if that fixes the most vulnerabilities. Let me say it like that because it can still be that there is a vulnerability that cannot be fixed yet. That is the near remediation advice we give because if you use a version that is way outdated and then it can be that in a newer version, say a newer bug fix, one of the vulnerabilities is fixed, but three versions up, more vulnerabilities will be fixed. So we give you the nearest version that actually fixes the vulnerabilities that will probably not be the latest and greatest can be, but we will give the one with the smallest delta that does remediate as much vulnerabilities as possible. 

AIMEE_KNIGHT: So outside of, you know, using it in VS code, are, do you guys build out other tooling as well? If I guess, what if let's say I want to like update something in package JSON, and then I do an NPM install. Do you guys have tooling around that as well? 

BRIAN_VERMEER: Yes, yes, definitely. We have, we have all sorts of tooling available. I think the easiest way is to, to download the sneak CLI that can basically do everything and is in some ways is the engine for a lot of the other stuff that we do by doing a sneak test with that CLI. If you're authenticated with a free account, if you do that in the root folder of your, well, this case, your, your, your note application, it will pick up your package dot Jason. It will look at the dependency tree, it will actually, it will gather the dependency tree, sends the dependency tree over to our side of the system. And we just cross-check if there are any vulnerabilities, what the severity of the vulnerabilities are. And if there is a remediation advice and what that remediation advice can be. And then we show you basically in line or in your terminal, we show you in a report of what should you fix to or watch or to what version should you upgrade to fix what kind of vulnerabilities. That is the way you do it on your local machine. But we can integrate with CI systems in that part. You can connect your repository to our SaaS solution and basically scan it on a daily base that you get actively notified when there is a new vulnerability found or a new fix found for a vulnerability that was already there. We do a bunch of integrations for other ecosystems as well. So we have all bits and pieces that in the baseline, we do the same thing, looking at your third party libraries and see if there are known vulnerabilities and what the severity of that is. But we can supply that information to you in very different ways and in very different stages of your software development life cycle. 

LIRAN_TAL: Yeah, that's why it's pretty diverse now having the today. It can also support and scan things like Docker images, which, you know, usually developers also kind of maintain and use or you're like, no, on the advanced side to the SRE, like we think, grenades and stuff like that. We're also scanning those. So it's kind of like a one, shall I dwell them all and be very handy in those aspects. 

DAN_SHAPPIR: I was away from the podcast for a minute. So I, hopefully I didn't miss something that you said, but I just to verify something, to make sure that I understand the tool, the extension for VS code, which is free, that gives you information just within your development environment, again, going to your database, assuming you've got the token. But if I wanted more of an enterprise solution that works, let's say, with a team of developers or integrates with my DevOps processes, CICD, whatever, then I would use one of the sneak products, correct? 

BRIAN_VERMEER: Exactly, you can use one of the sneak products. 

LIRAN_TAL: Yeah, I wouldn't position it specifically as an enterprise thing because you just might do that for like a small team or like, you know, your open source project. So you could still connect that and, you know, window all the same stuff, you know, getting an automatic request to fix it and so on. So it's all part of like the offering, which is anyway free. 

DAN_SHAPPIR: So cool. But in, in this, so the VS code extension that just provides me essentially all this information from within the development department. And I can just click it and it will just go and patch the package JSON from you automatically, or does, or does it just point out the problems?And then I would need to go and patch the package JSON. 

BRIAN_VERMEER: It points out the problems in this case. For now, we look at the, at what version you're using and to what version you should remediate, and then you have to do that yourself, because if we do that by the click of a button, we feel like we are too intrusive into the process of a developer. So now you can choose if you want to update that one or maybe even use a newer version, so we give you all the information and then you have to, or or common line and use your common line tool or your terminal to, to, to install a newer version via NPM or change your package.JSON exactly the way you want it to work. And then I'll basically redock your application, assuming you're using NPM. 

DAN_SHAPPIR: Cool. But sometimes I guess picking between versions is almost kind of choosing the lesser of evils. I would guess, I would assume that in some situations, whatever I choose, there are going to be vulnerabilities there. So how do you handle situations like that?

BRIAN_VERMEER: would basically say step by step because you start with a version and that version might not have a certain fund or that might have vulnerabilities, but have might not have a certain vulnerability that is discovered later on in a newer version. So it can actually be that you create something or patch something in or pick a newer version. And then you end up with a total new package of vulnerabilities. And that's why I wanted to say that if you do this early and often that you find out there are a few vulnerabilities, for instance, and you fix them already and you go on and on. So the delta of you fixing these kinds of things will be small. I believe that is the only good way of working regardless of which ecosystem or which version or which thing, if you're talking to dark containers, is exactly the same because a newer version can bring in new issues, et cetera, et cetera. So do it step by step. And as I believe that all listeners here will be, will be excellent developers. So we have a set of tests available that will make sure that the state, that your program is still working, fix them one by one, run your test suite to make sure that it's actually still doing the job you need to need to be doing, and then go on and on and try to go for a level that you're comfortable with. I wouldn't say specifically go for zero vulnerabilities in the end. Of course you want that, but I can also imagine that some vulnerabilities that you see and we name them, like what, what do these vulnerabilities actually do? What kind of vulnerability is it? And if you know that like this one is not so important or this one has, well, has, is less vulnerable in my situation, because that depends on the context, you might be believing that. So if you're comfortable with a certain level, you just want to make sure you're not getting worse in a certain, in a matter of speaking. So again, that depends on your way of working if you're an individual, if you work in a big team or not, but I would say again, do it step by step, run your, run your test suite to make sure that it does, still does the main job and then fix new ones and try to make the fixes as soon as possible to make sure that you do not have to up your level or up your dependency or your package to a new major version, which probably will break API. 

LIRAN_TAL: Yeah, I'd probably add that in terms of those, those kind of like steps. I think what we're trying, what we're seeing as a dilemma, right, with developers, but in open source and, you know, companies is how do you, how do you lower that signal to noise kind of ratio, right? How do you make it less friction, less, you know, less wump and flood developers with issues. And Amy, you mentioned, you know, it kind of resembles the sling, which, you know, is something you're trying to also like, you know, don't want to save a file, commit it for state and then linter's throws at you a hundred linter errors, right? But we're still using Realtors, right? It's a way to kind of like standardize guidelines and, you know, code style and whatever you're using it for, but kind of that's what we're trying to do. And I think that's kind of like the distinctive way that that sneak works, right? Where Brian mentioned the thing about the way that, you know, you were trying to get you to the most minimal sember version possible to create an upgrade, but also by default, you know, what we're, what we're scanning for is the prod dependencies. So if you have some stuff in depth dependencies, you know, you, we may not just give you that information out of the box. You may opt in for it, but we're trying to really reduce the noise for you as a developer to really focus on the most important things as possible. 

BRIAN_VERMEER: And again, when you scan for these kinds of things, you can already say, okay, I want you to be notified for only severities or only vulnerabilities that have at least, that are at least having a high severe or are at the level of high. So you have low, medium and high severity vulnerabilities. Maybe you do not want to get even notified by low severities. So you can pick and choose already in that. Then you just have to make your own reasonable decision if you want to switch these versions out. 

DAN_SHAPPIR: Without really shaming anybody, because I think we've all had vulnerabilities in our software. So it's really the reality of building software that you have vulnerabilities, but can you give examples of some of the vulnerabilities that you identify and recommend? So we kind of get the feeling of what we're talking about. 

LIRAN_TAL: Yeah, sure. I mean, vulnerabilities come in all different, I guess, sizes and tastes and whatnot. I would add that some of us also create vulnerabilities. I'm not shaming anyone, I'm included here on creating vulnerabilities too. But it's like, it's the fact of life, right? You're not creating software in a vacuum and everything has, you know, bugs and needs some attention and so on. This is kind of the way we think. It's really, it's anywhere between having SPL injections and, you know, cross-site scripting, so any kind of like these vulnerabilities will be really well fleshed out in terms of, you know, what we report on. I've seen, if you remember, there's been, there's been a lot of issues with some popular libraries on the genotype systems around prototype pollution. And that has been something that also sneak really endowed in a security research. So we've been raising some of these and working with the maintainers to fix them and create patches and so on. And this has been super received well by the maintainers and by the community. But to an extent, this is also something that's created a lot of noise, right? Like what, what extent the prototype pollution would be ever some. So it's not all the time. I think the problem with security in a sense is that it's mostly invisible. When you are super secure, there's nothing except maybe like a scanner, like this security scan that tells you zero vulnerabilities. But at the same extent, how do you quantify, I have an unread vulnerabilities, what's your level of exposure at the moment? Is it the amount of time you have them unpatched? Is it severity level, the CVSS? Is it exploitable? So many things that you need to take into account to figure out what is your current status. But it's super hard when you don't have the visibility into it. And I think kind of like understanding that even something as a prototype pollution is something that would be having very tangible impact on a system. If so to say, it's just important to understand that, you know, this is something that can happen. I think one of the experiments I've actually done probably about a month or two ago was we have this Goof app, which we use for demos. So if you go to it's open source, or if you go to like the GitHub repo, sneak slash goof, you would basically get a JavaScript out end to end with kind of vulnerabilities and also exploits inside and like help you experiment with this and do this. And what I've done is added this prototype pollution in one of the popular ORMs for nodes that is, you know, it's vulnerable for SQL injection just because of prototype pollution. So it's true that sometimes, you know, maybe on a front end, maybe in a specific context, you would not be able to exploit a prototype pollution vulnerability or an excess test or, you know, whatever. Right. But there's a slight chance that you may not understand fully the impact and the attack surface. And then you might be vulnerable. Like that's one example that creates this skill injection because of that prototype pollution vulnerability. But you really don't want to take that chance, right? You want to you're leaving the house after you leave, you know, it's a bit of a coffee time right now. But assuming you leave the house and allowed to, you want to close all the doors, right? You want to close all the windows, want to make sure everything is tight and you're not leaving anything open. And if you're like me, you're probably double checking everything twice. And so that's kind of like the world we live in with security as well. You do not want to leave that, you know, that small chance that something can go wrong and you want to do everything in your power, right? It's no need to go into crazy madness, which is what I think Brian was trying to say before you need to prioritize things and, you know, reach reach to them with some rationale, right? But at the same time, you need to have a plan to, to make better, you know, we have a good baseline and improve upon that. So that's kind of like the, I think the effort and the return of investment of investing in your own security in a sense. 

DAN_SHAPPIR: As you mentioned it several times, prototype pollution is the, is essentially the inadvertent problems caused by the fact that the same prototypes are shared across the entire application, right? That if I put something on string dot prototype, every, it impacts every string in the system. So is it more about the fact that somebody is maliciously intentionally putting something on a prototype and changing built-in behavior, or is it something else? Can you elaborate a little bit? 

BRIAN_VERMEER: Yeah, sure. So I guess, I mean, you pretty much explained it in a very simple term, so that's kind of what it is. I mean, it's very specific also to JavaScript and the prototype structure, right? It's a very specific world here that we're talking about, and that's essentially what it means. You have an object. And if we're able to, I guess there's different terminology here, right? If we're able to poison an object in terms of, for example, create an attribute on the base object of JavaScript that says is admin or, you know, whatever else you can think of, then any object created from that object will have is admin as well. So you can imagine the teacher is like a code, code path where you would be checking, you know, relatively, this is like an example from a backend, for example, where you have this, if something is admin equals true, and if it doesn't exist on the prototype of. I mean, of the current object, it will go off the prototype channel and we'll find it on that root object, which we poisoned. And at that point we have kind of like circumvented our way into, you know, poisoning that app or all that prototype channel to an is Admin a value and maybe have gained unwanted access, right? Access that we couldn't have gained before. And that happens in different ways, right? That there are different ways to make that happen. One of them is maybe, maybe you're processing JSON that is rooted in user input. Maybe you're processing user input, not as a JSON, but you're transforming it into a merger, into a JSON. And your merge is maybe an unsecured merge, right? You may be doing deep merges inside that tree, which do not take into account the fact that someone is able to impact the prototype. And so that's kind of like how this evolves. It's one example, right? It's one example, but there are so many. 

DAN_SHAPPIR: You remind me of a funny tweet that I recently saw that somebody listed several ways to sum up an area of numbers in JavaScript. So one was a simple for loop. Another one was to use the dot reduce method. But the final example was to take that area of numbers, join it with a string plus, and then Evaluate. So I was really amused with that particular example. 

LIRAN_TAL: Yeah. 

DAN_SHAPPIR: Or EvaluateEvaluate and so on. 

LIRAN_TAL: For sure. Yeah. It's something, yeah. People get after a while, right? If you're aware of it, that's kind of the thing that they work with. Raising awareness, like you just said, right? You understand the impact of that. And the moment you understand it and you see it, you know, that's, I think that's like, that's the 50% win, right? The next thing is just breaking off what is the solution, what is the alternative? But the moment you see it, it clicks. 

DAN_SHAPPIR: Cool. Now, how challenging was it for you to implement this extension for Visual Studio? I know that there are a lot of cool extensions for that. I personally have not yet built an extension for VS Code. That's something I probably have to do sooner or later. It's becoming a rite of passage almost. So can you talk a little bit about that? 

AIMEE_KNIGHT: One thing I would add to that question too that I was going to ask earlier. So I'm assuming there are extensions for other languages too, but I'm curious specifically maybe since it's a JavaScript podcast, if there were any complications that I'm assuming there are specifically with JavaScript. 

LIRAN_TAL: Not so much complications. It was more the structure, how to make it work within Visual Studio Code. That was a challenge. Luckily, we got the idea from what was the original thing called? I think it was... 

BRIAN_VERMEER: I probably know it was it. Yeah, Import Cost. 

LIRAN_TAL: Import Cost by the folks from Wix. And we looked at how they built their UI because they do the inline messaging, like there is something wrong or you're in, you're importing a certain package and it shows you how much space that package costs you. So from that point of view, we're like, okay, this is, this is nifty. This is very, very, very simple and elegant. And in a way, how they presented it and their code was, was there. So we built this with their idea. We took their idea and we built our stuff on top of that. So the UI part, well, we got inspired by them, say it like that. And then we connected our own APIs towards that. And then we had to think of, okay, how we make this fast and snappy, how we do caching, how we are not sure that we have to make sure that it doesn't scan your whole application again, when you change, change just a tiny little bit. These were the challenges that we had to make to make it work because nobody likes it when you change something or you change just one line and it takes over 30 seconds to, uh, to re-render the stuff. So most of the challenges were in the usability kind of way. 

AIMEE_KNIGHT: What about security vulnerabilities like in the dependency tree? So are you guys scanning all the way down or just at like the top level? 

BRIAN_VERMEER: We're scanning all the way down. So that's why we need your whole dependency tree with the use of things like NPM or with the package lock file. We know what kind of dependencies are underneath because we found out that most problems are not in the top level dependencies, but in the dependencies underneath. So, and that's what we show you. It's not that package that you might, that you import it, but it, but it can be something that is three or four levels deep. 

AIMEE_KNIGHT: I should have added to, I'm still scrolling through. So this isn't just anything that I were to import, but it works with script tags as well. 

BRIAN_VERMEER: Yes. 

LIRAN_TAL: Yeah. That's the thing I like about it actually. It's, it's the side, it's my side favorite thing about it. It's actually not even targeting specifically, like, you know, full-blown NPM JavaScript developers using import and that's with them and so on. But if you're just editing a file, like, you know, plain old, I don't know, the days of the nineties where you have a script actor importing something. 

AIMEE_KNIGHT: A lot of people still do that. 

LIRAN_TAL: Yeah, that's what I'm, that's what I'm getting at. That's my favorite thing. You have not neglected that part. And we've actually very consciously actually have looked into parsing those, you know, plain HTML files and script tags and using that to find out what you're using and so on. 

AIMEE_KNIGHT: All those good old monolithic Ruby on Rails and Django apps. 

LIRAN_TAL: Exactly. 

DAN_SHAPPIR: Not just that, I'm actually a fan of script tags. You're done right, you know. 

AIMEE_KNIGHT: It's not so bad, you can still import with them. 

DAN_SHAPPIR: No, done right, the web is a beautiful thing, you know. Script tag will always have a place. Unless you're using ES modules where you can do the import from within the JavaScript itself, and everything ultimately translate to a script tag. Well, there's also web workers which aren't script tags. But anyway, many things translate. 

AJ_O’NEAL: We don't need script tags. Just put everything in the onClick one line. Safe, it's secure, loads really fast. 

DAN_SHAPPIR: Yeah, go to the next step. 

AJ_O’NEAL: Easy to use. 

DAN_SHAPPIR: Yeah, onClick equals string. That's having code as strings. That's always secure. 

AJ_O’NEAL: Yeah, what could possibly go wrong? Nothing. It's perfect. 

LIRAN_TAL: Nobody will notice, right?

AJ_O’NEAL: When you're, when you're programming that way, you've got so little JavaScript in your code that your code's inherently, hopefully not even code. 

DAN_SHAPPIR: Yeah. Actually people will notice because your code will, your website will work surprisingly fast. 

AJ_O’NEAL: Let's, let's not troll too hard. People might believe that. 

DAN_SHAPPIR: It's actually true. Cool. So anything else you do, you want to tell us about either this extension or other, other extensions that you're or two or free tools that you're, that you're introducing.

BRIAN_VERMEER: Well, after creating this extension, we were thinking about, okay, that integration with an IDE is very common and it's very useful for developers, but how do you get into the process of picking a certain library? And you probably search around on different websites. It can be either a CDN and you use that script tag, or it can be, for instance, another website that you can look for a specific library that fixes or helps you with the problem you want to solve. So we reached out to a couple of those owners. And for instance, with JS Deliver and with CDNJS, we integrated our API with them. So if you are looking for a certain package, same with yarn, by the way, yarn package, if you're looking, if you're searching for a certain, for a package, and you're like, OK, I like that package, and you click on the details. You will see a bunch of these badges and the badges normally are like, okay, what kind of license is it? How much is it downloaded? But also gives you an indication of a specific version. How much, how many vulnerabilities are there? And just in a one-liner and right on top of mind, like, okay, this version might have two vulnerabilities. Do you want to use it or do you want to go to a newer or maybe even older version? Depends on what it is. Most of the time it's newer by the way. And if you want to know more, you can click on it and you go to our website that gives you more in-depth information on what kind of vulnerabilities are there. So we think like by giving this information early and often to the community, we tried basically to make it easy for developers to pick the right package. Initially. So that's one of the things we recently did next to the phone calls plugin and the integration with his website vulnerable with a web page test. Sorry. 

DAN_SHAPPIR: Again, without naming names. How vulnerable was the most vulnerable package that you've yet to encounter? 

LIRAN_TAL: That's a good question. I don't think I've ever put them on a scale like that. 

BRIAN_VERMEER: No, it's, and it's, then it's- 

AIMEE_KNIGHT: I can think of some from my MPM days for sure. 

BRIAN_VERMEER: I can think of some, but it's how you also count the vulnerabilities because do you count a vulnerability as one or do you count every vulnerable path that it can take as a vulnerability? So-That's the way like, okay, how do you actually come to the numbers? 

DAN_SHAPPIR: But I like that, uh, like that scene from the load of the ring movie or the elf Legolas takes down that elephant with all the fighters on it and then, and then give me the dwarf says, yeah, that only counts as one. So, so yeah, I guess it really depends on how you count it. 

BRIAN_VERMEER: It really, it really depends because it's basically the same vulnerability, but yeah, you can, you can trigger it in, in, in say a ton of different ways. So be accounted as one vulnerability or do you count it as a ton of vulnerabilities? But I've seen say in, in within the three digits. So over a hundred vulnerabilities I've, I've seen to a package, but that was a very, very old one and I'm not naming anybody in this case. 

DAN_SHAPPIR: But in most cases though, is it about the number or the severity? Because I would imagine that a single severe vulnerability could be, can be much worse than 20, you know, small vulnerability. 

BRIAN_VERMEER: That's totally depends on the context of your application. Just, just to give you an example, something like a path traversal kind of vulnerability might look like, okay, you can traverse backwards in a path and I can read a bunch of files that might not be, you cannot do anything, you can just read, but that is however, the start of how people get, get into your application. So they might be reading. For instance, a token that you left out there in a certain file that you normally only can read if you have access to that file system. If you combine two or three individually low severe vulnerabilities, but you combine these two or these three, they can still lead up to a massive destruction of your application or at least things you did not intend to expose to the outside world. So it totally depends on the context. However, I do agree that things like arbitrary code execution or these kinds of vulnerabilities are by default are more severe. So I would say if you're going to solve things, start with the high severe ones and go away to the lower ones, but don't underestimate the lower or medium vulnerabilities that are out there because combined they can do a lot of things. And most of the times it's not just. Unfortunately, it's not just one issue you have when you found out you got breached, it's probably a domino effect from three or four or more vulnerabilities that people combined to get into your system or read certain data or whatever it is they, they, they want to do with your stuff. 

 

Hey folks, this is Charles Maxwood and I just launched my book, the Max Coders guide to finding your dream developer job. It's up on Amazon. We self-published it. I would love your support. If you wanna go check it out, you can find it there. The Max Cotter's guide to finding your dream developer job. Have a good one, Max out. 

 

DAN_SHAPPIR: Yeah, so I actually have two questions about that. So we were discussing the fact that sometimes smaller vulnerabilities in the libraries that you're using can accumulate and that several small vulnerabilities can actually add up into a significant vulnerability. So I actually have two questions related to that. Question number one is that if I look at it from that perspective, it can be an accumulation of vulnerabilities from several libraries. That means I might be using, maybe the problem is because I'm using two specific libraries in conjunction. Is that something that you're also looking at or considering looking at? 

LIRAN_TAL: I don't think if there was an example that I remember out of my head, just because of combining two vulnerabilities, but there are definitely situations. And I think that's kind of like probably apparent in the, in like, you know, the, uh, the vulnerability, the security scene where you would be like a chain of, of things going kind of like wrong together, if so to say, would need to impact the vulnerabilities. So for example, we have, uh, probably give two examples that off the top of my hand, because these are exploits we have on the, uh, on the, um, on the public goof up, which I've mentioned before. And so. For example, let's say there's an XSS vulnerability in a package called marked, doing markdown, and this is a real thing, right? And by default in that version of marked, it actually sanitized those vulnerabilities, sorry, those specific strings, like a JavaScript colon something, and then you can't really do an XSS in an href context. And so if you try to replace that colon with something like the HTML entity representation of what a colon is, it actually does some regexpersing to find those as well. So that by itself, like trying both of those things didn't really work. And, 

DAN_SHAPPIR: oh, I love the sanitation, sanitation using regex. It's what can go wrong? 

LIRAN_TAL: Exactly. 

AJ_O’NEAL: Nothing, but because regular expressions are precise and regular. 

DAN_SHAPPIR: Yeah. And they're so easy to debug and understand. 

AJ_O’NEAL: Yeah. Unless you write them like Dan does. God.

LIRAN_TAL: Just don't try them at all. 

DAN_SHAPPIR: But it's a... We had this, an interesting Twitter exchange about me taking a simple, like three simple regular expressions and turning them into, or actually three simple replace instructions and using turning them into one not so simple replace instruction, because I like to write code like a compiler. But anyway, go on. So yes, using regular expressions to sanitize your code.

LIRAN_TAL: Right. So, I mean, it's interesting to note at this point that this maintainer was actually very security conscious. I mean, think about the mindset, someone, you know, understanding that, that the payload like JavaScript colon, you know, then alert or something could be, you know, malicious, then thinking about the fact that someone can represent it in a different way and then sanitizing HTML entities. I mean, that's, you gotta give, you know, some credit here, right? I mean, this is, this is a, you know, very security mindset in a way. And we'd love to see more of that. The thing is that rejects specifically like that with a structured way of that HTML entity. So if you would break the HTML entity down a bit to where it's like, uh, where it has, uh, you know, it's, it's supposed to end with like a semi-colon. But if you'd add a valid JavaScript statements or a, like, you know, like the word these for the word document, uh, before that semi-colon and, you know, right onto the, the end of, of the HTML entity, what would happen is it would actually bypass. That's not, you know, according to the reject. So that's, that's, that's supposedly fine. But then the browser thinks about it in a different way. And then when the browser process that the, the browser actually inserts that semi-colon creates an HTML entity. And the rest of that, um, of that statement is all valid JavaScript. And that's how you get an XSS. And that's for example, like one way where you might be thinking and trying different ways to exploit a vulnerability, like, you know, snake will tell you there's an XSS here and you're like driving or, you know, driving nuts about how to make it happen, you know, Q8 or, you know, try to see what's going under, might not, you know, think about this specific attack vector as a security researcher did and then, you know, file the security report about it. So things aren't, you know, as simple as they seem all the time. Some things, you know, require different chain of things to happen. You know, that's one example. I have more of those, but I don't know about like, you know, different libraries. I think that's, these are more complex situations, but definitely things are oftentimes, you know a bit more than they are complicated than they appear to be 

DAN_SHAPPIR: So that was one question that I had and the other is currently your researching vulnerabilities or or getting reports about vulnerabilities in third-party libraries and then based on that you're recommending You said either usually upgrades sometimes a downgrade. What about inspecting or using certain heuristics to verify my own code for because anything a third-party library can do, I can also do myself accidentally. 

LIRAN_TAL: And we're not doing that yet, but Brian, do you know that reachable vulns feature we have for Java? I think that's something worth and really interesting to share about because yes, Nick does like this tooling, which is more of like a developer first kind of tooling that we're trying to build, but then it does this other aspect which you mentioned, which is, you know, we do our own security research and have a weight report involved so we can work with the maintainers to fix them. But recently we've done something very much related to what you're saying. It's currently only out for Java. And that's more around the fact where sometimes you have, it's not exactly your code, but it's as close to it as you can get at this point. And that is, let's say you're using third party dependency. But the thing is the vulnerable function that is part of that dependency that has the vulnerability inside it, maybe you're not using it, right? And it's a very classic case, for example, from the JavaScript side, from things like Lodash where you'd import the entire of Lodash, but maybe that there's only that merge function, which you don't use, it's vulnerable. But the Tool Links tool tells you, upgrade Lodash because merge is vulnerable, but you're not using it, right? That's kind of like the frustration part. And so we have that right now for Java where you could pass some flags out to the CLI or you know, where you have some like integrations with the ID and so on, where we can leverage this information and then we can tell you it's actually only vulnerable if it's from a reachable code. So only if you're actually using a code path that triggers that specific vulnerable function because Nick also knows to say what is the actual function that is vulnerable within that third party library. It's not just no third party library version is vulnerable, but what is the actual function that is vulnerable? And then we can connect all of that flow together and tell you what you should be doing. So I think that's, that's the key part that, you know, we want to see more happening across other ecosystem languages too. 

BRIAN_VERMEER: Yeah, definitely. Um, for, for Java, for the, for the Java ecosystem, we now look into that to, to actually see if it's part of the call graph. Uh, so if it's actually reachable, that is, that is not of course, a hundred percent certainty, but then you, then we can give you uh, together with if there are known exploits for it together with, uh, what is the, uh, how high is, uh, is the CVSS score. All these things combined, we can give you a score to see, um, which one should you fix first, because what we, what we see for enterprise, uh, developers or developers with a lot of code, they have a bunch of vulnerabilities. They have a ton of vulnerabilities that they, that they need to need to, um, fix.Okay, where to start? So that is, that is the thing that we do. So we see if it's reachable or not. That's one of the major pilots over there. And then, um, of course, if it's, if it's out there for, for, for a very long time or a very new one, um, that influenced the score and it will, that will change over time, of course, all these, all these kinds of things, just like, uh, it can be, um, that something comes out and it turns out to be a false positive, uh, luckily we have our own security team that monitors these kind of things. So in a very rare situation, it can be that severity will change from high to medium or something like that. Or even if it's a real false positive, it will not be flagged anymore. So that is the benefit in my opinion from having our own security researchers inside our company. 

DAN_SHAPPIR: Cool. I think at this point, I will push us towards Picks. It's been quite a very interesting discussion for me and there's certainly been a lot of information here. 

 

One of the biggest pain points that I find as I talk to people about software is deployment. It's really interesting to have the conversations with people where it's, I don't want to deal with Docker, I don't want to deal with Kubernetes, I don't want to deal with setting up servers, all of these different things. And in a lot of ways, DevOps has gotten a lot easier. And in a lot of ways, DevOps has also kind of embraced a certain amount of culture around applications, the way we build them, the way we deploy them. And I've really felt for a long time that developers need to have the conversations with DevOps or adopt some form of DevOps so that they can take control of what they're doing and really understand when things go to production, what's going on so that they can help debug the issues and fix the issues and find the issues when they go wrong and help streamline things and make things better and slicker and easier so that they'll more generally go right. So we started a podcast called Adventures in DevOps and I pulled in one of the hosts from one of my favorite DevOps shows, Nell Chamarral Harrington from the Food Fight show. And we got things rolling there. And so this is more or less a continuation of the Food Fight show where we're talking about the things that go into DevOps. So if you're struggling with any of these operational type things, then definitely check out Adventures in DevOps. And you can find it at adventuresindevopspodcast.com. 

DAN_SHAPPIR: I don't know if you guys are familiar with this pick concept. Hopefully you are. If not, we will do our picks and then you'll probably get the gist of what it is. So because Amy had to drop off, AJ, why don't you go first? You usually have awesome picks. 

AJ_O’NEAL: Yeah. All right. So last week I talked about Zalgo and then there were crickets because I somehow...We're with a crowd that doesn't know what Zalgo is. These guys know what Zalgo is, right? You guys know Zalgo, no? Oh, man. What's going on? What, you like started being a developer yesterday? Come on. Zalgo is the demon god that comes when you parse HTML with regex. This is kind of like, it's- 

BRIAN_VERMEER: Why would you ever do that? That's why we don't know about it. We don't do these kind of like awful things.

AJ_O’NEAL: Oh, well, I mean, I just, it's one of the most famous Stack Overflow posts. It's like that Amazon review of the three wolf T-shirt, three wolf moon T-shirt. You know, it's just one of those things that, yeah. 

BRIAN_VERMEER: Only you know about these things. 

AJ_O’NEAL: And you know, and on that note, I'm going to pick the three wolf moon Amazon review. It's a parody review. And, and like this, this thing about Zago obviously is a, well, hopefully obviously is that is a, um, parody answer, but actually I don't know. Somebody will have to Google it. I don't know what the link is, but anyway, there's, there's, there's, there's a bunch of, if you Google for, um, like parody reviews on Amazon, there's stuff people talking about, like getting delivered like month old milk and, uh, gender specific, um, BIC pins and like just really weird random stuff. Okay, so another one that I've got to pick is the fish shell. If you are not using fish, you deserve better. Now, I am not going to suggest that you take any effort in learning how to script with fish because I think that's a waste of time. Now someone's gonna shoot me from the fish community. But fish is the best shell. It is the friendly interactive shell and it does things like as you type it highlights what you're typing. It doesn't wait for you to hit tab or hit return to start doing auto suggestions and error feedback. Like while you're typing if the command's not found it's going to be highlighted in red and then as soon as the command's found it turns into blue and it's just got um it's like if you've heard of oh my zsh it's like oh my zsh on steroids and by the way if you cannot just cannot use a shell that isn't bash compatible because you do too much bash foo, then there's no way that you haven't heard of ZSH and OMI ZSH, but if on the rare chance you are a bash foo guru who does not know of ZSH, then you can also use ZSH. But I recommend Phish. I always use bash for scripting. I never try to do anything fancy in Phish, but just as a way to just type out commands and files and folders and I just love, love, love having all the auto completions and highlighting and colors, et cetera, et cetera. So I've got an installer and cheat sheet up for that on webinstall.dev slash fish. And that'll show you how to integrate it with iTerm2 or terminal.app. I tend to try to stay away from things that require sudo. So you can also set it to your default shell with sudo and chsh, but I try to avoid that. And then along those lines, I will, well, I'll pick this again later, but there's a couple themes that I've discovered that I really love for I Term 2 and VS Code, and these themes are pretty much universal, but there's a theme called Tomorrow Night that's part of the Base 16 package of themes, and then there's another one called Toy Chest and another one called Dracula, so I'm going to pick Toy Chest. Well, tomorrow night, first of all, then Dracula, then toy chest. And I've, I've discovered this new thing with I term two, where I can, um, use in the, in the advanced tab, I can set it. So as soon as I SSH into something, all of my SSH users are app, which I think that's a pretty common convention. Um, so not giving away any information there and I don't use passwords. I only use keys, but, uh, so whenever I SSH into something that has the username app. The profile switches. So if I'm on a remote computer, I don't get confused between which terminal is which So I'll have like my remote will be in the toy chest theme and my local will be in Dracula and then I'll have a really ugly theme for the default theme So if it's my username then shows up in one theme if it's the app username It shows up in another theme and then if it's the root username, then it shows up in another theme that way I never get confused and this requires I term to and the terminal integrations under the like I term preferences tab or whatever, but it's super awesome. Absolutely love it. So yeah, I I've got that to pick and then okay, I'm going to pick I'm going to pick a really really unpopular figure for very good reason. I'm going to pick Jeff Bezos because he is the flipping modern Robin Hood. He's figured out how to get rich people from all the globe to invest in a company that drives up an inflated imaginary valuation so that he's quote unquote worth $200 billion when in fact he's actually just stolen all the rich people's money, lowered the cost of goods and services, and then provided to everybody for free or near free. Amazing. Those are my picks. Oh yeah, I think I think Jeff Bezos is getting such a bad rap right now, but like people don't understand how company valuation works. He doesn't have 200 billion dollars. He spent some amount of billions of dollars that after you do these adjustments for stock price, inflations, etc. It's imaginary money. You just making it up. It doesn't exist in the real world. It's not something you can pull out of a bank account or. 

DAN_SHAPPIR: Yeah, but our money is imaginary. You can't really pull all the money out of the bank accounts anyway.

AJ_O’NEAL: Well, what I mean is like, imagine that like there was no gold and then you dug and you found gold and suddenly you're rich. Like the gold didn't exist before, but then you found it. So it's not like 

DAN_SHAPPIR: you called cryptocurrency. 

AJ_O’NEAL: You didn't know that's that's you didn't you didn't take money. You didn't take money from poor people to get rich. You created a new asset where no asset previously existed.

DAN_SHAPPIR: Well again, we're living in an economy where the governments or actually the central banks keep pouring money into the economy so literally the concept of uh of pouring money out of thin air. It's not even that you don't even print the bills anymore. It's just numbers in a computer It's becoming literally meaningless. It's like I said, it's a shared psychosis, but I understand I understand what you're coming from. I'm just amused because I think the federal reserve is pouring the equivalent of one Jeff Bezos into the US economy literally every month. So that kind of puts things in perspective. 

AJ_O’NEAL: Well, now they're doing much more than that because he only actually gets salaried at, I think it's $10 million per year. And they're doing they're putting a lot more than that into. And yeah, but again, that's that's dilution and but we do need inflation. Inflation is important for a stable economy. 

DAN_SHAPPIR: So I'm going to go now with my picks. So pick number one is you mentioned the themes. So I'm always amused when somebody posts a bit of code on Twitter. And usually the way to do it these days is to post a screenshot and he goes like, or he or she goes and says, Hey, look at this really awesome code that I created, or I created this algorithm with which solves a problem, which was considered to be unsolvable before. And I did it small enough so that it can fit in a tweet. And everybody says, yeah, but what's your theme? So I'm always amused about that. And in this context, my pick is going to be that if you do actually post code on Twitter as an image, it's a really cool way of sharing code, especially if your code doesn't quite fit in the tweet itself. But the thing that we neglect to think about is the fact that visually impaired people can't actually see your code, because it's text in a picture and the screen readers can't handle that. And what you can actually do in Twitter these days is add alt text, like you can do with images on the web. You can actually do that in Twitter. So my first pick is going to be that if you, at any time, post a code on Twitter as an image, make sure to include all that code as an alt text for that image. People who are not visually impaired will just see that image that you posted along with your really nifty theme, but visually impaired people will actually get their screen readers to read out the code for them. So that's going to be my first pick. My second pick is going to be the series of books, fantasy books that I've been reading. They're not the best uh fantasy uh series that I've ever read but they're very enjoyable I'm having fun time reading them it's the demon cycle series I'm about to finish book number two uh and I'm definitely going to be reading book number three so uh that would be my second pick uh and I'll post the link to Goodreads about that series of books uh and that concludes my pick for today. So, Brian, let's go with you first. Do you have picks for us, or should I switch over to Liran before you? 

BRIAN_VERMEER: I'll try later on first, because I'm trying to make up what should I pick in what category. I'm trying to make me- 

DAN_SHAPPIR: It could be anything, literally. It doesn't need to have anything to do with technology whatsoever. It could be your hobby or whatever. Or just the random thing that happened today. 

BRIAN_VERMEER: He's a Java person, so it takes time to put up. Yeah, I've got multiple threats to spun up to do this for me. That's not getting it. 

DAN_SHAPPIR: Yeah, you've got the pic, but you're still creating all the boilerplate for it. 

BRIAN_VERMEER: Definitely, definitely. But it makes it readable. I like you, Dan. Okay, I will take a pic that's something like a bit of in the same fashion as you called out, Dan. But although now I have to rethink of that because of that alt tag that you mentioned. But I just stumbled upon carbon.now.sh, where you can literally grab a piece of code and push it in, and then it will create an image that looks like your terminal in a certain way. And you can mix and match themes in these kind of ways. So you have an actual nice picture kind of way to post it in a blog post or in a Twitter message that looks far better and far easier to read in my opinion than people just having a screen grab from their own screen. Because they, well, at least they have a nice background on it and you can pick and choose whatever you want. But I think it's a very nice way to present your code as an image in, for instance, a blog post. Although, I would say that if you blog somewhere and it's possible just to put it out as code and use Markdown for instance, that that should be your first pick. The other pick, I think I will pick a TV series and probably everybody knew about this one, but I haven't, I have stumbled upon this like literally last week and binged it, that was the Umbrella Academy, which is so addictive in my opinion. It is weird, it is strange, it is kind of superhero, but not really. And after this meeting, I will probably put one of these episodes up, just to clear my mind of all the JavaScript things that Leran throws at me. No, I'm kidding. 

DAN_SHAPPIR: Did you watch both seasons? 

BRIAN_VERMEER: I'm currently, I've been for season one, I'm currently somewhere within season two. 

AJ_O’NEAL: And that one is mostly like The Voice, right?

DAN_SHAPPIR: sort of boys is more... 

BRIAN_VERMEER: The boys have seen it as well. I have to start the second season, but that's more of the anti way of looking at superheroes. Because I must say that's also very, very amusing to see that super heroes are not your average good guy, but can do things to just they're misusing their powers to just make money and that kind of stuff. So it's just the whole enterprise around superheroes, which is amusing. But I fell for that umbrella company thing on Netflix. 

DAN_SHAPPIR: Yeah, they're supposed to have one more season of it. I'm not sure when it's supposed to come out. And that's supposed to be the last one. So it's going to be only three seasons. That's it. But again, I'm not exactly sure when that third season will actually land, especially with all the things that are going on. Yeah, but I agree with you. It's a really good, it's a really enjoyable show. I actually picked it myself a couple of episodes ago. 

BRIAN_VERMEER: Okay, well, I will conclude my picks with these two if that's okay. 

LIRAN_TAL: Right, I guess I'll stay on the tech side. To complete the FISH and ZSH kind of recommendation, I'll recommend you take a look at Starship Prompt. It's an open source project. Really pretty fine, your prompt on the shell, built by Matan Kushner. It's a really, really beautiful thing. So try it out. I feel like I need to give a shout out to you, Yarn2, Myle has put a lot of work into basically rewriting this thing from scratch. And if there's something we could always use is more opinions, more perspectives, and more ways of looking at things differently. So I think Yarn2 is definitely challenging the way that package managers work. That's gonna be a nice one. Check it out. I want to shout out for Vue.ify, which is a Vue.js thing. It might seem obvious, the obvious speak for some of you folks, but I'm bad at front-end and UI component libraries are helping me build things. So definitely a shout-out for that one. And maybe the last pick on packages and projects is take a look at the packed framework if you're into testing in a big way. And one of the challenges is how do you do API testing, integration testing in scale, so like imagine, you know, having thousands of microservices or don't even need to go to thousands, right? Tens or hundreds is just kind of like crazy enough. How do you test them in a way where you don't need to bring up a whole end to end system to do it and then the front end and the backend API's integration and so on. Fact is the way to solve that and it's based on this concept and pattern that has been here for a while called consumer driven contracts. So this has really tried in community. I really suggest taking a look at it. And I'll conclude my picks with a person that will be, I won't say to contradict the Jeff Bezos side of things, but I'll throw you back something like Charlie is back. And I'll pick Andrew Milner, which most chances, no one is listening has an idea who is this person is, but they have, they were, I think they were the sole creator of a bulletin board system that used to run on DOS called Remote Access. And that has basically shaped up my entire childhood back in 1995 or six or something around those days. So yeah, that's gonna be my pick. 

DAN_SHAPPIR: Cool, well, that concludes another JavaScript Java show. Thank you all for participating. It was awesome, really, really interesting. If anybody wants to reach out to you guys to learn about vulnerabilities in general, the tools that you're creating, how do they best reach out to you? 

BRIAN_VERMEER: I think the easy way is to reach us on Twitter. I mean, both of our DMs are open and that's how we connect with basically the rest of the world. Of course, you can use the old-fashioned email kind of way, which is still valid. But I think Twitter is the easiest one. And I think if you look for... 

DAN_SHAPPIR: What's your Twitter handle? 

BRIAN_VERMEER: It's BrianVerm. So Brian V-E-R-M at the end. That's my Twitter handle. And Liran is just your name, right? 

LIRAN_TAL: Almost, it's Liran underscore dal. 

DAN_SHAPPIR: Cool. So thank you both for coming on our show. Like I said, it was awesome, really interesting. 

LIRAN_TAL: Thank you for having us. 

DAN_SHAPPIR: You're welcome. See you all next time. Bye. 

BRIAN_VERMEER: See you, bye everyone. 

LIRAN_TAL: Bye bye, thank you.

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit C-A-C-H-E-F-L-Y dot com to learn more.

 

Album Art
JSJ 456: Developer-First Security and Security Tooling For Developers with Liran Tal & Brian Vermeer
0:00
1:06:34
Playback Speed: