Why do we have to fix security vulnerabilities on the test scope dependencies?

Viewed 339

Why do we have to fix security vulnerabilities on the libraries that we use only in testing scope?

I've been trying to find the answer online but no luck so thought of asking here.

For example: https://nvd.nist.gov/vuln/detail/CVE-2021-23463 I found this vulnerability but H2 was included as <scope>test</scope> in maven.

Testing code does not get shipped to production environment, so I was wondering why do we have to fix such vulnerabilities if it's only vulnerable in testing scope.

Thanks in advance!

2 Answers

TL;DR - It is probably more work to figure out if it is safe to not fix a vulnerability (in your tests) than to just fix the vulnerability.


Why do we have to fix security vulnerabilities on the libraries that we use only in testing scope?

I can think of a couple of reasons why you might have to fix the vulnerabilities:

  1. Because your management, or the security team tells you that you have to. They may tell you this for reason of compliance to some internal policy, or some external compliance rules ... or even for legal reasons. Or maybe because someone has a "thing" about it. They may not distinguish between production and test code.

  2. Because you are unable to conclusively show that the vulnerabilities in the test scope do not constitute a risk.

    For example, could the vulnerability be exploited by a bad actor who has access to your CI infrastructure? Can you demonstrate that that is not possible? Or that that would not provide a way to do significant damage ... to something that matters?


And the converse is:

  • IF management doesn't say that you have to fix them AND you can conclusively show that the vulnerability is NOT a risk in your test infrastructure THEN you could decide to not fix them.
  • HOWEVER if your assessment is in incorrect THEN the blame and consequences will fall on you.

In short ... you need to decide if you should take the risk of ignoring the vulnerability.

Tests will likely be run by CI on your internal infrastructure. Or just on your developer machines. They will be run somewhere that is more or less internal to your infrastructure.

A vulnerability can be exploited in many ways, the one you mentioned is an XXE. A malicious xml file can be used to do stuff on the host that processes it. This might allow an internal unprivileged attacker (eg. a developer) to compromise CI that might have access to more valuable credentials. Or it might allow an external attacker to compromise a developer PC (by somehow providing malicious xml input), and then compromise CI from there, and so on.

You can see the point, you don't just want to protect your production environment. Sure, that might be the most important, but the way to protect it is to apply defense in depth, and mitigate risks for the whole infrastructure.

Related