When Reusing Code Becomes a Security Problem

Almost nobody builds software from scratch anymore. Need logging? There's a library for that. Authentication, database connections, data parsing? Same story. Libraries save a huge amount of time and let us focus on the features people actually care about.

But there's a catch. Your own code can be perfectly secure and your application can still be vulnerable, because of something someone else wrote. So how do you trust code you don't fully control?

The problem with code you didn't write

A third-party library is just prewritten code from another person or organization. Say you're building a Java app. Instead of writing your own system for recording errors and activity, you pull in a logging library and move on.

That's convenient, but libraries can have bugs, outdated parts, or security flaws like any other software. When attackers find one, every application running an affected version is exposed.

It gets messier because dependencies have their own dependencies. You install one library and quietly end up with several others you never chose and may never have heard of. A vulnerability can sit in that hidden layer while you assume everything is fine.

NIST's Secure Software Development Framework (SSDF) recommends that organizations acquire well-secured components and keep verifying their security throughout their life cycles (Souppaya et al., 2022). In other words, checking a dependency once when you add it isn't enough. It's an ongoing job.

Why it matters: Log4Shell

The clearest example is Log4Shell, a critical vulnerability disclosed in December 2021 in Apache Log4j, a very widely used Java logging library (CVE-2021–44228).

According to a joint advisory from CISA and other security agencies, attackers could send specially crafted requests that made vulnerable software run unauthorized code. Depending on the system, that could mean stolen data, malware, or full control of the machine (CISA et al., 2021).

What made it so alarming was how common Log4j was. Plenty of organizations were exposed even though their developers never wrote a line of the vulnerable code. They first had to figure out which of their systems used an affected version, then update it, and then investigate whether anyone had already exploited it.

Log4Shell also shows that passing your tests doesn't mean you're safe. An application can do everything it's supposed to do and still contain a hole an attacker can use.

The deeper issue

The real problem isn't that developers sometimes use vulnerable libraries. That's going to happen. The problem is that development usually runs on features, deadlines, and convenience, while security management comes second.

Many of us also assume a popular library must be safe. Popularity doesn't prove that. Plenty of teams don't keep an accurate list of what they depend on either, so when a new vulnerability drops, they can't even tell whether they're affected.

Then there's ownership. Developers add dependencies, but it's up to the organization to give them the time, tools, and processes to keep an eye on those dependencies. When no one is clearly responsible, updates get delayed because everyone assumes someone else is handling it.

So this is as much an organizational problem as a technical one.

What I think teams should do

I believe organizations need a continuous dependency management process, not a hope that developers will remember to update things.

Know what you're running. Keep an inventory of your components, including indirect dependencies. A Software Bill of Materials (SBOM) is a practical way to do this.

Automate the scanning. Put dependency scanning into your pipeline so you're alerted when a known vulnerability shows up in a version you use. These tools aren't perfect, though. They can only flag what's already in their databases, so brand-new or unknown flaws will slip past them.

Prioritize sensibly. Not every update is equally urgent. Look at severity, exposure, and potential impact. A critical vulnerability in an internet-facing system needs attention right away. Test updates before deploying them so you don't break something else in the process.

Assign an owner. Someone should be clearly responsible for watching dependencies and responding to security advisories. This lines up with NIST's advice to keep verifying third-party components across the whole software life cycle.

All of this takes extra time, effort, and testing. Still, I think it's a fair price compared to what can happen when a critical vulnerability goes unpatched.

Final thoughts

Third-party libraries make development faster, and I'm not suggesting anyone stop using them. But they come with risks we can't afford to ignore. Log4Shell showed how one flaw in a popular component can ripple far beyond the library itself.

Writing correct code is only part of building secure software. We also need to know what our software depends on, keep watching it, and move quickly when problems appear. Reusing code should save us time, not give us an excuse to stop paying attention to security.

References

Cybersecurity and Infrastructure Security Agency (CISA), et al. (2021). Mitigating Log4Shell and Other Log4j-Related Vulnerabilities. https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-356a
Souppaya, M., Scarfone, K., & Dodson, D. (2022). Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. NIST Special Publication 800–218. https://doi.org/10.6028/NIST.SP.800-218