Dependencies Are Dangerous  ## Metadata - Author: [[Changelog Master Feed]] - Full Title: Dependencies Are Dangerous - Category: #podcasts - URL: https://share.snipd.com/episode/6b177957-a4e4-425e-9a23-6d53cd92c3de ## Document Notes ## Highlights - **CDNs: High Risk, High Impact** - CDN supply chain attacks impact hundreds of thousands of websites by compromising widely used scripts. - The vast usage and caching of CDNs make them lucrative and dangerous targets for attackers. Transcript: Speaker 3 Go Time! Your source for wide ranging discussions from all around the Go community. Find us on the web at gotime .fm, on the Fetaverse at Gotime, at changelog. And on X at go time FM. Thanks to our partners at fly to IO the home of change log .com launch your app as close to your users as possible. Find out how at fly .io. Okay, here we go. Speaker 1 Welcome to go time. It's yet another week yet another episode and I am your wonderful host, Chris. And today we are talking about supply chain security and dependencies. And joining me for this episode, we have Ian and Johnny. How are you doing today, Ian? I'm doing great. Awesome. Can't complain. Nice. How are you doing today, Johnny? Speaker 2 I'm checking to see if anything we use has anything to do with polyfill or, yeah, just get a quick check. That's how I'm doing stuff. Speaker 1 Just a little check, like a little grip of the code base. So yeah, yeah. Today what we're talking is a few things, but first up we're going to talk about this vulnerability, I guess, or this compromise one could say of polyfill .io. Ian, do you want to give the listeners a quick summary of what happened? Speaker 3 So polyfill .io is a CDN that serves a JavaScript library for browser polyfills. And a couple months back, the maintainer of the JavaScript library warned not to use the polyfill .io CDN, which he does not own and isn't associated with, because it was sold to a different Company. And yeah, just now, they started injecting malicious JavaScript and it affects hundreds of thousands of websites like Hulu and JSTOR, however you say that, all kinds of sites. They got caught redirecting to gambling sites and all kinds like that. So yeah, it's a pretty big deal. Speaker 2 So as you were saying that I'm thinking, okay, CDNs, CDNs, especially in the front -end community, pretty much CDNs are like, they reign supreme, right? Like usually, any libraries, JavaScript libraries that you're using to build your apps or even shipping stuff like there's usually a CDN URL because that's the best practice. The CDNs are distributed all over the world and your users are going to be close to hopefully one of those endpoints and that means your website, your app loads up that much faster. That's the value of CDNs. But I don't think anybody ever stops to, or rather, not that they don't, but I don't think people have like tend to pay close attention to CDNs because they're kind of like, they're always There. They're going to always work. You know, it's, you know, you see a link to a, you know, I'm going to date myself here, like a bootstrap CDN thing and you just copy and paste it and you're good to go. Now you've got bootstrap, right? Or whatever library of choice you're using. It's almost as if you just assume that, oh yeah, somebody's footing that bill. I don't have to worry about, you know, I don't have to worry about it. I just, you know, include it in my, in my JavaScript or in my app. And off I go. So it's kind of interesting that now you have, through a change in ownership of a domain name, you've got this thing popping up. How interesting. And again, within the NPM, is this not, well, that's not an NPM only thing, right? It's anybody that uses that polyfill, but I assume that it's libraries that are served up, it's JavaScript libraries that are primarily affected by this, right? Yeah. So not even JavaScript libraries. Speaker 3 I mean, it's at least for this, this specific attack, it's just anyone that includes this, right? Speaker 2 Anyone? Yeah. Yeah. Anybody. Speaker 3 I mean, it's like if jQuery or Google Analytics was compromised, attacked, compromised, how many sites would that affect? Speaker 1 Yeah, I think it's interesting that like, one of the biggest advantages of any of these CDN, especially like the front end CDN providers, like, is that you have, you know, if everybody's Using the same one, then there's a good chance that whatever library you're using, whatever code you're trying to pull in is already cached. So there's not even a request that happens to the CDN, so it's super fast. But that also makes them huge targets for attack because it's included on so many websites. So if you just make a small change there, if you get in there, you can compromise a gigantic number of websites. But also kind of feels like CDNs are at least a little bit a relic of the past in some ways. I mean, they obviously not CDNs total, but CDNs for this specific purpose. In the same kind of way that like I've always kind of come to see that putting having different subdomains for your assets is kind ([Time 0:00:12](https://share.snipd.com/snip/629e065a-daf5-4886-82f5-f84db7df9757)) - **Go's Supply Chain Defense** - Go mitigates supply chain attacks with build locks, cryptographic checksums, and source commit hashes. - The Go community prefers fewer dependencies and often copies code instead of importing libraries blindly. Transcript: Speaker 3 That you have or like using Google. Speaker 1 So if you're if a Go developer, how does this affect you? Or does it? Speaker 3 It doesn't. But not directly. Not directly. But the idea of like the supply chain attacks, I mean, does affect you as a Go developer. I think Go has done a lot to make it so we don't have to think about that as much. But it is still something that should be thought about. We've seen other pretty crafty supply chain attacks, like even this year. If you've seen the, what's the library card called? The compression library. Oh, XZ. Yeah. If you've seen the XZ attack, that one was actually, someone basically bullied a maintainer and said they weren't updating stuff fast enough and got themselves in as a maintainer. And then like slowly over years committed different pieces of code that eventually got to this exploit, right? That is sophisticated. It is sophisticated. Speaker 2 I mean, who's to say the bully or didn't get bullied into giving their, you know, get home or whatever it is, right? So you might not even have been the original. Speaker 3 I mean, based on the length of the tech. Yeah, but 100%. Right, yeah. It might have been. Yeah. Yeah, we don't know. But I mean, do you guys think about the, I don't know, the supply chain when you're deploying things and building things? Speaker 2 So thankfully, I'm not loading things up at runtime. Even if I was serving up an app, you can serve up a web app right through through go right you can just set up an HTTP server server for static site whatever it is right. So in a way if you were serving up a website through go in part of the HTML or JavaScript that you're loading and serving up to the client includes a library that you're loading at runtime That points to polyfelicity and you could be affected, right? That's a direct way you could be impacted. So your go code is not being affected, but the front end that you're serving that includes this library from that CDN could be affected, right? For Go itself, I rely on the guarantees or rather the steps that the Go team have taken to ensure that the things that I'm shipping as part of my binary are indeed what I think I'm shipping. And I think you linked out the list of things that we do, we mitigate supply chain attacks. So this was a post from Filippo Valsorda back in 2022, based in Will Link that in the show notes, right? So basically, from the locking of the builds, right, the versioning of the builds, to the contents of the bill, the dependencies themselves, right, never changing, because we're Using that that checksum database, to using your repository, right, to commit hashes, as a source of truth, and building code, and sort of just building doesn't execute code, right, There are certain attacks that can come from that, right. And also, generally speaking, within the Go community, I think we go to great lengths to sort of not, not include sort of random packages right into our programs, left and right, or at Least quite a few of us do. I certainly, I'm certainly very critical of anything I import into my library. ([Time 0:06:00](https://share.snipd.com/snip/b00264ff-0990-4d60-846c-78b11b5432b5)) - **Vet Dependencies Thoroughly** - Be critical of imports; review dependency metadata, popularity, and code before adding. - Avoid blindly including dependencies, especially those with many transitive imports or unusual behaviors. Transcript: Speaker 2 Problems and issues do come from dependencies. Every time you bring in a dependency from some third party, whether you're familiar with them or whether you're not, which is most likely you're not, because you might be bringing in A dependency that itself has dependencies. Perhaps you're familiar with the author of the dependency you're bringing in, but you're not familiar with the author or authors of the dependency that that dependency depends on. So like at any given turn, you're bringing in a whole bunch of stuff into your world. So what's to stop somebody, you know, now or in the future from actually, you know malicious code. I mean, think of it this way. If I were to have a popular Go package and I decide one day or maybe somebody one day gets hold of my GitHub creds or something, and then they decide to update my package to now have maybe Use the OS package to slurp up all of the environment variables of the application that you built that you imported my package into. I slurp up all of the OS inf. I take a slurp them all up and then I send them, or rather the malicious actor, sends them post the multi -environment variables to some server somewhere. I mean, that's how trivial it is, right? Literally somebody could just swap up all your environment variables, which chances are if you're following the 12 -factor sort of application approach, right, popularized by the Heroku days, where you are configuring your application through environment variables and you are storing secrets in there and whatnot. Who's just saw somebody from slurping all your environment variables and posting them to some random server because you imported a library that does something you think it does, but It does more than that. So things of that nature, which is why I'm very critical of any package I bring into my world, and the packages that those packages bring. Usually, if I'm seeing a lot of dependencies on a particular package, especially if the package is not used very often, or rather, if I can go on pkg .go .dev and I look up a particular package, I have enough metadata on the screen to help me judge. Can look at pkg .go .dev. I can look at the top portion. It tells me how many things are importing this package, how many packages that this thing import. So these things are factoring into my decision whether to import this package or not. Especially if it's a new package, not a lot of activity on it, not a lot of people are importing it, but it's importing a whole lot of things. It's suspiciously doing more than it ought to, or it's on its own surface. To me, these are, I'm immediately saying, okay, I need to go to this repository. I need to start looking at the code. I need to start seeing what it does before I bring this thing in. And whatever it does has to be sufficiently sophisticated that I can't quickly come up with it myself. So that whole notion of dependency is being able to harm me. That's a very real thing. Because despite all the checks and balances that we have in the Go community for preventing malicious code from getting in, if you willingly bring in malicious code in the first place, That's on you. Because you could have gone and read the code. You could have gone and checked at least to make sure that this is actively maintained, it's a popular pack, whatever your criteria for selection is, it's on you to put in some effort To do that. Now, we're not all sort of, we're not perfect, and some things could fall through the cracks, but it should be a habit for you to be reading, right, repositories and source code. Obviously, some libraries are large, right? You can't do that, but you can rely on, you know, sort of some anecdotes. You can rely on basically how many people are using this thing. How long has it been around? Right? Is it being maintained? Right? You can rely on those signals to help you with your dependencies. So to me, dependency, just picking them up left and right and putting them in your Go program. That's a big no -no for me. ([Time 0:13:09](https://share.snipd.com/snip/edcce3f0-6203-4e75-9045-52130c578cc9)) - **OpenTelemetry Dependency Churn** - Early adoption of OpenTelemetry at Heroku involved frequent breaking changes in dependencies. - Constant updates were necessary despite pains, as OpenTelemetry was evolving rapidly. Transcript: Speaker 2 I have some scars issues for this one, but back when OpenTelemetry was on the Go SDK, right, for OpenTelemetry was still so maturing. Basically, this was during my time at Heroku and the observability team. We were very early on and embracing open telemetry at Heroku. So we got a lot of cuts, if you will, from the dependencies changing constantly. All of a sudden, a certain package path is no longer around and now we have to go find where that particular type is now located or a particular behavior is now tucked into a different location. I mean, it was, I mean, and we knew all this going in. We accepted, you know, that there would be churn and we took that on and, you know, tried to do our best to sort of, you know, either contribute something back or, you know, understand Why things were changing to some degree and sort of insulate ourselves to some degree. But this was one of those things that, the timing of it, we knew that we were going to commit to open telemetry in the long term, for the long term. We didn't want to create yet some opaque to us only or mechanism only to us because we needed to have better observability, but we didn't want to commit to some sort of internal thing that Nobody knows about, that as team makeup changes, people come in and out, whatever it is, they have to now educate themselves on some obscure thing. We're like, hey, open telemetry, that's the standard, that's the direction the world is moving to. Let's embrace it. So we sort of, with our eyes open, we deliberately went in that direction. But there was a lot of cuts, a lot of paper cuts as we adopted and things kept changing. So yeah, this was one of the libraries that, yeah, I would go in and update as things change and then find all the places where a reference no longer is valid and things like that. So yeah, everything else we tried to keep sort of two point versions only, just patches but the open telemetry stuff, we kind of didn't have a choice. ([Time 0:25:30](https://share.snipd.com/snip/2de7730c-5da4-4a0f-ae61-9e3012126ed9)) - **How Malicious Code Hides in Go** - Sneaking vulnerabilities into Go dependencies is more likely via slow, incremental malicious code additions than cryptographic collisions. - Visibility of Go source code limits hiding malicious code compared to compiled languages. Transcript: Speaker 3 And two, how would you have to go about it? Speaker 2 The first thing I can think of is somehow, if you can somehow manage to get the vulnerability database or the some database, right, to maintain the same hash for the repository, despite The contents of the repository having changed. If you can somehow do that, right, then you're golden. Because what would happen is you'd have... That's interesting. Yeah, because what would happen is the checksum, the checksum sort of changes every time you commit happens. So if you say, hey, version 1 .0 .2, and this repository, right, this commit hash, right, all the constants, everything about this repository at point in time, generates a specific Checksum. And that goes into the sum DB. And then now, all of a sudden, you manage to somehow, right, have the same checksum without but having changed the repo somehow to include your malicious code, then you're in, you're In, because everybody will just, you know, the checks that happen is, hey, is this, are these things lining up? Is the checksum and the security checks we have based on that? Is everything lining up? Yep, you're good. But somehow we have new code coming in. That seems very improbable. But again, I mean, we're talking about the improbability of things here. Things that should never happen, but still happen. Speaker 3 Does it seem improbable? Isn't that kind of how Bitcoin mining works, right? Like, we're trying to append data until a hash matches what we expect. Could you not? Speaker 1 I mean, modern day cryptography is built on the assumption that it's not impossible, but close enough that collisions won't happen. Speaker 3 It might take a million years, right? Speaker 1 But you can do it, right? I think it's more of like, you know, the, you know, the comic where it's like, oh, like this person's used this level of cryptography. We can't get the, we'll never be able to break in and it's like beat them with this wrench until they give you the password. Right. Instead of trying to circumvent the system as a whole, like instead of trying to circumvent the computing system, you should circumvent the human system or find a vulnerability in That human system. You find a package that maybe has like what happened with XE where you have an overwhelmed maintainer and then you offer some help and you start doing things. Maybe at one point in one some innocuous commit, you just sneak a package in, your own package that you control that's just kinda not doing anything particularly fascinating or whatever, And then it's just there for a long time, people just get used to it, and then after a while, you add some, let's just code to that, and in like maybe a little patch version, you just bump The patch version, and then no one really notices, especially if this is a package you update, like frequently, if maybe you're adding a bunch of stuff to it, maybe you're building it Out a lot, so it just kinda slips under the radar, or it's like a dependency of your dependency kind of get some levels of indirection going. And then you know that that little vulnerable. You just slip a little vulnerability in there and then it kind of gets to everything. It just like another routine update that everybody sees whether you know you can't go and look at the code itself because it looks fine. It's like, oh there's nothing. It put me malicious code into the main dependency that people are looking at. It's at some further removed dependency that might have gotten updated like a while ago, and now it's just gotten like trickled up. So you have to really like chase down a lot of that. I think that's like the vulnerability. If you have a large pack of a lot of dependencies where someone could sneak something like this in. But I think that's like a much more viable path than trying to like break modern cryptography. Speaker 3 Yeah, you'd almost have to hide it in plain, but not almost, you would have to hide it in plain sight, right? I think that's one of the kind of the advantages of how Go does things, right? Like for say a C you're often shipping like a tar ball with compiled stuff in it, right? So you can hide whatever you want in there. I mean, you can, right? Speaker 2 I mean, hopefully it comes with a checksum. At least, you can at least verify. Speaker 3 But it's not like you're, it's not like you could hash your C code and make sure that what's in that tarball is what's in your C code, right? Because that's just not how it works. Like it's a pre -compiled piece. Speaker 1 Oh, you mean if you ship like a Like a like a dll. Speaker 3 Yeah an SL or something or yeah I don't actually know how it works not to be perfectly honest, but I know it's you're not shipping the C Yeah, if you just like the object code and you're like, Speaker 1 Oh just link this in during compile process so that it's part of it exactly The fact that we ship the source code, it's not, we're not shipping precompiled bits. Speaker 3 There's far less places to hide things, I think. So you really would have to slip it into plain sight slowly over time. ([Time 0:28:02](https://share.snipd.com/snip/f55430dc-7f3e-4204-b308-021d04ec4a3e)) - **Spot Suspicious Dependency Behavior** - Review your dependencies' code for suspicious behavior like network calls unrelated to their purpose. - Don’t trust dependencies blindly; identify unusual imports or functionality as red flags. Transcript: Speaker 2 What is this package that you're importing with the blanket then fire? What does it do? Speaker 3 Yeah, I'm going back to like the idea of hiding like malicious code in plain sight and go and I just cannot think of how to build something and go that makes a post request out without looking Like it's making a post request out. Right? Like, or at least looking like what you're doing something weird here, right? Like, like there's just not that many ways to hide stuff like that. Like, I mean, if you're, if you're clever, I'm sure there is. I can't think of one. Speaker 2 I mean, the first thing, in my workflow for validating things, which includes looking at PKG .go .dev and the metadata, whatever it is, if I dig sufficiently enough, one of the things That I do when I'm looking at repositories for some dependency that my dependency or, you know, like, how many deep, right? I have to go. If I just do a quick search for HTTP, for HTTP package, right? And repository. If I find some, then I'm going to be very interested in this package. And what it like, like, this thing is supposed to be, I don't know, like flipping characters backwards or something. Why? Why is the HTTP? Need? Like, I mean, you kind of have to be critical. Like, you know, this package is supposed to do this thing, a very specific thing. Why is it doing network calls? Like, like what's going on? Then things like that, that should be obvious smells that you need to investigate. And these are what I'm talking about. We can't catch everything. And no matter how, whatever our processes are that we think, oh yeah, we go through umpteen different hoops. We make people jump through. So we avoid vulnerabilities. Security is a game of mitigation and sort of safeguards. And it's not something you can 100% sort of, you know, do, right. So part of that mitigation is, as you as a developer, right, being you kind of the first line of defense here, right. And sort of being critical of these things, I'm importing this package. It's supposed to do this. Why is it doing that? Yeah. ([Time 0:35:46](https://share.snipd.com/snip/fce3b83d-2dc3-40d8-98d5-34683bfeac5d)) - **Use Vulnerability Bots Wisely** - Add a security vulnerability scanner bot to your CI to alert you of vulnerable dependencies. - Update dependencies only when vulnerabilities are disclosed or when new features are needed. Transcript: Speaker 3 And so if you just want a first step, just put that in your CI system and update when it tells you. I think that'll go a long way. Sounds good. Speaker 1 And now, for our favorite, for our favorite little segment of the show, Unpopular Opinions. Speaker 2 Things should probably leave. All right. Speaker 1 Who has an unpopular opinion? Speaker 2 Oh, I'll reiterate mine from earlier. I think on balance, backend developers are more security conscious than front -end developers. Because for a lot of reasons we just talked about, but the sheer number of vulnerabilities popping up from the NPMs of the world, it just seems to me like they're there again. I'm painting broad strokes here, but to me, it feels like it's too easy to simply copy paste, you know, code components from frameworks, a lot and then assume simply assume that it's All taken care of right like you don't, you know, some CDN some library from some CDN here. Of course, that's what we always do in the community, right? ([Time 0:41:15](https://share.snipd.com/snip/d6563dd2-1589-4783-b6a9-d62c76562dc3)) - **Backend vs Frontend Security Focus** - Backend developers tend to be more security conscious than front-end developers due to control and stakes. - Front-end security issues often stem from lack of cryptographic usage and control over the runtime environment. Transcript: Speaker 2 I get less of that from front -end communities. Speaker 1 I don't know. I mean, I definitely think that backend people... Yeah, I feel like because so much security is pushed onto the backend, there's so much that needs to be done to secure it, and it's such a big target. I think it's like the people in the backend do tend to be a little bit more focused on that instead of the other aspects of things, where the front -end people are just mostly focused on Trying to get the front -end like work and Wrangling with you know the many different browsers and all of the weird things that happen between them I think it's also like a level of control That you wind up having More of in the back end than you do in the front end right end of the day your code is running on someone else's computer on top of One of many browsers. It's just like a stack. You're just completely out of control. You don't have control over, whereas in the backend, you have a lot more control over your stack and everything that's happening with it. Speaker 3 I mean, I do think backend developers should be more security conscious, right? Like, if you just think about the stakes, right? Back in Roan, really, you might release your whole database. A front -end, like, it might be one user, right? Like... Speaker 2 Well, trying to go to JSTOR sends you to, you know, casino .com or something, right? It's not, you know, it's not nothing. Speaker 3 No, it's not nothing. And I do think both should be, but I mean, I would rather... If had to have one of my users attacked, I would rather it be like individual users than my whole database, right? Speaker 1 I think part of it also comes from the fact that like your backend code is within your secure domain and your frontend code is not, and you kind of have to treat your front -end code as if It's hostile, like, in all cases. So I think that kind of lowers the necessity in some cases of needing to be as security conscious about what's going on in your front -end. And most of the time, a lot of the front -end vulnerabilities, like cross -site scripting, can be blocked or prevented from, like, on the back -end side of things as well. But do think the kind of lack of security awareness for front end people, especially lack of cryptographic awareness does hinder in some ways. Like I've noticed that there's not a huge amount of the use of the cryptography APIs in the browser, where that could be a much better way to do authentication and authorization. Or you can like browser has had APIs for years now where you can just create a public -private key pair that is locked into the browser where another script, even on your same domain, can't Extract that key. And that would allow you to uniquely identify that browser in a cryptographically secure way, and you're not passing around tokens that can be kind of no matter what if someone can run Some JavaScript on your website. So it's like, yeah, there's, there's a little bit you can do through cross site scripting. If you, you know, you can still make API requests, but you can't lift that key and send it to a server and start making a ton of requests or anything like that. Whereas you can do that with a bearer token. I think some of the reason that's not done is because there isn't as much of a familiarity with these tools and these ideas in the front end community. ([Time 0:43:16](https://share.snipd.com/snip/0fa6583e-2d1d-4a68-b002-79a4221487e7)) - **Learn C for Deeper Insight** - Learning C enhances understanding of how machines work and memory management. - This knowledge improves abilities in higher-level languages and helps write better software. Transcript: Speaker 1 Good for you. You are blessed. Okay. So my unpopular opinion, I feel like this is probably going to be unpopular, but I think everybody should learn C. They're not write everything in C or write a lot of stuff in C, but I think everybody's to learn C. I think I think that's a that's a thing that we as an industry need to do because I don't think people understand nearly enough how any of this stuff works. I don't think too many languages do a very good job at hiding all of it from you. Speaker 2 What about C specifically? Like you do your own memory management or like what do you want them to get out of it? Speaker 1 Yeah, I think C is one of the few languages that is just like basically touching the metal, right? It's like, it's like right there. I mean, the lower, the lowest you can go is like assembly, right? That's just trying to hand code machine code for some reason. But like, you know, there's like assembly and then right above it is C. So you get a lot of the nice higher level facilities that you get in other languages, but you have to understand how the machine works to write C or even to learn C. I understand like what this memory model is, to understand how your actual instructions are flowing to at least some degree if you want to write C or in other languages that don't have This procedural level to them where they're more object -oriented and things are more abstract. It can be more difficult to understand how your machine is actually functioning. Speaker 2 Oh, oh, oh, mentioned. So personally, I've been doing Go, I don't miss. Oh, and some people say, Oh, Go is object oriented. I mean, that that's a debate that's kind of gone and that's kind of gone on for quite some time. But I think writing Go feels more like writing C to me than any other language. So I'd say, yeah, if you're, if you've never done C, and you want to know what it was like, or what it is like, even still for some people that are still writing C code, then yeah, definitely, You know, take a peek, right? At least do a Hello World or something a little bit beefier than that, right? Just to give you an idea and see what it's like to actually do your own memory allocation and freeing, like, you know, get a feel for what it is that you benefit from from a more modern language, For sure. But as far as sort of object orientation, like multiple layers of abstractions, you know, and all these things. I don't really miss those things. The most abstract I ever want to go in my Go programs is using an interface or something. That's the extent of OO I ever want to do, abstractions I ever want to do. Speaker 3 I was going to say, I'm not sure I agree everyone should learn C, but everyone should try, I don't know, like a C style language, like go see something like that. And I say this, like, as someone who wrote in PHP and JavaScript for the first couple of years of my career, I had no idea that like an HTTP request was just like bytes over a over a key, right? Like, you're working as like, I mean, in JavaScript, you have objects and in PHP, you have these, like, big associative arrays. I was like, I have no connection of how those got switched between each other, right? They were just objects were just what they were. And there was no, I had no concept that everything is just bytes, right? And you make a lot of silly mistakes when you don't like have that core concept. So doing something at a lower level, I do think is important, even if you're only going to be working in those higher -level, more abstract languages. Speaker 1 Yeah, I think the reason I think C is specific, I mean, A, C is the lingua franca of all systems out there. If you want to talk between two languages, you're doing it through C at the end of the day. But I also think like maybe there was another language that we had that was like just could show you more of the fundamentals of how machines work. That would also be helpful because I think like one of the things was the C where it doesn't have anything. It's not like in Go where you just be like, oh, I'm going to say go in front of my function and it's going to go spawn a Go routine and yay, concurrency. It's like, no, you have to figure out how that works for what you're trying to do and how multi -threading works. But also, like, you know, you need to have some awareness of like, you know, what is a cash line and how does my CPU work and how do how do all of these things work where I think, like, enough People don't understand that now. And we write really bad software as a result. Speaker 2 Because we've been told we have unlimited memory and limited disk space and limited CPU, just another VCPU added. We've been trained in the last, in the cloud era. We've been traded just saying, oh yeah, don't worry about these things. Just we'll throw more hardware at the problem. Speaker 1 That's back in the day. We didn't have that luxury. People also do this with like, we talked about memory management, but it's the same thing with garbage collection. There's a whole thing of that line of like, oh, we have a garbage collection problem. You don't have a garbage collection problem. You have a garbage problem. You're creating too much garbage for your garbage collector to keep up with. You're just making too many things and throwing them away. I think there's this persistent idea that you don't do memory management in languages where you aren't doing manual memory management. It's like, no, you still need to do memory management. You still need to think about your memory and how you're laying things out and what you're doing with them and how many of them you have when you're designing application. But yeah, I think, you know, by going into the depths of C, I think you can learn a lot of this stuff and have enough of a familiarity to kind of to be better at the higher level languages. ([Time 0:55:53](https://share.snipd.com/snip/ff3b22c0-ae27-471a-9c10-7c19b8f4d805)) - **Act Fast on Polyfill.io Risk** - Immediately remove polyfill.io from your frontend code because of the recent supply chain attack. - Check front-end assets proactively to avoid malicious code running in your app. Transcript: Speaker 1 You for listening. And, you know, make sure that your your dependencies are in check. Don't have any vulnerable code running out there, please. Pretty please. Speaker 2 And do a quick grip on all your front ends. If you have polyfill .io anywhere in there, get that out. Run. Do not walk. Run to your closest VCS. ([Time 1:01:40](https://share.snipd.com/snip/5380b06e-59f7-41cf-9e77-d2c6f7787c35))