Skip to main content

Handling Project Dependencies with Security Issues


So your software composition analysis (SCA) tool has let you know that your project includes a dependency that has a security problem. What do you do next?


Well, obviously, you want to fix it, right? The thing is, for any software project of any size, ‘fixing it’ might not be easy. Even if it is, getting your fix into the hands of customers might not be straightforward and will not be without risk (for you, or them).


And you might not need to fix this dependency with any urgency at all, even if the finding is a bad one. Why? Because an exploitable issue in a dependency you use does not necessarily translate to a vulnerability in your product. Sure, you want to make sure you’re running a more recent version; but not necessarily right now.


(As an aside, keeping dependencies as current as possible always makes this task much easier – but that’s a topic for another time)


To fix or not to fix?


This changes the problem; it’s no longer “we need to fix this now”, it’s more “we need to fix this at the most appropriate time”.


So how do you determine what is appropriate?


1.  Determine whether the dependency is used.


Yes, that’s right – you might be including dependencies with your application that are no longer actually used. Or, you have testing dependencies that aren’t actually used in production. So that’s the first step; establish whether that’s the case.


2.  Determine how the dependency is used.


There are two aspects of this: You want to determine whether it’s a direct dependency (something your software uses directly) and whether it’s transitive dependency (something another dependency of your software uses). It may be both! If it is a transitive dependency, you may want to get in touch with the project teams that maintain the direct dependencies that rely on it. They’ll need to carry out something like the next step before you know the best course of action available to you.


3. Determine whether your application makes use of the dependency in a way that exposes the vulnerability 


This step requires a little more effort and usually requires some detective work.


Advisories related to the dependency in question will typically include a summary of what the issue is and where, within the dependency’s code base, the vulnerability lies.


For example, if the advisory explains that “fictitiousLib has a vulnerability in the mythicalFunc function which can result in arbitrary code execution in cases where an attacker can influence the value passed to someParam,“ you’ll be asking: “Do I do anything that results in mythicalFunc being called?” And, if so: “What data are passed to mythicalFunc when it’s called?” If that function is never called from your code (or its dependencies), or it is, but the data passed can’t be controlled by the user, you’re most likely*(see footnote) safe.


Resources that can help


Doing all of this manually requires a great deal of work.


SCA tooling


Fortunately, there are tools that can help. Some SCA tools currently on the market can provide indicators for whether a dependency vulnerability is likely to be hit. If you have access to this capability, it’s great to have. 

Automated test coverage


There are also options available to you that can help you in the absence of this feature; good automated test coverage is one of them. The simplest approach is to instrument the calls to the dependency in question (either using your debugging tools, or some other means) so you can audit the call sites during a test run. This allows you to see, for each invocation of the vulnerable code, what data makes its way to the call (and possibly other information too, like the call stack).


In practice, this is not always possible. I’ve found this to be particularly tricky when making use of javascript libraries; the distributable files are often minified and/or obfuscated, which makes it hard to debug and inspect the use of specific functionality.


ZAP extension


To help with minified or obfuscated sources, we wrote an extension for the popular ZAP web security tool; this allows you to replace the minified distributable version of a script with either the corresponding un-minified sources (with source maps), or a custom version of your choice.


The extension can be found here; hopefully it’ll be included in a future ZAP release.


(Footnote: there are classes of DOM XSS issue where simply including a vulnerable script in a document can expose the vulnerability – make sure you read the advisory carefully)


Learn more about Matillion security


Visit our Security Page for everything you want to know about Matillion security, including security in our products, answers to frequently asked questions, our security certifications, and how to request a security report.


Go to the Security Page


Or to learn more about security best practices in the cloud, download our ebook, The Data Leader’s Guide to Enterprise Cloud Security