Tangled Up in Transitive Dependencies
Dear Sloan,
I just started a new job, and my first priority is to reduce our project vulnerabilities. When I investigated, I found that our most severe vulnerabilities are due to “transitive dependencies.” I’m overwhelmed with the prospect of cleaning it up. Where should I start?
Signed,
Tangled Up in Transitive Dependencies
Greetings!
Congratulations on your new position, and for stepping up to proactively manage your transitive dependencies to reduce your project vulnerability. No need to panic – we will untangle the web of transitive dependencies together.
Why Do You Have Transitive Dependencies?
Modern developers subscribe to the “work smarter, not harder” approach to drive rapid builds and efficiency. Let’s say your peer contributed to an OSS project; now you get to reference and use it (thanks, friend!). But your peer also referenced someone else’s work, and so on and so forth. Your project builds upon the code from each individual’s work and all the work they referenced too. This creates a nesting of dependencies called “transitive dependencies.”
There are a couple of ways transitive dependencies can cause you headaches. The first is when your build calls for the external dependency and it isn’t found. Your code breaks; everything grinds to a halt, and you’re left bewildered about the cause.
The second is a security risk. While the intention of OSS is generally altruistic, there are bad actors who maliciously alter code for their own nefarious gain.
Ultimately, you are an OSS consumer and depend on someone else to maintain and secure code referenced in your project. If you’re not taking the lead, who is? Ideally, you!
Remediate Your Dependencies
Your first course of action is to assess your current dependency management system, a topic I talked about in last month’s Ask Sloan article. Then, familiarize yourself with your company’s Software Composition Analysis (SCA) tool and governance policies. Carefully consider your direct dependencies: if you’re not using a particular component, can you exclude it? Once you identify and prioritize your vulnerable components, you’ll want to upgrade them.
Transitive dependencies are linked to their parent, so identifying and upgrading your direct dependency components is the simplest fix. Yet, according to the 2022 State of the Software Supply Chain report, you’re most likely choosing the wrong upgrade. Most developers fall into the trap of two categories – upgrading to the latest version or upgrading to the most popular version.
Make sure when upgrading to the newest version, that you are doing so for the right reasons. It doesn’t pay to have the latest and greatest version if it isn’t compatible with your other components. But, do upgrade to the newest version if it introduces a bug fix. Also, this isn’t a popularity contest; the most popular version doesn’t mean it’s the most secure. In fact, the report referenced above suggests you stay 2.7 versions behind the latest version.
If you can’t upgrade, or the upgrade doesn’t remediate the transitive dependency vulnerability, your next option is to migrate to a different component. You’ll want to do your research when choosing a new component. Choose a compatible, lower-security-risk component and migrate to it.
Assume the Risk
There are times when risk will need to be accepted, and we call that technical debt. You will assume the risk from the vulnerable components but continue to track them. Generally, there are five reasons to assume technical debt.
- Low or no risk of exploitation
- Limited product life
- Some mitigating control is in place
- Time to implement a fix is excessive
- Implementing the fix produces a domino effect of change
Be mindful of accruing technical debt as it will continue to grow, making remediation even more difficult.
Untangling the Knot
Nobody likes to be vulnerable, but this is a safe space. Keep your management proactive and simple: Scan often, upgrade or migrate as necessary; rinse and repeat.
Do transitive dependencies and their management keep you up at night? How do you stay proactive on your vulnerabilities? Let us know in the comments below.
Wishing you the best,
Sloan
~ Making Cyber a Safer Space
There is a flood of open source vulnerabilities to be managed. The remediation burden on developers keeps growing. We need to tackle this from a few angles:
Regarding “migrate to a different component”, i would love to see suggestions from Sonatype for components without a non-vulnerable upgrade path. Let’s say you are using AngularJS, which is end of life and has critical security vulnerabilities. I would love to see Sonatype suggestions for alternative components/ frameworks, based on security rating and popularity. Right now the burden (rightfully so) lands on the shoulders of the developer, but a list of suggested alternatives will definitively help in making the right choice.