The Secret Passengers in Your Code

By: Karrie Westmoreland

If patching your main applications is like locking your front door, updating your dependencies is like checking the windows, the back door, and that cellar hatch you forgot existed. 

Dependencies are the libraries, frameworks, and third-party packages your software quietly leans on to function. They are the unsung heroes that keep your applications running, and sometimes, if neglected, they become silent liabilities waiting to be exploited. 

The reality is that in modern applications, most vulnerabilities do not come from the code your team writes. They hide in the open-source libraries, vendor SDKs, and plug-ins quietly bundled into your builds. The good news is that with the right processes, these risks are not only manageable but preventable. By catching and addressing dependency vulnerabilities early, organizations can turn potential breaches into quick wins for security and stability. 

• Most code is borrowed In many modern applications, between 70 to 90 percent of the codebase comes from dependencies rather than in-house developers, according to studies by GitHub and the Linux Foundation. 

• Exploits move fast Threat actors often scan for vulnerable library versions within hours of a public disclosure. This was seen with vulnerabilities like Log4Shell, which was actively exploited the same day it became public. 
• Supply chain attacks are growing rapidly From SolarWinds to poisoned npm packages, malicious actors know that compromising a single dependency can give them a foothold in thousands of downstream applications. Sonatype’s 2024 State of the Software Supply Chain report shows a 742 percent increase in software supply chain attacks over the past three years.

Dependency vulnerabilities are not hypothetical risks. They are active attack vectors that are scanned for and exploited every single day. 

1. Update Released Maintainers publish a new version of a library, often with security fixes included. 
2. Notification Received Your tooling alerts you that you are running an outdated version. 
3. Testing in Staging You check if the update breaks any functionality. 
4. Deployment to Production You roll it out with confidence. 
5. Verification You confirm it is working and the vulnerability is resolved. 

Think of it like replacing worn brakes on your car. You get the mechanic’s alert, order the new parts, test them in the shop, then hit the road knowing you can stop safely when it matters most. 

The Situation: During a 2025 security review, a company was found running a customer portal built on an outdated PHP framework. A critical SQL injection flaw had been patched by the vendor two years earlier, but the update had never been applied. 

What Happened Next: Before the vulnerability could be exploited, the internal security team identified it through a scheduled dependency audit. The framework was immediately updated in a staging environment, tested for compatibility, and deployed to production the same week. 

• Track framework versions in an asset inventory. 

• Subscribe to vendor security advisories. 

• Schedule and execute regular updates before they become urgent security events. 

2. The Poisoned Plugin 

The Situation: An e-commerce client was using a popular payment plugin that relied on an open-source JavaScript library. The library’s maintainers had issued a critical update after detecting malicious code injection. 

What Happened Next: Automated vulnerability monitoring flagged the issue within hours of disclosure. The security team temporarily disabled the plugin, switched to a backup payment method, and ran a full dependency scan. Testing confirmed no malicious code had executed in production, and the patched version was safely deployed within 48 hours. 

• Use automated tools such as Dependabot, Renovate, or Snyk to detect risky packages early. 

• Keep a staging environment ready for testing and validating updates. 

• Build a rapid-response plan for isolating or replacing vulnerable components. 

“If it is not broken…”: The thinking goes: if the app is running and customers are not complaining, why mess with it? Unfortunately, “not broken” often means “not obviously on fire yet.” It is like refusing to change your car’s oil because the engine still runs fine. That works until it seizes in the middle of the highway. 

Update Fatigue: The flood of updates can feel like trying to drink from a firehose hooked up to an espresso machine. Minor patch releases can appear daily, piling up until your “we should probably update this” list starts to resemble the Leaning Tower of Pisa. Nobody wants to be the one who pulls the brick that makes it topple. 

No Clear Ownership: When everyone is responsible, no one is responsible. Dependency management often lives in a gray zone between DevOps, security, and engineering. It is the software equivalent of “whose turn is it to take out the trash?” And just like in a shared apartment, the pile grows until someone finally deals with it. 

Lack of Visibility: Without a Software Bill of Materials (SBOM), it is hard to know exactly what is inside your code. This is like baking a cake, leaving it out for six months, and then trying to remember if you used flour or powdered sugar. You cannot update what you cannot see, and teams are often unaware of the libraries buried three layers deep inside of other libraries. 

Much like patching, the challenge with dependency updates usually is not the update process itself. The real challenge is the moving parts around it: scheduling, testing, coordinating across teams, and making sure nothing else breaks in the process. Updates often get penciled in for “right after this release,” but timelines can stretch, priorities shift, and suddenly that update is still sitting on the to-do list. 

One way to avoid this is to make updates a natural part of the development rhythm. Use small, regular update windows that fit comfortably alongside other work. This steady approach keeps projects on track and, more importantly, helps ensure systems, software, and client data stay safe both at rest and in transit. 

Cybersecurity works best when it is built into the process from the start, not bolted on at the end. This is the thinking behind the Shift Left ideology, which moves security considerations earlier into the development cycle so issues are caught and resolved before they can cause trouble. 

1. Actively exploited vulnerabilities: Update within 24 to 48 hours, following guidance from CISA’s Known Exploited Vulnerabilities catalog. Treat these as emergencies with a hotfix deployed as soon as possible and a rollback plan ready. 
2. Security patches not under active attack: Aim for a seven-day turnaround. Roll the update out to staging first, verify functionality, then deploy to production. 
3. Major version upgrades: Use a quarterly schedule. Allocate time for testing, coordinate across teams, and plan in advance. 
4. Minor and patch updates: A monthly cycle works well. Automate where possible to reduce manual effort. 

• Automation First Let automation handle repetitive work so your team focuses on decisions, not chasing version numbers. Automated pull requests from tools like Dependabot or Renovate keep you aware of outdated dependencies. Pair this with automated security alerts and policy checks in your CI/CD pipeline to ensure updates pass tests before merging. 

• SBOM Management A Software Bill of Materials is your ingredient list for software. Generate it regularly, store it centrally, and feed it into vulnerability scanners so you are alerted as soon as something in your supply chain turns risky. 

• Test Like You Mean It Robust automated testing, from unit to end-to-end, takes the fear out of updates. If something breaks, you will know before it reaches production. 

• Ownership Assign a Dependency Steward or dedicated team to take charge. Visibility and accountability keep updates from falling through the cracks. 

Dependency updates are not glamorous, but they are one of the most effective ways to prevent vulnerabilities from sneaking into your software. By making them part of your routine, you protect your clients, your organization's reputation, and your peace of mind. 

Your code might be brilliant, but it is only as secure as the code it relies on.  

Keep it fresh, keep it safe, and your applications will thank you, in case your clients forget to.  

Dependency management will never make headlines, yet it is the quiet shield that keeps your applications from becoming tomorrow’s breach story. Treating updates as a chore is like treating seatbelts as an inconvenience. You do not notice their value until the moment you desperately need them. 

The path forward is simple but not passive. Inventory what you have, automate what you can, and make updates part of your regular development rhythm. Keep your SBOM current, ensure someone owns the process, and test until you are confident that updates make your software stronger, not weaker. 

Your code is a living ecosystem. If you leave its dependencies to rot, vulnerabilities will take root in the dark corners of your supply chain. If you tend to it regularly, you build resilience that no threat actor can easily dismantle. 

So start today. Schedule that update window. Turn on automated dependency alerts. Assign a steward for the process. 

Every dependency you update is one less open door for someone else to walk through.