• caglararli@hotmail.com
  • 05386281520

web app 3rd party JS dependency vulnerability management

Çağlar Arlı      -    51 Views

web app 3rd party JS dependency vulnerability management

As a security engineer, I wonder about the common approach for web app 3rd party JS dependency vulnerability management. We have a lot of apps depend on Jquery etc. In a regular vulnerability scan, old versions of JS libraries (which alot of them has XSS CVEs) reported as vulnerability. Without really reading and understanding the code, you can't say your app is affected by those XSS's or not and it is not an easy job for a security engineer. However, upgrading with newer version (which hopefully no assigned XSS CVE s) is not easy too because it requires effort for new developments and QA-UX tests on the app by other teams. I believe it is common problem. So what is the industry standart (applied by big players like Google, Apple, microsoft etc.).

We have cases that we classify the issue as vulnerability, without providing an actual XSS exploit. However development teams are not happy to upgrade it because of the effort. They suggest fixes by editing the library.

So what to do when you encounter an old JS library that has known vulnerabilities?

To Force the upgrade despite to development and test effort?

To fix the old version on your side by looking at the changes over source code? (guess it is the worst idea)

Totally ignoring it until an XSS exploit has been found for that specific app? (finding the real exploit is not easy because the need of really examine where the vulnerable part is and find out if you are using it or not. pretty time consuming for dynamic testers and it is completely manuel)

Classifying them as a risk instead of vulnerability

other ideas?