Embracing Vulnerability: Mindfully Managing Dependency Risk Management

From Baby Dev to “Why Won’t This Merge?!”

When I first joined the engineering team, I saw dependencies as simple tools—little libraries that helped my code run smoothly. I would install them, import them, and then quickly move on to the next task. But more often than I expected, my pull request fails in Continuous Integration (CI) because of "vulnerabilities found.”

It was fine an hour ago!

It turns out that something deep in my dependency tree got flagged. It wasn’t my fault, but it was now my problem. And at Disca, we don’t ship code with known vulnerabilities. Period.

‍

Why Dependency Risk Is Real (and Constantly Changing)

Dependencies are awesome. They let us move quickly and build upon the work of others. However, they also mean that our codebase includes code from other people, their security habits, and sometimes, their mistakes.

‍

Tiny Packages, Huge Consequences

Attackers have shifted their tactics, often targeting small utility packages that countless applications rely on. 

A case in point: in September 2025, a phishing attack compromised 18 popular npm packages, including widely used ones such as debug and chalk. These packages boasted over two billion weekly downloads, and the injected code aimed to silently collect sensitive data when the impacted projects were executed. [esecurityplanet.com, wiz.io, semgrep.dev]

These weren’t obscure libraries. They were staples in the JavaScript ecosystem. One day, they were fine. The next day, they weren’t. 

Another case: in March 2024, a hidden backdoor was found in XZ Utils, a core library used by most Linux distributions. An attacker spent months pretending to be a helpful contributor, gradually earning trust and gaining commit access to the project. Once inside, they embedded a hidden backdoor into versions 5.6.0 and 5.6.1 of the XZ Utils package. This backdoor compromised the Linux SSH service, allowing attackers to bypass authentication and run code remotely. It served as a direct entry point into affected systems, essentially a “master key” hidden within the operating system's plumbing. [Akamai, JFrog, Datadog Security Labs]

This incident highlighted a critical lesson: supply-chain risks extend beyond your immediate codebase. Your stack's security is only as strong as its weakest link, be it npm modules or foundational libraries. 

Circle back to when I thought, “It was fine an hour ago!”

The reality is that vulnerabilities do not adhere to a schedule. New Common Vulnerabilities and Exposures (CVEs) are published incessantly. Once listed in the National Vulnerability Database (NVD), they may quickly be flagged by your scanners, sometimes within minutes. At Disca, we prioritize nightly dependency audits to ensure that even merged code remains secure.

‍

Practicing Dependency Hygiene

I've come to see dependency hygiene as similar to brushing your teeth. It’s not enough to do it once and assume you're safe forever. Just as skipping this daily ritual can cause serious dental problems, ignoring regular dependency checks can lead to major security weaknesses.

‍

The Myth of "Just Upgrade Everything"

Faced with a failed audit, my impulse was to simply reinstall everything and create a new lockfile. 

Bad idea. 

And this is why:

1. New Dependencies, New Risks: Upgrading can inadvertently introduce vulnerabilities, as newer versions might come with undiscovered issues.
2. Audit Nightmares: Regenerating a lockfile can change hundreds or thousands of lines, making it nearly impossible for anyone to conduct a meaningful review.
3. Loss of Reproducibility: Lockfiles exist to ensure stable builds; disregarding them undermines this stability.
4. Increased Attack Surface: A chaotic update process can obscure the origins and maintenance status of dependencies, thereby increasing the attack surface.

Instead, a thoughtful approach is essential – targeted, deliberate updates that fix only what’s necessary, enabling verification and testing while preserving the stability of the rest.

Our Approach at Disca

Disca’s main policy for managing dependency risks is: no merges while a known vulnerability is present in the diff or current codebase.

Disca also promotes the idea that effective dependency management is about building consistent, healthy habits. 

Here’s the model we use:

1. All Audits on Every PR

At Disca, we implement PR gates with Socket.dev. Every pull request runs through a supply-chain analyzer that checks for risky or malicious dependencies. If something’s vulnerable, the merge is blocked until it’s fixed.
Why: It’s better to stop the risk before it enters main.

‍

2. Nightly CI Audits

Every night, all repositories are re-scanned. If a new vulnerability is found (even in code that has already been merged), the CI fails, and alerts are sent to Slack.
Why: Vulnerabilities can appear retroactively. Nightly scans are your early warning system.

‍

3. Lockfile Discipline

We treat lockfiles as safety rails. Changes must be minimal, intentional, and reviewed.

Why: Random lockfile churn hides risk. Minimal diffs keep history clean and traceable.

‍

4. “Should We Even Add This Dependency?” Checklist

Before adding any new dependency, ask yourself:

• Is it well-maintained and widely used?

• Does it have very few maintainers, low popularity, or many third-party dependencies? (These are red flags)

• How many dependencies does it pull in transitively?

• Can you replace it with a few lines of your own code?

• Is the license compatible?

• Does it have long-term support prospects and an upgrade path if it breaks?

Why: Prevention beats remediation. Fewer, healthier dependencies mean fewer headaches later.

‍

When You Hit a Vulnerability: The Upgrade Playbook

When a vulnerability is flagged, here’s what I’ve learned to do:

1. Upgrade the root package first.
   That’s usually the direct dependency in your code. Upgrading the root dependency might be the only reason you have this dependency; this approach is easier but requires thorough smoke testing and possible code adjustments.
   ‍
2. Do a minimal recursive bump.
   ‍Run yarn up -R <package> or pnpm up -r <package> to upgrade just that single dependency recursively in a minimal way.

3. Remove and reinstall dependents if needed.
   Remove all dependencies from your package.json that might require this third-party dependency, and use yarn why package to confirm it's no longer necessary. Then reinstall the packages you've removed to give them a new installation timeline. This updates packages to the latest versions but doesn't modify the entire lockfile.
   ‍
4. Re-evaluate whether you need it.
   Do you even need this? Sometimes, the simplest fix is to delete it. There may even be alternatives that are better maintained.
   ‍
5. Use resolutions only as a last resort.
   They’re a short-term workaround, not a permanent fix. If the root package actually has a hard requirement for a vulnerable package, this is the ONLY time you should ever use resolutions, and only after checking with the repo for an expected resolution time. Resolutions should ideally never be used because they break semantic versioning strategies, meaning you have code that may or may not be compatible with other third-party dependencies.
   ‍
6. Never regenerate the full lockfile unless it’s controlled and tested.
   ‍It’s the nuclear option. Use sparingly.

‍

In closing, embracing the reality of dependency risks is crucial for any developer. By cultivating disciplined practices and understanding the fluid nature of security threats, we can better navigate the intricate landscape of modern software development.