Dependencies 101: How Much of Your Code Did You Actually Write?
In this episode of Open Source Open Mic, we explore how developers actually build software today. With open source dependencies making up the majority of modern applications, the idea of “writing everything from scratch” no longer reflects reality.
This conversation breaks down what dependencies are, why developers rely on them, and how they shape productivity, security, and code ownership. We also dig into the challenges of understanding and managing increasingly complex dependency trees.
If you’re a developer navigating modern tooling and workflows, this episode will help you better understand the code you ship, and the code you depend on.
Transcript
0:00:04: Think about the last application you built.
0:00:09: Hundreds of libraries, maybe millions of lines of
0:00:09: code. But the question is, how much of that code
0:00:15: did you actually write? Today, we're talking about
0:00:15: dependencies and the role they play in modern
0:00:20: software development. Let's break it all down on
0:00:20: this episode of Open Source Open Mic. This is open
0:00:28: source open mic, the podcast where we talk about
0:00:28: everything happening in the world of open source
0:00:33: security. So pull up a chair. It's time for an
0:00:33: open conversation. Hello everyone and welcome to
0:00:41: another episode of Open Source Open Mic. My name
0:00:41: is Andrew Garrett and I am a product marketing
0:00:48: manager here at Sonotype and I'm pleased to be
0:00:48: joined today by my guest Eddie Knight. Eddie is a
0:00:55: software and cloud engineer with a background in
0:00:55: banking technology. When he isn't playing with his
0:01:00: three-year-old son, he combines his passion and
0:01:00: job duties by working to improve the security of
0:01:07: open-source software. Eddie currently helps lead
0:01:07: several security and compliance initiatives across
0:01:17: the CNCF, Open SSF, and Finnos. Well, Eddie,
0:01:17: it's great to have you on this episode today. Is
0:01:21: there anything else you would like to add about
0:01:21: your background? Oh, uh, absolutely. Uh, so, so
0:01:31: here in Sonotype, we have a, uh, special role, uh,
0:01:31: reporting to Brian. If you, if you, uh, few folks
0:01:38: remember that Brian originally made Maven Central,
0:01:38: uh, was part of the team that made Maven
0:01:43: before coming to found Sonotype. Um so so he
0:01:43: has always been deeply deeply passionate about
0:01:50: securing open source at the source as well as
0:01:50: uh at the ingestion point which is where Sonotype
0:01:55: specializes. Um but I have been very lucky for
0:01:55: the last couple years to fill the role that is
0:02:00: focused on actually going out to open source
0:02:00: projects to help with security. Um so I've been
0:02:07: part of the technical oversight committee for the
0:02:07: financial technology open source ecosystem. Uh I'm
0:02:14: a security adviser for the CNCF and uh and I built
0:02:14: the open source project security baseline which
0:02:21: is now a uh very highly adopted security standard
0:02:21: uh used across the Linux foundation other open
0:02:27: source ecosystems. The German government is using
0:02:27: it. Uh, so it's really fun that Sonotype has been
0:02:32: sponsoring me to do a lot of these things that
0:02:32: um that are just helping every single project
0:02:37: around the world make their software just a
0:02:37: little bit more secure for end users. It's been
0:02:43: really fun. Yeah, that's amazing. And Eddie,
0:02:43: I'm really glad that you carved out a few minutes
0:02:48: of your time today to speak with me. And you know,
0:02:48: the topic that we're going to touch on today
0:02:52: um is all about dependencies. We're calling it
0:02:52: dependencies 101. and we're going to talk about
0:03:00: how much of your code did you actually write. So
0:03:00: let's start right there. Um you know o open source
0:03:08: has become so prevalent in in the modern world and
0:03:08: I wanted to ask your opinion how much of modern
0:03:18: software is actually written by developers? Oh,
0:03:18: well I mean when the alternative is if it's
0:03:23: written by an AI um I think I think the really
0:03:23: interesting thing is how much of it is written by
0:03:30: your team, right? Uh I I can't estimate how much
0:03:30: is written by AI specifically, but we know that
0:03:37: it's like 90 95% sometimes higher of the of the
0:03:37: code is dependencies that's written by somebody
0:03:44: else that you've never met. Um, actually, okay,
0:03:44: Ilka probably won't be upset with me talking
0:03:50: about something that he's not uh publishing yet,
0:03:50: but uh he has this amazing tool right now that
0:03:57: he's it's kind of an R&D uh where he's taking
0:03:57: all of our data from uh sbombs. So, he's taking uh
0:04:03: one big like Spring Boot. He he show he showed me
0:04:03: this. He pulled up Spring Boot and he put it into
0:04:10: a galaxy map where all the dependencies are not
0:04:10: in just like a tree where they're like pointing
0:04:15: to each other, right? Um, but they're they're
0:04:15: loaded out into this like big ball that has all
0:04:21: the lines between it and stuff, but he it's like
0:04:21: three-dimensional. So, it's like a freaking star
0:04:27: map, but it's so big that he had to blow it out
0:04:27: into clusters to where it's like, okay, these 12
0:04:36: are uh kind of related topically. These 12 are
0:04:36: uh kind of frequently used by those, but it's
0:04:42: just this massive blob of clusters of dozens and
0:04:42: it's just all over the place. And then you have
0:04:46: the lines that you can kind of follow between it
0:04:46: and then he starts color coding it to show you
0:04:50: which ones have vulnerabilities. if you find one
0:04:50: malware in there, it's super surprising, but it's
0:04:55: like a big deal. Um, but it's just it's massive,
0:04:55: right? He says, "Okay, now look what happens when
0:04:58: I switch it to a tree because a lot of us like
0:04:58: to think of our dependencies as a tree, right? I
0:05:04: import your software, you import Bob's software,
0:05:04: but Bob might import Stacy's software, and
0:05:09: I import Stacy's software." So, it starts
0:05:09: getting really wonky. So, he says, "Look,
0:05:13: look what happens when it turns into a tree,
0:05:13: right? And it becomes this like smooshed thing
0:05:18: that doesn't even fit on the screen anymore. It's
0:05:18: just horizontally, just massively wide. It's maybe
0:05:25: five or six layers deep, but it's a thousand wide,
0:05:25: right?
0:05:25: right? Uh and and that's just because the way that
0:05:32: we write software, especially in modern languages,
0:05:32: is just it's you you stand on the shoulders
0:05:38: of giants. You import other code that works
0:05:38: because it does it well. You don't need to repeat
0:05:43: it, but your dependency space is just massive.
0:05:43: Absolutely massive. Yeah, I I'm glad you bring
0:05:53: that up because yeah, 90% 95% of all software,
0:05:53: you know, we we hear this percentage often, 90
0:06:00: to 95% is open source. And I like what you said
0:06:00: standing on the shoulders of giants. And um you
0:06:07: know, I I I wanted to to bring up the point of
0:06:07: dependencies specifically. Um but when we talk
0:06:15: about how much open source is out there and and
0:06:15: the the way that code is written today um can you
0:06:23: break down what exactly is a software dependency?
0:06:23: What does that mean? Um yeah. Yeah. So if you're
0:06:28: writing software then this is old hat for you. Uh
0:06:28: but if you're managing software teams then then
0:06:33: it is still important for you to understand that
0:06:33: um like you like the code that your teams are
0:06:43: writing is going to have a list of imports that
0:06:43: comes from somebody else and they're going to have
0:06:47: a list of imports, right? And so we call these the
0:06:47: first ones that we choose, we call those direct
0:06:54: dependencies and the ones that our choices chose,
0:06:54: we call those transitor dependencies. But any
0:06:59: software that we import from outside is is our
0:06:59: software dependencies. Okay. Yeah, that makes
0:07:08: sense. So, um why would you say developers rely
0:07:08: so heavily on dependencies today? Because giants
0:07:15: step on us, but standing on the shoulders of
0:07:15: giants lets you be above all of it, right? You can
0:07:20: there's no reason to be writing all of that code
0:07:20: yourself. Yeah. Yeah. I like that. So, uh, speed
0:07:32: comes into play. Um, developers are able to just,
0:07:32: uh, write code faster. Um, they're not trying
0:07:38: to reinvent the wheel or or build something
0:07:38: from scratch. Um, also security, security is
0:07:45: a huge thing. Um, uh, there there's actually
0:07:45: a uh some guidance that that we have, uh, which
0:07:53: is like we call it don't roll your own crypto,
0:07:53: right? you need to do cryptography, but you do
0:07:58: not know how to do cryptography. Like, there's
0:07:58: probably five people that I'm ever gonna meet that
0:08:04: actually understand how to do cryptography and do
0:08:04: it well. You should not be trying to do the thing
0:08:09: that those five people have already done and made
0:08:09: available to you. Yeah. Yeah. No, that makes total
0:08:18: sense. Um, so let's dive into that a little bit
0:08:18: more. um when when thinking about the dependencies
0:08:28: that teams are actually using since they're not an
0:08:28: expert in in everything right to your point. Um
0:08:35: is it challenging sometimes for organizations to
0:08:35: actually understand what dependencies they're
0:08:44: using? Oh yeah. Um, I mean the more that we
0:08:44: the more that we bring in um like modern supply
0:08:52: chain tooling uh it gets easier but even with
0:08:52: things like um GitHub's dependabot that are out
0:08:58: there um you're not you're not like getting a
0:08:58: really good view like that star map that I told
0:09:03: you that I showed me like that just changed my
0:09:03: mind. I was just like that is a gamecher. I I
0:09:09: hope that he can put that in a video somewhere
0:09:09: that everybody can see very very soon. But uh
0:09:15: but it it's just there's so many dependencies in
0:09:15: a single application especially I mean direct and
0:09:21: transitive and you know multiple layers deep it's
0:09:21: just so huge uh that when you start putting them
0:09:28: into an SBOM you get a little bit more machine
0:09:28: readable visibility where your machines can start
0:09:33: to know about them um but mapping them graphing
0:09:33: them things like that it's a massive undertaking.
0:09:42: Yeah. Um yeah, we hear the term dependency trees
0:09:42: um just sprawling out like like you're describing.
0:09:51: Um another term that is a new term for me is
0:09:51: a polyglot environment. Does that mean anything
0:09:57: to you? What what is that? What exactly is that?
0:09:57: Yeah. Well, I mean polyglot is multiple languages,
0:10:06: right? Um uh it's not uncommon now to have kind of
0:10:06: your your backend and your front end in a monor
0:10:13: repo um ch compile and ship your code together.
0:10:13: Uh in some cases you're you're able to just do
0:10:20: it all with with u with TypeScript. But but yeah,
0:10:20: once you start having an environment that
0:10:24: has multiple different languages in it,
0:10:24: then you have multiple different mechanisms for
0:10:30: tracking those dependencies in each of those. Um
0:10:30: some some languages uh do like locking, some of
0:10:38: them do like vendor style packaging. Um there's
0:10:38: like there's a lot of different ways in every
0:10:44: ecosystem to do it. There's some patterns so
0:10:44: we can build tools on top of these things that
0:10:48: fall that kind of follow the different patterns.
0:10:48: Uh but every every different language ecosystem
0:10:56: manages its dependencies differently. Okay. So,
0:10:56: you know, going back to my earlier question about
0:11:02: um organizations understanding what they're using,
0:11:02: what you're describing, it sounds like this would
0:11:10: be really hard if if I am the the dev lead or
0:11:10: or I'm managing a a team of developers. Our our
0:11:19: dependency tree is just sprawling out. It sounds
0:11:19: like the security risk would be just exponential
0:11:25: at this point. the larger your dependency tree
0:11:25: grows. I mean, is that is that really hard to
0:11:31: secure something like that when you don't even
0:11:31: know sometimes some of the things you're pulling
0:11:39: in? Yeah. And um we there there was a point in
0:11:39: time when Son was the only vendor dealing with
0:11:44: this and we used to have to teach people about
0:11:44: this like hey there's more happening than you
0:11:50: can see that you know this is this is beyond a
0:11:50: tip of an iceberg situation. This is like a boat
0:11:55: on the ocean kind of situation. Uh, you know,
0:11:55: there's there's just miles and miles of black
0:12:00: water beneath you and you have no idea what's
0:12:00: down there. Um, but but nowadays there's there's
0:12:06: an entire ecosystem around it. And I think most
0:12:06: folks are starting to understand that at
0:12:12: least they are in a dangerous situation,
0:12:12: right? Like they are sailing in a ship and if
0:12:16: this ship goes down, they're they're they're in
0:12:24: a they're in a bad spot. Um but but without that,
0:12:24: without proper like good tooling, good visibility,
0:12:35: um I I I I hope that you have a big team and
0:12:35: a small software footprint. Yeah, I like that.
0:12:39: Let's stay on your analogy here
0:12:39: of a boat on the ocean because
0:12:46: uh if you're this boat on the on the open source
0:12:46: ocean, let's call it um there are several hazards
0:12:52: or or icebergs if you want to call them
0:12:52: that you can run into um vulnerabilities,
0:12:58: malicious packages, abandoned projects. How
0:12:58: do you go about navigating those challenges?
0:13:00: Yeah, I mean I I I I keep going back to um to to
0:13:07: like you have to have software to help you with
0:13:07: this, right? And that's where you start getting
0:13:11: into like your job really is in triaging this,
0:13:11: right? So once you have tooling in place
0:13:16: that tells you, hey, here's a vulnerability,
0:13:16: uh here's some malware, um hopefully you have
0:13:21: software that can tell you when when when there's
0:13:21: abandoned software, um uh or bad patterns, things
0:13:27: like that, you know, but you're you're starting
0:13:27: to get into to pretty complex software at that
0:13:32: point. Um but what what happens is like what
0:13:32: do you do once you get those alerts? That's where
0:13:39: you're back in control again. like um trying to do
0:13:39: it without software like you're in a bad way.
0:13:48: Yeah. Yeah. And I I just think about recently
0:13:48: uh some of the headlines we've seen coming coming
0:13:53: through the security news lately. There have been
0:13:53: a lot of largecale cyber attacks over the last few
0:14:01: months. Um and we're recording this in in early
0:14:01: 2026. Uh but as I think back on some of these
0:14:08: largecale breaches, you know, every every time
0:14:08: one of these breaches comes across my feed and I
0:14:16: read about it, I I always just think to myself,
0:14:16: don't haven't they learned like haven't these
0:14:20: organizations learned by now? Don't don't they
0:14:20: have the the security measures in place? Um
0:14:26: so I guess my question to you is how does
0:14:26: this keep happening? How do we keep seeing these
0:14:33: open- source breaches even when we have so many
0:14:33: security teams and we have projects like OASP,
0:14:40: you know, the the OASP top 10, we have so many uh
0:14:40: like warning signals, I guess, uh best practices,
0:14:48: advice, so many things out there. How is it that
0:14:48: this keeps happening so often and and it seems
0:14:57: like the trend is frankly getting worse? Yeah.
0:14:57: Well, I mean, uh, AI is not making any part of
0:15:04: security easier.
0:15:04: Like, it's the more you use AI,
0:15:04: the less the more likely you're to have a breach.
0:15:08: And I use AI. I'm not I'm not saying don't use it,
0:15:08: but I'm just saying you're you've got a different
0:15:18: set of problems now. Um but uh let's so so some of
0:15:18: the big open source breaches um would be like um
0:15:27: so there's a few there's a few examples right uh
0:15:27: so non-malicious log for shell right um it was a
0:15:35: vulnerability that was detected later on and it's
0:15:35: found to be like okay that's a big deal we need to
0:15:43: patch it right um that uh was that you know that
0:15:43: was a Christmas surprise prize a few years back.
0:15:49: Big deal. Um then a couple years ago we have the
0:15:49: um the XC XZ utils, right? Uh and there was
0:15:56: a really good video by uh was it Veritassium
0:15:56: that did a a video on Jatan um on Xutils uh
0:16:04: and it it breaks down like how complicated
0:16:04: this attack was. It was it was uh but it was all
0:16:12: social engineering. Uh and um then after 2 years
0:16:12: of social engineering it became a technical attack
0:16:19: to where it was like okay cool. How do we get this
0:16:19: uh across the finish line and then how do we hide
0:16:23: it right? How do we get our attack in there and
0:16:23: then how do we keep it from being detected? Uh
0:16:28: and the interesting thing is that it was detected
0:16:28: by the obfuscation. the obuscation slowed down the
0:16:37: code and uh one one person was able to find it. Uh
0:16:37: barely barely in time. Uh which then creates the
0:16:44: question that is kind of at the heart of this is
0:16:44: like well how many other times has that succeeded
0:16:49: if we only found it this once. Um but that was
0:16:49: uh social engineering was was the big front there.
0:16:55: It was a two-year social engineering attack. Um
0:16:55: not by one person. Uh there is one persona and
0:17:02: then a series of supplemental personas that
0:17:02: um thatounded the maintainer until the maintainer
0:17:10: was exhausted and the uh the primary persona
0:17:10: stepped in and was like, "Hey, I got it from here.
0:17:17: Don't worry, man. We're in this together." Right.
0:17:17: Yeah. He was he we we the the theory is that
0:17:23: there is anywhere from 3 to 12 people on that
0:17:23: one account making sure that that account was like
0:17:30: really doing good work for those two years. Um so
0:17:30: so so that's so first one vulnerability happens
0:17:39: you need to patch um second one you need to detect
0:17:39: it and then patch it. Um, second one was social
0:17:45: engineering. Um, and then the third one is um is
0:17:45: a uh the very very very recent one, this trivia
0:17:52: attack. There's two trivia attacks recently. Um,
0:17:52: the one that that I'm thinking of right now for
0:17:58: the to continue this little narrative is the
0:17:58: um it was a exploit of GitHub. And so this
0:18:07: is actually a a a core ecosystem utility that
0:18:07: we all rely on, right? It's like GitHub is like
0:18:14: the electric company for for a lot of us, right?
0:18:14: There's like there's a couple electric companies
0:18:18: depending on where you live in the world. You
0:18:18: could kind of pick up your entire business and
0:18:23: move somewhere else to have a different electric
0:18:23: company. Uh same thing with GitHub, right? Like
0:18:29: once you're on GitHub, you're on GitHub. Um the
0:18:29: um the the interesting thing is that uh there's
0:18:35: a particular vulnerability in GitHub that GitHub
0:18:35: refused to patch. they they called it a feature
0:18:40: just like that, you know, we're not fixing that,
0:18:40: right?
0:18:40: Uh and it manifests in two ways and and
0:18:45: we've known this for a really long time. GitHub's
0:18:45: known it. I don't know which humans at GitHub
0:18:49: have known it, but it's like logged in their
0:18:49: systems for for a very long time. Um two ways
0:18:55: that it can be exploited. Uh one is uh through
0:18:55: malicious attachments. Uh so what'll happen is um
0:19:04: I trust uh you know the Andrew Garrett on GitHub
0:19:04: and I know that that you only produce software
0:19:11: that I love, right? Good software. I love you.
0:19:11: You send me something. Totally trust it. Run it
0:19:17: without asking, right? Um then somebody comes to
0:19:17: me and says, "Hey, look at this uh new thing, you
0:19:26: know, this new new package from Andrew Garrett,
0:19:26: right?" And I look at the URL and it says
0:19:32: github.com/andrewgarit something download path,
0:19:32: right? Like cool, let me download that. Uh turns
0:19:40: out somebody else went to your GitHub repo, left
0:19:40: a comment on that GitHub repo with an attachment.
0:19:48: that attachment's URL is now Andrew Garrett and
0:19:48: you cannot do anything about that. You cannot
0:19:54: delete that. You can't unattribute that that
0:19:54: download link. That download was uploaded in your
0:20:00: namespace and it is there. That link is is solid.
0:20:00: You would have to take that and like go through
0:20:05: some GitHub support channels, right? If if I I
0:20:05: and I'm this one I I might be teasing the lines
0:20:09: a little bit, but I think even if that person
0:20:09: uploaded it and then deleted the comment, the
0:20:13: upload's still there and it still has your name
0:20:13: in the path. You might not even even known that
0:20:18: it was uploaded under there to go through the the
0:20:18: rigomemer roll of trying to get it taken down. Um
0:20:28: so so that's a uh a very specific attack path like
0:20:28: it's it's involving a download. You need to know
0:20:33: the targets operating system, things like that.
0:20:33: um it's not been widely used as an attack path.
0:20:40: Uh so as people have been reporting it, there's
0:20:40: not like a lot of use cases where it's like and
0:20:43: this is how it ended the world. It's like that
0:20:43: that hasn't really happened, right? Um the second
0:20:52: the second thing, same problem is uh GitHub's uh
0:20:52: um branches, right? So, we can have your GitHub
0:21:01: uh Andrew Garrett and I can make a pull request to
0:21:01: your main branch on your repo, right? Well, all of
0:21:07: my commits that used to be mine. They used to be
0:21:07: Eddie Knight/ whatever Shaw commit, right? As soon
0:21:13: as I open up a pull request, it's duplicated. So,
0:21:13: now I've got commits on mine and I have those
0:21:19: commits in your space as a pull request branch.
0:21:19: M so now I can put anything into your name space
0:21:28: including operational code right so what somebody
0:21:28: did was they went to Trivy which is a security
0:21:34: tool that loads of people use uh you know
0:21:34: hundreds of thousands of people use it minimum um
0:21:39: I think I think uh when when the exploit went out
0:21:39: it was something like 240,000 people just like
0:21:46: downloaded it right away um wow so what happened
0:21:46: was uh somebody went on to trivia and they said
0:21:53: Hey, uh, the official GitHub actions repo has an
0:21:53: update. Here's the Shaw. And Trivia was just like,
0:21:59: yeah, whatever. And they merged it in. The path
0:21:59: was GitHub/GitHub. Like, why would you not trust
0:22:05: that? It's like the official GitHub thing. Well,
0:22:05: if, and here's the wild part, because I know that
0:22:12: that's an exploit. Um, when somebody showed that
0:22:12: to me, I was traveling at the time, so I didn't
0:22:16: see it till like 3 days later, so I knew it was an
0:22:16: exploit. and they're like here here's here's the
0:22:22: PR from the exploit and I look and I was like let
0:22:22: me go to that Shaw and I go over there and there's
0:22:28: just a super obvious I am stealing your code like
0:22:28: it's the most obvious thing in the world and it
0:22:32: was on a closed PR like the GitHub staff just
0:22:32: were like they looked at that and they're like no
0:22:36: why would we merge that in closed the PR moved on
0:22:36: with their lives but it they weren't attacking
0:22:41: GitHub they were using GitHub's namespace to
0:22:41: attack Trivia and by extension everybody who used
0:22:50: Trivy had all their secrets exfiltrated as soon as
0:22:50: they updated Trivy or as soon as they ran Trivy.
0:22:58: It was it was uh yeah it was very fast.
0:22:58: Yeah. So
0:22:58: this this sounds like social engineering at
0:23:05: its finest. Um yeah. So I guess it was kind
0:23:05: of a comp combination of social engineering
0:23:10: like you know I know that you trust GitHub,
0:23:10: right? But it's also a system exploit, right?
0:23:15: So, so that's where I was kind of showing like
0:23:15: different types of exploits here. Um, this one
0:23:18: is like you know that there's a vulnerability in
0:23:18: GitHub that GitHub hasn't patched. You know that
0:23:23: this person you want to attack is using GitHub
0:23:23: and so you go through the tooling. U so so this
0:23:31: is just kind of trying to to to elucidate on the
0:23:31: complexity of open source. It's this just massive
0:23:36: surface area. There's so many different ways to
0:23:36: attack it. So many different ways to social
0:23:41: engineer. so many different tools that you can
0:23:41: attack along the pipeline um hundreds of thousands
0:23:48: of packages to social engineer to get up to one
0:23:48: and that's what happened with XC utils right the
0:23:52: goal wasn't to compromise XC utils the goal was
0:23:52: to compromise the Linux kernel they almost did it
0:24:00: got into a release candidate like really big deal
0:24:00: so you you know we hear all the time this phrase
0:24:07: trust but verify trust but verify how how do you
0:24:07: verify in a situation like that, like what can
0:24:17: you do? Uh well, in the last example I gave um and
0:24:17: everybody should be doing this now. If somebody
0:24:25: who's not on your core team recommends an upgrade,
0:24:25: pins are not enough. We usually say like use pins.
0:24:30: Shaws, you have to like if if they if somebody you
0:24:30: don't know recommends a Shaw, either just reject
0:24:36: it or go check it. Um so that's like actually
0:24:36: going into the URL, swapping it out. It's kind of
0:24:43: complicated. Um, but I mean for end users, right,
0:24:43: for people who are not open source maintainers,
0:24:47: who aren't taking pull requests from the internet,
0:24:47: um, software, just have software that can check
0:24:56: these things, right? Um, because, uh, um, I forget
0:24:56: if it was the first or second trivia attack, um,
0:25:01: but all of the Sonotype users that had firewall,
0:25:01: it stops bad downloads, right? Um, firewall has,
0:25:09: you know, before AI was AI and we are still just
0:25:09: calling it machine learning. It's been doing
0:25:14: its thing. It hyper optimized on certain signals
0:25:14: detected the trivia attack in one minute. And
0:25:20: so anybody who I guess for the first minute we
0:25:20: weren't helping. Um, but after 60 seconds, uh, any
0:25:28: any of our users were were life cycle was aware,
0:25:28: stopped any incoming downloads and and were
0:25:33: protected, right? is just use the right tools.
0:25:33: Use the tools for the job that you're trying to
0:25:36: achieve. If you're trying to protect your open
0:25:36: source, have some SCA um have a internal registry,
0:25:43: have some tools that that can actually prevent
0:25:43: things from getting to your registry if they're
0:25:49: no malicious. Have scans in place on the things
0:25:49: in the registry and the dependencies that you're
0:25:54: using with your end users. Um it's just it's all
0:25:54: about just have the right tools. Then once you
0:25:59: have the right tools, what's back in your power
0:25:59: is what do you do when they alert? What do they
0:26:03: do? What do they what do you do once they send
0:26:03: up a signal? Uh that's back in your power again.
0:26:09: Well, I'm glad you brought that up because that
0:26:09: leads me into my next question um about having
0:26:16: good dependency hygiene. So, obviously you touched
0:26:16: on having the right tools. You need to have the
0:26:21: right tools and then you need to know what to do
0:26:21: when an alert comes in. Is there anything else
0:26:28: that you could recommend as a best practice to
0:26:28: maintain good dependency hygiene? What does that
0:26:38: look like? Ooh. Um, good dependency hygiene. Um,
0:26:38: when I hear that, and and you might need to to
0:26:43: lead the witness here a bit. When I hear good
0:26:43: dependency hygiene, I think of like minimizing
0:26:49: that surface area, right? Only use dependencies
0:26:49: that that you need. Um, don't use two of the
0:26:55: same thing if you don't need to, right? Uh,
0:26:55: there's there's m like in go in go there's uh
0:27:01: like my AI will always recommend a different
0:27:01: YAML parser, right? I use a lot of YAML. Uh, and
0:27:07: it's just always like it's like just recommending
0:27:07: a different one all the time. Um, I'll be in one
0:27:13: file using one YAML parser and it get to another
0:27:13: file and it's like use a different YAML parser.
0:27:17: Um, I think there's three to choose from, but
0:27:17: it also recommends outdated ones, right? So just
0:27:23: like keeping an eye on that that you're using only
0:27:23: dependencies that you need. Um and then uh because
0:27:32: you're already keeping it tight, double check
0:27:32: that you know that dependency like do I know that
0:27:38: author? Like does it at least look clean, right?
0:27:38: Is it does there is there some age on the account
0:27:42: or is it from an organization that I trust? Things
0:27:42: like that. And and then from there you can rely
0:27:47: on your tools for the rest. But like just kind of
0:27:47: a sniff test up front will go a long way. Yeah.
0:27:54: Yeah. And and if I could lead the witness here a
0:27:54: little bit, um I I think automation is a huge part
0:28:01: as well. And and you've touched on this a little
0:28:01: bit already, but you know, don't leave it all
0:28:08: up to you as the end user. You take some of that
0:28:08: out of your hands. if you can have some automated
0:28:16: policies, um, you know, things that just address
0:28:16: the concerns before they even reach you, right?
0:28:23: Yeah. Yeah. Well, awesome. Have the right tools.
0:28:23: You you you have to have the right tools. Yeah.
0:28:30: Absolutely. Well, uh, Eddie, this has been great
0:28:30: uh, talking about dependencies with you today.
0:28:35: I've I've learned a lot. And I did want to wrap up
0:28:35: our episode with a little bit of uh some something
0:28:43: I like to call the rapid fire round. Uh oh. So
0:28:43: this is where I ask you a question. You have to
0:28:50: answer in 10 words or less. Oh yeah. Okay. Okay.
0:28:50: So let's do it. So Eddie, in your opinion, what is
0:28:58: the biggest myth about open source dependencies?
0:28:59: I think there's like the
0:29:08: myth is that they're either
0:29:08: they're either
0:29:14: completely trustworthy or completely
0:29:14: untrustworthy. H I think that people tend
0:29:22: to shift between between the two of like oh like
0:29:22: we can't trust open source versus like oh with
0:29:28: uh with many eyes all bugs are shallow. We're
0:29:28: good guys. It's like it's somewhere in the
0:29:32: middle. You need to be you know we need
0:29:32: your eyes too. We need you to come over
0:29:36: and actually take a look so that way the
0:29:36: bugs are shallow. Okay. I like that it's
0:29:42: either completely trustworthy or completely
0:29:42: untrustworthy. It's either black or white.
0:29:47: That's that's the biggest myth in in your opinion
0:29:58: when put on the spot. Yeah, fair enough. Um well,
0:29:58: next question. What is the most common
0:30:08: dependency mistake that developers make?
0:30:08: Not thinking about dependencies. Okay. Uh
0:30:20: what is the most underrated supply chain risk?
0:30:20: Yeah, the security of your source forge.
0:30:25: Mhm. That is the most underrated risk I
0:30:25: think. Okay. Um what is one dependency
0:30:38: that every developer has used? Requests.
0:30:38: All right. And then to finish up here with our
0:30:44: rapid fire round, what is one habit every dev
0:30:44: team should adopt tomorrow? Spend more time
0:30:54: reviewing code. I like it. I like it. Well,
0:30:54: Eddie, this has been great talking with you
0:31:01: today. Um, really enjoyed the discussion. Uh,
0:31:01: really enjoyed your setup as well. You've got the
0:31:06: great mic, you got the nice backdrop. Uh, you've
0:31:06: been you've been the perfect guest for this.
0:31:11: So, this is very fun. Very fun. Andrew, thanks
0:31:11: for having me on. Absolutely. Yeah. And to our
0:31:18: viewers today, thank you so much for listening.
0:31:18: And if you're watching on YouTube, please remember
0:31:24: to subscribe to our channel. And if you have a
0:31:24: question for Eddie, please leave a a question
0:31:30: down below in the comments section. And uh we
0:31:30: hope you enjoyed our episode of Open Source Open
0:31:36: Mic. We'll see you next time. Thanks, everybody.
Related Resources
Software Dependencies FAQs
What is a software dependency?
A software dependency is any external code your application relies on. This includes libraries or packages you directly import, as well as transitive dependencies, which is code that your dependencies rely on.
What is the difference between direct and transitive dependencies?
Direct dependencies are the libraries you explicitly add to your project. Transitive dependencies are pulled in by those libraries, often without you realizing it, which is where complexity quickly grows.
How much of modern applications are actually dependencies?
Why do developers rely so heavily on dependencies?
Dependencies help developers move faster and avoid reinventing the wheel. Instead of building everything from scratch, you can use well-tested libraries to handle common functionality.
Why are dependency trees so complex?
Each dependency can bring in its own dependencies, creating a multi-layered graph. At scale, this can result in hundreds or even thousands of components in a single application.
What risks come with using dependencies?
Dependencies can introduce vulnerabilities, malicious code, or maintenance risks (like abandoned projects). The challenge is that many of these risks exist in parts of the codebase you don’t directly see.
Why is it hard to know what dependencies I'm using?
Because of transitive dependencies and multi-language environments, your full dependency graph can be much larger and more complex than what’s visible in your top-level configuration.
What does "dependency hygiene" mean in practice?
It means keeping your dependency footprint as small and intentional as possible, only using what you need, avoiding duplicates, and regularly reviewing what’s in your codebase.
How can developers manage dependency risk effectively?
Use tooling to gain visibility into your dependencies, automate checks for vulnerabilities or malicious packages, and review updates carefully, especially when they come from unknown sources.
What's a simple habit developers can adopt right now?
Spend more time reviewing code, especially dependencies and updates, before they make it into production.