The Security Hole We Keep Ignoring: Third-Party Scripts

Every few months, another major breach. Every time, the same core problem: developers linking to code they don't control, hosted on servers they don't manage, executing with privileges they haven't verified. I've been covering technology since the 1970s. Some patterns you see once. This one repeats.

Dave and Glenn tackled this question directly in their latest Shop Talk episode, and the conversation surfaced something I've watched happen in slow motion over three decades: the normalization of dependency. "When you had all of your libraries and header files on your PC, the supply chain attacks were not a thing," one viewer noted. "Pulling every function of your code from random internet places is crazy and dumb."

Dave's response cuts to the practical reality: "You can't do everything yourself. That's the problem. For some projects you can, but for things of certain complexity with enough dependencies, you're going to be at some point dependent on an external resource."

He's right. But that doesn't make the situation less precarious.

The Attack Surface Keeps Growing

Thirty years ago, your attack surface was smaller because your software stack was smaller. Operating systems weren't secure—they tried, but they weren't there yet. The difference now isn't that individual components are worse. It's that there are so many more of them.

"Even though the software is probably in some ways for security certainly better than it was 30 years ago, there's just so much more of it that you're going to find a hole somewhere in that whole stack," Dave explains. More dependencies mean more trust decisions. Each one is a potential vulnerability.

The municipal water analogy Dave uses is apt but incomplete. Yes, we trust external infrastructure. The difference is regulation, inspection, accountability. When your city's water supply fails, there are consequences, investigations, liability. When a JavaScript library you pulled from a CDN gets compromised, you're the one explaining to customers why their data leaked.

What Developers Actually Do

The gap between best practices and actual practice remains wide. Dave admits the sketchiest thing he sees—and has done himself—is the Homebrew installation pattern: "You go to a website, it says, 'Here's a big command line to run under Linux,' and it's got sudo in it, and it runs a script from the web. You got to trust somebody to take their script, pipe it through sudo, and run it on your machine."

This should terrify us. It doesn't, because we've done it hundreds of times without incident. Until the incident.

The practical advice Dave offers is sound: choose your scripts wisely, pin versions, run everything through your CI pipeline, test compatibility before deployment. But notice what's missing—a way to actually verify that the code does what it claims and nothing else. We're still operating on trust, just with more steps.

The AI Complication

Then there's the AI factor, which adds another layer of abstraction. When developers use AI to generate code, they're trusting not just external libraries but external intelligence about how to use those libraries. "Using AI to generate code—does that mean fewer developers actually understand what they're building?" one viewer asked.

"Yes," Dave answered. "Eventually it will."

His daughter built a website using AI-generated code. She's not a developer. The code requires Node. Did her site need Node? Probably not. But the AI thought it did, so now it does. Multiply this pattern across thousands of projects and you get infrastructure bloat, dependency sprawl, and an ever-expanding attack surface that nobody fully understands.

"If it works and it meets my needs, then I don't mess with it usually," Dave says about AI-generated code. This is rational behavior for an individual developer on a deadline. It's also how technical debt compounds and security assumptions go unexamined.

The Backup Reality Check

One of the more telling exchanges came around backup verification. Dave got burned when his backup system sent confirmation emails for backups that weren't actually completing—wrong email template, his notifications were lies. Now he manually checks folders periodically.

"How often, Dave?"

"Not often enough."

This is the reality of system administration at every scale. We know what we should do. We do less. The gap between theory and practice isn't laziness—it's the impossible math of finite time versus infinite potential failure modes.

What Actually Matters

The conversation meandered through Claude code leaks, AI guardrails, and whether Cursor still has a reason to exist (Dave doesn't think so). But the through-line is control versus convenience. We've chosen convenience. We've chosen it so consistently that the alternative now seems quaint.

Dave's observation about JavaScript tooling captures this: "It's amazing to me the amount of infrastructure people bring along with them to do small tasks." His own sites are three files plus a couple images. Most modern sites require npm, Yarn, webpack, Babel, and six layers of abstraction between the developer and what actually runs in the browser.

Each layer is someone else's code. Each dependency is someone else's decision about what's safe, what's tested, what's good enough. We've built an industry on the assumption that this scales. The breaches suggest otherwise.

I've seen this movie before—different technology, same pattern. In the 1990s, we trusted ActiveX controls. In the 2000s, we trusted Flash. Each time, we convinced ourselves the convenience justified the risk. Each time, we were eventually proven wrong. The question isn't whether third-party dependencies will continue to be a security problem. They will. The question is whether the current generation of developers will learn this through experience or education.

History suggests experience.

Bob Reynolds is Senior Technology Correspondent for Buzzrag