Home > database >  Snyk vulnerability scan not recognizing overriden nested package dependencies
Snyk vulnerability scan not recognizing overriden nested package dependencies

Time:11-15

I am running the snyk test command on my project to identify vulnerabilities with third party libraries and came across the following vulnerabilities in [email protected] ->@svgr/webpack": "^5.5.0"

  1. Regular Expression Denial of Service (ReDoS) - [email protected]
  2. Regular Expression Denial of Service (ReDoS) - [email protected]

To mitigate this, I added a dependency override( or dependency resolution in my case as the project is using yarn) in my package.json as shown below to replace the nested dependencies with a non vulnerable version :

  "resolutions": {
    "loader-utils": "^2.0.3",
    "nth-check": "2.0.1",
    "@svgr/webpack": "^6.2.1"
  },

and did yarn install. I confirmed in the project bundle that with these change , the latest version of loader-utils and nth-check was being installed. I also checked with Snyk Extension on VS Code and it seemed to resolve the vulnerability issues.

But when I run the snyk test in github actions pipeline as shown below :

      - name: Run Snyk test scan
        uses: snyk/actions/node@master
        with:
          command: test
          args: --severity-threshold=high --fail-on=all

it still reports the vulnerability on nth-check and loader-utils. My assumption is that, this is because Snyk github actions doest really install your dependencies before running a code analysis. Instead it examines the package.json file and unwrap the dependencies layer by layer causing it to think I still have the vulnerable dependencies as nested dependencies within react-scripts package, while in reality that gets overriden by the resolutions section in package.json.

Is there a way to circumvent this or force snyk to consider the nested dependency overrides ?

CodePudding user response:

After some research I found that there is no such issue within Snyk itself. The problem was in our snyk configuration. The scan configured to run on the package.json in our main branch while the fix was on a separate branch. Once we updated the snyk scan to run on the correct package.json, it did identify the issue as resolved.

  • Related